15:00:06 <EmilienM> #startmeeting puppet-openstack
15:00:07 <openstack> Meeting started Tue Sep 22 15:00:06 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:12 <sbadia> hey!
15:00:19 <iurygregory> o/
15:00:22 <maximov> hi
15:00:24 <EmilienM> #link agenda https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150922
15:00:27 <crinkle> o/
15:00:30 <_ody_> o/
15:00:31 <EmilienM> hello here
15:00:36 <degorenko> hey o/
15:00:41 <mwhahaha> hey
15:00:43 <mdorman> o/
15:01:17 <skolekonov> hi
15:01:23 <angdraug> \o
15:01:40 <richm> hello
15:01:51 <EmilienM> #topic Release schedule
15:02:03 <EmilienM> there is no schedule yet, so we are kind of free
15:02:30 <EmilienM> I would propose to wait for stable packages on both ubuntu/uca & centos/rdo
15:02:39 <sbadia> +1
15:02:43 <EmilienM> and then think about stable/liberty
15:02:56 <iurygregory> +1
15:03:01 <EmilienM> I think it would let us ~one month or so
15:03:22 <_ody_> +1
15:03:39 <EmilienM> please make sure stable/kilo & stable/juno have useful backports
15:04:49 <EmilienM> #link releases https://wiki.openstack.org/wiki/Puppet/releases
15:05:20 <EmilienM> #topic Summit
15:05:29 <EmilienM> #link summit etherpad https://etherpad.openstack.org/p/HND-puppet
15:05:47 <EmilienM> I hope our group will submit more topics
15:05:54 <EmilienM> for now, only spredzy and I did
15:06:31 <EmilienM> don't be shy :) and bring your ideas
15:07:21 <EmilienM> we need topics to define what's next, I hope people will contribute to the etherpad during the following days
15:08:08 <EmilienM> #topic service_default() and is_service_default() usage
15:08:21 <EmilienM> mwhahaha: hello
15:08:24 <mwhahaha> hey
15:09:02 * EmilienM looking for links
15:09:02 <mwhahaha> so last week we talked about the best way to check for the '<SERVICE DEFAULT>' strings and I proposed a function to check for it
15:09:05 <mwhahaha> #link https://review.openstack.org/#/c/223672/
15:09:29 <EmilienM> I liked Hunner & _ody_ feedbacks
15:09:33 <mwhahaha> when doing this, I also thought about the other side where we could use a function in place of '<SERVICE DEFAULT>'
15:09:35 <mwhahaha> #link https://review.openstack.org/#/c/224187/
15:09:57 <EmilienM> _ody_: can you summarize it again please?
15:10:30 <_ody_> I was a solid +0 on it until EmilienM sparked me to look at it again yesterday, then I transitioned into a -1.
15:10:58 <mwhahaha> for which? for both?
15:11:07 <_ody_> Yeah.
15:11:08 <_ody_> It might be a little easier on the eyes but not nearly as obvious to people reading the manifest for the first or even second time and I don't think it actually solves a problem.  Plus it has to run code to return a string, which is going to have overhead over parsing a simple string.  To obtain the same goal of abstracting the value away from the implementation, the params pattern has been use
15:11:15 <_ody_> d for that until now.
15:11:16 <EmilienM> _ody_: I don't see your review on Gerrit :(
15:11:34 <_ody_> EmilienM: I didn't submit it because it was long winded...I actually just pated it into IRC.
15:11:53 <_ody_> We could set a "default" string across all our modules by having a "openstacklib::params::servicedefault" variable and inherit "openstacklib::params" is every params class, e.g. "nova::params inherits openstacklib::params".
15:12:10 <_ody_> I am just generally not a fan of having ruby do work the puppet language can "generally" do.
15:12:18 <angdraug> premature optimization is root of all evil
15:12:38 <mwhahaha> fair enough, i think i had mentioned switching to the params as an alternative
15:12:42 <mwhahaha> in irc
15:13:18 <EmilienM> I would like to see an example of _ody_'s proposal with openstacklib::params::servicedefault
15:13:32 <_ody_> Sure.
15:13:45 <mwhahaha> so i think the is_service_default is still valid
15:13:49 <EmilienM> we all agree we want this feature
15:13:55 <EmilienM> we just don't know yet how to make it
15:13:56 <mwhahaha> but service_default is not the best way
15:14:34 <_ody_> mwhahaha: I am no sure.  That unsubmitted review I just pasted was the review I had prepared for service_default.
15:14:45 <EmilienM> mwhahaha: for now, yes, becayse you rely on SERVICE_DEFAULT pattern
15:14:52 <_ody_> I was kinda treating them the same but I'll leave that for after I try out a few other options.
15:15:09 <mwhahaha> for me is_service_default is like a stdlib function such as validate_string()
15:15:16 <mwhahaha> that is not a weird pattern
15:15:23 <EmilienM> mwhahaha: does it work for you, if we wait for _ody_'s proposal and see how it behaves?
15:15:37 <_ody_> mwhahaha: Ok.  I'll read through that one again.
15:15:38 <mwhahaha> the using service_default() as a param is odd, so i can see that not being so great
15:15:44 <crinkle> I think we should get the original plan, which just uses the string, in place and working and then we can optimize/clean up later
15:16:56 <EmilienM> crinkle: yeah, we could convert puppet-cinder (the module where we initiated the work) and see how it works. Later optimize/stabilize and then convert all modules once we have final design
15:17:39 <EmilienM> mwhahaha: yes, your function seems still valid if we go that way
15:17:45 <_ody_> I find running ruby to return a static to be my issue.  We've ween expirementing with puppetdbquery functions as parameter defaults lately.
15:18:02 <mwhahaha> I'm ok abandoning the service_default() function
15:18:14 <mwhahaha> i would like to keep is_service_default()
15:18:20 <EmilienM> mwhahaha: don't abandon it, it's too early I think
15:18:27 <EmilienM> yes, we might need to keep it
15:18:34 <EmilienM> the is_service_default
15:18:41 <mwhahaha> k
15:18:42 <_ody_> yeah.  Please no abandoning things yet.
15:19:25 <EmilienM> #action _ody_ to propose another default pattern solution (in puppet-openstacklib)
15:20:02 <EmilienM> _ody_: once you have something please use the ML thread, so we can move forward
15:20:57 <EmilienM> mwhahaha, spredzy: maybe we can start converting puppet-cinder to use is_service_default and see how it behaves
15:21:08 <EmilienM> do you like the plan? or?
15:21:41 <mwhahaha> we've got that one review that has been converted but fails CI because we haven't merged is_service_default yet
15:22:45 <EmilienM> unfortunatly, our CI does not handle Zuul cloner for unit tests
15:22:52 <_ody_> EmilienM: Yep will do after breakfast.
15:22:55 <EmilienM> but anyoen is free to make it happen
15:23:18 <mwhahaha> https://review.openstack.org/#/c/219275/
15:23:24 <EmilienM> crinkle wrote the tool in puppet-openstack-integration for beaker jobs
15:23:27 <EmilienM> we could re-use it
15:23:57 <EmilienM> this is a separated topic, but if anyone is interested to work on it, raise your hand
15:24:21 <EmilienM> mwhahaha: I think we can merge your function is openstacklib in the meantime
15:24:35 <EmilienM> mwhahaha: you don't break anything, and if we decide to go back, we can revert your patch
15:24:41 <mwhahaha> k
15:24:43 <_ody_> Yep.
15:24:50 <EmilienM> +2 +A
15:25:14 <EmilienM> mwhahaha: so in a few, you'll be able to do the recheck on the cinder patch and see unit test behavior
15:25:19 <mwhahaha> k
15:25:25 <EmilienM> mwhahaha: thanks
15:25:44 <EmilienM> spredzy is afk but I'll check with him if you guys are willing to use puppet-cinder to test the feature
15:26:13 <EmilienM> anything else about this topic?
15:26:54 <mwhahaha> doesn't look like it
15:26:57 <EmilienM> mwhahaha: maybe you can WIP https://review.openstack.org/#/c/224187 to avoid accidental merge
15:27:02 <mwhahaha> sure
15:27:15 <EmilienM> #topic Rewrite puppet-nova providers based on Openstacklib and Openstack client
15:27:22 <EmilienM> degorenko, sbog: o/
15:27:27 <degorenko> EmilienM, hey o/
15:27:34 <sbog> hi
15:27:36 <degorenko> my suggestion is to rewrite nova resource/providers authorization based on Openstacklib and openstack client
15:27:42 <degorenko> like it done for keystone
15:27:48 <degorenko> also adapt current providers and add some new providers (flavors, secgroups, e.g)
15:27:52 <degorenko> what do you think?
15:28:07 <EmilienM> well, this is where we try to go in keystone, glance & neutron so yeah nova makes sense
15:28:18 <degorenko> great
15:28:24 <degorenko> i've found next blueprint: #link https://blueprints.launchpad.net/puppet-openstacklib/+spec/use-openstackclient-in-module-resources
15:28:27 <EmilienM> until now, nobody had time to make it so we're happy if anyone can make it
15:28:34 <degorenko> can i use it?
15:28:35 <crinkle> just need to make sure openstackclient has support for what we're doing in those providers
15:28:43 <degorenko> of course
15:28:45 <_ody_> If someone is ready to put in the effort, it only seems natural.
15:28:46 <EmilienM> yeah, we need feature parity at least
15:28:46 <sbog> I think it would be nice. I have done such work for old openstack client, but it unusable now.
15:29:05 <EmilienM> awesome!
15:29:15 <degorenko> Btw, all modules depend on openstacklib, so, we can use one common way for authorization
15:29:21 <EmilienM> degorenko: look at puppet-glance, the implementation is pretty stable now
15:29:38 <degorenko> yep, i will look
15:29:45 <EmilienM> the Glance_image resource is a good example
15:30:09 <degorenko> probably we need use this for all modules?
15:30:09 <EmilienM> degorenko, sbog: anything else about this topic?
15:30:19 <EmilienM> this ?
15:30:20 <sbog> I think that's all
15:30:29 <degorenko> this feature :)
15:30:36 <degorenko> i mean auth via openstack client
15:30:38 <EmilienM> it's a "nice to have"
15:30:46 <EmilienM> since osclient is being the reference
15:30:57 <degorenko> ok, got it
15:31:01 <EmilienM> and since we decided to rely on osclient for our providers, yeah
15:31:21 <degorenko> we can discuss in summit this topic
15:31:36 <EmilienM> degorenko: cool, feel free to adjust etherpad
15:31:44 <EmilienM> #topic Keystone v3 - implement providers using composite namevar
15:31:45 <degorenko> great! i'll add a new topic
15:31:47 <EmilienM> chem: o/
15:31:55 <richm> yes, chem
15:32:03 <chem> yep ?
15:32:10 <chem> ah
15:32:18 <richm> so chem has figured out that you have to use isnamevar with _properties_, not _parameters_
15:32:24 * EmilienM wakes up chem
15:32:40 <_ody_> Ugh...yeah parameters are not syncable.
15:32:44 <richm> the puppet docs say that "properties" are the actual properties of the actual object being modeled
15:32:56 <_ody_> I mean other way around.
15:33:07 <richm> while parameters are just things passed from manifests into the provider code
15:33:23 <chem> running the spec using newparam make them fail
15:33:32 <richm> chem: how so?
15:33:45 <chem> didn't dig into it, but it falis
15:33:58 <chem> means you have to change some other code
15:34:01 <_ody_> I am happy to take a crack at it.
15:34:09 <richm> ok - so we still need to investigate this approach some more to see if it is viable
15:34:42 <chem> well I could finish the job to see what is failing
15:34:44 <richm> My suspicion is that it is not viable - if we have to use parameters instead of properties, that means that somewhere, somehow, puppet is not going to like it and barf
15:35:05 <richm> but, let's investigate some more
15:35:15 <chem> parameter == stuff that puppet cannot guess from the environment
15:35:29 <richm> or from the object being modeled
15:35:50 <chem> hum, oki.
15:35:54 <richm> chem: Can you investigate some more and follow up/reply to your email to the os-dev list?
15:36:15 <chem> oki, I look why it's failing and post the result
15:36:19 <richm> chem: Thanks
15:36:32 <chem> richm: np
15:37:04 <_ody> If someone has a link to a branch, I'll also hack on it.
15:37:12 * _ody didn't see one in the thread
15:37:26 <chem> _ody: no branch, just local modification
15:38:08 <chem> _ody: it was just exploration ... I may be able to make a gerrit review in wip that I'll destroy later no ?
15:38:27 <chem> is it something that people do ?
15:38:36 <EmilienM> I think the sooner you release your patch, the better it is
15:38:40 <EmilienM> all the time
15:38:55 <EmilienM> using Gerrit enforces collaboration, don't keep your code locally
15:39:32 <chem> but is it in merge conflit with what gilhub is working on ?
15:39:50 <chem> sorry : "isn't it"
15:40:05 <EmilienM> you can do Gerrit dependencies or patchs on top of master, whatever
15:40:24 <chem> EmilienM: oki
15:40:29 <richm> right - just rebase your patch on top of whatever you want as you base
15:40:29 <EmilienM> chem: you can do a PoC on top of his patch
15:40:46 <chem> EmilienM: richm: I'll do that
15:40:53 <richm> chem: Thanks!
15:41:13 <EmilienM> #action chem to propose PoC on top of gilles's patch
15:41:19 <EmilienM> thanks, anything else chem ?
15:41:29 <chem> EmilienM: no.
15:41:47 <EmilienM> #topic open discussion
15:41:47 <chem> i'm good
15:42:12 <angdraug> can we talk about mlnx vs cisco a bit?
15:42:33 <EmilienM> angdraug: sure, what's up?
15:42:36 <angdraug> #link https://review.openstack.org/209997
15:43:06 <angdraug> I'm not particularly for or against vendor drivers code in puppet-neutron, but the discussion there seems to be applying double standards
15:43:20 <angdraug> neutron itself has drivers for both cisco and mlnx
15:43:32 <angdraug> puppet-neutron has cisco specific code
15:43:44 <angdraug> why is it that mlnx specific code is undesirable?
15:43:57 <EmilienM> I reviewed the code and I don't think we should manage external repositories, but it's my opinion
15:44:19 <EmilienM> mlnx code is 100% desirable, I just disagree to install third party software
15:44:20 <angdraug> EmilienM: n1kv driver does that
15:44:39 <EmilienM> yes and if you read my review, you'll see I'm not happy with that.
15:44:55 <angdraug> how do you propose to fix that?
15:45:30 <EmilienM> angdraug: I'm curious to know what others think here
15:45:45 <EmilienM> I did not -2, I just -1 to raise something we never wanted to do initially
15:45:53 <EmilienM> even though cisco did it
15:45:59 <mwhahaha> i don't think we should include it
15:46:07 <EmilienM> I'm not a fan how installing external packages
15:46:18 <EmilienM> people have their own composition layer
15:46:23 <angdraug> is there a way to make that manifest work without external repos?
15:46:33 <EmilienM> if you install mellanox, create a puppet-mellanox module and install repo + packages
15:46:41 <EmilienM> puppet-neutron aims to manage neutron packages & config files only
15:47:05 <angdraug> as I said, that's fine by me, but following the same standards the cisco code should be removed
15:47:27 <EmilienM> angdraug: submit a patch, I'll +2
15:47:35 <angdraug> ok
15:47:47 <EmilienM> but before I would like to see consencus
15:48:14 <angdraug> I'm sure there will be -1's on the removal patch :)
15:48:28 <EmilienM> crinkle: do you have thoughts on this?
15:48:33 <angdraug> but if anyone here has an opinion, it would be nice to know
15:48:56 <EmilienM> angdraug: yes - and again I have nothing against mlx or cisco or whatever you know - I personally don't care.
15:49:13 <EmilienM> it's just the "how far should we manage plugins" question
15:49:51 <angdraug> yeah
15:50:12 <crinkle> I haven't digested the patch, no opinion really
15:50:25 <EmilienM> if anyone is good with that and I'm the only one who -1, I think we should allow external repos - I just want it documented somewhere. It's not clear to me atm
15:50:28 <crinkle> if its consistent with other plguins then why not?
15:50:32 <EmilienM> crinkle: https://review.openstack.org/#/c/209997/9/manifests/agents/ml2/mlnx.pp,cm
15:51:04 <crinkle> EmilienM: I've never taken the time to look at any plugins besides ovs and linuxbridge, why is this one different from the other vendored plugins?
15:51:10 <EmilienM> crinkle: the problem is that: did we do well by accepting external repos?
15:51:25 <EmilienM> because their packages are not in distros repos
15:51:40 <angdraug> crinkle: the difference is that cisco and mlnx drivers need packages from external repos to function
15:51:42 <EmilienM> but in third party repos, which might conflict with distros, etc
15:51:46 <crinkle> I see
15:51:55 <crinkle> it does have a parameter to turn it on and off though
15:51:57 <angdraug> not to mention that those repos may disappear at a moment's notice
15:51:59 <crinkle> so i don't really see the problem
15:52:05 <angdraug> and are likely to contain non-free software
15:52:26 <EmilienM> angdraug: this is *exactly* my concern, thank you
15:52:46 <crinkle> so we don't want to support a valid neutron configuration because it might use non-free software?
15:53:11 <EmilienM> crinkle: no, we do want to support the neutron config
15:53:18 <chem> I tend to agree with EmilienM about the puppet-mellanox, puppet-cisco, puppet-XXX relative to puppet-neutron which should just take care of configuration.  But legacy being what it is, it's going to be an hard montain to climb.
15:53:20 <EmilienM> it's just the external packages that you need
15:53:53 <crinkle> why split the packages and config? that seems confusing
15:53:56 <angdraug> on the other hand, you have neutron's decision to accept these drivers in-tree
15:54:04 <EmilienM> Juniper has puppet-opencontrail
15:54:10 <EmilienM> it takes care of everything about opencontrail
15:54:16 <EmilienM> and puppet-neutron just feed neutron config
15:54:25 <EmilienM> it works well! I think we should follow this pattern
15:54:31 <chem> yes, exactly
15:54:52 <EmilienM> crinkle: we don't split packages & config, you still need neutron plugin package
15:55:09 <EmilienM> crinkle: you're mixing third party & openstack packages
15:55:21 <EmilienM> 1/ is in external repos 2/ is in distros
15:55:41 <crinkle> okay, I don't have any strong opinions
15:55:58 <chem> but maybe, for the time being a switch in the module parameter would be enough.  Later on we can re-ask ourself if we have the resource to do the split on existing package and force it for new package.
15:56:17 <chem> (switch like configure the external resource)
15:56:23 <EmilienM> chem: like in https://review.openstack.org/#/c/209997/9/manifests/agents/ml2/mlnx.pp,cm ?
15:56:29 <EmilienM> with use_mellanox_repository ?
15:57:08 <chem> EmilienM: I think that It can be considered like a valid compromise for the time being
15:57:15 <EmilienM> yes
15:57:33 <angdraug> that would work for me, too
15:57:45 <EmilienM> ok, so proposal: use opencontrail way if we can, otherwise mlnx - but not cisco n1kv
15:58:22 <EmilienM> #action EmilienM send proposal to ML about neutron plugin mngt, gather feedback + write doc
15:58:32 <angdraug> not cisco n1kv == use of external repo is tolerated only if optional?
15:58:56 <EmilienM> before closing the meeting, iurygregory is asking for reviews, maybe richm & chem you can have a loot? I'll review them this week for sure.
15:59:04 <EmilienM> angdraug: yes
15:59:11 <iurygregory> thanks o/
15:59:13 <EmilienM> angdraug: we need to make sure it's optional
15:59:31 <EmilienM> thanks angdraug for this topic, very productive
15:59:40 <degorenko> EmilienM, one more review is needed :) https://review.openstack.org/#/c/211043
15:59:44 <EmilienM> a few seconds left
15:59:47 <chem> angdraug: yes, with the better option being : make a separate module for the installation of the package itself
15:59:58 <EmilienM> thanks everyone, have a great day!
16:00:04 <EmilienM> #endmeeting