15:00:01 <EmilienM> #startmeeting puppet-openstack
15:00:02 <openstack> Meeting started Tue Sep 29 15:00:01 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:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:05 <openstack> The meeting name has been set to 'puppet_openstack'
15:00:06 <EmilienM> #link meeting agenda: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150929
15:00:10 <EmilienM> o/
15:00:19 <xarses> o/
15:00:20 <degorenko> hi o/
15:00:23 <aderyugin> o/
15:00:33 <IBerezovskiy> o/
15:00:34 <crinkle> o/
15:00:42 <iurygregory> hi o/
15:00:50 <mfisch> yo
15:00:52 <sbadia> hello
15:01:03 <sbog> hi
15:01:18 <mwhahaha> hi
15:01:31 <skolekonov> hi
15:01:35 <EmilienM> #topic review past actions items
15:01:55 <EmilienM> "EmilienM send proposal to ML about neutron plugin mngt" > done - we have a topic later for that
15:01:57 <richm> hello
15:02:10 <EmilienM> "chem to propose PoC on top of gilles's patch" > ?
15:02:40 <EmilienM> _ody to propose another default pattern solution > done - we have a topic later for that too
15:03:18 <EmilienM> chem: ?
15:03:31 <chem> EmilienM: 2s I find the link
15:03:40 <chem> EmilienM: this is this https://review.openstack.org/#/c/226919/
15:03:51 <mattymo_> hi all
15:03:53 <_ody> o/
15:04:18 <EmilienM> chem: the patch isn't on top of any other patch, isn't?
15:04:37 <chem> EmilienM: no, it has been found with gilles that no other patch was required
15:04:40 <EmilienM> chem: do you still have any blocker?
15:05:13 <chem> EmilienM: yep, I still have to find why my beaker test are not run ... it's like insane ...
15:05:31 <EmilienM> we can talk about it in open discussion if timing allows it.
15:05:37 <EmilienM> let's move on to the agenda
15:05:40 <chem> EmilienM: I commenting the file by half each time to find the culprint and run beaker
15:06:00 <EmilienM> #topic review use zuul-cloner to prepare fixtures
15:06:02 <angdraug> EmilienM: default pattern?
15:06:02 <chem> EmilienM: really no need, the blocker is an obvious thing that I cannot point my finger on
15:06:13 <EmilienM> #link https://review.openstack.org/#/c/226830/
15:06:41 <EmilienM> except a few, we haven't got much feedback on this patch
15:07:06 <EmilienM> I would like feedback from nibalize (not here atm), Hunner, _ody, crinkle
15:07:43 <EmilienM> the code is ready for review. Is anyone against this proposal?
15:09:21 <EmilienM> well, if not, I guess we can co ahead with the patch.
15:09:43 <EmilienM> #action core team to merge https://review.openstack.org/#/c/226830/
15:09:46 <crinkle> I'm looking at the thread about this, I'm not convinced by the proposed solution to alex's issue
15:09:52 <EmilienM> ah
15:09:57 <crinkle> editing the puppetfile isn't the same as editing fixtures.yml
15:09:58 <EmilienM> #undo
15:09:59 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x9395bd0>
15:10:15 <crinkle> in fixtures.yml you can add a symlink to a local copy, that's not something the puppetfile can support
15:10:16 <nibalizer> o/
15:10:22 <EmilienM> crinkle: I haven't read you on Gerrit before :(
15:10:33 <crinkle> EmilienM: sorry, just catching up
15:10:43 <mwhahaha> does r10k not support a local file git ref?
15:11:06 <EmilienM> nibalizer: we're talking about https://review.openstack.org/#/c/226830/
15:11:31 <crinkle> mwhahaha: i suppose it might
15:11:57 <mwhahaha> i like using symlinks w/ .fixtures.yml but that's usually a local dev thing
15:12:40 <EmilienM> crinkle: what do you suggest?
15:12:42 <nibalizer> the goal here is to get depends-on working or something else?
15:12:47 <crinkle> using a local file git ref is probably sufficient, i withdraw my concern
15:12:54 <EmilienM> nibalizer: I sent a thread.
15:13:01 <crinkle> nibalizer: yes but for unit tests this time
15:13:02 <EmilienM> let me find it
15:13:24 <EmilienM> nibalizer: https://openstack.nimeyo.com/59931/openstack-dev-puppet-use-zuul-cloner-when-running-rspec
15:15:05 <EmilienM> nibalizer: not only depends-on
15:15:10 <EmilienM> but also consistent in what we test
15:15:22 <EmilienM> I found out some modules were testing a different version of a dependency
15:15:26 <EmilienM> which is not really what we want
15:15:50 <EmilienM> using the same Puppetfile for unit testing, beaker & integration CI would be good imho
15:16:41 <EmilienM> nibalizer: thoughts?
15:17:14 <nibalizer> i dont really have time at the moment to gice an opinion
15:17:16 <nibalizer> sorry
15:17:20 <EmilienM> :(
15:17:47 <EmilienM> crinkle: any proposal? suggestion?
15:18:02 <crinkle> EmilienM: let's move forward with it and review the patch
15:18:11 <EmilienM> mhh ok
15:18:30 <EmilienM> #action puppet team to review https://review.openstack.org/#/c/226830/
15:18:40 <EmilienM> I hope we can make progress on it
15:18:55 <EmilienM> #topic re- default value parameter
15:19:06 <EmilienM> _ody, spredzy: o/
15:19:20 <_ody> o.O
15:19:23 <EmilienM> _ody: can you post your patches?
15:19:41 <_ody> #link https://review.openstack.org/#/c/228670/
15:19:56 <_ody> #link https://review.openstack.org/#/c/228662/
15:20:22 <EmilienM> ok, unit tests are failing because previous topic
15:20:38 <_ody> Correct, plus one other thing.
15:20:49 <_ody> But i know what it is, I put a fail in a could defined on purpose.
15:20:52 <EmilienM> I would like to run a vote for the default pattern proposals
15:20:58 <EmilienM> if we summarize them we have:
15:21:06 <_ody> That is what i think people should go evaluate.  Go look at the defines.
15:21:22 <EmilienM> mwhahaha: proposal #1 - use a Puppet function
15:21:48 * EmilienM looks for links...
15:22:17 <EmilienM> #link https://review.openstack.org/#/c/224277/
15:22:38 <EmilienM> proposal #1 would set default params to service_default() function
15:22:43 <EmilienM> the function is in openstacklib
15:22:46 <mwhahaha> https://review.openstack.org/#/c/224187/
15:22:51 <mwhahaha> ^- functionm
15:23:17 <EmilienM> proposal #2 is _ody's one, with ::openstacklib::params https://review.openstack.org/#/c/228662/
15:24:00 <EmilienM> in proposal #2, all <module>::params would inherits from openstacklib::params
15:24:34 <EmilienM> benefit of proposal #2 is using $servicedefault instead of hardcoding <SERVICE DEFAULT>
15:25:06 <mwhahaha> and it's overridable per module right?
15:25:19 <_ody> correct
15:25:24 <EmilienM> both proposals address what we need
15:25:37 <iurygregory> we will vote?
15:25:41 <EmilienM> but #1 is something kind of new in a Puppet module, so we don't really know the downsides
15:25:41 <mwhahaha> I also threw out using a fact (not a static fact from facts.d, just a regular one) in openstacklib
15:25:48 <mwhahaha> not sure if you wanted to include that
15:25:56 <EmilienM> iurygregory: we're discussing now
15:26:19 <iurygregory> i like both the ideas =)
15:26:22 <EmilienM> it's sounds overkill to add a fact for this, isn't?
15:26:40 <mwhahaha> it reduces the overhead of the inheritance stuff
15:26:43 <mwhahaha> it's a mix of both
15:26:43 <_ody> mwhahaha's idea makes the defined type issue easier.
15:27:10 <EmilienM> _ody: can you explain?
15:28:10 <_ody> EmilienM: You can not inherit a params class in a define so if you want the servicedefault params pattern...base classes MUST be delcared before using defines.
15:28:33 <EmilienM> good point
15:28:43 <_ody> So, in the example, cinder MUST be defined before using the backend defines.
15:29:01 <EmilienM> ::cinder ?
15:29:05 <_ody> I am good with a fact if it is facts.d and static.
15:29:09 <_ody> EmilienM: Correct.
15:29:42 <EmilienM> I think everyone using providers deploy ::<module> class in their manifest, but I might be wrong.
15:29:45 <_ody> shipping a whole ruby fact I agree would be overkill.
15:29:58 <mwhahaha> I think it would be a problem for fuel
15:30:05 <mwhahaha> we may not always include the base class
15:30:16 <mwhahaha> i'd have to double check everywhere
15:30:24 <angdraug> mwhahaha: you're right we don't
15:30:26 <_ody> mwhahaha: I doesn't HAVE to be the base class...really.
15:30:35 <mwhahaha> yea just the params class right?
15:30:40 <_ody> It just needs to be one that include ::cinder::params.
15:30:45 <angdraug> but we probably include params everywhere
15:30:49 <_ody> That is actually the important part.
15:31:05 <_ody> I just chose cinder because it seem the most likely to be included.
15:31:11 <EmilienM> I think we can include params in defines
15:31:19 <mwhahaha> you have to include it before
15:31:21 <mwhahaha> i think
15:31:38 <mwhahaha> not sure processing order of params before the includes within a define?
15:32:14 <_ody> EmilienM: We can but it must be before so the variable exists before define parameters are parsed.
15:32:24 <EmilienM> if it's up to the composition layer, then we have a problem
15:32:43 <EmilienM> ie: if fuel has to change their manifests - we probably have other people who would have to do the same
15:32:44 <_ody> EmilienM: For defines, likely yes.
15:32:57 <EmilienM> mhh, it's not the best solution then.
15:32:59 <_ody> Can't get around it with a define.
15:33:20 <mwhahaha> i think a fact might be the best middle ground, we lose per-module overrides though
15:33:34 <_ody> mwhahaha: We shouldn't
15:33:36 <EmilienM> do we have a PoC of the fact solution?
15:33:43 <_ody> Oh no, you're right we do
15:33:57 <mwhahaha> no, but i could put one together for the next meeting
15:34:08 <mwhahaha> if we want to move on and come back to this next week
15:34:09 <EmilienM> mwhahaha: that would be great.
15:34:34 <EmilienM> I would like to move out _ody's proposal for now, because it's not backward compatible - and require some actions from people using our Defines.
15:34:39 <EmilienM> do we agree on that ? ^^^^^
15:35:26 <EmilienM> our solution would be between service_default() function or a fact
15:35:29 <_ody> Yeah. I'll look to see if there is another way and wait on mwhahaha's fact.
15:35:37 <EmilienM> cool
15:36:02 <EmilienM> #action mwhahaha provides (another) POC for service default parameter (using a fact)
15:36:09 <EmilienM> mwhahaha: thank you
15:36:24 <EmilienM> let's move on
15:36:39 <EmilienM> any thoughts are welcome to the ML thread by the way ^
15:36:45 <EmilienM> #topic puppet-openstack retirement
15:36:55 <EmilienM> so we have two options iiuc
15:38:09 <richm> a gold watch or an amazon gift cert?
15:38:21 <EmilienM> 1/ retire the repo (read only and committing a change to replace all the files with a README)
15:38:36 <EmilienM> 2/ move it to openstack and continue the developpement
15:38:58 <EmilienM> the module is deprecated since Juno
15:39:54 <EmilienM> #startvote Should we retire puppet-openstack module? yes, no, maybe
15:39:55 <openstack> Begin voting on: Should we retire puppet-openstack module? Valid vote options are yes, no, maybe.
15:39:56 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
15:40:07 <EmilienM> #vote yes
15:40:09 <_ody> #vote yes
15:40:22 <chem> #vote yes
15:40:24 <degorenko> #vote yes
15:40:25 <iurygregory> #vote yes
15:40:27 <aderyugin> #vote yes
15:40:31 <dmsimard> #yes
15:40:33 <sbadia> #vote yes
15:40:35 <dmsimard> #fail
15:40:37 <dmsimard> #vote yes
15:40:43 <crinkle> #vote yes
15:40:47 <mwhahaha> #vote yes
15:41:05 <EmilienM> 10 seconds more
15:41:19 <skolekonov> #vote yes
15:41:22 <EmilienM> #endvote
15:41:23 <openstack> Voted on "Should we retire puppet-openstack module?" Results are
15:41:24 <openstack> yes (11): aderyugin, skolekonov, mwhahaha, _ody, dmsimard, sbadia, iurygregory, crinkle, EmilienM, degorenko, chem
15:41:43 <EmilienM> #action emilien to update Wiki page to retire puppet-openstack
15:42:08 <EmilienM> thanks for voting, it's important to make sure we agree on that.
15:42:17 <EmilienM> I'll also make sure to communicate over the ML about it
15:42:25 <EmilienM> #topic puppet-ceph future
15:42:28 <EmilienM> dmsimard: o/
15:42:34 <dmsimard> oi
15:42:35 <EmilienM> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/075631.html
15:42:40 <iurygregory> oi? O.o
15:42:49 <dmsimard> It's like a "hi" but with an accent
15:42:52 <dmsimard> :)
15:42:57 <iurygregory> br =D
15:43:01 <EmilienM> we're running out of time
15:43:04 <EmilienM> let's move on please ;)
15:43:20 <EmilienM> we need to agree if we move stackforge/puppet-ceph to openstack or not.
15:43:40 <EmilienM> Bonus question: should it also move under Puppet OpenStack project (big tent)
15:43:42 <dmsimard> There hasn't been a lot of feedback from the community on that topic, would love if you can share your thoughts on the mailing list so it doesn't look like we've made a decision without asking anyone about it
15:44:20 <dmsimard> The puppet-ceph cores have all voted in favor of moving to /openstack, it isn't clear yet if we'll stay standalone or join the puppet openstack project
15:44:42 <EmilienM> AFIK, stackforge/puppet-ceph is 1/ the only one community module to deploy Ceph with Puppet - 2/ is considered official by Ceph project (see mirror on ceph namespace)
15:44:44 <EmilienM> dmsimard: right ? ^
15:45:07 <dmsimard> From what hogepodge told me, puppet-ceph could potentially move to /openstack without being part of puppet-openstack and thus not requiring the CLA to contribute to which is an asset for this particular module
15:45:16 <EmilienM> dmsimard: right.
15:45:19 <dmsimard> EmilienM: Yes
15:45:47 <EmilienM> moving to openstack/ namespace does not mean "you are in OpenStack big tent" anymore.
15:46:15 <EmilienM> dmsimard: in short term, I suggest you take care of the move from stackforge to openstack
15:46:34 <dmsimard> Speaking from a community perspective, I'm convinced it's important for puppet-ceph to stay as opened as possible to contributors (see: without CLA, owned by the community)
15:46:52 <EmilienM> in long term, I would like to see a concensus between stackforge/puppet-ceph & OpenStack community to see if we move it or not under the big tent. If yes, moving under Puppet OpenStack project or not.
15:46:56 <dmsimard> I'm obviously biased towards making it a part of puppet-openstack but I don't think that's the right thing to do, at least in the short term
15:47:10 <EmilienM> good
15:47:16 <dmsimard> EmilienM: I think that's a good option. Moving it to /openstack first and see what happens later.
15:47:40 <EmilienM> #action dmsimard move stackforge/puppet-ceph to openstack/
15:47:43 <EmilienM> dmsimard: thx
15:47:44 <EmilienM> next
15:47:55 <EmilienM> #topic should puppet-neutron manage third party software
15:48:00 <EmilienM> I ran a thread about it
15:48:17 <EmilienM> not sure we need to discuss it over here, except if there is concerns
15:48:31 <EmilienM> if you have concerns go ahead now, otherwise we follow-up on ML
15:49:39 <EmilienM> #action emilien to follow-up neutron plugins third party software management thread on ML
15:49:45 <EmilienM> #topic use openstackclient for nova auth
15:49:49 <EmilienM> degorenko: hey
15:49:54 <degorenko> EmilienM, hey o/
15:49:56 <EmilienM> #link https://review.openstack.org/#/c/226862/
15:50:00 <degorenko> so, i'm working on a new auth for nova providers, based on openstacklib and openstack client
15:50:05 <degorenko> now it uses auth_nova based on nova client and also nova-manage without auth
15:50:11 <degorenko> and problem that is openstack client doesnt support managing networks for nova-network
15:50:17 <degorenko> only for neutron
15:50:22 <EmilienM> hum.
15:50:23 <degorenko> so, i want to know how we can have deal with this problem
15:50:29 <degorenko> i have a couple of solutions
15:50:35 <degorenko> first, we can use old way with using nova-manage cli command
15:50:42 <EmilienM> I'm aware nova network is still in use
15:50:44 <degorenko> second, we can drop posibility to manage networks by nova provider
15:50:48 <EmilienM> the question is: when is it deprecated?
15:51:02 <degorenko> EmilienM, yes, as i know since kilo?
15:51:23 <EmilienM> can you deploy OpenStack without Neutron in Liberty?
15:51:51 <EmilienM> I think proposal #1 is enough for the few people using our modules to deploy nova-network
15:51:51 <degorenko> hmm, never didn't tried
15:52:10 <degorenko> yes, i vote for #1 too
15:52:16 <EmilienM> so much efforts for that... I'm not sure it's worth it
15:52:32 <degorenko> actually, it's also old way :)
15:52:50 <degorenko> it was changed to nova sometime ago
15:53:02 <EmilienM> degorenko: so your patch is doing #1 ?
15:53:29 <degorenko> EmilienM, right now - patch with nova_networks with openstack client - and it doesn't work
15:53:36 <degorenko> but it works with nova-manage
15:53:53 <EmilienM> looking at http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up
15:54:08 <EmilienM> nova-network is still here.
15:54:22 <degorenko> yes, we can use nova-manage for creating nova-networks
15:54:30 <degorenko> only one problem - no any auth
15:54:38 <EmilienM> degorenko: yeah, using DB, right?
15:54:44 <degorenko> exactly
15:54:48 <EmilienM> old way :)
15:54:54 <angdraug> EmilienM: this reminds me of an old thread where xarses asked about supporting previous openstack releases
15:54:56 <degorenko> like it done right now for aggregates and cells
15:55:02 <degorenko> and others :)
15:55:09 <EmilienM> angdraug: it was not exactly about it
15:55:16 <angdraug> are you suggesting we support pre-liberty releases?
15:55:22 <EmilienM> angdraug: it was "supporting multiple releases in one puppet module release"
15:55:23 <crinkle> does the current nova_network provider work?
15:55:31 <degorenko> crinkle, yep
15:55:38 <degorenko> crinkle, now it uses nova auth
15:55:40 <angdraug> well next release of puppet-openstack will support liberty
15:55:59 <angdraug> if liberty doesn't support nova-networks, the only relevant use case is kilo and earlier
15:56:15 <EmilienM> angdraug: http://lists.openstack.org/pipermail/openstack-dev/2015-July/069147.html
15:56:27 <degorenko> and i'm not sure, that openstack client will be have possibility to manage nova networks :(
15:56:37 <richm> it doesn't
15:56:39 <crinkle> why not just leave it alone? it might be going away soon and openstackclient is probably not going to add support for it
15:56:41 <EmilienM> so why do you need to patch it if it works?
15:56:46 <richm> openstack network list et. al. use neutron
15:56:47 <EmilienM> crinkle++
15:56:54 <degorenko> crinkle, because it uses now old way with nova client auth
15:57:29 <EmilienM> degorenko: do anyone needs this feature?
15:57:40 <degorenko> EmilienM, openstack client auth for nova?
15:57:49 <EmilienM> for networks*
15:58:04 <EmilienM> we have 2 min left
15:58:06 <degorenko> i'm not sure :) just security question may be :)
15:58:12 <EmilienM> degorenko: let's followup after the meeting on the channel
15:58:15 <EmilienM> ok?
15:58:17 <crinkle> i don't see a reason to put a lot of effort into moving it away from nova client
15:58:23 <degorenko> EmilienM,  yeah, ok :)
15:58:24 <EmilienM> +1
15:58:45 <EmilienM> crinkle is right, I'm not sure neither
15:58:52 <EmilienM> #topic debian package support
15:58:55 <EmilienM> mwhahaha: what's up?
15:58:58 <mwhahaha> we're looking to leverage the debian packages and they have different names/script locations
15:59:19 <mwhahaha> so rather than fork and change the ubuntu stuff, would it be beneficial to propose debian support?
15:59:34 <EmilienM> afik, there are already community efforts for packaging
15:59:48 <EmilienM> zigo & number 80 are (DEB & RPM) PTLs afik
16:00:01 <mwhahaha> yea we're just running into package names
16:00:04 <EmilienM> we should coordinate together maybe
16:00:06 <crinkle> yes please fix the debian support
16:00:08 <mwhahaha> k
16:00:12 <crinkle> should just be enough to fix params.pp
16:00:25 <mwhahaha> it shouldn't be too bad, but just want to make people aware
16:00:27 <EmilienM> let's close the meeting and follow up on our channel
16:00:30 <EmilienM> sorry guys
16:00:34 <EmilienM> end of time
16:00:39 <EmilienM> #endmeeting