From nthomas at redhat.com Wed Feb 1 10:30:45 2017 From: nthomas at redhat.com (Nishanth Thomas) Date: Wed, 1 Feb 2017 16:00:45 +0530 Subject: [Tendrl-devel] [TRACKING] Daily check-in summary for 20170201 Message-ID: https://meetbot.fedoraproject.org/tendrl-devel/2017-02-01/check-in_20170201.2017-02-01-09.03.html Thanks, Nishanth From nthomas at redhat.com Sat Feb 4 04:17:56 2017 From: nthomas at redhat.com (Nishanth Thomas) Date: Sat, 4 Feb 2017 09:47:56 +0530 Subject: [Tendrl-devel] [TRACKING] Daily check-in summary for 20170203 Message-ID: https://meetbot.fedoraproject.org/tendrl-devel/2017-02-03/check-in_20170203.2017-02-03-09.05.txt Thanks, Nishanth From mrugesh at brainfunked.org Tue Feb 7 10:14:38 2017 From: mrugesh at brainfunked.org (Mrugesh Karnik) Date: Tue, 7 Feb 2017 15:44:38 +0530 Subject: [Tendrl-devel] [TRACKING] Daily check-in summary for 20170207 Message-ID: Everyone has been pointed to specific jira issues before working on the specification/implementation to get a clear picture of the outcome expected. The jira issues are indicated via action items. https://meetbot.fedoraproject.org/tendrl-devel/2017-02-07/check-in_20170207.2017-02-07-09.20.html -- Mrugesh From japplewh at redhat.com Tue Feb 7 13:19:26 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Tue, 7 Feb 2017 08:19:26 -0500 Subject: [Tendrl-devel] move github repo for deployment machines in CentOS for Tendrl testing In-Reply-To: <4764ed26-0712-1ce7-bd58-e9c0caa2d50a@redhat.com> References: <4764ed26-0712-1ce7-bd58-e9c0caa2d50a@redhat.com> Message-ID: Hi Martin Please go through the steps to transfer this repository and I will accept it on the Tendrl side. https://help.github.com/articles/transferring-a-repository-owned-by-your-personal-account/ Thanks Jeff On Tue, Feb 7, 2017 at 4:38 AM, Martin Kudlej wrote: > Hi Jeff, all, > > On 12/01/2016 10:40 AM, Martin Kudlej wrote: > >> could you please move https://github.com/mkudlej/usmqe-centos-ci to >> https://github.com/Tendrl ? >> >> It is repository with Ansible playbook for deploying machines in CentOS >> CI for Tendrl testing. >> > > what is status of moving this repository to Tendrl group, please? > > > > -- > Best Regards, > Martin Kudlej. > RHSC/USM Senior Quality Assurance Engineer > Red Hat Czech s.r.o. > > Phone: +420 532 294 155 > E-mail:mkudlej at redhat.com > IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, > #usm-meeting @ redhat > #tendrl-devel @ freenode > -- Jeff Applewhite Principal Product Manager From mkudlej at redhat.com Tue Feb 7 13:37:27 2017 From: mkudlej at redhat.com (Martin Kudlej) Date: Tue, 7 Feb 2017 14:37:27 +0100 Subject: [Tendrl-devel] move github repo for deployment machines in CentOS for Tendrl testing In-Reply-To: References: <4764ed26-0712-1ce7-bd58-e9c0caa2d50a@redhat.com> Message-ID: <5c3c97de-5a54-dbd5-ad24-cd1e6eaeb330@redhat.com> Hi Jeff, as I have written in previous emails I have no rights for that. I've tried to do it before and also now and I see this error message: You don?t have the permission to create repositories on Tendrl Could you please transfer this repository to Tendrl? On 02/07/2017 02:19 PM, Jeff Applewhite wrote: > Hi Martin > > Please go through the steps to transfer this repository and I will accept > it on the Tendrl side. > > https://help.github.com/articles/transferring-a-repository-owned-by-your-personal-account/ > > > Thanks > > Jeff > > On Tue, Feb 7, 2017 at 4:38 AM, Martin Kudlej wrote: > >> Hi Jeff, all, >> >> On 12/01/2016 10:40 AM, Martin Kudlej wrote: >> >>> could you please move https://github.com/mkudlej/usmqe-centos-ci to >>> https://github.com/Tendrl ? >>> >>> It is repository with Ansible playbook for deploying machines in CentOS >>> CI for Tendrl testing. >>> >> >> what is status of moving this repository to Tendrl group, please? >> >> >> >> -- >> Best Regards, >> Martin Kudlej. >> RHSC/USM Senior Quality Assurance Engineer >> Red Hat Czech s.r.o. >> >> Phone: +420 532 294 155 >> E-mail:mkudlej at redhat.com >> IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, >> #usm-meeting @ redhat >> #tendrl-devel @ freenode >> > > > -- Best Regards, Martin Kudlej. RHSC/USM Senior Quality Assurance Engineer Red Hat Czech s.r.o. Phone: +420 532 294 155 E-mail:mkudlej at redhat.com IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, #usm-meeting @ redhat #tendrl-devel @ freenode From japplewh at redhat.com Tue Feb 7 13:38:33 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Tue, 7 Feb 2017 08:38:33 -0500 Subject: [Tendrl-devel] move github repo for deployment machines in CentOS for Tendrl testing In-Reply-To: <5c3c97de-5a54-dbd5-ad24-cd1e6eaeb330@redhat.com> References: <4764ed26-0712-1ce7-bd58-e9c0caa2d50a@redhat.com> <5c3c97de-5a54-dbd5-ad24-cd1e6eaeb330@redhat.com> Message-ID: Hey Martin If you can hop on the Tendrl slack channel and let's discuss Jeff On Tue, Feb 7, 2017 at 8:37 AM, Martin Kudlej wrote: > Hi Jeff, > as I have written in previous emails I have no rights for that. > I've tried to do it before and also now and I see this error message: > > You don?t have the permission to create repositories on Tendrl > > Could you please transfer this repository to Tendrl? > > > On 02/07/2017 02:19 PM, Jeff Applewhite wrote: > >> Hi Martin >> >> Please go through the steps to transfer this repository and I will accept >> it on the Tendrl side. >> >> https://help.github.com/articles/transferring-a-repository- >> owned-by-your-personal-account/ >> >> >> Thanks >> >> Jeff >> >> On Tue, Feb 7, 2017 at 4:38 AM, Martin Kudlej wrote: >> >> Hi Jeff, all, >>> >>> On 12/01/2016 10:40 AM, Martin Kudlej wrote: >>> >>> could you please move https://github.com/mkudlej/usmqe-centos-ci to >>>> https://github.com/Tendrl ? >>>> >>>> It is repository with Ansible playbook for deploying machines in CentOS >>>> CI for Tendrl testing. >>>> >>>> >>> what is status of moving this repository to Tendrl group, please? >>> >>> >>> >>> -- >>> Best Regards, >>> Martin Kudlej. >>> RHSC/USM Senior Quality Assurance Engineer >>> Red Hat Czech s.r.o. >>> >>> Phone: +420 532 294 155 >>> E-mail:mkudlej at redhat.com >>> IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, >>> #usm-meeting @ redhat >>> #tendrl-devel @ freenode >>> >>> >> >> >> > -- > Best Regards, > Martin Kudlej. > RHSC/USM Senior Quality Assurance Engineer > Red Hat Czech s.r.o. > > Phone: +420 532 294 155 > E-mail:mkudlej at redhat.com > IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, > #usm-meeting @ redhat > #tendrl-devel @ freenode > -- Jeff Applewhite Principal Product Manager From kdreyer at redhat.com Tue Feb 7 16:48:21 2017 From: kdreyer at redhat.com (Ken Dreyer) Date: Tue, 7 Feb 2017 09:48:21 -0700 Subject: [Tendrl-devel] move github repo for deployment machines in CentOS for Tendrl testing In-Reply-To: References: <4764ed26-0712-1ce7-bd58-e9c0caa2d50a@redhat.com> <5c3c97de-5a54-dbd5-ad24-cd1e6eaeb330@redhat.com> Message-ID: What is the Tendrl slack channel? Can we add a description to http://tendrl.org/community/ ? - Ken On Tue, Feb 7, 2017 at 6:38 AM, Jeff Applewhite wrote: > Hey Martin > > If you can hop on the Tendrl slack channel and let's discuss > > Jeff > > On Tue, Feb 7, 2017 at 8:37 AM, Martin Kudlej wrote: > >> Hi Jeff, >> as I have written in previous emails I have no rights for that. >> I've tried to do it before and also now and I see this error message: >> >> You don?t have the permission to create repositories on Tendrl >> >> Could you please transfer this repository to Tendrl? >> >> >> On 02/07/2017 02:19 PM, Jeff Applewhite wrote: >> >>> Hi Martin >>> >>> Please go through the steps to transfer this repository and I will accept >>> it on the Tendrl side. >>> >>> https://help.github.com/articles/transferring-a-repository- >>> owned-by-your-personal-account/ >>> >>> >>> Thanks >>> >>> Jeff >>> >>> On Tue, Feb 7, 2017 at 4:38 AM, Martin Kudlej wrote: >>> >>> Hi Jeff, all, >>>> >>>> On 12/01/2016 10:40 AM, Martin Kudlej wrote: >>>> >>>> could you please move https://github.com/mkudlej/usmqe-centos-ci to >>>>> https://github.com/Tendrl ? >>>>> >>>>> It is repository with Ansible playbook for deploying machines in CentOS >>>>> CI for Tendrl testing. >>>>> >>>>> >>>> what is status of moving this repository to Tendrl group, please? >>>> >>>> >>>> >>>> -- >>>> Best Regards, >>>> Martin Kudlej. >>>> RHSC/USM Senior Quality Assurance Engineer >>>> Red Hat Czech s.r.o. >>>> >>>> Phone: +420 532 294 155 >>>> E-mail:mkudlej at redhat.com >>>> IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, >>>> #usm-meeting @ redhat >>>> #tendrl-devel @ freenode >>>> >>>> >>> >>> >>> >> -- >> Best Regards, >> Martin Kudlej. >> RHSC/USM Senior Quality Assurance Engineer >> Red Hat Czech s.r.o. >> >> Phone: +420 532 294 155 >> E-mail:mkudlej at redhat.com >> IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, >> #usm-meeting @ redhat >> #tendrl-devel @ freenode >> > > > > -- > Jeff Applewhite > Principal Product Manager > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel From nthomas at redhat.com Wed Feb 8 07:49:14 2017 From: nthomas at redhat.com (Nishanth Thomas) Date: Wed, 8 Feb 2017 13:19:14 +0530 Subject: [Tendrl-devel] Tendrl demo recording Message-ID: https://bluejeans.com/s/VC32c/ Thanks, Nishanth From julim at redhat.com Wed Feb 8 21:11:43 2017 From: julim at redhat.com (Ju Lim) Date: Wed, 8 Feb 2017 16:11:43 -0500 Subject: [Tendrl-devel] Sprint 11 Planning - Summary Message-ID: Team: Here's a quick summary on what's planned for Sprint 11 based on the Sprint Planning discussion earlier today: *Sprint 11 (8 Feb 2017 - 21 Feb 22017)* - CRUD Ceph Pool - TEN-6 - Create a Ceph pool via APIACCEPTED - TEN-223 - CRUD refactoringDEVELOPMENT - TEN-229 - Create Ceph pool in UI NEW - https://github.com/Tendrl/ceph-integration/pull/104 - CRUD Ceph RBD - TEN-143 - Create a RBD via APIDEVELOPMENT - TEN-230 - Create Ceph RBD in UI NEW - https://github.com/Tendrl/ceph-integration/pull/107 - Create Ceph Cluster (Ceph Provisioning) - integration with ceph-installer - TEN-189 - Create Ceph 2.x cluster via API (OpenStack enabled) DEVELOPMENT - https://github.com/Tendrl/specifications/issues/48 - wire up flows with integration modules with goal to have API endpoint ready - UI work pending Monday, 16 Feb 2017 discussion - Create Gluster Cluster - integration with gdeploy - TEN-186 - Create Gluster trusted pool via API DEVELOPMENT - https://github.com/Tendrl/specifications/issues/49 - wire up flows with integration modules (Note: it will have the same API endpoint as for the Create Ceph Cluster) - UI work pending Monday, 16 Feb 2017 discussion - Basic user authentication in the API (TEN-231 ) - Required for alerting configuration - TEN-231 - Basic user authenticationSPECIFICATION - Dashboard - TEN-222 - View state of my Ceph cluster in the UI SPECIFICATION - TEN-221 - View state of my Gluster cluster in the UI SPECIFICATION - Notes: some evaluation done on how to enable the endpoints via performance monitoring, work will be around enabling backend support for this As always, you can see this same list at https://tendrl.atlassian.net/wiki/display/TEN/Sprints. Provisioning API documentation will be posted to the repository this week/today. That is aligned with the OSP-D requirements. CRUD Ceph Pool UX designs are underway and will be posted by the end of this week for discussions early next week. If I've missed anything, Mrugesh (or others), please feel free to add/edit. Thank you, Ju From rghatvis at redhat.com Mon Feb 13 10:22:43 2017 From: rghatvis at redhat.com (Bobb Gt) Date: Mon, 13 Feb 2017 15:52:43 +0530 Subject: [Tendrl-devel] Soliciting early feedback on RHSC 3.0 Install draft Message-ID: Aloha Hatters, It's docs time! (I hope nobody yawned) :D I've created a draft on RHSC 3.0[1] installation and would like to solicit your early feedback on the same. Just like we did for RHSC 2.0, you may leave your comments in the draft for CCS to consider and apply(same drill). Thanks a lot and have a good one! [1] https://docs.google.com/a/redhat.com/document/d/1cdCUAfQ3DHImXHhESZgwg_TEYy6Lo4BFDp2lV5L-KVY/edit?usp=sharing Regards [image: photo] Bobb GT Technical Writer, Red Hat Inc Mobile: +91 8411001236 <+91%208411001236> Website: redhat.com Division: Customer Content Services APAC Get a signature like this: Click here! From fbalak at redhat.com Thu Feb 16 10:06:42 2017 From: fbalak at redhat.com (Filip Balak) Date: Thu, 16 Feb 2017 05:06:42 -0500 (EST) Subject: [Tendrl-devel] Blocker for testing In-Reply-To: <1309205683.20844516.1487238912856.JavaMail.zimbra@redhat.com> Message-ID: <696255310.20848855.1487239602703.JavaMail.zimbra@redhat.com> Hi Anup, could you please look at our list of Blockers and High priority issues at [1]? I am especially concerned about [2] as it blocks our tests. Many thanks, Filip Balak [1] https://github.com/Tendrl/usmqe-tests/wiki [2] https://github.com/Tendrl/api/issues/82 From sankarshan at redhat.com Thu Feb 16 15:17:51 2017 From: sankarshan at redhat.com (sankarshan) Date: Thu, 16 Feb 2017 20:47:51 +0530 Subject: [Tendrl-devel] Query for Open Jira issues on https://tendrl.atlassian.net/wiki/display/TEN/Tendrl+Main Message-ID: Quick question, the query on is built using "... AND status not in (DONE, RESOLVED, CLOSED)" Looking at the the available states for the Status field (via ), I do not see the DONE/RESOLVED/CLOSED states. Where are these 3 state keywords being set? And who sets them? From fbalak at redhat.com Fri Feb 17 09:54:46 2017 From: fbalak at redhat.com (Filip Balak) Date: Fri, 17 Feb 2017 04:54:46 -0500 (EST) Subject: [Tendrl-devel] Blocker for testing In-Reply-To: References: <696255310.20848855.1487239602703.JavaMail.zimbra@redhat.com> Message-ID: <186294513.21181417.1487325286171.JavaMail.zimbra@redhat.com> Sure, I will contact you on IRC. Best Regards, Filip Balak ----- Original Message ----- From: "Anup Nivargi" To: "Filip Balak" Cc: "Mailing list for the contributors to the Tendrl project" Sent: Friday, February 17, 2017 10:23:16 AM Subject: Re: Blocker for testing Hi, Can you share your setup so I can debug this? This is not reproducible to me. Thanks. > On 16-Feb-2017, at 15:36, Filip Balak wrote: > > Hi Anup, > > could you please look at our list of Blockers and High priority issues at [1]? I am especially concerned about [2] as it blocks our tests. > > Many thanks, > > Filip Balak > > [1] https://github.com/Tendrl/usmqe-tests/wiki > [2] https://github.com/Tendrl/api/issues/82 -- Anup Nivargi From mkudlej at redhat.com Fri Feb 17 14:38:58 2017 From: mkudlej at redhat.com (Martin Kudlej) Date: Fri, 17 Feb 2017 15:38:58 +0100 Subject: [Tendrl-devel] Calamari-server for CentOS In-Reply-To: References: Message-ID: Hello all, I would like to ask again about calamari-server package for CentOS 7. Is there any plan to have calamari-server in Storage SIG in CentOS 7, please? On 01/17/2017 02:31 PM, Martin Kudlej wrote: > Hello Ceph users, > > I've installed Ceph from SIG(https://wiki.centos.org/SpecialInterestGroup/Storage) on CentOS 7. > I would like to install Calamari server too. It is not available in > SIG(http://mirror.centos.org/centos/7/storage/x86_64/ceph-jewel/). I've found > https://github.com/ksingh7/ceph-calamari-packages/tree/master/CentOS-el7 but there I cannot be sure > that it is well formed and maintained version for CentOS. > > Where can I find Calamari server package for CentOS 7, please? > -- Best Regards, Martin Kudlej. RHSC/USM Senior Quality Assurance Engineer Red Hat Czech s.r.o. Phone: +420 532 294 155 E-mail:mkudlej at redhat.com IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, #usm-meeting @ redhat #tendrl-devel @ freenode From kdreyer at redhat.com Fri Feb 17 16:11:57 2017 From: kdreyer at redhat.com (Ken Dreyer) Date: Fri, 17 Feb 2017 09:11:57 -0700 Subject: [Tendrl-devel] Calamari-server for CentOS In-Reply-To: References: Message-ID: I think the most up-to-date source of Calamari CentOS packages would be https://shaman.ceph.com/repos/calamari/1.5/ On Fri, Feb 17, 2017 at 7:38 AM, Martin Kudlej wrote: > Hello all, > > I would like to ask again about calamari-server package for CentOS 7. Is > there any plan to have calamari-server in Storage SIG in CentOS 7, please? > > > On 01/17/2017 02:31 PM, Martin Kudlej wrote: >> >> Hello Ceph users, >> >> I've installed Ceph from >> SIG(https://wiki.centos.org/SpecialInterestGroup/Storage) on CentOS 7. >> I would like to install Calamari server too. It is not available in >> SIG(http://mirror.centos.org/centos/7/storage/x86_64/ceph-jewel/). I've >> found >> https://github.com/ksingh7/ceph-calamari-packages/tree/master/CentOS-el7 >> but there I cannot be sure >> that it is well formed and maintained version for CentOS. >> >> Where can I find Calamari server package for CentOS 7, please? >> > > -- > Best Regards, > Martin Kudlej. > RHSC/USM Senior Quality Assurance Engineer > Red Hat Czech s.r.o. > > Phone: +420 532 294 155 > E-mail:mkudlej at redhat.com > IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, #usm-meeting > @ redhat > #tendrl-devel @ freenode > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel From mkudlej at redhat.com Sat Feb 18 08:57:02 2017 From: mkudlej at redhat.com (Martin Kudlej) Date: Sat, 18 Feb 2017 03:57:02 -0500 (EST) Subject: [Tendrl-devel] Upcomming demo Message-ID: <100937990.7371481.1487408222713.JavaMail.zimbra@redhat.com> Hi all, I think it will be great to do next demo with Tendrl installed by QE. I think in this phase of project there is no need to mock up environment for demo and we can just upgrade packages. Also any configuration options required for demo can be recorded and then documented. QE can prepare for demo this cluster: 1 machine for Api+Etcd, 4 with Gluster cluster, 3 monitors and 4 osd machines with Ceph cluster. If you need additional software like stress tool, please let me know. Best Regards, Martin K. From mbukatov at redhat.com Wed Feb 22 16:20:30 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Wed, 22 Feb 2017 17:20:30 +0100 Subject: [Tendrl-devel] closing some tendrl-alerting issues Message-ID: <5b082589-74b7-a025-900c-b20a41c4ec5c@redhat.com> Hi all, during my work related to alerting repo, I went through all issues reported there and noticed that 3 of them could be closed (based on my understanding): https://github.com/Tendrl/alerting/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20%22close%20this%22 Could somebody recheck this and close those if it's ok? It shouldn't take more than 5 minutes :) Thank you. -- Martin Bukatovic USM QE team From mbukatov at redhat.com Wed Feb 22 18:47:32 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Wed, 22 Feb 2017 19:47:32 +0100 Subject: [Tendrl-devel] simplification of python packaging Message-ID: <488dc6b4-2dd1-a43a-dcda-304faf82d04a@redhat.com> # Tendrl Dependencies issue Back in January, I created [issue #18](https://github.com/Tendrl/alerting/issues/18) about specifying dependencies in requirements.txt file, which I didn't like. Rohan argued that Tendrl developers maintain of dependencies via `pip freeze` this way. I accepted it and moved on. Then during/after fixing [tox/travis ci setup #25](https://github.com/Tendrl/alerting/pull/25) (which has been just merged), I realized the bigger picture here and noticed few problems as I wanted to fix remaining issues with tendrl-alerting before I create similar pull requests for the rest of tendrl python components, as we agreed on with Rohan and Nishanth. 1) First issue I noticed is that we have incorrect dependencies listed in requirements.txt file in most Tendrl repositories: * unnecessary modules are specified (not all items in tendrl-alerting requirements.txt must be there) * some required modules are missing (PyYAML is missing in tendrl-alerting requirements.txt) Those issues are then carried on into list of dependencies in rpm spec file, making the proble worse (eg. https://github.com/Tendrl/alerting/pull/28#discussion_r96627652). To solve this, I would suggest to not use `pip freeze` to generate requirements.txt file blindly (or to reuse requirements.txt from other tendrl repo), but rather add line with name of required module along new code which uses it. As long as one writes at least some unit tests for the new code, one would notice missing requirement early. So this is (imho) easy to solve and prevent. 2) Then the other issue is related to listing other tendrl component as a requirement. For example: tendrl-alerting requires tendrl-commons to run. Note that in this case, we: * don't have tendrl-commons on PyPI * we need to reffer to devel version (latest master from github) of tendrl-commons to run unit tests (even if we published tendrl-commons on PyPI) I was thinking how to solve this in a simple way and come up with the following: My Proposal ----------- Some tendrl python components are actually libraries (eg. tendrl-commons), while others are rather applications (eg. tendrl-gluster-integration or tendrl-alerting). Tendrl modules for libraries (such as tendrl-common) would follow somewhat higher standars for packaging: * installable via `pip install` (from end user perspective) * can be published on PyPI (I'm just saying that it would be possible) * all requirements listed directly in install_requires in setup.py * no requirements.txt file Tendrl applications, on the other hand: * have all requirements listed in requirements.txt file (including link to other tendrl libraries, via git+https url) * don't use install_requires in setup.py file at all * can't be installed via pip install (from end user perspective, dev could do whathewer coding/testing requires) * would not be published on PyPI Why I propose drop user-end installation via pip install for Tendrl application modules? Because full installation requires additional steps which are out of scope of pip install anyway, such as installation of default config files into /etc, installation of systemd unit files. Neither can pip list system (non python requirements). Droping this use case would simplify our packaging guidelines. Why I don't like to read requirements.txt file and push it into install_requires in setup.py? Because it's not necessary (see previous paragraph) and it's actually not possible: when I specify full git+https url of some other tendrl component like this: git+https://github.com/Tendrl/commons.git It's totally fine for requirements.txt file, but setup.py can't handle it. This way, full list of requirements would be on a single place. Why I suggest to drop requirements.txt file from tendrl libraries? Because this file is not meant to be used for specifying dependencies of libraries, it's not necessary. Does that make sense for you? What would that mean for tendrl-alerting? * https://github.com/Tendrl/alerting/issues/17 would be closed as not valid (that would be easy :-) * https://github.com/Tendrl/alerting/issues/18 would remain closed (again, quite easy) * requirements.txt file would need to be inspected: tendrl-common github url added, unnecessary modules removed, missing modules added * setup.py would not contain any code which pushes requirements.txt file content into install_requires (that is easy as well, there is no such code yet) -- Martin Bukatovic USM QE team From mbukatov at redhat.com Thu Feb 23 18:24:15 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 23 Feb 2017 19:24:15 +0100 Subject: [Tendrl-devel] distribution packaging Message-ID: Dear Tendrl community, I have another proposal related to packaging. And this time it's distribution packaging, by which I mean building and maintenance of rpm or deb packages. I'm not sure how much my idea make sense for us, but it's at lest worth discussion/consideration. This is important because such packages are main deliverable from the end user point of view. In the rest of this email, let's focus on rpm packages, which I'm more familiar with. To provide rpm package, we need to maintain rpm spec file (which fully describes build process of a package) and right now, we maintain such spec file in the repository of the component directly. Which is definitely a possible approach and makes sense. Besides that, I noticed that we sometimes needs to maintain spec files for dependencies which we use, but target distribution doesn't provide. See for example this spec files in tendrl-commons repo: https://github.com/Tendrl/commons/tree/develop/dependencies With this in mind, I think that we may consider a different approach: to maintain all rpm spec files in dedicated repository, which would contain directory for each package. This would be kind of in the middle between current approach when all spec files are in project repositories directly and fedora dist-git approach which uses separate git repository for each rpm specfile. I'm not proposing fedora dist-git approach since we are using copr for our usptream builds and copr doesn't provide dist-git interface right now - one needs to push srpm (source rpm) into it to start a build. And without support in copr, it would create unreasonable additional maintenance cost (note: just to be clear, I know that copr uses dist-git internally, but right now it doesn't use it as an interface in a way fedpkg/koji does). Good aspects of this approach: * all spec files would be on a single place * we wouldn't have to remember where a spec file for given dependency is stored (especially when it's necessary for multiple tendrl components) * rpm packaging issues would be easier to deal with (as those would be reported in a single repo and would not mix with other issues) Does this makes sense? -- Martin Bukatovic USM QE team From japplewh at redhat.com Thu Feb 23 22:06:05 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Thu, 23 Feb 2017 17:06:05 -0500 Subject: [Tendrl-devel] update error Message-ID: Hi All I have been testing and now on my storage nodes when I try to update I get: [root at gluster-02 tendrl]# yum update -y Loaded plugins: fastestmirror centos-gluster39 | 2.9 kB 00:00:00 Loading mirror speeds from cached hostfile * base: mirror.redsox.cc * epel: fedora-epel.mirrors.tds.net * extras: mirror.cogentco.com * updates: mirrors.centos.webair.com Resolving Dependencies --> Running transaction check ---> Package tendrl-gluster-integration.noarch 0:1.2-02_23_2017_13_46_10 will be updated ---> Package tendrl-gluster-integration.noarch 0:1.2-02_23_2017_20_10_12 will be an update --> Processing Dependency: gstatus for package: tendrl-gluster-integration-1.2-02_23_2017_20_10_12.noarch ---> Package tendrl-node-agent.noarch 0:1.2-02_23_2017_15_56_11 will be updated ---> Package tendrl-node-agent.noarch 0:1.2-02_24_2017_00_01_02 will be an update --> Finished Dependency Resolution Error: Package: tendrl-gluster-integration-1.2-02_23_2017_20_10_12.noarch (tendrl-tendrl) Requires: gstatus You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest ?How to resolve?? -- Jeff Applewhite Principal Product Manager From sankarshan at redhat.com Fri Feb 24 00:31:47 2017 From: sankarshan at redhat.com (sankarshan) Date: Fri, 24 Feb 2017 06:01:47 +0530 Subject: [Tendrl-devel] update error In-Reply-To: References: Message-ID: On 24 February 2017 at 03:36, Jeff Applewhite wrote: > Hi All > > I have been testing and now on my storage nodes when I try to update I get: > > [root at gluster-02 tendrl]# yum update -y > Loaded plugins: fastestmirror > centos-gluster39 > | > 2.9 kB 00:00:00 > Loading mirror speeds from cached hostfile > * base: mirror.redsox.cc > * epel: fedora-epel.mirrors.tds.net > * extras: mirror.cogentco.com > * updates: mirrors.centos.webair.com > Resolving Dependencies > --> Running transaction check > ---> Package tendrl-gluster-integration.noarch 0:1.2-02_23_2017_13_46_10 > will be updated > ---> Package tendrl-gluster-integration.noarch 0:1.2-02_23_2017_20_10_12 > will be an update > --> Processing Dependency: gstatus for package: > tendrl-gluster-integration-1.2-02_23_2017_20_10_12.noarch > ---> Package tendrl-node-agent.noarch 0:1.2-02_23_2017_15_56_11 will be > updated > ---> Package tendrl-node-agent.noarch 0:1.2-02_24_2017_00_01_02 will be an > update > --> Finished Dependency Resolution > Error: Package: tendrl-gluster-integration-1.2-02_23_2017_20_10_12.noarch > (tendrl-tendrl) > Requires: gstatus > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest > > > How to resolve? The gstatus package dependency package dependency was to be worked on today. For the moment, could you consider trying from the package itself? From sankarshan at redhat.com Fri Feb 24 00:35:25 2017 From: sankarshan at redhat.com (sankarshan) Date: Fri, 24 Feb 2017 06:05:25 +0530 Subject: [Tendrl-devel] update error In-Reply-To: References: Message-ID: Now being tracked via On 24 February 2017 at 06:01, sankarshan wrote: > On 24 February 2017 at 03:36, Jeff Applewhite wrote: >> Hi All >> >> I have been testing and now on my storage nodes when I try to update I get: >> >> [root at gluster-02 tendrl]# yum update -y >> Loaded plugins: fastestmirror >> centos-gluster39 >> | >> 2.9 kB 00:00:00 >> Loading mirror speeds from cached hostfile >> * base: mirror.redsox.cc >> * epel: fedora-epel.mirrors.tds.net >> * extras: mirror.cogentco.com >> * updates: mirrors.centos.webair.com >> Resolving Dependencies >> --> Running transaction check >> ---> Package tendrl-gluster-integration.noarch 0:1.2-02_23_2017_13_46_10 >> will be updated >> ---> Package tendrl-gluster-integration.noarch 0:1.2-02_23_2017_20_10_12 >> will be an update >> --> Processing Dependency: gstatus for package: >> tendrl-gluster-integration-1.2-02_23_2017_20_10_12.noarch >> ---> Package tendrl-node-agent.noarch 0:1.2-02_23_2017_15_56_11 will be >> updated >> ---> Package tendrl-node-agent.noarch 0:1.2-02_24_2017_00_01_02 will be an >> update >> --> Finished Dependency Resolution >> Error: Package: tendrl-gluster-integration-1.2-02_23_2017_20_10_12.noarch >> (tendrl-tendrl) >> Requires: gstatus >> You could try using --skip-broken to work around the problem >> You could try running: rpm -Va --nofiles --nodigest >> >> >> How to resolve? > > The gstatus package dependency package dependency was to be worked on > today. For the moment, could you consider trying from > > the package itself? From japplewh at redhat.com Fri Feb 24 12:51:21 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Fri, 24 Feb 2017 12:51:21 +0000 Subject: [Tendrl-devel] update error In-Reply-To: References: Message-ID: Ah ok thanks! On Thu, Feb 23, 2017 at 7:36 PM sankarshan wrote: > Now being tracked via < > https://github.com/Tendrl/gluster-integration/issues/151> > > > > On 24 February 2017 at 06:01, sankarshan wrote: > > > On 24 February 2017 at 03:36, Jeff Applewhite > wrote: > > >> Hi All > > >> > > >> I have been testing and now on my storage nodes when I try to update I > get: > > >> > > >> [root at gluster-02 tendrl]# yum update -y > > >> Loaded plugins: fastestmirror > > >> centos-gluster39 > > >> > | > > >> 2.9 kB 00:00:00 > > >> Loading mirror speeds from cached hostfile > > >> * base: mirror.redsox.cc > > >> * epel: fedora-epel.mirrors.tds.net > > >> * extras: mirror.cogentco.com > > >> * updates: mirrors.centos.webair.com > > >> Resolving Dependencies > > >> --> Running transaction check > > >> ---> Package tendrl-gluster-integration.noarch 0:1.2-02_23_2017_13_46_10 > > >> will be updated > > >> ---> Package tendrl-gluster-integration.noarch 0:1.2-02_23_2017_20_10_12 > > >> will be an update > > >> --> Processing Dependency: gstatus for package: > > >> tendrl-gluster-integration-1.2-02_23_2017_20_10_12.noarch > > >> ---> Package tendrl-node-agent.noarch 0:1.2-02_23_2017_15_56_11 will be > > >> updated > > >> ---> Package tendrl-node-agent.noarch 0:1.2-02_24_2017_00_01_02 will be > an > > >> update > > >> --> Finished Dependency Resolution > > >> Error: Package: > tendrl-gluster-integration-1.2-02_23_2017_20_10_12.noarch > > >> (tendrl-tendrl) > > >> Requires: gstatus > > >> You could try using --skip-broken to work around the problem > > >> You could try running: rpm -Va --nofiles --nodigest > > >> > > >> > > >> How to resolve? > > > > > > The gstatus package dependency package dependency was to be worked on > > > today. For the moment, could you consider trying from > > > < > https://github.com/gluster/gstatus/blob/master/rpms/gstatus-0.64-3.el7.x86_64.rpm > > > > > the package itself? > > > > _______________________________________________ > > Tendrl-devel mailing list > > Tendrl-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/tendrl-devel > > From kdreyer at redhat.com Mon Feb 27 19:39:50 2017 From: kdreyer at redhat.com (Ken Dreyer) Date: Mon, 27 Feb 2017 12:39:50 -0700 Subject: [Tendrl-devel] distribution packaging In-Reply-To: References: Message-ID: Hi Martin, In the past, I've seen issues where commits to upstream projects will end up breaking the package builds in subtle ways, and it's nice to keep the RPM .spec file in the same Git repository to catch these. For example, if the developers add a large feature that adds new files during "make install" (or equivalent), then the developer has to make two PRs to two separate Git repositories: one to add the feature, one to update the RPM packaging for the feature. The first one has to be merged prior to the second one. And operations like reverts or cherry-picks become more complicated. There are already some delays now with the way that Jenkins is not really doing full RPM builds for every GitHub pull request, but eventually I think that's where we want to go - having Jenkins do full RPM builds to test that each PR does not break the packaging. Just my 2 cents :) - Ken On Thu, Feb 23, 2017 at 11:24 AM, Martin Bukatovic wrote: > Dear Tendrl community, > > I have another proposal related to packaging. And this time it's > distribution packaging, by which I mean building and maintenance > of rpm or deb packages. I'm not sure how much my idea make sense > for us, but it's at lest worth discussion/consideration. > > This is important because such packages are main deliverable > from the end user point of view. > > In the rest of this email, let's focus on rpm packages, which > I'm more familiar with. > > To provide rpm package, we need to maintain rpm spec file > (which fully describes build process of a package) and right > now, we maintain such spec file in the repository > of the component directly. Which is definitely a possible > approach and makes sense. Besides that, I noticed that we > sometimes needs to maintain spec files for dependencies > which we use, but target distribution doesn't provide. > See for example this spec files in tendrl-commons repo: > > https://github.com/Tendrl/commons/tree/develop/dependencies > > With this in mind, I think that we may consider a different > approach: to maintain all rpm spec files in dedicated repository, > which would contain directory for each package. This would be kind > of in the middle between current approach when all spec files are > in project repositories directly and fedora dist-git approach which > uses separate git repository for each rpm specfile. > > I'm not proposing fedora dist-git approach since we are using copr > for our usptream builds and copr doesn't provide dist-git interface > right now - one needs to push srpm (source rpm) into it to start > a build. And without support in copr, it would create unreasonable > additional maintenance cost (note: just to be clear, I know that > copr uses dist-git internally, but right now it doesn't use it as > an interface in a way fedpkg/koji does). > > Good aspects of this approach: > > * all spec files would be on a single place > * we wouldn't have to remember where a spec file for given > dependency is stored (especially when it's necessary for multiple > tendrl components) > * rpm packaging issues would be easier to deal with > (as those would be reported in a single repo and > would not mix with other issues) > > Does this makes sense? > > -- > Martin Bukatovic > USM QE team > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel From mbukatov at redhat.com Tue Feb 28 08:31:42 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Tue, 28 Feb 2017 09:31:42 +0100 Subject: [Tendrl-devel] distribution packaging In-Reply-To: References: Message-ID: On 02/27/2017 08:39 PM, Ken Dreyer wrote: > In the past, I've seen issues where commits to upstream projects will > end up breaking the package builds in subtle ways, and it's nice to > keep the RPM .spec file in the same Git repository to catch these. > > For example, if the developers add a large feature that adds new files > during "make install" (or equivalent), then the developer has to make > two PRs to two separate Git repositories: one to add the feature, one > to update the RPM packaging for the feature. The first one has to be > merged prior to the second one. And operations like reverts or > cherry-picks become more complicated. That's true. The separated project and spec file repository is more suited to building of stable releases only. > There are already some delays now with the way that Jenkins is not > really doing full RPM builds for every GitHub pull request, but > eventually I think that's where we want to go - having Jenkins do full > RPM builds to test that each PR does not break the packaging. This is a good point. Thanks for pointing this out. We would need to make sure that when a commit changes something related to packaging, rpm spec file is updated in the same commit as well. -- Martin Bukatovic USM QE team From mkudlej at redhat.com Tue Feb 28 10:06:40 2017 From: mkudlej at redhat.com (Martin Kudlej) Date: Tue, 28 Feb 2017 11:06:40 +0100 Subject: [Tendrl-devel] distribution packaging In-Reply-To: References: Message-ID: Hi, On 02/28/2017 09:31 AM, Martin Bukatovic wrote: >> There are already some delays now with the way that Jenkins is not >> really doing full RPM builds for every GitHub pull request, but >> eventually I think that's where we want to go - having Jenkins do full >> RPM builds to test that each PR does not break the packaging. > > This is a good point. Thanks for pointing this out. > > We would need to make sure that when a commit changes something > related to packaging, rpm spec file is updated in the same commit > as well. I believe this is tested by CI. -- Best Regards, Martin Kudlej. RHSC/USM Senior Quality Assurance Engineer Red Hat Czech s.r.o. Phone: +420 532 294 155 E-mail:mkudlej at redhat.com IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, #usm-meeting @ redhat #tendrl-devel @ freenode From nthomas at redhat.com Tue Feb 28 10:30:07 2017 From: nthomas at redhat.com (Nishanth Thomas) Date: Tue, 28 Feb 2017 16:00:07 +0530 Subject: [Tendrl-devel] Fwd: [sds-mgmt-dev] fedora copr infra issue In-Reply-To: <2069306269.26386699.1488274578712.JavaMail.zimbra@redhat.com> References: <216165949.26386443.1488274478955.JavaMail.zimbra@redhat.com> <2069306269.26386699.1488274578712.JavaMail.zimbra@redhat.com> Message-ID: FYI ---------- Forwarded message ---------- From: Timothy Asir Jeyasingh Date: Tue, Feb 28, 2017 at 3:06 PM Subject: [sds-mgmt-dev] fedora copr infra issue To: An internal only mailing list for development team on RHSC product < sds-mgmt-dev at redhat.com> Hi All, There is a infrastructure issue on fedora copr due to which our builds are pending for last few hours. This will affect the testing. I will keep you posted once the things are fixed. Regards, Tim