15:00:00 <EmilienM> #startmeeting puppet-openstack
15:00:01 <openstack> Meeting started Tue Oct 13 15:00:00 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:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:04 <openstack> The meeting name has been set to 'puppet_openstack'
15:00:07 <sbadia> hello
15:00:08 <EmilienM> hello
15:00:09 <mwhahaha> hi
15:00:15 <iberezovskiy> hi
15:00:19 <skolekonov> hi
15:00:22 <iurygregory> hello =D
15:00:24 <aglarendil> hi
15:00:25 <mkarpin> hi
15:00:28 <aderyugin> hi
15:00:33 <mfisch> hey
15:00:33 <degorenko> hey o/
15:00:46 <_ody> o.
15:00:52 <_ody> o/
15:00:53 <clayton> o/
15:01:06 <EmilienM> #topic Review past action items
15:01:14 <EmilienM> sbadia and jasondotstar signed up to help with kilo release (done, we're synced)
15:01:18 <spredzy> o/
15:01:22 <EmilienM> continue globals topic on mailing list
15:01:36 <EmilienM> mwhahaha: ^ did you continue the discussion ?
15:01:49 <jasondotstar> o/
15:01:58 <yottatsa> hi
15:02:01 <mwhahaha> no i don't think so
15:02:15 <EmilienM> mwhahaha: do you think we need to postpone it?
15:02:33 <iberezovskiy> looks like topic has stalled
15:02:50 <mwhahaha> i think there was an updated review, but i haven't had time to look at it.
15:03:02 <EmilienM> same here
15:03:10 <richm> hello
15:03:18 <mwhahaha> let's review it next week
15:03:22 <mwhahaha> i'll spend some time today to look at it
15:03:27 <vinsh> o/
15:03:38 <EmilienM> #action continue "global topic" on ML
15:03:42 <EmilienM> reviewers review 226862 and 229548 (not done by core reviewers, needs to be postpone)
15:03:44 <EmilienM> #action reviewers review 226862 and 229548
15:03:54 <EmilienM> aglarendil to bring up openstackclient vs aviator on mailing list (done)
15:03:56 <EmilienM> #link osclient vs aviator new thread http://permalink.gmane.org/gmane.comp.cloud.openstack.devel/66423
15:04:12 <EmilienM> let's start the agenda
15:04:27 <EmilienM> #topic puppet-keystone non backward compatible change
15:04:33 <EmilienM> #link https://review.openstack.org/#/c/226624/
15:04:38 <EmilienM> mfisch, richm: hey
15:04:41 <mfisch> hey
15:04:46 <EmilienM> today I would like to find a consensus
15:05:22 <EmilienM> we really need to go ahead about that patch, because it's blocking many others, that block our future 7.0.0 release
15:05:52 <EmilienM> afik, until now, only mfisch disagreed on this change
15:06:06 <mfisch> I'm willing to go change our code to support the domain stuff
15:06:14 <mfisch> but I'm annoyed that this was done by fiat
15:06:27 <mfisch> I guess we can close the topic since I'm the only one who objected
15:07:01 <EmilienM> mfisch: we are aware this is annoying though
15:07:43 <EmilienM> richm: what would be the alternative?
15:08:09 <richm> leaving in the existing code, which no one wants to maintain
15:08:15 <EmilienM> also, I would like to note that we're breaking backward compatibility only when a domain is not specified and the resources is unique among all domains
15:08:24 <EmilienM> richm: fair enough
15:08:42 <EmilienM> I'll let our team to vote in Gerrit for https://review.openstack.org/#/c/226624/
15:08:47 <richm> right - we are breaking backward compatibility only in a special case
15:09:25 <EmilienM> mfisch, richm: anything else we need to discuss about that?
15:09:33 <mfisch> I dont think so
15:09:36 <richm> nack
15:09:38 <EmilienM> great
15:09:42 <mfisch> as soon as we merge up to master I'll add domains to everything
15:09:48 <mfisch> can't stop V3 forever I guess
15:09:57 <EmilienM> #topic Tokyo topics grooming
15:10:04 <EmilienM> #link https://etherpad.openstack.org/p/HND-puppet
15:10:31 <EmilienM> I created a "tag" for each topic, so we can try to organize the sessions by tags
15:10:47 * _ody totally just added another because he got annoyed trying to review changes again last night
15:10:49 <EmilienM> for eath topic, there is an abstract, a leader and votes
15:11:47 <EmilienM> note: the "votes" is here to get statistics about topics attraction
15:11:59 <EmilienM> we have a few slots, we need to be effective I guess
15:12:44 <clayton> maybe we should have a time goal for some of these?  For example, the one I proposed I can't see taking very long.  I suspect some of the others would be much longer
15:12:44 <EmilienM> #action the group to look at https://etherpad.openstack.org/p/HND-puppet and vote for topics
15:12:46 <mfisch> You'll need to use some judgement too
15:13:01 <EmilienM> clayton: good idea
15:13:06 <mfisch> more cores/faster reviews should be a major topic
15:13:26 <mfisch> my healthcheck one is also 15 min
15:13:27 <EmilienM> mfisch: yes, it's a community thing
15:13:48 <EmilienM> mfisch: so we need to estimate timing for each topic
15:14:03 <clayton> I think estimates and time limits are different things
15:14:22 <mfisch> time limit is to prevent people from arguing about it for 3 hours
15:14:34 <clayton> I'd estimate 5 minutes for mine, but to guarantee to move on after 15
15:14:36 <EmilienM> right, but before time limiting, we need to know the estimates, isn't?
15:14:58 <EmilienM> ok, so maybe we can ask people to set both
15:15:06 <clayton> I put both on mine, others can do the same if they like
15:15:16 <EmilienM> #action tokyo topics leaders to add "estimate" and "limit" timing
15:15:20 <EmilienM> clayton: awesome
15:15:24 <clayton> the concept I want to discuss is pretty simple, I suspect people will either think it's a good idea, or want to move on
15:15:51 <EmilienM> ok, so I'll let a few more days to let our team work on the etherpad
15:15:59 <spredzy> We can probably reserve one of the slot for a bucket of topics to talk
15:16:03 <EmilienM> and I think by the next week we can come up with an agenda
15:16:25 <EmilienM> spredzy: ?
15:16:38 <EmilienM> spredzy: a bucket of topics that are not in etherpad?
15:16:49 <spredzy> what I mean is I see 5 slot of 40min
15:17:06 <spredzy> let's keep one of those slot where we could prob. address several of the topics listed
15:17:08 <mfisch> lots of those topics can be 2 per slot
15:17:12 <mfisch> or 3
15:17:24 <spredzy> not a 1:1 mapping
15:17:29 <EmilienM> spredzy: of course not
15:17:30 <mfisch> my topic and clayton's can share a slot for sure
15:17:44 <EmilienM> spredzy: a slot will contain different topics, that's why we're talking about timing here
15:18:07 <spredzy> EmilienM, ack. Sounds good to me.
15:18:09 <EmilienM> anything else about summit? (please have a look this week)
15:18:58 <EmilienM> great, let's continue the work on etherpad and we will define our agenda next week or so
15:19:11 <EmilienM> #topic puppet-murano: murano module in liberty
15:19:15 <EmilienM> aderyugin: yo
15:19:17 <aderyugin> Hi! There was a thread in ML that murano module may not be released in liberty. So i'd like to know, what should be done to have a murano module in liberty.
15:19:25 * mfisch perks up too
15:19:26 <aderyugin> I've added some acceptance tests https://review.openstack.org/#/c/233591/, but I don't know how to enable acceptance job for murano module.
15:19:29 <EmilienM> is it beaker-tested?
15:19:39 <mfisch> not yet I dont think
15:19:44 <EmilienM> aderyugin: you need to patch openstack-infra/project-config
15:19:56 <EmilienM> aderyugin: from where do you install packages?
15:20:00 <EmilienM> to install murano?
15:20:21 <mfisch> I poked Canonical and they're in UCA now
15:20:25 <EmilienM> wow
15:20:27 <mfisch> as of Monday
15:20:36 <EmilienM> is it in RDO?
15:20:42 <mfisch> I think so
15:21:01 <EmilienM> no: http://trunk.rdoproject.org/f21/current/
15:21:11 <EmilienM> I'll poke RDO folks
15:21:15 <angdraug> https://trello.com/c/we5K0deF/60-add-murano-and-ec2-api-in-rdo
15:21:23 <angdraug> marked as blocked, asking for volunteers
15:21:42 <EmilienM> oh nice
15:21:55 <EmilienM> angdraug: not a blocker for us
15:22:00 <mfisch> I think aderyugin needs help with acceptance based on what he said above
15:22:00 <EmilienM> if we test at least on UCA, that's okay
15:22:19 <EmilienM> mfisch: he needs to patch infra
15:22:26 <EmilienM> aderyugin: I can help with that
15:22:42 <angdraug> thanks!
15:22:43 <aderyugin> EmilienM: it will be great
15:22:43 <EmilienM> #action EmilienM & aderyugin patch infra to enable beaker jobs on murano module
15:22:50 <degorenko> i think we can also find volunteers for package building
15:23:16 <EmilienM> anything else about murano?
15:23:18 <mfisch> I started playing with Murano last night and also have a few comments if we have time
15:23:31 <mfisch> mainly, the parameter names don't match what we use in other modules
15:23:32 <EmilienM> we do have time
15:23:35 <mfisch> especially all the rabbit stuff
15:23:42 <EmilienM> that's a big deal
15:23:46 <mfisch> since nobody is really using this module yet I'd like to get it fixed
15:23:51 <EmilienM> +1
15:23:55 <mfisch> but maybe fuel is using it?
15:24:11 <mwhahaha> yes we use it
15:24:22 <mfisch> for example: "rabbit_os_user", "rabbit_own_host" etc
15:24:30 <EmilienM> that's not compliant
15:24:39 <mfisch> mwhahaha: how much of an issue is it to change these to match everything else?
15:24:40 <_ody> parameters need to match.
15:24:46 <EmilienM> aderyugin: can you make sure the module is using the right param names?
15:24:49 <mwhahaha> it operates differently
15:25:01 <mwhahaha> supporting two rabbitmq instances
15:25:04 <mfisch> yeah  that
15:25:07 <mwhahaha> one for openstack and one for murano
15:25:09 <aglarendil> yep, we need to make it compliant
15:25:27 <mfisch> lets just look and see what can be improved and made compliant
15:25:31 <mfisch> there are some special things in here for sure
15:25:33 <mwhahaha> we can fix variable names, that's not too bad but we need to figure out how to fix it correctly
15:25:37 <aderyugin> EmilienM: parameters names can be changed, and it will not cause dificulties
15:25:51 <mfisch> thanks aderyugin I also sent you a few small patches yesterday
15:26:00 <angdraug> agreed, as long as we keep the ability to have a dedicated rabbitmq instance for murano
15:26:04 <mfisch> I will be using it over the next few weeks when I have time and may have some more fixes
15:26:31 <EmilienM> #action aderyugin to make sure puppet-murano has compliant parameters
15:26:45 <EmilienM> mfisch: thanks for having looked at it
15:27:04 <EmilienM> anything else about murano? last call
15:27:14 <mfisch> im done
15:27:28 <EmilienM> #topic nova_admin_* options deprecation in Neutron
15:27:33 <EmilienM> skolekonov: hola
15:27:36 <skolekonov> So currently we have nova_admin_* options in neutron.conf. They are deprecated since Kilo, so I propose to replace them.
15:27:41 <skolekonov> The only problem is that we will have to use Keystone auth plugins, which differ from each other. So I propose not to just replace deprecated options
15:27:48 <skolekonov> but let a user pass a hash with all parameters and use a provider to set them in a configuration file.
15:27:54 <skolekonov> What do you think?
15:28:12 <EmilienM> hum, we don't do that anywhere else
15:28:24 <skolekonov> It will probably let us to avoid adding a bunch of new parameters which will not cover all possible auth plugins.
15:28:50 <skolekonov> Something a bit similar was in Heat https://github.com/openstack/puppet-heat/blob/0e850373a8196b06e4387abb5f2fe81727dce1fb/lib/puppet/provider/heat_domain_id_setter/ruby.rb#L183
15:28:51 <EmilienM> skolekonov: where go the parameters now? in a keystone authtoken section or?
15:29:35 <skolekonov> They are in DEFAULT if I'm not mistaken
15:29:40 <EmilienM> https://github.com/openstack/puppet-neutron/blob/master/lib/puppet/provider/nova_admin_tenant_id_setter/ini_setting.rb#L191
15:29:59 <EmilienM> why not just updating the section,
15:30:16 <EmilienM> does the parameter name also change?
15:30:48 <skolekonov> Yes, they've changed and also we can't cover all possible combinations of them
15:31:05 <EmilienM> skolekonov: do you have some doc about it?
15:31:08 <skolekonov> We can just switch to the 'password' plugin, but it's not universal I guess
15:31:37 <skolekonov> For example here http://docs.openstack.org/developer/python-keystoneclient/authentication-plugins.html
15:31:56 <skolekonov> It's possible to create a custom plugin
15:32:20 <EmilienM> oh I see, ok
15:33:19 <EmilienM> the password looks fine, isn't?
15:33:37 <skolekonov> Yep. Should we support others?
15:33:43 <EmilienM> richm: do you have thoughts?
15:34:04 <EmilienM> skolekonov: I think one should be fine
15:34:39 <skolekonov> EmilienM, ok, than we can just switch to it
15:35:01 <EmilienM> skolekonov: yes but I don't like the hash thing, it's a bit overkill, isn't?
15:35:06 <aglarendil> skolekonov: EmilienM: why should we disregard token authentication here ?
15:35:27 <EmilienM> it would be great to keep our interface backward compatible
15:35:44 <richm> looking
15:35:46 <EmilienM> if possible, keep the same parameters, and puppet-neutron would deal itself to configure the right section
15:35:57 <skolekonov> aglarendil, we don't support it now, do we?
15:36:23 <aglarendil> skolekonov: but if we want to remove those deprecated options - it is better to support both password and token types, I think
15:36:35 <aglarendil> some people will still have only v2 keystone functioning for a while
15:36:45 <aglarendil> and password seems to work only v3 according to this link
15:36:58 <skolekonov> aglarendil, no, it should work
15:37:10 <skolekonov> and of course we will keep compatibility
15:37:22 <richm> can nova use keystone_authtoken section, and keystone authtokenmiddleware?
15:37:33 <EmilienM> richm: we're talking about neutron-server
15:37:51 <EmilienM> (neutron.conf)
15:37:53 <richm> EmilienM: ok, sorry
15:37:58 <richm> same question applies
15:38:06 <richm> s/nova/neutron/
15:38:38 <richm> and yes, v2 password auth is still supported for at least another release, afaik, but the keystone guys can confirm that
15:39:09 <lazy_prince> jroll: regarding the ci for network-provider, you wanted to check the possibility of testing network flip using two networks... Would that not be a problem when the VM is connected to the bridge and two networks will be serving ip address to the vm..?
15:39:11 <skolekonov> This is how it works now (this section is only for interacting between neutron and nova). Other auth way will require some changes in Neutron, I guess
15:39:44 <EmilienM> lazy_prince: wrong chan I guess :)
15:39:54 <aglarendil> skolekonov: richm I think we will need to implement some better way than password auth. This is like an important part of inter-service communication in OpenStack
15:39:55 <lazy_prince> just realized..
15:40:33 <skolekonov> aglarendil, we can support v2/v3 auth and token without using things like hashes with parameters
15:40:45 <skolekonov> not too many new parameters I think
15:41:03 <richm> aglarendil: skolekonov: How is this different than the problem which [keystone_authtoken] and keystonemiddleware solves?
15:41:15 <EmilienM> skolekonov: you can come up with a proposal (code or blueprint) (if code, don't write tests) so we can see which solution would be better
15:41:40 <skolekonov> EmilienM, yes, I'm going to propose a patch
15:41:45 <EmilienM> richm: I think that's 2 different things
15:42:18 <skolekonov> Just wanted to clarify the first steps
15:42:25 <EmilienM> richm: keystone_authtoken is used by neutron to identify against keystone and manage network resources, while we need an auth to connect with nova
15:42:46 <EmilienM> but I'm prob wrong
15:42:59 <richm> keystone_authtoken is used to authenticate to Keystone and get a token to use with other OpenStack services
15:43:11 <richm> afaik
15:43:22 <richm> but again, we can get someone from Keystone to answer questions
15:43:58 <richm> that is, nova doesn't have a username/password database of its own that it uses to authenticate uses separately from Keystone
15:43:58 <EmilienM> skolekonov: can you run the discussion on the ML
15:44:12 <EmilienM> with [keystone] [puppet] [neutron] tags
15:44:13 <skolekonov> EmilienM, I will
15:44:16 <EmilienM> thank you
15:44:21 <skolekonov> np
15:44:30 <EmilienM> #action skolekonov to continue nova_admin_* options deprecation topic on ML
15:44:45 <EmilienM> #topic Open Discussion, Bug and Review triage
15:44:58 <EmilienM> I would like to talk about the ruby library
15:45:24 <EmilienM> while I see a lot of advantages of using a ruby library, I'm still concerned by who is going to make it
15:46:08 <EmilienM> as a long term solution, I would like to see first a real ruby library that would be usable by anyone (not only us)
15:46:17 <aglarendil> EmilienM: we have a set of guys working at Mirantis here who are intersted in it
15:46:25 <degorenko> i've already prepared patches for nova with new auth based on Openstacklib and client, i can also help with this activity
15:46:43 <EmilienM> so if someone wants to work on a ruby SDK for openstack go ahead, but it will have to be in OpenStack, documented, tested, etc
15:46:46 <richm> can we also have a complete oslo.config implementation in ruby so we can get rid of the "hacky" inifile?
15:47:02 <aglarendil> EmilienM: not a problem - we have big contribution into OpenStack anyway
15:47:06 <EmilienM> richm: what is the problem with inifile?
15:47:26 <richm> it doesn't handle some of the weird cases that oslo.config supports
15:47:37 <aglarendil> richm: which use cases?
15:47:38 <richm> so you end up having to hack around
15:47:40 <EmilienM> it's very brave to think we're going to support a ruby SDK and follow openstack features
15:47:46 <richm> e.g. you have to strip() values
15:47:48 <EmilienM> all API changes, etc
15:47:58 <aglarendil> EmilienM: we can have this client lagging a bit, but we can provide users with choice
15:48:08 <aglarendil> 1) OpenStackClient which is slower
15:48:14 <richm> I think there were some problems with sections with special characters in them e.g. [foo:bar]
15:48:16 <aglarendil> 2) Ruby library with less features but faster
15:48:32 <aglarendil> richm: oh, you are talking about multiparams
15:48:37 <richm> yes
15:48:38 <chem> EmilienM: true values
15:49:06 <richm> maybe it would be easier to just call python directly from ruby . . .
15:49:07 <chem> EmilienM: there are a lot broader in the oslo.config (y, n, 1, 0, ...)
15:49:09 <EmilienM> openstack is hard to catch-up, and now we're going to write a new library? go ahead if you like, but good luck
15:49:12 <chem> EmilienM: for instance
15:49:34 <aglarendil> folks, can we bring up oslo.config vs inifile in ML ?
15:49:42 <aglarendil> please?
15:49:46 <EmilienM> ++
15:49:48 <aglarendil> we are mixing the discussion
15:49:51 <richm> +1
15:49:58 <clayton> EmilienM: it doesn't support the syntax needed for neutron service providers
15:49:58 <chem> ok, I can do this
15:50:15 <EmilienM> #action chem to run ML thread about oslo.config vs inifile
15:50:33 <aglarendil> so, for ruby library - I propose we come up with library and provide users with a choice
15:50:39 <aglarendil> and let the best man win
15:51:07 <EmilienM> I'm not sure I understand the expression but anyway
15:51:14 <richm> IMO the biggest problem with openstackclient is that the distros lag so far behind
15:51:21 <aglarendil> I mean let people decide which one they love the best
15:51:23 <richm> will this new ruby library have the same problem?
15:51:42 <mfisch> how would it get deployed?
15:51:46 <EmilienM> richm: I -1 your statement
15:51:52 <aglarendil> richm: it depends on who well the package with this library is maintained
15:52:11 <EmilienM> because we are developping liberty now, and osclient is up to date AFIK
15:52:34 <EmilienM> the valid statement would be: we can't backport some patches because of osclient lag
15:52:42 <EmilienM> but we could have the same issue with the library
15:52:56 <EmilienM> we will have to bump up the library in our stable branches
15:53:07 <EmilienM> which will increase the need of backward compatibility code between API changes
15:53:12 <mfisch> how does the library get pulled in? its not packaged right?
15:53:14 <mfisch> gem?
15:53:18 <richm> EmilienM: ok - but who knows what weird problem we will run into with trying to implement federation that can only be solved by another osc update . . .
15:53:22 <EmilienM> I think it would be a gem
15:54:02 <aglarendil> EmilienM: could you please come up with these points in the ML? It is easier to read such long arguments in one place
15:54:10 <mfisch> +1
15:54:12 <EmilienM> sure
15:54:21 <EmilienM> I saw you guys took time to write during the meeting, I could not
15:54:27 <EmilienM> I'll write my thoughts today
15:54:32 <mfisch> is Vladimir here?
15:54:35 <crinkle> the way we were doing it with aviator was the whole gem was vendored into its own module
15:54:46 <aglarendil> Vladimir is me, btw
15:54:52 <crinkle> we can't depend on a gem, for the same reason we can't depend on pip libraries
15:55:24 <aglarendil> crinkle: there are good ways of continuous delivery of ruby gem packages
15:55:27 <aglarendil> as well as pip libraries
15:55:59 <EmilienM> crinkle: why can't we?
15:56:09 <angdraug> why can't we package it?
15:56:28 <aglarendil> Folks, could I bring up another theme on openstacklib exception handling?
15:56:32 <crinkle> EmilienM: you would be fine with depending on pip libraries? then why are we trying to use the openstackclient distro packages?
15:56:51 <richm> I think using gems is a non-starter for RDO, for example
15:56:52 <EmilienM> aglarendil: it was not on the agenda, and meeting is almost done.. but go ahead..
15:57:15 <aglarendil> I wrinte an email, please look into it - it has spent several days without an answer
15:57:21 <EmilienM> crinkle: no I would not be fine using pip libraries
15:57:33 <aglarendil> #link http://permalink.gmane.org/gmane.comp.cloud.openstack.devel/65977
15:57:34 <crinkle> EmilienM: gems are the same thing
15:57:58 <EmilienM> richm: such a change would indeed require some packaging work for RDO
15:58:15 <aglarendil> crinkle: could you please follow up this issue into ML ? I will provide my thoughts on it in response
15:58:25 <crinkle> aglarendil: sure
15:59:23 <EmilienM> #action the group to take care of openstacklib exception handling http://permalink.gmane.org/gmane.comp.cloud.openstack.devel/65977
15:59:34 <EmilienM> thanks everyone, a lot of topics today
15:59:49 <EmilienM> #endmeeting