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