15:00:18 <EmilienM> #startmeeting puppet-openstack
15:00:18 <openstack> Meeting started Tue Sep  1 15:00:18 2015 UTC and is due to finish in 60 minutes.  The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:21 <openstack> The meeting name has been set to 'puppet_openstack'
15:00:28 <EmilienM> #link agenda: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150901
15:00:31 <EmilienM> o/
15:00:35 <mwhahaha> hi
15:00:36 <aderyugin> o/
15:00:38 <clayton> here
15:00:42 <xarses> hi
15:00:45 <partner> hi
15:00:47 <guimaluf> hi
15:00:49 <skolekonov> hi
15:00:55 <angdraug_> \o
15:00:57 <iurygregory> hello
15:00:58 <degorenko> o/
15:00:58 <iurygregory> =D
15:00:58 <Hunner> mwhahaha: I always think someone is laughing in the channel when I read your name :P
15:01:09 <mfisch> hola
15:01:33 <ativelkov> o/
15:01:41 <clayton> Hunner: same
15:01:48 <bogdando> hi
15:02:02 <EmilienM> #topic Review past action items
15:02:10 <EmilienM> clayton to prepare an etherpad about  external install & svc management patches in puppet-* for midcycle
15:02:22 <clayton> working on it right now :)
15:02:27 <EmilienM> clayton: I don't see the etherpad on https://etherpad.openstack.org/p/puppet-liberty-mid-cycle
15:02:31 <EmilienM> ok, we have an agenda topic anyway
15:02:46 <EmilienM> richm to start a new etherpad for midcycle about keystone v3 work that we could achieve in 3 days
15:02:53 <sgolovatiuk> \o
15:03:05 <mattymo_> hey
15:03:06 <EmilienM> richm: same, could we do an etherpad?
15:03:35 <_ody> o/
15:04:02 <EmilienM> EmilienM to sends an email to ttx about Summit rooms (2 hours of Fishbowl slots) and Workroom slots for dev sessions
15:04:11 <richm> EmilienM: do we need an entire separate etherpad for the v3 midcycle work?
15:04:14 <EmilienM> -> done - I haven't got news though, I guess we need to wait
15:04:27 <EmilienM> richm: if you think we need to, yes. Otherwise no
15:04:49 <richm> EmilienM: I added the work that needs to be done to the midcycle etherpad
15:04:51 <mfisch> hola
15:04:52 <EmilienM> richm: just make sure you know what we can do in 3 days of work, and the participants
15:04:56 <EmilienM> richm: good
15:05:01 <richm> EmilienM: ack
15:05:08 <EmilienM> and richm to inform ML about Keystone v3 resource naming for domain scoped resources Liberty and M behaviors
15:05:10 <EmilienM> -> done
15:05:23 <EmilienM> so let's continue the agenda
15:05:34 <EmilienM> #topic midcycle
15:05:45 <EmilienM> #link midcycle etherpad: https://etherpad.openstack.org/p/puppet-liberty-mid-cycle
15:06:02 <EmilienM> pabelanger: please look https://etherpad.openstack.org/p/puppet-openstack-CI
15:06:15 <EmilienM> I put two topics in high priority and two in low priority
15:06:21 <EmilienM> let me know if it makes sense to you
15:06:36 <EmilienM> since we are only 2 working on this right now...
15:06:52 <mfisch> EmilienM: what about ubuntu issues I was wondering if we could have a better pipeline to send them bugs and fixes?
15:06:57 <mfisch> LP issues seem to be ignored/missed
15:07:15 <EmilienM> well, heat/ironic/glance are now non voting for beaker/trusty jobs
15:07:35 <mfisch> we can expect the same issues in M
15:07:37 <EmilienM> I don't know what we can do more than reporting them on LP & IRC
15:07:40 <EmilienM> maybe a bird
15:08:04 <EmilienM> stable packages are usually fine
15:08:08 <mfisch> if the packaging code was in git I can send fixes ;)
15:08:24 <EmilienM> mfisch: it's a bit out of the topic right now
15:09:16 <EmilienM> so to summarize we have 6 topics for the midcycle
15:09:35 <EmilienM> Paul and I will lead CI work -> https://etherpad.openstack.org/p/puppet-openstack-CI
15:09:53 <EmilienM> clayton will lead docker/pip/venv integration https://etherpad.openstack.org/p/puppet-liberty-mid-cycle-install-and-svc-hooks
15:10:10 <EmilienM> richm will lead keystone v3 work (see etherpad)
15:10:24 <EmilienM> mfisch will lead bug triage, I would love someone from mirantis with him
15:10:38 <mfisch> yes and the bug list is posted and additions are welcome
15:10:40 <EmilienM> ie, someone from Fuel team
15:10:44 <mwhahaha> i can help
15:10:46 <mfisch> It looks like a good list for now
15:10:53 <EmilienM> #link bug triage https://etherpad.openstack.org/p/puppet-openstack-bugtriage
15:10:56 <EmilienM> mwhahaha: thx
15:11:10 <EmilienM> mwhahaha: I added your name in leader names
15:11:17 <mwhahaha> k
15:11:26 <EmilienM> and the last topic (we have 5 not 6...) is
15:11:32 <EmilienM> Module documentation and forge/puppetlabs approval status
15:11:39 <EmilienM> lead by _ody and Hunner
15:11:50 <Hunner> Yup
15:12:12 <EmilienM> so if anyone is interested to participate, please connect on #openstack-sprint tomorrow and start talking to the leaders who will distribute the work
15:12:23 <EmilienM> we will have a daily (short) meeting to see if there are blockers
15:12:39 <EmilienM> ^ if needed only
15:13:00 <EmilienM> the timing is regular work day, so depending where you are in the world
15:13:40 <EmilienM> we will have support from -infra team (anteaya will be around) so they are willing to help quicker than usual
15:14:01 <EmilienM> anything else we might need to discuss about midcycle? any questions?
15:14:52 <mfisch> when is the daily meeting?
15:14:57 <EmilienM> this is our first sprint, so I guess it will be very interesting to learn from how it happens :)
15:14:57 <mfisch> same time?
15:15:10 <EmilienM> mfisch: no idea, probably yes, to allow everyone to join
15:15:12 <bogdando> EmilienM, is it liberty bugs triage?
15:15:24 <EmilienM> bogdando: this is all bugs triage
15:15:38 <mfisch> bogdando: liberty or even kilo, I made a list of bugs that are important and need some looking into
15:15:42 <EmilienM> but I guess liberty and kilo bugs are highest priorities
15:15:51 <EmilienM> mfisch++
15:16:14 <EmilienM> cool, so I guess we can go ahead
15:16:15 <EmilienM> #topic Support for atomic classes orchestration actions
15:16:22 <EmilienM> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/073268.html
15:16:23 <EmilienM> bogdando: o/
15:17:04 <EmilienM> reading your email, this is very interesting
15:17:11 <bogdando> please read this thread and look for bp https://blueprints.launchpad.net/puppet-neutron/+spec/atomic-classes-orchestration
15:17:28 <clayton> I was looking over bogdando's reviews for this earlier, I think there is a lot of overlap between what is needed to support this, and what is needed for the external install/svc management.
15:17:31 <bogdando> yes, this is orchestration-agnostic feature
15:17:31 <EmilienM> but hard to implement without breaking our current interface maybe
15:18:01 <EmilienM> clayton, bogdando: so you guys might need to talk each others
15:18:04 <clayton> bogdando: This is an example of what I'm talking about - https://review.openstack.org/#/c/216926/
15:18:08 <bogdando> at least it is possible to decrease external references as much as possible
15:18:23 <clayton> I think we could probably integrate what you're trying to achieve with the same approach
15:18:36 <bogdando> clayton, EmilienM yes, this looks imilar
15:18:43 <bogdando> s/similar
15:19:02 <bogdando> clayton, would be nice
15:19:11 <EmilienM> bogdando: I would suggest you to spend a little of time with clayton during the midcycle and try to sort this out, at least by a follow-up of your proposal
15:19:16 <clayton> you want to make the classes more composable and less tangled, and my stuff for the external install/svc management does that partially kind of as a side-effect
15:19:54 <bogdando> yes, that works
15:19:59 <bogdando> let's do it
15:20:00 <clayton> sounds good :)
15:20:13 <EmilienM> cool
15:20:37 <EmilienM> bogdando: though, can you follow-up your thread on the ML? it would be interested
15:20:41 <EmilienM> interesting*
15:21:17 <EmilienM> anything else about this topic?
15:21:18 <bogdando> yes, sure and could clayton  do this as well?
15:21:51 <bogdando> adding more details for related patches would be nice
15:22:34 <EmilienM> bogdando: sounds good, ok clayton ^^ ?
15:22:39 <clayton> yeap
15:22:44 <EmilienM> cool
15:22:46 <EmilienM> #topic Deprecate RabbitMQ class implementation for nova
15:22:57 <EmilienM> bogdando, aderyugin o/
15:23:03 <bogdando> there is a nova::rabbitmq
15:23:08 <EmilienM> we should drop it
15:23:23 <EmilienM> I remember back in time, we talked about this with you maybe bogdando
15:23:24 <bogdando> and this patch https://review.openstack.org/#/c/216926/ seems just folowing the same pattern
15:23:36 <bogdando> yes, we did
15:23:53 <EmilienM> I remember, we asked for deprecation
15:24:13 <bogdando> so, I will submit a deprecation patch. But we should think on a format
15:24:48 <EmilienM> bogdando: you should change all modules that have it, to send a warning if the class is declared
15:24:55 <EmilienM> and in M-, we will drop the code
15:25:02 <bogdando> ok
15:25:07 <EmilienM> anyone against that ? ^
15:25:16 <EmilienM> bogdando: please follow-up on ML
15:25:24 <aderyugin> EmilienM, bogdando: murano requires 2 instances of RabbitMQ, and puppetlabs-rabbitmq module doesn't support multiple instances
15:25:26 <EmilienM> so all puppet group can ack that
15:25:30 <bogdando> idea is what we should either deprecate nova::rabbitmq or allow clones like https://review.openstack.org/#/c/216926/
15:25:37 <EmilienM> aderyugin: two? wow
15:25:46 <iurygregory> omg o.o
15:25:55 <clayton> why does it require two?  it can't use vhosts?
15:26:03 <EmilienM> yeah?
15:26:19 <bogdando> aderyugin, yes, idea is to delegate configuring any instances to composition layer, IIUC
15:26:20 <aderyugin> one for communacation with openstack services, and another one for communication with agents installed on VMs
15:26:31 <EmilienM> bogdando:  please send an email about deprecating nova::rabbitmq in L and drop the code in M
15:26:42 <bogdando> EmilienM, will do
15:26:45 <EmilienM> puppet-* should not manage rabbitmq server
15:26:59 <EmilienM> and for resources it could be managed by puppet-openstacklib, like it's done for mysql
15:27:37 <EmilienM> #action bogdando ask on ML for nova::rabbitmq deprecation
15:28:03 <EmilienM> aderyugin: and for that, you can do vhosts I guess
15:29:33 <EmilienM> bogdando: though we could provide an interface to manage rabbitmq resources, but I'm not sure
15:29:47 <EmilienM> people should manage their rabbitmq resources in their composition layer imh
15:29:49 <EmilienM> imho*
15:29:59 <bogdando> sounds reasonable
15:30:12 <EmilienM> anything else for this topic?
15:30:22 <bogdando> not from my side
15:30:26 <EmilienM> ok
15:30:31 * _ody does already
15:30:39 <_ody> didn't even know those classes existed
15:30:57 <EmilienM> I'll just add a last minute topic which is some latest infos
15:31:01 <EmilienM> #topic ci status
15:31:14 <EmilienM> so I disabled voting on beaker/trusty jobs for heat/ironic and glance
15:31:35 <EmilienM> but this morning I also found two issues on centos7 for ceilometer and neutron
15:31:42 <EmilienM> https://bugs.launchpad.net/puppet-neutron/+bug/1490990 and https://bugs.launchpad.net/puppet-ceilometer/+bug/1490986
15:31:44 <openstack> Launchpad bug 1490990 in puppet-neutron "acceptance: neutron fails to start server service" [Undecided,New] - Assigned to Emilien Macchi (emilienm)
15:31:45 <openstack> Launchpad bug 1490986 in puppet-ceilometer "centos: puppet run is not idempotent (collector & notif agents)" [Undecided,New] - Assigned to Emilien Macchi (emilienm)
15:32:03 <EmilienM> it's useless to do recheck until bug are fixed
15:32:20 <EmilienM> that's it about ci status
15:32:43 <EmilienM> #topic Open Discussion, Bug and Review triage
15:33:03 <EmilienM> if you have any outstanding patch or bug, please go ahead now
15:33:07 <guimaluf> IIUC
15:33:08 <guimaluf> hey, I would like to talk about https://review.openstack.org/#/c/205243
15:33:27 <guimaluf> this review intents to fix a bug, the way things are the use of swift_*_config depends in which order  resource and template are applied.
15:33:55 <guimaluf> so I did not get the thing about backwards compatibility. what should be done? just wait? confirm the bug?
15:34:08 <EmilienM> so let me explain my -1
15:34:34 <EmilienM> since you are changing orchestration, if someone will run puppet with your change, I'm wondering if his configuration will change, since you change ordering
15:34:51 <EmilienM> in that case, it will break deployer's configuration
15:36:03 <guimaluf> EmilienM, but this is the exactly problem.
15:36:17 <guimaluf> the way things are done, this configuration just doesnt work...
15:36:43 <guimaluf> so I don't know if someone is using this. And I don't know if this applies only to swift
15:37:15 <EmilienM> only to swift, yes because it's the only one module that use concat
15:37:52 <EmilienM> mgagne: have you seen that ^ ?
15:38:38 <clayton> It seems like a bug that this dependency isn't already there.
15:38:49 <mgagne> EmilienM: no, this is work I have not touched in a long time
15:39:14 <guimaluf> so maybe swift should be move out from concat module
15:39:17 <EmilienM> mgagne: if you could just see https://review.openstack.org/#/c/205243
15:39:26 <mgagne> I'm reading atm
15:39:32 <EmilienM> guimaluf: this is a topic we're talking for... wow I can't remember ;)
15:40:04 <mgagne> close to 2 years?
15:40:08 <mgagne> https://github.com/mgagne/puppet-swift/tree/bp/swift-proxy-config-ini-settings
15:40:34 <EmilienM> that would have been a nice work for the midcycle
15:40:39 <EmilienM> but iirc, mgagne can't make it, right?
15:41:08 <mgagne> there is nothing in progress to make it happen. my boss just came back today
15:41:09 <_ody> concat is a scourge on modules everywhere
15:41:30 <EmilienM> mgagne: how did you manage orders with ini provider?
15:42:02 <EmilienM> ie: middleware ordering
15:42:15 <mgagne> EmilienM: I'm not using it AFAIK =)
15:42:32 <mgagne> EmilienM: dmsimard is working on swift
15:42:53 <EmilienM> guimaluf: regarding other +1's, and the feedback here, I'll +2 the patch
15:42:59 <mgagne> EmilienM: I only started on theorical migration to ini provider but never managed to actually test it
15:43:29 <mgagne> EmilienM: but yes, there is no way to cleanly migrate to ini without breaking backward compatibility
15:43:55 <EmilienM> mgagne: ok
15:43:58 <EmilienM> anything else?
15:43:59 <mgagne> EmilienM: unless ini config build a concat fragment of some sort
15:44:05 <mgagne> still reading
15:44:27 <EmilienM> any core can +A this backport? https://review.openstack.org/#/c/214498/
15:45:03 <guimaluf> EmilienM, ty
15:45:08 <mgagne> only problem I can see is Puppet always reporting changes at each catalog run due to the mix of concat and ini provider
15:46:03 <EmilienM> also, https://review.openstack.org/#/c/207088 is deleting some old openstack parameters, please review
15:46:17 <EmilienM> mgagne: yes, so we loose the idempotent thing
15:46:22 <EmilienM> which is bad
15:46:22 <mgagne> yep
15:46:44 <mgagne> that's why we can to find a migration path to make this new provider actually usable
15:46:58 <mgagne> I'm guilty of half implementing the BP
15:47:01 <EmilienM> who is Aleksandr Didenko?
15:47:19 <EmilienM> about https://review.openstack.org/#/c/198695/ ^
15:47:34 <mwhahaha> what's the question?
15:47:47 <EmilienM> I would recommend him to talk to Christian Schwede
15:47:58 <EmilienM> or the swift team
15:48:04 <mwhahaha> k i'll send a note
15:48:09 <EmilienM> on thine one, I would like at least one +1 from swift people
15:49:07 <mwhahaha> k i dropped him a message
15:49:12 <EmilienM> cool
15:49:17 <EmilienM> do we have anything else outstanding?
15:49:23 <mfisch> nope
15:49:30 <mwhahaha> https://review.openstack.org/#/c/194673
15:49:39 <mwhahaha> just wanted to check if that retry logic was acceptable
15:49:51 <iurygregory> EmilienM, i have
15:50:04 <iurygregory> https://review.openstack.org/#/c/216821/
15:50:46 <iurygregory> The idea when we appŕoved the spec was one class for Service Provider
15:52:01 <EmilienM> I remember yes
15:52:09 <iurygregory> The common parameters doesn't exist because we will not use puppet-keystone to configure things related to shibboleth, mellon and openid
15:52:15 <EmilienM> we said that all parameters would be the same whatever plugin we're using?
15:53:04 <iurygregory> yes we have agree that the class will have all necessary parameters for all plugins
15:53:28 <iurygregory> and we will just validate according to the choice of deploy
15:53:35 <EmilienM> the only one reason we should have split classes, it's if we can run multiple plugins in the same time
15:54:09 <EmilienM> richm: any thoughts?
15:54:30 <EmilienM> it seems we have two options :
15:54:30 <mwhahaha> there are other modules where you still have multiple modules even though only one can be defined at the same time
15:54:32 <iurygregory> mwhahaha, have post comments in this review
15:54:43 <richm> There was one keystone guy who strongly felt that each provider should have its own puppet class
15:54:48 <EmilienM> 1/ keep one single class, only if all parameters are the same for whatever plugin, AND if we can run only one plugin in the same time
15:55:18 <EmilienM> 2/ split into separated classes for each plugins, with their own parameters and the capability to run multiple plugins in the same time (if keystone allows it)
15:55:55 <mwhahaha> my main concern about the current implementation is around the complex if/else used for validating all the combinations
15:56:00 <EmilienM> iurygregory: if we turn to 2/ I'm sorry, I suggested 1/ during the spec review but I was missing some context I guess
15:56:14 <EmilienM> mwhahaha: true
15:56:35 <mwhahaha> if we split it out, it will be much simpler and i think easier to comprehend when someone goes to try and implement
15:56:44 <EmilienM> I think it's early enough to iterate and split out, it's not a big change I guess
15:56:52 <EmilienM> iurygregory: wdyt?
15:56:59 <iurygregory> send another spec or change the spec approved?
15:57:03 <iurygregory> wdyt? o.o
15:57:11 <EmilienM> iurygregory: amend the spec and your code
15:57:20 <chem> ?
15:57:22 <EmilienM> which is 77 lines now
15:57:31 <EmilienM> hopefully you did not sent 1500 lines
15:58:01 <iurygregory> I agree with mwhahaha the complex if/else
15:58:07 <richm> +1
15:58:14 <EmilienM> iurygregory: good for 2/ ?
15:58:28 <iurygregory> yeah no problem in send other spec XD
15:58:43 <EmilienM> that's why iteration is good :)
15:58:46 <iurygregory> or just change the approved with the necessary modifications
15:58:51 <EmilienM> we fail quickly and fix quickly
15:59:04 <EmilienM> iurygregory: do not send a new spec
15:59:09 <EmilienM> amend the approved one
15:59:14 <iurygregory> sure =)
15:59:17 <EmilienM> good
15:59:19 <chem> for what is worth I agree with option 2/
15:59:21 <EmilienM> anything else? 2 min left
15:59:51 <iurygregory> need to create a bug or something?
15:59:55 <EmilienM> I'm looking forward to hack with you during the midcycle, and hope everyone will have fun
16:00:07 <EmilienM> have a nice day
16:00:11 <EmilienM> #endmeeting