17:59:57 #startmeeting trove 17:59:57 Meeting started Wed Jul 1 17:59:57 2015 UTC and is due to finish in 60 minutes. The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:59 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:02 The meeting name has been set to 'trove' 18:00:07 what up yall 18:00:21 hello everyone 18:00:32 hi hi o/ 18:00:35 hey Trove team! 18:00:54 o/ 18:01:04 Agenda for today's meeting is at: 18:01:07 #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting 18:01:26 Hey all 18:01:36 heyo 18:01:50 o/ 18:01:52 o/ 18:02:30 Alright, let's get started. 18:02:37 #topic Trove pulse update 18:02:45 #link https://etherpad.openstack.org/p/trove-pulse-update 18:03:42 looks like this past week we did quite a few more reviews 18:04:08 yup ~182 overall reviews — thanks to everyone for putting in the time to do reviews. 18:04:20 not as many merged 18:04:27 right - that's what i noticed 18:04:31 o/ 18:04:34 the queue seems to be lengthening 18:04:41 yeah 18:04:53 almost 2 per day 18:04:59 queue growth 18:05:03 There were 3 some that merged late last night after I pulled the numbers. 18:05:45 But yes, overall we do have fewer merges this week. 18:06:26 on the other hand it looks like there are less waiting on reviewer tho 18:06:27 (which in and of itself might not be a problem for one given week). 18:06:42 But something to watch out for as a trend. 18:07:06 i'd expect this coming week to possibly be less being a holiday weekend for the states 18:07:26 cp16net it's a holiday today in Canada 18:07:35 which is why most of the Tesora gang isn't here 18:07:36 say what? 18:07:39 you workin? 18:07:41 :-P 18:07:44 ahh... 18:07:51 dougshelley66: ah that explains the attendance :) 18:08:34 Let's keep an eye out for that merge rate over the next few weeks. 18:08:49 Any other questions/comments? 18:09:13 Let's move on, quite a bit to cover for today's meeting. 18:09:16 looks like good progress great work 18:09:33 cp16net: ++ 18:09:40 +1 18:09:41 keep those reviews flowing 18:09:42 cp16net++ :) 18:09:59 #topic Liberty Mid-cycle sprint 18:10:21 So I've added a lot more details for the Trove Liberty Mid cycle sprint at: 18:10:29 #link https://wiki.openstack.org/wiki/Sprints/TroveLibertySprint 18:10:38 schedule looks older one :P 18:10:49 i'm having this deja vu on the agenda :) 18:11:08 lol 18:11:21 dougshelley66: I'm still working on the agenda :) 18:11:58 Actually, I have an updated one — I missed updating the wiki page. 18:11:58 SlickNik np - it actually took me a while to realize that :) 18:12:14 lol i just realized its linked to the kilo stuff ;-P 18:13:31 refresh that page, and you should have a tentative agenda for the Liberty (not Kilo) sprint linked to the new etherpad pages. 18:13:54 awesome 18:14:02 sweet 18:14:16 so quick :D 18:14:44 sushilkm: I'm quick like that :) 18:14:59 thank god breakfast still made it in there 18:14:59 (y) 18:15:14 make sure to register :) 18:15:27 or no food for you ... :-D 18:15:30 We still have a couple of slots open — so if there's a topic that you'd like to cover, let me know and we can get it on the schedule. 18:15:42 Oh, yeah thanks for the reminder cp16net 18:15:53 There's a link to the evite page on the wiki as well. 18:16:00 For folks to register. 18:16:37 So I can get a headcount, and more importantly dietary restrictions and tshirt sizes 18:16:53 #link https://www.eventbrite.com/e/trove-mid-cycle-sprint-liberty-tickets-17600134476 18:16:58 is there a design for the shirts? 18:17:10 cp16net: Not as yet 18:17:27 If you have ideas for the design, please send them to me! 18:18:18 #info Folks who will be attending the Trove Liberty mid-cycle sprint please register at https://www.eventbrite.com/e/trove-mid-cycle-sprint-liberty-tickets-17600134476 18:19:02 also anyone coming out for mid-cycle is invited to Trove Day - it is the day before 18:19:04 http://www.tesora.com/troveday/2015-openstack-trove-day/ 18:19:19 I believe there is free drinks... 18:19:24 ah yes, thanks for the reminder dougshelley66! 18:20:05 thats gud one "The trove day" 18:20:47 Doug, do you want everyone to sign-up for Trove Day on that EventBrite site as well? 18:20:59 yes - i believe so 18:21:32 link https://www.eventbrite.com/e/trove-day-2015-tickets-16502193505 18:21:44 Thanks ashleighfarnham! 18:21:52 #link https://www.eventbrite.com/e/trove-day-2015-tickets-16502193505 18:22:27 ashleighfarnham: works better with a # (The meeting bot will know what to do when it generates meeting minutes for us in that way) 18:23:12 any other questions / comments related to the mid-cycle or trove-day? 18:23:20 . 18:23:29 #topic Lightweight monitoring framework 18:23:44 vkmc: around? 18:23:48 here :) 18:23:50 thanks SlickNik 18:24:10 so, during the design session we discussed about adding a monitoring framework 18:24:31 and I said I wanted to work on that 18:24:45 I have been a little slow on get some implementation options and such 18:24:54 but I did that in this etherpad 18:25:02 #link https://etherpad.openstack.org/p/trove-monitoring 18:26:00 amrith worked on the spec, so I assumed maybe Tesora folks have some feedback on the ways we can implement that 18:26:22 so we can have a useful feature without adding too much complexity 18:26:29 Thanks for compiling that info about the monitoring options, and pros and cons of each approach. 18:26:51 * SlickNik is reading through the etherpad page. 18:26:54 and of course, apart from Tesora folks, our community feedback and thoughts :) 18:27:30 maybe we can discuss more about this in the channel, after you have some time to check the etherpad, but I wanted to bring it up now so everybody is aware of that feature 18:28:12 vkmc, we are definitely interested in this 18:28:24 dougshelley66, awesome! 18:28:32 vkmc but as i mentioned earlier most of the crew is off - i don't see amrith here atm 18:28:40 this wud surely help managing the guest instances 18:28:42 yeah 18:28:44 So I think maybe something like what you propose in your third bullet point (Monitoring strategies) works well with what is being proposed in https://review.openstack.org/#/c/186040 (monitoring framework). 18:29:05 i think this is an important feature thanks for pulling the info together 18:29:45 dougshelley66 / vkmc: Yes, perhaps we can have a bit more of a detailed discussion when other folks are around as well. 18:29:48 SlickNik, yeah I think that too... I think its the sanest approach 18:29:51 +1 to Slicks point. It's going to be a problem if we pick a particular monitoring solution and hard code to that 18:30:15 but still, I got some feedback from operators, and they use monitoring solutions like Nagios/Zabbix/Cacti 18:31:04 I think we have to make it possible to plug in something like Nagios but supporting only Nagios seems heavy handed. Especially considering Monasca is the "OpenStack" monitoring solution 18:31:21 yeah i know of people using other monitoring solutions like in house solutions 18:31:25 yeah, agree shayneburgess_++ 18:31:44 vkmc: Yes, but I think if we go with the third approach, there's nothing preventing someone from extending the guest with a ZabbixMySQL strategy, for example. 18:31:54 Percona provides a set of plugins that would allow us to write strategies for monitoring 18:32:02 with Nagios/Zabbix/Cacti 18:32:11 at least for mysql 18:32:19 SlickNik, true that 18:32:46 I think whatever we come up with, we should maybe include a section at the end of the design that explains how you would plug both Nagios and Monasca into it 18:33:09 then we can feel reasonably confident we have a solution that solves the problem for the majority of operators 18:33:26 sounds good 18:33:44 Okay, vkmc do you want to take point and drive this design discussion with amrith, me and other interested folks? 18:33:50 Ashleigh might be able to help there. She has been looking at Monasca a lot lately 18:33:55 SlickNik, sure thing 18:34:03 and vgnbkr 18:34:03 oh that would be awesome shayneburgess_ 18:34:16 great! :) 18:34:19 ++ to input from ashleighfarnham on monasca. 18:35:14 will do 18:35:37 cool, we can sync up tomorrow in #openstack-trove 18:35:38 #action vkmc to take point on having further conversations with interested parties on the design of how to proceed with the trove monitoring framework 18:35:59 vkmc: Sounds like a good plan 18:36:02 Thanks! 18:36:05 thanks! 18:36:28 #topic Trove-compatible images creation automation 18:36:38 that's me again 18:37:04 I know that you probably have heard about this several times 18:37:22 we always have people in #openstack-trove having problems with the images they manually create 18:37:44 and we redirect them to use trove-integration script to create their images 18:38:05 while this is a good solution, I noticed two things 18:38:16 - its packed in a bigger script 18:38:33 so users need to get a lots of bits that they don't need to build their images 18:38:55 - the images that they can create with that script are for testing purposes only 18:39:16 - there are elements for ubuntu and fedora only 18:39:27 (that makes... three things hehe) 18:39:42 so, I was wondering if it would make sense to take an approach similar to Sahara 18:39:54 and create a trove-image-elements script 18:40:05 s/script/project 18:40:27 vkmc, +1 (says the guy from red hat) 18:41:10 what are your thoughts about this? 18:41:42 Just thinking about this. 18:41:56 are you proposing to move the trove-image-elements into a separate repo similar to sahara ? 18:42:01 would be nice to have a common location for DIB elements too outside of redstack 18:42:04 no need to rush though 18:42:18 Moving it out to a separate project would help 1., but doesn't address 2. and 3. though. 18:42:20 my first thought is will this cause problems trying to test them with a separate project? 18:42:30 i think it probably would 18:42:51 but i dont think thats a strong reason to keep them together 18:42:51 2. can be addressed as part of the process (cleaning them up) 18:42:53 there are also elements already in tripleo-image-elements 18:43:18 SlickNik, 2. can be addressed if we create the proper elements and 3. will come with contributors creating their elements for their distros 18:43:18 there is one more problem related to image-creation, that trove-integration is not branched based, so many number of times it makes problematic to create image for older releases 18:43:19 i don't think have another repo for trove ones makes sense - it will complicate testing and reviews more 18:43:20 3. having them in a central place would help merging back the elements which vkmc worked on for Fedora, CentOS and RHEL 18:44:08 sushilkm: having a properly branches trove-image-generation or trove-image-elements project would help, as people could rely on a specific branch 18:44:17 the main hurdle I see with trying to address 2. is that in order to build a production-like image, we'd have to know how exactly is Trove deployed in their production environment. 18:44:19 abramley: it didn't complicate testing for sahara at all 18:44:51 SlickNik, but people would customize the elements accorcdingly 18:45:00 IMO trove-integration as is makes sense for development environments 18:45:03 SlickNik: but detaching from the big integration script would help define which are the specific parts needed by testing (define clear interfaces) 18:45:23 but right now we don't have anything, apart from documentation, that helps our uses to create their images 18:45:37 and having a well-built image is an important part of having Trove working 18:45:47 well, and even documentation could get some extra love... 18:45:53 s/uses/users 18:46:14 tosky: ++ on better docs 18:46:20 tosky ++ 18:47:15 cp16net: I don't think that we'll run into many issues in trove-integration if we separate the image-elements out - using the ELEMENTS_PATH for diskimage-builder works fairly well. 18:47:31 ok 18:47:45 SlickNik, +1 18:48:05 I have worked on a script, similar (very very small in comparison) to the sahara-image-elements 18:48:08 it sounds like there are more benifits if we did move them to its owe repo 18:48:20 that uses the ELEMENT_PATH for diskimage-builder 18:48:36 and its working as expected 18:48:39 Yeah, I'm not averse to this idea — I do think it will simplify life for folks who are _just_ trying to build images. 18:48:48 in fact, redstack could invoke the separate project for "kick-start mysql" 18:48:55 e.g. 18:49:08 yeah i think the bigger issue is docs to create a good image 18:50:14 we can discuss about this further in the upcoming days, and if the community agrees, create an stackforge project 18:50:22 vkmc: Okay, let's do this. Can we simultaneously get a project up and running with the trove-image-elements and build script. 18:50:48 i like the idea of automation for baseline images, then docs etc. for production considerations 18:51:25 Once that project is able to build images successfully we can look at pulling out the functionality from trove-integration and replacing it with images from this new project. 18:51:38 SlickNik, sounds good! 18:51:51 (it sounds like you've already started looking into some of this) 18:52:05 I did yes 18:52:23 :) 18:52:32 sounds good 18:52:54 Okay — sounds like we have a plan. Thanks! 18:52:59 cool! 18:53:01 thanks 18:53:14 We've still got another item to cover on the agenda, so let's keep going. 18:53:28 #topic MariaDB guestagent implementation 18:53:35 ... and that's me again 18:54:03 vkmc i presume this would be dependent on the spec that atomic was working on 18:54:11 yes, exactly 18:54:30 I dunno what is the status on that 18:54:40 but certainly this will depend on atomic's refactor 18:54:52 https://review.openstack.org/#/c/168083/ 18:54:57 So if I understand correctly, once atomic is done with the refactoring this is the work item to ensure that MariaDB works on top of that? 18:54:57 the spec has merged 18:54:58 thanks 18:55:05 yeah! 18:55:09 he is starting to work on that 18:55:34 I have been testing how well MariaDB behaves with the MySQL guestagent implementation 18:55:53 and unfortunately, while they are similar, the results weren't very good 18:56:10 dougshelley66, will that sub-divide the mysql family and refactor common code? 18:56:23 pmackinn yes i believe so 18:56:24 and that is a problem because both RHEL and SUSE distributions use MariaDB as their default MySQL implementation 18:56:26 pmackinn: That's the idea 18:56:36 vkmc: Yes, this sounds really good to me. 18:56:40 we have done some work to get maria 5.5 and 10 working on ubuntu/centos and rhel 18:56:58 but those changes are really mergeable because the right way to fix maria is that mysql guest refactor 18:57:10 ack 18:57:14 vkmc: I'm really curious to know what results you found, and what the differences were. 18:57:25 i am as well 18:57:29 sure thing 18:57:38 I should write them down 18:57:45 might be os differences 18:57:45 but making it briefly 18:57:53 most trivial operations work as expected 18:58:01 mariadb 5.5 doesn't fully support repl v2 18:58:02 CRUD for users and databases I mean 18:58:17 pmackinn it can't 18:58:20 i recall using the mysql agent to work with mariadb on debain 18:58:21 that was in the spec 18:58:28 but might have made some minor changes 18:58:31 i dont recall 18:58:31 but in mariadb10, the GTID implementation is completely different to the mysql 5.6 implementation 18:58:38 vkmc that is correct 18:58:47 and it hasn't been implremented yet 18:59:01 yeah, in mariadb 5.5 we have binlog replication and, with some extra configurations, it works as expected 18:59:04 oh so replication stuffs 18:59:09 vkmc: Yes — that would have to be solved using a new MariaGTIDReplication strategy, I believe. 18:59:16 SlickNik, indeed 18:59:22 SlickNik, vkmc, 18:59:34 but that strategy can't be implemented until the manager is refactored 18:59:41 dougshelley66, agree 18:59:48 i can't remember the exact reason why, but i recall vgnbkr talking about it 18:59:49 vkmc / dougshelley66: yup, with you on that. 19:00:11 dougshelley66, I'll follow up with atomic tomorrow, he probably can give me some details on that 19:00:40 vkmc, certianly - i'm sure i will be talking to him as well :) 19:00:55 and, if we can get that refactor and the community is ok on getting a MariaDB strategy for Liberty, I'm willing to work on that 19:01:09 (that's reason why I submitted the topic in this meeting :) 19:01:22 vkmc, sounds like you are going to be busy :) 19:01:28 yes :o 19:01:51 certainly 19:02:37 vkmc: Sounds good to me. 19:02:49 cool! 19:02:52 I'm glad to see that we're working to get a better MariaDB story given that it's now the default on RedHat and SUSE. :) 19:03:14 yeah :D 19:03:27 Okay and with that, we're officially over time. 19:03:41 If you have open items for discussion, let's take it to #openstack-trove. 19:03:46 #endmeeting