15:00:02 <EmilienM> #startmeeting puppet-openstack
15:00:03 <openstack> Meeting started Tue May  5 15:00:02 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:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:06 <openstack> The meeting name has been set to 'puppet_openstack'
15:00:09 <EmilienM> who is here today?
15:00:12 <clayton> morning
15:00:32 <mmagr> hi
15:00:43 <dfisher> morning
15:00:43 <xingchao> hi
15:00:52 <panda> hello
15:01:22 <crinkle> o/
15:01:22 <EmilienM> #link https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150505
15:01:24 <Hunner> o/
15:01:40 <jpena> hi
15:02:10 <EmilienM> in the last meeting, the only one action was about master policy blueprint, and we have an item so i'll skip this review
15:02:15 <EmilienM> let's start!
15:02:19 <EmilienM> #topic CI status
15:02:40 <EmilienM> sbadia: any status on Puppet4 ?
15:04:01 <EmilienM> he's probably not here
15:04:20 <EmilienM> I think he's also using the spreadsheet
15:04:22 <EmilienM> #link https://docs.google.com/spreadsheets/d/1i2z5QyvukHCWU_JjkWrTpn-PexPBnt3bWPlQfiDGsj8/edit?pli=1#gid=0
15:04:23 <nibalizer> o/
15:04:47 <EmilienM> so we miss nova, neutron, swift to have all modules working
15:05:17 <vinsh> I can give swift a puppet 4 push this week.
15:05:19 <mfisch> morning
15:05:29 <EmilienM> also this morning sbadia, dmsimard and I talked about backporting RSpec3.x work to stable branches
15:05:41 <EmilienM> because some backports failed (obvious) to pass CI
15:05:56 <EmilienM> has anyone some thoughts?
15:06:03 <gchamoul> o/
15:06:30 <EmilienM> #link https://review.openstack.org/#/q/branch:stable/juno+topic:1451460,n,z
15:07:14 <EmilienM> I think we will try first to backport this work to Juno and see if we can backport to Icehouse
15:07:31 <EmilienM> if you have any concern/thought rise your hand
15:08:11 <EmilienM> ok
15:08:13 <EmilienM> #action Backport RSpec3.x work to stable branches
15:08:23 <EmilienM> beaker status:
15:08:34 <EmilienM> crinkle, sbadia : thanks for your reviews on https://review.openstack.org/#/q/topic:bug-1444736,n,z
15:08:49 <EmilienM> we have more than 50% of our modules that have beaker tests now
15:08:54 <mfisch> +1
15:09:11 <EmilienM> and all of our modules (except Gnocchi, Tuskar) that don't have (packaging missing)
15:09:16 <clayton> +1
15:09:44 <EmilienM> panda rose a blueprint today
15:09:56 <EmilienM> #link https://review.openstack.org/180180
15:10:12 <EmilienM> this is about "Tests requirements and goals" for our beaker work
15:10:41 <EmilienM> afik, OpenStack infra is also looking at our work to replicate the tests to their modules
15:10:52 <EmilienM> panda, nibalizer: you may want to keep in touch
15:11:03 <panda> It's really a draft, I'm expecting a lot of comments a discussions
15:11:11 * nibalizer nods
15:11:16 <EmilienM> panda: that's great, we will use this document for that. Thanks
15:11:47 <EmilienM> anything else about CI?
15:11:54 <nibalizer> "a change in a common dependency (usually concat)" nice
15:12:19 <nibalizer> EmilienM: nothing from me
15:12:49 <EmilienM> ok. Hopefully next week we will have figured out this Rspec3 issue in stable branches and make progress on beaker blueprint
15:13:15 <EmilienM> #topic swift: replication network
15:13:23 <EmilienM> #link https://review.openstack.org/#/c/177037/
15:13:24 <EmilienM> vinsh: o/
15:13:32 <vinsh> Hey all
15:14:05 <richm> EmilienM: Sorry I'm late, but I'm here now
15:14:10 <vinsh> The discussion around the init files makes sense... and I could write a class that provides one.. that I know works in ubuntu atleast.
15:14:23 <vinsh> But as someone else mentioned... it might be left to the user to do that
15:14:26 <EmilienM> richm: ack, keystone v3 is the next topic ;)
15:15:05 <EmilienM> anyone has feedback about his mail/code?
15:15:27 <vinsh> One more thing to do is add the respec tests around this change, which will take me more then a day.
15:15:31 <EmilienM> vinsh: I quickly looked at the code yesterday, I have a few comments that I'll let inline, but nothing major
15:15:37 <vinsh> OK
15:16:01 <vinsh> once this merges.. I will back port it to that change: https://review.openstack.org/#/c/169071/
15:16:40 <mfisch> (vinsh is giving his daily stand-up update right now back in 1 min)
15:16:53 <EmilienM> vinsh: I don't seen any critical thing in your patch or any decision to take here
15:17:20 <EmilienM> let's move on
15:17:25 <vinsh> +1
15:17:28 <EmilienM> #topic keystone v3 status
15:17:33 <EmilienM> richm: good morning Sir
15:18:20 <richm> We have split up the jumbo patch into several smaller patches, all up for review
15:18:34 <richm> EmilienM has rebased them and fixed them for beaker ci
15:19:02 <richm> gildub is working on converting the endpoint and service providers to use v3
15:19:50 <EmilienM> richm: regarding the discussion on the ML / Gerrit: do you need to discuss about an eventual design thing or blocker?
15:20:12 <richm> The basic problem was if we could not assume v3 auth
15:20:25 <richm> However, if we can assume that the keystone provider code will only run on Keystone nodes
15:20:44 <richm> then the provider will have access to keystone.conf, and will be able to use the default domain
15:20:54 <EmilienM> yes, afik it's how we do today (cc mgagne )
15:21:33 <richm> Furthermore, if we can assume that if additional authentication information needs to be supplied, it will be supplied in an extra-puppet way (e.g. environment variables)
15:21:43 <crinkle> part of the goal of the rewrite was that we didn't necessarily want to assume that https://review.openstack.org/#/c/107546/
15:22:07 <crinkle> and i think it's useful to be able to pass parameters in from hiera without having them in a config file on localhost
15:22:18 <crinkle> i'm curious if anyone is using that or thinks they might use that
15:22:26 <richm> crinkle: Then we will assume that the admin/operator somehow provides authentication credentials in some other way e.g. hiera, environment variables, other
15:22:56 <mgagne> I think we have to list all valid use cases we wishes to support. otherwise we will get lost in implementation trying to support stuff we might not have to support
15:23:22 <mgagne> we might also have to come up with something no one else before has done
15:23:27 <clayton> We handle this the same way that mgagne described on the list, we include those resources on the kestone node.
15:25:20 <EmilienM> mgagne: that should be written in the blueprint imho
15:25:53 <richm> The other problem is if we do not have all of the keystone v3 auth information, we have to fallback to using v2 for auth, which means that we have to use the v2 api, which means the providers will have to be able to use both v2 and v3
15:26:00 <mgagne> what are the current challenges or use cases? keystone resource provisioning for keystone (admin user?), keystone resources for services (endpoints, services, users), service resources (images, networks). All those requires a keystone token.
15:27:09 <crinkle> they don't have to, after the initial admin user and tenant are set up they could require an admin username/password
15:27:26 <crinkle> and the keystone docs recommend disabling that token
15:27:30 <richm> and admin user domain and admin tenant and admin tenant domain
15:27:43 <mgagne> we should then list what is available on the nodes (glance.conf, keystone_authtoken section) where we expect the provision to happen. if informations are missing, reconsider our POV regarding provisioning or find a way to make it happen.
15:27:44 <richm> we have to use the admin_token based auth for bootstrapping
15:28:42 <mgagne> so keystone resources provisoning needs to happen on a privileged keystone node with the admin_authtoken middleware
15:28:43 <EmilienM> crinkle: for security purpose?
15:28:48 <crinkle> EmilienM: yes
15:29:07 <richm> mgagne: For some amount of bootstrapping, yes
15:29:10 <mgagne> yep
15:29:19 <richm> Would a multi-phase puppet keystone install work?
15:29:34 <mgagne> if people wishes to not use the admin_token, we will have to figure out an other way to pass in the credentials, method which doesn't exist yet
15:29:37 <richm> That is, you switch authentication at some point from admin token to username/password?
15:29:51 <richm> In the middle of the puppet run?
15:30:05 <crinkle> mgagne: that does exist
15:30:10 <sbadia> hi!, sorry for the delay…
15:30:15 <EmilienM> crinkle: well, we already have these credentials everywhere...
15:30:16 <mgagne> crinkle: in the current implementation?
15:31:08 <crinkle> mgagne: https://github.com/stackforge/puppet-openstacklib/blob/master/lib/puppet/util/openstack.rb#L8-L28
15:31:23 <mgagne> crinkle: thanks, I missed it I guess
15:31:39 <mgagne> crinkle: so how those credentials end up there?
15:32:44 <mgagne> crinkle: I know it's openstacklib but we will have to get them there somehow in our other modules. I guess it's all the purpose of this discussion.
15:33:29 <crinkle> mgagne: the keystone types include that param like this https://github.com/stackforge/puppet-openstacklib/blob/master/lib/puppet/util/openstack.rb#L8-L28
15:33:42 <mgagne> same link
15:33:46 <crinkle> er
15:33:49 <crinkle> https://github.com/stackforge/puppet-keystone/blob/master/lib/puppet/type/keystone_user.rb#L85
15:33:51 <crinkle> that one
15:34:13 <richm> Right - so every manifest has to change everywhere in order to add the auth hash to every keystone resource?
15:34:33 <crinkle> richm: no, the point is that in your roles and profiles you could add more keystone users and tenants if you wanted to
15:34:35 <richm> Which means every class resource that refers to a keystone resource has to add additional parameters for auth?  and so on
15:34:37 <mgagne> richm: that feels bothersome
15:34:56 <crinkle> richm: no, the keystone types default to using the keystone.conf the same as they always do
15:35:18 <crinkle> it's just an extra add-on if the user wants to have other keystone types not provided in the classes
15:36:01 <mgagne> is the problem with type like glance_image which might not have access to keystone.conf?
15:36:23 <crinkle> glance_image reads keystone creds out of a keystone_authtoken section in glance.conf
15:36:29 <crinkle> but that's another place it could be useful
15:36:35 <crinkle> i have a patch up for that too
15:36:49 <crinkle> https://review.openstack.org/#/c/172580/
15:36:50 <EmilienM> glance_image needs to be instantiated on glance api node
15:37:10 <mgagne> so what are the unsolved challenges?
15:37:27 <mgagne> sorry for asking so much questions, I've been out of the loop for a little too long
15:37:59 <crinkle> mgagne: are you asking what the challenges were that having the auth param solves, or challenges that it's causing?
15:38:32 <mgagne> crinkle: well, I'm trying to understand why we felt the need to talk about it in the meeting
15:38:34 <richm> Can the code enabled for v3 assume that the authentication will be provided somehow, and the people implementing v3 don't have to worry about implementing another mechanism for getting auth credentials?
15:39:22 <crinkle> richm: why can't it default to grabbing v3 credentials from keystone.conf the way it does now?
15:39:35 <crinkle> as well as allow them to specify it in a parameter if they wanted to do that instead
15:40:20 <richm> crinkle: It can and it does.  But we were concerned that keystone code would be running on non keystone nodes and that we were going to figure out how to get the auth credentials, how to figure out if we needed to use v2 or v3 for auth, how to figure out if we can use the v2 or v3 api, etc. etc.
15:40:59 <EmilienM> richm: crinkle's patch for glance is a great example
15:41:08 <imcsk8> richm: in that case you should supply user/pw
15:41:16 <EmilienM> #link https://review.openstack.org/#/c/172580
15:41:29 <crinkle> the way it works now is it runs on a keystone node (or you'd copied the keystone.conf to another node for some reason) and i don't see what needs to change about that
15:41:44 <richm> ok - I was not aware that I could assume that
15:41:55 <richm> I did not want to make any unfounded assumptions
15:42:29 <richm> I do not want to have to write v2 and v3 versions of all of the keystone openstack providers either
15:42:51 <crinkle> so, to be clear, the provider works by first trying to use credentials from the auth parameter and falls back to reading keystone.conf
15:42:54 <EmilienM> richm: and it's fair
15:43:28 <EmilienM> crinkle: I think it's a good summary
15:43:36 <mfisch> agree
15:43:41 <richm> ok
15:44:08 <EmilienM> richm: does this statement make a lot of changes in your current code?
15:44:20 <richm> EmilienM: no - it is how the current code works
15:44:38 <EmilienM> that's nice
15:45:02 <EmilienM> richm: is there anything else we need to discuss?
15:45:17 <EmilienM> crinkle, mgagne: any last thoughts?
15:45:24 <crinkle> not from me
15:45:30 <richm> no, I'm good, but if anyone has any questions about the v3 implementation, feel free to ask me here or in puppet-openstack
15:45:43 <mgagne> EmilienM: no, sorry, my attention drifted to an other meeting
15:45:58 <EmilienM> richm: well if your patches are ready, I would ask to people to have a look
15:46:15 <EmilienM> richm: I'll make sure beaker job is demonstrating the workflow without regression.
15:46:26 <EmilienM> let's move on
15:46:37 <EmilienM> #topic master policy
15:46:41 <EmilienM> (the EPIC)
15:46:46 <crinkle> ha
15:46:50 <EmilienM> this morning I created a draft
15:46:52 <EmilienM> #link https://review.openstack.org/#/c/180141/
15:47:05 <EmilienM> it's really WIP but I first want your reviews about the problems/challenges
15:47:17 <EmilienM> mgagne, mfisch, clayton ^
15:47:36 <mfisch> I will look at it today
15:48:15 <EmilienM> I'll continue that work this week, feel free to participate this this patch.
15:48:38 <EmilienM> This is an official blueprint, that means we will take serious decisions after it merges
15:48:46 <mfisch> thanks for starting it
15:48:47 <EmilienM> like breaking (or not?) master, etc
15:49:02 <EmilienM> so again, if you have anything to say, make sure you're involved here
15:49:14 <EmilienM> we have 10 min for open discussion I think
15:49:24 <EmilienM> #topic Open Discussion / Bug/review triage
15:49:42 <EmilienM> Hunner: do you have any update about project naming by any chance ?
15:50:22 <EmilienM> I'm still waiting from Puppetlabs to know if we can use 'Puppet modules'
15:52:01 <EmilienM> well it seems like Hunner is not around
15:52:07 <Hunner> hi
15:52:13 <EmilienM> Hunner: hey!
15:52:13 <mfisch> would be nice to know before summit
15:52:17 <EmilienM> mfisch: +1
15:52:18 <mfisch> since we're doing some presentations
15:52:32 <EmilienM> mfisch: well, and also to move forward with that.
15:52:38 <Hunner> I have not heard any update. I will check with Richard later, as he is closer to that
15:52:54 <EmilienM> Hunner: thanks!
15:53:00 <Hunner> But AFAIK we're still greenlight and it's just stuck in paperwork hell :)
15:53:05 <mfisch> lets get this on the agenda again for next week
15:53:15 <EmilienM> ok
15:53:34 <EmilienM> does anyone has a bug to raise or a patch that needs review?
15:54:01 <mfisch> I thnk vinsh's was one but we already discussed
15:54:08 <EmilienM> oh I have something
15:54:22 <EmilienM> #link https://etherpad.openstack.org/p/liberty-summit-puppet-team-building
15:54:37 <EmilienM> if anyone is interested to have a diner together during the summit ^
15:54:41 <clayton> Emilien really likes bowling :)
15:54:45 <EmilienM> please raise your end in the etherpad
15:54:50 <EmilienM> clayton: I'm actually pretty bad
15:55:00 <EmilienM> clayton: I broke my hand once... but keep it for you
15:55:06 <clayton> It's hard to imagine that you'd be any worse than I am :)
15:55:15 <mfisch> we will have bowling shirts
15:55:27 <EmilienM> well, if there isn't anything else, I can close the meeting
15:55:37 <mfisch> thanks
15:55:42 <EmilienM> thanks everyone!
15:55:57 <EmilienM> #endmeeting