From dahorak at redhat.com Mon Sep 4 08:34:34 2017 From: dahorak at redhat.com (=?UTF-8?Q?Daniel_Hor=c3=a1k?=) Date: Mon, 4 Sep 2017 10:34:34 +0200 Subject: [Tendrl-devel] Historical data for graphs in Grafana older than 24 hours? Message-ID: <56c138c1-d664-0173-aa30-696b1f3b3a99@redhat.com> Hi all, What's the default time for keeping historical data for graphs in Grafana? (for example Throughput Trend, Ping Latency Trend, Memory, CPU, Swap, Capacity Utilization Trend and others) I have two clusters running over the weekend (one running for more than 4 days, the second one for more than 3 days), but if I'll try to "Zoom Out" any graph (or set the Time Range for 2 or 7 days), it shows graph only for last 24 hours. The same apply for graphs in Graphite, no matter how long date range I'll select, it shows only last 24 hours. Is this expected behavior? If yes, I thing we should reconsider the respective decision, because most of the graphs doesn't make much sense for such short period. If no, I'll create issue for the monitoring-integration component. Thanks, Daniel From mkudlej at redhat.com Wed Sep 6 13:20:19 2017 From: mkudlej at redhat.com (Martin Kudlej) Date: Wed, 6 Sep 2017 15:20:19 +0200 Subject: [Tendrl-devel] How to find agreed implementation for one of milestone 2 feature Message-ID: Hi all, I've tested user list feature which should be and is implemented in milestone 2, see https://docs.google.com/document/d/1TUSa0Ik-nWW9DtDRvK6lJ9U2e2qkgIEyDm7U20vIJBg/edit?pli=1 During testing I need to compare real design implementation with agreed design, so I've look at design document related to user list, see https://github.com/Tendrl/documentation/wiki/Tendrl-UI-Designs-for-Gluster-Only-Monitoring-Release and design https://redhat.invisionapp.com/share/8QCOEVEY9#/screens/244738633 I've found one difference (missing user status - enabled/disabled) so I've filed issue https://github.com/Tendrl/ui/issues/556 . In the related issue Nishanth's stated https://github.com/Tendrl/api/issues/238 that enabling/disabling will not be implemented and this was already decided. I'm not able to find this change in design document or in any related issue/spec: https://github.com/Tendrl/specifications/issues/176 https://github.com/Tendrl/specifications/issues/200 https://github.com/Tendrl/specifications/issues/227 https://github.com/Tendrl/specifications/pull/235 https://github.com/Tendrl/specifications/pull/237 https://github.com/Tendrl/specifications/pull/238 https://github.com/Tendrl/specifications/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20user Also I cannot find any mock-up for user list so I expect that implementation should be done exactly according design document. I would like to ask couple of questions: 1. Is there any change in workflow? 2. What pieces should I put together to find design which I can compare with implementation? 3. I've thought that design documents from wiki can be used for testing and in case of any change there is linked PR. Is there any change in this? 4. Somebody has mentioned that all last changes are reflected in API documentation. But I think that design cannot be tested according API documentation. Could anybody explain this more, please? Also I would like to ask to publish link to record of today Daily meeting of Tendrl developers (BJ ID 223603813) where we have discussed these topics so we can play it again and try to work according recommendations mentioned during meeting. Thank you for answers and for sharing link to download today meeting! -- 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 dahorak at redhat.com Thu Sep 7 09:23:38 2017 From: dahorak at redhat.com (=?UTF-8?Q?Daniel_Hor=c3=a1k?=) Date: Thu, 7 Sep 2017 11:23:38 +0200 Subject: [Tendrl-devel] Gluster Volume Profiling questions Message-ID: Hi All, I have bunch of questions and potentially issues related to Gluster Volume Profiling. I've unsuccessfully tried to find some specification, so please redirect me to the right link, if some of my questions are already answered somewhere. Profiling is Volume specific configuration, but Tendrl web UI displays it as cluster level information (Volume Profile column on Clusters page) - what that should means? For example what it should display, if profiling will be started on one volume and stopped on second volume? Should the information reflect actual state as it is configured in Gluster (so it will change, when I'll start/stop profiling via `gluster volume profile` command) or only the theoretical state configured by Tendrl? What have higher priority - configuration via `gluster volume profile` command or via Tendrl? Or the last change, no mater where it was initiated? When I'll import cluster to Tendrl I'm able to switch Profiling on and off few times via Tendrl web UI and it seems to be reflected correctly in gluster, but later, when I'll change it in Tendrl, there is no change in gluster. How/where can I debug the problem? Why the state is changed in Tendrl but not in gluster? Also when I'll click to Enable or Disable Profiling, message "Volume profiling updated successfully." is shown quite immediately, but the state in gluster is changed after some delay (sometime after tens of seconds). Thanks, Daniel From shtripat at redhat.com Thu Sep 7 11:06:52 2017 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Thu, 7 Sep 2017 16:36:52 +0530 Subject: [Tendrl-devel] Gluster Volume Profiling questions In-Reply-To: References: Message-ID: Hi Daniel, Find below few comments inline -- >> Profiling is Volume specific configuration, but Tendrl web UI displays it as cluster level information (Volume Profile column on Clusters page) - what that should means? Tendrl supports enable/disable of volume profiling at cluster level only. While import cluster if admin selects to enable profiling, during cluster sync, for all the volumes, the profiling would be enabled. If admin selects not to have profiling enabled for the volumes, it wont be enabled. >> For example what it should display, if profiling will be started on one volume and stopped on second volume? If volume profiling is enabled for selective volumes from CLI and then the cluster is enabled (say with profiling de-selected in UI) the cluster level field would be set as `False` and while syncing the volumes, get-state doesnt report any details about profiling so actually no action at volume level. >> Should the information reflect actual state as it is configured in Gluster (so it will change, when I'll start/stop profiling via `gluster volume profile` command) or only the theoretical state configured by Tendrl? If you toggle between the profiling enabled/disable for individual volumes from CLI, there is no change in tendrl central store as part of sync. If the cluster is maintained by Tendrl, admin should use enable/disable option from UI for profling and this would enable/disable profiling for all the volumes in the cluster. >> What have higher priority - configuration via `gluster volume profile` command or via Tendrl? Or the last change, no mater where it was initiated? So the logic is like if `cluster.enable_volume_profling` is set as `yes` for cluster, while syncing the cluster details for each volume, it checks if `profiling_enabled` is un-set. If so it enables profiling for the volumes and sets this flag (so that next sync we don't try to set it again). There is no other way around. If from CLI profiling is set for a specific volume, there is way way to identify that and set in tendrl central store. >> When I'll import cluster to Tendrl I'm able to switch Profiling on and off few times via Tendrl web UI and it seems to be reflected correctly in gluster, but later, when I'll change it in Tendrl, there is no change in gluster. How/where can I debug the problem? Why the state is changed in Tendrl but not in gluster? You need to look for any errors in the flow. Also take a note that, when you say disable profiling for a cluster, it actually sets the cluster level flag `enable_volume_profling` to `yes` and while next sync only the required changes would be taken care. So if you do this back to back, sometimes before next sync is triggered you might not see the changes in effect at CLI. But I would suggest to check for errors as well for the jobs. >> Also when I'll click to Enable or Disable Profiling, message "Volume profiling updated successfully." is shown quite immediately, but the state in gluster is changed after some delay (sometime after tens of seconds). As mentioned above this flow changes the flag only at cluster level and next round of sync does the actual enable/disable of profiling for the volumes. May be the message is confusing. In that case I would suggest UX to suggest a better sentence to report that, volume profiling flag is set for the cluster, and next sync would enable/disable accordingly. Hope I have answered the questions but would request others as well to comment if something missing here. Thanks and Regards, Shubhendu On Thu, Sep 7, 2017 at 2:53 PM, Daniel Hor?k wrote: > Hi All, > I have bunch of questions and potentially issues related to Gluster Volume > Profiling. > > I've unsuccessfully tried to find some specification, so please redirect > me to the right link, if some of my questions are already answered > somewhere. > > Profiling is Volume specific configuration, but Tendrl web UI displays it > as cluster level information (Volume Profile column on Clusters page) - > what that should means? > For example what it should display, if profiling will be started on one > volume and stopped on second volume? > > Should the information reflect actual state as it is configured in Gluster > (so it will change, when I'll start/stop profiling via `gluster volume > profile` command) or only the theoretical state configured by Tendrl? > > What have higher priority - configuration via `gluster volume profile` > command or via Tendrl? Or the last change, no mater where it was initiated? > > When I'll import cluster to Tendrl I'm able to switch Profiling on and off > few times via Tendrl web UI and it seems to be reflected correctly in > gluster, but later, when I'll change it in Tendrl, there is no change in > gluster. How/where can I debug the problem? Why the state is changed in > Tendrl but not in gluster? > > Also when I'll click to Enable or Disable Profiling, message "Volume > profiling updated successfully." is shown quite immediately, but the state > in gluster is changed after some delay (sometime after tens of seconds). > > Thanks, > Daniel > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > From shtripat at redhat.com Thu Sep 7 11:11:43 2017 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Thu, 7 Sep 2017 16:41:43 +0530 Subject: [Tendrl-devel] Gluster Volume Profiling questions In-Reply-To: References: Message-ID: Small typo correction >> there is way way to identify that and set in tendrl central store. there is no way to identify that and set in tendrl central store. Sorry for the inconvenience. On Thu, Sep 7, 2017 at 4:36 PM, Shubhendu Tripathi wrote: > Hi Daniel, > > Find below few comments inline -- > > >> Profiling is Volume specific configuration, but Tendrl web UI displays > it as cluster level information (Volume Profile column on Clusters page) - > what that should means? > > Tendrl supports enable/disable of volume profiling at cluster level only. > While import cluster if admin selects to enable profiling, during cluster > sync, for all the volumes, the profiling would be enabled. If admin selects > not to have profiling enabled for the volumes, it wont be enabled. > > >> For example what it should display, if profiling will be started on > one volume and stopped on second volume? > > If volume profiling is enabled for selective volumes from CLI and then the > cluster is enabled (say with profiling de-selected in UI) the cluster level > field would be set as `False` and while syncing the volumes, get-state > doesnt report any details about profiling so actually no action at volume > level. > > >> Should the information reflect actual state as it is configured in > Gluster (so it will change, when I'll start/stop profiling via `gluster > volume profile` command) or only the theoretical state configured by Tendrl? > > If you toggle between the profiling enabled/disable for individual volumes > from CLI, there is no change in tendrl central store as part of sync. If > the cluster is maintained by Tendrl, admin should use enable/disable option > from UI for profling and this would enable/disable profiling for all the > volumes in the cluster. > > >> What have higher priority - configuration via `gluster volume profile` > command or via Tendrl? Or the last change, no mater where it was initiated? > > So the logic is like if `cluster.enable_volume_profling` is set as `yes` > for cluster, while syncing the cluster details for each volume, it checks > if `profiling_enabled` is un-set. If so it enables profiling for the > volumes and sets this flag (so that next sync we don't try to set it > again). There is no other way around. If from CLI profiling is set for a > specific volume, there is way way to identify that and set in tendrl > central store. > > >> When I'll import cluster to Tendrl I'm able to switch Profiling on and > off few times via Tendrl web UI and it seems to be reflected correctly in > gluster, but later, when I'll change it in Tendrl, there is no change in > gluster. How/where can I debug the problem? Why the state is changed in > Tendrl but not in gluster? > > You need to look for any errors in the flow. Also take a note that, when > you say disable profiling for a cluster, it actually sets the cluster level > flag `enable_volume_profling` to `yes` and while next sync only the > required changes would be taken care. So if you do this back to back, > sometimes before next sync is triggered you might not see the changes in > effect at CLI. But I would suggest to check for errors as well for the jobs. > > >> Also when I'll click to Enable or Disable Profiling, message "Volume > profiling updated successfully." is shown quite immediately, but the state > in gluster is changed after some delay (sometime after tens of seconds). > > As mentioned above this flow changes the flag only at cluster level and > next round of sync does the actual enable/disable of profiling for the > volumes. May be the message is confusing. In that case I would suggest UX > to suggest a better sentence to report that, volume profiling flag is set > for the cluster, and next sync would enable/disable accordingly. > > Hope I have answered the questions but would request others as well to > comment if something missing here. > > Thanks and Regards, > Shubhendu > > On Thu, Sep 7, 2017 at 2:53 PM, Daniel Hor?k wrote: > >> Hi All, >> I have bunch of questions and potentially issues related to Gluster >> Volume Profiling. >> >> I've unsuccessfully tried to find some specification, so please redirect >> me to the right link, if some of my questions are already answered >> somewhere. >> >> Profiling is Volume specific configuration, but Tendrl web UI displays it >> as cluster level information (Volume Profile column on Clusters page) - >> what that should means? >> For example what it should display, if profiling will be started on one >> volume and stopped on second volume? >> >> Should the information reflect actual state as it is configured in >> Gluster (so it will change, when I'll start/stop profiling via `gluster >> volume profile` command) or only the theoretical state configured by Tendrl? >> >> What have higher priority - configuration via `gluster volume profile` >> command or via Tendrl? Or the last change, no mater where it was initiated? >> >> When I'll import cluster to Tendrl I'm able to switch Profiling on and >> off few times via Tendrl web UI and it seems to be reflected correctly in >> gluster, but later, when I'll change it in Tendrl, there is no change in >> gluster. How/where can I debug the problem? Why the state is changed in >> Tendrl but not in gluster? >> >> Also when I'll click to Enable or Disable Profiling, message "Volume >> profiling updated successfully." is shown quite immediately, but the state >> in gluster is changed after some delay (sometime after tens of seconds). >> >> Thanks, >> Daniel >> >> _______________________________________________ >> Tendrl-devel mailing list >> Tendrl-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/tendrl-devel >> > > From dahorak at redhat.com Thu Sep 7 13:59:40 2017 From: dahorak at redhat.com (=?UTF-8?Q?Daniel_Hor=c3=a1k?=) Date: Thu, 7 Sep 2017 15:59:40 +0200 Subject: [Tendrl-devel] python-ruamel-yaml issues - backport fix to release 1.5.1 branch? Message-ID: Hi, would it be possible to backport following two PRs to release/1.5.1 branch? https://github.com/Tendrl/commons/pull/706 https://github.com/Tendrl/monitoring-integration/pull/56 Because python-ruamel-yaml package was removed from dependencies branch (which is ok) but the version from epel provides only python2-ruamel-yaml so now it is not possible to install release 1.5.1 version of Tendrl. I'm not sure, if there is any other possible solution for this issue, this seems to me like the best one. Thanks, Daniel From dahorak at redhat.com Thu Sep 7 14:01:26 2017 From: dahorak at redhat.com (=?UTF-8?Q?Daniel_Hor=c3=a1k?=) Date: Thu, 7 Sep 2017 16:01:26 +0200 Subject: [Tendrl-devel] Gluster Volume Profiling questions In-Reply-To: References: Message-ID: <747314fa-2570-e4e2-db0a-0026dcc37e59@redhat.com> Thanks Shubhendu for your comprehensive answer! I have few supplemental and extensional questions, to be sure that I understand it well. Whenever I'll enable (or disable) the Volume Profiling in Tendrl, after some time all the volumes in the respective cluster should reflect the desired state, no matter if the profiling was previously enabled or disabled. In other words, changing the state from Tendrl will initiate check if all the volumes are in correct state. Did I understand it correctly? And how it should be with newly created volume? Should it automatically reflect the state configured in Tendrl? Thanks, Daniel On 09/07/17 13:11, Shubhendu Tripathi wrote: > Small typo correction > >>> there is way way to identify that and set in tendrl central store. > > there is no way to identify that and set in tendrl central store. > > Sorry for the inconvenience. > > On Thu, Sep 7, 2017 at 4:36 PM, Shubhendu Tripathi > wrote: > >> Hi Daniel, >> >> Find below few comments inline -- >> >>>> Profiling is Volume specific configuration, but Tendrl web UI displays >> it as cluster level information (Volume Profile column on Clusters page) - >> what that should means? >> >> Tendrl supports enable/disable of volume profiling at cluster level only. >> While import cluster if admin selects to enable profiling, during cluster >> sync, for all the volumes, the profiling would be enabled. If admin selects >> not to have profiling enabled for the volumes, it wont be enabled. >> >>>> For example what it should display, if profiling will be started on >> one volume and stopped on second volume? >> >> If volume profiling is enabled for selective volumes from CLI and then the >> cluster is enabled (say with profiling de-selected in UI) the cluster level >> field would be set as `False` and while syncing the volumes, get-state >> doesnt report any details about profiling so actually no action at volume >> level. >> >>>> Should the information reflect actual state as it is configured in >> Gluster (so it will change, when I'll start/stop profiling via `gluster >> volume profile` command) or only the theoretical state configured by Tendrl? >> >> If you toggle between the profiling enabled/disable for individual volumes >> from CLI, there is no change in tendrl central store as part of sync. If >> the cluster is maintained by Tendrl, admin should use enable/disable option >> from UI for profling and this would enable/disable profiling for all the >> volumes in the cluster. >> >>>> What have higher priority - configuration via `gluster volume profile` >> command or via Tendrl? Or the last change, no mater where it was initiated? >> >> So the logic is like if `cluster.enable_volume_profling` is set as `yes` >> for cluster, while syncing the cluster details for each volume, it checks >> if `profiling_enabled` is un-set. If so it enables profiling for the >> volumes and sets this flag (so that next sync we don't try to set it >> again). There is no other way around. If from CLI profiling is set for a >> specific volume, there is way way to identify that and set in tendrl >> central store. >> >>>> When I'll import cluster to Tendrl I'm able to switch Profiling on and >> off few times via Tendrl web UI and it seems to be reflected correctly in >> gluster, but later, when I'll change it in Tendrl, there is no change in >> gluster. How/where can I debug the problem? Why the state is changed in >> Tendrl but not in gluster? >> >> You need to look for any errors in the flow. Also take a note that, when >> you say disable profiling for a cluster, it actually sets the cluster level >> flag `enable_volume_profling` to `yes` and while next sync only the >> required changes would be taken care. So if you do this back to back, >> sometimes before next sync is triggered you might not see the changes in >> effect at CLI. But I would suggest to check for errors as well for the jobs. >> >>>> Also when I'll click to Enable or Disable Profiling, message "Volume >> profiling updated successfully." is shown quite immediately, but the state >> in gluster is changed after some delay (sometime after tens of seconds). >> >> As mentioned above this flow changes the flag only at cluster level and >> next round of sync does the actual enable/disable of profiling for the >> volumes. May be the message is confusing. In that case I would suggest UX >> to suggest a better sentence to report that, volume profiling flag is set >> for the cluster, and next sync would enable/disable accordingly. >> >> Hope I have answered the questions but would request others as well to >> comment if something missing here. >> >> Thanks and Regards, >> Shubhendu >> >> On Thu, Sep 7, 2017 at 2:53 PM, Daniel Hor?k wrote: >> >>> Hi All, >>> I have bunch of questions and potentially issues related to Gluster >>> Volume Profiling. >>> >>> I've unsuccessfully tried to find some specification, so please redirect >>> me to the right link, if some of my questions are already answered >>> somewhere. >>> >>> Profiling is Volume specific configuration, but Tendrl web UI displays it >>> as cluster level information (Volume Profile column on Clusters page) - >>> what that should means? >>> For example what it should display, if profiling will be started on one >>> volume and stopped on second volume? >>> >>> Should the information reflect actual state as it is configured in >>> Gluster (so it will change, when I'll start/stop profiling via `gluster >>> volume profile` command) or only the theoretical state configured by Tendrl? >>> >>> What have higher priority - configuration via `gluster volume profile` >>> command or via Tendrl? Or the last change, no mater where it was initiated? >>> >>> When I'll import cluster to Tendrl I'm able to switch Profiling on and >>> off few times via Tendrl web UI and it seems to be reflected correctly in >>> gluster, but later, when I'll change it in Tendrl, there is no change in >>> gluster. How/where can I debug the problem? Why the state is changed in >>> Tendrl but not in gluster? >>> >>> Also when I'll click to Enable or Disable Profiling, message "Volume >>> profiling updated successfully." is shown quite immediately, but the state >>> in gluster is changed after some delay (sometime after tens of seconds). >>> >>> 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 shtripat at redhat.com Fri Sep 8 05:32:05 2017 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Fri, 8 Sep 2017 11:02:05 +0530 Subject: [Tendrl-devel] Gluster Volume Profiling questions In-Reply-To: <747314fa-2570-e4e2-db0a-0026dcc37e59@redhat.com> References: <747314fa-2570-e4e2-db0a-0026dcc37e59@redhat.com> Message-ID: >> Whenever I'll enable (or disable) the Volume Profiling in Tendrl, after some time all the volumes in the respective cluster should reflect the desired state, no matter if the profiling was previously enabled or disabled. In other words, changing the state from Tendrl will initiate check if all the volumes are in correct state. Did I understand it correctly? If we enable / disable profiling from tendrl UI, the underlying cluster volumes would get it enabled/disabled accordingly in next sync cycle. >> And how it should be with newly created volume? Should it automatically reflect the state configured in Tendrl? For newly created volumes, next sync cycle would figure out that for few volumes, profiling is still not on and it would do the needful to enable the same. Regards, Shubhendu On Thu, Sep 7, 2017 at 7:31 PM, Daniel Hor?k wrote: > Thanks Shubhendu for your comprehensive answer! > > I have few supplemental and extensional questions, to be sure that I > understand it well. > > Whenever I'll enable (or disable) the Volume Profiling in Tendrl, after > some time all the volumes in the respective cluster should reflect the > desired state, no matter if the profiling was previously enabled or > disabled. In other words, changing the state from Tendrl will initiate > check if all the volumes are in correct state. Did I understand it > correctly? > > And how it should be with newly created volume? Should it automatically > reflect the state configured in Tendrl? > > Thanks, > Daniel > > > > On 09/07/17 13:11, Shubhendu Tripathi wrote: > >> Small typo correction >> >> there is way way to identify that and set in tendrl central store. >>>> >>> >> there is no way to identify that and set in tendrl central store. >> >> Sorry for the inconvenience. >> >> On Thu, Sep 7, 2017 at 4:36 PM, Shubhendu Tripathi >> wrote: >> >> Hi Daniel, >>> >>> Find below few comments inline -- >>> >>> Profiling is Volume specific configuration, but Tendrl web UI displays >>>>> >>>> it as cluster level information (Volume Profile column on Clusters >>> page) - >>> what that should means? >>> >>> Tendrl supports enable/disable of volume profiling at cluster level only. >>> While import cluster if admin selects to enable profiling, during cluster >>> sync, for all the volumes, the profiling would be enabled. If admin >>> selects >>> not to have profiling enabled for the volumes, it wont be enabled. >>> >>> For example what it should display, if profiling will be started on >>>>> >>>> one volume and stopped on second volume? >>> >>> If volume profiling is enabled for selective volumes from CLI and then >>> the >>> cluster is enabled (say with profiling de-selected in UI) the cluster >>> level >>> field would be set as `False` and while syncing the volumes, get-state >>> doesnt report any details about profiling so actually no action at volume >>> level. >>> >>> Should the information reflect actual state as it is configured in >>>>> >>>> Gluster (so it will change, when I'll start/stop profiling via `gluster >>> volume profile` command) or only the theoretical state configured by >>> Tendrl? >>> >>> If you toggle between the profiling enabled/disable for individual >>> volumes >>> from CLI, there is no change in tendrl central store as part of sync. If >>> the cluster is maintained by Tendrl, admin should use enable/disable >>> option >>> from UI for profling and this would enable/disable profiling for all the >>> volumes in the cluster. >>> >>> What have higher priority - configuration via `gluster volume profile` >>>>> >>>> command or via Tendrl? Or the last change, no mater where it was >>> initiated? >>> >>> So the logic is like if `cluster.enable_volume_profling` is set as `yes` >>> for cluster, while syncing the cluster details for each volume, it checks >>> if `profiling_enabled` is un-set. If so it enables profiling for the >>> volumes and sets this flag (so that next sync we don't try to set it >>> again). There is no other way around. If from CLI profiling is set for a >>> specific volume, there is way way to identify that and set in tendrl >>> central store. >>> >>> When I'll import cluster to Tendrl I'm able to switch Profiling on and >>>>> >>>> off few times via Tendrl web UI and it seems to be reflected correctly >>> in >>> gluster, but later, when I'll change it in Tendrl, there is no change in >>> gluster. How/where can I debug the problem? Why the state is changed in >>> Tendrl but not in gluster? >>> >>> You need to look for any errors in the flow. Also take a note that, when >>> you say disable profiling for a cluster, it actually sets the cluster >>> level >>> flag `enable_volume_profling` to `yes` and while next sync only the >>> required changes would be taken care. So if you do this back to back, >>> sometimes before next sync is triggered you might not see the changes in >>> effect at CLI. But I would suggest to check for errors as well for the >>> jobs. >>> >>> Also when I'll click to Enable or Disable Profiling, message "Volume >>>>> >>>> profiling updated successfully." is shown quite immediately, but the >>> state >>> in gluster is changed after some delay (sometime after tens of seconds). >>> >>> As mentioned above this flow changes the flag only at cluster level and >>> next round of sync does the actual enable/disable of profiling for the >>> volumes. May be the message is confusing. In that case I would suggest UX >>> to suggest a better sentence to report that, volume profiling flag is set >>> for the cluster, and next sync would enable/disable accordingly. >>> >>> Hope I have answered the questions but would request others as well to >>> comment if something missing here. >>> >>> Thanks and Regards, >>> Shubhendu >>> >>> On Thu, Sep 7, 2017 at 2:53 PM, Daniel Hor?k wrote: >>> >>> Hi All, >>>> I have bunch of questions and potentially issues related to Gluster >>>> Volume Profiling. >>>> >>>> I've unsuccessfully tried to find some specification, so please redirect >>>> me to the right link, if some of my questions are already answered >>>> somewhere. >>>> >>>> Profiling is Volume specific configuration, but Tendrl web UI displays >>>> it >>>> as cluster level information (Volume Profile column on Clusters page) - >>>> what that should means? >>>> For example what it should display, if profiling will be started on one >>>> volume and stopped on second volume? >>>> >>>> Should the information reflect actual state as it is configured in >>>> Gluster (so it will change, when I'll start/stop profiling via `gluster >>>> volume profile` command) or only the theoretical state configured by >>>> Tendrl? >>>> >>>> What have higher priority - configuration via `gluster volume profile` >>>> command or via Tendrl? Or the last change, no mater where it was >>>> initiated? >>>> >>>> When I'll import cluster to Tendrl I'm able to switch Profiling on and >>>> off few times via Tendrl web UI and it seems to be reflected correctly >>>> in >>>> gluster, but later, when I'll change it in Tendrl, there is no change in >>>> gluster. How/where can I debug the problem? Why the state is changed in >>>> Tendrl but not in gluster? >>>> >>>> Also when I'll click to Enable or Disable Profiling, message "Volume >>>> profiling updated successfully." is shown quite immediately, but the >>>> state >>>> in gluster is changed after some delay (sometime after tens of seconds). >>>> >>>> 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 rkanade at redhat.com Fri Sep 8 07:43:51 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Fri, 8 Sep 2017 13:13:51 +0530 Subject: [Tendrl-devel] python-ruamel-yaml issues - backport fix to release 1.5.1 branch? In-Reply-To: References: Message-ID: Daniel, The 1.5.1 release is a milestone release and not the final release for 1.5.x, The last release of 1.5.x will be eligible for backports but not 1.5.1. The fixes you are requesting will be available in 1.5.2 and onward. On Thu, Sep 7, 2017 at 7:29 PM, Daniel Hor?k wrote: > Hi, > > would it be possible to backport following two PRs to release/1.5.1 branch? > > https://github.com/Tendrl/commons/pull/706 > https://github.com/Tendrl/monitoring-integration/pull/56 > > Because python-ruamel-yaml package was removed from dependencies branch > (which is ok) but the version from epel provides only python2-ruamel-yaml > so now it is not possible to install release 1.5.1 version of Tendrl. > > I'm not sure, if there is any other possible solution for this issue, this > seems to me like the best one. > > Thanks, > Daniel > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > From nthomas at redhat.com Fri Sep 8 11:21:36 2017 From: nthomas at redhat.com (Nishanth Thomas) Date: Fri, 8 Sep 2017 16:51:36 +0530 Subject: [Tendrl-devel] python-ruamel-yaml issues - backport fix to release 1.5.1 branch? In-Reply-To: References: Message-ID: Hi Daniel, We have copied back python-ruamel-yaml package into tendrl/dependencies repo so that you are unblocked. This will be removed after 1.5.2 is out Thanks, Nishanth On Fri, Sep 8, 2017 at 1:13 PM, Rohan Kanade wrote: > Daniel, > > The 1.5.1 release is a milestone release and not the final release for > 1.5.x, The last release of 1.5.x will be eligible for backports but not > 1.5.1. > > The fixes you are requesting will be available in 1.5.2 and onward. > > On Thu, Sep 7, 2017 at 7:29 PM, Daniel Hor?k wrote: > > > Hi, > > > > would it be possible to backport following two PRs to release/1.5.1 > branch? > > > > https://github.com/Tendrl/commons/pull/706 > > https://github.com/Tendrl/monitoring-integration/pull/56 > > > > Because python-ruamel-yaml package was removed from dependencies branch > > (which is ok) but the version from epel provides only python2-ruamel-yaml > > so now it is not possible to install release 1.5.1 version of Tendrl. > > > > I'm not sure, if there is any other possible solution for this issue, > this > > seems to me like the best one. > > > > 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 ltrilety at redhat.com Wed Sep 13 11:40:52 2017 From: ltrilety at redhat.com (Lubos Trilety) Date: Wed, 13 Sep 2017 07:40:52 -0400 (EDT) Subject: [Tendrl-devel] Gluster Volume Profiling questions In-Reply-To: References: Message-ID: <1163808020.14763790.1505302852860.JavaMail.zimbra@redhat.com> Hi Shubhendu, just a note. I hope that profiling per volume is still planned as https://redhat.invisionapp.com/share/8QCOEVEY9#/screens/247445416 states. Regards, Lubos ----- Original Message ----- From: "Shubhendu Tripathi" To: "Mailing list for the contributors to the Tendrl project" Sent: Thursday, September 7, 2017 1:06:52 PM Subject: Re: [Tendrl-devel] Gluster Volume Profiling questions Hi Daniel, Find below few comments inline -- >> Profiling is Volume specific configuration, but Tendrl web UI displays it as cluster level information (Volume Profile column on Clusters page) - what that should means? Tendrl supports enable/disable of volume profiling at cluster level only. While import cluster if admin selects to enable profiling, during cluster sync, for all the volumes, the profiling would be enabled. If admin selects not to have profiling enabled for the volumes, it wont be enabled. >> For example what it should display, if profiling will be started on one volume and stopped on second volume? If volume profiling is enabled for selective volumes from CLI and then the cluster is enabled (say with profiling de-selected in UI) the cluster level field would be set as `False` and while syncing the volumes, get-state doesnt report any details about profiling so actually no action at volume level. >> Should the information reflect actual state as it is configured in Gluster (so it will change, when I'll start/stop profiling via `gluster volume profile` command) or only the theoretical state configured by Tendrl? If you toggle between the profiling enabled/disable for individual volumes from CLI, there is no change in tendrl central store as part of sync. If the cluster is maintained by Tendrl, admin should use enable/disable option from UI for profling and this would enable/disable profiling for all the volumes in the cluster. >> What have higher priority - configuration via `gluster volume profile` command or via Tendrl? Or the last change, no mater where it was initiated? So the logic is like if `cluster.enable_volume_profling` is set as `yes` for cluster, while syncing the cluster details for each volume, it checks if `profiling_enabled` is un-set. If so it enables profiling for the volumes and sets this flag (so that next sync we don't try to set it again). There is no other way around. If from CLI profiling is set for a specific volume, there is way way to identify that and set in tendrl central store. >> When I'll import cluster to Tendrl I'm able to switch Profiling on and off few times via Tendrl web UI and it seems to be reflected correctly in gluster, but later, when I'll change it in Tendrl, there is no change in gluster. How/where can I debug the problem? Why the state is changed in Tendrl but not in gluster? You need to look for any errors in the flow. Also take a note that, when you say disable profiling for a cluster, it actually sets the cluster level flag `enable_volume_profling` to `yes` and while next sync only the required changes would be taken care. So if you do this back to back, sometimes before next sync is triggered you might not see the changes in effect at CLI. But I would suggest to check for errors as well for the jobs. >> Also when I'll click to Enable or Disable Profiling, message "Volume profiling updated successfully." is shown quite immediately, but the state in gluster is changed after some delay (sometime after tens of seconds). As mentioned above this flow changes the flag only at cluster level and next round of sync does the actual enable/disable of profiling for the volumes. May be the message is confusing. In that case I would suggest UX to suggest a better sentence to report that, volume profiling flag is set for the cluster, and next sync would enable/disable accordingly. Hope I have answered the questions but would request others as well to comment if something missing here. Thanks and Regards, Shubhendu On Thu, Sep 7, 2017 at 2:53 PM, Daniel Hor?k wrote: > Hi All, > I have bunch of questions and potentially issues related to Gluster Volume > Profiling. > > I've unsuccessfully tried to find some specification, so please redirect > me to the right link, if some of my questions are already answered > somewhere. > > Profiling is Volume specific configuration, but Tendrl web UI displays it > as cluster level information (Volume Profile column on Clusters page) - > what that should means? > For example what it should display, if profiling will be started on one > volume and stopped on second volume? > > Should the information reflect actual state as it is configured in Gluster > (so it will change, when I'll start/stop profiling via `gluster volume > profile` command) or only the theoretical state configured by Tendrl? > > What have higher priority - configuration via `gluster volume profile` > command or via Tendrl? Or the last change, no mater where it was initiated? > > When I'll import cluster to Tendrl I'm able to switch Profiling on and off > few times via Tendrl web UI and it seems to be reflected correctly in > gluster, but later, when I'll change it in Tendrl, there is no change in > gluster. How/where can I debug the problem? Why the state is changed in > Tendrl but not in gluster? > > Also when I'll click to Enable or Disable Profiling, message "Volume > profiling updated successfully." is shown quite immediately, but the state > in gluster is changed after some delay (sometime after tens of seconds). > > 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 ltrilety at redhat.com Wed Sep 13 14:20:14 2017 From: ltrilety at redhat.com (Lubos Trilety) Date: Wed, 13 Sep 2017 10:20:14 -0400 (EDT) Subject: [Tendrl-devel] Gluster Volume Profiling questions In-Reply-To: <1163808020.14763790.1505302852860.JavaMail.zimbra@redhat.com> References: <1163808020.14763790.1505302852860.JavaMail.zimbra@redhat.com> Message-ID: <1596791396.14991955.1505312414180.JavaMail.zimbra@redhat.com> Hi all, another question: Should be wide volume profiling by default enabled or disabled? Currently the default for API call is disabled and using UI it is enabled. Personally I think disabled should be the answer as it could have some performance impact on gluster machines. Lubos ----- Original Message ----- From: "Lubos Trilety" To: "Mailing list for the contributors to the Tendrl project" Sent: Wednesday, September 13, 2017 1:40:52 PM Subject: Re: [Tendrl-devel] Gluster Volume Profiling questions Hi Shubhendu, just a note. I hope that profiling per volume is still planned as https://redhat.invisionapp.com/share/8QCOEVEY9#/screens/247445416 states. Regards, Lubos ----- Original Message ----- From: "Shubhendu Tripathi" To: "Mailing list for the contributors to the Tendrl project" Sent: Thursday, September 7, 2017 1:06:52 PM Subject: Re: [Tendrl-devel] Gluster Volume Profiling questions Hi Daniel, Find below few comments inline -- >> Profiling is Volume specific configuration, but Tendrl web UI displays it as cluster level information (Volume Profile column on Clusters page) - what that should means? Tendrl supports enable/disable of volume profiling at cluster level only. While import cluster if admin selects to enable profiling, during cluster sync, for all the volumes, the profiling would be enabled. If admin selects not to have profiling enabled for the volumes, it wont be enabled. >> For example what it should display, if profiling will be started on one volume and stopped on second volume? If volume profiling is enabled for selective volumes from CLI and then the cluster is enabled (say with profiling de-selected in UI) the cluster level field would be set as `False` and while syncing the volumes, get-state doesnt report any details about profiling so actually no action at volume level. >> Should the information reflect actual state as it is configured in Gluster (so it will change, when I'll start/stop profiling via `gluster volume profile` command) or only the theoretical state configured by Tendrl? If you toggle between the profiling enabled/disable for individual volumes from CLI, there is no change in tendrl central store as part of sync. If the cluster is maintained by Tendrl, admin should use enable/disable option from UI for profling and this would enable/disable profiling for all the volumes in the cluster. >> What have higher priority - configuration via `gluster volume profile` command or via Tendrl? Or the last change, no mater where it was initiated? So the logic is like if `cluster.enable_volume_profling` is set as `yes` for cluster, while syncing the cluster details for each volume, it checks if `profiling_enabled` is un-set. If so it enables profiling for the volumes and sets this flag (so that next sync we don't try to set it again). There is no other way around. If from CLI profiling is set for a specific volume, there is way way to identify that and set in tendrl central store. >> When I'll import cluster to Tendrl I'm able to switch Profiling on and off few times via Tendrl web UI and it seems to be reflected correctly in gluster, but later, when I'll change it in Tendrl, there is no change in gluster. How/where can I debug the problem? Why the state is changed in Tendrl but not in gluster? You need to look for any errors in the flow. Also take a note that, when you say disable profiling for a cluster, it actually sets the cluster level flag `enable_volume_profling` to `yes` and while next sync only the required changes would be taken care. So if you do this back to back, sometimes before next sync is triggered you might not see the changes in effect at CLI. But I would suggest to check for errors as well for the jobs. >> Also when I'll click to Enable or Disable Profiling, message "Volume profiling updated successfully." is shown quite immediately, but the state in gluster is changed after some delay (sometime after tens of seconds). As mentioned above this flow changes the flag only at cluster level and next round of sync does the actual enable/disable of profiling for the volumes. May be the message is confusing. In that case I would suggest UX to suggest a better sentence to report that, volume profiling flag is set for the cluster, and next sync would enable/disable accordingly. Hope I have answered the questions but would request others as well to comment if something missing here. Thanks and Regards, Shubhendu On Thu, Sep 7, 2017 at 2:53 PM, Daniel Hor?k wrote: > Hi All, > I have bunch of questions and potentially issues related to Gluster Volume > Profiling. > > I've unsuccessfully tried to find some specification, so please redirect > me to the right link, if some of my questions are already answered > somewhere. > > Profiling is Volume specific configuration, but Tendrl web UI displays it > as cluster level information (Volume Profile column on Clusters page) - > what that should means? > For example what it should display, if profiling will be started on one > volume and stopped on second volume? > > Should the information reflect actual state as it is configured in Gluster > (so it will change, when I'll start/stop profiling via `gluster volume > profile` command) or only the theoretical state configured by Tendrl? > > What have higher priority - configuration via `gluster volume profile` > command or via Tendrl? Or the last change, no mater where it was initiated? > > When I'll import cluster to Tendrl I'm able to switch Profiling on and off > few times via Tendrl web UI and it seems to be reflected correctly in > gluster, but later, when I'll change it in Tendrl, there is no change in > gluster. How/where can I debug the problem? Why the state is changed in > Tendrl but not in gluster? > > Also when I'll click to Enable or Disable Profiling, message "Volume > profiling updated successfully." is shown quite immediately, but the state > in gluster is changed after some delay (sometime after tens of seconds). > > 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 _______________________________________________ Tendrl-devel mailing list Tendrl-devel at redhat.com https://www.redhat.com/mailman/listinfo/tendrl-devel From sankarshan at redhat.com Wed Sep 13 15:10:54 2017 From: sankarshan at redhat.com (sankarshan) Date: Wed, 13 Sep 2017 20:40:54 +0530 Subject: [Tendrl-devel] Gluster Volume Profiling questions In-Reply-To: <1596791396.14991955.1505312414180.JavaMail.zimbra@redhat.com> References: <1163808020.14763790.1505302852860.JavaMail.zimbra@redhat.com> <1596791396.14991955.1505312414180.JavaMail.zimbra@redhat.com> Message-ID: On 13 September 2017 at 19:50, Lubos Trilety wrote: > Hi all, > > another question: > Should be wide volume profiling by default enabled or disabled? > Currently the default for API call is disabled and using UI it is enabled. My take is that how it is right now is the correct way. Personally I think disabled should be the answer as it could have some performance impact on gluster machines. From jspray at redhat.com Thu Sep 14 14:05:17 2017 From: jspray at redhat.com (John Spray) Date: Thu, 14 Sep 2017 15:05:17 +0100 Subject: [Tendrl-devel] Ceph Message-ID: Hi folks, I'm not sure what your plans are around Ceph, but if you have any interest in REST APIs, there is a thread on ceph-devel called "REST APIs" that you might like to contribute to. This relates to the same module that Tim mentioned in the "ceph-mgr REST API" thread on this list in May -- there was a limited response to that, so whether anyone working on Tendrl is interested is a bit of a mystery. John From rwheeler at redhat.com Thu Sep 14 17:45:24 2017 From: rwheeler at redhat.com (Ric Wheeler) Date: Thu, 14 Sep 2017 20:45:24 +0300 Subject: [Tendrl-devel] Ceph In-Reply-To: References: Message-ID: Thanks for the reminder, Ric On Sep 14, 2017 5:26 PM, "John Spray" wrote: > Hi folks, > > I'm not sure what your plans are around Ceph, but if you have any > interest in REST APIs, there is a thread on ceph-devel called "REST > APIs" that you might like to contribute to. > > This relates to the same module that Tim mentioned in the "ceph-mgr > REST API" thread on this list in May -- there was a limited response > to that, so whether anyone working on Tendrl is interested is a bit of > a mystery. > > John > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > From rkanade at redhat.com Sat Sep 16 03:37:24 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Sat, 16 Sep 2017 09:07:24 +0530 Subject: [Tendrl-devel] tendrl-release v1.5.2 (milestone-3) is available Message-ID: Hello, The Tendrl team is happy to present tendrl-release v1.5.2 (milestone-3) Summary: https://github.com/Tendrl/documentation/wiki/Tendrl-release-v1.5.2-(summary) Install docs: https://github.com/Tendrl/documentation/wiki/Tendrl-release-v1.5.2-(install-guide) Metrics: https://github.com/Tendrl/documentation/wiki/Metrics From rwheeler at redhat.com Sat Sep 16 08:51:48 2017 From: rwheeler at redhat.com (Ric Wheeler) Date: Sat, 16 Sep 2017 11:51:48 +0300 Subject: [Tendrl-devel] REST APIs In-Reply-To: <1505396014.391.8.camel@redhat.com> References: <1505396014.391.8.camel@redhat.com> Message-ID: <9b92fe4b-cafa-a293-d4be-12b9e455b132@redhat.com> On 09/14/2017 04:33 PM, Boris Ranto wrote: > Hi, > > I still plan to port the v1 endpoints from calamari to the restful > module so that it provides a full replacement for calamari rest api and > so that it could be used by projects like tendlr. > > We do document the restful module in the RHCEPH product and several > people are/were interested in it. I did not hear of any product/app > being built on top of it yet though. > > We can extend the pass through method in the restful module so that it > is more user friendly for a more robust/useful replacement of the ceph- > rest-api. > > Regards, > Boris This sounds very useful to me - have REST API's let us plug into various frameworks in a standard way. thanks! Ric > > > On Wed, 2017-09-13 at 14:43 +0100, John Spray wrote: >> Hi all, >> >> This message is prompted by: https://github.com/ceph/ceph/pull/17530 >> >> Questions: >> ?- Is anyone using either ceph-rest-api or the restful module? >> ?- Is anyone planning on doing any work on either? >> ?- Is the CLI pass through of the restful module a sufficient >> replacement for ceph-rest-api for anyone that was using it? >> >> John From rwheeler at redhat.com Sun Sep 17 10:51:44 2017 From: rwheeler at redhat.com (Ric Wheeler) Date: Sun, 17 Sep 2017 13:51:44 +0300 Subject: [Tendrl-devel] [rhhi-dev] Are we displaying storage metrics in HC dashboard? In-Reply-To: References: Message-ID: It looks like our ceoh-metrics and gluster-metrics boards to me :) Ric On Sep 17, 2017 1:44 PM, "Yaniv Kaul" wrote: > See Microsoft's new dashboard for HC[1]. > Y. > > [1] https://msdnshared.blob.core.windows.net/media/2017/ > 09/Hyper-Converged-Cluster-Manager-solution-in-Project-Honolulu2.png > > --- > Note: This list is intended for discussions relating to Hyperconvergence > and Red Hat Storage products, customers and/or support. > From mkudlej at redhat.com Tue Sep 19 14:05:57 2017 From: mkudlej at redhat.com (Martin Kudlej) Date: Tue, 19 Sep 2017 16:05:57 +0200 Subject: [Tendrl-devel] How to find agreed implementation for one of milestone 2 feature In-Reply-To: References: Message-ID: <7b8a8a90-958e-4053-50cf-5174c8dd9739@redhat.com> Hi all, On 09/06/2017 03:20 PM, Martin Kudlej wrote: > I've found one difference (missing user status - enabled/disabled) so I've filed issue > https://github.com/Tendrl/ui/issues/556 . In the related issue Nishanth's stated > https://github.com/Tendrl/api/issues/238 that enabling/disabling will not be implemented and this > was already decided. I'm not able to find this change in design document or in any related issue/spec: This problem was solved by adding comment to design document. > I would like to ask couple of questions: > 1. Is there any change in workflow? > 2. What pieces should I put together to find design which I can compare with implementation? > 3. I've thought that design documents from wiki can be used for testing and in case of any change > there is linked PR. Is there any change in this? > 4. Somebody has mentioned that all last changes are reflected in API documentation. But I think that > design cannot be tested according API documentation. Could anybody explain this more, please? QE use design documents for testing UI implementation. Developers have declared that design documents are just suggestions and implementation can differ. But QE should have one single place where they can find all designs with comments about agreed differences which we can compare with implementation. Otherwise we cannot be sure that tested item is implemented as it should be. Also searching for differences and if they are acknowledged by team is very time consuming (which slow down testing). I think the best place to store differences with design are comments in design documents like it was done for issue mentioned above. QE continue to use design documents for testing UI with respect of comments in design documents including links to issues or specifications in github. One example how searching of differences between design and implementation is time consuming. You can try to find described issue and count how much effort you need to find it: Imagine that you are QE who tests list of users. You see that at design document every user has "First name" and "Last name" (https://redhat.invisionapp.com/share/KNB25OEQT#/screens/226063808) but they are missing in current implementation so it differs with design. You can search anywhere excluding github issues for Tendrl project because I and my colleagues have already filed this issue for couple of components and answer is there. -- 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 mrugesh at brainfunked.org Thu Sep 21 11:07:39 2017 From: mrugesh at brainfunked.org (Mrugesh Karnik) Date: Thu, 21 Sep 2017 16:37:39 +0530 Subject: [Tendrl-devel] How to find agreed implementation for one of milestone 2 feature In-Reply-To: <7b8a8a90-958e-4053-50cf-5174c8dd9739@redhat.com> References: <7b8a8a90-958e-4053-50cf-5174c8dd9739@redhat.com> Message-ID: On 19 September 2017 at 19:35, Martin Kudlej wrote: > QE use design documents for testing UI implementation. Developers have > declared that design documents are just suggestions and implementation can > differ. But QE should have one single place where they can find all designs > with comments about agreed differences which we can compare with > implementation. Otherwise we cannot be sure that tested item is implemented > as it should be. Also searching for differences and if they are acknowledged > by team is very time consuming (which slow down testing). I think the best > place to store differences with design are comments in design documents like > it was done for issue mentioned above. QE continue to use design documents > for testing UI with respect of comments in design documents including links > to issues or specifications in github. > > One example how searching of differences between design and implementation > is time consuming. You can try to find described issue and count how much > effort you need to find it: > > Imagine that you are QE who tests list of users. You see that at > design document every user has "First name" and "Last name" > (https://redhat.invisionapp.com/share/KNB25OEQT#/screens/226063808) but they > are missing in current implementation so it differs with design. You can > search anywhere excluding github issues for Tendrl project because I and my > colleagues have already filed this issue for couple of components and answer > is there. This is precisely why the contributors that test the releases need to be actively involved in the specifications phase. The milestones linked off to specifications, which are clearly tagged based on the components and the specification pull requests are to accompanied by the UX mockups that the specifications would implement. The validation is that the output from the pull request should be match with the mockups in the pull request itself. The reason the UX design documents are treated as suggestions is that they don't always align with the actual functionality being delivered and/or the backend architecture. The developers thus figure out what can be implemented as part of the specification pull request. Finally, I honestly fail to understand whether the testing is for the functionality delivered by the UI or the exact 'design compliance'. Not having access to the exact difference between the suggested and implemented UX designs does not prevent anyone from validating that the functionality works as expected. Whether something is a link or a button does not prevent that functionality from working (unless of course it does, in which case, it's a bug). Basically, if you were to validate the 'design compliance', it should've been done at the pull request stage. Since the 'Gluster Monitoring' build has been released, which does not have any work-in-progress UI features, the reference is what you see in the actual UI from that build. This does not mean that the build is bug-free, but it does mean that within the context of the feature and it's implementation, the UI does not fail to enable the intended functionality. The context is not '100% compliance' with the design suggestions, but rather that the functionality works as intended and is intuitive enough for the users to use. Which then brings up the point that unless there's feedback from the actual administrators monitoring their gluster infrastructure with this release, the UI implementation will not be changed in terms of the design. If there are bugs with the implementation, we'll fix them. Changes to the designs of the implemented UI will be considered when there's a justifiable case made against it from an actual target user. -- Mrugesh From mbukatov at redhat.com Wed Sep 27 20:40:01 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Wed, 27 Sep 2017 22:40:01 +0200 Subject: [Tendrl-devel] tendrl-ansible status update Message-ID: <1324ea08-3940-7382-a6f6-1a5c832d44e8@redhat.com> Dear all, I have finally tweaked last moving parts in the rpm spec file so that we have rpm snapshots builds in tendrl/tendrl copr: https://copr.fedorainfracloud.org/coprs/tendrl/tendrl/package/tendrl-ansible/ The basic layout looks like this (checking doc files in the package): # rpm -q tendrl-ansible tendrl-ansible-1.5.3-20170927T205649.29c6d57.noarch # rpm -qd tendrl-ansible /usr/share/ansible/roles/tendrl-ansible.ceph-installer/README.md /usr/share/ansible/roles/tendrl-ansible.gluster-gdeploy-copr/README.md /usr/share/ansible/roles/tendrl-ansible.grafana-repo/README.md /usr/share/ansible/roles/tendrl-ansible.tendrl-copr/README.md /usr/share/ansible/roles/tendrl-ansible.tendrl-server/README.md /usr/share/ansible/roles/tendrl-ansible.tendrl-storage-node/README.md /usr/share/doc/tendrl-ansible-1.5.3/LICENSE /usr/share/doc/tendrl-ansible-1.5.3/README.md /usr/share/doc/tendrl-ansible-1.5.3/prechecks.yml /usr/share/doc/tendrl-ansible-1.5.3/site.yml.sample /usr/share/doc/tendrl-ansible-1.5.3/workaround.disable-firewall.yml /usr/share/doc/tendrl-ansible-1.5.3/workaround.disable-selinux.yml This layout is based packaging choices made for rhel-system-roles. That said, I would like to test it a bit more before calling this done and part of upstream release. Also we need to reconfigure our CI to use this package instead of git repository ... Status of the other tasks follows. The overall status of tendrl-ansible work could be checked in these milestones: * https://github.com/Tendrl/tendrl-ansible/milestone/2 * https://github.com/Tendrl/tendrl-ansible/milestone/3 For SSL setup (tendrl-ansible/milestone/2), I have an initial pull request which verified the setup and revealed one missing piece: https://github.com/Tendrl/api/issues/303 I'm ok with merging this only when this issue will be addressed and not blocking upstream release because of this (more on that below). Then there is SELinux setup, which I haven't inspected in detail, I would like to consult with SELinux people while working on this: https://github.com/Tendrl/tendrl-ansible/issues/44 And the last missing piece is etcd auth, which boils down into 2 tasks: * removing password auth https://github.com/Tendrl/tendrl-ansible/issues/37 * setting up cert based out here I wait for dev team to provide suggestions and doc drafts how we should configure etcd and tendrl for cert auth to work. For this reason, I would like to postpone the planned additional upstream release, which was inserted into the plan only for tendrl ansible to catch up and provide rpm builds, and to address these last missing pieces and moving parts next week. Since tendrl-ansible is already able to install tendrl from master (but without selinux, fast etcd auth and full working ssl setup), this delay would not block planned upstream testing, as long as we manage to fill in the blanks next week. -- Martin Bukatovic USM QE team Red Hat From sankarshan at redhat.com Wed Sep 27 22:20:00 2017 From: sankarshan at redhat.com (sankarshan) Date: Thu, 28 Sep 2017 03:50:00 +0530 Subject: [Tendrl-devel] tendrl-ansible status update In-Reply-To: <1324ea08-3940-7382-a6f6-1a5c832d44e8@redhat.com> References: <1324ea08-3940-7382-a6f6-1a5c832d44e8@redhat.com> Message-ID: On Sep 28, 2017 02:43, "Martin Bukatovic" wrote: Dear all, I have finally tweaked last moving parts in the rpm spec file so that we have rpm snapshots builds in tendrl/tendrl copr: https://copr.fedorainfracloud.org/coprs/tendrl/tendrl/ package/tendrl-ansible/ This is good work. Thanks for the additional detail as below. The basic layout looks like this (checking doc files in the package): # rpm -q tendrl-ansible tendrl-ansible-1.5.3-20170927T205649.29c6d57.noarch # rpm -qd tendrl-ansible /usr/share/ansible/roles/tendrl-ansible.ceph-installer/README.md /usr/share/ansible/roles/tendrl-ansible.gluster-gdeploy-copr/README.md /usr/share/ansible/roles/tendrl-ansible.grafana-repo/README.md /usr/share/ansible/roles/tendrl-ansible.tendrl-copr/README.md /usr/share/ansible/roles/tendrl-ansible.tendrl-server/README.md /usr/share/ansible/roles/tendrl-ansible.tendrl-storage-node/README.md /usr/share/doc/tendrl-ansible-1.5.3/LICENSE /usr/share/doc/tendrl-ansible-1.5.3/README.md /usr/share/doc/tendrl-ansible-1.5.3/prechecks.yml /usr/share/doc/tendrl-ansible-1.5.3/site.yml.sample /usr/share/doc/tendrl-ansible-1.5.3/workaround.disable-firewall.yml /usr/share/doc/tendrl-ansible-1.5.3/workaround.disable-selinux.yml This layout is based packaging choices made for rhel-system-roles. That said, I would like to test it a bit more before calling this done and part of upstream release. Also we need to reconfigure our CI to use this package instead of git repository ... Status of the other tasks follows. The overall status of tendrl-ansible work could be checked in these milestones: * https://github.com/Tendrl/tendrl-ansible/milestone/2 * https://github.com/Tendrl/tendrl-ansible/milestone/3 For SSL setup (tendrl-ansible/milestone/2), I have an initial pull request which verified the setup and revealed one missing piece: https://github.com/Tendrl/api/issues/303 I'm ok with merging this only when this issue will be addressed and not blocking upstream release because of this (more on that below). Then there is SELinux setup, which I haven't inspected in detail, I would like to consult with SELinux people while working on this: https://github.com/Tendrl/tendrl-ansible/issues/44 Is this something you will be looking into this week? And the last missing piece is etcd auth, which boils down into 2 tasks: * removing password auth https://github.com/Tendrl/tendrl-ansible/issues/37 * setting up cert based out here I wait for dev team to provide suggestions and doc drafts how we should configure etcd and tendrl for cert auth to work. For this reason, I would like to postpone the planned additional upstream release, which was inserted into the plan only for tendrl ansible to catch up and provide rpm builds, and to address these last missing pieces and moving parts next week. Since tendrl-ansible is already able to install tendrl from master (but without selinux, fast etcd auth and full working ssl setup), this delay would not block planned upstream testing, as long as we manage to fill in the blanks next week. -- 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 rkanade at redhat.com Thu Sep 28 19:39:18 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Fri, 29 Sep 2017 01:09:18 +0530 Subject: [Tendrl-devel] Running Tendrl with a secure etcd cluster Message-ID: I wrote up a guide and some PRs to enable TLS cert support etcd for Tendrl services. Please try it out and provide feedback https://github.com/Tendrl/documentation/wiki/Tendrl-with-a-secure-etcd-cluster Regards, Rohan Kanade From sankarshan.mukhopadhyay at gmail.com Fri Sep 29 03:59:50 2017 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Fri, 29 Sep 2017 09:29:50 +0530 Subject: [Tendrl-devel] Running Tendrl with a secure etcd cluster In-Reply-To: References: Message-ID: On Fri, Sep 29, 2017 at 1:09 AM, Rohan Kanade wrote: > I wrote up a guide and some PRs to enable TLS cert support etcd for Tendrl > services. Please try it out and provide feedback > > https://github.com/Tendrl/documentation/wiki/Tendrl-with-a-secure-etcd-cluster > Thanks Rohan! Martin - would these be sufficient for you to work with on tendrl-ansible? The context for the question is your notes about tendrl-ansible from a few days back.