From root at dhcp42-16.lab.eng.blr.redhat.com Tue Jul 4 10:36:04 2017 From: root at dhcp42-16.lab.eng.blr.redhat.com (root at dhcp42-16.lab.eng.blr.redhat.com) Date: Tue, 4 Jul 2017 16:06:04 +0530 (IST) Subject: [Tendrl-devel] Downstream Scratch Build for Common report Message-ID: <20170704103604.708A824B8A51@dhcp42-16.lab.eng.blr.redhat.com> Tendrl-Commons Downstream scratch built successfully. From surs at redhat.com Thu Jul 6 10:47:42 2017 From: surs at redhat.com (Sachidananda URS) Date: Thu, 6 Jul 2017 16:17:42 +0530 Subject: [Tendrl-devel] Geo-replication support in gdeploy Message-ID: Hi, Now we have support for creating geo-replication sessions (secure-session included) using gdeploy. Thanks to Aravinda, for the valuable suggestions and help in debugging geo-replication install process. The patch https://github.com/gluster/gdeploy/commit/a1447c4304de50 has been merged into upstream. For configuring secure geo-replication session the following configuration can be used: [hosts] 10.70.42.122 [geo-replication] action=create georepuser=testgeorep mastervol=10.70.42.122:mastervolume slavevol=10.70.43.48:slavevolume slavenodes=10.70.43.48,10.70.42.217 force=no Assuming mastervol and slavevol are already created. For configuring geo-replication as root: [hosts] 10.70.43.219 [geo-replication] action=create mastervol=10.70.43.219:mastervolume slavevol=10.70.43.25:slavevolume slavenodes=10.70.43.25,10.70.43.86 force=yes Future plan in the coming week: Capability to stop/pause/resume/delete geo-replication sessions. Capability to reconfigure geo-replication sessions. Add support for failover and failback. -sac From surs at redhat.com Fri Jul 7 13:29:44 2017 From: surs at redhat.com (Sachidananda URS) Date: Fri, 7 Jul 2017 18:59:44 +0530 Subject: [Tendrl-devel] Geo-replication support in gdeploy In-Reply-To: References: Message-ID: Follow up on earlier mail: Now gdeploy supports all the features of geo-replication (including configure) except for failover and failback. -sac On Thu, Jul 6, 2017 at 4:17 PM, Sachidananda URS wrote: > Hi, > > Now we have support for creating geo-replication sessions (secure-session > included) using > gdeploy. Thanks to Aravinda, for the valuable suggestions and help in > debugging > geo-replication install process. > > The patch https://github.com/gluster/gdeploy/commit/a1447c4304de50 has > been merged into > upstream. > > For configuring secure geo-replication session the following configuration > can be used: > > [hosts] > 10.70.42.122 > > [geo-replication] > action=create > georepuser=testgeorep > mastervol=10.70.42.122:mastervolume > slavevol=10.70.43.48:slavevolume > slavenodes=10.70.43.48,10.70.42.217 > force=no > > Assuming mastervol and slavevol are already created. > > For configuring geo-replication as root: > > [hosts] > 10.70.43.219 > > [geo-replication] > action=create > mastervol=10.70.43.219:mastervolume > slavevol=10.70.43.25:slavevolume > slavenodes=10.70.43.25,10.70.43.86 > force=yes > > > Future plan in the coming week: > > Capability to stop/pause/resume/delete geo-replication sessions. > Capability to reconfigure geo-replication sessions. > Add support for failover and failback. > > -sac > From surs at redhat.com Thu Jul 13 14:11:17 2017 From: surs at redhat.com (Sachidananda URS) Date: Thu, 13 Jul 2017 19:41:17 +0530 Subject: [Tendrl-devel] Geo-replication support in gdeploy In-Reply-To: References: Message-ID: I've added failover support in gdeploy. Failback will not be added as it involves monitoring the status and then triggering a few configurations. I'm leaving it for now. Any suggestions? On Fri, Jul 7, 2017 at 6:59 PM, Sachidananda URS wrote: > Follow up on earlier mail: > > Now gdeploy supports all the features of geo-replication (including > configure) except for failover and failback. > > -sac > > > > On Thu, Jul 6, 2017 at 4:17 PM, Sachidananda URS wrote: > >> Hi, >> >> Now we have support for creating geo-replication sessions (secure-session >> included) using >> gdeploy. Thanks to Aravinda, for the valuable suggestions and help in >> debugging >> geo-replication install process. >> >> The patch https://github.com/gluster/gdeploy/commit/a1447c4304de50 has >> been merged into >> upstream. >> >> For configuring secure geo-replication session the following >> configuration can be used: >> >> [hosts] >> 10.70.42.122 >> >> [geo-replication] >> action=create >> georepuser=testgeorep >> mastervol=10.70.42.122:mastervolume >> slavevol=10.70.43.48:slavevolume >> slavenodes=10.70.43.48,10.70.42.217 >> force=no >> >> Assuming mastervol and slavevol are already created. >> >> For configuring geo-replication as root: >> >> [hosts] >> 10.70.43.219 >> >> [geo-replication] >> action=create >> mastervol=10.70.43.219:mastervolume >> slavevol=10.70.43.25:slavevolume >> slavenodes=10.70.43.25,10.70.43.86 >> force=yes >> >> >> Future plan in the coming week: >> >> Capability to stop/pause/resume/delete geo-replication sessions. >> Capability to reconfigure geo-replication sessions. >> Add support for failover and failback. >> >> -sac >> > > From rkanade at redhat.com Fri Jul 14 05:29:21 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Fri, 14 Jul 2017 10:59:21 +0530 Subject: [Tendrl-devel] Important updates to git branching and nightly/release/feature rpm packaging for Tendrl Message-ID: The current branching model [0] used by the Tendrl projects is being simplified, These changes are in line to ensure we can release/prep releases better and allow development of new features simultaneously. Changes: Release: - A stable release branch is cut off from master - Release prep is to be done on this branch - bug fixes can be targeted towards release branches - rpm packages to be built for such branches - eg: release/1.4.1, release/$nvr Features: - $feature branches will be the place to land code related to that $feature across all Tendrl repos - These branches will be merged to master once feature is tested - rpm packages to be built for each feature branch across repos - branch eg: spec/gluster_volume_delete/, spec/$tendrl_spec_name - Travis gate per PR on feature branches. Master: - feature branches land in master branch - release branches are cut off from master branch - bug-fixes in release branches can be targeted towards master branch - rpm packages to be built (these are unstable nightly packages) for the master - Travis and Functional CI gates per PR on master branch. From rkanade at redhat.com Fri Jul 14 05:30:35 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Fri, 14 Jul 2017 11:00:35 +0530 Subject: [Tendrl-devel] Important updates to git branching and nightly/release/feature rpm packaging for Tendrl In-Reply-To: References: Message-ID: Adding the previous branching strategy https://www.redhat.com/archives/tendrl-devel/2017-March/msg00023.html On Fri, Jul 14, 2017 at 10:59 AM, Rohan Kanade wrote: > The current branching model [0] used by the Tendrl projects is being > simplified, These changes are in line to ensure we can release/prep > releases better and allow development of new features simultaneously. > > Changes: > > Release: > - A stable release branch is cut off from master > - Release prep is to be done on this branch > - bug fixes can be targeted towards release branches > - rpm packages to be built for such branches > - eg: release/1.4.1, release/$nvr > > > Features: > - $feature branches will be the place to land code related to that > $feature across all Tendrl repos > - These branches will be merged to master once feature is tested > - rpm packages to be built for each feature branch across repos > - branch eg: spec/gluster_volume_delete/, spec/$tendrl_spec_name > - Travis gate per PR on feature branches. > > > Master: > - feature branches land in master branch > - release branches are cut off from master branch > - bug-fixes in release branches can be targeted towards master branch > - rpm packages to be built (these are unstable nightly packages) for the > master > - Travis and Functional CI gates per PR on master branch. > > > From rkanade at redhat.com Sat Jul 15 18:49:58 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Sun, 16 Jul 2017 00:19:58 +0530 Subject: [Tendrl-devel] Tendrl Community update - Governance Message-ID: Pleased to share updates from Tendrl core team related to Governance structure of Tendrl community Link: https://github.com/Tendrl/documentation/wiki/Tendrl-Governance-and-Community From rkanade at redhat.com Tue Jul 18 06:10:06 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Tue, 18 Jul 2017 11:40:06 +0530 Subject: [Tendrl-devel] Important updates to git branching and nightly/release/feature rpm packaging for Tendrl In-Reply-To: References: Message-ID: Currently reviewing in-progress PRs across Tendrl repos, once these are merged the above proposed workflow will be effective On Fri, Jul 14, 2017 at 11:00 AM, Rohan Kanade wrote: > Adding the previous branching strategy > > https://www.redhat.com/archives/tendrl-devel/2017-March/msg00023.html > > On Fri, Jul 14, 2017 at 10:59 AM, Rohan Kanade wrote: > >> The current branching model [0] used by the Tendrl projects is being >> simplified, These changes are in line to ensure we can release/prep >> releases better and allow development of new features simultaneously. >> >> Changes: >> >> Release: >> - A stable release branch is cut off from master >> - Release prep is to be done on this branch >> - bug fixes can be targeted towards release branches >> - rpm packages to be built for such branches >> - eg: release/1.4.1, release/$nvr >> >> >> Features: >> - $feature branches will be the place to land code related to that >> $feature across all Tendrl repos >> - These branches will be merged to master once feature is tested >> - rpm packages to be built for each feature branch across repos >> - branch eg: spec/gluster_volume_delete/, spec/$tendrl_spec_name >> - Travis gate per PR on feature branches. >> >> >> Master: >> - feature branches land in master branch >> - release branches are cut off from master branch >> - bug-fixes in release branches can be targeted towards master branch >> - rpm packages to be built (these are unstable nightly packages) for the >> master >> - Travis and Functional CI gates per PR on master branch. >> >> >> > From mbukatov at redhat.com Wed Jul 19 15:19:06 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Wed, 19 Jul 2017 17:19:06 +0200 Subject: [Tendrl-devel] Tendrl Community update - Governance In-Reply-To: References: Message-ID: On 07/15/2017 08:49 PM, Rohan Kanade wrote: > Pleased to share updates from Tendrl core team related to Governance > structure of Tendrl community > > Link: > https://github.com/Tendrl/documentation/wiki/Tendrl-Governance-and-Community The wikipage states: > https://github.com/Tendrl/ui (current and future content need to be > sent as PRs to Tendrl/dashboard and the upcoming metrics/monitoring > dashboard) This list of all UI design maintained by Ju is very useful, for all groups involved and I guess we all agree with that. But the suggestion to move the list of ux designs somewhere else, where Ju would have to create pull request first makes me puzzled for the following reasons: 1) The proposal suggests to split the list of ui designs into multiple places, while I think that there is a value in having this in a *single place*. Even when we will have 2 different types of ui - tendrl web and grafana dashboard, keeping it on a single place would for example make easier to plan which grafana dashboards should be linked from where. Needles to say that single place is easier to search, review and maintain. 2) Asking Ju to create a pull request when she completes a ui design in a different repository would prevent her to maintain the list efficiently - what is the reasoning behind this? If the problem is the fact that this ui design list is placed in repository among other tendrl repositories on tendrl github group, we could think about moving this overview of ui design into wiki page in https://github.com/Tendrl/documentation/wiki This way, Ju could maintain the list as she does now, but in a wiki page (so that it would be hopefully as easy or easier compared to current situation), all the others still have the list of designs to refer to and we solve the problem with the repo. Or am I missing anything? And sorry for intervening here, but I just wants to make sure that this design overview doesn't go away :) -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Wed Jul 19 15:33:34 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Wed, 19 Jul 2017 17:33:34 +0200 Subject: [Tendrl-devel] Tendrl Community update - Governance In-Reply-To: References: Message-ID: On 07/15/2017 08:49 PM, Rohan Kanade wrote: > Pleased to share updates from Tendrl core team related to Governance > structure of Tendrl community > > Link: > https://github.com/Tendrl/documentation/wiki/Tendrl-Governance-and-Community When it comes to the unsupported repos (the last section in the Governance wikipage linked above), I have the following notes. Repositories with usmqe- prefix are maintained by usmqe team[1] and the question is whether to rename them or to move them out of Tendrl github organization. And I guess that the decision will boil down the a question what do we understand by *adaptation to Tendrl repo best practices*. The other point I would like to raise here is suggestion to merge usmqe-setup with tendrl-ansible doesn't make sense, because the purpose and focus of these two repositories is very different: * tendrl-ansible is official part of tendrl project, following the tendrl branching model and will be part of next upstream release. The purpose of this repository is to automate tendrl installation based on tendrl documentation, for others to install it either on poc virtual machines or production. * usmqe-setup is not part of tendrl upstream release. The main purpose of this repository is to automate qe related setup operations, such as installation of qe tools, setup of qe infrastructure, description of ci environment and test case setup. This has no direct value for tendrl user. Some playbooks here uses roles from tendrl-ansible - as there is no value in duplicating them. We actually did the opposite recently: we moved ansible roles which are useful for general installation out of usmqe-setup into tendrl ansible project. I hope this description helps to shed some light to the situation. [1] https://usmqe-tests.readthedocs.io/en/latest/usmqe_team.html -- Martin Bukatovic USM QE team Red Hat From julim at redhat.com Thu Jul 20 02:51:57 2017 From: julim at redhat.com (Ju Lim) Date: Wed, 19 Jul 2017 22:51:57 -0400 Subject: [Tendrl-devel] Tendrl Community update - Governance In-Reply-To: References: Message-ID: >> https://github.com/Tendrl/ui (current and future content need to be >> sent as PRs to Tendrl/dashboard and the upcoming metrics/monitoring >> dashboard) > This list of all UI design maintained by Ju is very useful, for all > groups involved and I guess we all agree with that. But the suggestion > to move the list of ux designs somewhere else, where Ju would have to > create pull request first makes me puzzled for the following reasons: > 1) The proposal suggests to split the list of ui designs into multiple > places, while I think that there is a value in having this in a *single > place*. Even when we will have 2 different types of ui - tendrl web and > grafana dashboard, keeping it on a single place would for example make > easier to plan which grafana dashboards should be linked from where. > Needles to say that single place is easier to search, review and > maintain. > 2) Asking Ju to create a pull request when she completes a ui design > in a different repository would prevent her to maintain the list > efficiently - what is the reasoning behind this? > If the problem is the fact that this ui design list is placed in > repository among other tendrl repositories on tendrl github group, > we could think about moving this overview of ui design into wiki page > in https://github.com/Tendrl/documentation/wiki > This way, Ju could maintain the list as she does now, but in a wiki > page (so that it would be hopefully as easy or easier compared to > current situation), all the others still have the list of designs > to refer to and we solve the problem with the repo. +1 to what MartinB has stated. Using PR's is cumbersome as this would create multiple PR's for a workflow, or a feature, etc. It will potentially break telling the end-to-end workflow or UX. I'm fine with switching from the .adoc we've been maintaining to a wiki if that's easier. I think we may want to consider having 2 repos for the Dashboard -- one for the native Tendrl UI and the other for the Grafana dashboards. Reason is if we allow for a grafana dashboards (aka glustermetrics), it will allow for users to stand this up separately if that is all they wish and potentially allow for those specific contributions. Let's discuss this in an upcoming meeting. Thank you, Ju On Wed, Jul 19, 2017 at 11:33 AM, Martin Bukatovic wrote: > On 07/15/2017 08:49 PM, Rohan Kanade wrote: > > Pleased to share updates from Tendrl core team related to Governance > > structure of Tendrl community > > > > Link: > > https://github.com/Tendrl/documentation/wiki/Tendrl- > Governance-and-Community > > When it comes to the unsupported repos (the last section in the > Governance wikipage linked above), I have the following notes. > > Repositories with usmqe- prefix are maintained by usmqe team[1] and > the question is whether to rename them or to move them out of Tendrl > github organization. And I guess that the decision will boil down > the a question what do we understand by *adaptation to Tendrl repo > best practices*. > > The other point I would like to raise here is suggestion to merge > usmqe-setup with tendrl-ansible doesn't make sense, because the > purpose and focus of these two repositories is very different: > > * tendrl-ansible is official part of tendrl project, following the > tendrl branching model and will be part of next upstream release. > The purpose of this repository is to automate tendrl installation > based on tendrl documentation, for others to install it either on > poc virtual machines or production. > > * usmqe-setup is not part of tendrl upstream release. The main > purpose of this repository is to automate qe related setup operations, > such as installation of qe tools, setup of qe infrastructure, > description of ci environment and test case setup. This has no > direct value for tendrl user. Some playbooks here uses roles > from tendrl-ansible - as there is no value in duplicating them. > > We actually did the opposite recently: we moved ansible roles which > are useful for general installation out of usmqe-setup into tendrl > ansible project. > > I hope this description helps to shed some light to the situation. > > [1] https://usmqe-tests.readthedocs.io/en/latest/usmqe_team.html > > -- > Martin Bukatovic > USM QE team > Red Hat > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > -- Ju Lim Red Hat Office: 978-399-0422 Mobile: 781-507-1323 Email: julim at redhat.com IRC: julim From rkanade at redhat.com Thu Jul 20 10:53:15 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Thu, 20 Jul 2017 16:23:15 +0530 Subject: [Tendrl-devel] Tendrl Community update - Governance In-Reply-To: References: Message-ID: UX designs are moved to https://github.com/Tendrl/documentation/wiki/Tendrl-UI-designs if a contributor wants to propose new UI changes to Tendrl they will have to create specification for the same at https://github.com/Tendrl/specifications Once the specification is implemented or in-progress, it will be listed on the above wiki page. On Thu, Jul 20, 2017 at 8:21 AM, Ju Lim wrote: > >> https://github.com/Tendrl/ui (current and future content need to be > >> sent as PRs to Tendrl/dashboard and the upcoming metrics/monitoring > >> dashboard) > > > This list of all UI design maintained by Ju is very useful, for all > > groups involved and I guess we all agree with that. But the suggestion > > to move the list of ux designs somewhere else, where Ju would have to > > create pull request first makes me puzzled for the following reasons: > > > 1) The proposal suggests to split the list of ui designs into multiple > > places, while I think that there is a value in having this in a *single > > place*. Even when we will have 2 different types of ui - tendrl web and > > grafana dashboard, keeping it on a single place would for example make > > easier to plan which grafana dashboards should be linked from where. > > Needles to say that single place is easier to search, review and > > maintain. > > > 2) Asking Ju to create a pull request when she completes a ui design > > in a different repository would prevent her to maintain the list > > efficiently - what is the reasoning behind this? > > > If the problem is the fact that this ui design list is placed in > > repository among other tendrl repositories on tendrl github group, > > we could think about moving this overview of ui design into wiki page > > in https://github.com/Tendrl/documentation/wiki > > This way, Ju could maintain the list as she does now, but in a wiki > > page (so that it would be hopefully as easy or easier compared to > > current situation), all the others still have the list of designs > > to refer to and we solve the problem with the repo. > > +1 to what MartinB has stated. Using PR's is cumbersome as this would > create multiple PR's for a workflow, or a feature, etc. It will > potentially break telling the end-to-end workflow or UX. I'm fine with > switching from the .adoc we've been maintaining to a wiki if that's easier. > > I think we may want to consider having 2 repos for the Dashboard -- one for > the native Tendrl UI and the other for the Grafana dashboards. Reason is > if we allow for a grafana dashboards (aka glustermetrics), it will allow > for users to stand this up separately if that is all they wish and > potentially allow for those specific contributions. > > Let's discuss this in an upcoming meeting. > > Thank you, > Ju > > > On Wed, Jul 19, 2017 at 11:33 AM, Martin Bukatovic > wrote: > > > On 07/15/2017 08:49 PM, Rohan Kanade wrote: > > > Pleased to share updates from Tendrl core team related to Governance > > > structure of Tendrl community > > > > > > Link: > > > https://github.com/Tendrl/documentation/wiki/Tendrl- > > Governance-and-Community > > > > When it comes to the unsupported repos (the last section in the > > Governance wikipage linked above), I have the following notes. > > > > Repositories with usmqe- prefix are maintained by usmqe team[1] and > > the question is whether to rename them or to move them out of Tendrl > > github organization. And I guess that the decision will boil down > > the a question what do we understand by *adaptation to Tendrl repo > > best practices*. > > > > The other point I would like to raise here is suggestion to merge > > usmqe-setup with tendrl-ansible doesn't make sense, because the > > purpose and focus of these two repositories is very different: > > > > * tendrl-ansible is official part of tendrl project, following the > > tendrl branching model and will be part of next upstream release. > > The purpose of this repository is to automate tendrl installation > > based on tendrl documentation, for others to install it either on > > poc virtual machines or production. > > > > * usmqe-setup is not part of tendrl upstream release. The main > > purpose of this repository is to automate qe related setup operations, > > such as installation of qe tools, setup of qe infrastructure, > > description of ci environment and test case setup. This has no > > direct value for tendrl user. Some playbooks here uses roles > > from tendrl-ansible - as there is no value in duplicating them. > > > > We actually did the opposite recently: we moved ansible roles which > > are useful for general installation out of usmqe-setup into tendrl > > ansible project. > > > > I hope this description helps to shed some light to the situation. > > > > [1] https://usmqe-tests.readthedocs.io/en/latest/usmqe_team.html > > > > -- > > Martin Bukatovic > > USM QE team > > Red Hat > > > > _______________________________________________ > > Tendrl-devel mailing list > > Tendrl-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/tendrl-devel > > > > > > -- > Ju Lim > Red Hat > Office: 978-399-0422 > Mobile: 781-507-1323 > Email: julim at redhat.com > IRC: julim > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > From rkanade at redhat.com Thu Jul 20 11:02:55 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Thu, 20 Jul 2017 16:32:55 +0530 Subject: [Tendrl-devel] Tendrl Community update - Governance In-Reply-To: References: Message-ID: On Wed, Jul 19, 2017 at 9:03 PM, Martin Bukatovic wrote: > On 07/15/2017 08:49 PM, Rohan Kanade wrote: > > Pleased to share updates from Tendrl core team related to Governance > > structure of Tendrl community > > > > Link: > > https://github.com/Tendrl/documentation/wiki/Tendrl- > Governance-and-Community > > When it comes to the unsupported repos (the last section in the > Governance wikipage linked above), I have the following notes. > > Repositories with usmqe- prefix are maintained by usmqe team[1] and > the question is whether to rename them or to move them out of Tendrl > github organization. And I guess that the decision will boil down > the a question what do we understand by *adaptation to Tendrl repo > best practices*. > These repos (usmqe*) came into existence when Tendrl had no concept of governance and community. These repositories are not approved by the Tendrl core team and would need to # Go through changes as required by Tendrl core team or # Move the repositories outside the Tendrl github organisation. > > The other point I would like to raise here is suggestion to merge > usmqe-setup with tendrl-ansible doesn't make sense, because the > purpose and focus of these two repositories is very different: > > * tendrl-ansible is official part of tendrl project, following the > tendrl branching model and will be part of next upstream release. > The purpose of this repository is to automate tendrl installation > based on tendrl documentation, for others to install it either on > poc virtual machines or production. > > * usmqe-setup is not part of tendrl upstream release. The main > purpose of this repository is to automate qe related setup operations, > such as installation of qe tools, setup of qe infrastructure, > description of ci environment and test case setup. This has no > direct value for tendrl user. Some playbooks here uses roles > from tendrl-ansible - as there is no value in duplicating them. > > We actually did the opposite recently: we moved ansible roles which > are useful for general installation out of usmqe-setup into tendrl > ansible project. > > I hope this description helps to shed some light to the situation. > > [1] https://usmqe-tests.readthedocs.io/en/latest/usmqe_team.html > > -- > Martin Bukatovic > USM QE team > Red Hat > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > From mbukatov at redhat.com Thu Jul 20 13:13:28 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 20 Jul 2017 15:13:28 +0200 Subject: [Tendrl-devel] Tendrl Community update - Governance In-Reply-To: References: Message-ID: <89c7f5f9-ac54-97de-163b-bb2238902b7a@redhat.com> On 07/20/2017 01:02 PM, Rohan Kanade wrote: > These repos (usmqe*) came into existence when Tendrl had no concept of > governance and community. These repositories are not approved by the Tendrl > core team and would need to # Go through changes as required by Tendrl core > team or # Move the repositories outside the Tendrl github organisation. Ok, understood, I would go with moving for now to reach expected state across all Tendrl repositories faster, avoiding disruption in the near future. But still I need to have this discussed with other people from our team and then coordinate the move with Daniel, otherwise we would risk breaking our existing scripts and ci. I will let you know next week, when both Martin and Daniel are back from pto. -- Martin Bukatovic USM QE team Red Hat From julim at redhat.com Thu Jul 20 21:06:35 2017 From: julim at redhat.com (Ju Lim) Date: Thu, 20 Jul 2017 17:06:35 -0400 Subject: [Tendrl-devel] UX design published - initial onboarding experience after tendrl-ansible executed Message-ID: Hi. Per the recommended suggestion by Rohan K., we've published our latest designs by creating a spec/PR/issue in https://github.com/Tendrl/specifications: - Initial onboarding experience for user accessing Tendrl UI ( https://github.com/Tendrl/specifications/issues/200) We?ve put together 2 design proposals with varying navigation that focuses on the UI and user experience for what happens after the user has run tendrl-ansible and logs into the Tendrl UI. Both designs are focused solely on Monitoring for Gluster (though the design concepts conveyed will translate well for other storage subsystems, e.g. Ceph). Key highlights of the designs include the following: - addresses handling errors/failures related to misconfigured tendrl-ansible failed Import Cluster (dialog with messages and host list) - Import cluster - enabling / disable volume profiling during Import Cluster (cluster-wide) and at the volume level - indicate where the ?Launch Dashboard? (link-n-launch to Grafana) buttons would be located - provide an element manager (single-cluster) focused navigation via 2 different design proposals, which includes updates to the navigation: - Concept A: Multi-Level Drill Down (re-uses existing design elements and implementation) - Concept B: Context Selector Navigation (optimizes the navigation and emphasizes the single cluster management/monitoring experience) - Removed all CRUD actions (buttons) - updated rebalance column in the Volumes list to be more monitoring focused (without the CRUD controls) - added SNMPv3 configuration The reason for 2 design proposals (they differ based on navigation) is one design attempts to re-use as many of the existing design and implementation assets (Concept A: Multi-Level Drill Down) but has some drawbacks. The alternate design (Concept B: Context Selector Navigation) addresses the drawbacks encountered with Concept A and emphasizes a cluster-centric user experience. Comments are welcome -- whether in Invision (see Invision links above) and/or GitHub (https://github.com/Tendrl/specifications/issues/200). Thank you, Ju & Matt From mrugesh at brainfunked.org Tue Jul 25 02:25:49 2017 From: mrugesh at brainfunked.org (Mrugesh Karnik) Date: Tue, 25 Jul 2017 07:55:49 +0530 Subject: [Tendrl-devel] [IMPORTANT] Milestones and spec reviews Message-ID: All, All the spec issues have been filed for the upcoming milestones. Please take a look at the milestones page[1]. Each individual milestone links to the relevant spec issues. Some of the spec issues have received a corresponding pull request for the actual spec. All contributors are requested to review all the possible specs. Only the mandatory reviewers are marked explicitly as reviewers. Thanks. [1] https://github.com/Tendrl/specifications/milestones?direction=asc&sort=due_date&state=open -- Mrugesh From mbukatov at redhat.com Thu Jul 27 16:19:16 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 27 Jul 2017 18:19:16 +0200 Subject: [Tendrl-devel] Tendrl Community update - Governance In-Reply-To: <89c7f5f9-ac54-97de-163b-bb2238902b7a@redhat.com> References: <89c7f5f9-ac54-97de-163b-bb2238902b7a@redhat.com> Message-ID: <3972d51e-dc57-115e-f401-34809388a6d4@redhat.com> On 07/20/2017 03:13 PM, Martin Bukatovic wrote: > I will let you know next week, when both Martin and Daniel are back from > pto. We will do the move tomorrow (on Friday 28th). -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Fri Jul 28 13:57:33 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 28 Jul 2017 15:57:33 +0200 Subject: [Tendrl-devel] usmqe repositories moved from Tendrl group Message-ID: Dear all, based on discussion with Rohan (see also [1]), we moved following usmqe repositories from Tendrl github group: * usmqe-tests * usmqe-setup * usmqe-centos-ci into separate github group here: https://github.com/usmqe Changes has been made to related configuration of: * travis ci * readthedocs * centos ci jobs so that the move is now complete. [1] https://github.com/Tendrl/documentation/wiki/Tendrl-Governance-and-Community -- Martin Bukatovic USM QE team Red Hat From anivargi at redhat.com Fri Jul 28 14:06:28 2017 From: anivargi at redhat.com (Anup Nivargi) Date: Fri, 28 Jul 2017 10:06:28 -0400 (EDT) Subject: [Tendrl-devel] Status summary of monitoring dashboards with Grafana In-Reply-To: <1358686307.31139152.1501247249041.JavaMail.zimbra@redhat.com> Message-ID: <985675096.31154094.1501250788327.JavaMail.zimbra@redhat.com> Hi all, We have made progress on using Grafana[1] as the default monitoring dashboard in Tendrl. Following is the summary of components and actions possible on dashboard: - Graphs for nodes stats like memory, cpu, storage and swap usage. These stats are collected using collectd plugins - Graphs for volumes and bricks stats which are collected using Gluster get-state - Multi cluster navigation - Node navigation within a cluster - Volumes navigation within a cluster - Bricks navigation within a cluster We have a initial PR[2] under review for the monitoring-integration component, which will be used to populate the default dashboards on any Grafana instance. The README contains installation instructions on its usage. Details about the metrics can be found at wiki[3]. The wiki contains list of metrics and screenshots for reference. Note that the wiki is still WIP and needs to be updated with what is currently implemented and what will be implemented per milestone. [1] https://grafana.com/ [2] https://github.com/Tendrl/monitoring-integration/pull/1 [3] https://github.com/Tendrl/documentation/wiki/Metrics -Anup Nivargi From jefbrown at redhat.com Fri Jul 28 14:12:54 2017 From: jefbrown at redhat.com (Jeff Brown) Date: Fri, 28 Jul 2017 10:12:54 -0400 Subject: [Tendrl-devel] Status summary of monitoring dashboards with Grafana In-Reply-To: <985675096.31154094.1501250788327.JavaMail.zimbra@redhat.com> References: <1358686307.31139152.1501247249041.JavaMail.zimbra@redhat.com> <985675096.31154094.1501250788327.JavaMail.zimbra@redhat.com> Message-ID: Thanks Anup. On Fri, Jul 28, 2017 at 10:06 AM, Anup Nivargi wrote: > Hi all, > > We have made progress on using Grafana[1] as the default monitoring > dashboard in Tendrl. > > Following is the summary of components and actions possible on dashboard: > > - Graphs for nodes stats like memory, cpu, storage and swap usage. These > stats are collected using collectd plugins > - Graphs for volumes and bricks stats which are collected using Gluster > get-state > - Multi cluster navigation > - Node navigation within a cluster > - Volumes navigation within a cluster > - Bricks navigation within a cluster > > We have a initial PR[2] under review for the monitoring-integration > component, which will be used to populate the default dashboards on any > Grafana instance. > The README contains installation instructions on its usage. > > Details about the metrics can be found at wiki[3]. The wiki contains list > of metrics and screenshots for reference. > Note that the wiki is still WIP and needs to be updated with what is > currently implemented and what will be implemented per milestone. > > [1] https://grafana.com/ > [2] https://github.com/Tendrl/monitoring-integration/pull/1 > [3] https://github.com/Tendrl/documentation/wiki/Metrics > > > -Anup Nivargi > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel >