15:01:14 <EmilienM> #startmeeting puppet-openstack
15:01:15 <openstack> Meeting started Tue Mar 15 15:01:14 2016 UTC and is due to finish in 60 minutes.  The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:19 <openstack> The meeting name has been set to 'puppet_openstack'
15:01:25 <mfisch> morning
15:01:27 <EmilienM> #link agenda https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160315
15:01:30 <degorenko> hey :)
15:01:34 <chem> o/
15:01:36 <_ody> o/
15:01:38 <EmilienM> wow wehave items this week
15:02:09 <EmilienM> let's start
15:02:13 <EmilienM> #topic trove external repos
15:02:15 <clayton> o/
15:02:15 <EmilienM> mfisch: o/
15:02:18 <mfisch> hey
15:02:25 <mfisch> okay so this came up as we looked into using Trove
15:02:32 <mwhahaha> hi
15:02:46 <mfisch> tesora have their own repo that it would be nice to add support for, but I saw in a previous neutron review that we've dropped external repos?
15:02:48 <mfisch> whats the policy?
15:02:53 <EmilienM> what do they provide?
15:03:17 <EmilienM> mfisch: https://openstack.nimeyo.com/60184/openstack-puppet-should-puppet-neutron-manage-party-software
15:03:37 <mfisch> they do more frequent releases amongst other things
15:03:53 <mfisch> not a great comparison but like redhat enterprise to centos
15:03:56 <EmilienM> you want to enable third party repos to install a more recent version of Trove?
15:04:01 <mfisch> abramley: can you explain better ^
15:04:05 <mwhahaha> we could add it into openstack_extras?
15:04:15 <EmilienM> it's sounds very odd to me.
15:04:26 <mfisch> it could be an optional repo
15:04:42 <mfisch> rather than forking the module I think it's preferred
15:04:47 <EmilienM> they should rather contribute to RDO or UCA, which are supposed to be official packaging, isn't?
15:04:49 <mfisch> something like $use_tesora_repo
15:05:08 <EmilienM> mfisch: is package name & service name the same?
15:05:14 <mfisch> good question
15:05:19 <mfisch> service names yes, package names no
15:05:22 <abramley> Tesora is a commercial offering based on trove
15:05:23 <EmilienM> if yes, just do it in your composition layer
15:05:36 <EmilienM> theere is no way we enable commercial things in our repositories.
15:05:36 <mfisch> in order to avoid a fork at a minimum we need to make the package names configurable
15:05:47 <mfisch> then yes, operators could do their own repo managament
15:05:58 <mwhahaha> sounds like our uca vs deb package name conversation again
15:06:05 <EmilienM> yes, exactly
15:06:12 <mfisch> remind me the outcome of that?
15:06:43 <mwhahaha> we are using the os_package_type fact for that but that doesn't make sense for this
15:06:59 <mwhahaha> the original idea proposed was to create a globals class that you could override package names
15:07:03 <clayton> that worked because your names match the debian names exactly
15:07:04 <mfisch> I was thinking package names would need to be parameters
15:07:18 <mfisch> there's what 3 main packages for trove?
15:07:32 <clayton> this is a similar situation in that tesora is basically an alternate distro for just trove
15:07:39 <abramley> yes
15:07:42 <mwhahaha> you could just Package <| title == 'trove' |> { name => 'whatever' } in your composition layer
15:07:44 <mfisch> thats a good way to explain
15:07:54 <degorenko> +1 to mwhahaha way
15:07:55 <EmilienM> no, 4 at least
15:07:55 <abramley> we keep the same package structure - api, conductor, taskmanager
15:08:28 <mwhahaha> could automagically do such things in an openstack_extras class where it sets up the repo
15:08:43 <EmilienM> abramley: same service name?
15:08:55 <abramley> yes - same service names
15:09:09 <EmilienM> if service/package names are same as in UCA, there is no need to patch puppet-trove.
15:09:28 <mfisch> package names are not
15:09:29 <mfisch> I said above
15:09:30 <EmilienM> so the question is whether allow openstack_extras to have a class that setup the repo or let people manage that in their composition layer
15:09:32 <mfisch> tesora-dbaas-common_1.6.2-614_all.deb
15:09:38 <mfisch> tesora-dbaas-api_1.7.0-93_all.deb
15:09:39 <mfisch> etc
15:09:54 <mwhahaha> so override them with the spaceship
15:10:09 <EmilienM> right, you don't need to fork puppet-trove for that
15:10:42 <mfisch> just provide some guidance to folks to make it easy to use
15:10:58 <mfisch> we already have a large comp layer so its easy to add there
15:11:23 <mwhahaha> so if we create a tesora class in openstack_extras that sets up the repo and puts in the package name overrides, it would be an easy to implement thing for anyone who wants it
15:11:40 <EmilienM> mfisch: you could patch puppet-trove/examples/tesora.pp with an example of manifest that add the repo and change package name and deploy trove
15:11:44 <mfisch> whats the argument for putting it there? just because we manage other repos there?
15:11:45 <mwhahaha> include openstack_extras::repo::tesora or something
15:11:51 <mwhahaha> yea
15:11:58 <EmilienM> mwhahaha: if we do that, we'll have to accept other third party repos
15:12:09 <EmilienM> something we kind of rejected in the past with https://openstack.nimeyo.com/60184/openstack-puppet-should-puppet-neutron-manage-party-software
15:12:17 <mwhahaha> only as part of the puppet-neutron
15:12:25 <mwhahaha> i would say -1 to putting it in puppet-trove
15:12:27 <clayton> EmilienM: I think plugins and distros are different cases
15:12:41 <EmilienM> I don't mind enabling tesora repos then
15:13:00 <mfisch> so we'll do it in openstack-extras
15:13:02 <EmilienM> mfisch: ok for openstack_extras::repo::tesora
15:13:12 <mfisch> with package spaceships there too?
15:13:20 <mfisch> for lack of a better way to explain ^
15:13:21 <EmilienM> mfisch: optionally, yes
15:13:30 <EmilienM> that you can disable with a boolean
15:13:45 <mfisch> thanks
15:13:55 <EmilienM> abramley: why not re-using ubuntu package names?
15:14:15 <EmilienM> mfisch: cool, sounds like a good approach.
15:14:44 <abramley> at the time I seem to remember it was a branding thing more than anything else
15:14:53 <EmilienM> #action mfish to create openstack_extras::repo::tesora
15:15:02 <EmilienM> mfisch: anything else?
15:15:09 <mfisch> thats it on that
15:15:09 <EmilienM> abramley: good, no problem
15:15:20 <mfisch> that action may take awhile btw just due to priorities
15:15:29 <EmilienM> #topic move some functions from puppet-openstacklib to puppetlabs-stdlib
15:15:43 <EmilienM> I've noticed some of our functions could be move to upstream puppet
15:15:49 <EmilienM> chem created one recently about ipv6
15:16:03 <EmilienM> Hunner, _ody: would it make sense to you?
15:16:10 <chem> normalize_ip_for_uri would be a good candidate
15:16:19 <EmilienM> for example https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/parser/functions/normalize_ip_for_uri.rb
15:16:36 <EmilienM> chem: we might need to support array too
15:16:51 <EmilienM> I've been playing with our CI to deploy IPv6 and I had to use it
15:17:05 <EmilienM> chem: can you engage the move maybe?
15:17:13 <chem> EmilienM:this is not a problem
15:17:33 <EmilienM> #action chem move normalize_ip_for_uri to puppetlabs-stdlib and support array
15:17:35 <EmilienM> chem: thx
15:17:38 <chem> EmilienM: Yep, will make the feature request on puppetlab side no problem
15:17:49 <EmilienM> nice, ping Hunner or _ody when done, so we can get it soon
15:17:52 <_ody> EmilienM: yeah.  Our functions are good and robust and obviously solve issues.
15:17:58 <chem> ack
15:18:16 <EmilienM> #topic release status
15:18:20 <EmilienM> so just some fyi :
15:18:35 <EmilienM> I'm working this week on Mitaka release notes for modules that will get release
15:18:46 <EmilienM> #link release doc https://docs.google.com/spreadsheets/d/1XVrmEiLrJSdxDo-S_vFB7ljxTdYg-pe8hiMUryRor5A/edit#gid=1966527233&vpid=A1
15:19:22 <EmilienM> Ubuntu confirmed they'll cut their stable release soon after the official release
15:20:04 <EmilienM> so, 8.0.0 (Mitaka) should be release almost in same time as other projects
15:20:25 <EmilienM> if you have anything you need in stable/mitaka before the cut, let us know
15:20:27 <_ody> Wow.  Like first time ever, isn't it?
15:20:41 <EmilienM> _ody: yeah, we're getting better
15:20:57 <_ody> Well packaging only started keeping up in the last couple cycles.
15:21:09 <EmilienM> our CI is robust enought to certify you can deploy Mitaka, so I don't see the need to wait more
15:21:34 <EmilienM> #action EmilienM to write release notes with reno for our modules
15:21:58 <EmilienM> just a reminder about reno, I'm not pushing people to write release notes when they send patches, but please do it if you like me
15:22:21 <EmilienM> during Newton cycle, we need to start to push people using it a little bit more
15:22:38 <EmilienM> so if you fix a bug, bring a feature, please add a release note, it takes 30 seconds.
15:22:46 <EmilienM> #link reno doc http://docs.openstack.org/developer/reno/usage.html
15:22:55 <EmilienM> any question / feedback about releases ?
15:23:21 <degorenko> EmilienM, we can add some check for this
15:23:32 <degorenko> so if we have patch and don't have updated notes -1 :D
15:23:35 <degorenko> for job
15:23:43 <EmilienM> that's tough
15:24:04 <degorenko> since newton i guess we can add (if need)
15:24:04 <EmilienM> I think we want to educate by gently asking people to do it, by showing the right example
15:24:19 <EmilienM> so if our core team follows this path
15:24:28 <EmilienM> I'm sure other will get educated over the time
15:24:44 <EmilienM> but I won't -1 someone who miss it
15:25:00 <degorenko> i like this way
15:25:21 <EmilienM> #topic Open Discussion, Bug and Review triage (submit modules to triage here)
15:25:38 <mwhahaha> don't forget to follow up with a ML email about reno for newton :)
15:25:46 <mwhahaha> cause i'm so going to forget
15:26:12 <degorenko> good point, to notify people via mail
15:26:13 <EmilienM> mwhahaha: right
15:26:26 <EmilienM> #action EmilienM to follow-up on ML about reno & releases
15:26:53 <EmilienM> degorenko: so let's start triage
15:26:57 <EmilienM> degorenko: puppet-heat?
15:27:00 <degorenko> yep
15:27:00 <degorenko> so
15:27:05 <degorenko> it's about version less
15:27:09 <degorenko> https://review.openstack.org/261326
15:27:09 <_ody> I've noticed recently that some failing CI patches have old tests gates assigned to them.  If you rebasse or ammend your commit, you'll get the newest set that are more likely to pass.
15:27:29 <degorenko> also we have one more patch from Gael
15:27:44 <degorenko> and it seems like we need to mix our patches into one
15:27:47 <skolekonov> Probably we should also think about moving heat to auth plugins?
15:28:17 <degorenko> we can try to do it, yes
15:28:26 <EmilienM> skolekonov: can it be done in a further iteration? or should it be done in the same patch?
15:28:43 <EmilienM> are the patches exclusive?
15:29:05 <skolekonov> We will need to deprecate identity_uri. So probably one patch makes sense
15:29:28 <EmilienM> ok
15:29:32 <EmilienM> degorenko: ok to change that?
15:29:33 <degorenko> my patch is for auth_uri and indentity but it won't work without a couple trustee params and client_uri
15:29:45 <degorenko> that is implemented by Gael patch
15:30:18 <degorenko> we with dmburmistrov tested it, it works when both patches is on repo
15:30:35 <EmilienM> do we need to stash both patches in one?
15:30:47 <degorenko> yes
15:31:01 <EmilienM> ping gael about it, and make sure you agree on that, but I don't see any problem
15:31:17 <EmilienM> if we need to stash, go ahead, and make it clear in commit message
15:31:34 <degorenko> ok, i will ping gael then
15:32:05 <EmilienM> mfisch: keystone hook
15:32:23 <EmilienM> I think your patch need further work, regarding degorenko's review
15:33:33 <degorenko> i also have one more request for review :) https://review.openstack.org/#/c/291709/
15:33:34 <mfisch> EmilienM: yep
15:33:40 <mfisch> EmilienM: I am going to look today
15:33:52 <EmilienM> iberezovskiy: excellent work on oslo
15:34:00 <EmilienM> the code LGTM, I'm waiting for CI
15:34:16 <EmilienM> I'm glad you're working on that, it was kind of staled lately
15:34:25 <iberezovskiy> EmilienM, as you can see I've also started to switch nova to it
15:34:45 <iberezovskiy> so, I wanna ask one thing, do we need to keep qpid https://github.com/openstack/puppet-nova/blob/master/manifests/init.pp#L616 ?
15:35:02 <EmilienM> AFIK qpid is dead in Oslo meesaging
15:35:07 <degorenko> yep
15:35:10 <degorenko> https://review.openstack.org/#/q/topic:deprecate_qpid
15:35:11 <EmilienM> mwhahaha: can you review https://review.openstack.org/#/c/292638/ please?
15:35:23 <degorenko> i'm done with deprecation it for liberty some time ago
15:35:26 <mwhahaha> sure
15:35:27 <EmilienM> iberezovskiy: so in a separated patch, we need to drop qpid everywhere
15:35:32 <degorenko> now it can be fully removed in mitaka i guess
15:35:38 <EmilienM> with parameter deprecation to keep our users happy
15:35:46 <dims> EmilienM : replaced with QPid/Proton + pyngus python library
15:36:24 <iberezovskiy> ok, it'll be a separate patch
15:36:27 <degorenko> dims, can you provide some docs for Proton?
15:36:37 <iberezovskiy> also I'll start working on other modules to switch to oslo
15:36:49 <EmilienM> degorenko: Qpid has been replaced by Proton + pyngus, right?
15:37:07 <degorenko> EmilienM, this question i guess is going to dims
15:37:11 <dims> degorenko http://docs.openstack.org/developer/oslo.messaging/AMQP1.0.html
15:37:46 <EmilienM> dims: ^ yeah sorry
15:38:37 <dims> y, we have a new driver
15:38:58 <degorenko> then we need not remove qpid in mitaka, but replace it on proton
15:39:09 <dims> degorenko : that's logical +1
15:39:19 <degorenko> iberezovskiy, ^^^
15:39:24 <EmilienM> ok, do we have people deploying proton?
15:39:57 <EmilienM> anyway, let's first move rabbimq code to puppet-oslo
15:39:58 <dims> EmilienM have to ask flaper87 and kgiusti
15:40:11 <EmilienM> and drop all old qpid stuff if needed
15:40:19 <EmilienM> we'll see for proton during newton cycle
15:40:35 <iberezovskiy> ok
15:40:51 <dims> EmilienM : makes sense
15:40:57 <degorenko> +1 for me
15:41:12 <flaper87> what did I do now?
15:41:15 <flaper87> :(
15:41:40 <EmilienM> flaper87: we were wondering about new amqp driver in oslo.messaging
15:41:41 <dims> flaper87 : are there folks deploying proton+pyngus+oslo.messaging
15:41:49 <flaper87> dims: yes
15:42:02 <flaper87> note that proton != qpid
15:42:02 <EmilienM> outside devstack? :-)
15:42:11 <flaper87> EmilienM: >.>
15:42:16 <flaper87> :P
15:42:24 <flaper87> Is there a problem?
15:42:24 <dims> lol
15:42:28 <flaper87> something I can help with?
15:42:39 <degorenko> do we have packages?
15:42:52 <EmilienM> it sounds something we need to investigate
15:42:55 <flaper87> degorenko: for proton? yes
15:43:06 <flaper87> There are packages for qpid-proton and pyngus
15:43:10 <flaper87> I'm not sure about debian, though
15:43:15 <flaper87> I think there are no for debian
15:43:20 <flaper87> but I know there's work in progress
15:43:26 <flaper87> perhaps zigo can help us out there
15:43:28 <degorenko> nice, then we need some investigation, yes, about using this
15:43:35 <EmilienM> cool
15:43:39 <flaper87> and there's work on puppet manifests for it
15:43:46 <EmilienM> flaper87: where?
15:43:49 <flaper87> I can point you to the folks working on that
15:43:51 <degorenko> O_o
15:44:02 <flaper87> It's in progress, fwiw
15:44:14 <EmilienM> we haven't seen any Puppet work related on that
15:44:15 <flaper87> I don't have other details as of now
15:44:29 <EmilienM> except if people commit on their own github
15:44:30 <degorenko> may be they have some separate repo for this?
15:44:31 <flaper87> EmilienM: it's not ready/upstream yet but it's in progress AFAICT
15:44:35 <EmilienM> :(
15:44:37 <flaper87> no no
15:44:39 <flaper87> wait, stop
15:44:42 <flaper87> don't freak out
15:44:43 <degorenko> :D
15:44:44 <flaper87> jeeez
15:44:44 <EmilienM> it would be great if people would commit upstream, even WIP
15:44:53 <degorenko> agree ^
15:44:54 <flaper87> There's people *working* on it as of like 2 or 3 weeks ago
15:45:00 <EmilienM> at least for keeping open design & discssuon
15:45:17 <EmilienM> release early, release often
15:45:23 <flaper87> EmilienM: these are folks not working on open stack full time. Bare with me while I help them go upstream
15:45:28 <EmilienM> I put all my WIP in Gerrit so people can look at it
15:45:34 <flaper87> openstack*
15:45:42 <EmilienM> cool
15:45:52 <degorenko> probably we can ask them to upload wip review
15:45:53 <EmilienM> tell them to commit on Gerrit so at least we know they're on it
15:46:19 <EmilienM> flaper87: take my hat. What would you do if you see parallel and private efforts to improve puppet modules?
15:46:49 <EmilienM> anyway, I'm looking forward to seeing their work, ASAP
15:46:58 <flaper87> EmilienM: I'm not saying you're wrong. I'm just providing you info based on what I know
15:47:03 <EmilienM> do we have outstanding bugs or reviews for today?
15:47:38 <flaper87> It's better to assume good faith. They are not working on this privately because they are afraid of reviews
15:47:50 <EmilienM> flaper87: thank you for letting us know this information, and thank you for pushing them to contribute upstream
15:48:11 <degorenko> they should not afraid us :)
15:48:33 <dims> AFAICT we don't bite...right? :)
15:48:40 <flaper87> degorenko: they are not, trust me!
15:48:42 <EmilienM> how can you be afraid of a puppy https://c1.staticflickr.com/5/4112/5170590074_714d36db83_b.jpg
15:48:55 <dims> awww
15:49:03 <degorenko> :D
15:49:16 <EmilienM> ok, I'll let open discussion for 1 min and close the meeting, if nothing comes up
15:49:32 <EmilienM> I love puppies
15:49:46 <EmilienM> if I had a house, I would buy dogs
15:50:11 <EmilienM> have a good week everyone
15:50:16 <EmilienM> #endmeeting