15:00:11 <EmilienM> #startmeeting puppet-openstack
15:00:12 <openstack> Meeting started Tue Sep 15 15:00:11 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:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:16 <openstack> The meeting name has been set to 'puppet_openstack'
15:00:16 <iurygregory> hello o/ ( こんにちは )
15:00:22 <EmilienM> #link agenda: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150915
15:00:28 <xarses> hi
15:00:30 <mwhahaha> hi
15:00:30 <EmilienM> hello, who is here today?
15:00:42 <IBerezovskiy> hi
15:00:48 <spredzy> hello
15:00:58 <degorenko> o/ hey
15:01:34 <angdraug> o/
15:01:40 <crinkle> o/
15:02:01 <mfisch> hey
15:02:02 <skolekonov> hi
15:02:19 <EmilienM> #topic documentation
15:02:31 <EmilienM> #link https://wiki.openstack.org/wiki/Puppet
15:02:44 <EmilienM> I worked on a new layout and also more content
15:02:55 <richm> here
15:03:00 <EmilienM> any volunteer to contribute? we still need more content
15:03:18 <EmilienM> I thought maybe we could create an etherpad to synchronize the work
15:03:20 <iurygregory> i can help a little =)
15:03:56 <EmilienM> #link https://etherpad.openstack.org/p/puppet-wiki
15:04:56 <sbadia> hey
15:05:01 <EmilienM> I would expect some help on Coding style, specially from our core team since they should already know that
15:05:16 <EmilienM> it will help newcomers to quickly provide good patches
15:05:50 <EmilienM> so if anyone is interested, look at the etherpad and contribute!
15:06:06 <sbadia> ack, /me take a look
15:06:16 <EmilienM> the documentation will help us to welcome more contributors, get more adoption and have more visibility so please consider it :)
15:06:25 <iurygregory> ok o/
15:06:56 <EmilienM> cool
15:07:20 <EmilienM> #topic Sprint Retrospective
15:07:22 <EmilienM> #link https://etherpad.openstack.org/p/puppet-liberty-sprint-retrospective
15:07:42 <EmilienM> so except me and mfisch - there is not much feedback
15:08:04 <EmilienM> I'm not sure it means everything was perfect :)
15:08:22 <EmilienM> mfisch recommends to make it in person next time
15:08:41 <EmilienM> for that, I would suggest we schedule it long time (enough) ago
15:08:43 <mfisch> its difficult to focus for me otherwise, my boss sees me here he expects me to do work here
15:08:59 <EmilienM> and avoid overlap with operators or infra sprints
15:09:27 <EmilienM> does anyone has any other feedback to share about the sprint?
15:09:28 <mfisch> I think we should do it concurrentish with operators
15:09:37 <mfisch> ops is T-W, we could do R-F
15:09:49 <EmilienM> mfisch: R-F ?
15:09:59 <mfisch> Thursday/Friday
15:10:02 <EmilienM> ah
15:10:06 <mfisch> sorry two days start with T in English so we use R
15:10:16 <xarses> we do?
15:10:21 <EmilienM> I wish I could speak in french here
15:10:21 <iurygregory> o.o
15:10:23 <mfisch> absolutely
15:10:31 <xarses> Th here
15:10:49 <EmilienM> it sounds a good idea but are we sure our folks want to attend OPS sprint too?
15:10:55 <mfisch> they dont have to
15:11:01 <mfisch> they can come in Wednesday night right?
15:11:07 <EmilienM> yeah
15:11:10 <EmilienM> I like the idea
15:11:13 <mfisch> but me, dorman, crinkley, and a bunch of others were already there
15:11:17 <xarses> anyway it would be helpful to double upIMO
15:11:20 <mfisch> sorry crinkle, not crinkley
15:11:23 <crinkle> lol
15:11:26 <EmilienM> ahah
15:11:29 <EmilienM> big +1
15:12:13 <EmilienM> mfisch: written in the etherpad
15:12:16 <mfisch> thx
15:12:42 <EmilienM> anything else to say about the sprint?
15:13:11 <EmilienM> ok let's move then
15:13:25 <EmilienM> #topic Tokyo - Summit
15:13:43 <EmilienM> #link Summit etherpad https://etherpad.openstack.org/p/HND-puppet
15:13:47 <EmilienM> all you need to know is here ^
15:14:10 <EmilienM> if you attend the summit, please open the link and look
15:14:24 <EmilienM> we are still preparing the agenda, feel free to bring any topic
15:14:39 <EmilienM> well, even if you don't attend it in person, we can arrange remote things
15:15:36 <EmilienM> I'll let a bit more of time for our group to feed the topics
15:15:50 <EmilienM> and make sure we have an agenda when we are there
15:16:02 <EmilienM> mfisch: this time I hope there will not be overlap with ops stuffs
15:16:14 <mfisch> Im sure there will be unfortunately
15:16:30 <EmilienM> anyway, we will deal with that, like usual :)
15:16:39 <EmilienM> anything else about summit?
15:17:02 <EmilienM> if you noticed, I haven't suggested playing bowling yet
15:17:05 <mfisch> lol
15:17:16 <sbadia> ^^
15:17:20 <spredzy> EmilienM, this is Japan isn't Karaoke there thing :)
15:17:25 <EmilienM> ok let's move
15:17:30 <EmilienM> spredzy: I'm very good at singing
15:17:34 <EmilienM> or maybe not
15:17:38 <EmilienM> #topic Cinder module & <SERVICE DEFAULT>
15:17:40 <sbadia> EmilienM: please don't :D
15:17:40 <EmilienM> spredzy: o/
15:17:58 <spredzy> degorenko, o/
15:17:58 <Hunner> "karaoke" is a japanese word even
15:18:05 <EmilienM> spredzy, mwhahaha and degorenko: hey
15:18:11 <degorenko> EmilienM, spredzy,  o/
15:18:13 <mwhahaha> hey
15:18:33 <EmilienM> what needs to be discussed here?
15:18:35 <mwhahaha> #link https://review.openstack.org/#/c/219275/4
15:18:41 <degorenko> yep ^
15:18:53 <mwhahaha> so we're using '<SERVICE DEFAULT>' but when we flip a parameter to true we can't use that anymore
15:18:58 <mwhahaha> previously that's an undef check
15:19:07 <mwhahaha> so how should we handle such cases
15:19:38 <mwhahaha> when we need to enforce the parameter is set to something other than <SERVICE DEFAULT>
15:19:50 <mfisch> yeah I was wondering about that in the review
15:19:54 <mfisch> how we deal with bools
15:20:18 <spredzy> Well we do have this case in this current review
15:20:22 <spredzy> #link https://review.openstack.org/#/c/221265/4/manifests/backend/gpfs.pp,cm
15:20:45 <spredzy> with == '<SERVICE DEFAULT>' meaning true for tests
15:21:39 <mwhahaha> so we'll need to do a != '<SERVICE DEFAULT>' check as necessary?
15:22:10 <EmilienM> I recognize the name is not easy
15:22:31 <spredzy> mwhahaha, correct
15:22:44 <mwhahaha> ugh, but ok
15:23:03 <EmilienM> spredzy: could not we do better?
15:23:52 <spredzy> I am open - but the name was decided after several meeting. Changing the name per se isn't much work, making sure it can't be misinterpreted by  a module is another story
15:24:04 <spredzy> neither of the traditional undef, '', false, nil can do
15:24:35 <EmilienM> I think we can stick on that name now, but I would like good documentation around this
15:24:46 <EmilienM> spredzy: can you make sure you document it in coding style?
15:24:52 <EmilienM> with a dedicated subsection
15:25:36 <spredzy> EmilienM, ack
15:25:58 <spredzy> I see the wiki is already updated :)
15:26:16 <EmilienM> spredzy: yeah I take notes in //
15:26:22 <EmilienM> great
15:26:39 <EmilienM> mwhahaha: so yeah... in the meantime, let's continue like this - if you have a better proposal, please propose it
15:27:00 <EmilienM> what spredzy is doing will really help to stick on default OpenStack values
15:27:07 <mwhahaha> i don't think there is one unfortunately, just want to make sure we all agree on this
15:27:25 <mwhahaha> no makes sense, it's just very ugly from a readability standpoint
15:27:29 <mwhahaha> and so much extra code :/
15:27:45 <EmilienM> mwhahaha: wait - our first motivation was to reduce code
15:27:59 <degorenko> by using this we reduce code actualy :)
15:28:12 <degorenko> we just don't use absent setting anymore
15:28:19 <EmilienM> yeah
15:28:25 <EmilienM> since our provider is taking care of that
15:28:33 <mwhahaha> we'll see
15:28:37 <mwhahaha> :)
15:28:39 <degorenko> i think, it's good, but i agree, parameter name is ugly :)
15:29:00 <EmilienM> spredzy, mwhahaha: if you guys have ideas to improve the readability, go ahead - for now we use puppet-cinder as canary
15:29:05 <EmilienM> do not patch other modules yet ^
15:29:25 <mwhahaha> can we create a not service default function in openstacklib or something?
15:29:27 <EmilienM> mwhahaha, degorenko: as spredzy is saying, we discussed about that name in previous meetings
15:29:50 <mwhahaha> is_os_default($var) that does a check for == '<SERVICE DEFAULT>'
15:29:51 <EmilienM> mwhahaha: which name would you use?
15:29:58 <mwhahaha> or something
15:30:00 <degorenko> yes, i'm not against such name
15:30:02 <mwhahaha> is_service_default
15:30:15 <mwhahaha> so we don't have to keep typing '<SERVICE DEFAULT>' for these checks
15:30:35 <spredzy> mwhahaha, I am not against it
15:30:44 <EmilienM> I would like to see some code as an example
15:30:46 <chem> that's a good adiea
15:30:52 <chem> idea
15:30:53 <mwhahaha> sure i'll create a review
15:30:58 <spredzy> if this improves readability basically it would be an if == <SERVICE DEFAULT> return true else return false
15:30:59 <EmilienM> mwhahaha: cool th
15:31:00 <iurygregory> ++
15:31:00 <EmilienM> thx
15:31:13 <mwhahaha> #action mwhahaha to create is_service_default check function
15:31:40 <mwhahaha> if is_service_default($var) { fail(...) }
15:31:45 <mwhahaha> something of the sort
15:31:52 <EmilienM> mwhahaha: sounds like cool
15:32:20 <EmilienM> mwhahaha: you can patch puppet-openstacklib + patch puppet-cinder and use Depends-On
15:32:26 <EmilienM> so we can actually test and see the result
15:32:36 <mwhahaha> sure, i'll get with degorenko and get it lined up
15:32:44 <EmilienM> awesome :)
15:32:51 <EmilienM> anything else on this topic?
15:33:01 <mwhahaha> i'm ok
15:33:11 <degorenko> yep! thanks :)
15:33:17 <EmilienM> #topic Federation blueprint
15:33:19 <EmilienM> iurygregory: o/
15:33:22 <iurygregory> o/
15:33:25 <iurygregory> Well people, when the spec enabling-federation was approved, the idea was one class for service provider and we should validate the choice because we have three possibilities: OpenID Connector as protocol and with SAML as protocol, with SAML we need to choose the module between shibboleth and mellon.
15:33:49 <iurygregory> The reason to have just one class was that they will share common attributes, but since the code will be on puppet-keystone and we can only modify configuration files (keystone.conf keystone-apache) related to Keystone and this attributes are related to the configuration files of the installed protocol/module, taking as an example Shibboleth, we need to apply changes in shibboleth2.xml and attribute-map.xml which are located in "/etc/s
15:33:49 <iurygregory> hibboleth" =/ .
15:34:23 <EmilienM> first thing to consider, if this single manifest is going to be huge, better to split it from now
15:34:49 <iurygregory> ok
15:34:57 <EmilienM> mfisch: any thoughts?
15:35:03 <EmilienM> richm: ^
15:35:46 <iurygregory> So i need to change the spec only to say that we will have one class for each possibility with the proper attributes to configure keystone files?
15:35:58 <EmilienM> I think we could have ::keystone::federation::saml
15:36:02 <richm> yes
15:36:13 <EmilienM> and ::keystone::federation::shib
15:36:14 <EmilienM> etc
15:36:23 <mfisch> yes
15:36:25 <mfisch> agree
15:36:25 <iurygregory> ok ^^
15:36:26 <richm> then a class/resource (might be a resource if there will be more than one instance)
15:36:31 <EmilienM> iurygregory: I know it's confusing from what we said some time ago
15:36:40 <EmilienM> but I think we did not realize all the logic in there
15:36:47 <chem> you could load them from a keystone::federation one and share common attributes there
15:36:49 <EmilienM> and for readability we could split it
15:36:51 <iurygregory> no problem EmilienM
15:36:56 <EmilienM> chem++
15:37:09 <EmilienM> iurygregory: chem's proposal is also good if we have common parameters
15:37:10 <richm> there is a lot of stuff in common for all federation, but there are also a lot of differences between the providers
15:37:17 <iurygregory> chem, i think we doesn't have common attributes anymore =/
15:37:21 <richm> so it's going to be a matter of finding the right balance
15:37:32 <EmilienM> for common params we could have ::keystone::federation
15:37:38 <richm> right
15:37:38 <iurygregory> parameters*
15:37:52 <EmilienM> and then ::keystone::federation::<backends>
15:38:09 <EmilienM> it's same thing as cinder volumes, etc or kind of
15:38:22 <richm> yeah - common idiom used in a lot of opm
15:39:08 <chem> the split seems natural, but if the parameter are too different may end up hard to implement in puppet...
15:39:54 <EmilienM> I think common params should live in ::keystone::federation
15:40:03 <EmilienM> and specific backends config in ::keystone::federation::<backends>
15:40:13 <iurygregory> i think one class for each possibilty is fine, or maybe we can have a puppet-federation module =P
15:40:32 <EmilienM> iurygregory: nope - puppet-keystone is the right module for that
15:40:45 <chem> and let the user call directly each backend or have each backend called from keystone::federation ?
15:41:00 <EmilienM> side node, puppet-keystone won't configure the backend service itself (ie: configure any other service but keystone or WSGI)
15:41:10 <EmilienM> chem: #1
15:41:19 <EmilienM> chem: I think?
15:41:25 <EmilienM> or #2 would avoid mistakes
15:41:26 <chem> EmilienM: oki, harder, but cleaner :)
15:41:38 <EmilienM> chem: #1 would require good documentation
15:41:45 <EmilienM> but make the code cleaner
15:42:06 <EmilienM> #2 is easiers for our users but code is hard to maintain
15:42:13 <EmilienM> what do we want?
15:42:23 * EmilienM pokes mfisch
15:42:40 <mfisch> let me catch up
15:43:41 <mfisch> #1 is your proposal emilien
15:43:42 <mfisch> ?
15:43:51 <EmilienM> mfisch: for now, yes
15:44:07 <richm> +1 for #1
15:44:12 <mfisch> I think that makes sense
15:44:18 <iurygregory> well i think the common attributes will not exist because we wont  configure the backend service =)
15:44:21 <mfisch> I could live with the other option too
15:44:28 <EmilienM> iurygregory: let's go for #1
15:44:33 <EmilienM> iurygregory: ok
15:45:01 <EmilienM> iurygregory: yeah, configuring the backend service is not up to openstack modules
15:45:13 <EmilienM> I expect people using a specific puppet module for that
15:45:14 <iurygregory> ok EmilienM ^^
15:45:32 <iurygregory> So i need to change the spec only to say that we will have one class for each possibility with the proper attributes to configure keystone files?
15:46:09 <EmilienM> iurygregory: eventually
15:46:54 <EmilienM> ok we have 15m left
15:46:54 <iurygregory> Should we change the spec after the code get merged or right now?
15:47:03 <EmilienM> iurygregory: before
15:47:13 <iurygregory> ok
15:47:13 <EmilienM> a blueprint should be merged before any code in theory
15:47:22 <EmilienM> in reality, we sometimes need to iterate :)
15:47:28 <iurygregory> tks o/
15:47:34 <EmilienM> iurygregory: thx!
15:47:36 <richm> I think it would be helpful to me (and probably a lot of people here) to see some sort of implementation in puppet (i.e. a WIP)
15:48:02 <richm> . . . but there's no reason why the code and the blueprint cannot be worked on in parallel
15:48:09 <EmilienM> richm: like in the example/*.pp ?
15:48:11 <richm> one usually informs the other
15:48:24 <richm> EmilienM: yes
15:48:29 <EmilienM> richm: of course
15:48:36 <EmilienM> it would be super useful for our users
15:48:51 <EmilienM> maybe give an example of manifest with an external module is ok
15:49:15 <iurygregory> ok ^^
15:49:17 <EmilienM> richm, iurygregory: anything else?
15:49:31 <iurygregory> not in this topic
15:49:36 <EmilienM> #topic Open Discussion, Bugs, Reviews triage
15:50:03 <mfisch> looking through reviews and the Cinder one was a big one that we already discussed
15:50:04 <EmilienM> note: for the Lab101: I think it should be an effort documented here: https://etherpad.openstack.org/p/puppet-wiki
15:51:06 <EmilienM> if you have any outstanding patch, review or bug please raise it here
15:51:10 <tiswanso> Hi all, I have a review out that I'm really depending on for tripleo support in Liberty.  https://review.openstack.org/#/c/222451
15:51:32 <tiswanso> It's to a cisco specific piece of ML2 conf
15:52:06 <iurygregory> Anyone that knows about acceptance can please review - https://review.openstack.org/#/c/208054/ :D
15:52:09 <EmilienM> tiswanso: nice, finally we get rid of erb templates :)
15:52:16 <tiswanso> I'd like to also follow-on with a similar technique for another new config piece
15:52:18 <tiswanso> :-)
15:53:12 <EmilienM> tiswanso: degorenko already reviewed it, but it's nits
15:53:55 <tiswanso> EmilienM: yes, I can get those nits done quick if required.
15:54:05 <EmilienM> iurygregory: that's a big patch, I'll have a look later today :)
15:54:11 <EmilienM> tiswanso: thanks
15:54:20 <iurygregory> o/ thanks EmilienM
15:54:29 <EmilienM> there is also a neutron patch (QOS), see https://review.openstack.org/#/c/216654/
15:54:38 <iurygregory> the acceptance is just wsgi + federation
15:55:00 <EmilienM> mfisch, crinkle: I would be happy to have a review on https://review.openstack.org/#/c/217352/
15:55:12 <skolekonov2> EmilienM
15:55:20 <skolekonov2> thanks, I've tried to check how Neutron QoS works on devstack, and the changes which I'm adding in the patch should be enough to enable it.
15:55:26 <mfisch> yes I started to look at that last night EmilienM I will finish today
15:55:46 <skolekonov2> though it's not important change, just a Liberty feature
15:55:58 <EmilienM> skolekonov2: good to know
15:56:03 <EmilienM> anything else for today?
15:56:06 <IBerezovskiy> EmilienM, we talked today about cookiecutter for puppet-murano. Is this CR  https://review.openstack.org/#/c/223597/ what you've expected?
15:57:26 <EmilienM> IBerezovskiy: is that all your initial commit?
15:57:32 <EmilienM> there is no manifests, etc
15:58:09 <IBerezovskiy> EmilienM, this is in next commit https://review.openstack.org/#/c/211043/
15:58:24 <degorenko> EmilienM, no, all manifests will be added in dependency patch
15:58:37 <EmilienM> so you split in chunks
15:58:50 <IBerezovskiy> yep
15:58:53 <degorenko> yes, to avoid a biiig patches :)
15:58:59 <EmilienM> works for me
15:59:11 <IBerezovskiy> good to know :)
15:59:13 <EmilienM> I +2'ed the initial commit
15:59:16 <degorenko> yep :)
15:59:17 <EmilienM> I'll review other later
15:59:21 <IBerezovskiy> thanks
15:59:25 <EmilienM> anything else?
15:59:40 <EmilienM> thanks for joining - have a great day
15:59:47 <EmilienM> #endmeeting