From anbabu at redhat.com Thu Jun 1 06:58:35 2017 From: anbabu at redhat.com (Anmol Babu) Date: Thu, 1 Jun 2017 02:58:35 -0400 (EDT) Subject: [Tendrl-devel] installation of monitoring and alerting In-Reply-To: <0c4130c9-4966-0202-ca53-48f687b3ab7d@redhat.com> References: <28595887-4cbf-1cb9-cb60-2778e94a3733@redhat.com> <1945471781.13697150.1496225261797.JavaMail.zimbra@redhat.com> <0c4130c9-4966-0202-ca53-48f687b3ab7d@redhat.com> Message-ID: <722642968.13981932.1496300315646.JavaMail.zimbra@redhat.com> Please find my responses inline Anmol Babu Software Engineer Red Hat India Pvt Ltd M: 8884245644 ----- Original Message ----- From: "Martin Bukatovic" To: tendrl-devel at redhat.com Sent: Wednesday, May 31, 2017 7:20:02 PM Subject: Re: [Tendrl-devel] installation of monitoring and alerting Hi Anmol, On 05/31/2017 12:07 PM, Anmol Babu wrote: > 1. The performance-monitoring installation brings in(installs) and configures graphite. > 2. All nodes push stats to the graphite installed by performance-monitoring application.. > 3. Writes to graphite induce read/write disk operations as the stats are maintained in files by whisper database(part of graphite stack). > > Note: Metrics get fed into the graphite stack via the Carbon service, which writes data out to Whisper databases for long-term storage. >Ok, so performance monitoring machine is a target for performance data >pushes from all other Tendrl machines. Yes >> 1) What are pros and cons of each installation configuration? Based on >> what should one decide on which machine to install the role in both >> cases? > > I think the answer to this is mainly governed by: > a. Points 1 to 3 above under "Important points to note..." > b. performance-monitoring application does lots of etcd interactions and also has interactions from tendrl/api which makes me say that having them co-resident > would be beneficial from network utilization perspective may not be a major gain though... > c. To avoid having to dedicate a node for this purpose one can as well use the same node for installing etcd, api, dashboard, performance-monitoring and alerting application along with their dependent service node-agent. > d. Point c in essence also suggests that this can be essentially deployed on a storage node as well. > Note: Having etcd and api along with performance-monitoring, node-monitoring and alerting might bring in resource utilization related issues. > But this might need to be confirmed via tests... >And at the same time, performance monitoring communicates a lot with >etcd and tendrl api. Ok. Yes >So for this reason, it may make sense to deploy it on the Tendrl Server >(along with etcd and tendrl api/web). But you are concerned with the >resource requirements, especially wrt scaling. Yes but I think we can get a clear understanding once we do some performance/scale tests... >But I don't get why it seems a good idea to deploy performance >monitoring on storage node. There are even more issues with resource >utilization in that case ... So, if we consider the case of deploying -- etcd + api + dashboard + node-agent + performance-monitoring + node-monitoring(if we want to monitor even this node..) which I think is a normal deployment scenario vs a storage node, the former essentially just doesn't have tendrl-gluster-integration or tendrl-ceph-integration based on sds type of cluster.. while on the other hand a storage node doesn't also need to necessarily carry packages like etcd or api so the number or the load is almost the same but yes api is light-weight and etcd might seem light-weight with a clustered setup but as it stands today, the 2 deployments don't seem very different to me from the perspective of load they put.. >> 2) What is suggested safe default? > > The answer to this varies in accordance with considerations above... >I will reply below the summary. Ack >> 3) Does "New node" for Performance Monitoring mean a dedicated machine >> just for this role? > > Yes, based on considerations above, if this is inevitable, there is nothing in code that stops such a deployment... >Ok. >> 4) Why alternative place for monitoring is "new node", while alerting >> could be placed on storage node? Is it possible to install monitoring >> and alerting on single dedicated machine? And would it make sense? > > The alternatives to both applications from the perspective of code are the same.. > Its just a fix required on documentation if it suggests otherwise.. > Having performance-monitoring and alerting on a dedicated machine might make sense but yes as said above it all depends on considerations above... >You mentioned Performance Monitoring constrains in a clear way, but not >for Alerting. I'm interested especially in: >* having performance monitoring and alerting on the same machine - >* having alerting on storage machine At this stage, the alerting module is light-weight when compared to the performance-monitoring application(brings in graphite + lot of periodic etcd interactions to facilitate dashboards). Its only responsibility is to scan through /messages/events in etcd and if it finds any new message that carries a priority "notice" It initiates a chain of actions like 1. Putting the validated alert in a appropriate location in etcd... 2. Sending out the alert to its configured destinations(currently only via email to configured users) The way it works is described at https://github.com/Tendrl/documentation/wiki/How-to-send-alerts-from-inside-Tendrl---for-devs If you find time, please review it and provide your feedback on it.. So to summarise, from the perspective of alerting module, I currently don't see any trade-offs by virtue of where it is deployed and even the code doesn't lay any limitations on where it can be deployed. > To summarise, I would like to say that definitive and/or quantitative answers to most of these questions, can be made after: > > 1. We test each of these deployment scenarios > 2. We perform scale tests to see how tendrl scales... >So at this point, we don't have enough experiences with the behavior of >the system to suggest how to deploy the system exactly. That's fine, but >I would suggest to write down a gist of what we know right now directly >into the docs. >Would it make sense to write something like (here I'm proposing what >we could add into the docs and verifying that I understand you at the >same time - feel free to correct me and fix/expand the text): >For Performance Monitoring: --- suggested update --- This role could be deployed either on Tendrl Server machine (along with tendrl api, etcd, ... as described above) or a dedicated machine. Performance monitoring machine is a target for performance data pushes from all other Tendrl machines and communicates a lot with services on Tendrl Server (etcd and tendrl-api) - which affects network utilization and produces lots of tiny I/O operations. For this reason, it makes sense to deploy it on Tendrl Server, but when you see problems with resource utilization on Tendrl Server, it may be better to go with deployment on a dedicated machine. We have not enough experiences to provide final and exact guidelines here. --- suggested update --- >The same should be done for Alerting. Sure.. I'll make these changes as you suggested... >For testing, we deploy both alerting and performance monitoring on >tendrl server, as can be seen here: >https://github.com/Tendrl/usmqe-setup/blob/master/tendrl_server.yml#L18 Ok >I understand you reply as a request for us to start tracking resource >utilization per services on this type of machine, to get a better data. -- 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 Jun 1 10:43:47 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 1 Jun 2017 12:43:47 +0200 Subject: [Tendrl-devel] installation of monitoring and alerting In-Reply-To: <722642968.13981932.1496300315646.JavaMail.zimbra@redhat.com> References: <28595887-4cbf-1cb9-cb60-2778e94a3733@redhat.com> <1945471781.13697150.1496225261797.JavaMail.zimbra@redhat.com> <0c4130c9-4966-0202-ca53-48f687b3ab7d@redhat.com> <722642968.13981932.1496300315646.JavaMail.zimbra@redhat.com> Message-ID: Hi Anmol, On 06/01/2017 08:58 AM, Anmol Babu wrote: > At this stage, the alerting module is light-weight when compared to the performance-monitoring application(brings in graphite + lot of periodic etcd interactions to facilitate dashboards). > Its only responsibility is to scan through /messages/events in etcd and if it finds any new message that carries a priority "notice" It initiates a chain of actions like > 1. Putting the validated alert in a appropriate location in etcd... > 2. Sending out the alert to its configured destinations(currently only via email to configured users) > The way it works is described at https://github.com/Tendrl/documentation/wiki/How-to-send-alerts-from-inside-Tendrl---for-devs > If you find time, please review it and provide your feedback on it.. > So to summarise, from the perspective of alerting module, I currently don't see any trade-offs by virtue of where it is deployed and even the code doesn't lay any limitations on where it can be deployed. Thanks a lot for this explanation. I have few additional questions: Based on your description, I guess that the safe default for tendrl-alerting is collocation on Tendrl Server (even though that you can deploy it anywhere), right? What kind of additional processing of raw messages with priority notice from /messages/events are done? I see you mention classification and meta data processing - so do I read it right that the alerting process only messages from etcd and nothing else? Does it mean that if you don't plan to configure email notifications, you don't have to deploy tendrl-alerting at all? Would not installing tendrl-alerting have any side effect on the rest of tendrl? Does tendrl-alerting write some data back into etcd? -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Thu Jun 1 11:42:30 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 1 Jun 2017 13:42:30 +0200 Subject: [Tendrl-devel] REST API consistency In-Reply-To: References: <8e1e89a1-2106-0209-a13b-96186d75fb60@redhat.com> Message-ID: ping On 05/30/2017 04:23 PM, Martin Kudlej wrote: > Hi all, > > I would like to ask if there is any movement in this area? > > On 04/26/2017 09:58 AM, Martin Kudlej wrote: >> Hi all, >> >> I think there is still time to unify Tendrl API functions according >> some rules. >> I've filed https://github.com/Tendrl/documentation/issues/70 couple of >> months ago without response. >> >> One example for all. >> There are these functions for Ceph cluster(Flows on cluster): >> "name": "CephCreatePool", >> "method": "POST", >> >> "name": "CephCreateECProfile", >> "method": "POST", >> >> "name": "CephDeleteECProfile", >> "method": "DELETE", >> >> "name": "CephCreateRbd", >> "method": "POST", >> >> "name": "CephDeleteRbd", >> "method": "DELETE", >> >> "name": "CephResizeRbd", >> "method": "PUT", >> >> "name": "CephDeletePool", >> "method": "DELETE", >> >> "name": "CephUpdatePool", >> "method": "PUT", >> >> and according documentation there should be also >> "name": "CephPoolList" >> "method": "GET" >> >> I think that there should be also "GET" "CephPool" because of >> performance. >> >> I think that these functions should be transformed avoiding verb >> duplicity. Also I believe if API function names are renamed >> integration with other projects will be much easier. >> >> Pool CRUD >> "name": ":ceph_cluster_id:/pool", >> "method": "POST", >> >> "name": ":ceph_cluster_id:/pool/:ceph_pool_id:", >> "method": "GET", >> >> "name": ":ceph_cluster_id:/pool/:ceph_pool_id:", >> "method": "PUT", >> >> "name": ":ceph_cluster_id:/pool/:ceph_pool_id:", >> "method": "DELETE", >> >> RBD CRUD >> >> "name": ":ceph_cluster_id:/rbd", >> "method": "POST", >> >> "name": ":ceph_cluster_id:/rbd/:ceph_pool_id:", >> "method": "GET", >> >> "name": ":ceph_cluster_id:/rbd/:ceph_pool_id:", >> "method": "PUT", >> >> "name": ":ceph_cluster_id:/rbd/:ceph_pool_id:", >> "method": "DELETE", >> >> EC Profile CRUD >> >> "name": ":ceph_cluster_id:/ecprofile", >> "method": "POST", >> >> "name": ":ceph_cluster_id:/ecprofile/:ec_profile_id:", >> "method": "GET", >> >> (update if it is possible) >> "name": ":ceph_cluster_id:/ecprofile/:ec_profile_id:", >> "method": "PUT", >> >> "name": ":ceph_cluster_id:/ecprofile/:ec_profile_id:", >> "method": "DELETE", >> >> >> Lists >> >> "name": ":ceph_cluster_id:/pool" >> "method": "GET" >> >> "name": ":ceph_cluster_id:/rbd" >> "method": "GET" >> >> "name": ":ceph_cluster_id:/ecprofile" >> "method": "GET" >> >> Please consider this rename until is not too late and there are not >> many projects which are integrated with Tendrl. >> > -- Martin Bukatovic USM QE team Red Hat From anbabu at redhat.com Thu Jun 1 12:15:11 2017 From: anbabu at redhat.com (Anmol Babu) Date: Thu, 1 Jun 2017 08:15:11 -0400 (EDT) Subject: [Tendrl-devel] installation of monitoring and alerting In-Reply-To: References: <28595887-4cbf-1cb9-cb60-2778e94a3733@redhat.com> <1945471781.13697150.1496225261797.JavaMail.zimbra@redhat.com> <0c4130c9-4966-0202-ca53-48f687b3ab7d@redhat.com> <722642968.13981932.1496300315646.JavaMail.zimbra@redhat.com> Message-ID: <364384271.14043091.1496319311551.JavaMail.zimbra@redhat.com> Please find my comments inline... Anmol Babu Software Engineer Red Hat India Pvt Ltd M: 8884245644 ----- Original Message ----- From: "Martin Bukatovic" To: tendrl-devel at redhat.com Sent: Thursday, June 1, 2017 4:13:47 PM Subject: Re: [Tendrl-devel] installation of monitoring and alerting Hi Anmol, On 06/01/2017 08:58 AM, Anmol Babu wrote: > At this stage, the alerting module is light-weight when compared to the performance-monitoring application(brings in graphite + lot of periodic etcd interactions to facilitate dashboards). > Its only responsibility is to scan through /messages/events in etcd and if it finds any new message that carries a priority "notice" It initiates a chain of actions like > 1. Putting the validated alert in a appropriate location in etcd... > 2. Sending out the alert to its configured destinations(currently only via email to configured users) > The way it works is described at https://github.com/Tendrl/documentation/wiki/How-to-send-alerts-from-inside-Tendrl---for-devs > If you find time, please review it and provide your feedback on it.. > So to summarise, from the perspective of alerting module, I currently don't see any trade-offs by virtue of where it is deployed and even the code doesn't lay any limitations on where it can be deployed. >Thanks a lot for this explanation. >I have few additional questions: >Based on your description, I guess that the safe default for >tendrl-alerting is collocation on Tendrl Server (even though >that you can deploy it anywhere), right? Yes you are right.. >What kind of additional processing of raw messages with priority >notice from /messages/events are done? I see you mention >classification and meta data processing - so do I read it right >that the alerting process only messages from etcd and nothing >else? Additional processing involves: 1. Classifying alerts as node-related or cluster related and further classifying them by the node ids/cluster ids as applicable within the initial classification.. 2. Anything in /messages/events is just messages which includes our logs, alerts and job updates but, classifying and extracting out messages corresponding to alerts into a dedicated etcd directory is done by alerting module. These apart from the final notifying to configured users.. 1 and 2 are source of alerts for the api that are shown on UI both filtered by cluster/node and unfiltered list... >Does it mean that if you don't plan to configure email >notifications, you don't have to deploy tendrl-alerting >at all? The alerting module also handles auto-acking an alert when there is a negation alert for the already existing alert in etcd. It also facilitates user acking the alert so that he doesn't want to see it anymore in list of alerts.. It is also responsible for adding alert counters >Would not installing tendrl-alerting have any >side effect on the rest of tendrl? Not installing tendrl-alerting theoretically would leave: 1. alerts page empty 2. alerts list on dashboards empty 3. Number of alerts in each of the dashboards for each of the cards as 0.. >Does tendrl-alerting >write some data back into etcd? Yes in accordance with 1 and 2 above, it does write messages corresponding to alerts to dedicated location in etcd.. -- 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 fbalak at redhat.com Thu Jun 1 14:04:31 2017 From: fbalak at redhat.com (Filip Balak) Date: Thu, 1 Jun 2017 10:04:31 -0400 (EDT) Subject: [Tendrl-devel] Create cluster documentation In-Reply-To: <691364936.14963767.1496325158841.JavaMail.zimbra@redhat.com> Message-ID: <1748967170.14967977.1496325871068.JavaMail.zimbra@redhat.com> Hi Anup, could you please help me to better understand how to correctly set parameters for CreateCluster API call? From documentation[1] it isn't clear to me what is correct value for some parameters. Especialy parameters `provisioning_ip` and `node_identifier`. What could be correct values of those parameters? I have created issue[2] about clarity of documentation for this API call. Best Regards Filip Balak [1] https://github.com/Tendrl/api/blob/master/docs/clusters.adoc#create-cluster [2] https://github.com/Tendrl/api/issues/197 From mbukatov at redhat.com Thu Jun 1 14:15:28 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 1 Jun 2017 16:15:28 +0200 Subject: [Tendrl-devel] tendrl-api configuration Message-ID: <4257b900-3fed-6f4c-44ab-5307538fe500@redhat.com> Dear all, In *Tendrl Package Installation Reference* document, I see that during configuration of tendrl-api, both password and username values are changed to `''` (empty string), while there are some default config values shipped in /etc/tendr/etcd.yml. I have 2 questions: is this username/password pair used to connect to etcd (in other words, is it an etcd user)? And if so, how come that it works when empty string values are specified? I'm asking because I was thinking about changing the defaults shipped in tendrl-api rpm package to empty strings as well, but I would like to understand the meaning of the options better first. Thank you for help. -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Thu Jun 1 15:36:01 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 1 Jun 2017 17:36:01 +0200 Subject: [Tendrl-devel] incomplete description of tendrl-api installation Message-ID: <428da7b4-a515-64d0-d00d-3bb35dffdb71@redhat.com> Dear all, I noticed that the Tendrl Package Installation Reference[1] doesn't list all steps needed to install tendrl-api on Tendrl Server machine. It states how to install and configure tendrl-api package, but I'm missing there: * installation of tendrl-api-httpd package * creating admin user (as documented in [2]) Could you review this and update the docs if you agree that the mentioned steps are missing? Thank you. [1] https://github.com/Tendrl/documentation/wiki/Tendrl-Package-Installation-Reference [2] https://github.com/Tendrl/api/blob/master/docs/users.adoc#create-admin-user -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Thu Jun 1 18:35:42 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 1 Jun 2017 20:35:42 +0200 Subject: [Tendrl-devel] node agent tags on Tendrl Server Message-ID: Hi all, I have another question: do I really need to install node agent and specify `provisioner/ceph` tag on Tendrl Server even if I don't plan to provision ceph? In package installation reference it seems so[1], but release notes for 1.2.2 release[2] seems to imply that this is required for ceph provisioning only. Having in mind that we have updated the docs[1] already stating that one doesn't need to install ceph-installer on Tendrl Server, what would be the proper approach? Btw, what is Tendrl expected to do in a case when either `provisioner/ceph` tag is not assigned or ceph-installer is not installed? [1] https://github.com/Tendrl/documentation/wiki/Tendrl-Package-Installation-Reference#performance-monitoring-installation [2] https://github.com/Tendrl/documentation/wiki/Tendrl-release-v1.2.2 -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Thu Jun 1 18:41:24 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 1 Jun 2017 20:41:24 +0200 Subject: [Tendrl-devel] installation of monitoring and alerting In-Reply-To: <364384271.14043091.1496319311551.JavaMail.zimbra@redhat.com> References: <28595887-4cbf-1cb9-cb60-2778e94a3733@redhat.com> <1945471781.13697150.1496225261797.JavaMail.zimbra@redhat.com> <0c4130c9-4966-0202-ca53-48f687b3ab7d@redhat.com> <722642968.13981932.1496300315646.JavaMail.zimbra@redhat.com> <364384271.14043091.1496319311551.JavaMail.zimbra@redhat.com> Message-ID: On 06/01/2017 02:15 PM, Anmol Babu wrote: >> Based on your description, I guess that the safe default for >> tendrl-alerting is collocation on Tendrl Server (even though >> that you can deploy it anywhere), right? > > Yes you are right.. With this in mind, do you agree if I make the installation of tendrl-alerting part of Tendrl Server ansible role? For restart and 1st version of tendrl-ansible, we try to keep the number of roles low as we don't consider more advanced deployment scenarios at all. That said, I would keep the role for Monitoring separate, as there are clear reasons for this choice. -- Martin Bukatovic USM QE team Red Hat From rkanade at redhat.com Thu Jun 1 20:41:40 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Fri, 2 Jun 2017 02:11:40 +0530 Subject: [Tendrl-devel] tendrl-release v1.4.0 (alpha1) is available Message-ID: Hello, The Tendrl team is happy to present tendrl-release v1.4.0 (alpha1) Summary: https://github.com/Tendrl/documentation/wiki/Tendrl-release-v1.4.0-(summary) Install docs: https://github.com/Tendrl/documentation/wiki/Tendrl-release-v1.4.0-(install-docs) Cheers! From anbabu at redhat.com Fri Jun 2 03:07:55 2017 From: anbabu at redhat.com (Anmol Babu) Date: Thu, 1 Jun 2017 23:07:55 -0400 (EDT) Subject: [Tendrl-devel] installation of monitoring and alerting In-Reply-To: References: <28595887-4cbf-1cb9-cb60-2778e94a3733@redhat.com> <1945471781.13697150.1496225261797.JavaMail.zimbra@redhat.com> <0c4130c9-4966-0202-ca53-48f687b3ab7d@redhat.com> <722642968.13981932.1496300315646.JavaMail.zimbra@redhat.com> <364384271.14043091.1496319311551.JavaMail.zimbra@redhat.com> Message-ID: <113329433.14297179.1496372875267.JavaMail.zimbra@redhat.com> Comments inline... Anmol Babu Software Engineer Red Hat India Pvt Ltd M: 8884245644 ----- Original Message ----- From: "Martin Bukatovic" To: tendrl-devel at redhat.com Sent: Friday, June 2, 2017 12:11:24 AM Subject: Re: [Tendrl-devel] installation of monitoring and alerting On 06/01/2017 02:15 PM, Anmol Babu wrote: >> Based on your description, I guess that the safe default for >> tendrl-alerting is collocation on Tendrl Server (even though >> that you can deploy it anywhere), right? > > Yes you are right.. >With this in mind, do you agree if I make the installation of >tendrl-alerting part of Tendrl Server ansible role? For restart >and 1st version of tendrl-ansible, we try to keep the number of >roles low as we don't consider more advanced deployment scenarios >at all. Ack >That said, I would keep the role for Monitoring separate, as >there are clear reasons for this choice. Ack -- 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 shtripat at redhat.com Fri Jun 2 04:14:41 2017 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Fri, 2 Jun 2017 09:44:41 +0530 Subject: [Tendrl-devel] node agent tags on Tendrl Server In-Reply-To: References: Message-ID: <007a5e5f-92f4-49cf-5792-eef1c2d34aac@redhat.com> Martin, Few comments in-line below. Request others as well to add / correct if required.. Regards, Shubhendu On 06/02/2017 12:05 AM, Martin Bukatovic wrote: > Hi all, > > I have another question: do I really need to install > node agent and specify `provisioner/ceph` tag on Tendrl > Server even if I don't plan to provision ceph? If you dont plan to provision ceph, ceph-installer installation is not required on server node. Also the tag `provisioner/ceph` is not required in node-agent configuration. tendrl-node-agent installation might be required on the server node if you plan to monitor it using tendrl dashboards. > > In package installation reference it seems so[1], > but release notes for 1.2.2 release[2] seems to imply > that this is required for ceph provisioning only. > > Having in mind that we have updated the docs[1] already > stating that one doesn't need to install ceph-installer > on Tendrl Server, what would be the proper approach? Proper approach would be 1. Dont install ceph-installer if not planning to provision ceph cluster using tendrl 2. Install tendrl-node-agent on server node only if you want to monitor this node as well 3. If ceph-installer not installed, no need to have tag `provisioner/ceph` in tendrl-node-agent configuration (if tendrl-node-agent is installed on server node) > > Btw, what is Tendrl expected to do in a case when > either `provisioner/ceph` tag is not assigned or > ceph-installer is not installed? If ceph-installer is not installed provisioning of a ceph cluster would fail saying `no service available at http://:8181`. If tag `provisioner/ceph` is missing, a ceph cluster creation job would never be picked for processing (even if ceph-installer is up and running on the server node) > > [1] > https://github.com/Tendrl/documentation/wiki/Tendrl-Package-Installation-Reference#performance-monitoring-installation > [2] https://github.com/Tendrl/documentation/wiki/Tendrl-release-v1.2.2 > From rkanade at redhat.com Fri Jun 2 05:49:03 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Fri, 2 Jun 2017 11:19:03 +0530 Subject: [Tendrl-devel] node agent tags on Tendrl Server In-Reply-To: References: Message-ID: - Tendrl does not install ceph-installer (we should) - If one wants to create and manage ceph clusters, then ceph-installer is to be installed on the Tendrl server (Tendrl API node) - The tendrl-node-agent on the Tendrl server will auto detect the ceph installer service and auto tag itself as "provisioner/ceph" On 02-Jun-2017 00:06, "Martin Bukatovic" wrote: Hi all, I have another question: do I really need to install node agent and specify `provisioner/ceph` tag on Tendrl Server even if I don't plan to provision ceph? In package installation reference it seems so[1], but release notes for 1.2.2 release[2] seems to imply that this is required for ceph provisioning only. Having in mind that we have updated the docs[1] already stating that one doesn't need to install ceph-installer on Tendrl Server, what would be the proper approach? Btw, what is Tendrl expected to do in a case when either `provisioner/ceph` tag is not assigned or ceph-installer is not installed? [1] https://github.com/Tendrl/documentation/wiki/Tendrl-Package-Installation- Reference#performance-monitoring-installation [2] https://github.com/Tendrl/documentation/wiki/Tendrl-release-v1.2.2 -- 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 Fri Jun 2 08:58:27 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 2 Jun 2017 10:58:27 +0200 Subject: [Tendrl-devel] rename tendrl-api service In-Reply-To: <43a4a1e3-9124-fcdf-7ea4-02a4e7dd5a59@redhat.com> References: <43a4a1e3-9124-fcdf-7ea4-02a4e7dd5a59@redhat.com> Message-ID: <35d54f1f-453f-bf79-8dbe-768c8a5bc992@redhat.com> On 05/31/2017 09:28 PM, Martin Bukatovic wrote: > Could we get this simple rename fix in next upstream build? > > https://github.com/Tendrl/api/issues/45 > > I would be nice to have this in asap so that we don't have > to change documentation and tendrl-ansible again later. Fixed in tendrl-api-1.4.0-1.el7.centos.noarch Thank you. -- Martin Bukatovic USM QE team Red Hat From rkanade at redhat.com Fri Jun 2 09:37:05 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Fri, 2 Jun 2017 15:07:05 +0530 Subject: [Tendrl-devel] Tendrl release branch rpm jenkins jobs Message-ID: Hi, These are the jenkins rpm build jobs for all tendrl components and dependencies, The develop, master, release/$nvr branch rpms are also included. python-gdeploy: https://paste.fedoraproject.org/paste/XKW5wsinwfA3G4Ayq1OKx15M1UNdIGYhyRLivL9gydE= tendrl-performance-monitoring: https://paste.fedoraproject.org/paste/CCLwcOG-Wt5i~2YbE1FtpF5M1UNdIGYhyRLivL9gydE= tendrl-node-monitoring: https://paste.fedoraproject.org/paste/ZqPsbnWds9lTaQ4RCHpV1V5M1UNdIGYhyRLivL9gydE= tendrl-node-agent: https://paste.fedoraproject.org/paste/FL7SZssRCJlxeMRGtwZgmF5M1UNdIGYhyRLivL9gydE= tendrl-gluster-integration: https://paste.fedoraproject.org/paste/YYSQxImMJCc5waVEL9AnOF5M1UNdIGYhyRLivL9gydE= tendrl-dashboard: https://paste.fedoraproject.org/paste/cy7vCDwR08RyURedNcSNyV5M1UNdIGYhyRLivL9gydE= tendrl-commons: https://paste.fedoraproject.org/paste/X0x40uI-Pm-aEUTUVChpzV5M1UNdIGYhyRLivL9gydE= tendrl-ceph-integration: https://paste.fedoraproject.org/paste/dm52F5bxV-~27os1bFIB7V5M1UNdIGYhyRLivL9gydE= tendrl-api: https://paste.fedoraproject.org/paste/r1A4Wz3Wr8GvQTTtrrO4Pl5M1UNdIGYhyRLivL9gydE= tendrl-alerting: https://paste.fedoraproject.org/paste/lbosKhDeAz43boVJI95wZV5M1UNdIGYhyRLivL9gydE= These jobs can be used to make Tendrl "release/$nvr" branch rpms in any CI (centos etc). Same jobs (with changes to rpm name like adding git commit hash etc) can be used to build the "master" and "develop" branches of the respective Tendrl repos Let me know if any feedback/questions about the jobs From mbukatov at redhat.com Fri Jun 2 11:39:02 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 2 Jun 2017 13:39:02 +0200 Subject: [Tendrl-devel] node agent tags on Tendrl Server In-Reply-To: References: Message-ID: On 06/02/2017 07:49 AM, Rohan Kanade wrote: > - Tendrl does not install ceph-installer (we should) > - If one wants to create and manage ceph clusters, then ceph-installer is > to be installed on the Tendrl server (Tendrl API node) > - The tendrl-node-agent on the Tendrl server will auto detect the ceph > installer service and auto tag itself as "provisioner/ceph" Thank you both for the clarification, I'm updating the ansible accordingly. -- Martin Bukatovic USM QE team Red Hat From mkudlej at redhat.com Fri Jun 2 11:40:21 2017 From: mkudlej at redhat.com (Martin Kudlej) Date: Fri, 2 Jun 2017 13:40:21 +0200 Subject: [Tendrl-devel] Fwd: Re: Tendrl release branch rpm jenkins jobs In-Reply-To: <107edfa6-c221-5f41-dad2-048bd3c692ac@redhat.com> References: <107edfa6-c221-5f41-dad2-048bd3c692ac@redhat.com> Message-ID: -------- Forwarded Message -------- Subject: Re: Tendrl release branch rpm jenkins jobs Date: Fri, 2 Jun 2017 13:38:53 +0200 From: Martin Kudlej To: Rohan Kanade Hi Rohan, thank you for this email. I expect we will discus this pull request https://github.com/Tendrl/usmqe-centos-ci/pull/1 and we will work together on this pull request. On 06/02/2017 11:37 AM, Rohan Kanade wrote: > Hi, > > These are the jenkins rpm build jobs for all tendrl components and dependencies, The develop, > master, release/$nvr branch rpms are also included. > > python-gdeploy: > https://paste.fedoraproject.org/paste/XKW5wsinwfA3G4Ayq1OKx15M1UNdIGYhyRLivL9gydE= > > tendrl-performance-monitoring: > https://paste.fedoraproject.org/paste/CCLwcOG-Wt5i~2YbE1FtpF5M1UNdIGYhyRLivL9gydE= > > tendrl-node-monitoring: > https://paste.fedoraproject.org/paste/ZqPsbnWds9lTaQ4RCHpV1V5M1UNdIGYhyRLivL9gydE= > > tendrl-node-agent: > https://paste.fedoraproject.org/paste/FL7SZssRCJlxeMRGtwZgmF5M1UNdIGYhyRLivL9gydE= > > tendrl-gluster-integration: > https://paste.fedoraproject.org/paste/YYSQxImMJCc5waVEL9AnOF5M1UNdIGYhyRLivL9gydE= > > tendrl-dashboard: > https://paste.fedoraproject.org/paste/cy7vCDwR08RyURedNcSNyV5M1UNdIGYhyRLivL9gydE= > > tendrl-commons: > https://paste.fedoraproject.org/paste/X0x40uI-Pm-aEUTUVChpzV5M1UNdIGYhyRLivL9gydE= > > tendrl-ceph-integration: > https://paste.fedoraproject.org/paste/dm52F5bxV-~27os1bFIB7V5M1UNdIGYhyRLivL9gydE= > > tendrl-api: > https://paste.fedoraproject.org/paste/r1A4Wz3Wr8GvQTTtrrO4Pl5M1UNdIGYhyRLivL9gydE= > > tendrl-alerting: > https://paste.fedoraproject.org/paste/lbosKhDeAz43boVJI95wZV5M1UNdIGYhyRLivL9gydE= > > > > These jobs can be used to make Tendrl "release/$nvr" branch rpms in any CI (centos etc). > > Same jobs (with changes to rpm name like adding git commit hash etc) can be used to build the > "master" and "develop" branches of the respective Tendrl repos > > Let me know if any feedback/questions about the jobs > > -- Best Regards, Martin Kudlej. RHSC/USM Senior Quality Assurance Engineer Red Hat Czech s.r.o. Phone: +420 532 294 155 E-mail:mkudlej at redhat.com IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, #usm-meeting @ redhat #tendrl-devel @ freenode -- Best Regards, Martin Kudlej. RHSC/USM Senior Quality Assurance Engineer Red Hat Czech s.r.o. Phone: +420 532 294 155 E-mail:mkudlej at redhat.com IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, #usm-meeting @ redhat #tendrl-devel @ freenode From mkudlej at redhat.com Fri Jun 2 13:58:20 2017 From: mkudlej at redhat.com (Martin Kudlej) Date: Fri, 2 Jun 2017 15:58:20 +0200 Subject: [Tendrl-devel] Enhance upstream CI Message-ID: Hi all, AI: - Daniel will update old PR https://github.com/Tendrl/usmqe-centos-ci/pull/1 - Daniel will email to CentOS CI mailing list and ask what is the best solution to build source packages which require npm - Timothy(and anybody else) will review https://github.com/Tendrl/usmqe-centos-ci/pull/1 - Daniel and Timothy will create jobs in ci.centos.org and establish CI for devel branch CI: 1. build src packages in ci.cento.org 2. push src packages to Copr 3. wait till packages are built 4. create/update repo 5. run package sanity tests 6. run cluster installation test 7. run functional tests Goals(ordered according priority): - CI for devel branch - triggered by merge - CI for master branch and other stable branches(v1.4 right now) - triggered by merge - CI for devel branches based on specification - these builds will be triggered on demand - CI for PR as a merge gate Issues filed: - https://github.com/Tendrl/usmqe-centos-ci/issues/14 - https://github.com/Tendrl/usmqe-centos-ci/issues/13 -- Best Regards, Martin Kudlej. RHSC/USM Senior Quality Assurance Engineer Red Hat Czech s.r.o. Phone: +420 532 294 155 E-mail:mkudlej at redhat.com IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, #usm-meeting @ redhat #tendrl-devel @ freenode From mbukatov at redhat.com Fri Jun 2 14:57:36 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 2 Jun 2017 16:57:36 +0200 Subject: [Tendrl-devel] repository for ceph-installer Message-ID: Dear all, the installation reference states: > configure the ceph-installer repo (as made available by the project) Could we be more precise and add a link to ceph-installer repositories we expect people to use? In usmqe-setup, we were using the following repositories for downstream testing right now: * https://shaman.ceph.com/api/repos/ceph-installer/master/latest/centos/7/noarch/noarch * https://shaman.ceph.com/api/repos/ceph-ansible/master/latest/centos/7/noarch/noarch * http://copr-be.cloud.fedoraproject.org/results/ktdreyer/ceph-installer/epel-7-x86_64/ as you can see there: https://github.com/Tendrl/usmqe-setup/blob/master/roles/ceph-installer-repo/tasks/main.yml Would that be fine for official tendrl ansible? -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Fri Jun 2 16:49:16 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 2 Jun 2017 18:49:16 +0200 Subject: [Tendrl-devel] node agent tags on Tendrl Server In-Reply-To: References: Message-ID: <4c857c52-20df-1fdb-e7a9-7d24f383651f@redhat.com> On 06/02/2017 07:49 AM, Rohan Kanade wrote: > - The tendrl-node-agent on the Tendrl server will auto detect the ceph > installer service and auto tag itself as "provisioner/ceph" What would trigger this self re tagging exactly? I just installed ceph-installer on Tendrl Server and node agent didn't updated the tags, restart of node agent didn't help. Note that ceph-installer service was running (which is the default state after installing tendrl-installer package). Also note that ceph-installer installation is mentioned after installation of node agent in the documentation[1]. When I tried to install ceph-installer first, and Tendrl Server components (including node agent) second, the ceph provisioner tag was not added either. Did I misunderstood the feature? Based on your explanation, I would either fix ansible code (clarification in the docs would be needed as well) - or file an issue. I'm using the latest upsteram release: # rpm -qa | grep tendrl tendrl-commons-1.4.0-1.el7.centos.noarch tendrl-api-1.4.0-1.el7.centos.noarch tendrl-api-httpd-1.4.0-1.el7.centos.noarch tendrl-node-agent-1.4.0-2.el7.centos.noarch tendrl-dashboard-1.4.0-2.el7.centos.noarch [1] https://github.com/Tendrl/documentation/wiki/Tendrl-Package-Installation-Reference -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Fri Jun 2 16:56:05 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 2 Jun 2017 18:56:05 +0200 Subject: [Tendrl-devel] repository for ceph-installer In-Reply-To: References: Message-ID: On 06/02/2017 04:57 PM, Martin Bukatovic wrote: > Would that be fine for official tendrl ansible? My proposal how to install ceph-installer for the purposes of Tendrl based on my current understaning is here: https://github.com/mbukatov/tendrl-ansible/tree/usmqe-reboot/roles/ceph-installer -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Fri Jun 2 17:27:13 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 2 Jun 2017 19:27:13 +0200 Subject: [Tendrl-devel] REST API consistency In-Reply-To: References: <8e1e89a1-2106-0209-a13b-96186d75fb60@redhat.com> Message-ID: ping On 06/01/2017 01:42 PM, Martin Bukatovic wrote: > ping > > On 05/30/2017 04:23 PM, Martin Kudlej wrote: >> Hi all, >> >> I would like to ask if there is any movement in this area? >> >> On 04/26/2017 09:58 AM, Martin Kudlej wrote: >>> Hi all, >>> >>> I think there is still time to unify Tendrl API functions according >>> some rules. >>> I've filed https://github.com/Tendrl/documentation/issues/70 couple of >>> months ago without response. >>> >>> One example for all. >>> There are these functions for Ceph cluster(Flows on cluster): >>> "name": "CephCreatePool", >>> "method": "POST", >>> >>> "name": "CephCreateECProfile", >>> "method": "POST", >>> >>> "name": "CephDeleteECProfile", >>> "method": "DELETE", >>> >>> "name": "CephCreateRbd", >>> "method": "POST", >>> >>> "name": "CephDeleteRbd", >>> "method": "DELETE", >>> >>> "name": "CephResizeRbd", >>> "method": "PUT", >>> >>> "name": "CephDeletePool", >>> "method": "DELETE", >>> >>> "name": "CephUpdatePool", >>> "method": "PUT", >>> >>> and according documentation there should be also >>> "name": "CephPoolList" >>> "method": "GET" >>> >>> I think that there should be also "GET" "CephPool" because of >>> performance. >>> >>> I think that these functions should be transformed avoiding verb >>> duplicity. Also I believe if API function names are renamed >>> integration with other projects will be much easier. >>> >>> Pool CRUD >>> "name": ":ceph_cluster_id:/pool", >>> "method": "POST", >>> >>> "name": ":ceph_cluster_id:/pool/:ceph_pool_id:", >>> "method": "GET", >>> >>> "name": ":ceph_cluster_id:/pool/:ceph_pool_id:", >>> "method": "PUT", >>> >>> "name": ":ceph_cluster_id:/pool/:ceph_pool_id:", >>> "method": "DELETE", >>> >>> RBD CRUD >>> >>> "name": ":ceph_cluster_id:/rbd", >>> "method": "POST", >>> >>> "name": ":ceph_cluster_id:/rbd/:ceph_pool_id:", >>> "method": "GET", >>> >>> "name": ":ceph_cluster_id:/rbd/:ceph_pool_id:", >>> "method": "PUT", >>> >>> "name": ":ceph_cluster_id:/rbd/:ceph_pool_id:", >>> "method": "DELETE", >>> >>> EC Profile CRUD >>> >>> "name": ":ceph_cluster_id:/ecprofile", >>> "method": "POST", >>> >>> "name": ":ceph_cluster_id:/ecprofile/:ec_profile_id:", >>> "method": "GET", >>> >>> (update if it is possible) >>> "name": ":ceph_cluster_id:/ecprofile/:ec_profile_id:", >>> "method": "PUT", >>> >>> "name": ":ceph_cluster_id:/ecprofile/:ec_profile_id:", >>> "method": "DELETE", >>> >>> >>> Lists >>> >>> "name": ":ceph_cluster_id:/pool" >>> "method": "GET" >>> >>> "name": ":ceph_cluster_id:/rbd" >>> "method": "GET" >>> >>> "name": ":ceph_cluster_id:/ecprofile" >>> "method": "GET" >>> >>> Please consider this rename until is not too late and there are not >>> many projects which are integrated with Tendrl. >>> >> > > -- Martin Bukatovic USM QE team Red Hat From rkanade at redhat.com Fri Jun 2 17:37:33 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Fri, 2 Jun 2017 23:07:33 +0530 Subject: [Tendrl-devel] REST API consistency In-Reply-To: References: <8e1e89a1-2106-0209-a13b-96186d75fb60@redhat.com> Message-ID: Anup, this topic seems like something you can discuss more about. @Martin While I dont have a problem with the RESTful structure suggested by you. Tendrl choose the Amazon AWS style [0] Action based http API style because it maps well with the Flows exposed by backend (1:1) I am not of favor of changing the current API style unless there's actual use cases for the style proposed by Martin. HTTP verbs mapped to Tendrl API actions/flows can be reviewed and corrected [0]: http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Operations.html On Fri, Jun 2, 2017 at 10:57 PM, Martin Bukatovic wrote: > ping > > On 06/01/2017 01:42 PM, Martin Bukatovic wrote: > > ping > > > > On 05/30/2017 04:23 PM, Martin Kudlej wrote: > >> Hi all, > >> > >> I would like to ask if there is any movement in this area? > >> > >> On 04/26/2017 09:58 AM, Martin Kudlej wrote: > >>> Hi all, > >>> > >>> I think there is still time to unify Tendrl API functions according > >>> some rules. > >>> I've filed https://github.com/Tendrl/documentation/issues/70 couple of > >>> months ago without response. > >>> > >>> One example for all. > >>> There are these functions for Ceph cluster(Flows on cluster): > >>> "name": "CephCreatePool", > >>> "method": "POST", > >>> > >>> "name": "CephCreateECProfile", > >>> "method": "POST", > >>> > >>> "name": "CephDeleteECProfile", > >>> "method": "DELETE", > >>> > >>> "name": "CephCreateRbd", > >>> "method": "POST", > >>> > >>> "name": "CephDeleteRbd", > >>> "method": "DELETE", > >>> > >>> "name": "CephResizeRbd", > >>> "method": "PUT", > >>> > >>> "name": "CephDeletePool", > >>> "method": "DELETE", > >>> > >>> "name": "CephUpdatePool", > >>> "method": "PUT", > >>> > >>> and according documentation there should be also > >>> "name": "CephPoolList" > >>> "method": "GET" > >>> > >>> I think that there should be also "GET" "CephPool" because of > >>> performance. > >>> > >>> I think that these functions should be transformed avoiding verb > >>> duplicity. Also I believe if API function names are renamed > >>> integration with other projects will be much easier. > >>> > >>> Pool CRUD > >>> "name": ":ceph_cluster_id:/pool", > >>> "method": "POST", > >>> > >>> "name": ":ceph_cluster_id:/pool/:ceph_pool_id:", > >>> "method": "GET", > >>> > >>> "name": ":ceph_cluster_id:/pool/:ceph_pool_id:", > >>> "method": "PUT", > >>> > >>> "name": ":ceph_cluster_id:/pool/:ceph_pool_id:", > >>> "method": "DELETE", > >>> > >>> RBD CRUD > >>> > >>> "name": ":ceph_cluster_id:/rbd", > >>> "method": "POST", > >>> > >>> "name": ":ceph_cluster_id:/rbd/:ceph_pool_id:", > >>> "method": "GET", > >>> > >>> "name": ":ceph_cluster_id:/rbd/:ceph_pool_id:", > >>> "method": "PUT", > >>> > >>> "name": ":ceph_cluster_id:/rbd/:ceph_pool_id:", > >>> "method": "DELETE", > >>> > >>> EC Profile CRUD > >>> > >>> "name": ":ceph_cluster_id:/ecprofile", > >>> "method": "POST", > >>> > >>> "name": ":ceph_cluster_id:/ecprofile/:ec_profile_id:", > >>> "method": "GET", > >>> > >>> (update if it is possible) > >>> "name": ":ceph_cluster_id:/ecprofile/:ec_profile_id:", > >>> "method": "PUT", > >>> > >>> "name": ":ceph_cluster_id:/ecprofile/:ec_profile_id:", > >>> "method": "DELETE", > >>> > >>> > >>> Lists > >>> > >>> "name": ":ceph_cluster_id:/pool" > >>> "method": "GET" > >>> > >>> "name": ":ceph_cluster_id:/rbd" > >>> "method": "GET" > >>> > >>> "name": ":ceph_cluster_id:/ecprofile" > >>> "method": "GET" > >>> > >>> Please consider this rename until is not too late and there are not > >>> many projects which are integrated with Tendrl. > >>> > >> > > > > > > > -- > 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 Fri Jun 2 19:28:23 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Sat, 3 Jun 2017 00:58:23 +0530 Subject: [Tendrl-devel] node agent tags on Tendrl Server In-Reply-To: <4c857c52-20df-1fdb-e7a9-7d24f383651f@redhat.com> References: <4c857c52-20df-1fdb-e7a9-7d24f383651f@redhat.com> Message-ID: Seems like a valid issue, can you open a issue on https://github.com/Tendrl/node-agent/issues Please share the environment via pm On Fri, Jun 2, 2017 at 10:19 PM, Martin Bukatovic wrote: > On 06/02/2017 07:49 AM, Rohan Kanade wrote: > > - The tendrl-node-agent on the Tendrl server will auto detect the ceph > > installer service and auto tag itself as "provisioner/ceph" > What would trigger this self re tagging exactly? I just installed > ceph-installer on Tendrl Server and node agent didn't updated the > tags, restart of node agent didn't help. > > Note that ceph-installer service was running (which is the default > state after installing tendrl-installer package). > > Also note that ceph-installer installation is mentioned after > installation of node agent in the documentation[1]. > > When I tried to install ceph-installer first, and Tendrl Server > components (including node agent) second, the ceph provisioner > tag was not added either. > > Did I misunderstood the feature? Based on your explanation, I > would either fix ansible code (clarification in the docs would > be needed as well) - or file an issue. > > I'm using the latest upsteram release: > > # rpm -qa | grep tendrl > tendrl-commons-1.4.0-1.el7.centos.noarch > tendrl-api-1.4.0-1.el7.centos.noarch > tendrl-api-httpd-1.4.0-1.el7.centos.noarch > tendrl-node-agent-1.4.0-2.el7.centos.noarch > tendrl-dashboard-1.4.0-2.el7.centos.noarch > > > [1] > https://github.com/Tendrl/documentation/wiki/Tendrl- > Package-Installation-Reference > > -- > 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 julim at redhat.com Fri Jun 2 20:20:59 2017 From: julim at redhat.com (Ju Lim) Date: Fri, 2 Jun 2017 16:20:59 -0400 Subject: [Tendrl-devel] File Share (aka Gluster Volume) creation wizard In-Reply-To: References: Message-ID: Daniel et al: Just a heads-up that we've updated the Create File Share workflow -- see Create File Share design -- to clarify the questions you raised. Regards, Ju On Wed, May 31, 2017 at 4:03 PM, Ju Lim wrote: > Hi Daniel: > > Thanks for starting this thread as there appears to be a difference > between our design vs. implementation. > > Some assumptions before I go into answering your questions: > > For Tendrl, we will initially support 2 types of volumes: > > - 3-way distributed replicated > - Erasure Coded (4+2 with min 6 bricks, 8+3 with min 11 bricks, 8+4 > with min 12 bricks) > > Note: 2-way distributed replicated is left off as we will plan arbiter > volumes to cover that scenario in the future. > > For the 3-way distributed replicated, per the official documentation > > : > > The number of bricks must be a multiple of the replica count for a > distributed replicated volume. Also, the order in which bricks are > specified has a great effect on data protection. > > Each replica_count consecutive bricks in the list you give will form a > replica set, with all replica sets combined into a distribute set. To > ensure that replica-set members are not placed on the same node, list the > first brick on every server, then the second brick on every server in the > same order, and so on. > > So, in other words, if we had a 3-way dist-rep, that means it?s 3 > consecutive bricks to form a replica set. So, if you?re using 6 nodes > (with 1 brick each), that would mean 2 replica sets. > > Ideally, user should not have to input Bricks per Replica set, and System > should be able to compute this, i.e. > > # bricks per replica set == replica_count > > # replica sets == # of bricks / replica_count > > Thus, we should remove the ?Bricks per Replica Set? from the design. > > > For EC (distributed dispersed) volumes, the 2 parameters needed are > typically: > > - disperse-data_count == k or the number of bricks that is part of the > dispersed volume, excluding the count of the redundant bricks > > > - redundancy_count (optional parameter) == m or # of bricks that can > fail without losing data, i.e. m > > > To answer your questions for the Create File Share (aka create gluster > volume): > > > What exactly means the "Bricks per Replica Set" value on Create File Share > - Layout[1] page? > > - This was intended to help with the visualization of the layout but I > don?t think it?s needed and probably should be removed. (It was a bit of > heritage from the old console.) > > > - Is it related to replication or distribution? It isn?t. > > > Some observations from the current implemented Create File Share workflow: > > - The combined Type (Distributed Replicated) + Replica Count {2 or 3} > == 2-way or 3-way distributed replicated. This is not to design as we > collapsed this to 3-way distributed replicated for the Type in our design > to simplify the user experience. > - The Distribution Count is not in our design and it?s not even > specified in the Gluster CLI for in the related Tendrl specs that I could > find, so I?m not sure what this is for. I thought perhaps it was for > something EC-related, but there?s currently no way to specify EC in the UI > for creating the volume. Per https://github.com/Tendrl/ > specifications/blob/33eabe3123b290bd030a94b30fdde7 > 09253539f8/specs/segragate_object_specific_flows.adoc > , > the volume inputs expected are volume.volname, volume.bricks and optionally: > > - Volume.stripe_count > - Volume.replica_count > - Volume.arbiter_count > - Volume.disperse_count > - Volume.disperse_data_count > - Volume.redundancy_count > - Volume.transport > - Volume.force > > > Related References: > > - Create File Share workflow: https://redhat.invisionapp. > com/share/Q78YMAVDJ#/screens/217726640 > > - Gaps of design vs. implementation: https://bugzilla.redhat.com/ > show_bug.cgi?id=1456418#c3 > - Spec for Create Volume: ? Distribution Count was> > - Tendrl-gdeploy wrapper spec: https://github.com/Tendrl/ > specifications/blob/8c19e6af7a459bf6a6070fca2bbe3e > f710aff819/specs/tendrl_gdeploy_wrapper.adoc > > - Segregate object specific flows: https://github.com/Tendrl/ > specifications/blob/33eabe3123b290bd030a94b30fdde7 > 09253539f8/specs/segragate_object_specific_flows.adoc > > - UI code references for distribution count: https://github.com/Tendrl/ > dashboard/search?utf8=%E2%9C%93&q=distribution+count&type= > > > > As a last note, we will update the Create File Share design to remove the > 2-way distributed-replicated and the Bricks per Replica Set field, and > update the sample workflow. > > > I hope this clarifies any confusion. If needed and it makes sense, please > feel free to schedule a meeting to discuss this to get everyone on the same > page. > > > Thank you, > Ju > > On Wed, May 31, 2017 at 4:14 AM, Daniel Hor?k wrote: > >> Hi Ju, >> >> I have few questions related to File Share (aka Gluster Volume) creation >> wizard. >> >> What exactly means the "Bricks per Replica Set" value on Create File >> Share - Layout[1] page? >> Is it related to replication or distribution? I think it should be >> related to "distribution" (because Replication might be set only to 2 or >> 3), but I'm not sure how exactly. >> >> And also there seems to be some misunderstanding between the design and >> real implementation[2]. >> >> [1] https://redhat.invisionapp.com/share/Q78YMAVDJ#/screens/228991297 >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1456418#c3 >> >> Thanks, >> Daniel >> > > > > -- Ju Lim Red Hat Office: 978-399-0422 Mobile: 781-507-1323 Email: julim at redhat.com IRC: julim From mbukatov at redhat.com Fri Jun 2 20:26:11 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 2 Jun 2017 22:26:11 +0200 Subject: [Tendrl-devel] node agent tags on Tendrl Server In-Reply-To: References: <4c857c52-20df-1fdb-e7a9-7d24f383651f@redhat.com> Message-ID: On 06/02/2017 09:28 PM, Rohan Kanade wrote: > Seems like a valid issue, can you open a issue on > https://github.com/Tendrl/node-agent/issues > > Please share the environment via pm Seems like I did look at wrong place, I retried the scenario (installing ceph-ansible later) when I wait a bit, I see the tag added: # etcdctl --endpoints "http://10.34.108.90:2379" get /indexes/tags/provisioner/ceph ["4fc5d13a-a2db-40ae-b4cf-e9bad9f70a09"] # etcdctl --endpoints "http://10.34.108.90:2379" get /indexes/machine_id/afaa14aad3604ce1ae8f2c2e795cd1a7 4fc5d13a-a2db-40ae-b4cf-e9bad9f70a09 # cat /etc/machine-id afaa14aad3604ce1ae8f2c2e795cd1a7 Sorry for the confusion. That said, could you show a little light on the original question I had: what would trigger this self re tagging exactly? At this point, I'm just curious. -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Fri Jun 2 20:41:00 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 2 Jun 2017 22:41:00 +0200 Subject: [Tendrl-devel] status of tendrl-ansible reboot Message-ID: <4d7f5343-a84b-cd77-657d-f89f3d2df7a2@redhat.com> Dear all, Based on ansible code from ``usmqe-setup``, ``tendrl-ansible`` and current upstream installation documentation[1], I have created new branch ``usmqe_reboot`` in https://github.com/mbukatov/tendrl-ansible repository with proposed new structure of ansible roles for Tendrl installation. As you are likely aware, we plan to replace Tendrl/tendrl-ansible repo with my new branch I'm announcing here in the end. The work is not fully finished (see details below), but if you are interested, you can review the current state and provide feedback. The main idea is described in: https://tendrl.atlassian.net/browse/TEN-257 Implementation and comparison wit others ---------------------------------------- Changes compared to ``usmqe-setup`` include: * different structure of roles (less granular, based solely on documentation[1] with production type deployment in mind) * in few places, configuration was updated to match what is stated in the docs[1] * some qe hacks removed Changes compared to tendrl-ansible: * license is *Apache 2.0*, which I consider a better choice here (both ``ceph-ansible`` and ``usmqe-setup`` uses it as well) * repositories are not enabled in the roles directly, but there is a separate role for tendrl copr for the release * there is support for upstream only * there is no default playbook site.yml, but a commented example which could be easily tweaked for particular deployment (this is similar to what ceph-ansible is doing) - TODO: not yet commited * roles doesn't try to guess or derive ip addressess for tendrl components, values of ip adressess are passed via variables instead (will be demostrated in example playbook) Other assumptions: * I tried to make the Tendrl roles general, so that one could use them both downstrem and upstream. * I tried to follow good ansible practices, so that one could eg. rerun the playbook just to check that the machines are configured as expected without restarting any service (unless necessary). This is useful for reconfiguration as well. * We are not going to publish the roles on ansible galaxy (at least until we understand the consequences for both upstream and downstream), so the roles contain no ansible galaxy metadata to avoid confusion. We can consider publishing roles on galaxy later, when we have more experiences, time and disuccsion with ansible team. * Works on CentOS 7 only (eg. it would not work on RHEL) - which matches both requirements and documentation. This allowed to siplify tendrl-copr role, moreover we test upstream on CentOS only anyway. * Role tendrl-copr installs repositories for Tendrl Upstream Release only. * We can add *new role* to setup repos of non release builds (such as master or develop ones) later when/if needed. But I don't see a need for this now, qe team have this in usmqe-setup for testing already. * Tendlr roles doesn't have hard dependency on tendrl-copr role, so that: one can use different role to setup repositories without changing any of the Tendrl roles (roles would be reusable downstream or adding testing role as suggested in previous point would be possible). * Checks suggested by Jeff are implemented in separate playbook - so that it's easier to reuse them. What is missing and needs to be done ------------------------------------ I still need to verify my understanding of few details (see tendrl-list for my questions) and make sure the docs are updated if needed. Moreover I need think more about configuration of ip addressess of tendrl components. cover all possibilities of tendrl-alerting email configuration Next week qe team will try to reuse this new ansible code in our CI and compare the test result with previous deployment automation. In other words, we need to check that it actually works. Add sowhere `useradd tendrl-user -g tendrl` for tendrl alerting. I also need to check if we have an issue for this ... Do a separate playbook for basic pre-checks. Add a separate playbook for selinux and firewall configuration - which we don't have at this point - it would just turn it off if I read the docs right ... Ask Chriss Blum to recreate vagrant scripts. I plan to have a separate playbook for vagrant use case, something like vagrant.yml, which would be usable without any tweaking via vagrant. I tried to design the roles to make this possible via specifying configuration variables in a playbook instead of adding checks/when statements directly into the roles. [1] https://github.com/Tendrl/documentation/wiki/Tendrl-Package-Installation-Reference -- Martin Bukatovic USM QE team Red Hat From rkanade at redhat.com Fri Jun 2 21:57:58 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Sat, 3 Jun 2017 03:27:58 +0530 Subject: [Tendrl-devel] node agent tags on Tendrl Server In-Reply-To: References: <4c857c52-20df-1fdb-e7a9-7d24f383651f@redhat.com> Message-ID: No worries, - Tendrl is interested in these services ( https://github.com/Tendrl/node-agent/blob/develop/tendrl/node_agent/node_sync/__init__.py#L26 ) - When tendrl-node-agent detects any of above services running during its sync cycle [0], It checks from this map of service-to-tendrl_tags [1] and assigns that tag to itself [2] (the node-agent) [0]: https://github.com/Tendrl/node-agent/blob/develop/tendrl/node_agent/node_sync/__init__.py#L30 [1]: https://github.com/Tendrl/commons/blob/develop/tendrl/commons/objects/definition/master.yaml#L22 [2]: https://github.com/Tendrl/node-agent/blob/develop/tendrl/node_agent/node_sync/__init__.py#L63 On Sat, Jun 3, 2017 at 1:56 AM, Martin Bukatovic wrote: > On 06/02/2017 09:28 PM, Rohan Kanade wrote: > > Seems like a valid issue, can you open a issue on > > https://github.com/Tendrl/node-agent/issues > > > > Please share the environment via pm > > Seems like I did look at wrong place, I retried the scenario (installing > ceph-ansible later) when I wait a bit, I see the tag added: > > # etcdctl --endpoints "http://10.34.108.90:2379" get > /indexes/tags/provisioner/ceph > ["4fc5d13a-a2db-40ae-b4cf-e9bad9f70a09"] > > # etcdctl --endpoints "http://10.34.108.90:2379" get > /indexes/machine_id/afaa14aad3604ce1ae8f2c2e795cd1a7 > 4fc5d13a-a2db-40ae-b4cf-e9bad9f70a09 > > # cat /etc/machine-id > > afaa14aad3604ce1ae8f2c2e795cd1a7 > > Sorry for the confusion. > > That said, could you show a little light on the original question I had: > what would trigger this self re tagging exactly? At this point, I'm just > curious. > > -- > 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 anbabu at redhat.com Sat Jun 3 17:17:10 2017 From: anbabu at redhat.com (Anmol Babu) Date: Sat, 3 Jun 2017 13:17:10 -0400 (EDT) Subject: [Tendrl-devel] PR review request In-Reply-To: <1680456300.14834381.1496509814327.JavaMail.zimbra@redhat.com> Message-ID: <325975950.14835847.1496510230636.JavaMail.zimbra@redhat.com> Rohan, I am writing this mail in accordance with your suggestion to mention the below PRs on the mailing list.. @nishanth @shubhendu @rohan Please review the following PRs: [1] https://github.com/Tendrl/performance-monitoring/pull/180 [2] https://github.com/Tendrl/node-monitoring/pull/44 [3] https://github.com/Tendrl/node-agent/pull/484 Note: PR [1] above fixes an issue in gluster dashboard when there are no volumes.. PR [2] above fixes an issue with showing incorrect utilization sync by collectd (The issue also needs to be fixed on gluster-integration: https://github.com/Tendrl/gluster-integration/issues/283) PR [3] above fixes https://bugzilla.redhat.com/show_bug.cgi?id=1456552 Anmol Babu Software Engineer Red Hat India Pvt Ltd M: 8884245644 From japplewh at redhat.com Mon Jun 5 01:51:28 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Sun, 4 Jun 2017 21:51:28 -0400 Subject: [Tendrl-devel] question on storage node GUIDs Message-ID: Hi All I have a test bed where I had 8 nodes. 3 of them were in an existing ceph cluster. 1 was in a single node Ceph cluster. I deleted the one standalone cluster and rebuilt the node completely to a "fresh centos" install. It is no longer registered at all. That brings me to a total of 7 registered nodes out of the previous 8 and 1 pre-existing 3 node ceph cluster. I then deleted the etcd data on the tendrl node, reinstalled etcd, recreated the admin user, and restarted all the node agents on the storage nodes. Now granted this is less than a "clean install" procedure but I would have hoped to see the node agents re-register with the new etcd/api/tendrl node, despite having previously been registered to a tendrl node that was in the same IP/Port location. I would also expect to see my pre-existing ceph cluster show up for importing - which it did..so I successfully re-imported it -- nice! But - I really should now expect to see [root at tendrl ~]# etcdctl --endpoints http://tendrl:2379 ls /nodes| wc -l 7 when in fact I see.. [root at tendrl ~]# etcdctl --endpoints http://tendrl:2379 ls /nodes| wc -l 15 or 7 "new nodes" + 8 "old nodes" = 15 -- so in essence all the nodes seem to generate a new id within etcd when they register, but their old GUID also gets into etcd somehow.. I think this behavior might be problematic for some users. In a large cluster it would be nice to be able to flush etcd (or some subset of it), restart the node agents and have them re-appear with their old GUID (not a new GUID and the old one too). Can someone explain the current behavior and the rationale? There might be good technical reasons for the behavior but I'd like to understand them. I'd rather not file a bug until I understand a little better what is going on here. It seems like maybe the Tendrl node needs some way to detect this case: "oh - I have a Tendrl storage node agent reporting to me and it seems to have a previous identity, maybe I should just re-use that GUID instead of generating a new one" or... maybe the "old" node agent should be whacked on the head and told "no your old GUID is no good around here - use this one instead!" Either behavior would prevent more GUIDs than nodes in etcd. Thoughts? Jeff From anivargi at redhat.com Mon Jun 5 11:11:51 2017 From: anivargi at redhat.com (Anup Nivargi) Date: Mon, 5 Jun 2017 07:11:51 -0400 (EDT) Subject: [Tendrl-devel] REST API consistency In-Reply-To: References: <8e1e89a1-2106-0209-a13b-96186d75fb60@redhat.com> Message-ID: <935742345.16949420.1496661111259.JavaMail.zimbra@redhat.com> Hi, We completely agree that the API endpoints need to be consistent. But, given the UI integration at this point of time with the existing API's and upcoming features, making the change is rather difficult immediately. This has been planned as a part of the performance optimization hackathon in coming weeks (no date has been finalized yet). Thanks. -Anup NIVARGI ----- Original Message ----- From: "Rohan Kanade" To: "Mailing list for the contributors to the Tendrl project" Cc: "Anup Nivargi" Sent: Friday, 2 June, 2017 11:07:33 PM Subject: Re: [Tendrl-devel] REST API consistency Anup, this topic seems like something you can discuss more about. @Martin While I dont have a problem with the RESTful structure suggested by you. Tendrl choose the Amazon AWS style [0] Action based http API style because it maps well with the Flows exposed by backend (1:1) I am not of favor of changing the current API style unless there's actual use cases for the style proposed by Martin. HTTP verbs mapped to Tendrl API actions/flows can be reviewed and corrected [0]: http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Operations.html On Fri, Jun 2, 2017 at 10:57 PM, Martin Bukatovic wrote: > ping > > On 06/01/2017 01:42 PM, Martin Bukatovic wrote: > > ping > > > > On 05/30/2017 04:23 PM, Martin Kudlej wrote: > >> Hi all, > >> > >> I would like to ask if there is any movement in this area? > >> > >> On 04/26/2017 09:58 AM, Martin Kudlej wrote: > >>> Hi all, > >>> > >>> I think there is still time to unify Tendrl API functions according > >>> some rules. > >>> I've filed https://github.com/Tendrl/documentation/issues/70 couple of > >>> months ago without response. > >>> > >>> One example for all. > >>> There are these functions for Ceph cluster(Flows on cluster): > >>> "name": "CephCreatePool", > >>> "method": "POST", > >>> > >>> "name": "CephCreateECProfile", > >>> "method": "POST", > >>> > >>> "name": "CephDeleteECProfile", > >>> "method": "DELETE", > >>> > >>> "name": "CephCreateRbd", > >>> "method": "POST", > >>> > >>> "name": "CephDeleteRbd", > >>> "method": "DELETE", > >>> > >>> "name": "CephResizeRbd", > >>> "method": "PUT", > >>> > >>> "name": "CephDeletePool", > >>> "method": "DELETE", > >>> > >>> "name": "CephUpdatePool", > >>> "method": "PUT", > >>> > >>> and according documentation there should be also > >>> "name": "CephPoolList" > >>> "method": "GET" > >>> > >>> I think that there should be also "GET" "CephPool" because of > >>> performance. > >>> > >>> I think that these functions should be transformed avoiding verb > >>> duplicity. Also I believe if API function names are renamed > >>> integration with other projects will be much easier. > >>> > >>> Pool CRUD > >>> "name": ":ceph_cluster_id:/pool", > >>> "method": "POST", > >>> > >>> "name": ":ceph_cluster_id:/pool/:ceph_pool_id:", > >>> "method": "GET", > >>> > >>> "name": ":ceph_cluster_id:/pool/:ceph_pool_id:", > >>> "method": "PUT", > >>> > >>> "name": ":ceph_cluster_id:/pool/:ceph_pool_id:", > >>> "method": "DELETE", > >>> > >>> RBD CRUD > >>> > >>> "name": ":ceph_cluster_id:/rbd", > >>> "method": "POST", > >>> > >>> "name": ":ceph_cluster_id:/rbd/:ceph_pool_id:", > >>> "method": "GET", > >>> > >>> "name": ":ceph_cluster_id:/rbd/:ceph_pool_id:", > >>> "method": "PUT", > >>> > >>> "name": ":ceph_cluster_id:/rbd/:ceph_pool_id:", > >>> "method": "DELETE", > >>> > >>> EC Profile CRUD > >>> > >>> "name": ":ceph_cluster_id:/ecprofile", > >>> "method": "POST", > >>> > >>> "name": ":ceph_cluster_id:/ecprofile/:ec_profile_id:", > >>> "method": "GET", > >>> > >>> (update if it is possible) > >>> "name": ":ceph_cluster_id:/ecprofile/:ec_profile_id:", > >>> "method": "PUT", > >>> > >>> "name": ":ceph_cluster_id:/ecprofile/:ec_profile_id:", > >>> "method": "DELETE", > >>> > >>> > >>> Lists > >>> > >>> "name": ":ceph_cluster_id:/pool" > >>> "method": "GET" > >>> > >>> "name": ":ceph_cluster_id:/rbd" > >>> "method": "GET" > >>> > >>> "name": ":ceph_cluster_id:/ecprofile" > >>> "method": "GET" > >>> > >>> Please consider this rename until is not too late and there are not > >>> many projects which are integrated with Tendrl. > >>> > >> > > > > > > > -- > 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 mkudlej at redhat.com Mon Jun 5 11:26:28 2017 From: mkudlej at redhat.com (Martin Kudlej) Date: Mon, 5 Jun 2017 13:26:28 +0200 Subject: [Tendrl-devel] REST API consistency In-Reply-To: References: <8e1e89a1-2106-0209-a13b-96186d75fb60@redhat.com> Message-ID: Hi Rohan, thank you for your response. My comments are inline. On 06/02/2017 07:37 PM, Rohan Kanade wrote: > Anup, this topic seems like something you can discuss more about. > > @Martin > > While I dont have a problem with the RESTful structure suggested by you. > Tendrl choose the Amazon AWS style [0] Action based http API style because > it maps well with the Flows exposed by backend (1:1) I've checked Amazon AWS and there are logical differences between Tendrl API and Amazon AWS API. Amazon AWS API uses only HTTP GET method. Data is transferred as url attributes. Example request: curl https://ec2.amazonaws.com/?Action=CreateNatGateway &SubnetId=subnet-1a2b3c4d &AllocationId=eipalloc-37fc1a52 &AUTHPARAMS As you can see verb(Create) and subject(NatGateway) are stored in function name and data is transferred as url attributes(SubnetId, AllocationId). On the other hand REST API mentioned by me has verb in HTTP action(GET, POST, PUT, DELETE) and subject is identified by id in collection in url(/natgateway/:id:). Translated AWS example: curl -X POST -d '{"SubnetId":"subnet-1a2b3c4d", "AllocationId":"eipalloc-37fc1a52"}' /natgateway Another AWS example: curl https://ec2.amazonaws.com/?Action=DeleteNatGateway &NatGatewayId=nat-04ae55e711cec5680 &AUTHPARAMS and translated one: curl -X DELETE /natgateway/nat-04ae55e711cec5680 Now Tendrl API doesn't follow Amazon AWS API and it doesn't follow rules for REST API based on HTTP verbs. Here is documentation https://github.com/Tendrl/documentation/blob/master/api/overview.adoc for building Tendrl API. It seems to me that Tendrl API would follow API based on HTTP verbs. So I think that current Tendrl API should be changed. > I am not of favor of changing the current API style unless there's actual > use cases for the style proposed by Martin. I understand that in this project phase it is probably too late to change API. But we should think also about potential long term API support because of some integration with other projects. I think it is still time to change this and avoid potential problems in future. > HTTP verbs mapped to Tendrl API actions/flows can be reviewed and corrected Sure, I'll check if there is any issue once my concerns above are clear. > > [0]: > http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Operations.html > > On Fri, Jun 2, 2017 at 10:57 PM, Martin Bukatovic > wrote: > >> ping >> >> On 06/01/2017 01:42 PM, Martin Bukatovic wrote: >>> ping >>> >>> On 05/30/2017 04:23 PM, Martin Kudlej wrote: >>>> Hi all, >>>> >>>> I would like to ask if there is any movement in this area? >>>> >>>> On 04/26/2017 09:58 AM, Martin Kudlej wrote: >>>>> Hi all, >>>>> >>>>> I think there is still time to unify Tendrl API functions according >>>>> some rules. >>>>> I've filed https://github.com/Tendrl/documentation/issues/70 couple of >>>>> months ago without response. >>>>> >>>>> One example for all. >>>>> There are these functions for Ceph cluster(Flows on cluster): >>>>> "name": "CephCreatePool", >>>>> "method": "POST", >>>>> >>>>> "name": "CephCreateECProfile", >>>>> "method": "POST", >>>>> >>>>> "name": "CephDeleteECProfile", >>>>> "method": "DELETE", >>>>> >>>>> "name": "CephCreateRbd", >>>>> "method": "POST", >>>>> >>>>> "name": "CephDeleteRbd", >>>>> "method": "DELETE", >>>>> >>>>> "name": "CephResizeRbd", >>>>> "method": "PUT", >>>>> >>>>> "name": "CephDeletePool", >>>>> "method": "DELETE", >>>>> >>>>> "name": "CephUpdatePool", >>>>> "method": "PUT", >>>>> >>>>> and according documentation there should be also >>>>> "name": "CephPoolList" >>>>> "method": "GET" >>>>> >>>>> I think that there should be also "GET" "CephPool" because of >>>>> performance. >>>>> >>>>> I think that these functions should be transformed avoiding verb >>>>> duplicity. Also I believe if API function names are renamed >>>>> integration with other projects will be much easier. >>>>> >>>>> Pool CRUD >>>>> "name": ":ceph_cluster_id:/pool", >>>>> "method": "POST", >>>>> >>>>> "name": ":ceph_cluster_id:/pool/:ceph_pool_id:", >>>>> "method": "GET", >>>>> >>>>> "name": ":ceph_cluster_id:/pool/:ceph_pool_id:", >>>>> "method": "PUT", >>>>> >>>>> "name": ":ceph_cluster_id:/pool/:ceph_pool_id:", >>>>> "method": "DELETE", >>>>> >>>>> RBD CRUD >>>>> >>>>> "name": ":ceph_cluster_id:/rbd", >>>>> "method": "POST", >>>>> >>>>> "name": ":ceph_cluster_id:/rbd/:ceph_pool_id:", >>>>> "method": "GET", >>>>> >>>>> "name": ":ceph_cluster_id:/rbd/:ceph_pool_id:", >>>>> "method": "PUT", >>>>> >>>>> "name": ":ceph_cluster_id:/rbd/:ceph_pool_id:", >>>>> "method": "DELETE", >>>>> >>>>> EC Profile CRUD >>>>> >>>>> "name": ":ceph_cluster_id:/ecprofile", >>>>> "method": "POST", >>>>> >>>>> "name": ":ceph_cluster_id:/ecprofile/:ec_profile_id:", >>>>> "method": "GET", >>>>> >>>>> (update if it is possible) >>>>> "name": ":ceph_cluster_id:/ecprofile/:ec_profile_id:", >>>>> "method": "PUT", >>>>> >>>>> "name": ":ceph_cluster_id:/ecprofile/:ec_profile_id:", >>>>> "method": "DELETE", >>>>> >>>>> >>>>> Lists >>>>> >>>>> "name": ":ceph_cluster_id:/pool" >>>>> "method": "GET" >>>>> >>>>> "name": ":ceph_cluster_id:/rbd" >>>>> "method": "GET" >>>>> >>>>> "name": ":ceph_cluster_id:/ecprofile" >>>>> "method": "GET" >>>>> >>>>> Please consider this rename until is not too late and there are not >>>>> many projects which are integrated with Tendrl. >>>>> >>>> >>> >>> >> >> >> -- >> Martin Bukatovic >> USM QE team >> Red Hat >> >> _______________________________________________ >> 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 > -- 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 fbalak at redhat.com Mon Jun 5 14:43:01 2017 From: fbalak at redhat.com (Filip Balak) Date: Mon, 5 Jun 2017 10:43:01 -0400 (EDT) Subject: [Tendrl-devel] Parallel processing of tasks and events In-Reply-To: <67556345.15906801.1496672937441.JavaMail.zimbra@redhat.com> Message-ID: <337321263.15911797.1496673781864.JavaMail.zimbra@redhat.com> Hi Anmol, does Tendrl support parallel processing of tasks and events? For example: are job events that install ceph on nodes during CephClusterCreate job installed paralelly? Is importing of two clusters running simultinously or are they waiting on each other? Best Regards, Filip Balak From rkanade at redhat.com Mon Jun 5 16:13:33 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Mon, 5 Jun 2017 21:43:33 +0530 Subject: [Tendrl-devel] Parallel processing of tasks and events In-Reply-To: <337321263.15911797.1496673781864.JavaMail.zimbra@redhat.com> References: <67556345.15906801.1496672937441.JavaMail.zimbra@redhat.com> <337321263.15911797.1496673781864.JavaMail.zimbra@redhat.com> Message-ID: Ill try to explain this one, As we all know, Tendrl is a collection concrete namespaces of flows/objects/atoms [0] Each flow in above namespaces can be invoked (via the tendrl-api using http or curl or Tendrl-dashboard) and pushed to Tendrl central store Each flow in these namespaces can also be invoked directly by pushing a Tendrl job to Tendrl central store location "/queue/:job_id/", Sample jobs [1] can be found in "etc" dir of any Tendrl repo (Tendrl/node-agent, ceph-integration This is when Tendrl Jobs are picked up in Parallel: - Each Tendrl Job has a "type" ["node", "monitoring", "sds"] which are processed by these processes respectively: tendrl-node-agent, tendrl-node-monitoring and tendrl-{ceph, gluster}-integrations - Total parallel jobs for a 10 node tendrl managed cluster with all 3 services installed (tendrl-node-agent, tendrl-node-monitoring, tendrl-ceph or gluster-integration) = 30 Moving beyond above basics, every Tendrl Job runs a Tendrl Flow [2] which executes pre run validations, executes the atoms/actions required to complete the flow, post run validations , all of this happens serially for now. But we should Identify steps for each tendrl flow which can be run in parallel without requiring inputs from the previous actions in the flow. Now moving on specific examples, Tendrl CreateCluster job for ceph is executes a Flow which calls the Tendrl provisioning wrapper for ceph-installer. This wrapper exploits all parallel exec capabilities of ceph-installer [3], more inputs welcome. Similar to that we use a wrapper python-gdeploy which consumes gdeploy features and helps Tendrl deal with gluster. In the coming week or two, the dev team has included an item in the performance-monitoring hackathon which deals with creating topic queues (like in rabbitmq) in etcd for Tendrl central store, which can be used to distribute tendrl jobs more efficiently, will share more details of the performance hackathon soon. [0]: https://github.com/Tendrl/commons/pull/285#issuecomment-288370228 [1]: https://github.com/Tendrl/node-agent/blob/develop/etc/create_ceph_cluster_sample_job.py [2] : https://github.com/Tendrl/commons/blob/develop/tendrl/commons/objects/definition/master.yaml#L24 [3] : http://docs.ceph.com/ceph-installer/docs/#install-operations On Mon, Jun 5, 2017 at 8:13 PM, Filip Balak wrote: > Hi Anmol, > > does Tendrl support parallel processing of tasks and events? For example: > are job events that install ceph on nodes during CephClusterCreate job > installed paralelly? Is importing of two clusters running simultinously or > are they waiting on each other? > > Best Regards, > > Filip Balak > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > From anbabu at redhat.com Mon Jun 5 17:08:13 2017 From: anbabu at redhat.com (Anmol Babu) Date: Mon, 5 Jun 2017 13:08:13 -0400 (EDT) Subject: [Tendrl-devel] Parallel processing of tasks and events In-Reply-To: <337321263.15911797.1496673781864.JavaMail.zimbra@redhat.com> References: <337321263.15911797.1496673781864.JavaMail.zimbra@redhat.com> Message-ID: <1285167179.15713638.1496682493469.JavaMail.zimbra@redhat.com> Hi Filip, The way the tasks processing works is as follows: Summary: 1. Every task(for which I am somehow accustomed to use the term "job" :) ) in tendrl starts with an entry in /queue in etcd. Note: a. Currently, this queue is one single/global queue across all integrations of tendrl. b. Entries in /queue corresponding to each job(failed, successfully executed or new(not-yet picked)) exist for a definitive interval of time after which they get erased automatically in etcd This makes use of ttl feature provided by etcd... Note: @rohan will be better able to add more details and/or correct me if I am wrong.. Personally I feel from the perspective of performance, i. It might be better to have per-component/integration specific queue with ttl ii. Move the completed and/or failed jobs to some other global queue. A combination or at-least one or both of these can prove to be really very useful for bigger deployments... 2. Now execution of any and every job is essentially an execution of a set of atomic operations(atoms in tendrl terminology) preceded(pre) and followed(post) by atoms that validate the applicability/suitability/validity as applicable of the job on the tendrl managed resource and validation of success or failure of job execution accordingly.. 3. Any job in tendrl is meant to be executed by a specific tendrl-module and can be even targeted to a specific node or even a collection of nodes depending on i. Type of job ii. Purpose of job iii. User input/choice as applicable and with suitable validations and best/recommended perspectives in view. 4. So, given 1,2 and 3 above, tendrl-integrations scan through every entry in /queue of etcd and pick the jobs that are 1. marked status new(not finished which indicates the job is already processed and executed or failed which indicates that the job execution failed) 2. relevant/targeted to them and then they validate(pre and post atoms) and execute them..(This is the reason for my thoughts in point 1 above) This is in accordance with a match between i. Tags tagged to the integration module(some via entries in the integration's conf file and some based on what the integration module is meant for) and ii. Tags contained in job specific details in /queue in etcd... This Note: a. The job to constituent validation + execution atoms mapping is maintained as part of integration module specific definitions(which is also pushed to etcd in '_NS//definitions' in etcd b. The tendrl object definitions are also maintained in above mentioned location as part of integration-specific definitions So given 1, 2, 3 and 4, job execution runs parallely between the integration modules unless serialized explicitly by the job only if required/applicable(as per implementation of job)... But the scan of /queue in etcd essentially is through a possibly huge list... Atleast from the perspective of monitoring, currently what happens is per node, per collectd plugin jobs are loaded to /queue to generate a collectd configuration file.. To give an idea of what this means, let see an example: i. Per node that is not part of any cluster, we have memory, cpu, swap, mount-point, disk, dbpush(push stats to graphite), latency which means 7 jobs. ii. In addition on every gluster node, there will be 4 more plugins : brick_utilization, cluster_utilization, peer_network_throughput and volume_utilization iii. In addition, every ceph mon node will have 6 more plugins: cluster_iops, cluster_utilization, node_network_throughput, osd_utilization, pool_utilization and rbd_utilization. which makes me arrive at a maximum of i. 7 + 4 = 11 monitoring-specific jobs for a gluster peer. ii. 7 + 6 = 13 monitoring-specific jobs for a ceph mon node. iii. 7 + 1 = 8 monitoring specific jobs for a ceph osd node. Note: i. These figures are deterministic numbers are not bound to change by no. of resources(ex:bricks or volumes the node takes part in for a gluster node or osds the node contributes for a ceph node) on the node. ii. These numbers only increase with every operation to alter/override the default threshold values(currently the capability is not exposed).. iii. The current way of loading monitoring jobs if felt appropriate can be optimized to per node 1(for all resources) or 2(1 for all physical resources + 1 for all logical resources) jobs... But somehow, this idea fails to convince me. And I am in favour of the approach above in Point 1 Now regarding CephClusterCreate job in particular I am probably not the correct person to comment here @shubhendu can comment/detail out better The ceph installation + cluster creation is through ceph-installer and as per my observation, from the point the job is in ceph-installer until the ceph bits are installed and actual cluster is created, the job is probably serial and not parallel(and this is probably not in tendrl's control). This I feel is because of my observation of task detail page of ceph cluster create task as it progresses.. Note: My comments about CephClusterCreate are just out of my observations and are prone to be incorrect as I have no concrete experience in that area... @shubhendu @nishanth @rohan would probably be better to comment more on this... Anmol Babu Software Engineer Red Hat India Pvt Ltd M: 8884245644 ----- Original Message ----- From: "Filip Balak" To: "Anmol Babu" Cc: "Mailing list for the contributors to the Tendrl project" Sent: Monday, June 5, 2017 8:13:01 PM Subject: Parallel processing of tasks and events Hi Anmol, does Tendrl support parallel processing of tasks and events? For example: are job events that install ceph on nodes during CephClusterCreate job installed paralelly? Is importing of two clusters running simultinously or are they waiting on each other? Best Regards, Filip Balak From anbabu at redhat.com Mon Jun 5 17:12:56 2017 From: anbabu at redhat.com (Anmol Babu) Date: Mon, 5 Jun 2017 13:12:56 -0400 (EDT) Subject: [Tendrl-devel] Parallel processing of tasks and events In-Reply-To: References: <67556345.15906801.1496672937441.JavaMail.zimbra@redhat.com> <337321263.15911797.1496673781864.JavaMail.zimbra@redhat.com> Message-ID: <989424418.15714614.1496682776138.JavaMail.zimbra@redhat.com> Ok I see Rohan has already addressed your question.. Please prioritize his answers as final over mine(as I have not much experience in this area) wherever conflicting... Anmol Babu Software Engineer Red Hat India Pvt Ltd M: 8884245644 ----- Original Message ----- From: "Rohan Kanade" To: "Mailing list for the contributors to the Tendrl project" Cc: "Anmol Babu" Sent: Monday, June 5, 2017 9:43:33 PM Subject: Re: [Tendrl-devel] Parallel processing of tasks and events Ill try to explain this one, As we all know, Tendrl is a collection concrete namespaces of flows/objects/atoms [0] Each flow in above namespaces can be invoked (via the tendrl-api using http or curl or Tendrl-dashboard) and pushed to Tendrl central store Each flow in these namespaces can also be invoked directly by pushing a Tendrl job to Tendrl central store location "/queue/:job_id/", Sample jobs [1] can be found in "etc" dir of any Tendrl repo (Tendrl/node-agent, ceph-integration This is when Tendrl Jobs are picked up in Parallel: - Each Tendrl Job has a "type" ["node", "monitoring", "sds"] which are processed by these processes respectively: tendrl-node-agent, tendrl-node-monitoring and tendrl-{ceph, gluster}-integrations - Total parallel jobs for a 10 node tendrl managed cluster with all 3 services installed (tendrl-node-agent, tendrl-node-monitoring, tendrl-ceph or gluster-integration) = 30 Moving beyond above basics, every Tendrl Job runs a Tendrl Flow [2] which executes pre run validations, executes the atoms/actions required to complete the flow, post run validations , all of this happens serially for now. But we should Identify steps for each tendrl flow which can be run in parallel without requiring inputs from the previous actions in the flow. Now moving on specific examples, Tendrl CreateCluster job for ceph is executes a Flow which calls the Tendrl provisioning wrapper for ceph-installer. This wrapper exploits all parallel exec capabilities of ceph-installer [3], more inputs welcome. Similar to that we use a wrapper python-gdeploy which consumes gdeploy features and helps Tendrl deal with gluster. In the coming week or two, the dev team has included an item in the performance-monitoring hackathon which deals with creating topic queues (like in rabbitmq) in etcd for Tendrl central store, which can be used to distribute tendrl jobs more efficiently, will share more details of the performance hackathon soon. [0]: https://github.com/Tendrl/commons/pull/285#issuecomment-288370228 [1]: https://github.com/Tendrl/node-agent/blob/develop/etc/create_ceph_cluster_sample_job.py [2] : https://github.com/Tendrl/commons/blob/develop/tendrl/commons/objects/definition/master.yaml#L24 [3] : http://docs.ceph.com/ceph-installer/docs/#install-operations On Mon, Jun 5, 2017 at 8:13 PM, Filip Balak wrote: > Hi Anmol, > > does Tendrl support parallel processing of tasks and events? For example: > are job events that install ceph on nodes during CephClusterCreate job > installed paralelly? Is importing of two clusters running simultinously or > are they waiting on each other? > > Best Regards, > > Filip Balak > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > From shtripat at redhat.com Tue Jun 6 04:17:15 2017 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Tue, 6 Jun 2017 09:47:15 +0530 Subject: [Tendrl-devel] Parallel processing of tasks and events In-Reply-To: <1285167179.15713638.1496682493469.JavaMail.zimbra@redhat.com> References: <337321263.15911797.1496673781864.JavaMail.zimbra@redhat.com> <1285167179.15713638.1496682493469.JavaMail.zimbra@redhat.com> Message-ID: <10b8f33b-4044-d0be-a53e-6582b2fbe026@redhat.com> Thanks Anmol for such a nice summary. My comments in-line regarding CephClusterCreate flow. Regards, Shubhendu On 06/05/2017 10:38 PM, Anmol Babu wrote: > Hi Filip, > > The way the tasks processing works is as follows: > > Summary: > 1. Every task(for which I am somehow accustomed to use the term "job" :) ) in tendrl starts with an entry in /queue in etcd. > Note: > a. Currently, this queue is one single/global queue across all integrations of tendrl. > b. Entries in /queue corresponding to each job(failed, successfully executed or new(not-yet picked)) exist for a definitive interval of time after which they get erased automatically in etcd > This makes use of ttl feature provided by etcd... > Note: > @rohan will be better able to add more details and/or correct me if I am wrong.. > Personally I feel from the perspective of performance, > i. It might be better to have per-component/integration specific queue with ttl > ii. Move the completed and/or failed jobs to some other global queue. > A combination or at-least one or both of these can prove to be really very useful for bigger deployments... > 2. Now execution of any and every job is essentially an execution of a set of atomic operations(atoms in tendrl terminology) preceded(pre) and followed(post) by atoms that > validate the applicability/suitability/validity as applicable of the job on the tendrl managed resource and validation of success or failure of job execution accordingly.. > 3. Any job in tendrl is meant to be executed by a specific tendrl-module and can be even targeted to a specific node or even a collection of nodes depending on > i. Type of job > ii. Purpose of job > iii. User input/choice > as applicable and with suitable validations and best/recommended perspectives in view. > 4. So, given 1,2 and 3 above, tendrl-integrations scan through every entry in /queue of etcd and pick the jobs that are > 1. marked status new(not finished which indicates the job is already processed and executed or failed which indicates that the job execution failed) > 2. relevant/targeted to them > and then they validate(pre and post atoms) and execute them..(This is the reason for my thoughts in point 1 above) > This is in accordance with a match between > i. Tags tagged to the integration module(some via entries in the integration's conf file and some based on what the integration module is meant for) and > ii. Tags contained in job specific details in /queue in etcd... > This > Note: > a. The job to constituent validation + execution atoms mapping is maintained as part of integration module specific definitions(which is also pushed to etcd in '_NS//definitions' in etcd > b. The tendrl object definitions are also maintained in above mentioned location as part of integration-specific definitions > So given 1, 2, 3 and 4, job execution runs parallely between the integration modules unless serialized explicitly by the job only if required/applicable(as per implementation of job)... > But the scan of /queue in etcd essentially is through a possibly huge list... > Atleast from the perspective of monitoring, currently what happens is per node, per collectd plugin jobs are loaded to /queue to generate a collectd configuration file.. > To give an idea of what this means, let see an example: > > i. Per node that is not part of any cluster, we have memory, cpu, swap, mount-point, disk, dbpush(push stats to graphite), latency which means 7 jobs. > ii. In addition on every gluster node, there will be 4 more plugins : brick_utilization, cluster_utilization, peer_network_throughput and volume_utilization > iii. In addition, every ceph mon node will have 6 more plugins: cluster_iops, cluster_utilization, node_network_throughput, osd_utilization, pool_utilization and rbd_utilization. > > which makes me arrive at a maximum of > i. 7 + 4 = 11 monitoring-specific jobs for a gluster peer. > ii. 7 + 6 = 13 monitoring-specific jobs for a ceph mon node. > iii. 7 + 1 = 8 monitoring specific jobs for a ceph osd node. > > Note: > i. These figures are deterministic numbers are not bound to change by no. of resources(ex:bricks or volumes the node takes part in for a gluster node or osds the node contributes for a ceph node) on the node. > ii. These numbers only increase with every operation to alter/override the default threshold values(currently the capability is not exposed).. > iii. The current way of loading monitoring jobs if felt appropriate can be optimized to per node 1(for all resources) or 2(1 for all physical resources + 1 for all logical resources) jobs... > But somehow, this idea fails to convince me. And I am in favour of the approach above in Point 1 > > > Now regarding CephClusterCreate job in particular I am probably not the correct person to comment here @shubhendu can comment/detail out better > The ceph installation + cluster creation is through ceph-installer and as per my observation, from the point the job is in ceph-installer until the ceph bits are installed and actual cluster is created, > the job is probably serial and not parallel(and this is probably not in tendrl's control). This I feel is because of my observation of task detail page of ceph cluster create task as it progresses.. During CephClusterCreate flow, the installation of all mons and osds nodes is one call each to ceph-installer. But I have observed, ceph-installer internally does this in serial order. The way ceph-installer provisioner plugin works can be seen at [1] and [2] for more details. Yes, configuration/creation of mons and osds on the nodes is serial in nature from tendrl side itself (this is done because first monitor creation in cluster is special and then onwards all other monitors/osd creations need details of all the pre-exiting mons to be passed in request to ceph-installer) [1] https://github.com/Tendrl/node-agent/blob/develop/tendrl/node_agent/provisioner/ceph/plugins/ceph_installer.py#L28 [2] https://github.com/Tendrl/node-agent/blob/develop/tendrl/node_agent/provisioner/ceph/plugins/ceph_installer.py#L69 > Note: > My comments about CephClusterCreate are just out of my observations and are prone to be incorrect as I have no concrete experience in that area... > @shubhendu @nishanth @rohan would probably be better to comment more on this... > > Anmol Babu > Software Engineer > Red Hat India Pvt Ltd > M: 8884245644 > > ----- Original Message ----- > From: "Filip Balak" > To: "Anmol Babu" > Cc: "Mailing list for the contributors to the Tendrl project" > Sent: Monday, June 5, 2017 8:13:01 PM > Subject: Parallel processing of tasks and events > > Hi Anmol, > > does Tendrl support parallel processing of tasks and events? For example: are job events that install ceph on nodes during CephClusterCreate job installed paralelly? Is importing of two clusters running simultinously or are they waiting on each other? > > Best Regards, > > Filip Balak From mbukatov at redhat.com Tue Jun 6 06:30:06 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Tue, 6 Jun 2017 08:30:06 +0200 Subject: [Tendrl-devel] repository for ceph-installer In-Reply-To: References: Message-ID: <7e4dadda-6a73-db96-9bf8-a02c05c97f78@redhat.com> ping On 06/02/2017 04:57 PM, Martin Bukatovic wrote: > Dear all, > > the installation reference states: > >> configure the ceph-installer repo (as made available by the project) > > Could we be more precise and add a link to ceph-installer repositories > we expect people to use? > > In usmqe-setup, we were using the following repositories for downstream > testing right now: > > * > https://shaman.ceph.com/api/repos/ceph-installer/master/latest/centos/7/noarch/noarch > * > https://shaman.ceph.com/api/repos/ceph-ansible/master/latest/centos/7/noarch/noarch > * > http://copr-be.cloud.fedoraproject.org/results/ktdreyer/ceph-installer/epel-7-x86_64/ > > as you can see there: > > https://github.com/Tendrl/usmqe-setup/blob/master/roles/ceph-installer-repo/tasks/main.yml > > Would that be fine for official tendrl ansible? > -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Tue Jun 6 06:30:46 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Tue, 6 Jun 2017 08:30:46 +0200 Subject: [Tendrl-devel] incomplete description of tendrl-api installation In-Reply-To: <428da7b4-a515-64d0-d00d-3bb35dffdb71@redhat.com> References: <428da7b4-a515-64d0-d00d-3bb35dffdb71@redhat.com> Message-ID: <251b61dd-038e-36c4-31e3-86bb040e6b55@redhat.com> ping On 06/01/2017 05:36 PM, Martin Bukatovic wrote: > Dear all, > > I noticed that the Tendrl Package Installation Reference[1] > doesn't list all steps needed to install tendrl-api on Tendrl > Server machine. > > It states how to install and configure tendrl-api package, > but I'm missing there: > > * installation of tendrl-api-httpd package > * creating admin user (as documented in [2]) > > Could you review this and update the docs if you agree > that the mentioned steps are missing? > > Thank you. > > [1] > https://github.com/Tendrl/documentation/wiki/Tendrl-Package-Installation-Reference > [2] > https://github.com/Tendrl/api/blob/master/docs/users.adoc#create-admin-user > -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Tue Jun 6 06:31:32 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Tue, 6 Jun 2017 08:31:32 +0200 Subject: [Tendrl-devel] tendrl-api configuration In-Reply-To: <4257b900-3fed-6f4c-44ab-5307538fe500@redhat.com> References: <4257b900-3fed-6f4c-44ab-5307538fe500@redhat.com> Message-ID: ping On 06/01/2017 04:15 PM, Martin Bukatovic wrote: > Dear all, > > In *Tendrl Package Installation Reference* document, I see that during > configuration of tendrl-api, both password and username values are > changed to `''` (empty string), while there are some default config > values shipped in /etc/tendr/etcd.yml. > > I have 2 questions: is this username/password pair used to connect > to etcd (in other words, is it an etcd user)? And if so, how come that > it works when empty string values are specified? > > I'm asking because I was thinking about changing the defaults > shipped in tendrl-api rpm package to empty strings as well, but > I would like to understand the meaning of the options better first. > > Thank you for help. > -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Tue Jun 6 06:33:25 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Tue, 6 Jun 2017 08:33:25 +0200 Subject: [Tendrl-devel] extraneous packages in tendrl dependencies repository In-Reply-To: References: <6c43e4c6-6ee9-ee78-9812-c3d629ec69cb@redhat.com> Message-ID: ping On 05/30/2017 04:18 PM, Martin Bukatovic wrote: > On 05/22/2017 02:37 PM, Nishanth Thomas wrote: >> Thanks for pointing this out >> Earlier these packages were not available in epel - this got added >> recently. There is specifically no reason to pin down to that old version >> and we are making the changes to fix it. > > That's good to hear! This means that we can drop the packages from the > repository ... so could we do that? I still see them there, which > makes rmdeplint tests fail: > > https://ci.centos.org/view/Tendrl/job/tendrl-0-2-package-validation-rpmdeplint/347/testReport/ > > Thank you. > -- Martin Bukatovic USM QE team Red Hat From sankarshan at redhat.com Tue Jun 6 06:32:45 2017 From: sankarshan at redhat.com (sankarshan) Date: Tue, 6 Jun 2017 12:02:45 +0530 Subject: [Tendrl-devel] repository for ceph-installer In-Reply-To: References: Message-ID: On 2 June 2017 at 20:27, Martin Bukatovic wrote: > Dear all, > > the installation reference states: > >> configure the ceph-installer repo (as made available by the project) > > Could we be more precise and add a link to ceph-installer repositories > we expect people to use? > The original rationale was that Tendrl project would expect the admin-user persona to be aware of the repository to add. Upon further thought on your email, I see the valid point you raise. > In usmqe-setup, we were using the following repositories for downstream > testing right now: > > * > https://shaman.ceph.com/api/repos/ceph-installer/master/latest/centos/7/noarch/noarch > * > https://shaman.ceph.com/api/repos/ceph-ansible/master/latest/centos/7/noarch/noarch > * > http://copr-be.cloud.fedoraproject.org/results/ktdreyer/ceph-installer/epel-7-x86_64/ > These look good. Can we confirm with Ken that these are good to go? > as you can see there: > > https://github.com/Tendrl/usmqe-setup/blob/master/roles/ceph-installer-repo/tasks/main.yml > > Would that be fine for official tendrl ansible? > > -- > 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 Tue Jun 6 07:58:19 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Tue, 6 Jun 2017 09:58:19 +0200 Subject: [Tendrl-devel] workaround for https://github.com/Tendrl/performance-monitoring/issues/9 Message-ID: <221dd247-56be-e6a3-23de-ba1a05dfcd8b@redhat.com> Hi there, as a workaround for https://github.com/Tendrl/performance-monitoring/issues/9, current installation documentation suggests to: > Note: > > All nodes need to have tendrl-user added to tendrl group created by > node-agent > > useradd tendrl-user -g tendrl Does this apply for all machines, including Tendrl Server and/or Tendrl Performance Monitoring, or does it apply to just Storage Nodes? -- Martin Bukatovic USM QE team Red Hat From anbabu at redhat.com Wed Jun 7 04:22:08 2017 From: anbabu at redhat.com (Anmol Babu) Date: Wed, 7 Jun 2017 00:22:08 -0400 (EDT) Subject: [Tendrl-devel] workaround for https://github.com/Tendrl/performance-monitoring/issues/9 In-Reply-To: <221dd247-56be-e6a3-23de-ba1a05dfcd8b@redhat.com> References: <221dd247-56be-e6a3-23de-ba1a05dfcd8b@redhat.com> Message-ID: <1522738554.16233839.1496809328716.JavaMail.zimbra@redhat.com> Hi Martin, The user addition needs to be done on all those nodes that are monitored(node-monitoring and hence collectd installed)... Basically, we have a collectd plugin that on threshold breach of any resource's utilization, sends out a notification to tendrl about the threshold breach. The limitation on collectd to run plugin as a script to be executed on a threshold breach detected, is that it can't be run as root and it(collectd threshold handling script) has to run only as a non-root user So, if you want the server node also to be monitored and alerted on utilization breaches, then user needs to be added on that machine as well. The plugin is as in: https://github.com/Tendrl/node-monitoring/blob/develop/tendrl/node_monitoring/plugins/handle_collectd_notification.py The plugin is loaded as: https://github.com/Tendrl/node-monitoring/blob/develop/tendrl/node_monitoring/templates/collectd.jinja#L28 Anmol Babu Software Engineer Red Hat India Pvt Ltd M: 8884245644 ----- Original Message ----- From: "Martin Bukatovic" To: tendrl-devel at redhat.com Sent: Tuesday, June 6, 2017 1:28:19 PM Subject: [Tendrl-devel] workaround for https://github.com/Tendrl/performance-monitoring/issues/9 Hi there, as a workaround for https://github.com/Tendrl/performance-monitoring/issues/9, current installation documentation suggests to: > Note: > > All nodes need to have tendrl-user added to tendrl group created by > node-agent > > useradd tendrl-user -g tendrl Does this apply for all machines, including Tendrl Server and/or Tendrl Performance Monitoring, or does it apply to just Storage Nodes? -- 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 ltrilety at redhat.com Wed Jun 7 11:34:37 2017 From: ltrilety at redhat.com (Lubos Trilety) Date: Wed, 7 Jun 2017 13:34:37 +0200 Subject: [Tendrl-devel] CreateBrick task/job Message-ID: Hi all, it really surprised me how long it will take to create bricks. In my case I have 40 bricks, 10 bricks on 4 machines, and the creation takes almost an hour till it ends. I am faintly remembering it was a quick thing on RHGSC using an 'unsupported? script which checks all disks and creates a brick for those which are not used. So when it takes so long on our tendrl architecture it really surprised me. Anyway whats behind 'creating bricks? job? I thought it just mounts the disks (setup lvm, mkfs.xfs and mkdir) on machines as the brick is not actually used till the file share is not created. Job messages doesn?t help as they just said: info Creating the gluster bricks 06 Jun 2017 04:23:49 and next message is: info Created the gluster bricks successfully 06 Jun 2017 05:12:38 Lubos From japplewh at redhat.com Wed Jun 7 14:35:06 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Wed, 7 Jun 2017 10:35:06 -0400 Subject: [Tendrl-devel] CreateBrick task/job In-Reply-To: References: Message-ID: If this is Ansible driven perhaps parallel execution would help: http://docs.ansible.com/ansible/playbooks_async.html On Wed, Jun 7, 2017 at 7:34 AM, Lubos Trilety wrote: > Hi all, > > it really surprised me how long it will take to create bricks. In my case > I have 40 bricks, 10 bricks on 4 machines, and the creation takes almost an > hour till it ends. I am faintly remembering it was a quick thing on RHGSC > using an 'unsupported? script which checks all disks and creates a brick > for those which are not used. So when it takes so long on our tendrl > architecture it really surprised me. > > Anyway whats behind 'creating bricks? job? I thought it just mounts the > disks (setup lvm, mkfs.xfs and mkdir) on machines as the brick is not > actually used till the file share is not created. Job messages doesn?t help > as they just said: > info Creating the gluster bricks > 06 Jun 2017 04:23:49 > and next message is: > info Created the gluster bricks successfully 06 > Jun 2017 05:12:38 > > Lubos > > > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > -- Jeff Applewhite Principal Product Manager From dnarayan at redhat.com Wed Jun 7 15:18:20 2017 From: dnarayan at redhat.com (Darshan Narayana Murthy) Date: Wed, 7 Jun 2017 11:18:20 -0400 (EDT) Subject: [Tendrl-devel] CreateBrick task/job In-Reply-To: References: Message-ID: <1540306176.20040354.1496848700590.JavaMail.zimbra@redhat.com> We are using gdeploy's backend-setup [1] feature to provision gluster-bricks out of free disks. My understanding was gdeploy would provision bricks on different nodes in parallel as it uses ansible internally. But the time mentioned below seems too much for parallel execution. Adding Sac from gdeploy team to provide more inputs on this. [1] http://gdeploy.readthedocs.io/en/latest/features/lvm.html#backend-setup -Darshan ----- Original Message ----- > From: "Jeff Applewhite" > To: "Mailing list for the contributors to the Tendrl project" > Sent: Wednesday, June 7, 2017 8:05:06 PM > Subject: Re: [Tendrl-devel] CreateBrick task/job > > If this is Ansible driven perhaps parallel execution would help: > > http://docs.ansible.com/ansible/playbooks_async.html > > On Wed, Jun 7, 2017 at 7:34 AM, Lubos Trilety wrote: > > > Hi all, > > > > it really surprised me how long it will take to create bricks. In my case > > I have 40 bricks, 10 bricks on 4 machines, and the creation takes almost an > > hour till it ends. I am faintly remembering it was a quick thing on RHGSC > > using an 'unsupported? script which checks all disks and creates a brick > > for those which are not used. So when it takes so long on our tendrl > > architecture it really surprised me. > > > > Anyway whats behind 'creating bricks? job? I thought it just mounts the > > disks (setup lvm, mkfs.xfs and mkdir) on machines as the brick is not > > actually used till the file share is not created. Job messages doesn?t help > > as they just said: > > info Creating the gluster bricks > > 06 Jun 2017 04:23:49 > > and next message is: > > info Created the gluster bricks successfully 06 > > Jun 2017 05:12:38 > > > > Lubos > > > > > > > > _______________________________________________ > > Tendrl-devel mailing list > > Tendrl-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/tendrl-devel > > > > > > -- > Jeff Applewhite > Principal Product Manager > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > From rkanade at redhat.com Wed Jun 7 23:21:36 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Thu, 8 Jun 2017 04:51:36 +0530 Subject: [Tendrl-devel] tendrl-release v1.4.1 (alpha2) is available Message-ID: Hello, The Tendrl team is happy to present tendrl-release v1.4.0 (alpha1) Summary: https://github.com/Tendrl/documentation/wiki/Tendrl-release-v1.4.1-(summary) Install docs: https://github.com/Tendrl/documentation/wiki/Tendrl-release-v1.4.1-(install-doc) Cheers! From ltrilety at redhat.com Thu Jun 8 09:18:00 2017 From: ltrilety at redhat.com (Lubos Trilety) Date: Thu, 8 Jun 2017 05:18:00 -0400 (EDT) Subject: [Tendrl-devel] File Share (aka Gluster Volume) creation wizard In-Reply-To: References: Message-ID: <558089243.31630979.1496913480871.JavaMail.zimbra@redhat.com> Hi all Thanks Ju for your update. Any knowledge where this update will be incorporated to the Tendrl? Should we create some BZ for that? Regards, Lubos ----- Original Message ----- From: "Ju Lim" To: "Daniel Hor?k" Cc: "Mailing list for the contributors to the Tendrl project" Sent: Friday, June 2, 2017 10:20:59 PM Subject: Re: [Tendrl-devel] File Share (aka Gluster Volume) creation wizard Daniel et al: Just a heads-up that we've updated the Create File Share workflow -- see Create File Share design -- to clarify the questions you raised. Regards, Ju On Wed, May 31, 2017 at 4:03 PM, Ju Lim wrote: > Hi Daniel: > > Thanks for starting this thread as there appears to be a difference > between our design vs. implementation. > > Some assumptions before I go into answering your questions: > > For Tendrl, we will initially support 2 types of volumes: > > - 3-way distributed replicated > - Erasure Coded (4+2 with min 6 bricks, 8+3 with min 11 bricks, 8+4 > with min 12 bricks) > > Note: 2-way distributed replicated is left off as we will plan arbiter > volumes to cover that scenario in the future. > > For the 3-way distributed replicated, per the official documentation > > : > > The number of bricks must be a multiple of the replica count for a > distributed replicated volume. Also, the order in which bricks are > specified has a great effect on data protection. > > Each replica_count consecutive bricks in the list you give will form a > replica set, with all replica sets combined into a distribute set. To > ensure that replica-set members are not placed on the same node, list the > first brick on every server, then the second brick on every server in the > same order, and so on. > > So, in other words, if we had a 3-way dist-rep, that means it?s 3 > consecutive bricks to form a replica set. So, if you?re using 6 nodes > (with 1 brick each), that would mean 2 replica sets. > > Ideally, user should not have to input Bricks per Replica set, and System > should be able to compute this, i.e. > > # bricks per replica set == replica_count > > # replica sets == # of bricks / replica_count > > Thus, we should remove the ?Bricks per Replica Set? from the design. > > > For EC (distributed dispersed) volumes, the 2 parameters needed are > typically: > > - disperse-data_count == k or the number of bricks that is part of the > dispersed volume, excluding the count of the redundant bricks > > > - redundancy_count (optional parameter) == m or # of bricks that can > fail without losing data, i.e. m > > > To answer your questions for the Create File Share (aka create gluster > volume): > > > What exactly means the "Bricks per Replica Set" value on Create File Share > - Layout[1] page? > > - This was intended to help with the visualization of the layout but I > don?t think it?s needed and probably should be removed. (It was a bit of > heritage from the old console.) > > > - Is it related to replication or distribution? It isn?t. > > > Some observations from the current implemented Create File Share workflow: > > - The combined Type (Distributed Replicated) + Replica Count {2 or 3} > == 2-way or 3-way distributed replicated. This is not to design as we > collapsed this to 3-way distributed replicated for the Type in our design > to simplify the user experience. > - The Distribution Count is not in our design and it?s not even > specified in the Gluster CLI for in the related Tendrl specs that I could > find, so I?m not sure what this is for. I thought perhaps it was for > something EC-related, but there?s currently no way to specify EC in the UI > for creating the volume. Per https://github.com/Tendrl/ > specifications/blob/33eabe3123b290bd030a94b30fdde7 > 09253539f8/specs/segragate_object_specific_flows.adoc > , > the volume inputs expected are volume.volname, volume.bricks and optionally: > > - Volume.stripe_count > - Volume.replica_count > - Volume.arbiter_count > - Volume.disperse_count > - Volume.disperse_data_count > - Volume.redundancy_count > - Volume.transport > - Volume.force > > > Related References: > > - Create File Share workflow: https://redhat.invisionapp. > com/share/Q78YMAVDJ#/screens/217726640 > > - Gaps of design vs. implementation: https://bugzilla.redhat.com/ > show_bug.cgi?id=1456418#c3 > - Spec for Create Volume: ? Distribution Count was> > - Tendrl-gdeploy wrapper spec: https://github.com/Tendrl/ > specifications/blob/8c19e6af7a459bf6a6070fca2bbe3e > f710aff819/specs/tendrl_gdeploy_wrapper.adoc > > - Segregate object specific flows: https://github.com/Tendrl/ > specifications/blob/33eabe3123b290bd030a94b30fdde7 > 09253539f8/specs/segragate_object_specific_flows.adoc > > - UI code references for distribution count: https://github.com/Tendrl/ > dashboard/search?utf8=%E2%9C%93&q=distribution+count&type= > > > > As a last note, we will update the Create File Share design to remove the > 2-way distributed-replicated and the Bricks per Replica Set field, and > update the sample workflow. > > > I hope this clarifies any confusion. If needed and it makes sense, please > feel free to schedule a meeting to discuss this to get everyone on the same > page. > > > Thank you, > Ju > > On Wed, May 31, 2017 at 4:14 AM, Daniel Hor?k wrote: > >> Hi Ju, >> >> I have few questions related to File Share (aka Gluster Volume) creation >> wizard. >> >> What exactly means the "Bricks per Replica Set" value on Create File >> Share - Layout[1] page? >> Is it related to replication or distribution? I think it should be >> related to "distribution" (because Replication might be set only to 2 or >> 3), but I'm not sure how exactly. >> >> And also there seems to be some misunderstanding between the design and >> real implementation[2]. >> >> [1] https://redhat.invisionapp.com/share/Q78YMAVDJ#/screens/228991297 >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1456418#c3 >> >> Thanks, >> Daniel >> > > > > -- 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 Jun 8 09:26:23 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Thu, 8 Jun 2017 14:56:23 +0530 Subject: [Tendrl-devel] Tendrl performance hackathon June 2017 - Inputs welcome Message-ID: The Tendrl team has assessed the current tendrl-release 1.4.1 and come up with a rough agenda which will help improve the performance of Tendrl and it's components. Link: https://github.com/Tendrl/documentation/wiki/Performance-Hackathon,-June-2017 The Tendrl community would love to hear about your performance pain points, expected performance and any other detail which will lead to better performance in Tendrl. Please reply to this thread with your inputs or directly file issues at http://github.com/Tendrl/$component The performance hackathon is planned around June 2017. Cheers! From sankarshan.mukhopadhyay at gmail.com Thu Jun 8 10:03:52 2017 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Thu, 8 Jun 2017 15:33:52 +0530 Subject: [Tendrl-devel] File Share (aka Gluster Volume) creation wizard In-Reply-To: <558089243.31630979.1496913480871.JavaMail.zimbra@redhat.com> References: <558089243.31630979.1496913480871.JavaMail.zimbra@redhat.com> Message-ID: On Thu, Jun 8, 2017 at 2:48 PM, Lubos Trilety wrote: > Hi all > > Thanks Ju for your update. > > Any knowledge where this update will be incorporated to the Tendrl? Should we create some BZ for that? > I understand that Mrugesh, Nishanth, Neha (among others) were in a discussion on this topic this afternoon. I'll leave it to Nishanth/Neha to provide estimates on making this capability available in an upcoming build. -- sankarshan mukhopadhyay From mbukatov at redhat.com Thu Jun 8 17:48:40 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 8 Jun 2017 19:48:40 +0200 Subject: [Tendrl-devel] minimal hw requirements Message-ID: Dear all, could we clarify minimal hw requirements we need to check before installing Tendrl? I'm asking because I wanted to automate this kind of check based on Jeff's requirements in: https://tendrl.atlassian.net/browse/TEN-257 And I have few few questions: * Do we have this specified globally? I see that there are memory and cpu requirements for Tendrl Server in release install docs[1], but do we have more details somewhere else? * The requirements for Tendrl Server (based on [1]) are: 12 GB of memory and 4 cpus. Does that apply for small POC clusters on virtual machines (non production demonstration) as well? Thanks for clarification. [1] https://github.com/Tendrl/documentation/wiki/Tendrl-release-v1.4.1-(install-doc) -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Thu Jun 8 17:51:37 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 8 Jun 2017 19:51:37 +0200 Subject: [Tendrl-devel] workaround for https://github.com/Tendrl/performance-monitoring/issues/9 In-Reply-To: <1522738554.16233839.1496809328716.JavaMail.zimbra@redhat.com> References: <221dd247-56be-e6a3-23de-ba1a05dfcd8b@redhat.com> <1522738554.16233839.1496809328716.JavaMail.zimbra@redhat.com> Message-ID: On 06/07/2017 06:22 AM, Anmol Babu wrote: > The user addition needs to be done on all those nodes that are monitored(node-monitoring and hence collectd installed)... > Basically, we have a collectd plugin that on threshold breach of any resource's utilization, sends out a notification to tendrl about the threshold breach. > The limitation on collectd to run plugin as a script to be executed on a threshold breach detected, is that it can't be run as root and it(collectd threshold handling script) has to run only as a non-root user > So, if you want the server node also to be monitored and alerted on utilization breaches, then user needs to be added on that machine as well. > > The plugin is as in: > https://github.com/Tendrl/node-monitoring/blob/develop/tendrl/node_monitoring/plugins/handle_collectd_notification.py > > The plugin is loaded as: > https://github.com/Tendrl/node-monitoring/blob/develop/tendrl/node_monitoring/templates/collectd.jinja#L28 Thanks a lot for the explanation. I have additional question: do I understand this right that tendrl-user is created in node-agent package because it's better wrt to maintenance, but the actual component which requires it is just monitoring at this point? -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Thu Jun 8 17:52:09 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 8 Jun 2017 19:52:09 +0200 Subject: [Tendrl-devel] extraneous packages in tendrl dependencies repository In-Reply-To: References: <6c43e4c6-6ee9-ee78-9812-c3d629ec69cb@redhat.com> Message-ID: ping On 06/06/2017 08:33 AM, Martin Bukatovic wrote: > ping > > On 05/30/2017 04:18 PM, Martin Bukatovic wrote: >> On 05/22/2017 02:37 PM, Nishanth Thomas wrote: >>> Thanks for pointing this out >>> Earlier these packages were not available in epel - this got added >>> recently. There is specifically no reason to pin down to that old version >>> and we are making the changes to fix it. >> >> That's good to hear! This means that we can drop the packages from the >> repository ... so could we do that? I still see them there, which >> makes rmdeplint tests fail: >> >> https://ci.centos.org/view/Tendrl/job/tendrl-0-2-package-validation-rpmdeplint/347/testReport/ >> >> Thank you. >> > > -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Thu Jun 8 17:53:24 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 8 Jun 2017 19:53:24 +0200 Subject: [Tendrl-devel] tendrl-api configuration In-Reply-To: References: <4257b900-3fed-6f4c-44ab-5307538fe500@redhat.com> Message-ID: ping On 06/06/2017 08:31 AM, Martin Bukatovic wrote: > ping > > On 06/01/2017 04:15 PM, Martin Bukatovic wrote: >> Dear all, >> >> In *Tendrl Package Installation Reference* document, I see that during >> configuration of tendrl-api, both password and username values are >> changed to `''` (empty string), while there are some default config >> values shipped in /etc/tendr/etcd.yml. >> >> I have 2 questions: is this username/password pair used to connect >> to etcd (in other words, is it an etcd user)? And if so, how come that >> it works when empty string values are specified? >> >> I'm asking because I was thinking about changing the defaults >> shipped in tendrl-api rpm package to empty strings as well, but >> I would like to understand the meaning of the options better first. >> >> Thank you for help. >> > > -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Thu Jun 8 17:54:09 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 8 Jun 2017 19:54:09 +0200 Subject: [Tendrl-devel] incomplete description of tendrl-api installation In-Reply-To: <251b61dd-038e-36c4-31e3-86bb040e6b55@redhat.com> References: <428da7b4-a515-64d0-d00d-3bb35dffdb71@redhat.com> <251b61dd-038e-36c4-31e3-86bb040e6b55@redhat.com> Message-ID: <258a18bd-4327-7347-6dc2-0c0d5f76582b@redhat.com> ping On 06/06/2017 08:30 AM, Martin Bukatovic wrote: > ping > > On 06/01/2017 05:36 PM, Martin Bukatovic wrote: >> Dear all, >> >> I noticed that the Tendrl Package Installation Reference[1] >> doesn't list all steps needed to install tendrl-api on Tendrl >> Server machine. >> >> It states how to install and configure tendrl-api package, >> but I'm missing there: >> >> * installation of tendrl-api-httpd package >> * creating admin user (as documented in [2]) >> >> Could you review this and update the docs if you agree >> that the mentioned steps are missing? >> >> Thank you. >> >> [1] >> https://github.com/Tendrl/documentation/wiki/Tendrl-Package-Installation-Reference >> [2] >> https://github.com/Tendrl/api/blob/master/docs/users.adoc#create-admin-user >> > > -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Thu Jun 8 17:56:36 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 8 Jun 2017 19:56:36 +0200 Subject: [Tendrl-devel] Create cluster documentation In-Reply-To: <1748967170.14967977.1496325871068.JavaMail.zimbra@redhat.com> References: <1748967170.14967977.1496325871068.JavaMail.zimbra@redhat.com> Message-ID: <2e7fec9f-8e67-cf95-b85f-9010879deb36@redhat.com> ping On 06/01/2017 04:04 PM, Filip Balak wrote: > Hi Anup, > > could you please help me to better understand how to correctly set parameters for CreateCluster API call? From documentation[1] it isn't clear to me what is correct value for some parameters. > > Especialy parameters `provisioning_ip` and `node_identifier`. What could be correct values of those parameters? > > I have created issue[2] about clarity of documentation for this API call. > > Best Regards > > Filip Balak > > [1] https://github.com/Tendrl/api/blob/master/docs/clusters.adoc#create-cluster > [2] https://github.com/Tendrl/api/issues/197 > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > -- Martin Bukatovic USM QE team Red Hat From anbabu at redhat.com Fri Jun 9 06:09:53 2017 From: anbabu at redhat.com (Anmol Babu) Date: Fri, 9 Jun 2017 02:09:53 -0400 (EDT) Subject: [Tendrl-devel] workaround for https://github.com/Tendrl/performance-monitoring/issues/9 In-Reply-To: References: <221dd247-56be-e6a3-23de-ba1a05dfcd8b@redhat.com> <1522738554.16233839.1496809328716.JavaMail.zimbra@redhat.com> Message-ID: <2064873507.16943681.1496988593222.JavaMail.zimbra@redhat.com> Hi Martin, >I have additional question: do I understand this right that tendrl-user >is created in node-agent package because it's better wrt to maintenance, >but the actual component which requires it is just monitoring at this >point? "at this point" This is correct ... Anmol Babu Software Engineer Red Hat India Pvt Ltd M: 8884245644 ----- Original Message ----- From: "Martin Bukatovic" To: tendrl-devel at redhat.com Sent: Thursday, June 8, 2017 11:21:37 PM Subject: Re: [Tendrl-devel] workaround for https://github.com/Tendrl/performance-monitoring/issues/9 On 06/07/2017 06:22 AM, Anmol Babu wrote: > The user addition needs to be done on all those nodes that are monitored(node-monitoring and hence collectd installed)... > Basically, we have a collectd plugin that on threshold breach of any resource's utilization, sends out a notification to tendrl about the threshold breach. > The limitation on collectd to run plugin as a script to be executed on a threshold breach detected, is that it can't be run as root and it(collectd threshold handling script) has to run only as a non-root user > So, if you want the server node also to be monitored and alerted on utilization breaches, then user needs to be added on that machine as well. > > The plugin is as in: > https://github.com/Tendrl/node-monitoring/blob/develop/tendrl/node_monitoring/plugins/handle_collectd_notification.py > > The plugin is loaded as: > https://github.com/Tendrl/node-monitoring/blob/develop/tendrl/node_monitoring/templates/collectd.jinja#L28 Thanks a lot for the explanation. I have additional question: do I understand this right that tendrl-user is created in node-agent package because it's better wrt to maintenance, but the actual component which requires it is just monitoring at this point? -- 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 nthomas at redhat.com Fri Jun 9 06:24:59 2017 From: nthomas at redhat.com (Nishanth Thomas) Date: Fri, 9 Jun 2017 11:54:59 +0530 Subject: [Tendrl-devel] incomplete description of tendrl-api installation In-Reply-To: <428da7b4-a515-64d0-d00d-3bb35dffdb71@redhat.com> References: <428da7b4-a515-64d0-d00d-3bb35dffdb71@redhat.com> Message-ID: On Thu, Jun 1, 2017 at 9:06 PM, Martin Bukatovic wrote: > Dear all, > > I noticed that the Tendrl Package Installation Reference[1] > doesn't list all steps needed to install tendrl-api on Tendrl > Server machine. > > It states how to install and configure tendrl-api package, > but I'm missing there: > > * installation of tendrl-api-httpd package > This not required to be mentioned as it is a dependency to tendrl-dashboard and pulled automatically > * creating admin user (as documented in [2]) > This step is missing and we will add them to doc soon > > Could you review this and update the docs if you agree > that the mentioned steps are missing? > > Thank you. > > [1] > https://github.com/Tendrl/documentation/wiki/Tendrl- > Package-Installation-Reference > [2] > https://github.com/Tendrl/api/blob/master/docs/users.adoc# > create-admin-user > > -- > 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 nthomas at redhat.com Fri Jun 9 06:29:52 2017 From: nthomas at redhat.com (Nishanth Thomas) Date: Fri, 9 Jun 2017 11:59:52 +0530 Subject: [Tendrl-devel] tendrl-api configuration In-Reply-To: <4257b900-3fed-6f4c-44ab-5307538fe500@redhat.com> References: <4257b900-3fed-6f4c-44ab-5307538fe500@redhat.com> Message-ID: On Thu, Jun 1, 2017 at 7:45 PM, Martin Bukatovic wrote: > Dear all, > > In *Tendrl Package Installation Reference* document, I see that during > configuration of tendrl-api, both password and username values are > changed to `''` (empty string), while there are some default config > values shipped in /etc/tendr/etcd.yml. > > I have 2 questions: is this username/password pair used to connect > to etcd (in other words, is it an etcd user)? And if so, how come that > it works when empty string values are specified? > This is an option provided in the api config if the etcd is setup with authentication. Empty string means there is no auth. > > I'm asking because I was thinking about changing the defaults > shipped in tendrl-api rpm package to empty strings as well, but > I would like to understand the meaning of the options better first. > > Thank you for help. > > -- > 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 Fri Jun 9 06:44:49 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Fri, 9 Jun 2017 12:14:49 +0530 Subject: [Tendrl-devel] minimal hw requirements In-Reply-To: References: Message-ID: Hi Martin, Storage nodes should follow hardware guidelines as given by the storage system documentation (ceph, gluster docs). As for Tendrl Server, it hosts the tendrl-api, tendrl-monitor (tendrl-node-agent which monitors all other tendrl-node-agent) and the tendrl central store (etcd) which contains master data for tendrl managed nodes, tendrl managed clusters and all the error/warning/notice (alerts) logs coming out of tendrl. Given the responsibilities of tendrl-server, it is a good practice to run it on 12 GB memory and 4VCPU, but for POC clusters, I would say you can get away with 8GB Memory and 4 VCPUs for tendrl-server The reason it is not documented globally and done per release is , we are yet to finish performance optimizations and dont really lots of precise data about how much resources Tendrl-server would require. Perhaps you can generate some numbers while testing Tendrl? On Thu, Jun 8, 2017 at 11:18 PM, Martin Bukatovic wrote: > Dear all, > > could we clarify minimal hw requirements we need to check before > installing Tendrl? I'm asking because I wanted to automate this > kind of check based on Jeff's requirements in: > > https://tendrl.atlassian.net/browse/TEN-257 > > And I have few few questions: > > * Do we have this specified globally? I see that there are memory > and cpu requirements for Tendrl Server in release install docs[1], > but do we have more details somewhere else? > > * The requirements for Tendrl Server (based on [1]) are: 12 GB of > memory and 4 cpus. Does that apply for small POC clusters on > virtual machines (non production demonstration) as well? > > Thanks for clarification. > > [1] > https://github.com/Tendrl/documentation/wiki/Tendrl- > release-v1.4.1-(install-doc) > > -- > 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 nthomas at redhat.com Fri Jun 9 06:58:49 2017 From: nthomas at redhat.com (Nishanth Thomas) Date: Fri, 9 Jun 2017 12:28:49 +0530 Subject: [Tendrl-devel] extraneous packages in tendrl dependencies repository In-Reply-To: References: <6c43e4c6-6ee9-ee78-9812-c3d629ec69cb@redhat.com> Message-ID: Tim, Can you please take care of this? Thanks, Nishanth On Tue, May 30, 2017 at 7:48 PM, Martin Bukatovic wrote: > On 05/22/2017 02:37 PM, Nishanth Thomas wrote: > > Thanks for pointing this out > > Earlier these packages were not available in epel - this got added > > recently. There is specifically no reason to pin down to that old version > > and we are making the changes to fix it. > > That's good to hear! This means that we can drop the packages from the > repository ... so could we do that? I still see them there, which > makes rmdeplint tests fail: > > https://ci.centos.org/view/Tendrl/job/tendrl-0-2-package- > validation-rpmdeplint/347/testReport/ > > Thank you. > > -- > 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 tjeyasin at redhat.com Fri Jun 9 09:31:34 2017 From: tjeyasin at redhat.com (Timothy Asir Jeyasingh) Date: Fri, 9 Jun 2017 05:31:34 -0400 (EDT) Subject: [Tendrl-devel] extraneous packages in tendrl dependencies repository In-Reply-To: References: <6c43e4c6-6ee9-ee78-9812-c3d629ec69cb@redhat.com> Message-ID: <702379060.7342259.1497000694899.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Nishanth Thomas" > To: "Mailing list for the contributors to the Tendrl project" , "Timothy Asir Jeyasingh" > > Sent: Friday, June 9, 2017 12:28:49 PM > Subject: Re: [Tendrl-devel] extraneous packages in tendrl dependencies repository > > Tim, > > Can you please take care of this? > Sure Regards, Tim > Thanks, > Nishanth > > On Tue, May 30, 2017 at 7:48 PM, Martin Bukatovic > wrote: > > > On 05/22/2017 02:37 PM, Nishanth Thomas wrote: > > > Thanks for pointing this out > > > Earlier these packages were not available in epel - this got added > > > recently. There is specifically no reason to pin down to that old version > > > and we are making the changes to fix it. > > > > That's good to hear! This means that we can drop the packages from the > > repository ... so could we do that? I still see them there, which > > makes rmdeplint tests fail: > > > > https://ci.centos.org/view/Tendrl/job/tendrl-0-2-package- > > validation-rpmdeplint/347/testReport/ > > > > Thank you. > > > > -- > > 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 sankarshan at redhat.com Fri Jun 9 10:17:57 2017 From: sankarshan at redhat.com (sankarshan) Date: Fri, 9 Jun 2017 15:47:57 +0530 Subject: [Tendrl-devel] Tendrl performance hackathon June 2017 - Inputs welcome In-Reply-To: References: Message-ID: On 8 June 2017 at 14:56, Rohan Kanade wrote: > The Tendrl team has assessed the current tendrl-release 1.4.1 and come up > with a rough agenda which will help improve the performance of Tendrl and > it's components. > > Link: > https://github.com/Tendrl/documentation/wiki/Performance-Hackathon,-June-2017 > > > The Tendrl community would love to hear about your performance pain points, > expected performance and any other detail which will lead to better > performance in Tendrl. > I haven't noticed issues or, any commentary around the topics - do you have a cut-off date for finalizing what would be the items worked on? > Please reply to this thread with your inputs or directly file issues at > http://github.com/Tendrl/$component > > > The performance hackathon is planned around June 2017. From mkudlej at redhat.com Fri Jun 9 11:48:04 2017 From: mkudlej at redhat.com (Martin Kudlej) Date: Fri, 9 Jun 2017 13:48:04 +0200 Subject: [Tendrl-devel] Tendrl performance hackathon June 2017 - Inputs welcome In-Reply-To: References: Message-ID: <19066aa9-e46d-06c9-d33e-d091dbb37950@redhat.com> Hi Rohan, thank you for starting this initiative. On 06/08/2017 11:26 AM, Rohan Kanade wrote: > The Tendrl team has assessed the current tendrl-release 1.4.1 and come up > with a rough agenda which will help improve the performance of Tendrl and > it's components. > > Link: > https://github.com/Tendrl/documentation/wiki/Performance-Hackathon,-June-2017 I have no rights to edit this wiki so I'm writing email. - I think will be great to clean up API, please see couple of emails in tendrl-devel and https://github.com/Tendrl/documentation/issues/70 - it will be great to fix memory and CPU consumption for storage integration. I think it is not acceptable that Tendrl services uses memory and CPU which should be used by Ceph or Gluster, please see https://github.com/Tendrl/ceph-integration/issues/140 and https://github.com/Tendrl/ceph-integration/issues/223 - I think that it will be great to implement idea in https://bugzilla.redhat.com/show_bug.cgi?id=1302765 because Tendrl do the same like Skyring. It is not efficient to load all info for all objects in the lists, most critical is host(and osd list if there is any) list. Imagine that there are about 200 nodes in typical installation(more than 50 nodes per cluster). - I think will be great to split job queue to monitoring/eventing queue and queue with rest of the jobs. And/or generate monitoring/eventing jobs only if there is any state change. Please look at root of this issue. Exmaple https://bugzilla.redhat.com/show_bug.cgi?id=1456563#c6 - Ceph cluster installation takes similar time than in Skyring. Tendrl has different architecture than Skyring. Is it possible to use ceph-installer API more efficient for cluster creation? For example to do some operations in parallel? -- 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 sankarshan at redhat.com Fri Jun 9 12:43:12 2017 From: sankarshan at redhat.com (sankarshan) Date: Fri, 9 Jun 2017 18:13:12 +0530 Subject: [Tendrl-devel] Tendrl performance hackathon June 2017 - Inputs welcome In-Reply-To: <19066aa9-e46d-06c9-d33e-d091dbb37950@redhat.com> References: <19066aa9-e46d-06c9-d33e-d091dbb37950@redhat.com> Message-ID: On 9 June 2017 at 17:18, Martin Kudlej wrote: > Hi Rohan, > thank you for starting this initiative. > > On 06/08/2017 11:26 AM, Rohan Kanade wrote: >> >> The Tendrl team has assessed the current tendrl-release 1.4.1 and come up >> with a rough agenda which will help improve the performance of Tendrl and >> it's components. >> >> Link: >> >> https://github.com/Tendrl/documentation/wiki/Performance-Hackathon,-June-2017 > > > I have no rights to edit this wiki so I'm writing email. > > - I think will be great to clean up API, please see couple of emails in > tendrl-devel and https://github.com/Tendrl/documentation/issues/70 > > - it will be great to fix memory and CPU consumption for storage > integration. I think it is not acceptable that Tendrl services uses memory > and CPU which should be used by Ceph or Gluster, please see > https://github.com/Tendrl/ceph-integration/issues/140 and > https://github.com/Tendrl/ceph-integration/issues/223 > One part of this is being able to narrow down towards a "recommended configuration" for set up. Running on the same node(s) as the storage systems bring up a set of costs and as we progress towards completion - being able to work on this as a constant and iterative improvement is called for. > - I think that it will be great to implement idea in > https://bugzilla.redhat.com/show_bug.cgi?id=1302765 because Tendrl do the > same like Skyring. It is not efficient to load all info for all objects in > the lists, most critical is host(and osd list if there is any) list. Imagine > that there are about 200 nodes in typical installation(more than 50 nodes > per cluster). > > > - I think will be great to split job queue to monitoring/eventing queue and > queue with rest of the jobs. And/or generate monitoring/eventing jobs only > if there is any state change. Please look at root of this issue. Exmaple > https://bugzilla.redhat.com/show_bug.cgi?id=1456563#c6 > > - Ceph cluster installation takes similar time than in Skyring. Tendrl has > different architecture than Skyring. Is it possible to use ceph-installer > API more efficient for cluster creation? For example to do some operations > in parallel? > > > -- > 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 rkanade at redhat.com Sat Jun 10 12:44:43 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Sat, 10 Jun 2017 18:14:43 +0530 Subject: [Tendrl-devel] Ruby and Python bindings for the tendrl-api Message-ID: Hi, We have started work on ruby [0] and python [1] CLI client and language bindings for the tendrl-api Goals: - provide language bindings wrapping the tendrl-api - provide CLI access to the tendrl-api eg . for python "from tendrlclient import GetNodeList node_list = GetNodeList() " eg: cmd ~ tendrl node list output Bunch of node id's [0] : https://github.com/Tendrl/ruby-tendrlclient [1] : https://github.com/Tendrl/python-tendrlclient Contributions in terms of code, feature suggestions welcome From anivargi at redhat.com Sat Jun 10 14:42:33 2017 From: anivargi at redhat.com (Anup Nivargi) Date: Sat, 10 Jun 2017 10:42:33 -0400 (EDT) Subject: [Tendrl-devel] Ruby and Python bindings for the tendrl-api In-Reply-To: References: Message-ID: <2093164270.19192044.1497105753713.JavaMail.zimbra@redhat.com> I have renamed the Tendrl ruby client to follow ruby gem naming convention to tendrl-ruby [1] https://github.com/Tendrl/tendrl-ruby -Anup NIVARGI ----- Original Message ----- From: "Rohan Kanade" To: "Mailing list for the contributors to the Tendrl project" Sent: Saturday, 10 June, 2017 6:14:43 PM Subject: [Tendrl-devel] Ruby and Python bindings for the tendrl-api Hi, We have started work on ruby [0] and python [1] CLI client and language bindings for the tendrl-api Goals: - provide language bindings wrapping the tendrl-api - provide CLI access to the tendrl-api eg . for python "from tendrlclient import GetNodeList node_list = GetNodeList() " eg: cmd ~ tendrl node list output Bunch of node id's [0] : https://github.com/Tendrl/ruby-tendrlclient [1] : https://github.com/Tendrl/python-tendrlclient Contributions in terms of code, feature suggestions welcome _______________________________________________ Tendrl-devel mailing list Tendrl-devel at redhat.com https://www.redhat.com/mailman/listinfo/tendrl-devel From sankarshan at redhat.com Mon Jun 12 02:47:30 2017 From: sankarshan at redhat.com (sankarshan) Date: Mon, 12 Jun 2017 08:17:30 +0530 Subject: [Tendrl-devel] Ruby and Python bindings for the tendrl-api In-Reply-To: References: Message-ID: On 10 June 2017 at 18:14, Rohan Kanade wrote: > Hi, > > We have started work on ruby [0] and python [1] CLI client and language > bindings for the tendrl-api > > Goals: > - provide language bindings wrapping the tendrl-api > - provide CLI access to the tendrl-api > > > > eg . for python > "from tendrlclient import GetNodeList > node_list = GetNodeList() > " > > eg: cmd > ~ tendrl node list > > output > Bunch of node id's > This is neat. Do you think we can get the first pass implementation in one language fairly quickly enough? > > > [0] : https://github.com/Tendrl/ruby-tendrlclient > [1] : https://github.com/Tendrl/python-tendrlclient > > > Contributions in terms of code, feature suggestions welcome From anivargi at redhat.com Mon Jun 12 06:58:16 2017 From: anivargi at redhat.com (Anup Nivargi) Date: Mon, 12 Jun 2017 02:58:16 -0400 (EDT) Subject: [Tendrl-devel] Ruby and Python bindings for the tendrl-api In-Reply-To: References: Message-ID: <1010457400.19305342.1497250696461.JavaMail.zimbra@redhat.com> Hi, The Ruby implementation[1] already has the following implemented: 1) Authentication 2) Node List 3) Import Cluster 4) Job List 5) Job Single 6) Job Status 7) Cluster List Note: The responses of each action are just very raw as of now, but it works. [1]https://github.com/Tendrl/tendrl-ruby -Anup Nivargi ----- Original Message ----- From: "sankarshan" To: "Mailing list for the contributors to the Tendrl project" Sent: Monday, 12 June, 2017 8:17:30 AM Subject: Re: [Tendrl-devel] Ruby and Python bindings for the tendrl-api On 10 June 2017 at 18:14, Rohan Kanade wrote: > Hi, > > We have started work on ruby [0] and python [1] CLI client and language > bindings for the tendrl-api > > Goals: > - provide language bindings wrapping the tendrl-api > - provide CLI access to the tendrl-api > > > > eg . for python > "from tendrlclient import GetNodeList > node_list = GetNodeList() > " > > eg: cmd > ~ tendrl node list > > output > Bunch of node id's > This is neat. Do you think we can get the first pass implementation in one language fairly quickly enough? > > > [0] : https://github.com/Tendrl/ruby-tendrlclient > [1] : https://github.com/Tendrl/python-tendrlclient > > > Contributions in terms of code, feature suggestions welcome _______________________________________________ Tendrl-devel mailing list Tendrl-devel at redhat.com https://www.redhat.com/mailman/listinfo/tendrl-devel From surs at redhat.com Wed Jun 14 06:35:18 2017 From: surs at redhat.com (Sachidananda URS) Date: Wed, 14 Jun 2017 12:05:18 +0530 Subject: [Tendrl-devel] CreateBrick task/job In-Reply-To: <1540306176.20040354.1496848700590.JavaMail.zimbra@redhat.com> References: <1540306176.20040354.1496848700590.JavaMail.zimbra@redhat.com> Message-ID: On Wed, Jun 7, 2017 at 8:48 PM, Darshan Narayana Murthy wrote: > We are using gdeploy's backend-setup [1] feature to provision > gluster-bricks out of free disks. > My understanding was gdeploy would provision bricks on different nodes in > parallel as it uses > ansible internally. But the time mentioned below seems too much for > parallel execution. > > Adding Sac from gdeploy team to provide more inputs on this. > Setting up disks roughly involves the below mentioned steps: 1. Creating PV, VG, Thinlvs 2. Create XFS filesystem on them. 3. Mount. Since we use Ansible, the tasks run in parallel on all the nodes. However, since you have 10 disks on each node, for those ten bricks the actions are serial. It picks each disk one by one and creates filesystem on them. As Jeff has mentioned earlier, we may have to use mechanisms to make those brick actions parallel on each node if multiple disks are present. We have to investigate more on making tasks parallel within each of the nodes. -sac From ltrilety at redhat.com Wed Jun 14 12:43:52 2017 From: ltrilety at redhat.com (Lubos Trilety) Date: Wed, 14 Jun 2017 08:43:52 -0400 (EDT) Subject: [Tendrl-devel] repetitive cluster names In-Reply-To: <485413746.34764586.1497443195083.JavaMail.zimbra@redhat.com> Message-ID: <1499051836.34800397.1497444232287.JavaMail.zimbra@redhat.com> Hi all, tendlr allows to use the same name for multiple (for now it applies only to ceph) clusters. That behavior seems correct, however it brings several problems as it's not easy to distinguish between such clusters in any list on UI. That's the cluster list itself but also hosts, pools and rbds lists. In those later ones the issue is with related cluster for displayed items. The same could be said when a user tries to create a new pool or rbd. That said tendrl should provide some means how the user could differentiate such clusters. Regards, Lubos From mkudlej at redhat.com Wed Jun 14 13:21:24 2017 From: mkudlej at redhat.com (Martin Kudlej) Date: Wed, 14 Jun 2017 15:21:24 +0200 Subject: [Tendrl-devel] repetitive cluster names In-Reply-To: <1499051836.34800397.1497444232287.JavaMail.zimbra@redhat.com> References: <1499051836.34800397.1497444232287.JavaMail.zimbra@redhat.com> Message-ID: Hi Lubos, all, On 06/14/2017 02:43 PM, Lubos Trilety wrote: > tendlr allows to use the same name for multiple (for now it applies only to ceph) clusters. That behavior seems correct, however it brings several problems as it's not easy to distinguish between such clusters in any list on UI. That's the cluster list itself but also hosts, pools and rbds lists. In those later ones the issue is with related cluster for displayed items. The same could be said when a user tries to create a new pool or rbd. That said tendrl should provide some means how the user could differentiate such clusters. I think that support for cluster names for ceph-ansible will be removed https://bugzilla.redhat.com/show_bug.cgi?id=1459861 BUT it's really user unfriendly to identify cluster by its hash. So I think that your point is valid and Tendrl should support names for clusters internally. -- 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 rkanade at redhat.com Wed Jun 14 14:03:25 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Wed, 14 Jun 2017 19:33:25 +0530 Subject: [Tendrl-devel] repetitive cluster names In-Reply-To: References: <1499051836.34800397.1497444232287.JavaMail.zimbra@redhat.com> Message-ID: Look at this from the tendrl-api consumer's (cloudforms or ospd) perspective. Being able to have a unique identifier to the cluster (i.e tendrl_context.cluster_id) and being able to have a short cluster name are both essential I think our default cluster_name should be standardised for gluster (and for ceph when they remove cluster name support) It can be a smaller version (5 chars) of the $hash +-ceph|gluster" And we should turn off support for setting cluster name for new clusters (imported clusters and have their cluster names) On 14-Jun-2017 18:51, "Martin Kudlej" wrote: > Hi Lubos, all, > > On 06/14/2017 02:43 PM, Lubos Trilety wrote: > >> tendlr allows to use the same name for multiple (for now it applies only >> to ceph) clusters. That behavior seems correct, however it brings several >> problems as it's not easy to distinguish between such clusters in any list >> on UI. That's the cluster list itself but also hosts, pools and rbds lists. >> In those later ones the issue is with related cluster for displayed items. >> The same could be said when a user tries to create a new pool or rbd. That >> said tendrl should provide some means how the user could differentiate such >> clusters. >> > > I think that support for cluster names for ceph-ansible will be removed > https://bugzilla.redhat.com/show_bug.cgi?id=1459861 > > BUT it's really user unfriendly to identify cluster by its hash. So I > think that your point is valid and Tendrl should support names for clusters > internally. > > -- > Best Regards, > Martin Kudlej. > RHSC/USM Senior Quality Assurance Engineer > Red Hat Czech s.r.o. > > Phone: +420 532 294 155 > E-mail:mkudlej at redhat.com > IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, > #usm-meeting @ redhat > #tendrl-devel @ freenode > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > From sankarshan at redhat.com Wed Jun 14 14:04:11 2017 From: sankarshan at redhat.com (sankarshan) Date: Wed, 14 Jun 2017 19:34:11 +0530 Subject: [Tendrl-devel] repetitive cluster names In-Reply-To: References: <1499051836.34800397.1497444232287.JavaMail.zimbra@redhat.com> Message-ID: On 14 June 2017 at 18:51, Martin Kudlej wrote: > Hi Lubos, all, > > On 06/14/2017 02:43 PM, Lubos Trilety wrote: >> >> tendlr allows to use the same name for multiple (for now it applies only >> to ceph) clusters. That behavior seems correct, however it brings several >> problems as it's not easy to distinguish between such clusters in any list >> on UI. That's the cluster list itself but also hosts, pools and rbds lists. >> In those later ones the issue is with related cluster for displayed items. >> The same could be said when a user tries to create a new pool or rbd. That >> said tendrl should provide some means how the user could differentiate such >> clusters. > > > I think that support for cluster names for ceph-ansible will be removed > https://bugzilla.redhat.com/show_bug.cgi?id=1459861 > > BUT it's really user unfriendly to identify cluster by its hash. So I think > that your point is valid and Tendrl should support names for clusters > internally. This feedback has been brought up last week during a demo/discussion. Attempting to take this further - what's (from an admin perspective) a good/acceptable method of distinguishing between multiple clusters when listed in that UI? From shtripat at redhat.com Wed Jun 14 14:08:12 2017 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Wed, 14 Jun 2017 19:38:12 +0530 Subject: [Tendrl-devel] repetitive cluster names In-Reply-To: References: <1499051836.34800397.1497444232287.JavaMail.zimbra@redhat.com> Message-ID: On 06/14/2017 07:33 PM, Rohan Kanade wrote: > Look at this from the tendrl-api consumer's (cloudforms or ospd) > perspective. Being able to have a unique identifier to the cluster (i.e > tendrl_context.cluster_id) and being able to have a short cluster name are > both essential > > > > I think our default cluster_name should be standardised for gluster (and > for ceph when they remove cluster name support) > > It can be a smaller version (5 chars) of the $hash +-ceph|gluster" I like this idea as it would be easier to remember in this case. May be instead of randomly taking 5 chars from hash, can we think of a numeric representation as it would be more easier to remember? > > And we should turn off support for setting cluster name for new clusters > (imported clusters and have their cluster names) > > > On 14-Jun-2017 18:51, "Martin Kudlej" wrote: > >> Hi Lubos, all, >> >> On 06/14/2017 02:43 PM, Lubos Trilety wrote: >> >>> tendlr allows to use the same name for multiple (for now it applies only >>> to ceph) clusters. That behavior seems correct, however it brings several >>> problems as it's not easy to distinguish between such clusters in any list >>> on UI. That's the cluster list itself but also hosts, pools and rbds lists. >>> In those later ones the issue is with related cluster for displayed items. >>> The same could be said when a user tries to create a new pool or rbd. That >>> said tendrl should provide some means how the user could differentiate such >>> clusters. >>> >> I think that support for cluster names for ceph-ansible will be removed >> https://bugzilla.redhat.com/show_bug.cgi?id=1459861 >> >> BUT it's really user unfriendly to identify cluster by its hash. So I >> think that your point is valid and Tendrl should support names for clusters >> internally. >> >> -- >> Best Regards, >> Martin Kudlej. >> RHSC/USM Senior Quality Assurance Engineer >> Red Hat Czech s.r.o. >> >> Phone: +420 532 294 155 >> E-mail:mkudlej at redhat.com >> IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, >> #usm-meeting @ redhat >> #tendrl-devel @ freenode >> >> _______________________________________________ >> Tendrl-devel mailing list >> Tendrl-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/tendrl-devel >> > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel From ltrilety at redhat.com Thu Jun 15 05:03:04 2017 From: ltrilety at redhat.com (Lubos Trilety) Date: Thu, 15 Jun 2017 07:03:04 +0200 Subject: [Tendrl-devel] repetitive cluster names In-Reply-To: References: <1499051836.34800397.1497444232287.JavaMail.zimbra@redhat.com> Message-ID: <25B7F0C0-5C4F-4CF8-96C6-FD9AF4549A4F@redhat.com> Hi all, the idea with 5 chars representation on our side seems good. However when ceph clusters will not have specific names and the same could be said for gluster trusted pools, as their never have that and never will, we could allow to users to change the cluster name internally. We could just set internal names to be unique and catch all attempts to not be so. Only reason why names could be repetitive was that there could be multiple ceph clusters with the same name running on different machines. Lubos > On 14 Jun 2017, at 16:08, Shubhendu Tripathi wrote: > > On 06/14/2017 07:33 PM, Rohan Kanade wrote: >> Look at this from the tendrl-api consumer's (cloudforms or ospd) >> perspective. Being able to have a unique identifier to the cluster (i.e >> tendrl_context.cluster_id) and being able to have a short cluster name are >> both essential >> >> >> >> I think our default cluster_name should be standardised for gluster (and >> for ceph when they remove cluster name support) >> >> It can be a smaller version (5 chars) of the $hash +-ceph|gluster" > > I like this idea as it would be easier to remember in this case. May be instead of randomly taking 5 chars from hash, can we think of a numeric representation as it would be more easier to remember? > >> >> And we should turn off support for setting cluster name for new clusters >> (imported clusters and have their cluster names) >> >> >> On 14-Jun-2017 18:51, "Martin Kudlej" wrote: >> >>> Hi Lubos, all, >>> >>> On 06/14/2017 02:43 PM, Lubos Trilety wrote: >>> >>>> tendlr allows to use the same name for multiple (for now it applies only >>>> to ceph) clusters. That behavior seems correct, however it brings several >>>> problems as it's not easy to distinguish between such clusters in any list >>>> on UI. That's the cluster list itself but also hosts, pools and rbds lists. >>>> In those later ones the issue is with related cluster for displayed items. >>>> The same could be said when a user tries to create a new pool or rbd. That >>>> said tendrl should provide some means how the user could differentiate such >>>> clusters. >>>> >>> I think that support for cluster names for ceph-ansible will be removed >>> https://bugzilla.redhat.com/show_bug.cgi?id=1459861 >>> >>> BUT it's really user unfriendly to identify cluster by its hash. So I >>> think that your point is valid and Tendrl should support names for clusters >>> internally. >>> >>> -- >>> Best Regards, >>> Martin Kudlej. >>> RHSC/USM Senior Quality Assurance Engineer >>> Red Hat Czech s.r.o. >>> >>> Phone: +420 532 294 155 >>> E-mail:mkudlej at redhat.com >>> IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, >>> #usm-meeting @ redhat >>> #tendrl-devel @ freenode >>> >>> _______________________________________________ >>> Tendrl-devel mailing list >>> Tendrl-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/tendrl-devel >>> >> _______________________________________________ >> Tendrl-devel mailing list >> Tendrl-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/tendrl-devel > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel From mbukatov at redhat.com Fri Jun 16 17:39:42 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 16 Jun 2017 19:39:42 +0200 Subject: [Tendrl-devel] tracking issues with documentation from wiki and documentation in general Message-ID: <2164e5cd-c868-2d4c-c7e1-f87816969e4c@redhat.com> Dear all, I would like to know what is the preferred way to report and track issues with documentation maintained in the wiki here: https://github.com/Tendrl/documentation/wiki I'm not sure if filing a issue here: https://github.com/Tendrl/documentation/issues is a good idea, as the tracker here is designed for documentation repository itself and most of the issues reported there are ignored for long time (42 at the time of writing this, most of them months old). Which brings me to a more fundamental problem here - we still didn't figured out how the documentation for tendrl should work: https://github.com/Tendrl/specifications/issues/25#issuecomment-309085592 Looking at the list of stalled merge requests for the documentation repository: https://github.com/Tendrl/documentation/pulls (there are 11 stalled requests at the time of writing this) What would you suggest? Move all still relevant content from documentation repo into wiki (which seems to be working better now) or move content from wiki into documentation repo (which would also require to establish and maintain some level of order, including review of issues and merge requests, establishing ci to publish html build of the docs somewhere and so on ...)? -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Fri Jun 16 18:56:37 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 16 Jun 2017 20:56:37 +0200 Subject: [Tendrl-devel] Create cluster documentation In-Reply-To: <2e7fec9f-8e67-cf95-b85f-9010879deb36@redhat.com> References: <1748967170.14967977.1496325871068.JavaMail.zimbra@redhat.com> <2e7fec9f-8e67-cf95-b85f-9010879deb36@redhat.com> Message-ID: <97ac49ac-9e7e-8a20-1070-be1fc6ae7539@redhat.com> ping On 06/08/2017 07:56 PM, Martin Bukatovic wrote: > ping > > On 06/01/2017 04:04 PM, Filip Balak wrote: >> Hi Anup, >> >> could you please help me to better understand how to correctly set parameters for CreateCluster API call? From documentation[1] it isn't clear to me what is correct value for some parameters. >> >> Especialy parameters `provisioning_ip` and `node_identifier`. What could be correct values of those parameters? >> >> I have created issue[2] about clarity of documentation for this API call. >> >> Best Regards >> >> Filip Balak >> >> [1] https://github.com/Tendrl/api/blob/master/docs/clusters.adoc#create-cluster >> [2] https://github.com/Tendrl/api/issues/197 >> >> _______________________________________________ >> Tendrl-devel mailing list >> Tendrl-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/tendrl-devel >> > > -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Fri Jun 16 19:08:44 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 16 Jun 2017 21:08:44 +0200 Subject: [Tendrl-devel] ceph-mgr REST API In-Reply-To: <582e4a87-0c93-05f9-e43c-cb2614d8daba@redhat.com> References: <6c4ce752-4594-aa31-9d0e-35985e379c5a@suse.com> <582e4a87-0c93-05f9-e43c-cb2614d8daba@redhat.com> Message-ID: <5800c1cf-d2a8-2b0f-fd9b-27ee7073c0ee@redhat.com> ping what is the current plan related to ceph-mgr? On 05/22/2017 11:14 AM, Martin Bukatovic wrote: > On 05/17/2017 08:29 AM, Tim Serong wrote: >> There's a PR that's been open for a while to add a new pecan-based REST >> API to ceph-mgr: >> >> https://github.com/ceph/ceph/pull/14457 >> >> This is intended to be consumed internally by management tools such as >> openATTIC[1] and Tendrl[2] (and anything else that wants to manage a >> Ceph cluster via a REST API). >> >> There's been quite some discussion on the PR, and we also spoke about it >> at the May CDM, but I don't think much mention has occurred on the >> various mailing lists, so I'm writing this to raise awareness and >> solicit feedback. >> >> There's a desire to get this PR merged for the Luminous release, but >> possibly marked "experimental", so that at least we have something out >> there that people can start using. >> >> I had volunteered to document the delta between this ceph-mgr REST API >> and the Ceph REST API currently present in openATTIC, to attempt to >> gauge the effort involved in making openATTIC use the ceph-mgr REST API, >> but Sebastian Wagner has beaten me to it with some good details[3] >> (thanks!), so I'll just try to summarise here for the record: >> >> - Both APIs provide: >> - For OSDs: list, get details, modify (reweight, up/in state) >> - For Pools: list, get details, modify, delete >> - A means of handling long running requests (although AIUI these >> work somewhat differently) >> >> - The openATTIC API provides in addition: >> - For PGs: list (can be filtered by pool, osd), get details >> - For RBD volumes: list, create, delete, modify >> - For CephFS: list >> - For EC Profiles: list, create, delete >> - Pagination of lists (important for non-small clusters) >> >> - The ceph-mgr REST API provides in addition: >> - For cluster config options: list, get value >> - For CRUSH rules: list >> - For MONs: list, get details >> - For OSDs: run commands (scrub, deep_scrub, repair) >> - For Servers: list, get details >> >> There are also some differences in naming and which fields are >> exposed[4], but hopefully this is enough to give a general idea. My >> apologies to Boris Ranto (ceph-mgr REST API) and the openATTIC folks if >> I've gotten anything wrong here. > > Thanks for keeping us involved. > > My feeling is that we should try to evaluate Tendrl API and try to > keep as close as possible to proposed ceph-mgr API - unless we have > some problem with the design, but then we should try to influence the > design on ceph side. > > It seems that we need to cleanup the Tenrl API anyway, as the current > implementation suffers with some design problems - see email > "[Tendrl-devel] REST API consistency". > -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Fri Jun 16 19:11:05 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 16 Jun 2017 21:11:05 +0200 Subject: [Tendrl-devel] tracking issues with documentation from wiki and documentation in general In-Reply-To: <2164e5cd-c868-2d4c-c7e1-f87816969e4c@redhat.com> References: <2164e5cd-c868-2d4c-c7e1-f87816969e4c@redhat.com> Message-ID: <03d81389-2f25-e0c8-e33f-96255864df92@redhat.com> On 06/16/2017 07:39 PM, Martin Bukatovic wrote: > Dear all, > > I would like to know what is the preferred way to report and > track issues with documentation maintained in the wiki here: > > https://github.com/Tendrl/documentation/wiki In the meantime, I created new issue here: https://github.com/Tendrl/documentation/issues/85 based on discussions from tendrl-devel, which hasn't been fully resolved -- Martin Bukatovic USM QE team Red Hat From sankarshan at redhat.com Sat Jun 17 03:05:31 2017 From: sankarshan at redhat.com (sankarshan) Date: Sat, 17 Jun 2017 08:35:31 +0530 Subject: [Tendrl-devel] tracking issues with documentation from wiki and documentation in general In-Reply-To: <2164e5cd-c868-2d4c-c7e1-f87816969e4c@redhat.com> References: <2164e5cd-c868-2d4c-c7e1-f87816969e4c@redhat.com> Message-ID: On 16 June 2017 at 23:09, Martin Bukatovic wrote: > Dear all, > > I would like to know what is the preferred way to report and > track issues with documentation maintained in the wiki here: > > https://github.com/Tendrl/documentation/wiki > > I'm not sure if filing a issue here: > > https://github.com/Tendrl/documentation/issues > > is a good idea, as the tracker here is designed for documentation > repository itself and most of the issues reported there are > ignored for long time (42 at the time of writing this, most of > them months old). > I would think that we have not had the momentum around the documentation bits to be able to have as comprehensive ownership and maintenance as we have across the other components. This is bad - incredibly so. Because the current span or, extent of the documentation is limited to installation process and debug help. I myself have not collated the ToC I had put forth on this list a while back. Over the weekend I am going to take a look at some of the stalled issues and update with comments or, merge them if appropriate. Having said that, we do need a more comprehensive ownership - else, this ill tended garden will be overrun with weeds. > Which brings me to a more fundamental problem here - we still > didn't figured out how the documentation for tendrl should work: > > https://github.com/Tendrl/specifications/issues/25#issuecomment-309085592 > > Looking at the list of stalled merge requests for the documentation > repository: > > https://github.com/Tendrl/documentation/pulls > > (there are 11 stalled requests at the time of writing this) > > What would you suggest? Move all still relevant content from > documentation repo into wiki (which seems to be working better > now) or move content from wiki into documentation repo (which > would also require to establish and maintain some level of order, > including review of issues and merge requests, establishing ci > to publish html build of the docs somewhere and so on ...)? > > -- > Martin Bukatovic > USM QE team > Red Hat > From sankarshan.mukhopadhyay at gmail.com Sat Jun 17 03:10:35 2017 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Sat, 17 Jun 2017 08:40:35 +0530 Subject: [Tendrl-devel] Create cluster documentation In-Reply-To: <97ac49ac-9e7e-8a20-1070-be1fc6ae7539@redhat.com> References: <1748967170.14967977.1496325871068.JavaMail.zimbra@redhat.com> <2e7fec9f-8e67-cf95-b85f-9010879deb36@redhat.com> <97ac49ac-9e7e-8a20-1070-be1fc6ae7539@redhat.com> Message-ID: On Sat, Jun 17, 2017 at 12:26 AM, Martin Bukatovic wrote: > ping > Which aspect are you following through? There's as an update on the issue and that also has the note from Anup about following up on updating the documentation. Pings-with-context help me understand the issue here :) > On 06/08/2017 07:56 PM, Martin Bukatovic wrote: >> ping >> >> On 06/01/2017 04:04 PM, Filip Balak wrote: >>> Hi Anup, >>> >>> could you please help me to better understand how to correctly set parameters for CreateCluster API call? From documentation[1] it isn't clear to me what is correct value for some parameters. >>> >>> Especialy parameters `provisioning_ip` and `node_identifier`. What could be correct values of those parameters? >>> >>> I have created issue[2] about clarity of documentation for this API call. >>> >>> Best Regards >>> >>> Filip Balak >>> >>> [1] https://github.com/Tendrl/api/blob/master/docs/clusters.adoc#create-cluster >>> [2] https://github.com/Tendrl/api/issues/197 >>> >>> _______________________________________________ >>> Tendrl-devel mailing list >>> Tendrl-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/tendrl-devel >>> >> >> > > > -- > Martin Bukatovic > USM QE team > Red Hat > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel -- sankarshan mukhopadhyay From sankarshan.mukhopadhyay at gmail.com Sat Jun 17 03:11:24 2017 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Sat, 17 Jun 2017 08:41:24 +0530 Subject: [Tendrl-devel] repetitive cluster names In-Reply-To: <25B7F0C0-5C4F-4CF8-96C6-FD9AF4549A4F@redhat.com> References: <1499051836.34800397.1497444232287.JavaMail.zimbra@redhat.com> <25B7F0C0-5C4F-4CF8-96C6-FD9AF4549A4F@redhat.com> Message-ID: Did we arrive at a consensus on this topic? How has action item to nail it down into a spec? On Thu, Jun 15, 2017 at 10:33 AM, Lubos Trilety wrote: > Hi all, > > the idea with 5 chars representation on our side seems good. However when ceph clusters will not have specific names and the same could be said for gluster trusted pools, as their never have that and never will, we could allow to users to change the cluster name internally. We could just set internal names to be unique and catch all attempts to not be so. Only reason why names could be repetitive was that there could be multiple ceph clusters with the same name running on different machines. > > Lubos > >> On 14 Jun 2017, at 16:08, Shubhendu Tripathi wrote: >> >> On 06/14/2017 07:33 PM, Rohan Kanade wrote: >>> Look at this from the tendrl-api consumer's (cloudforms or ospd) >>> perspective. Being able to have a unique identifier to the cluster (i.e >>> tendrl_context.cluster_id) and being able to have a short cluster name are >>> both essential >>> >>> >>> >>> I think our default cluster_name should be standardised for gluster (and >>> for ceph when they remove cluster name support) >>> >>> It can be a smaller version (5 chars) of the $hash +-ceph|gluster" >> >> I like this idea as it would be easier to remember in this case. May be instead of randomly taking 5 chars from hash, can we think of a numeric representation as it would be more easier to remember? >> >>> >>> And we should turn off support for setting cluster name for new clusters >>> (imported clusters and have their cluster names) >>> >>> >>> On 14-Jun-2017 18:51, "Martin Kudlej" wrote: >>> >>>> Hi Lubos, all, >>>> >>>> On 06/14/2017 02:43 PM, Lubos Trilety wrote: >>>> >>>>> tendlr allows to use the same name for multiple (for now it applies only >>>>> to ceph) clusters. That behavior seems correct, however it brings several >>>>> problems as it's not easy to distinguish between such clusters in any list >>>>> on UI. That's the cluster list itself but also hosts, pools and rbds lists. >>>>> In those later ones the issue is with related cluster for displayed items. >>>>> The same could be said when a user tries to create a new pool or rbd. That >>>>> said tendrl should provide some means how the user could differentiate such >>>>> clusters. >>>>> >>>> I think that support for cluster names for ceph-ansible will be removed >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1459861 >>>> >>>> BUT it's really user unfriendly to identify cluster by its hash. So I >>>> think that your point is valid and Tendrl should support names for clusters >>>> internally. >>>> >>>> -- >>>> Best Regards, >>>> Martin Kudlej. >>>> RHSC/USM Senior Quality Assurance Engineer >>>> Red Hat Czech s.r.o. >>>> >>>> Phone: +420 532 294 155 >>>> E-mail:mkudlej at redhat.com >>>> IRC: mkudlej at #brno, #gluster, #storage-qa, #rhs, #rh-ceph, >>>> #usm-meeting @ redhat >>>> #tendrl-devel @ freenode >>>> >>>> _______________________________________________ >>>> Tendrl-devel mailing list >>>> Tendrl-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/tendrl-devel >>>> >>> _______________________________________________ >>> 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 -- sankarshan mukhopadhyay From rkanade at redhat.com Sat Jun 17 17:51:56 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Sat, 17 Jun 2017 23:21:56 +0530 Subject: [Tendrl-devel] question on storage node GUIDs In-Reply-To: References: Message-ID: Here are the steps followed by tendrl-node-agent on startup (pseudo code) 1) machine_id = read_file("/etc/machine-id") (Get current node's machine id) 2) last_known_node_id = etcd_read("/indexes/machine_id/$machine_id") (Get the last seen tendrl node_id for above machine id) 3) local_node_id = read_file("/var/lib/tendrl/node_id")' if local_node_id is not found 4) Generate node_id for this node if and only if Tendrl has not seen this node's machine id before i.e. "last_known_node_id" is None if last_known_node_id == local_node_id 4) Everything's good, Tendrl recognizes this node as an already managed node TLDR: Tendrl remembers the machine id for each node and associates a Tendrl node_id to each such node. To Unmanage a node from Tendrl, delete "/var/lib/tendrl/node_id" and delete etcd("/indexes/machine_id/$machine_id") On Mon, Jun 5, 2017 at 7:21 AM, Jeff Applewhite wrote: > Hi All > > I have a test bed where I had 8 nodes. 3 of them were in an existing ceph > cluster. 1 was in a single node Ceph cluster. I deleted the one standalone > cluster and rebuilt the node completely to a "fresh centos" install. It is > no longer registered at all. > > That brings me to a total of 7 registered nodes out of the previous 8 and 1 > pre-existing 3 node ceph cluster. > > I then deleted the etcd data on the tendrl node, reinstalled etcd, > recreated the admin user, and restarted all the node agents on the storage > nodes. > > Now granted this is less than a "clean install" procedure but I would have > hoped to see the node agents re-register with the new etcd/api/tendrl node, > despite having previously been registered to a tendrl node that was in the > same IP/Port location. I would also expect to see my pre-existing ceph > cluster show up for importing - which it did..so I successfully re-imported > it -- nice! > > But - I really should now expect to see > [root at tendrl ~]# etcdctl --endpoints http://tendrl:2379 ls /nodes| wc -l > 7 > > when in fact I see.. > > [root at tendrl ~]# etcdctl --endpoints http://tendrl:2379 ls /nodes| wc -l > 15 > > or 7 "new nodes" + 8 "old nodes" = 15 -- so in essence all the nodes seem > to generate a new id within etcd when they register, but their old GUID > also gets into etcd somehow.. > > I think this behavior might be problematic for some users. In a large > cluster it would be nice to be able to flush etcd (or some subset of it), > restart the node agents and have them re-appear with their old GUID (not a > new GUID and the old one too). > > Can someone explain the current behavior and the rationale? There might be > good technical reasons for the behavior but I'd like to understand them. > I'd rather not file a bug until I understand a little better what is going > on here. > > It seems like maybe the Tendrl node needs some way to detect this case: > > "oh - I have a Tendrl storage node agent reporting to me and it seems to > have a previous identity, maybe I should just re-use that GUID instead of > generating a new one" > > or... > > maybe the "old" node agent should be whacked on the head and told > "no your old GUID is no good around here - use this one instead!" > > Either behavior would prevent more GUIDs than nodes in etcd. > > Thoughts? > > > Jeff > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel > From rkanade at redhat.com Sun Jun 18 13:45:07 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Sun, 18 Jun 2017 19:15:07 +0530 Subject: [Tendrl-devel] Tendrl performance profiler (feedback wanted) Message-ID: I have documented the newly introduced Tendrl internal profiler and its usage Give it a spin: https://github.com/Tendrl/documentation/wiki/Tendrl-profiling From sankarshan at redhat.com Sun Jun 18 13:49:31 2017 From: sankarshan at redhat.com (sankarshan) Date: Sun, 18 Jun 2017 19:19:31 +0530 Subject: [Tendrl-devel] tracking issues with documentation from wiki and documentation in general In-Reply-To: References: <2164e5cd-c868-2d4c-c7e1-f87816969e4c@redhat.com> Message-ID: On 17 June 2017 at 08:35, sankarshan wrote: > Over the weekend I am going to take a look at some of the stalled > issues and update with comments or, merge them if appropriate. Most of the PRs have benign issues and they should be merged. I don't see sign-off in the comments stating they are ready to be so - I am not sure if that has been the case for the repo previously. From mbukatov at redhat.com Mon Jun 19 11:30:38 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Mon, 19 Jun 2017 13:30:38 +0200 Subject: [Tendrl-devel] Create cluster documentation In-Reply-To: References: <1748967170.14967977.1496325871068.JavaMail.zimbra@redhat.com> <2e7fec9f-8e67-cf95-b85f-9010879deb36@redhat.com> <97ac49ac-9e7e-8a20-1070-be1fc6ae7539@redhat.com> Message-ID: <3dc472d6-9aa9-d832-9840-5d0c73000a6b@redhat.com> On 06/17/2017 05:10 AM, Sankarshan Mukhopadhyay wrote: > On Sat, Jun 17, 2017 at 12:26 AM, Martin Bukatovic wrote: >> ping >> > > Which aspect are you following through? There's > as > an update on the issue and that also has the note from Anup about > following up on updating the documentation. > > Pings-with-context help me understand the issue here :) You are right, this one seems to be moving into right direction, I didn't check the status enough and thought that it got stalled. Sorry for the confusion. -- Martin Bukatovic USM QE team Red Hat From rkanade at redhat.com Mon Jun 19 13:44:09 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Mon, 19 Jun 2017 19:14:09 +0530 Subject: [Tendrl-devel] tendrl-release v1.4.2 (alpha3) is available Message-ID: Hello, The Tendrl team is happy to present tendrl-release v1.4.2 (alpha3) Summary: https://github.com/Tendrl/documentation/wiki/Tendrl-release-v1.4.2-(summary) Install docs: https://github.com/Tendrl/documentation/wiki/Tendrl-release-v1.4.2-(install-doc) Cheers! From dahorak at redhat.com Mon Jun 19 13:47:40 2017 From: dahorak at redhat.com (=?UTF-8?Q?Daniel_Hor=c3=a1k?=) Date: Mon, 19 Jun 2017 15:47:40 +0200 Subject: [Tendrl-devel] CentOS CI status summary Message-ID: Hi all, let me summarize the current state of CentOS CI related things. **Building Tendrl packages in CentOS CI (more precisely triggering the builds in Copr)** - jobs for building all Tendrl packages from develop and latest release branch are ready[1,2]. - The packages are now build in my testing Copr repository[3], but it is only about small configuration change to move it to official Tendrl Copr repo (I don't want to move it there before I'll be sure everything works as expected). - There are few issues[4] related to the building process (mainly missing targets in Makefile) which needs to be fixed to be able to build all the Tendrl packages without further workarounds. **Test executed in CentOS CI** The "Tendrl CI Dashboard"[5] now contains status of 10 jobs: - Jobs 1 - 4: Package validation (with issues in rpmlint and rpmdeplint) - Jobs 5 - 7 are divided to Ceph and Gluster and they are supposed to install particular cluster (job 5) and run Ceph/Gluster specific tests (job6) and other - common - tests (job7). - Cluster installation (Jobs 5) commonly works (it uses packages from release repo). - Ceph/Gluster specific tests are failing (I'll have to check if it is expected/known issue or if it is problem with the infrastructure or tests itself). - Other (common) tests are passing with one known/expected failure[6] (so that's the reason for yellow color instead of green). I'll continue on the improvement of the CI workflow, check the failures and prospectively send another update or create related issues. [1] https://ci.centos.org/view/tendrl-build/ [2] https://github.com/Tendrl/usmqe-centos-ci/pull/1 [3] https://copr.fedorainfracloud.org/coprs/dahorak/tendrl-test/builds/ [4] https://github.com/Tendrl/api/issues/202 https://github.com/Tendrl/api/issues/209 https://github.com/Tendrl/dashboard/issues/442 [5] https://ci.centos.org/view/Tendrl/ [6] https://bugzilla.redhat.com/show_bug.cgi?id=1457220 https://github.com/Tendrl/api/issues/140 Regards, Daniel From japplewh at redhat.com Mon Jun 19 19:01:33 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Mon, 19 Jun 2017 15:01:33 -0400 Subject: [Tendrl-devel] Troubleshooting/diagnosing storage node detection issues Message-ID: Hi All I have taken on the unofficial role of tester of Tendrl in a variety of virtual environments. My status thus far is: Two additional disks have been added to storage nodes in these environments. I run the storage node ansible setup from tendrl-ansible.. Node detection works in: - Digital Ocean (with recent bug fix) - QCOW / KVM testbeds Does not work in: - GCE - VirtualBox (see Vagrantfile for setup in tendrl-ansible repo) Have not yet tested: - AWS - Bare metal hardware! *How can I troubleshoot or get valuable logs for diagnosing/fixing the underlying issues/filing bugs?* I suspect they are hardware detection related but this is just a guess without evidence. In many cases I see nothing of use in /var/log/messages file. Thanks, ?~Jeff From mrugesh at brainfunked.org Tue Jun 20 11:33:17 2017 From: mrugesh at brainfunked.org (Mrugesh Karnik) Date: Tue, 20 Jun 2017 17:03:17 +0530 Subject: [Tendrl-devel] Troubleshooting/diagnosing storage node detection issues In-Reply-To: References: Message-ID: On 20 June 2017 at 00:31, Jeff Applewhite wrote: > *How can I troubleshoot or get valuable logs for diagnosing/fixing the > underlying issues/filing bugs?* I suspect they are hardware detection > related but this is just a guess without evidence. In many cases I see > nothing of use in /var/log/messages file. journalctl -u tendrl-node-agent.service > "tendrl-node-agent-$(hostname).log" should be useful to start with. -- Mrugesh From japplewh at redhat.com Tue Jun 20 13:11:29 2017 From: japplewh at redhat.com (Jeff Applewhite) Date: Tue, 20 Jun 2017 09:11:29 -0400 Subject: [Tendrl-devel] Github Issues Message-ID: Hi All I think we need to do some cleanup with Github issues. There are many I think that are either fixed and not in closed state. Other issues are not bugs and so another thing that would help is to clearly tag anything that is a bug with the BUG tag. This will help in sorting and triage. Once we have some better organization around this I'd like to propose a scrub meeting to go through only the BUG tagged issues and do some prioritization on these. Thoughts? Jeff From sankarshan at redhat.com Tue Jun 20 13:15:12 2017 From: sankarshan at redhat.com (sankarshan) Date: Tue, 20 Jun 2017 18:45:12 +0530 Subject: [Tendrl-devel] Github Issues In-Reply-To: References: Message-ID: On 20 June 2017 at 18:41, Jeff Applewhite wrote: > Hi All > > I think we need to do some cleanup with Github issues. There are many I > think that are either fixed and not in closed state. Other issues are not > bugs and so another thing that would help is to clearly tag anything that > is a bug with the BUG tag. This will help in sorting and triage. > Issues which are fixed are cited in the PRs. However, it is worth doing a scrub to get things squared away. > Once we have some better organization around this I'd like to propose a > scrub meeting to go through only the BUG tagged issues and do some > prioritization on these. > The present set of labels available are listed at > Thoughts? From dahorak at redhat.com Tue Jun 20 13:29:36 2017 From: dahorak at redhat.com (=?UTF-8?Q?Daniel_Hor=c3=a1k?=) Date: Tue, 20 Jun 2017 15:29:36 +0200 Subject: [Tendrl-devel] CentOS CI status summary In-Reply-To: References: Message-ID: <6e996c3d-24b5-db76-5dbb-82a53b58b81e@redhat.com> Just short update: * I've updated the package validation tests configuration, so now it is consuming packages from copr tendrl/release repository (and it is passing). * Also there seems to be fixed one issue in Tendrl API, so "others" tests are passing too. Regards, Daniel On 06/19/17 15:47, Daniel Hor?k wrote: > Hi all, > > let me summarize the current state of CentOS CI related things. > > **Building Tendrl packages in CentOS CI (more precisely triggering the > builds in Copr)** > - jobs for building all Tendrl packages from develop and latest release > branch are ready[1,2]. > - The packages are now build in my testing Copr repository[3], but it is > only about small configuration change to move it to official Tendrl Copr > repo (I don't want to move it there before I'll be sure everything works > as expected). > - There are few issues[4] related to the building process (mainly > missing targets in Makefile) which needs to be fixed to be able to build > all the Tendrl packages without further workarounds. > > > **Test executed in CentOS CI** > The "Tendrl CI Dashboard"[5] now contains status of 10 jobs: > - Jobs 1 - 4: Package validation (with issues in rpmlint and rpmdeplint) > - Jobs 5 - 7 are divided to Ceph and Gluster and they are supposed to > install particular cluster (job 5) and run Ceph/Gluster specific tests > (job6) and other - common - tests (job7). > > - Cluster installation (Jobs 5) commonly works (it uses packages from > release repo). > - Ceph/Gluster specific tests are failing (I'll have to check if it is > expected/known issue or if it is problem with the infrastructure or > tests itself). > - Other (common) tests are passing with one known/expected failure[6] > (so that's the reason for yellow color instead of green). > > I'll continue on the improvement of the CI workflow, check the failures > and prospectively send another update or create related issues. > > > [1] https://ci.centos.org/view/tendrl-build/ > [2] https://github.com/Tendrl/usmqe-centos-ci/pull/1 > [3] https://copr.fedorainfracloud.org/coprs/dahorak/tendrl-test/builds/ > [4] https://github.com/Tendrl/api/issues/202 > https://github.com/Tendrl/api/issues/209 > https://github.com/Tendrl/dashboard/issues/442 > [5] https://ci.centos.org/view/Tendrl/ > [6] https://bugzilla.redhat.com/show_bug.cgi?id=1457220 > https://github.com/Tendrl/api/issues/140 > > Regards, > Daniel > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel From amainkar at redhat.com Tue Jun 20 13:48:55 2017 From: amainkar at redhat.com (Anjali Mainkar) Date: Tue, 20 Jun 2017 09:48:55 -0400 (EDT) Subject: [Tendrl-devel] CentOS CI status summary In-Reply-To: <6e996c3d-24b5-db76-5dbb-82a53b58b81e@redhat.com> References: <6e996c3d-24b5-db76-5dbb-82a53b58b81e@redhat.com> Message-ID: <1205289536.24504277.1497966535119.JavaMail.zimbra@redhat.com> Great work Daniel! Thanks for all your efforts. Anjali ----- Original Message ----- | From: "Daniel Hor?k" | To: "Mailing list for the contributors to the Tendrl project" | Sent: Tuesday, June 20, 2017 9:29:36 AM | Subject: Re: [Tendrl-devel] CentOS CI status summary | | Just short update: | * I've updated the package validation tests configuration, so now it is | consuming packages from copr tendrl/release repository (and it is passing). | | * Also there seems to be fixed one issue in Tendrl API, so "others" | tests are passing too. | | Regards, | Daniel | | On 06/19/17 15:47, Daniel Hor?k wrote: | > Hi all, | > | > let me summarize the current state of CentOS CI related things. | > | > **Building Tendrl packages in CentOS CI (more precisely triggering the | > builds in Copr)** | > - jobs for building all Tendrl packages from develop and latest release | > branch are ready[1,2]. | > - The packages are now build in my testing Copr repository[3], but it is | > only about small configuration change to move it to official Tendrl Copr | > repo (I don't want to move it there before I'll be sure everything works | > as expected). | > - There are few issues[4] related to the building process (mainly | > missing targets in Makefile) which needs to be fixed to be able to build | > all the Tendrl packages without further workarounds. | > | > | > **Test executed in CentOS CI** | > The "Tendrl CI Dashboard"[5] now contains status of 10 jobs: | > - Jobs 1 - 4: Package validation (with issues in rpmlint and rpmdeplint) | > - Jobs 5 - 7 are divided to Ceph and Gluster and they are supposed to | > install particular cluster (job 5) and run Ceph/Gluster specific tests | > (job6) and other - common - tests (job7). | > | > - Cluster installation (Jobs 5) commonly works (it uses packages from | > release repo). | > - Ceph/Gluster specific tests are failing (I'll have to check if it is | > expected/known issue or if it is problem with the infrastructure or | > tests itself). | > - Other (common) tests are passing with one known/expected failure[6] | > (so that's the reason for yellow color instead of green). | > | > I'll continue on the improvement of the CI workflow, check the failures | > and prospectively send another update or create related issues. | > | > | > [1] https://ci.centos.org/view/tendrl-build/ | > [2] https://github.com/Tendrl/usmqe-centos-ci/pull/1 | > [3] https://copr.fedorainfracloud.org/coprs/dahorak/tendrl-test/builds/ | > [4] https://github.com/Tendrl/api/issues/202 | > https://github.com/Tendrl/api/issues/209 | > https://github.com/Tendrl/dashboard/issues/442 | > [5] https://ci.centos.org/view/Tendrl/ | > [6] https://bugzilla.redhat.com/show_bug.cgi?id=1457220 | > https://github.com/Tendrl/api/issues/140 | > | > Regards, | > Daniel | > | > _______________________________________________ | > Tendrl-devel mailing list | > Tendrl-devel at redhat.com | > https://www.redhat.com/mailman/listinfo/tendrl-devel | | _______________________________________________ | Tendrl-devel mailing list | Tendrl-devel at redhat.com | https://www.redhat.com/mailman/listinfo/tendrl-devel | From mbukatov at redhat.com Thu Jun 22 06:17:22 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 22 Jun 2017 08:17:22 +0200 Subject: [Tendrl-devel] provisioner gluster Message-ID: <70485d75-963b-1052-1461-05c8cbe1ea57@redhat.com> Dear all, I would like to clarify setup of provisioner/gluster tag, as documented in package installation reference[1], which states that the tag should be added into /etc/tendrl/node-agent/node-agent.conf.yaml file on every storage node, while my impression was that this should be done on a single storage machine only. Could someone elaborate? I'm tracking this here: https://github.com/Tendrl/documentation/issues/85 based on this: https://github.com/Tendrl/tendrl-ansible/issues/14 [1] https://github.com/Tendrl/documentation/wiki/Tendrl-Package-Installation-Reference -- Martin Bukatovic USM QE team Red Hat From shtripat at redhat.com Thu Jun 22 06:24:23 2017 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Thu, 22 Jun 2017 11:54:23 +0530 Subject: [Tendrl-devel] provisioner gluster In-Reply-To: <70485d75-963b-1052-1461-05c8cbe1ea57@redhat.com> References: <70485d75-963b-1052-1461-05c8cbe1ea57@redhat.com> Message-ID: <77daa0af-e679-89a9-2859-dc28114b21a7@redhat.com> Martin, So its like while cluster creation flow only node should be marked as `provisioner/gluster` and also the gdeploy repos shpould be pre-added to this node. While cluster creation gdeploy and python-gdeploy get installed on this node and then used. During import cluster, the job gets submitted to any node having tag `gluster/node` and as all the gluster nodes are marked with that, randomly any node can pick the import cluster job. Thats the reason I feel its mentioned as adding `provisioner/gluster` on all the gluster nodes. Just having this tag doesnt suffice as gdeploy repos also required for import to be successful. Hope this helps you. Regards, Shubhendu On 06/22/2017 11:47 AM, Martin Bukatovic wrote: > Dear all, > > I would like to clarify setup of provisioner/gluster tag, as > documented in package installation reference[1], which states > that the tag should be added into > /etc/tendrl/node-agent/node-agent.conf.yaml file on every storage node, > while my impression > was that this should be done on a single storage machine only. > > Could someone elaborate? > > I'm tracking this here: > > https://github.com/Tendrl/documentation/issues/85 > > based on this: > > https://github.com/Tendrl/tendrl-ansible/issues/14 > > [1] > https://github.com/Tendrl/documentation/wiki/Tendrl-Package-Installation-Reference > From shtripat at redhat.com Thu Jun 22 06:26:36 2017 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Thu, 22 Jun 2017 11:56:36 +0530 Subject: [Tendrl-devel] provisioner gluster In-Reply-To: <77daa0af-e679-89a9-2859-dc28114b21a7@redhat.com> References: <70485d75-963b-1052-1461-05c8cbe1ea57@redhat.com> <77daa0af-e679-89a9-2859-dc28114b21a7@redhat.com> Message-ID: <59c708fe-7daa-403e-a381-ebe478b748f0@redhat.com> Also there is a PR https://github.com/Tendrl/commons/pull/622 in progress for import cluster flow, which checks if already there is a node with tag `provisioner/gluster` and installs gdeploy, python-gdeploy on that node only for further gluster operations. On 06/22/2017 11:54 AM, Shubhendu Tripathi wrote: > Martin, > > So its like while cluster creation flow only node should be marked as > `provisioner/gluster` and also the gdeploy repos shpould be pre-added > to this node. > While cluster creation gdeploy and python-gdeploy get installed on > this node and then used. > > During import cluster, the job gets submitted to any node having tag > `gluster/node` and as all the gluster nodes are marked with that, > randomly any node can pick the import cluster job. Thats the reason I > feel its mentioned as adding `provisioner/gluster` on all the gluster > nodes. Just having this tag doesnt suffice as gdeploy repos also > required for import to be successful. > > Hope this helps you. > > Regards, > Shubhendu > > > On 06/22/2017 11:47 AM, Martin Bukatovic wrote: >> Dear all, >> >> I would like to clarify setup of provisioner/gluster tag, as >> documented in package installation reference[1], which states >> that the tag should be added into >> /etc/tendrl/node-agent/node-agent.conf.yaml file on every storage node, >> while my impression >> was that this should be done on a single storage machine only. >> >> Could someone elaborate? >> >> I'm tracking this here: >> >> https://github.com/Tendrl/documentation/issues/85 >> >> based on this: >> >> https://github.com/Tendrl/tendrl-ansible/issues/14 >> >> [1] >> https://github.com/Tendrl/documentation/wiki/Tendrl-Package-Installation-Reference >> >> > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel From shtripat at redhat.com Thu Jun 22 10:28:54 2017 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Thu, 22 Jun 2017 15:58:54 +0530 Subject: [Tendrl-devel] provisioner gluster In-Reply-To: <59c708fe-7daa-403e-a381-ebe478b748f0@redhat.com> References: <70485d75-963b-1052-1461-05c8cbe1ea57@redhat.com> <77daa0af-e679-89a9-2859-dc28114b21a7@redhat.com> <59c708fe-7daa-403e-a381-ebe478b748f0@redhat.com> Message-ID: Martin, The wiki is modified now and it says to set tag `provisioner/gluster` on one node only. Also there was a typo in my previous reply. Corrected the same inline below. Regards, Shubhendu On 06/22/2017 11:56 AM, Shubhendu Tripathi wrote: > Also there is a PR https://github.com/Tendrl/commons/pull/622 in > progress for import cluster flow, which checks if already there is a > node with tag `provisioner/gluster` and installs gdeploy, > python-gdeploy on that node only for further gluster operations. > > On 06/22/2017 11:54 AM, Shubhendu Tripathi wrote: >> Martin, >> >> So its like while cluster creation flow only node should be marked as >> `provisioner/gluster` and also the gdeploy repos shpould be pre-added >> to this node. >> While cluster creation gdeploy and python-gdeploy get installed on >> this node and then used. >> >> During import cluster, the job gets submitted to any node having tag >> `gluster/node` and as all the gluster nodes are marked with that, >> randomly any node can pick the During import cluster, the job gets submitted to any node having tag `tendrl/node` and as all the nodes are marked with that, randomly any node can pick the >> import cluster job. Thats the reason I feel its mentioned as adding >> `provisioner/gluster` on all the gluster nodes. Just having this tag >> doesnt suffice as gdeploy repos also required for import to be >> successful. >> >> Hope this helps you. >> >> Regards, >> Shubhendu >> >> >> On 06/22/2017 11:47 AM, Martin Bukatovic wrote: >>> Dear all, >>> >>> I would like to clarify setup of provisioner/gluster tag, as >>> documented in package installation reference[1], which states >>> that the tag should be added into >>> /etc/tendrl/node-agent/node-agent.conf.yaml file on every storage node, >>> while my impression >>> was that this should be done on a single storage machine only. >>> >>> Could someone elaborate? >>> >>> I'm tracking this here: >>> >>> https://github.com/Tendrl/documentation/issues/85 >>> >>> based on this: >>> >>> https://github.com/Tendrl/tendrl-ansible/issues/14 >>> >>> [1] >>> https://github.com/Tendrl/documentation/wiki/Tendrl-Package-Installation-Reference >>> >>> >> >> _______________________________________________ >> 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 Thu Jun 22 12:16:03 2017 From: rkanade at redhat.com (Rohan Kanade) Date: Thu, 22 Jun 2017 17:46:03 +0530 Subject: [Tendrl-devel] Upstream testing Message-ID: Hi, Please use the latest upstream release (currently : tendrl-release 1.4.2) for testing Link: https://github.com/Tendrl/documentation/wiki/Tendrl-release-v1.4.2-(install-doc) From mbukatov at redhat.com Thu Jun 22 15:30:52 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 22 Jun 2017 17:30:52 +0200 Subject: [Tendrl-devel] provisioner gluster In-Reply-To: References: <70485d75-963b-1052-1461-05c8cbe1ea57@redhat.com> <77daa0af-e679-89a9-2859-dc28114b21a7@redhat.com> <59c708fe-7daa-403e-a381-ebe478b748f0@redhat.com> Message-ID: <9f50078e-7dd5-426e-3d53-b40e17f37105@redhat.com> On 06/22/2017 12:28 PM, Shubhendu Tripathi wrote: > The wiki is modified now and it says to set tag `provisioner/gluster` on > one node only. > Also there was a typo in my previous reply. Corrected the same inline > below. Thanks a lot for the fix and explanation. Marking as resolved. -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Thu Jun 22 15:42:24 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 22 Jun 2017 17:42:24 +0200 Subject: [Tendrl-devel] provisioner gluster In-Reply-To: <59c708fe-7daa-403e-a381-ebe478b748f0@redhat.com> References: <70485d75-963b-1052-1461-05c8cbe1ea57@redhat.com> <77daa0af-e679-89a9-2859-dc28114b21a7@redhat.com> <59c708fe-7daa-403e-a381-ebe478b748f0@redhat.com> Message-ID: <443001ec-b960-ce82-6e3a-da684afd193b@redhat.com> On 06/22/2017 08:26 AM, Shubhendu Tripathi wrote: > Also there is a PR https://github.com/Tendrl/commons/pull/622 in > progress for import cluster flow, which checks if already there is a > node with tag `provisioner/gluster` and installs gdeploy, python-gdeploy > on that node only for further gluster operations. This caught my attention: for ceph integration it works vice versa: Tendrl detects that ceph-installer is up and running and based on that, tags the machine as provisioner/ceph. Is this discrepancy in approaches temporary or do we plan to install ceph-installer as well keeping the detection feature as it works now? -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Thu Jun 22 15:43:44 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Thu, 22 Jun 2017 17:43:44 +0200 Subject: [Tendrl-devel] Upstream testing In-Reply-To: References: Message-ID: <5681da34-99a3-0379-0ae1-fb27a0551f87@redhat.com> On 06/22/2017 02:16 PM, Rohan Kanade wrote: > Please use the latest upstream release (currently : tendrl-release 1.4.2) > for testing > > Link: > https://github.com/Tendrl/documentation/wiki/Tendrl-release-v1.4.2-(install-doc) ack, thank you for this update -- Martin Bukatovic USM QE team Red Hat From shtripat at redhat.com Fri Jun 23 03:57:52 2017 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Fri, 23 Jun 2017 09:27:52 +0530 Subject: [Tendrl-devel] provisioner gluster In-Reply-To: <443001ec-b960-ce82-6e3a-da684afd193b@redhat.com> References: <70485d75-963b-1052-1461-05c8cbe1ea57@redhat.com> <77daa0af-e679-89a9-2859-dc28114b21a7@redhat.com> <59c708fe-7daa-403e-a381-ebe478b748f0@redhat.com> <443001ec-b960-ce82-6e3a-da684afd193b@redhat.com> Message-ID: Martin, ceph-installer needs to be installed manually as its outside the cluster. As ceph-installer is a service, its detected and so marked the node as `provisioner/ceph`. I dont think there is any plan to install ceph-installer from tendrl side. @rkanade/@mrugesh correct me if wrong here. Regards, Shubhendu On 06/22/2017 09:12 PM, Martin Bukatovic wrote: > On 06/22/2017 08:26 AM, Shubhendu Tripathi wrote: >> Also there is a PR https://github.com/Tendrl/commons/pull/622 in >> progress for import cluster flow, which checks if already there is a >> node with tag `provisioner/gluster` and installs gdeploy, python-gdeploy >> on that node only for further gluster operations. > This caught my attention: for ceph integration it works vice versa: > Tendrl detects that ceph-installer is up and running and based on > that, tags the machine as provisioner/ceph. Is this discrepancy in > approaches temporary or do we plan to install ceph-installer as well > keeping the detection feature as it works now? > From mbukatov at redhat.com Fri Jun 23 15:42:40 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 23 Jun 2017 17:42:40 +0200 Subject: [Tendrl-devel] provisioner gluster In-Reply-To: References: <70485d75-963b-1052-1461-05c8cbe1ea57@redhat.com> <77daa0af-e679-89a9-2859-dc28114b21a7@redhat.com> <59c708fe-7daa-403e-a381-ebe478b748f0@redhat.com> <443001ec-b960-ce82-6e3a-da684afd193b@redhat.com> Message-ID: <479ceefd-d56f-4c3e-e1a0-09af3b63d0e4@redhat.com> On 06/23/2017 05:57 AM, Shubhendu Tripathi wrote: > I dont think there is any plan to install ceph-installer from tendrl > side. @rkanade/@mrugesh correct me if wrong here. ok -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Fri Jun 23 16:03:56 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 23 Jun 2017 18:03:56 +0200 Subject: [Tendrl-devel] dedicated tendrl-monitoring (docs related) Message-ID: <58613065-18ac-0762-bde0-06d906ebbb2e@redhat.com> Dear all, I'm setting up dedicated Tendrl Monitoring deployment for qe enviroment and noticed place worth clarifying in installation reference[1]: > Configure performance monitoring > > Open /etc/tendrl/performance-monitoring/performance-monitoring.conf.yaml > update --> > > etcd_connection = > > time_series_db_server = > > api_server_addr = Two minor points: I guess that `api_server_addr = ` should read `api_server_addr = ` - which is the same as ip address of etcd server in this case - maybe we should either unify how we refer to the ip addresses or just point this fact out there wrt time_series_db_server value: this looks like a pointer to the carbon, right? could we add that (maybe just as a note into brackets) there? this wouldn't be that much overreach, as we discuss setting up and starting carbon-cache service just few steps away [1] https://github.com/Tendrl/documentation/wiki/Tendrl-Package-Installation-Reference -- Martin Bukatovic USM QE team Red Hat From mbukatov at redhat.com Fri Jun 23 18:15:01 2017 From: mbukatov at redhat.com (Martin Bukatovic) Date: Fri, 23 Jun 2017 20:15:01 +0200 Subject: [Tendrl-devel] tendrl logging Message-ID: <10c29726-95be-40bd-1512-45bfe00605cb@redhat.com> Hi all, looking into logging configuration of tendrl-node-agent, I think that writing down some explanation and reasoning behind these defaults would be useful. See /etc/tendrl/node-agent/node-agent_logging.yaml ``` handlers: console: class: logging.StreamHandler level: DEBUG stream: ext://sys.stdout info_file_handler: class: logging.handlers.SysLogHandler facility: local5 address: /dev/log level: INFO loggers: my_module: level: ERROR handlers: [console] propagate: no root: level: INFO handlers: [console, info_file_handler] ``` This looks like we log on INFO level into syslog, but with DEBUG level into stdout, which means that this would go into journald. Then we have a default for my_module and for root logger. It would be useful to connect the dots with the default behavior when I see little different type of messages in syslog file /var/log/tendrl/node-agent/node-agent.log compared to journald (journalctl -u tendrl-node-agent). I'm not questioning the decisions, but I think that documenting this with the admin who would run this in mind would be super useful for debugging and maintenance. -- Martin Bukatovic USM QE team Red Hat From sankarshan.mukhopadhyay at gmail.com Mon Jun 26 04:59:53 2017 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Mon, 26 Jun 2017 10:29:53 +0530 Subject: [Tendrl-devel] Fwd: Ideas on the UI/UX improvement of ceph-mgr: Cluster Status Dashboard In-Reply-To: References: Message-ID: As ceph-mgr continues to make progress, the "batteries included" nature of dashboard approaches such as these are always interesting. ---------- Forwarded message ---------- From: saumay agrawal Date: Mon, Jun 26, 2017 at 10:22 AM Subject: Ideas on the UI/UX improvement of ceph-mgr: Cluster Status Dashboard To: Ceph Development Hi everyone! I am working on the improvement of the web-based dashboard for Ceph. My intention is to add some UI elements to visualise some performance counters of a Ceph cluster. This gives a better overview to the users of the dashboard about how the Ceph cluster is performing and, if necessary, where they can make necessary optimisations to get even better performance from the cluster. Here is my suggestion on the two perf counters, commit latency and apply latency. They are visualised using line graphs. I have prepared UI mockups for the same. 1. OSD apply latency [https://drive.google.com/open?id=0ByXy5gIBzlhYNS1MbTJJRDhtSG8] 2. OSD commit latency [https://drive.google.com/open?id=0ByXy5gIBzlhYNElyVU00TGtHeVU] These mockups show the latency values (y-axis) against the instant of time (x-axis). The latency values for different OSDs are highlighted using different colours. The average latency value of all OSDs is shown specifically in red. This representation allows the dashboard user to compare the performances of an OSD with other OSDs, as well as with the average performance of the cluster. The line width in these graphs is specially kept less, so as to give a crisp and clear representation for more number of OSDs. However, this approach may clutter the graph and make it incomprehensible for a cluster having significantly higher number of OSDs. For such situations, we can retain only the average latency indications from both the graphs to make things more simple for the dashboard user. Also, higher latency values suggest bad performance. We can come up with some specific values for both the counters, above which we can say that the cluster is performing very bad. If the value of any of the OSDs exceeds this value, we can highlight entire graph in a light red shade to draw the attention of user towards it. I am planning to use AJAX based templates and plugins (like Flotcharts) for these graphs. This would allow real-time update of the graphs without having any need to reload the entire dashboard page. Another feature I propose to add is the representation of the version distribution of all the clients in a cluster. This can be categorised into distribution 1. on the basis of ceph version [https://drive.google.com/open?id=0ByXy5gIBzlhYYmw5cXF2bkdTWWM] and, 2. on the basis of kernel version [https://drive.google.com/open?id=0ByXy5gIBzlhYczFuRTBTRDcwcnc] I have used doughnut charts instead of regular pie charts, as they have some whitespace at their centre. This whitespace makes the chart appear less cluttered, while properly indicating the appropriate fraction of the total value. Also, we can later add some data to display at this centre space when we hover over a particular slice of the chart. The main purpose of this visualisation is to identify any number of clients left behind while updating the clients of the cluster. Suppose a cluster has 50 clients running ceph jewel. In the process of updating this cluster, 40 clients get updated to ceph luminous, while the other 10 clients remain behind on ceph jewel. This may occur due to some bug or any interruption in the update process. In such scenarios, the user can find which clients have not been updated and update them according to his needs. It may also give a clear picture for troubleshooting, during any package dependency issues due to the kernel. The clients are represented in both, absolutes numbers as well as the percentage of the entire cluster, for a better overview. An interesting approach could be highlighting the older version(s) specifically to grab the attention of the user. For example, a user running ceph jewel may not need to update as necessarily compared to the user running ceph hammer. As of now, I am looking for plugins in AdminLTE to implement these two elements in the dashboard. I would like to have feedbacks and suggestions on these two from the ceph community, on how can I make them more informative about the cluster. Also a request to the various ceph users and developers. It would be great if you could share the various metrics you are using as a performance indicator for your cluster, and how you are using them. Any metrics being used to identify the issues in a cluster can also be shared. -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- sankarshan mukhopadhyay From tendrl-jenkins-build-sys at dhcp42-16.lab.eng.blr.redhat.com Thu Jun 29 08:28:51 2017 From: tendrl-jenkins-build-sys at dhcp42-16.lab.eng.blr.redhat.com (Tendrl Jenkins Build System) Date: Thu, 29 Jun 2017 13:58:51 +0530 (IST) Subject: [Tendrl-devel] Downstream Gluster-integration Scratch Build built successfully! Message-ID: <20170629082851.7FC8E2038F2A@dhcp42-16.lab.eng.blr.redhat.com> result.stdout From root at dhcp42-16.lab.eng.blr.redhat.com Thu Jun 29 08:30:47 2017 From: root at dhcp42-16.lab.eng.blr.redhat.com (root at dhcp42-16.lab.eng.blr.redhat.com) Date: Thu, 29 Jun 2017 14:00:47 +0530 (IST) Subject: [Tendrl-devel] Downstream Scratch Build for Node-Agent report Message-ID: <20170629083047.6F7FA24B838F@dhcp42-16.lab.eng.blr.redhat.com> Tendrl-Node-Agent Downstream scratch built successfully. From root at dhcp42-16.lab.eng.blr.redhat.com Thu Jun 29 08:34:08 2017 From: root at dhcp42-16.lab.eng.blr.redhat.com (root at dhcp42-16.lab.eng.blr.redhat.com) Date: Thu, 29 Jun 2017 14:04:08 +0530 (IST) Subject: [Tendrl-devel] Downstream Scratch Build for Common report Message-ID: <20170629083408.89F112038EAA@dhcp42-16.lab.eng.blr.redhat.com> Tendrl-Commons Downstream scratch built successfully. From tendrl-jenkins-build-sys at dhcp42-16.lab.eng.blr.redhat.com Thu Jun 29 08:38:38 2017 From: tendrl-jenkins-build-sys at dhcp42-16.lab.eng.blr.redhat.com (Tendrl Jenkins Build System) Date: Thu, 29 Jun 2017 14:08:38 +0530 (IST) Subject: [Tendrl-devel] Downstream Gluster-integration Scratch Build built successfully! Message-ID: <20170629083838.1D6CF20F9C8F@dhcp42-16.lab.eng.blr.redhat.com> Building rhscon-gluster-integration-3.0-alpha.8.el7 for rhscon-3-rhel-7-candidate Created task: 13568879 Task info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=13568879 Watching tasks (this may be safely interrupted)... 13568879 build (rhscon-3-rhel-7-candidate, /rpms/rhscon-gluster-integration:cfd147df699f882257f150d0dbd0a0770d9cebbd): free 13568879 build (rhscon-3-rhel-7-candidate, /rpms/rhscon-gluster-integration:cfd147df699f882257f150d0dbd0a0770d9cebbd): free -> open (x86-030.build.eng.bos.redhat.com) 13568880 buildSRPMFromSCM (/rpms/rhscon-gluster-integration:cfd147df699f882257f150d0dbd0a0770d9cebbd): open (x86-030.build.eng.bos.redhat.com) 13568880 buildSRPMFromSCM (/rpms/rhscon-gluster-integration:cfd147df699f882257f150d0dbd0a0770d9cebbd): open (x86-030.build.eng.bos.redhat.com) -> closed 0 free 1 open 1 done 0 failed 13568908 buildArch (tendrl-gluster-integration-3.0-alpha.8.el7scon.src.rpm, noarch): free 13568908 buildArch (tendrl-gluster-integration-3.0-alpha.8.el7scon.src.rpm, noarch): free -> open (x86-019.build.eng.bos.redhat.com) 13568908 buildArch (tendrl-gluster-integration-3.0-alpha.8.el7scon.src.rpm, noarch): open (x86-019.build.eng.bos.redhat.com) -> closed 0 free 1 open 2 done 0 failed 13568879 build (rhscon-3-rhel-7-candidate, /rpms/rhscon-gluster-integration:cfd147df699f882257f150d0dbd0a0770d9cebbd): open (x86-030.build.eng.bos.redhat.com) -> closed 0 free 0 open 3 done 0 failed 13568879 build (rhscon-3-rhel-7-candidate, /rpms/rhscon-gluster-integration:cfd147df699f882257f150d0dbd0a0770d9cebbd) completed successfully From tjeyasin at redhat.com Thu Jun 29 08:49:21 2017 From: tjeyasin at redhat.com (Timothy Asir Jeyasingh) Date: Thu, 29 Jun 2017 04:49:21 -0400 (EDT) Subject: [Tendrl-devel] Downstream Gluster-integration Scratch Build built successfully! In-Reply-To: <20170629082851.7FC8E2038F2A@dhcp42-16.lab.eng.blr.redhat.com> References: <20170629082851.7FC8E2038F2A@dhcp42-16.lab.eng.blr.redhat.com> Message-ID: <217500643.12718570.1498726161784.JavaMail.zimbra@redhat.com> Hi All, I am automating downstream build. These are the emails sent by our tendrl jenkins on every patch merge to upstream. This will help us to quickly find any downstream build issues. Kindly ignore these emails. Regards, Tim ----- Original Message ----- > From: "Tendrl Jenkins Build System" > To: sds-mgmt-dev at redhat.com, tendrl-devel at redhat.com > Cc: "Timothy Asir" > Sent: Thursday, June 29, 2017 1:58:51 PM > Subject: Downstream Gluster-integration Scratch Build built successfully! > > result.stdout > > From tjeyasin at redhat.com Thu Jun 29 09:02:47 2017 From: tjeyasin at redhat.com (Timothy Asir Jeyasingh) Date: Thu, 29 Jun 2017 05:02:47 -0400 (EDT) Subject: [Tendrl-devel] Downstream Gluster-integration Scratch Build built successfully! In-Reply-To: <20170629083838.1D6CF20F9C8F@dhcp42-16.lab.eng.blr.redhat.com> References: <20170629083838.1D6CF20F9C8F@dhcp42-16.lab.eng.blr.redhat.com> Message-ID: <1497264186.12721531.1498726967889.JavaMail.zimbra@redhat.com> These are only scratch builds. We are not going to automatically trigger any final build. Once the scratch build is success and after serious verification we will manually trigger the final build. Regards, Tim ----- Original Message ----- > From: "Tendrl Jenkins Build System" > To: sds-mgmt-dev at redhat.com, tendrl-devel at redhat.com > Cc: "Timothy Asir" > Sent: Thursday, June 29, 2017 2:08:38 PM > Subject: Downstream Gluster-integration Scratch Build built successfully! > > Building rhscon-gluster-integration-3.0-alpha.8.el7 for > rhscon-3-rhel-7-candidate > Created task: 13568879 > Task info: > https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=13568879 > Watching tasks (this may be safely interrupted)... > 13568879 build (rhscon-3-rhel-7-candidate, > /rpms/rhscon-gluster-integration:cfd147df699f882257f150d0dbd0a0770d9cebbd): > free > 13568879 build (rhscon-3-rhel-7-candidate, > /rpms/rhscon-gluster-integration:cfd147df699f882257f150d0dbd0a0770d9cebbd): > free -> open (x86-030.build.eng.bos.redhat.com) > 13568880 buildSRPMFromSCM > (/rpms/rhscon-gluster-integration:cfd147df699f882257f150d0dbd0a0770d9cebbd): > open (x86-030.build.eng.bos.redhat.com) > 13568880 buildSRPMFromSCM > (/rpms/rhscon-gluster-integration:cfd147df699f882257f150d0dbd0a0770d9cebbd): > open (x86-030.build.eng.bos.redhat.com) -> closed > 0 free 1 open 1 done 0 failed > 13568908 buildArch (tendrl-gluster-integration-3.0-alpha.8.el7scon.src.rpm, > noarch): free > 13568908 buildArch (tendrl-gluster-integration-3.0-alpha.8.el7scon.src.rpm, > noarch): free -> open (x86-019.build.eng.bos.redhat.com) > 13568908 buildArch (tendrl-gluster-integration-3.0-alpha.8.el7scon.src.rpm, > noarch): open (x86-019.build.eng.bos.redhat.com) -> closed > 0 free 1 open 2 done 0 failed > 13568879 build (rhscon-3-rhel-7-candidate, > /rpms/rhscon-gluster-integration:cfd147df699f882257f150d0dbd0a0770d9cebbd): > open (x86-030.build.eng.bos.redhat.com) -> closed > 0 free 0 open 3 done 0 failed > > 13568879 build (rhscon-3-rhel-7-candidate, > /rpms/rhscon-gluster-integration:cfd147df699f882257f150d0dbd0a0770d9cebbd) > completed successfully > > From dahorak at redhat.com Fri Jun 30 13:56:01 2017 From: dahorak at redhat.com (=?UTF-8?Q?Daniel_Hor=c3=a1k?=) Date: Fri, 30 Jun 2017 15:56:01 +0200 Subject: [Tendrl-devel] CentOS CI status summary In-Reply-To: <6e996c3d-24b5-db76-5dbb-82a53b58b81e@redhat.com> References: <6e996c3d-24b5-db76-5dbb-82a53b58b81e@redhat.com> Message-ID: <54ed0843-eca2-c017-cdc8-676bdab00366@redhat.com> Another short update: * Building packages in CentOS CI[1] is "blocked" by [2,3,4]. (Once those issues will be resolved in the particular repository/branch, all the jobs should be passing - but without configuration change it will be still pushing the packages to my testing copr repository. I don't want to change it to the official Tendrl Copr repository, before everything will be properly working). * Main API tests for Ceph and Gluster[5] are failing mainly because of required changes in the test structure (not fully ready yet). I'll be on PTO next week, so there will be probably no change during the following days. [1] https://ci.centos.org/view/tendrl-build/ [2] https://github.com/Tendrl/api/issues/202 [3] https://github.com/Tendrl/api/issues/209 [4] https://github.com/Tendrl/dashboard/issues/442 [5] https://ci.centos.org/view/Tendrl/ On 06/20/17 15:29, Daniel Hor?k wrote: > Just short update: > * I've updated the package validation tests configuration, so now it is > consuming packages from copr tendrl/release repository (and it is passing). > > * Also there seems to be fixed one issue in Tendrl API, so "others" > tests are passing too. > > Regards, > Daniel > > On 06/19/17 15:47, Daniel Hor?k wrote: >> Hi all, >> >> let me summarize the current state of CentOS CI related things. >> >> **Building Tendrl packages in CentOS CI (more precisely triggering the >> builds in Copr)** >> - jobs for building all Tendrl packages from develop and latest >> release branch are ready[1,2]. >> - The packages are now build in my testing Copr repository[3], but it >> is only about small configuration change to move it to official Tendrl >> Copr repo (I don't want to move it there before I'll be sure >> everything works as expected). >> - There are few issues[4] related to the building process (mainly >> missing targets in Makefile) which needs to be fixed to be able to >> build all the Tendrl packages without further workarounds. >> >> >> **Test executed in CentOS CI** >> The "Tendrl CI Dashboard"[5] now contains status of 10 jobs: >> - Jobs 1 - 4: Package validation (with issues in rpmlint and rpmdeplint) >> - Jobs 5 - 7 are divided to Ceph and Gluster and they are supposed to >> install particular cluster (job 5) and run Ceph/Gluster specific tests >> (job6) and other - common - tests (job7). >> >> - Cluster installation (Jobs 5) commonly works (it uses packages from >> release repo). >> - Ceph/Gluster specific tests are failing (I'll have to check if it is >> expected/known issue or if it is problem with the infrastructure or >> tests itself). >> - Other (common) tests are passing with one known/expected failure[6] >> (so that's the reason for yellow color instead of green). >> >> I'll continue on the improvement of the CI workflow, check the >> failures and prospectively send another update or create related issues. >> >> >> [1] https://ci.centos.org/view/tendrl-build/ >> [2] https://github.com/Tendrl/usmqe-centos-ci/pull/1 >> [3] https://copr.fedorainfracloud.org/coprs/dahorak/tendrl-test/builds/ >> [4] https://github.com/Tendrl/api/issues/202 >> https://github.com/Tendrl/api/issues/209 >> https://github.com/Tendrl/dashboard/issues/442 >> [5] https://ci.centos.org/view/Tendrl/ >> [6] https://bugzilla.redhat.com/show_bug.cgi?id=1457220 >> https://github.com/Tendrl/api/issues/140 >> >> Regards, >> Daniel >> >> _______________________________________________ >> Tendrl-devel mailing list >> Tendrl-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/tendrl-devel > > _______________________________________________ > Tendrl-devel mailing list > Tendrl-devel at redhat.com > https://www.redhat.com/mailman/listinfo/tendrl-devel