From nthomas at redhat.com Wed Mar 1 05:41:46 2017 From: nthomas at redhat.com (Nishanth Thomas) Date: Wed, 1 Mar 2017 11:11:46 +0530 Subject: [Tendrl-devel] Tendrl 1.2.1 packages available Message-ID: All, We are pleased to announce the availability Tendrl 1.2.1 packages. Repository : https://copr.fedorainfracloud.org/coprs/tendrl/tendrl/ Repo file can be downloaded from : https://copr.fedorainfracloud.org/coprs/tendrl/tendrl/repo/epel-7/tendrl-tendrl-epel-7.repo Package Version : 1.2.1-2.el7(centos) Contents: Import cluster flow: ceph and gluster - Auto detection of available clusters - import ceph and gluster from the detected cluster list Performance Monitoring - Automatic configuration of storage nodes(monitoring conf, collect config and startup) - Host specific stats are available(cpu, memory etc) - Host specific stats are populated as part of GetNodeList API Cluster status : ceph and gluster cluster(API only) Gluster volume status Cluster utilization : ceph and gluster Storage utilization: volumes and pools Inventory listing: - ceph and gluster cluster - volumes, pools and rbds - storage nodes - Ceph Pool creation - Replicated pools - EC Pools(API only) - Edit Ceph Pool(API only) Grow PGs(API only) Delete Pool(API only) Ceph RBD Creation Resize Rbds Delete Rbds(API only) Known Issues: *Any update/create operations are not auto updated on to the UI. Need to do a force refresh always(ctrl+R) *Out of band deletes from CLI are not reflected in central store *Cluster Status on the UI not updated *No of OSDs for the pool is not populated on the UI *EC pool creation available only via API in this build *Pool Edit(edit pool, grow pgs) available only via API in this b*uild *Pool, Rbd delete available only via API in this build Installation doc: https://github.com/Tendrl/documentation/wiki/Tendrl-Package-Installation-Reference Please let us know if you have any questions Thanks, Nishanth From japplewh at redhat.com Wed Mar 1 12:29:50 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Wed, 01 Mar 2017 12:29:50 +0000 Subject: [Tendrl-devel] Tendrl 1.2.1 packages available In-Reply-To: References: Message-ID: Excellent and thanks for the extra details the update. On Wed, Mar 1, 2017 at 12:41 AM Nishanth Thomas wrote: > All, > > > > We are pleased to announce the availability Tendrl 1.2.1 packages. > > > > Repository : https://copr.fedorainfracloud.org/coprs/tendrl/tendrl/ > > > > Repo file can be downloaded from : > > > > > https://copr.fedorainfracloud.org/coprs/tendrl/tendrl/repo/epel-7/tendrl-tendrl-epel-7.repo > > > > Package Version : 1.2.1-2.el7(centos) > > > > Contents: > > > > Import cluster flow: ceph and gluster > > > > - Auto detection of available clusters > > > > - import ceph and gluster from the detected cluster list > > > > Performance Monitoring > > > > - Automatic configuration of storage nodes(monitoring conf, collect config > > and startup) > > > > - Host specific stats are available(cpu, memory etc) > > > > - Host specific stats are populated as part of GetNodeList API > > > > Cluster status : ceph and gluster cluster(API only) > > > > Gluster volume status > > > > Cluster utilization : ceph and gluster > > > > Storage utilization: volumes and pools > > > > Inventory listing: > > > > - ceph and gluster cluster > > > > - volumes, pools and rbds > > > > - storage nodes > > > > - > > > > Ceph Pool creation > > > > - Replicated pools > > > > - EC Pools(API only) > > > > - Edit Ceph Pool(API only) > > > > Grow PGs(API only) > > > > Delete Pool(API only) > > > > Ceph RBD Creation > > > > Resize Rbds > > > > Delete Rbds(API only) > > > > Known Issues: > > > > *Any update/create operations are not auto updated on to the UI. Need to do > > a force refresh always(ctrl+R) > > > > *Out of band deletes from CLI are not reflected in central store > > > > *Cluster Status on the UI not updated > > > > *No of OSDs for the pool is not populated on the UI > > > > *EC pool creation available only via API in this build > > > > *Pool Edit(edit pool, grow pgs) available only via API in this b*uild > > > > *Pool, Rbd delete available only via API in this build > > > > Installation doc: > > > > > https://github.com/Tendrl/documentation/wiki/Tendrl-Package-Installation-Reference > > > > Please let us know if you have any questions > > > > Thanks, > > > > Nishanth > > _______________________________________________ > > Tendrl-devel mailing list > > Tendrl-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/tendrl-devel > > From sankarshan at redhat.com Fri Mar 3 06:16:09 2017 From: sankarshan at redhat.com (sankarshan) Date: Fri, 3 Mar 2017 11:46:09 +0530 Subject: [Tendrl-devel] seeking updates on the following stories/topics Message-ID: + + + Dashboard components around per-node data I don't have a story/epic at hand for the last one; I recall that we talked about this. /s From julim at redhat.com Fri Mar 3 19:17:43 2017 From: julim at redhat.com (Ju Lim) Date: Fri, 3 Mar 2017 14:17:43 -0500 Subject: [Tendrl-devel] seeking updates on the following stories/topics In-Reply-To: References: Message-ID: The epic for the TEN-204 and TEN-206 stories are already in JIRA. To clarify, here's more details to clarify the epic and underlying user stories: Epic: View Object Details (TEN-205) Underlying user stories: *Ceph-specific* TEN-210 Cluster object details for Ceph ^? TEN-184 UX: Cluster Object Details Dashboard for Ceph TEN-252 Pool object details TEN-251 Ceph OSD details views ["OSD" tab] *Gluster-specific* TEN-211 Cluster object details for Gluster trusted storage pool ^? TEN-185 UX: Cluster Object Details Dashboard for Gluster TEN-206 View File Share Object Details in UI ^? TEN-213 File share / volume object details [note: this is a duplicate of TEN-206] TEN-250 Gluster brick details views ["Bricks" tab] *Ceph, Gluster, and Neither (host not associated with a cluster)* TEN-212 Host object details TEN-204 UX: Host Object Details - Overview/Dashboard Specific to the story for the "+ Dashboard components around per-node data," if you're referring to the "dashboard" (or rather the "Overview") for the host, that would be TEN-204. TEN-212 is the overarching host object details which would need to cover all the tabs including the "Overview" tab. As the user stories don?t break down into the individual tabs/views for each of the object details types (cluster, host, pool, file share/volume), it may be a little easier to understand the scope by referring to the designs which may be found at https://github.com/Tendrl/ui/blob/master/UI%20Designs.adoc. As discussed, we'll be posting additional object detail designs by end of this week which should include all the dashboard / overview tabs for the various object types mentioned above. If you've further questions and/or concerns, please let me know. Thanks, Ju On Fri, Mar 3, 2017 at 1:16 AM, sankarshan wrote: > + > + > + Dashboard components around per-node data > > I don't have a story/epic at hand for the last one; I recall that we > talked about this. > > /s > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > From sankarshan.mukhopadhyay at gmail.com Sun Mar 5 05:29:45 2017 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Sun, 5 Mar 2017 10:59:45 +0530 Subject: [Tendrl-devel] seeking updates on the following stories/topics In-Reply-To: References: Message-ID: On Sat, Mar 4, 2017 at 12:47 AM, Ju Lim wrote: > As the user stories don?t break down into the individual tabs/views for > each of the object details types (cluster, host, pool, file share/volume), > it may be a little easier to understand the scope by referring to the > designs which may be found at > https://github.com/Tendrl/ui/blob/master/UI%20Designs.adoc. > This is a great landing page and aggregate - thank you! -- sankarshan mukhopadhyay From japplewh at redhat.com Tue Mar 7 11:04:05 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Tue, 7 Mar 2017 06:04:05 -0500 Subject: [Tendrl-devel] Tendrl sprint demo Message-ID: Hi All Due to scheduling around the hackathon this week in Brno the team will be doing a recording of the sprint demo and mailing out tomorrow. Thanks -- Jeff Applewhite From mbukatov at redhat.com Wed Mar 8 10:08:23 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Wed, 8 Mar 2017 11:08:23 +0100 Subject: [Tendrl-devel] tendrl stragegy for ceph cluster map hierarchy Message-ID: Dear Tendrl community, I recently reviewed chapter 5 "Data Distribution" from Sage's Ceph thesis[1], (since I try to improve my understanding of Ceph in general) and noticed the importance of "cluster map hierarchy" (aka CRUSH Map Bucket Hierarchy[2]). In short, it's a tree structure in which: * nodes are called "buckets" * leaf nodes represent OSDs * inner (non leaf) nodes has a "bucket type", which influences efficiency and performance of cluster operations on OSDs and data stored there Design of this structure is important for performance, planned usage patterns, cluster expansion and failure domains (which means that poorly designed hierarchy could result in data loss which could be prevented if proper design had been used instead). Eg. one could define bucket node for each rack, which would make possible to define crash rules to make sure that at least one replica is placed in different rack to prevent data loss when particular rack is down/lost. Without proper cluster hierarchy, it's not possible to achieve that. If you are not familiar with the concept and are working or interested in features dealing with cluster import or creation, I would suggest to definitely check either mentioned chapter from the thesis or ceph documentation. So the big question here is *how is Tendrl planning to work with this feature*? We definitely can't ignore this now. Tendrl needs to have a clear strategy here from the beginning as this is something which can't be added or changed later easily. Since this is core low level feature, there is no particular use case JIRA for it. That said handling of cluster hierarchy is imho core part of the following JIRAs: * TEN-2 Install Ceph 2.x Cluster * TEN-4 Import a Ceph 2.x Cluster * TEN-164 UX: Create Ceph Cluster Design * TEN-190 Create Ceph cluster via UI My opinion is that we need to be able at least: * import any valid/supported cluster cluster with it's hierarchy, without breaking ceph or tendrl * communicate clearly with tendrl admin user how the cluster hierarchy created during ceph cluster creation would look like * make it possible for admin to define cluster hierarchy manually if he decides that what tendrl provides doesn't fit his needs * design the tendrl architecture/code so that it's possible to add additional cluster map setup features, validation later without significant refactoring of tendrl code [1] http://ceph.com/papers/weil-thesis.pdf (link temp. broken at the moment) [2] http://docs.ceph.com/docs/master/rados/operations/crush-map/#crush-map-bucket-hierarchy [TEN-2] https://tendrl.atlassian.net/browse/TEN-2 -- Martin Bukatovic USM QE team From mbukatov at redhat.com Wed Mar 8 10:20:46 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Wed, 8 Mar 2017 11:20:46 +0100 Subject: [Tendrl-devel] Fwd: tendrl stragegy for ceph cluster map hierarchy In-Reply-To: References: Message-ID: <85cfd1d7-d808-69a4-4258-44acf8ae1be9@redhat.com> Dear Ceph community, I'm trying to understand how ceph cluster hierarchy feature relates and affects Tendrl project (http://tendrl.org/), which tries to provide web UI and API for ceph (and gluster) management. The problem is that my understanding is based solely on reading Sage's thesis, documentation and playing around with toy sized clusters. So I would definitely appreciated someone with better understanding of ceph to check my thinking here. I'm forwarding my tendrl post below. Btw: Tendrl project definitely welcomes you to show your opinions about tendrl plans/ides on tendrl-devel list :) -- Martin Bukatovic USM QE team -------- Forwarded Message -------- Subject: tendrl stragegy for ceph cluster map hierarchy Date: Wed, 8 Mar 2017 11:08:23 +0100 From: Martin Bukatovic Organization: Red Hat To: tendrl-devel at redhat.com Dear Tendrl community, I recently reviewed chapter 5 "Data Distribution" from Sage's Ceph thesis[1], (since I try to improve my understanding of Ceph in general) and noticed the importance of "cluster map hierarchy" (aka CRUSH Map Bucket Hierarchy[2]). In short, it's a tree structure in which: * nodes are called "buckets" * leaf nodes represent OSDs * inner (non leaf) nodes has a "bucket type", which influences efficiency and performance of cluster operations on OSDs and data stored there Design of this structure is important for performance, planned usage patterns, cluster expansion and failure domains (which means that poorly designed hierarchy could result in data loss which could be prevented if proper design had been used instead). Eg. one could define bucket node for each rack, which would make possible to define crash rules to make sure that at least one replica is placed in different rack to prevent data loss when particular rack is down/lost. Without proper cluster hierarchy, it's not possible to achieve that. If you are not familiar with the concept and are working or interested in features dealing with cluster import or creation, I would suggest to definitely check either mentioned chapter from the thesis or ceph documentation. So the big question here is *how is Tendrl planning to work with this feature*? We definitely can't ignore this now. Tendrl needs to have a clear strategy here from the beginning as this is something which can't be added or changed later easily. Since this is core low level feature, there is no particular use case JIRA for it. That said handling of cluster hierarchy is imho core part of the following JIRAs: * TEN-2 Install Ceph 2.x Cluster * TEN-4 Import a Ceph 2.x Cluster * TEN-164 UX: Create Ceph Cluster Design * TEN-190 Create Ceph cluster via UI My opinion is that we need to be able at least: * import any valid/supported cluster cluster with it's hierarchy, without breaking ceph or tendrl * communicate clearly with tendrl admin user how the cluster hierarchy created during ceph cluster creation would look like * make it possible for admin to define cluster hierarchy manually if he decides that what tendrl provides doesn't fit his needs * design the tendrl architecture/code so that it's possible to add additional cluster map setup features, validation later without significant refactoring of tendrl code [1] http://ceph.com/papers/weil-thesis.pdf (link temp. broken at the moment) [2] http://docs.ceph.com/docs/master/rados/operations/crush-map/#crush-map-bucket-hierarchy [TEN-2] https://tendrl.atlassian.net/browse/TEN-2 From japplewh at redhat.com Wed Mar 8 14:18:43 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Wed, 8 Mar 2017 09:18:43 -0500 Subject: [Tendrl-devel] Sprint planning Message-ID: Hi All We will be targeting to complete two major items in the next two weeks: - Gluster CRUD Epic - Main Dashboard For the details / user stories please see sprint 13 notes. -- Jeff Applewhite Principal Product Manager From sage at newdream.net Wed Mar 8 14:52:25 2017 From: sage at newdream.net (Sage Weil) Date: Wed, 8 Mar 2017 14:52:25 +0000 (UTC) Subject: [Tendrl-devel] Fwd: tendrl stragegy for ceph cluster map hierarchy In-Reply-To: <85cfd1d7-d808-69a4-4258-44acf8ae1be9@redhat.com> References: <85cfd1d7-d808-69a4-4258-44acf8ae1be9@redhat.com> Message-ID: Hi Martin, On Wed, 8 Mar 2017, Martin Bukatovic wrote: > Dear Ceph community, > > I'm trying to understand how ceph cluster hierarchy feature relates > and affects Tendrl project (http://tendrl.org/), which tries to > provide web UI and API for ceph (and gluster) management. > > The problem is that my understanding is based solely on reading > Sage's thesis, documentation and playing around with toy sized > clusters. So I would definitely appreciated someone with better > understanding of ceph to check my thinking here. I'm forwarding > my tendrl post below. > > Btw: Tendrl project definitely welcomes you to show your > opinions about tendrl plans/ides on tendrl-devel list :) Joined! > -------- Forwarded Message -------- > Subject: tendrl stragegy for ceph cluster map hierarchy > Date: Wed, 8 Mar 2017 11:08:23 +0100 > From: Martin Bukatovic > Organization: Red Hat > To: tendrl-devel at redhat.com > > Dear Tendrl community, > > I recently reviewed chapter 5 "Data Distribution" from Sage's Ceph > thesis[1], > (since I try to improve my understanding of Ceph in general) and noticed the > importance of "cluster map hierarchy" (aka CRUSH Map Bucket Hierarchy[2]). > > In short, it's a tree structure in which: > > * nodes are called "buckets" > * leaf nodes represent OSDs > * inner (non leaf) nodes has a "bucket type", which influences efficiency > and performance of cluster operations on OSDs and data stored there > > Design of this structure is important for performance, planned usage > patterns, cluster expansion and failure domains (which means that poorly > designed hierarchy could result in data loss which could be prevented if > proper design had been used instead). > > Eg. one could define bucket node for each rack, which would make > possible to define crash rules to make sure that at least one replica is > placed in different rack to prevent data loss when particular rack is > down/lost. Without proper cluster hierarchy, it's not possible to > achieve that. > > If you are not familiar with the concept and are working or interested > in features dealing with cluster import or creation, I would suggest to > definitely check either mentioned chapter from the thesis or ceph > documentation. > > So the big question here is *how is Tendrl planning to work with this > feature*? > > We definitely can't ignore this now. Tendrl needs to have a clear > strategy here from the beginning as this is something which can't be > added or changed later easily. > > Since this is core low level feature, there is no particular use case JIRA > for it. That said handling of cluster hierarchy is imho core part of the > following JIRAs: > > * TEN-2 Install Ceph 2.x Cluster > * TEN-4 Import a Ceph 2.x Cluster > * TEN-164 UX: Create Ceph Cluster Design > * TEN-190 Create Ceph cluster via UI > > My opinion is that we need to be able at least: > > * import any valid/supported cluster cluster with it's hierarchy, without > breaking ceph or tendrl > * communicate clearly with tendrl admin user how the cluster hierarchy created > during ceph cluster creation would look like > * make it possible for admin to define cluster hierarchy manually if he decides > that what tendrl provides doesn't fit his needs > * design the tendrl architecture/code so that it's possible to add additional > cluster map setup features, validation later without significant refactoring > of tendrl code The "master" copy of the cluster hierarchy (datacenters, rows, racks, hosts, devices) is the CRUSH map. Ceph makes this easily accessible in JSON form, and provides a series of commands that let you adjust the hierachy (moving nodes of the tree around), so I think this is primarily a UI issue. Usually the OSDs know enough to put the devices under the correct host, but usually hosts don't know where they exist within the larger cluster. (There are hooks to do this on the host, but it currently relies on something like ansible or chef or puppet to put this somewhere in /etc so that we can tell which rack etc the host lives in.) That means it's usually the admin who ensure the hosts are positioned properly in the overall hierarchy. So probably teh first thing would be to make the GUI let you create racks/rows/datacenters/whatever and drag parts of the tree around. As far as visualizing the cluster, the key thing I think we should address from the get-go is how to do it in a way that will scale gracefully to clusters with 100s, 1000s, and 10000s of OSDs. The most promising thing I've seen (and admittedly I haven't seen much) was from a paper someone (Loic?) sent around a few weeks ago: http://www.aviz.fr/wiki/uploads/Teaching2014/bundles_infovis.pdf See, for example Fig 1 and Fig 13a. The circle grouping can scale down as the cluster scales up (or you zoom in/out). (And the actual subject of the paper--data flows--can be applied to show things like data movement during rebalancing/recovery or proposed CRUSH changes.) sage From khartsoe at redhat.com Thu Mar 9 15:56:40 2017 From: khartsoe at redhat.com (Kenneth Hartsoe) Date: Thu, 9 Mar 2017 10:56:40 -0500 (EST) Subject: [Tendrl-devel] RHS-C 3.0: Eng Timeline In-Reply-To: <2112675940.54587.1489074871702.JavaMail.zimbra@redhat.com> Message-ID: <1705294593.55035.1489075000935.JavaMail.zimbra@redhat.com> Hi Sankarshan, I wanted to check in to see if Eng has scoped the order/workflow of the remaining features to be delivered for 3.0; this is not in regard to your forthcoming beta assessment, but in regard to the overall 3.0 delivery. Knowing the priority of Eng's work will help docs plan our accompanying doc effort. Thanks Sankarshan. Ken Hartsoe Content Strategist Red Hat Storage Documentation khartsoe at redhat.com; IRC: khartsoe Office: 919 754 4770; Internal: 814 4770 From mbukatov at redhat.com Mon Mar 13 10:04:24 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Mon, 13 Mar 2017 11:04:24 +0100 Subject: [Tendrl-devel] Fwd: tendrl stragegy for ceph cluster map hierarchy In-Reply-To: References: <85cfd1d7-d808-69a4-4258-44acf8ae1be9@redhat.com> Message-ID: <89f191fb-1561-058d-1ba4-458ccef0f45b@redhat.com> On 03/08/2017 03:52 PM, Sage Weil wrote: > Usually the OSDs know enough to put the devices under the correct host, > but usually hosts don't know where they exist within the larger cluster. > (There are hooks to do this on the host, but it currently relies on > something like ansible or chef or puppet to put this somewhere in /etc so > that we can tell which rack etc the host lives in.) That means it's > usually the admin who ensure the hosts are positioned properly in the > overall hierarchy. So probably teh first thing would be to make the GUI > let you create racks/rows/datacenters/whatever and drag parts of the tree > around. That's a good point. Right now Tendrl is in a early stage of development and don't have this yet. That said, we need to consider this feature from the beginning. I expect that ceph-ansible and ceph-installer provides a way to achieve this (for the node to know where in hierarchy it is for ceph to place it into correct place in the crush cluster hierarchy). To Tendrl team: do we have a plan for such feature? > As far as visualizing the cluster, the key thing I think we should address > from the get-go is how to do it in a way that will scale gracefully to > clusters with 100s, 1000s, and 10000s of OSDs. The most promising > thing I've seen (and admittedly I haven't seen much) was from a > paper someone (Loic?) sent around a few weeks ago: > > http://www.aviz.fr/wiki/uploads/Teaching2014/bundles_infovis.pdf > > See, for example Fig 1 and Fig 13a. The circle grouping can scale down as > the cluster scales up (or you zoom in/out). (And the actual subject > of the paper--data flows--can be applied to show things like data movement > during rebalancing/recovery or proposed CRUSH changes.) Thanks for the link the the paper. What is the opinion of the Tendrl design and gui people about this idea? We don't need to have a proper visualization of the cluster in 1st version, but when we start working on it, having scaling to 10000s OSDs in mind is a very good approach. -- Martin Bukatovic USM QE team From mkudlej at redhat.com Mon Mar 13 11:02:17 2017 From: mkudlej at redhat.com (Martin Kudlej) Date: Mon, 13 Mar 2017 12:02:17 +0100 Subject: [Tendrl-devel] Dev - QE meeting during Tendrl - OSP Hackathon Message-ID: <0a0943c1-189c-a41f-898b-a8bed31fa6a3@redhat.com> Hello, Dev and QE have met in Brno during Tendrl - OSP Hackathon and discussed some hot topics. Here are my notes. They can be mixed with my personal notes and are interpreted by me. If you think that I've missed something please reply or correct me. 1. Unit tests are critical part of testing because it can decrease testing blockers. Also if there is working unit testing, QE can drop support of deployment based on source. Preferred and only right way how to deploy Tendrl is based on packages. Agreement: Unit tests for Tendrl should be fixed in first phase. In second phase coverage will be increased to about 90% like it was planned at beginning of project. QE will try to help to fix unit testing if it is possible and QE has human resources for it. My personal note: I think goal is to fix unit testing before Beta to decrease number of testing blockers. 2. QE will use packages based on master. There are only completed features in master branch. There can be partially finished features in devel branch and related packages. My personal note: It is not clear when features and fixes will be merged to master. Is there any plan to do this? 3. QE thinks that API is fragile. For example there are not useful error messages. For example if there is wrong configuration of performance monitoring, it is not obvious from API response that where is the problem and how to fix it. Devs are working on better error messages according which user can find in docs what is cause of problem and how to fix it. 4. It will be helpful if Devs can easily deploy Tendrl cluster based on QE deployment scripts. It can help for example for reproducing bug, for deployment for demo and so on. Agreement: Devs will provide HW or resources in internal OSP instance and QE will deploy Jenkins slave there. 5. QE would like to know how to find all Github issues/specifications/pull requests for Jira story/epic. Devs have declared that they don't use Jira and don't follow Sprints anymore. There is spreadsheet for work planning which is not publicly available. My personal note: I expect further discussion including PMs about this topic. Also I expect that it will be found workflow and tooling where anybody involved in project can easily find project status and tasks which should be done to finish planned features. 6. QE question: What is status of installation Ceph and Gluster by Tendrl? Dev answer: Ceph installation is on way to master branch. Gluster installation is not ready. 7. There is request from Devs for testing content of Etcd database. Agreement: If there is Json template in specification(or in related task/issue) QE will test Etcd content according this template. This will be done for Ceph installation for first time. 8. There will not be any backports from Tendrl Ceph integration to Calamari. 9. There will be bug triage meetings since last week of March. 10. There is also plan to have SOS-report plugin in upstream for Tendrl to easily gather all required info in case of bug. -- 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 mbukatov at redhat.com Mon Mar 13 12:53:14 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Mon, 13 Mar 2017 13:53:14 +0100 Subject: [Tendrl-devel] Dev - QE meeting during Tendrl - OSP Hackathon In-Reply-To: <0a0943c1-189c-a41f-898b-a8bed31fa6a3@redhat.com> References: <0a0943c1-189c-a41f-898b-a8bed31fa6a3@redhat.com> Message-ID: On 03/13/2017 12:02 PM, Martin Kudlej wrote: > 2. QE will use packages based on master. There are only completed > features in master branch. There can be partially finished features in > devel branch and related packages. > > My personal note: It is not clear when features and fixes will be merged > to master. Is there any plan to do this? The dev team mentioned the plan to move towards git flow model as described here: http://nvie.com/posts/a-successful-git-branching-model/ To put this into context, see this tutorial which compares the model with other common git workflows (you may be familiar with) in a nice way: https://www.atlassian.com/git/tutorials/comparing-workflows That said, the git flow model has few downsides which needs to be considered (as any other workflow) as mentioned here: https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/ But as long as we understand the trade off and are able to follow and enforce the rules properly, it should work. This is on the development team to consider and decide. From my QE perspective, I would like to avoid situation when the rules are not followed completely, which would result with additional work without the planned benefits. So based on this, the answer to the questions above would be (correct me if I read it wrong): The plan is that every commit in master is a release, properly tagged so completed feature is merged into master when the release is done (so it's already stabilized and tested). Which means that feature and fixes will be merged into master when the release is done. As you probably noticed, this conflicts with the statement above that qe team uses packages from master branch only, because at the point something hits master, it's already released by definition so it would be too late for qe team to consume builds from master. This conflict is here because right now, we are not fully following the flow model: some tendrl repositories on github already have both develop branch (where most development happens) and master branch, which is more stable compared to develop. So when one considers a pull request, it should be done based on develop branch and not master. That said, the full git flow modes as described in link above is not followed yet and for the team to get there, cleanup is needed first. Again, feel free to correct me if I get something wrong. -- Martin Bukatovic USM QE team From khartsoe at redhat.com Mon Mar 13 14:32:41 2017 From: khartsoe at redhat.com (Kenneth Hartsoe) Date: Mon, 13 Mar 2017 10:32:41 -0400 (EDT) Subject: [Tendrl-devel] Dev - QE meeting during Tendrl - OSP Hackathon In-Reply-To: <0a0943c1-189c-a41f-898b-a8bed31fa6a3@redhat.com> References: <0a0943c1-189c-a41f-898b-a8bed31fa6a3@redhat.com> Message-ID: <899006117.1514763.1489415561682.JavaMail.zimbra@redhat.com> Hi Martin, Regarding #3, please let me know if you need any doc input related to 3.0 content: i.e., location, etc., of potential doc solutions in 3.0 content. Thanks. Ken Hartsoe Content Strategist Red Hat Storage Documentation khartsoe at redhat.com; IRC: khartsoe Office: 919 754 4770; Internal: 814 4770 ----- Original Message ----- | Hello, | | Dev and QE have met in Brno during Tendrl - OSP Hackathon and discussed some | hot topics. Here are my | notes. They can be mixed with my personal notes and are interpreted by me. If | you think that I've | missed something please reply or correct me. | | 1. Unit tests are critical part of testing because it can decrease testing | blockers. Also if there | is working unit testing, QE can drop support of deployment based on source. | Preferred and only right | way how to deploy Tendrl is based on packages. | | Agreement: Unit tests for Tendrl should be fixed in first phase. In second | phase coverage will be | increased to about 90% like it was planned at beginning of project. | | QE will try to help to fix unit testing if it is possible and QE has human | resources for it. | | My personal note: I think goal is to fix unit testing before Beta to decrease | number of testing | blockers. | | 2. QE will use packages based on master. There are only completed features in | master branch. There | can be partially finished features in devel branch and related packages. | | My personal note: It is not clear when features and fixes will be merged to | master. Is there any | plan to do this? | | 3. QE thinks that API is fragile. For example there are not useful error | messages. For example if | there is wrong configuration of performance monitoring, it is not obvious | from API response that | where is the problem and how to fix it. Devs are working on better error | messages according which | user can find in docs what is cause of problem and how to fix it. | | 4. It will be helpful if Devs can easily deploy Tendrl cluster based on QE | deployment scripts. It | can help for example for reproducing bug, for deployment for demo and so on. | | Agreement: Devs will provide HW or resources in internal OSP instance and QE | will deploy Jenkins | slave there. | | 5. QE would like to know how to find all Github issues/specifications/pull | requests for Jira | story/epic. Devs have declared that they don't use Jira and don't follow | Sprints anymore. There is | spreadsheet for work planning which is not publicly available. | | My personal note: I expect further discussion including PMs about this topic. | Also I expect that it | will be found workflow and tooling where anybody involved in project can | easily find project status | and tasks which should be done to finish planned features. | | 6. QE question: What is status of installation Ceph and Gluster by Tendrl? | Dev answer: Ceph installation is on way to master branch. Gluster | installation is not ready. | | 7. There is request from Devs for testing content of Etcd database. | | Agreement: If there is Json template in specification(or in related | task/issue) QE will test Etcd | content according this template. This will be done for Ceph installation for | first time. | | 8. There will not be any backports from Tendrl Ceph integration to Calamari. | | 9. There will be bug triage meetings since last week of March. | | 10. There is also plan to have SOS-report plugin in upstream for Tendrl to | easily gather all | required info in case of bug. | | -- | 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 mbukatov at redhat.com Mon Mar 13 16:15:59 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Mon, 13 Mar 2017 17:15:59 +0100 Subject: [Tendrl-devel] el6 support Message-ID: <7336dec4-1fb1-9145-3edb-63f6d66920b8@redhat.com> Dear Tendrl list, I noticed that we are going to package some components for el6 distributions (CentOS 6 and RHEL 6): https://github.com/Tendrl/gluster-integration/pull/166 Do we have a full list of such components somewhere? I'm asking because for those components, it would be good to enable unit tests run on python 2.6 as well (since this particular version is shipped with el6). Right now, the only component with Travis CI configured to run on python 2.6 is tendrl-commons (as no matter which other tendrl component(s) will need to run on el6 as well, tendrl-commons will be always needed), but the test run fails on this issue: https://github.com/Tendrl/commons/issues/179 I would suggest to fix this and enable el6 test run on all components targeted for el6 before providing el6 packages for qe consumption, because we are likely to find many minor issues much faster this way. -- Martin Bukatovic USM QE team From mbukatov at redhat.com Mon Mar 13 16:51:13 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Mon, 13 Mar 2017 17:51:13 +0100 Subject: [Tendrl-devel] pep8 fixes for tendrl-commons Message-ID: Hi Rohan, when you have some time, ping me when I can go on and prepare a pull request which would be mergeable into develop branch: https://github.com/Tendrl/commons/pull/200 So that you can merge it in just after that. Without this sync, we wouldn't be able to merge it (considering the fast pace of changes last week and few pull requests waiting for a review). Sooner we do that, the easier it would be. -- Martin Bukatovic USM QE team From mbukatov at redhat.com Mon Mar 13 17:04:06 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Mon, 13 Mar 2017 18:04:06 +0100 Subject: [Tendrl-devel] can't access ww.tendrl.org site Message-ID: <99a895cf-281e-d38b-355e-6dd0b7a9bfb2@redhat.com> Dear Tendrl list, I noticed that we link to tendrl.org site in 2 ways: * as http://tendrl.org/ from https://github.com/Tendrl * as http://www.tendrl.org/ from eg. https://github.com/Tendrl/commons And the problem here is that http://www.tendrl.org/ url fails to load. Could we fix the configuration of tendrl.org site so that people are able to access it via www.tendrl.org as well? -- Martin Bukatovic USM QE team From japplewh at redhat.com Mon Mar 13 18:15:32 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Mon, 13 Mar 2017 14:15:32 -0400 Subject: [Tendrl-devel] can't access ww.tendrl.org site In-Reply-To: <99a895cf-281e-d38b-355e-6dd0b7a9bfb2@redhat.com> References: <99a895cf-281e-d38b-355e-6dd0b7a9bfb2@redhat.com> Message-ID: Hi Martin For now I edited the tendrl/commons link to point to tendrl.org. We should fix the www issue though as that is obviously the standard. If someone gets to the bottom of this I will update the links to point to www.tendrl.org Thanks Jeff On Mon, Mar 13, 2017 at 1:04 PM, Martin Bukatovic wrote: > Dear Tendrl list, > > I noticed that we link to tendrl.org site in 2 ways: > > * as http://tendrl.org/ from https://github.com/Tendrl > * as http://www.tendrl.org/ from eg. https://github.com/Tendrl/commons > > And the problem here is that http://www.tendrl.org/ url > fails to load. > > Could we fix the configuration of tendrl.org site so that > people are able to access it via www.tendrl.org as well? > > -- > Martin Bukatovic > USM QE team > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > -- Jeff Applewhite Principal Product Manager From kdreyer at redhat.com Mon Mar 13 22:29:46 2017 From: kdreyer at redhat.com (Ken Dreyer) Date: Mon, 13 Mar 2017 16:29:46 -0600 Subject: [Tendrl-devel] can't access ww.tendrl.org site In-Reply-To: References: <99a895cf-281e-d38b-355e-6dd0b7a9bfb2@redhat.com> Message-ID: I've emailed Patrick a patch to our RH DNS config to make this work. You can test it out in the mean time: $ sudo echo 192.30.252.153 www.tendrl.org >> /etc/hosts $ curl -I www.tendrl.orgHTTP/1.1 301 Moved Permanently Server: GitHub.com Date: Mon, 13 Mar 2017 22:29:27 GMT Content-Type: text/html Content-Length: 178 Location: http://tendrl.org/ On Mon, Mar 13, 2017 at 12:15 PM, Jeff Applewhite wrote: > Hi Martin > > For now I edited the tendrl/commons link to point to tendrl.org. > We should fix the www issue though as that is obviously the standard. > If someone gets to the bottom of this I will update the links to point to > www.tendrl.org > > Thanks > > Jeff > > On Mon, Mar 13, 2017 at 1:04 PM, Martin Bukatovic > wrote: > >> Dear Tendrl list, >> >> I noticed that we link to tendrl.org site in 2 ways: >> >> * as http://tendrl.org/ from https://github.com/Tendrl >> * as http://www.tendrl.org/ from eg. https://github.com/Tendrl/commons >> >> And the problem here is that http://www.tendrl.org/ url >> fails to load. >> >> Could we fix the configuration of tendrl.org site so that >> people are able to access it via www.tendrl.org as well? >> >> -- >> Martin Bukatovic >> USM QE team >> >> _______________________________________________ >> Tendrl-devel mailing list >> Tendrl-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/tendrl-devel >> > > > > -- > Jeff Applewhite > Principal Product Manager > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel From sankarshan.mukhopadhyay at gmail.com Tue Mar 14 06:03:49 2017 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Tue, 14 Mar 2017 11:33:49 +0530 Subject: [Tendrl-devel] el6 support In-Reply-To: <7336dec4-1fb1-9145-3edb-63f6d66920b8@redhat.com> References: <7336dec4-1fb1-9145-3edb-63f6d66920b8@redhat.com> Message-ID: On Mon, Mar 13, 2017 at 9:45 PM, Martin Bukatovic wrote: > Dear Tendrl list, > > I noticed that we are going to package some components for > el6 distributions (CentOS 6 and RHEL 6): > > https://github.com/Tendrl/gluster-integration/pull/166 > > Do we have a full list of such components somewhere? > I'm asking because for those components, it would be > good to enable unit tests run on python 2.6 as well > (since this particular version is shipped with el6). > Timothy has been putting together a manifest of work to be undertaken for CentOS6/el6. It is likely that he has this list you seek. > Right now, the only component with Travis CI configured > to run on python 2.6 is tendrl-commons (as no matter > which other tendrl component(s) will need to run on el6 > as well, tendrl-commons will be always needed), but the > test run fails on this issue: > > https://github.com/Tendrl/commons/issues/179 > > I would suggest to fix this and enable el6 test run on > all components targeted for el6 before providing > el6 packages for qe consumption, because we are likely > to find many minor issues much faster this way. > > -- > Martin Bukatovic > USM QE team > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel -- sankarshan mukhopadhyay From tjeyasin at redhat.com Tue Mar 14 06:27:17 2017 From: tjeyasin at redhat.com (Timothy Asir Jeyasingh) Date: Tue, 14 Mar 2017 02:27:17 -0400 (EDT) Subject: [Tendrl-devel] el6 support In-Reply-To: References: <7336dec4-1fb1-9145-3edb-63f6d66920b8@redhat.com> Message-ID: <1718172454.3704641.1489472837127.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Sankarshan Mukhopadhyay" > To: "Mailing list for the contributors to the Tendrl project" > Sent: Tuesday, March 14, 2017 11:33:49 AM > Subject: Re: [Tendrl-devel] el6 support > > On Mon, Mar 13, 2017 at 9:45 PM, Martin Bukatovic > wrote: > > Dear Tendrl list, > > > > I noticed that we are going to package some components for > > el6 distributions (CentOS 6 and RHEL 6): > > > > https://github.com/Tendrl/gluster-integration/pull/166 > > > > Do we have a full list of such components somewhere? > > I'm asking because for those components, it would be > > good to enable unit tests run on python 2.6 as well > > (since this particular version is shipped with el6). > > > > Timothy has been putting together a manifest of work to be undertaken > for CentOS6/el6. It is likely that he has this list you seek. > Yes, I am working on the list of required components for el6 distributions for tendrl. url: https://projects.engineering.redhat.com/browse/RCM-13529 provides the list of required packages for rhel6. I have already sent PRs for gluster-integration, commons and its dependencies. Now i am working on remaining components like ceph-integration, performance-monitoring, node-monitoring and tendrl-api and its rubygem package dependencies. I will soon create and share a google-doc or google-sheet to list down the packages and its PRs. Thanks and Regards, Timothy > > Right now, the only component with Travis CI configured > > to run on python 2.6 is tendrl-commons (as no matter > > which other tendrl component(s) will need to run on el6 > > as well, tendrl-commons will be always needed), but the > > test run fails on this issue: > > > > https://github.com/Tendrl/commons/issues/179 > > > > I would suggest to fix this and enable el6 test run on > > all components targeted for el6 before providing > > el6 packages for qe consumption, because we are likely > > to find many minor issues much faster this way. > > > > -- > > Martin Bukatovic > > USM QE team > > > > _______________________________________________ > > Tendrl-devel mailing list > > Tendrl-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/tendrl-devel > > > > -- > sankarshan mukhopadhyay > > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > From mbukatov at redhat.com Tue Mar 14 09:17:35 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Tue, 14 Mar 2017 10:17:35 +0100 Subject: [Tendrl-devel] el6 support In-Reply-To: <1718172454.3704641.1489472837127.JavaMail.zimbra@redhat.com> References: <7336dec4-1fb1-9145-3edb-63f6d66920b8@redhat.com> <1718172454.3704641.1489472837127.JavaMail.zimbra@redhat.com> Message-ID: On 03/14/2017 07:27 AM, Timothy Asir Jeyasingh wrote: >> Timothy has been putting together a manifest of work to be undertaken >> for CentOS6/el6. It is likely that he has this list you seek. > > Yes, I am working on the list of required components for el6 > distributions for tendrl. > url: https://projects.engineering.redhat.com/browse/RCM-13529 Just a note here: this is red hat internal url, we should not link such in upstream mailing list because it doesn't make much sense. > provides the list of required packages for rhel6. > I have already sent PRs for gluster-integration, commons and its > dependencies. Now i am working on remaining components like > ceph-integration, performance-monitoring, node-monitoring and > tendrl-api and its rubygem package dependencies. I will soon > create and share a google-doc or google-sheet to list down > the packages and its PRs. Anyway, thanks for the update and the list. Based on what you say here and the list, I see that we plan to package all the components for el6: tendrl-ceph-integration tendrl-gluster-integration tendrl-node-agent tendrl-commons tendrl-api tendrl-dashboard tendrl-performance-monitoring tendrl-node-monitoring So I read this more like that we plan to support el6 in general rather than only for particular components (such as tendrl gluster integration) - which was my original impression. Thanks for the update. -- Martin Bukatovic USM QE team From rkanade at redhat.com Tue Mar 14 13:36:15 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Tue, 14 Mar 2017 19:06:15 +0530 Subject: [Tendrl-devel] Improved Github workflow/branching for Tendrl components Message-ID: Hi, Over the last release (1.2.1) we ran into issues related to async/parallel development and we broke a few things here and there while trying to sort out our branching model. Here is what we should be doing to enable better categorization of code coming in Tendrl Branch 1) Master == production ready code (This code should be tested via all functional/regression/integration tests) 2) Develop == feature ready code (This code should be regularly tested functionally) 3) Feature branches == span across components (eg node-agent, commons etc) and contain code for a that $Feature (these branches should be tested functionally and moved to develop once done) 4) Hotfixes == Any fixes required in the production code (master) branch should go to hotfix branches and should be merged back to master and develop The Tendrl backend repositories have been updated to reflect above branches. Id like to request the tendrl-api and the tendrl-dashboard to incorporate these too. More details on how this works out with examples : http://nvie.com/posts/a-successful-git-branching-model/ From khartsoe at redhat.com Tue Mar 14 18:42:22 2017 From: khartsoe at redhat.com (Kenneth Hartsoe) Date: Tue, 14 Mar 2017 14:42:22 -0400 (EDT) Subject: [Tendrl-devel] RHS-C 3.0: Eng Timeline In-Reply-To: <1705294593.55035.1489075000935.JavaMail.zimbra@redhat.com> References: <1705294593.55035.1489075000935.JavaMail.zimbra@redhat.com> Message-ID: <1860752711.2577462.1489516942094.JavaMail.zimbra@redhat.com> Following up w/ Eng as I believe Sankarshan is unavailable....what is Eng's time line regarding having import (gluster and ceph) ready? And create cluster? Or is the time line targeted for the April 11 Beta feature freeze? Thanks. Ken Hartsoe Content Strategist Red Hat Storage Documentation khartsoe at redhat.com; IRC: khartsoe Office: 919 754 4770; Internal: 814 4770 ----- Original Message ----- | Hi Sankarshan, | | I wanted to check in to see if Eng has scoped the order/workflow of the | remaining features to be delivered for 3.0; this is not in regard to your | forthcoming beta assessment, but in regard to the overall 3.0 delivery. | Knowing the priority of Eng's work will help docs plan our accompanying doc | effort. | | Thanks Sankarshan. | | Ken Hartsoe | Content Strategist | Red Hat Storage Documentation | | khartsoe at redhat.com; IRC: khartsoe | Office: 919 754 4770; Internal: 814 4770 | | _______________________________________________ | Tendrl-devel mailing list | Tendrl-devel at redhat.com | https://www.redhat.com/mailman/listinfo/tendrl-devel | From sankarshan at redhat.com Wed Mar 15 02:41:05 2017 From: sankarshan at redhat.com (sankarshan) Date: Wed, 15 Mar 2017 08:11:05 +0530 Subject: [Tendrl-devel] RHS-C 3.0: Eng Timeline In-Reply-To: <1860752711.2577462.1489516942094.JavaMail.zimbra@redhat.com> References: <1705294593.55035.1489075000935.JavaMail.zimbra@redhat.com> <1860752711.2577462.1489516942094.JavaMail.zimbra@redhat.com> Message-ID: On 15 March 2017 at 00:12, Kenneth Hartsoe wrote: > Following up w/ Eng as I believe Sankarshan is unavailable....what is Eng's time line regarding having import (gluster and ceph) ready? And create cluster? Or is the time line targeted for the April 11 Beta feature freeze? Thanks. > I apologize about the tardiness. I'll be working on putting together a timeline of when the capabilities will be available in the build so as to provide adequate heads-up for CCS and other teams. I expect to make this available latest by 20Mar. It is likely that import operations will be available first in sequence. > ----- Original Message ----- > | Hi Sankarshan, > | > | I wanted to check in to see if Eng has scoped the order/workflow of the > | remaining features to be delivered for 3.0; this is not in regard to your > | forthcoming beta assessment, but in regard to the overall 3.0 delivery. > | Knowing the priority of Eng's work will help docs plan our accompanying doc > | effort. > | > | Thanks Sankarshan. > | > | Ken Hartsoe > | Content Strategist > | Red Hat Storage Documentation > | > | khartsoe at redhat.com; IRC: khartsoe > | Office: 919 754 4770; Internal: 814 4770 > | > | _______________________________________________ > | Tendrl-devel mailing list > | Tendrl-devel at redhat.com > | https://www.redhat.com/mailman/listinfo/tendrl-devel > | From mbukatov at redhat.com Wed Mar 15 09:03:29 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Wed, 15 Mar 2017 10:03:29 +0100 Subject: [Tendrl-devel] el6 support In-Reply-To: References: <7336dec4-1fb1-9145-3edb-63f6d66920b8@redhat.com> <1718172454.3704641.1489472837127.JavaMail.zimbra@redhat.com> Message-ID: <9662de51-624c-c18c-e975-c47dd64585fa@redhat.com> On 03/14/2017 10:17 AM, Martin Bukatovic wrote: > Anyway, thanks for the update and the list. Based on what > you say here and the list, I see that we plan to package > all the components for el6: > > tendrl-ceph-integration > tendrl-gluster-integration > tendrl-node-agent > tendrl-commons > tendrl-api > tendrl-dashboard > tendrl-performance-monitoring > tendrl-node-monitoring > > So I read this more like that we plan to support el6 in general > rather than only for particular components (such as tendrl gluster > integration) - which was my original impression. Either way, it would be nice to know the original reasoning behind this as well, so that we can check if requirement to build everything for epel7 as well is sound. -- Martin Bukatovic USM QE team From sankarshan.mukhopadhyay at gmail.com Wed Mar 15 09:07:21 2017 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Wed, 15 Mar 2017 14:37:21 +0530 Subject: [Tendrl-devel] el6 support In-Reply-To: <9662de51-624c-c18c-e975-c47dd64585fa@redhat.com> References: <7336dec4-1fb1-9145-3edb-63f6d66920b8@redhat.com> <1718172454.3704641.1489472837127.JavaMail.zimbra@redhat.com> <9662de51-624c-c18c-e975-c47dd64585fa@redhat.com> Message-ID: On Wed, Mar 15, 2017 at 2:33 PM, Martin Bukatovic wrote: > On 03/14/2017 10:17 AM, Martin Bukatovic wrote: >> Anyway, thanks for the update and the list. Based on what >> you say here and the list, I see that we plan to package >> all the components for el6: >> >> tendrl-ceph-integration >> tendrl-gluster-integration >> tendrl-node-agent >> tendrl-commons >> tendrl-api >> tendrl-dashboard >> tendrl-performance-monitoring >> tendrl-node-monitoring >> >> So I read this more like that we plan to support el6 in general >> rather than only for particular components (such as tendrl gluster >> integration) - which was my original impression. > Well, no. I believe there's some wires crossed and your original understanding ought to be accurate. There is a sizeable challenge in building all the components for el6 - specifically limited to the availability of particular NVRs of dependencies. > Either way, it would be nice to know the original reasoning behind > this as well, so that we can check if requirement to build everything > for epel7 as well is sound. If we do not build the set of packages from the respositories with an el7 build-target, how would be have binaries available to enable the capabilities provided by the packages? -- sankarshan mukhopadhyay From mbukatov at redhat.com Wed Mar 15 09:07:56 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Wed, 15 Mar 2017 10:07:56 +0100 Subject: [Tendrl-devel] can't access ww.tendrl.org site In-Reply-To: References: <99a895cf-281e-d38b-355e-6dd0b7a9bfb2@redhat.com> Message-ID: <0f4b998e-e9ef-2bf6-b572-0aa4334b6685@redhat.com> On 03/13/2017 11:29 PM, Ken Dreyer wrote: > I've emailed Patrick a patch to our RH DNS config to make this work. Thanks for this. It's still not yet updated in the dns, but but I guess that we are close. > You can test it out in the mean time: > > $ sudo echo 192.30.252.153 www.tendrl.org >> /etc/hosts > > $ curl -I www.tendrl.orgHTTP/1.1 301 Moved Permanently > Server: GitHub.com > Date: Mon, 13 Mar 2017 22:29:27 GMT > Content-Type: text/html > Content-Length: 178 > Location: http://tendrl.org/ This configuration check works for me :) -- Martin Bukatovic USM QE team From mbukatov at redhat.com Wed Mar 15 09:16:54 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Wed, 15 Mar 2017 10:16:54 +0100 Subject: [Tendrl-devel] el6 support In-Reply-To: References: <7336dec4-1fb1-9145-3edb-63f6d66920b8@redhat.com> <1718172454.3704641.1489472837127.JavaMail.zimbra@redhat.com> <9662de51-624c-c18c-e975-c47dd64585fa@redhat.com> Message-ID: On 03/15/2017 10:07 AM, Sankarshan Mukhopadhyay wrote: > On Wed, Mar 15, 2017 at 2:33 PM, Martin Bukatovic wrote: >> On 03/14/2017 10:17 AM, Martin Bukatovic wrote: >>> Anyway, thanks for the update and the list. Based on what >>> you say here and the list, I see that we plan to package >>> all the components for el6: >>> >>> tendrl-ceph-integration >>> tendrl-gluster-integration >>> tendrl-node-agent >>> tendrl-commons >>> tendrl-api >>> tendrl-dashboard >>> tendrl-performance-monitoring >>> tendrl-node-monitoring >>> >>> So I read this more like that we plan to support el6 in general >>> rather than only for particular components (such as tendrl gluster >>> integration) - which was my original impression. >> > > Well, no. I believe there's some wires crossed and your original > understanding ought to be accurate. There is a sizeable challenge in > building all the components for el6 - specifically limited to the > availability of particular NVRs of dependencies. Ok, that makes sense and it's good to hear. So the question is which components require el6 builds? All which needs to run on gluster server or all but api and dashboard? >> Either way, it would be nice to know the original reasoning behind >> this as well, so that we can check if requirement to build everything >> for epel7 as well is sound. > > If we do not build the set of packages from the respositories with an > el7 build-target, how would be have binaries available to enable the > capabilities provided by the packages? Ah, sorry I did a typo. I meant el6 here. And my idea was to understand reasons why components selected for el6 needs that so that we can review and drop those which we don't need on el6 after all. -- Martin Bukatovic USM QE team From sankarshan at redhat.com Wed Mar 15 09:21:07 2017 From: sankarshan at redhat.com (sankarshan) Date: Wed, 15 Mar 2017 14:51:07 +0530 Subject: [Tendrl-devel] el6 support In-Reply-To: References: <7336dec4-1fb1-9145-3edb-63f6d66920b8@redhat.com> <1718172454.3704641.1489472837127.JavaMail.zimbra@redhat.com> <9662de51-624c-c18c-e975-c47dd64585fa@redhat.com> Message-ID: On 15 March 2017 at 14:46, Martin Bukatovic wrote: > On 03/15/2017 10:07 AM, Sankarshan Mukhopadhyay wrote: >> On Wed, Mar 15, 2017 at 2:33 PM, Martin Bukatovic wrote: >>> On 03/14/2017 10:17 AM, Martin Bukatovic wrote: >>>> Anyway, thanks for the update and the list. Based on what >>>> you say here and the list, I see that we plan to package >>>> all the components for el6: >>>> >>>> tendrl-ceph-integration >>>> tendrl-gluster-integration >>>> tendrl-node-agent >>>> tendrl-commons >>>> tendrl-api >>>> tendrl-dashboard >>>> tendrl-performance-monitoring >>>> tendrl-node-monitoring >>>> >>>> So I read this more like that we plan to support el6 in general >>>> rather than only for particular components (such as tendrl gluster >>>> integration) - which was my original impression. >>> >> >> Well, no. I believe there's some wires crossed and your original >> understanding ought to be accurate. There is a sizeable challenge in >> building all the components for el6 - specifically limited to the >> availability of particular NVRs of dependencies. > > Ok, that makes sense and it's good to hear. So the question is which > components require el6 builds? All which needs to run on gluster server > or all but api and dashboard? > The components which need to be installed on the SDS node would require el6 packages. I'll have to confirm with Rohan/Mrugesh - the previous statement is based on a hall-way conversation from December. >>> Either way, it would be nice to know the original reasoning behind >>> this as well, so that we can check if requirement to build everything >>> for epel7 as well is sound. >> >> If we do not build the set of packages from the respositories with an >> el7 build-target, how would be have binaries available to enable the >> capabilities provided by the packages? > > Ah, sorry I did a typo. I meant el6 here. And my idea was to understand > reasons why components selected for el6 needs that so that we can > review and drop those which we don't need on el6 after all. > From ltrilety at redhat.com Thu Mar 16 10:14:37 2017 From: ltrilety at redhat.com (Lubos Trilety) Date: Thu, 16 Mar 2017 06:14:37 -0400 (EDT) Subject: [Tendrl-devel] Improved Github workflow/branching for Tendrl components In-Reply-To: References: Message-ID: <1739917321.6637131.1489659277023.JavaMail.zimbra@redhat.com> Hi, you know that suggested work-flow does not follow http://nvie.com/posts/a-successful-git-branching-model/ right? 1. What I miss most is lack of release branches. It brings a question how the code will be moved from develop branch to master. Especially 'who' will decide and 'when' it will be made? 2. Another thing is related to current situation in our repositories. In most cases there are master and develop branches, but feature branches are not there. Well there are some which almost correspond to some feature, but not entirely. It's more like 'issue branches', which doesn't have to be automatically bad. But with no working unit tests and even not working other travis/tox checks that issue work-flow actually is bad as it is very difficult to put things together. What or who will tell that it should work together. With that a lot of issues arise later in product life and they will cost much more time to fix them. In other words, we should focus primary on those checks. Lubos ----- Original Message ----- From: "Rohan Kanade" To: "Mailing list for the contributors to the Tendrl project" Sent: Tuesday, March 14, 2017 2:36:15 PM Subject: [Tendrl-devel] Improved Github workflow/branching for Tendrl components Hi, Over the last release (1.2.1) we ran into issues related to async/parallel development and we broke a few things here and there while trying to sort out our branching model. Here is what we should be doing to enable better categorization of code coming in Tendrl Branch 1) Master == production ready code (This code should be tested via all functional/regression/integration tests) 2) Develop == feature ready code (This code should be regularly tested functionally) 3) Feature branches == span across components (eg node-agent, commons etc) and contain code for a that $Feature (these branches should be tested functionally and moved to develop once done) 4) Hotfixes == Any fixes required in the production code (master) branch should go to hotfix branches and should be merged back to master and develop The Tendrl backend repositories have been updated to reflect above branches. Id like to request the tendrl-api and the tendrl-dashboard to incorporate these too. More details on how this works out with examples : http://nvie.com/posts/a-successful-git-branching-model/ _______________________________________________ Tendrl-devel mailing list Tendrl-devel at redhat.com https://www.redhat.com/mailman/listinfo/tendrl-devel From rkanade at redhat.com Thu Mar 16 12:39:46 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Thu, 16 Mar 2017 18:09:46 +0530 Subject: [Tendrl-devel] Improved Github workflow/branching for Tendrl components In-Reply-To: <1739917321.6637131.1489659277023.JavaMail.zimbra@redhat.com> References: <1739917321.6637131.1489659277023.JavaMail.zimbra@redhat.com> Message-ID: 1. I was merely summarising the original article, we are indeed going to have release branches and feature branches. Its upto the maintainers of each tendrl repo as to when to implement them. 2. PEP8 and unit test coverage can definitely improve. Hoping for more contributions. On 16-Mar-2017 15:48, "Lubos Trilety" wrote: > Hi, > > you know that suggested work-flow does not follow http://nvie.com/posts/a- > successful-git-branching-model/ right? > 1. What I miss most is lack of release branches. It brings a question how > the code will be moved from develop branch to master. Especially 'who' will > decide and 'when' it will be made? > 2. Another thing is related to current situation in our repositories. In > most cases there are master and develop branches, but feature branches are > not there. Well there are some which almost correspond to some feature, but > not entirely. It's more like 'issue branches', which doesn't have to be > automatically bad. But with no working unit tests and even not working > other travis/tox checks that issue work-flow actually is bad as it is very > difficult to put things together. What or who will tell that it should work > together. With that a lot of issues arise later in product life and they > will cost much more time to fix them. In other words, we should focus > primary on those checks. > > Lubos > > > > ----- Original Message ----- > From: "Rohan Kanade" > To: "Mailing list for the contributors to the Tendrl project" < > tendrl-devel at redhat.com> > Sent: Tuesday, March 14, 2017 2:36:15 PM > Subject: [Tendrl-devel] Improved Github workflow/branching for Tendrl > components > > Hi, > > Over the last release (1.2.1) we ran into issues related to async/parallel > development and we broke a few things here and there while trying to sort > out our branching model. > > Here is what we should be doing to enable better categorization of code > coming in Tendrl > > Branch > 1) Master == production ready code (This code should be tested via all > functional/regression/integration tests) > > 2) Develop == feature ready code (This code should be regularly tested > functionally) > > 3) Feature branches == span across components (eg node-agent, commons etc) > and contain code for a that $Feature (these branches should be tested > functionally and moved to develop once done) > > 4) Hotfixes == Any fixes required in the production code (master) branch > should go to hotfix branches and should be merged back to master and > develop > > The Tendrl backend repositories have been updated to reflect above > branches. > > Id like to request the tendrl-api and the tendrl-dashboard to incorporate > these too. > > More details on how this works out with examples : > > http://nvie.com/posts/a-successful-git-branching-model/ > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > From mbukatov at redhat.com Fri Mar 17 10:18:02 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 17 Mar 2017 11:18:02 +0100 Subject: [Tendrl-devel] can't access ww.tendrl.org site In-Reply-To: References: <99a895cf-281e-d38b-355e-6dd0b7a9bfb2@redhat.com> Message-ID: <5b914946-3951-e070-14a0-be6022f444ce@redhat.com> On 03/13/2017 11:29 PM, Ken Dreyer wrote: > I've emailed Patrick a patch to our RH DNS config to make this work. I just noticed that url http://www.tendrl.org is reachable, thanks all involved. -- Martin Bukatovic USM QE team From japplewh at redhat.com Fri Mar 17 12:27:14 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Fri, 17 Mar 2017 08:27:14 -0400 Subject: [Tendrl-devel] can't access ww.tendrl.org site In-Reply-To: <5b914946-3951-e070-14a0-be6022f444ce@redhat.com> References: <99a895cf-281e-d38b-355e-6dd0b7a9bfb2@redhat.com> <5b914946-3951-e070-14a0-be6022f444ce@redhat.com> Message-ID: Yes I have updated the Github links to point to www.tendrl.org. One remaining issue/nit is that www.tendrl.org is being re-written to tendrl.org. On Fri, Mar 17, 2017 at 6:18 AM, Martin Bukatovic wrote: > On 03/13/2017 11:29 PM, Ken Dreyer wrote: > > I've emailed Patrick a patch to our RH DNS config to make this work. > > I just noticed that url http://www.tendrl.org is reachable, thanks > all involved. > > -- > Martin Bukatovic > USM QE team > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > -- Jeff Applewhite Principal Product Manager From mbukatov at redhat.com Fri Mar 17 13:38:47 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 17 Mar 2017 14:38:47 +0100 Subject: [Tendrl-devel] Improved Github workflow/branching for Tendrl components In-Reply-To: References: Message-ID: Dear all, On 03/14/2017 02:36 PM, Rohan Kanade wrote: > Over the last release (1.2.1) we ran into issues related to async/parallel > development and we broke a few things here and there while trying to sort > out our branching model. > > Here is what we should be doing to enable better categorization of code > coming in Tendrl > > Branch > 1) Master == production ready code (This code should be tested via all > functional/regression/integration tests) > > 2) Develop == feature ready code (This code should be regularly tested > functionally) > > 3) Feature branches == span across components (eg node-agent, commons etc) > and contain code for a that $Feature (these branches should be tested > functionally and moved to develop once done) > > 4) Hotfixes == Any fixes required in the production code (master) branch > should go to hotfix branches and should be merged back to master and develop > > The Tendrl backend repositories have been updated to reflect above branches. > > Id like to request the tendrl-api and the tendrl-dashboard to incorporate > these too. > > More details on how this works out with examples : > > http://nvie.com/posts/a-successful-git-branching-model/ I have few questions: 1) Do you plan to follow the branching model from nvie.com entirely? I'm asking because the model is quite specific about what each branch means and what could be branched from and into. 2) The follow up question: if we plan to follow the nvie.com model entirely, do we have some plan for transition period to get there? 3) The branching model describes feature branches as a private branch of some developer. Does it fit our model of work? I'm asking because it's not clear to me how would 2 or more people work on a single feature. There are multiple ways to do this: * branching model from nvie.com doesn't allow 2 or more people to work on a single feature/branch - all branches are on the same level and for this to work, it's better if the branches are more or less independent of each other * "a maintainer/gatekeeper model" when one person maintains some feature branch and other people, if they need to work on this feature as well work with this maintainer on his branch. 4) Would we allow branching from and into feature branches or do we plan to follow linear history there via rebases? This is kind of related to previous question. 5) I see one risk related to parallel development in feature branches. When there are multiple such branches open, it's possible that all the branches starts to conflict with each other after some time and so it would be harder to integrated them together when merging back into develop. What is our strategy related to this issue? This is related to question #3. 6) Do we plan to clarify delegation of responsibilities wrt new model, eg. who is going to be a gatekeeper for merging feature branch into develop, who would do the merge of develop into master? And so on. Thank you all for being patient with me and (maybe) too obvious questions, I'm guessing you have already figured out at least half of the details I'm asking about here. I'm just trying to be on the same page with you. -- Martin Bukatovic USM QE team From dahorak at redhat.com Mon Mar 20 08:19:34 2017 From: dahorak at redhat.com (=?UTF-8?Q?Daniel_Hor=c3=a1k?=) Date: Mon, 20 Mar 2017 09:19:34 +0100 Subject: [Tendrl-devel] obsolete (renamed) packages in Tendrl repo Message-ID: <27393eb7-5fae-c9c3-b744-a6cd309f3c5e@redhat.com> Hi, there are some packages in the Tendrl repo[1,2] which were renamed (for example tendrl-common -> tendrl-commons) and the old version was not removed from the repo (or they are obsolete for some other reason). Would it be possible to remove those obsolete packages? Old versions of current packages are ok, yum and other tools will chose the latest version, but packages with different name are considered as valid packages and it breaks some kind of package sanity testing (e.g. repoclosure). [1] https://copr.fedorainfracloud.org/coprs/tendrl/tendrl/ [2] https://copr-be.cloud.fedoraproject.org/results/tendrl/tendrl/ Thanks, Daniel From sankarshan at redhat.com Mon Mar 20 08:21:18 2017 From: sankarshan at redhat.com (sankarshan) Date: Mon, 20 Mar 2017 13:51:18 +0530 Subject: [Tendrl-devel] obsolete (renamed) packages in Tendrl repo In-Reply-To: <27393eb7-5fae-c9c3-b744-a6cd309f3c5e@redhat.com> References: <27393eb7-5fae-c9c3-b744-a6cd309f3c5e@redhat.com> Message-ID: On 20 March 2017 at 13:49, Daniel Hor?k wrote: > there are some packages in the Tendrl repo[1,2] which were renamed (for > example tendrl-common -> tendrl-commons) and the old version was not removed > from the repo (or they are obsolete for some other reason). > > Would it be possible to remove those obsolete packages? > > Old versions of current packages are ok, yum and other tools will chose the > latest version, but packages with different name are considered as valid > packages and it breaks some kind of package sanity testing (e.g. > repoclosure). > > [1] https://copr.fedorainfracloud.org/coprs/tendrl/tendrl/ > [2] https://copr-be.cloud.fedoraproject.org/results/tendrl/tendrl/ Fair point - would you file a catch-all issue and assign Timothy for this? From dahorak at redhat.com Mon Mar 20 14:55:05 2017 From: dahorak at redhat.com (=?UTF-8?Q?Daniel_Hor=c3=a1k?=) Date: Mon, 20 Mar 2017 15:55:05 +0100 Subject: [Tendrl-devel] obsolete (renamed) packages in Tendrl repo In-Reply-To: References: <27393eb7-5fae-c9c3-b744-a6cd309f3c5e@redhat.com> Message-ID: On 03/20/17 09:21, sankarshan wrote: > On 20 March 2017 at 13:49, Daniel Hor?k wrote: >> there are some packages in the Tendrl repo[1,2] which were renamed (for >> example tendrl-common -> tendrl-commons) and the old version was not removed >> from the repo (or they are obsolete for some other reason). >> >> Would it be possible to remove those obsolete packages? >> >> Old versions of current packages are ok, yum and other tools will chose the >> latest version, but packages with different name are considered as valid >> packages and it breaks some kind of package sanity testing (e.g. >> repoclosure). >> >> [1] https://copr.fedorainfracloud.org/coprs/tendrl/tendrl/ >> [2] https://copr-be.cloud.fedoraproject.org/results/tendrl/tendrl/ > > Fair point - would you file a catch-all issue and assign Timothy for this? What is the best place (which repository) for this new issue? I know about the tendrl-common package, but there are probably others belonging also to other repositories. Thanks, Daniel From japplewh at redhat.com Mon Mar 20 16:00:36 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Mon, 20 Mar 2017 12:00:36 -0400 Subject: [Tendrl-devel] obsolete (renamed) packages in Tendrl repo In-Reply-To: References: <27393eb7-5fae-c9c3-b744-a6cd309f3c5e@redhat.com> Message-ID: Yes I would also like to understand how best to file issues on packaging problems On Mon, Mar 20, 2017 at 10:55 AM, Daniel Hor?k wrote: > On 03/20/17 09:21, sankarshan wrote: > >> On 20 March 2017 at 13:49, Daniel Hor?k wrote: >> >>> there are some packages in the Tendrl repo[1,2] which were renamed (for >>> example tendrl-common -> tendrl-commons) and the old version was not >>> removed >>> from the repo (or they are obsolete for some other reason). >>> >>> Would it be possible to remove those obsolete packages? >>> >>> Old versions of current packages are ok, yum and other tools will chose >>> the >>> latest version, but packages with different name are considered as valid >>> packages and it breaks some kind of package sanity testing (e.g. >>> repoclosure). >>> >>> [1] https://copr.fedorainfracloud.org/coprs/tendrl/tendrl/ >>> [2] https://copr-be.cloud.fedoraproject.org/results/tendrl/tendrl/ >>> >> >> Fair point - would you file a catch-all issue and assign Timothy for this? >> > > What is the best place (which repository) for this new issue? > > I know about the tendrl-common package, but there are probably others > belonging also to other repositories. > > Thanks, > Daniel > > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > -- Jeff Applewhite Principal Product Manager From tjeyasin at redhat.com Tue Mar 21 09:40:32 2017 From: tjeyasin at redhat.com (Timothy Asir Jeyasingh) Date: Tue, 21 Mar 2017 05:40:32 -0400 (EDT) Subject: [Tendrl-devel] obsolete (renamed) packages in Tendrl repo In-Reply-To: <27393eb7-5fae-c9c3-b744-a6cd309f3c5e@redhat.com> References: <27393eb7-5fae-c9c3-b744-a6cd309f3c5e@redhat.com> Message-ID: <662183969.6072370.1490089232755.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Daniel Hor?k" > To: tendrl-devel at redhat.com > Sent: Monday, March 20, 2017 1:49:34 PM > Subject: [Tendrl-devel] obsolete (renamed) packages in Tendrl repo > > Hi, > > there are some packages in the Tendrl repo[1,2] which were renamed (for > example tendrl-common -> tendrl-commons) and the old version was not > removed from the repo (or they are obsolete for some other reason). > tendrl-common is removed now from the Tendrl repo[1,2]. > Would it be possible to remove those obsolete packages? > > Old versions of current packages are ok, yum and other tools will chose > the latest version, but packages with different name are considered as > valid packages and it breaks some kind of package sanity testing (e.g. > repoclosure). > > [1] https://copr.fedorainfracloud.org/coprs/tendrl/tendrl/ > [2] https://copr-be.cloud.fedoraproject.org/results/tendrl/tendrl/ > > Thanks, > Daniel > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > From sankarshan at redhat.com Tue Mar 21 09:44:53 2017 From: sankarshan at redhat.com (sankarshan) Date: Tue, 21 Mar 2017 15:14:53 +0530 Subject: [Tendrl-devel] obsolete (renamed) packages in Tendrl repo In-Reply-To: References: <27393eb7-5fae-c9c3-b744-a6cd309f3c5e@redhat.com> Message-ID: On 20 March 2017 at 21:30, Jeff Applewhite wrote: > Yes I would also like to understand how best to file issues on packaging > problems > Packaging related issues are linked to the packages originating from the repositories within the organization. The "best place" would be the appropriate repository. I agree that this is cumbersome at this point and I'm open to feedback on what would be an easier path From tjeyasin at redhat.com Tue Mar 21 09:55:19 2017 From: tjeyasin at redhat.com (Timothy Asir Jeyasingh) Date: Tue, 21 Mar 2017 05:55:19 -0400 (EDT) Subject: [Tendrl-devel] obsolete (renamed) packages in Tendrl repo In-Reply-To: <662183969.6072370.1490089232755.JavaMail.zimbra@redhat.com> References: <27393eb7-5fae-c9c3-b744-a6cd309f3c5e@redhat.com> <662183969.6072370.1490089232755.JavaMail.zimbra@redhat.com> Message-ID: <1582497060.6083451.1490090119290.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Timothy Asir Jeyasingh" > To: "Mailing list for the contributors to the Tendrl project" > Sent: Tuesday, March 21, 2017 3:10:32 PM > Subject: Re: [Tendrl-devel] obsolete (renamed) packages in Tendrl repo > > > > ----- Original Message ----- > > From: "Daniel Hor?k" > > To: tendrl-devel at redhat.com > > Sent: Monday, March 20, 2017 1:49:34 PM > > Subject: [Tendrl-devel] obsolete (renamed) packages in Tendrl repo > > > > Hi, > > > > there are some packages in the Tendrl repo[1,2] which were renamed (for > > example tendrl-common -> tendrl-commons) and the old version was not > > removed from the repo (or they are obsolete for some other reason). > > > tendrl-common is removed now from the Tendrl repo[1,2]. also i have removed python-yaml, pyYAML, tendrl-frontend, six. package: namespaces will be removed after few days. > > Would it be possible to remove those obsolete packages? > > > > Old versions of current packages are ok, yum and other tools will chose > > the latest version, but packages with different name are considered as > > valid packages and it breaks some kind of package sanity testing (e.g. > > repoclosure). > > > > [1] https://copr.fedorainfracloud.org/coprs/tendrl/tendrl/ > > [2] https://copr-be.cloud.fedoraproject.org/results/tendrl/tendrl/ > > > > Thanks, > > Daniel > > > > _______________________________________________ > > Tendrl-devel mailing list > > Tendrl-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/tendrl-devel > > > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > From mbukatov at redhat.com Tue Mar 21 10:00:51 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Tue, 21 Mar 2017 11:00:51 +0100 Subject: [Tendrl-devel] obsolete (renamed) packages in Tendrl repo In-Reply-To: References: <27393eb7-5fae-c9c3-b744-a6cd309f3c5e@redhat.com> Message-ID: On 03/21/2017 10:44 AM, sankarshan wrote: > Packaging related issues are linked to the packages originating from > the repositories within the organization. The "best place" would be > the appropriate repository. I agree that this is cumbersome at this > point and I'm open to feedback on what would be an easier path I originally suggested keeping all rpm spec files in a single repo, so that rpm packaging work would be concentrated on a single place. This could (this is my guess though) simplify spec file maintenance as all spec files, including dependencies not included in CentOS, could be changed and inspected at once, maintained by single person. On the other hand, Ken pointed out that having spec file with the code itself make synchronization between changes in code and spec file easier - which is a fair point. From my qe perspective, this delivers most values for us when we mandate that every change in a spec file should be buildable. -- Martin Bukatovic USM QE team From japplewh at redhat.com Thu Mar 23 02:01:10 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Thu, 23 Mar 2017 02:01:10 +0000 Subject: [Tendrl-devel] API configuration Message-ID: Hi All Can we please get an update on the proper configuration of the API and etcd services. It appears that there is a new requirement here but it's not documented anywhere I have seen. Thanks Jeff From sankarshan at redhat.com Thu Mar 23 08:39:38 2017 From: sankarshan at redhat.com (sankarshan) Date: Thu, 23 Mar 2017 14:09:38 +0530 Subject: [Tendrl-devel] https://github.com/Tendrl/usmqe-tests/wiki Message-ID: I don't want to edit/munge the content on this page. However, some of the topics in the high priority list seem to have been closed already - can we have a strike through? /s From mbukatov at redhat.com Thu Mar 23 08:58:10 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 23 Mar 2017 09:58:10 +0100 Subject: [Tendrl-devel] https://github.com/Tendrl/usmqe-tests/wiki In-Reply-To: References: Message-ID: On 03/23/2017 09:39 AM, sankarshan wrote: > I don't want to edit/munge the content on this page. However, some of > the topics in the high priority list seem to have been closed already > - can we have a strike through? I did a quick review and updated the wikipage with the following results: * I have marked issue gluster-integration/issues/151 as resolved. * Issue api/issues/33 needs to be verified on working cluster first. * I have no idea what issue performance-monitoring/pull/67 is all about (the description here is not good enough), recheck from our side is needed. * Issue node-agent/issues/297 was marked as resolved. -- Martin Bukatovic USM QE team From mkudlej at redhat.com Thu Mar 23 10:28:49 2017 From: mkudlej at redhat.com (Martin Kudlej) Date: Thu, 23 Mar 2017 11:28:49 +0100 Subject: [Tendrl-devel] API configuration In-Reply-To: References: Message-ID: Hi Jeff, On 03/23/2017 03:01 AM, Jeff Applewhite wrote: > Can we please get an update on the proper configuration of the API and etcd > services. It appears that there is a new requirement here but it's not > documented anywhere I have seen. you need to create admin user: https://github.com/Tendrl/api/blob/master/docs/users.adoc#create-admin-user Then you can call API functions. User login is not implemented in UI yet. See https://github.com/Tendrl/dashboard/issues/202 and https://github.com/Tendrl/dashboard/issues/203 -- 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 Thu Mar 23 15:05:05 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Thu, 23 Mar 2017 11:05:05 -0400 Subject: [Tendrl-devel] API configuration In-Reply-To: References: Message-ID: Thanks Martin That step should also be reflected here too: https://github.com/Tendrl/documentation/wiki/Tendrl-Package-Installation-Reference Jeff On Thu, Mar 23, 2017 at 6:28 AM, Martin Kudlej wrote: > Hi Jeff, > > On 03/23/2017 03:01 AM, Jeff Applewhite wrote: > >> Can we please get an update on the proper configuration of the API and >> etcd >> services. It appears that there is a new requirement here but it's not >> documented anywhere I have seen. >> > > you need to create admin user: https://github.com/Tendrl/api/ > blob/master/docs/users.adoc#create-admin-user > Then you can call API functions. User login is not implemented in UI yet. > See https://github.com/Tendrl/dashboard/issues/202 and > https://github.com/Tendrl/dashboard/issues/203 > > > -- > 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 > -- Jeff Applewhite Principal Product Manager From dahorak at redhat.com Thu Mar 23 20:50:22 2017 From: dahorak at redhat.com (=?UTF-8?Q?Daniel_Hor=c3=a1k?=) Date: Thu, 23 Mar 2017 21:50:22 +0100 Subject: [Tendrl-devel] Initial package validation process Message-ID: <11f8aec4-457f-4b05-b791-876c7413a27b@redhat.com> Hello All, thanks to Martin B., we have initial version of package validation process. Now it consists from following two jobs in CentOS CI[1]: Tendrl0 - 2 - package-validation - Test RPMs Tendrl0 - 3 - package-validation - Test Installation (The ambient jobs "Tendrl0 - 1..." and "Tendrl0 - X..." are just auxiliary jobs - setup and teardown of the test environment.) The "Test RPMs"[2] job performs repoclosure for whole tendrl[3] repository and rpmlint and rpmdeplint for each tendrl-* package. As you can see, there are failures in the Test Result - all of them are now from rpmlint warnings and errors. The "Test Installation"[4] job tries to install and uninstall each tendrl-* package (nothing else). Hopefully in the near future, we will be able to add more steps to the validation process and also we will have nicer and clearer dashboard. [1] https://ci.centos.org/view/Tendrl/ [2] https://ci.centos.org/view/Tendrl/job/tendrl0-2-package-validation-test-rpm/ [3] https://copr-be.cloud.fedoraproject.org/results/tendrl/tendrl/epel-7-x86_64/ [4] https://ci.centos.org/view/Tendrl/job/tendrl0-3-package-validation-test-install/ Regards, Daniel From kdreyer at redhat.com Thu Mar 23 21:14:51 2017 From: kdreyer at redhat.com (Ken Dreyer) Date: Thu, 23 Mar 2017 15:14:51 -0600 Subject: [Tendrl-devel] Initial package validation process In-Reply-To: <11f8aec4-457f-4b05-b791-876c7413a27b@redhat.com> References: <11f8aec4-457f-4b05-b791-876c7413a27b@redhat.com> Message-ID: This is great. Thanks guys. On Thu, Mar 23, 2017 at 2:50 PM, Daniel Hor?k wrote: > Hello All, > > thanks to Martin B., we have initial version of package validation process. > > Now it consists from following two jobs in CentOS CI[1]: > > Tendrl0 - 2 - package-validation - Test RPMs > Tendrl0 - 3 - package-validation - Test Installation > > (The ambient jobs "Tendrl0 - 1..." and "Tendrl0 - X..." are just auxiliary > jobs - setup and teardown of the test environment.) > > The "Test RPMs"[2] job performs repoclosure for whole tendrl[3] repository > and rpmlint and rpmdeplint for each tendrl-* package. > > As you can see, there are failures in the Test Result - all of them are now > from rpmlint warnings and errors. > > The "Test Installation"[4] job tries to install and uninstall each tendrl-* > package (nothing else). > > Hopefully in the near future, we will be able to add more steps to the > validation process and also we will have nicer and clearer dashboard. > > [1] https://ci.centos.org/view/Tendrl/ > [2] > https://ci.centos.org/view/Tendrl/job/tendrl0-2-package-validation-test-rpm/ > [3] > https://copr-be.cloud.fedoraproject.org/results/tendrl/tendrl/epel-7-x86_64/ > [4] > https://ci.centos.org/view/Tendrl/job/tendrl0-3-package-validation-test-install/ > > Regards, > Daniel > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel From amainkar at redhat.com Thu Mar 23 21:18:04 2017 From: amainkar at redhat.com (Anjali Mainkar) Date: Thu, 23 Mar 2017 17:18:04 -0400 (EDT) Subject: [Tendrl-devel] Initial package validation process In-Reply-To: <11f8aec4-457f-4b05-b791-876c7413a27b@redhat.com> References: <11f8aec4-457f-4b05-b791-876c7413a27b@redhat.com> Message-ID: <334438795.6211430.1490303884671.JavaMail.zimbra@redhat.com> That's awesome. Nice job martin for taking extra effort to get this done. ----- Original Message ----- | From: "Daniel Hor?k" | To: "Mailing list for the contributors to the Tendrl project" | Sent: Thursday, March 23, 2017 4:50:22 PM | Subject: [Tendrl-devel] Initial package validation process | | Hello All, | | thanks to Martin B., we have initial version of package validation process. | | Now it consists from following two jobs in CentOS CI[1]: | | Tendrl0 - 2 - package-validation - Test RPMs | Tendrl0 - 3 - package-validation - Test Installation | | (The ambient jobs "Tendrl0 - 1..." and "Tendrl0 - X..." are just | auxiliary jobs - setup and teardown of the test environment.) | | The "Test RPMs"[2] job performs repoclosure for whole tendrl[3] | repository and rpmlint and rpmdeplint for each tendrl-* package. | | As you can see, there are failures in the Test Result - all of them are | now from rpmlint warnings and errors. | | The "Test Installation"[4] job tries to install and uninstall each | tendrl-* package (nothing else). | | Hopefully in the near future, we will be able to add more steps to the | validation process and also we will have nicer and clearer dashboard. | | [1] https://ci.centos.org/view/Tendrl/ | [2] | https://ci.centos.org/view/Tendrl/job/tendrl0-2-package-validation-test-rpm/ | [3] | https://copr-be.cloud.fedoraproject.org/results/tendrl/tendrl/epel-7-x86_64/ | [4] | https://ci.centos.org/view/Tendrl/job/tendrl0-3-package-validation-test-install/ | | Regards, | Daniel | | _______________________________________________ | Tendrl-devel mailing list | Tendrl-devel at redhat.com | https://www.redhat.com/mailman/listinfo/tendrl-devel | | | From japplewh at redhat.com Fri Mar 24 12:15:08 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Fri, 24 Mar 2017 08:15:08 -0400 Subject: [Tendrl-devel] Initial package validation process In-Reply-To: <334438795.6211430.1490303884671.JavaMail.zimbra@redhat.com> References: <11f8aec4-457f-4b05-b791-876c7413a27b@redhat.com> <334438795.6211430.1490303884671.JavaMail.zimbra@redhat.com> Message-ID: Yes nice work! On Thu, Mar 23, 2017 at 5:18 PM, Anjali Mainkar wrote: > That's awesome. Nice job martin for taking extra effort to get this done. > > ----- Original Message ----- > | From: "Daniel Hor?k" > | To: "Mailing list for the contributors to the Tendrl project" < > tendrl-devel at redhat.com> > | Sent: Thursday, March 23, 2017 4:50:22 PM > | Subject: [Tendrl-devel] Initial package validation process > | > | Hello All, > | > | thanks to Martin B., we have initial version of package validation > process. > | > | Now it consists from following two jobs in CentOS CI[1]: > | > | Tendrl0 - 2 - package-validation - Test RPMs > | Tendrl0 - 3 - package-validation - Test Installation > | > | (The ambient jobs "Tendrl0 - 1..." and "Tendrl0 - X..." are just > | auxiliary jobs - setup and teardown of the test environment.) > | > | The "Test RPMs"[2] job performs repoclosure for whole tendrl[3] > | repository and rpmlint and rpmdeplint for each tendrl-* package. > | > | As you can see, there are failures in the Test Result - all of them are > | now from rpmlint warnings and errors. > | > | The "Test Installation"[4] job tries to install and uninstall each > | tendrl-* package (nothing else). > | > | Hopefully in the near future, we will be able to add more steps to the > | validation process and also we will have nicer and clearer dashboard. > | > | [1] https://ci.centos.org/view/Tendrl/ > | [2] > | https://ci.centos.org/view/Tendrl/job/tendrl0-2-package- > validation-test-rpm/ > | [3] > | https://copr-be.cloud.fedoraproject.org/results/ > tendrl/tendrl/epel-7-x86_64/ > | [4] > | https://ci.centos.org/view/Tendrl/job/tendrl0-3-package- > validation-test-install/ > | > | Regards, > | Daniel > | > | _______________________________________________ > | Tendrl-devel mailing list > | Tendrl-devel at redhat.com > | https://www.redhat.com/mailman/listinfo/tendrl-devel > | > | > | > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > -- Jeff Applewhite Principal Product Manager From dahorak at redhat.com Tue Mar 28 08:50:44 2017 From: dahorak at redhat.com (=?UTF-8?Q?Daniel_Hor=c3=a1k?=) Date: Tue, 28 Mar 2017 10:50:44 +0200 Subject: [Tendrl-devel] CentOS: where to get ceph-ansible? Message-ID: <2aab9fee-f18e-93b1-2f63-a4c01391237b@redhat.com> Hi, If I understand it correctly, there is a plan to use ceph-ansible (and maybe ceph-installer) for Ceph installation process in Tendrl. Also we are using ceph-ansible for creating Ceph cluster for test import functionality of Tendrl. Where can we get ceph-ansible package for CentOS 7? Thanks, Daniel From dahorak at redhat.com Tue Mar 28 11:33:06 2017 From: dahorak at redhat.com (=?UTF-8?Q?Daniel_Hor=c3=a1k?=) Date: Tue, 28 Mar 2017 13:33:06 +0200 Subject: [Tendrl-devel] rpmlint errors and warnings (was: Initial package validation process) In-Reply-To: <11f8aec4-457f-4b05-b791-876c7413a27b@redhat.com> References: <11f8aec4-457f-4b05-b791-876c7413a27b@redhat.com> Message-ID: <727f4e47-7a1c-1e0f-f2f5-2f149f75e14d@redhat.com> Hi, as you might noticed, the dashboard[1] announced in previous email was changed recently. Firstly we have nice and clear dashboard. If it is not displayed correctly on your screen, please tweak it yourself by the "Configure" button (it is not possible to change this configuration globally, so you have to tweak it for yourself). Also I've changed the jobs names to be slightly more clear and I'll add additional test steps later. The main point of this email is the list of failing rpmlint checks[2]. There are lot's of errors and warnings from rpmlint nearly for each package in the tendrl repo. We consider all those issues serious enoght to be looked into. Even when the warning looks insignificant, it could be caused by serious error and for this reason, we think it's necessary to look into every error reported there and find out what caused it and act based on that. The current state of packaging is not good, definitelly dont matching fedora requirements we target. Could you please review those issues and fix what's possible to fix? We will report github issue for each meaningful warning/error later, but the list is quite huge and some of the issues might be fixed easily without unnecessary paperwork. [1] https://ci.centos.org/view/Tendrl/ [2] https://ci.centos.org/view/Tendrl/job/tendrl-0-1-package-validation-rpmlint/lastCompletedBuild/testReport/ Thanks, Daniel On 03/23/17 21:50, Daniel Hor?k wrote: > Hello All, > > thanks to Martin B., we have initial version of package validation process. > > Now it consists from following two jobs in CentOS CI[1]: > > Tendrl0 - 2 - package-validation - Test RPMs > Tendrl0 - 3 - package-validation - Test Installation > > (The ambient jobs "Tendrl0 - 1..." and "Tendrl0 - X..." are just > auxiliary jobs - setup and teardown of the test environment.) > > The "Test RPMs"[2] job performs repoclosure for whole tendrl[3] > repository and rpmlint and rpmdeplint for each tendrl-* package. > > As you can see, there are failures in the Test Result - all of them are > now from rpmlint warnings and errors. > > The "Test Installation"[4] job tries to install and uninstall each > tendrl-* package (nothing else). > > Hopefully in the near future, we will be able to add more steps to the > validation process and also we will have nicer and clearer dashboard. > > [1] https://ci.centos.org/view/Tendrl/ > [2] > https://ci.centos.org/view/Tendrl/job/tendrl0-2-package-validation-test-rpm/ > > [3] > https://copr-be.cloud.fedoraproject.org/results/tendrl/tendrl/epel-7-x86_64/ > > [4] > https://ci.centos.org/view/Tendrl/job/tendrl0-3-package-validation-test-install/ > > > Regards, > Daniel > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel From kdreyer at redhat.com Tue Mar 28 15:05:51 2017 From: kdreyer at redhat.com (Ken Dreyer) Date: Tue, 28 Mar 2017 09:05:51 -0600 Subject: [Tendrl-devel] CentOS: where to get ceph-ansible? In-Reply-To: <2aab9fee-f18e-93b1-2f63-a4c01391237b@redhat.com> References: <2aab9fee-f18e-93b1-2f63-a4c01391237b@redhat.com> Message-ID: For now you can download builds from Ceph's CI system, shaman.ceph.com. https://shaman.ceph.com/api/repos/ceph-ansible/master/latest/centos/7/repo is a permalink/redirect URL to whatever the latest master is. Note that you'll need to refresh the entire repo definition if you want to get a new build here. You can also directly link to a repository by using baseurl=https://shaman.ceph.com/api/repos/ceph-ansible/master/latest/centos/7/noarch/noarch in your own .repo file. This is similar to the way Copr works. Note that when this is set, new builds will replace old builds, so you'll want to use a short Yum cache TTL. Up to you which method you want to use. The first method gives you more control, in that once you've downloaded the .repo file, you're guaranteed to get the same NVR build every time you "yum install ceph-ansible". It also means you have to refresh the repository definition each time you want to take in a new build. The second method is more traditional. - Ken On Tue, Mar 28, 2017 at 2:50 AM, Daniel Hor?k wrote: > Hi, > > If I understand it correctly, there is a plan to use ceph-ansible (and maybe > ceph-installer) for Ceph installation process in Tendrl. Also we are using > ceph-ansible for creating Ceph cluster for test import functionality of > Tendrl. > > Where can we get ceph-ansible package for CentOS 7? > > Thanks, > Daniel > > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel