15:00:03 <EmilienM> #startmeeting puppet-openstack
15:00:07 <openstack> Meeting started Tue Mar 31 15:00:03 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:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:10 <openstack> The meeting name has been set to 'puppet_openstack'
15:00:25 <gchamoul> o/
15:00:41 <EmilienM> #topic last weeks action items
15:01:09 <EmilienM> so we did not get a lot of feedback from sbadia's emails
15:01:40 <EmilienM> sbadia: thanks for your e-mail
15:02:27 <EmilienM> well, I guess he's not around now
15:02:42 <mgagne> o/
15:03:13 <EmilienM> if you have any feedback to share about "Coordinator(s)/PTL tasks description" thread, it's time
15:03:39 <EmilienM> same thing about "Moving under the big tent" thread
15:04:06 <EmilienM> I guess everybody agreed to move under the big tent finally
15:04:15 <gchamoul> yes!
15:04:29 <Hunner> It's not if, just when & how :)
15:04:36 <mgagne> yep
15:05:00 <EmilienM> I think the next step is to document what sbadia suggested in PTL tasks description
15:05:05 <EmilienM> so we can contribute on it on the wiki
15:05:20 <EmilienM> or maybe write a spec for it, I have no preference
15:05:44 <EmilienM> so we will agree on what we actually expect from PTL
15:06:04 <crinkle> I think just copying what was in sbadia's email into a wiki page is probably fine
15:06:11 <EmilienM> even though I'm convinced everything is already in official PTL document
15:06:15 <EmilienM> crinkle: ack
15:06:28 <EmilienM> #action EmilienM to document sbadia's email in the wiki
15:06:39 <dvorak> EmilienM: I wonder how much of that is that people don't read openstack-dev
15:07:09 <EmilienM> and then, we need to elect a PTL, so first we open the position. People can send their candidacy on the ML
15:07:18 <crinkle> dvorak: this was cross-posted to both lists
15:07:24 <dvorak> ah, nm then :)
15:08:17 <EmilienM> anything to add about this topic?
15:08:40 <crinkle> should we set a date to start submitting nominations?
15:09:22 <EmilienM> crinkle: well, I guess from today until next meeting we are waiting for candidacies and then if we have more than one candidate, we will have to figure out how to elect
15:09:35 <crinkle> EmilienM: mmk
15:09:43 <EmilienM> crinkle: does it make sense?
15:09:43 <mfisch> the ability to subscribe only to the puppet tag should remove any objections to the openstack-dev ml
15:09:57 <crinkle> EmilienM: sure, so it's open now
15:10:01 <EmilienM> yep
15:10:22 <EmilienM> I switch to next topic then
15:10:38 <EmilienM> #topic Defaults for new config file parameters
15:10:48 <EmilienM> #link https://review.openstack.org/#/c/169066/
15:11:02 <EmilienM> mgagne: dvorak ^
15:11:11 <mgagne> I posted my opinion on the subject in the review
15:11:31 <sbadia> hi! (sorry I'm late)
15:11:31 <EmilienM> and I +1 the comment.
15:11:37 <dvorak> We don't seem to handle this consistently.  In some places we're putting defaults into config files if they're not specified i other places we're ensuring absent if they're not specified
15:11:54 <EmilienM> we may need a new blueprint, that will affect all modules
15:12:01 <mgagne> We don't have a policy in place regarding default value. Until we have one (or not), I suggest we do not block the change.
15:12:53 <gchamoul> I suggest to open a blueprint on that because I am agree with mgagne that it will be time consuming!
15:12:54 <mgagne> some values need to be ensure => absent if some features are disabled. This isn't really because of default value.
15:13:19 <mgagne> well, I'm wrong I guess
15:13:21 <EmilienM> ok so, we move forward for ongoing patches and we create a blueprint for future
15:13:31 <mgagne> 10 lines below: volume_tmp_dir is ensure => absent
15:13:52 <EmilienM> who want to start working on the BP ?
15:14:05 <crinkle> EmilienM: but what policy should the blueprint put forward?
15:14:11 <dvorak> is there any concensus about what the BP should say?
15:14:15 <crinkle> ^
15:14:20 <dvorak> I think the answer is not obvious
15:14:24 <mgagne> IMO, there is no right answer
15:14:36 <mgagne> because you NEED some reasonable default values to have a working setup.
15:14:46 <dvorak> and I think the if defined { set option} else { ensure absent } pattern is pretty gross, but it's generally the behavior I prefer
15:14:49 <EmilienM> crinkle: only default values for Puppet params
15:15:06 <dvorak> mgagne: yes, but personally I'm opposed to hard coding upstream defaults in puppet modules
15:15:06 <mgagne> I think the issue is that we lag behind master when it comes to default values
15:15:44 <mgagne> dvorak: volume_tmp_dir is ensure => absent because the default value in openstack is None
15:15:47 <dvorak> it's a huge maintnance hassle that we're pretty much always going to be behind on with no automated testing
15:16:01 <mgagne> dvorak: "with no automated testing" lets fix that part?
15:16:24 <dvorak> that might be possible with openstack projects, but probably not with things like 3rd party drivers
15:16:50 <mgagne> dvorak: which 3rd party drivers are you referring to?
15:17:05 <dvorak> for example, storage backends, like solid fire, etc
15:17:18 <dvorak> or there was an issue with the Cisco Nexus 1K recently
15:17:22 <mgagne> dvorak: I don't see the problem
15:17:47 <mgagne> dvorak: they provide configs (and default values) just like any other openstack components
15:18:38 <mfisch> my frustration with encoding defaults is that the default change upstream and then puppet doesn't
15:18:40 <Hunner> dvorak: I think defaults should be sane, not just copied upstream. However upstream is usually pretty sane
15:18:41 <dvorak> fair enough, but developing that tooling is a huge task.  I don't think we should necessarily assume it will be developed in a policy we put together in the near future.
15:18:48 <mfisch> that doesnt have anything to do with 3rd party modules
15:18:51 <dvorak> Hunner: my concern is more when upstream defaults change.
15:19:15 <mfisch> The issue is whether upstream means Openstack, RedHat, or Ubuntu
15:19:24 <Hunner> dvorak: Yeah, but there isn't really any way around that. Software changes, and modules adapt to it
15:19:25 <EmilienM> should we dev a tool to detect it ?
15:19:34 <EmilienM> mfisch: OpenStack.
15:19:36 <gchamoul> i think yes !
15:19:45 <mgagne> dvorak: including NO default values defeat the whole purpose of our modules. I better use file resource to manage my configs then
15:20:05 <gchamoul> and being able to detect all the deprecated parameters as well!
15:20:11 <mfisch> +1000 for a tool
15:20:15 <dvorak> mgagne: specifically my concern is situations like this rbd patch, where there are already built-in defaults that take effect if the module sets nothing
15:20:21 <dvorak> I guess I should have been more clear
15:20:45 <mgagne> gchamoul: it isn't that hard. ask openstack projects to dump config definitions in a consumable format and we parse from there
15:21:05 <mgagne> dvorak: it's all over the place alright, rbd isn't the first one
15:21:25 <mgagne> dvorak: I could say you are opening a pandora's box
15:21:33 <gchamoul> mgagne: no it's too hard! That's something I was thinking about for a while now
15:21:35 <EmilienM> gchamoul: there is already a python tool to generate .conf files, we can re-use it?
15:21:45 <EmilienM> it's in oslo somewhere
15:21:51 <dvorak> right, and my conern specifically with this sort of patch, is that if the default schange in the next version of RBD, then you potentially have a non-optimal or even unsupported config w/ceph
15:22:11 <gchamoul> EmilienM: the doc team are using something too but I didn't find it
15:22:15 <mgagne> dvorak: is ceph any different than any other drivers or core openstack components?
15:22:24 <dvorak> no, it's just an example
15:22:31 <mgagne> dvorak: we just can't make exceptions based on the "feeling" of reviewers
15:22:52 <mgagne> dvorak: it has to be a project wide policy
15:23:12 <dvorak> That's exactly why I added it to the agenda.
15:23:21 <mgagne> alright
15:23:31 <mgagne> lets work on it then
15:23:50 <mgagne> but I suggest we do not block this change otherwise it might never merge, well not before months
15:24:02 <dvorak> I -1'ed it, it's not blocking anything.
15:24:08 <EmilienM> mgagne: +1
15:24:26 <gchamoul> well we have a lot of reviews in gerrit since a while!
15:24:27 * EmilienM comes again with a blueprint suggestion
15:25:09 <gchamoul> that's why I am harrassing core people for 3 weeks!
15:25:13 <dvorak> EmilienM: I see no consensus, so I'm not going to waste time writing a BP when there isnt' even agreement on what the problem is.
15:25:31 <EmilienM> dvorak: right
15:25:46 <EmilienM> that's the purpose of this topic and I don't want to close it until we got one
15:26:05 <dvorak> ok, fair enough
15:26:07 <mgagne> can we come up with a tool to detect default values provided by our modules and compare them with upstream? lets compile a basic catalog, blacklist/ignore any username/password/connection configs and see what comes up as different from upstream
15:26:51 <gchamoul> mgagne: +1
15:26:55 <EmilienM> gchamoul: out of topic now, can you raise it by the end of this meeting (open discussion)
15:27:13 <dvorak> when there is a default provided by the underlying software, what is the value of having the puppet module also write it in the config file?
15:27:41 <gchamoul> EmilienM: I know I was just answering to "but I suggest we do not block this change otherwise it might never merge, well not before months
15:27:43 <dvorak> specifically in the common case where the end user doesn't want to chagne the default.
15:27:47 <gchamoul> from mgagne
15:28:27 <mgagne> lets create a ML thread and continue here?
15:28:34 <crinkle> ++
15:28:37 <EmilienM> +1
15:28:40 <gchamoul> +!
15:28:42 <gchamoul> 1
15:28:58 <EmilienM> #action mgagne or dvorak runs a new thread on ML about Defaults for new config file parameters
15:29:21 <EmilienM> dvorak: mgagne : can we go to next topic? anything else to add ?
15:29:29 <mgagne> not for me
15:29:40 <dvorak> sure.
15:29:42 <EmilienM> #topic Support for recent changes to nova-novncproxy service
15:29:45 <EmilienM> #link https://review.openstack.org/#/c/168545
15:29:49 <EmilienM> larsks: ping
15:29:52 <larsks> pong!
15:30:21 <EmilienM> nothing much to say in a meeting, we just need some feedback on gerrit about https://review.openstack.org/#/c/168545
15:30:40 <EmilienM> larsks: go ahead if you want to explain the problem, and solutions
15:30:48 <larsks> For information on why we are doing this, take a look @ https://bugs.launchpad.net/nova/+bug/1409142.
15:30:49 <openstack> Launchpad bug 1409142 in OpenStack Compute (nova) juno "[OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259)" [High,Fix committed] - Assigned to Dave McCowan (dave-mccowan)
15:30:51 <larsks> The tl;dr is:
15:31:22 <larsks> Those changes in nova made the value of novncproxy_base_url required both for nova-compute *and* for nova-novncproxy, where previously it was only required by nova-compute.
15:31:53 <EmilienM> so novnc support in our puppet-nova is broken in kilo
15:32:47 <larsks> We have gone through several iterations of the fix; I'm reasonably happy with what we have right now, but open to alternative suggestions.
15:33:16 <larsks> It will require changes to tools that use the puppet-nova module (packstack, staypuft, etc)
15:33:30 <EmilienM> the major thing is, where to put vncproxy common params
15:33:43 <mgagne> in nova::vncproxy::common =)
15:33:53 <larsks> mgagne: I am happy to rename _ to :: :)
15:34:01 <mgagne> and find a way to inform the use about the new location
15:34:04 <mgagne> user*
15:34:21 <larsks> I was thinking about that earlier.  In theory, the user doesn't need to know about the module; it used by either nova::compute or nova::vncproxy
15:34:27 <EmilienM> I was thinking about using nova::vncproxy and add a boolean to manage the proxy service or not
15:34:53 <larsks> EmilienM: I like that less, because just about everything else (I think) has separate modules for "providing the service" vs "client of that service".
15:34:56 <mgagne> larsks: values used to be passed to nova::compute, it's now nova::vncproxy::common. they need to move their configs
15:35:16 <larsks> mgagne: what? I don't think there exists a nova:vncproxy::common right now...
15:35:24 <mgagne> larsks: in the proposed change: yes
15:35:40 <larsks> Errr...in the proposed change, which I wrote, there is a nova::vncproxy_common module.
15:36:02 <mgagne> I suggested renaming nova::vncproxy_common for nova::vncproxy::common
15:36:09 <larsks> Right, i agree with that change.
15:36:11 <mgagne> We don't use underscore much in our class name
15:36:12 <EmilienM> sounds fair
15:36:18 <larsks> Works for me.
15:36:21 <EmilienM> cool!
15:36:28 <EmilienM> let's continue the discussion on gerrit
15:36:32 <EmilienM> thanks a lot larsks
15:36:36 <larsks> Sure thing.
15:36:36 <mgagne> alright
15:36:39 <EmilienM> #topic Open Discussion, Bug and Review triage
15:36:50 <EmilienM> gchamoul: shoot
15:36:59 <EmilienM> you were worry about that before.
15:37:25 <gchamoul> No I was just reacting to mgagne sentence
15:37:27 <gchamoul> :D
15:37:47 <gchamoul> so we have some patches needing Approvals
15:37:48 <mgagne> I closed a bunch of released bugs. Some are still targeted to 6.0.0 (kilo) and others to unreleased versions (5.1.0, 4.3.0)
15:37:52 <EmilienM> if some people have specific patches to highlight, shoot here
15:37:59 <gchamoul> https://review.openstack.org/#/dashboard/?foreach=%28project%3Astackforge%2Fpuppet%252Dcinder+OR%0Aproject%3Astackforge%2Fpuppet%252Dnova+OR%0Aproject%3Astackforge%2Fpuppet%252Dswift+OR%0Aproject%3Astackforge%2Fpuppet%252Dmanila+OR%0Aproject%3Astackforge%2Fpuppet%252Dceilometer+OR%0Aproject%3Astackforge%2Fpuppet%252Dironic+OR%0Aproject%3Astackforge%2Fpuppet%252Dheat+OR%0Aproject%3Astackforge%2Fpu
15:38:01 <crinkle> thank you for working on that mgagne
15:38:01 <gchamoul> ppet%252Dneutron+OR%0Aproject%3Astackforge%2Fpuppet%252Dglance+OR%0Aproject%3Astackforge%2Fpuppet%252Dceph+OR%0Aproject%3Astackforge%2Fpuppet%252Dmonasca+OR%0Aproject%3Astackforge%2Fpuppet%252Dgnocchi+OR%0Aproject%3Astackforge%2Fpuppet%252Dtripleo+OR%0Aproject%3Astackforge%2Fpuppet%252Dkeystone+OR%0Aproject%3Astackforge%2Fpuppet%252Dhorizon+OR%0Aproject%3Astackforge%2Fpuppet%252Ddesignate+OR%0Apr
15:38:02 <EmilienM> mgagne: thanks a lot for this work
15:38:03 <gchamoul> oject%3Astackforge%2Fpuppet%252Dmurano+OR%0Aproject%3Astackforge%2Fpuppet%252Dn1k%252Dvsm+OR%0Aproject%3Astackforge%2Fpuppet%252Dsahara+OR%0Aproject%3Astackforge%2Fpuppet%252Dvswitch+OR%0Aproject%3Astackforge%2Fpuppet%252Dtrove+OR%0Aproject%3Astackforge%2Fpuppet%252Dtempest+OR%0Aproject%3Astackforge%2Fpuppet%252Dopenstacklib+OR%0Aproject%3Astackforge%2Fpuppet%252Dopenstack+OR%0Aproject%3Astackfor
15:38:05 <gchamoul> ge%2Fpuppet%252Dopenstack%252Dspecs%29+status%3Aopen+NOT+label%3AWorkflow%3C%3D%252D1+NOT+label%3ACode%252DReview%3C%3D%252D2&title=Puppet+Openstack+Modules+Inbox&My+Patches+Requiring+Attention=owner%3Aself+%28label%3AVerified%252D1%252cjenkins+OR+label%3ACode%252DReview%252D1%29&Puppet+Openstack+Specs=NOT+owner%3Aself+project%3Astackforge%2Fpuppet%252Dopenstack%252Dspecs&Needs+Approval=label%3AV
15:38:07 <gchamoul> erified%3E%3D1%252cjenkins+NOT+owner%3Aself+label%3ACode%252DReview%3E%3D2+NOT+label%3ACode%252DReview%252D1&5+Days+Without+Feedback=label%3AVerified%3E%3D1%252cjenkins+NOT+owner%3Aself+NOT+project%3Astackforge%2Fpuppet%252Dopenstack%252Dspecs+NOT+label%3ACode%252DReview%3C%3D2+age%3A5d&No+Negative+Feedback=label%3AVerified%3E%3D1%252cjenkins+NOT+owner%3Aself+NOT+project%3Astackforge%2Fpuppet%252
15:38:09 <EmilienM> oh dear..
15:38:09 <gchamoul> Dopenstack%252Dspecs+NOT+label%3ACode%252DReview%3C%3D%252D1+NOT+label%3ACode%252DReview%3E%3D2+limit%3A50&Other=label%3AVerified%3E%3D1%252cjenkins+NOT+owner%3Aself+NOT+project%3Astackforge%2Fpuppet%252Dopenstack%252Dspecs+label%3ACode%252DReview%252D1+limit%3A20
15:38:13 <gchamoul> sorry for the link
15:38:13 <crinkle> -_-
15:38:16 <larsks> Ouch.
15:38:29 <EmilienM> gchamoul: can you short the link ?
15:38:36 <EmilienM> with bit.ly or...
15:38:41 <mgagne> also, I would like to know if we are planning on actively supporting legacy branches or not?
15:38:42 <gchamoul> sure
15:38:44 <mgagne> like grizzly =)
15:38:50 <EmilienM> hum...
15:39:05 <EmilienM> we should ask on ML about that I think
15:39:17 <crinkle> if people backport things to those branches I don't see a problem with making bugfix releases to them
15:39:33 <mgagne> because although we might think it's free, it still has a cost where we have to update rspec framework to make tests pass
15:39:59 <EmilienM> yes
15:40:17 <dvorak> depending on how you define "support" it's a huge amount of work even aside from the unit tests
15:40:51 <mgagne> dvorak: so far, stable branches have been a scratch your own itch thing
15:41:31 <dvorak> I'm curious, who here is using the stable branches?
15:41:35 <mgagne> I am
15:41:42 <EmilienM> me too
15:42:04 <mgagne> but I'm seriously thinking about running from master with a branchless puppetmaster
15:42:23 <mgagne> I'm not sure how yet but the idea is out there
15:42:31 <gchamoul> so https://goo.gl/
15:42:35 <dvorak> we're running from master, and plan to keep doing so until we run into kilo/juno compat issues
15:42:41 <EmilienM> with good CI, all is possible...
15:42:49 <crinkle> there are already kilo/juno compat issues
15:42:52 <gchamoul> can you have a look under 'Needs Approvals'
15:42:53 <EmilienM> yep
15:43:00 <dvorak> crinkle: none that have affected us
15:43:09 <mgagne> EmilienM: especially if I can detect deprecated configs or not yet introduced configs =)
15:43:40 <crinkle> dvorak: there are a couple in neutron that try to install packages that don't exist yet
15:43:41 <EmilienM> gchamoul: the url is incomplete..
15:43:46 <gchamoul> https://goo.gl/hKTmf1
15:44:30 <EmilienM> if people could have a look at https://goo.gl/hKTmf1 and do some reviews, gchamoul would be very happy :è)
15:45:15 <crinkle> ...those are all the patches...
15:45:17 <mgagne> EmilienM: btw, my bug tools are there: https://github.com/mgagne/openstack-puppet-release-tools
15:45:39 <EmilienM> crinkle: yeah... just to highlight the "need approvals" things..
15:45:45 <gchamoul> crinkle: the priority is the 'Needs Approvals' list
15:45:51 <EmilienM> gchamoul: I was waiting more from specific patches...
15:46:00 <EmilienM> gchamoul: how come it's a priority?
15:46:03 <gchamoul> and '5 days without Feedback
15:46:36 <dvorak> gchamoul: thanks for that, I like the way the dashboard is done, I've been meaning to do something similar
15:46:57 <gchamoul> EmilienM: I think all is urgent!
15:46:58 <EmilienM> mgagne: that's a nice tool, I think we would need it to move it under openstack repo
15:47:15 <EmilienM> gchamoul: well, I disagree with you. We have different point of view I think.
15:47:29 <EmilienM> we have some very urgent things and some less urgent.
15:47:53 <EmilienM> the idea of this topic is to highlight some blocked patches, that needs discussion or just reviews... same for bugs
15:48:06 <crinkle> ++
15:48:12 <EmilienM> not putting a BIG url
15:48:20 <EmilienM> with all patches that are under review
15:48:53 <EmilienM> mfisch: we have 10 min left, would you like to talk about Bug Triage for a specific module?
15:49:32 <mfisch> I have again failed to prepare for this
15:49:42 <mfisch> Lets discuss puppet-nova next week
15:49:45 <gchamoul> EmilienM: I just want to help!
15:49:47 <EmilienM> no problem.
15:49:47 <gchamoul> ok
15:50:00 <EmilienM> gchamoul: your help is highly appreciated
15:50:04 <gchamoul> we have a lot of patches in review
15:50:11 <EmilienM> we just want to be efficient and this URL does not help much
15:50:42 <EmilienM> ok, so we can ask officially here to let core people know that they may do more review if they have time
15:50:46 <gchamoul> and I am quite disappointed when I am seeing some new contrib ... without feedbacks, without reviews after 3 weeks
15:51:15 <EmilienM> it's a good feedback
15:51:27 <gchamoul> that's why I am spamming all the core people!
15:51:35 <EmilienM> spamming won't help much I guess
15:51:42 <gchamoul> mfisch likes that!
15:51:49 <EmilienM> are we done?
15:52:02 <gchamoul> so What to do ?
15:52:04 <EmilienM> if you have something else to add, rise your and now
15:52:10 <mfisch> We need more cores then
15:52:10 <EmilienM> hand*
15:52:10 <gchamoul> doing the same on IRC?
15:52:29 <EmilienM> mfisch: indeed, what do you suggest?
15:53:49 <mfisch> EmilienM: well I wish I had an answer
15:53:53 <EmilienM> hehe
15:53:54 <dvorak> gchamoul: I'd remove puppet-ceph from that dashboard, since the core list is separate
15:54:02 <EmilienM> dvorak: +1
15:54:06 <mfisch> I'd certainly like to get feedback for new commiters
15:54:09 <dvorak> same for monasca
15:54:15 <gchamoul> dvorak: ack
15:54:17 <mfisch> yes +1 for monasca
15:54:18 <EmilienM> mfisch: we can discuss about that later (offline?) to see if someone could be proposed
15:54:33 <EmilienM> mfisch: we are core on monasca now, right ? ( cc sbadia )
15:55:33 <mfisch> I am for sure
15:55:42 <EmilienM> cool
15:55:58 <mfisch> those guys still work very closely with the HP team, changes so much
15:56:48 <EmilienM> yeah... the module will need some work I think
15:56:53 <mfisch> I agree
15:56:59 <EmilienM> I think we are done
15:57:03 <EmilienM> thanks everyone
15:57:07 <mfisch> they're still fighting with stuff like upstream forcing keystone v3 without warning for exampple
15:57:09 <mfisch> thanks
15:57:18 <EmilienM> #endmeeting