14:59:36 <EmilienM> #startmeeting puppet-openstack
14:59:36 <openstack> Meeting started Tue Feb  2 14:59:36 2016 UTC and is due to finish in 60 minutes.  The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:59:39 <openstack> The meeting name has been set to 'puppet_openstack'
14:59:52 <EmilienM> hello puppeteers
14:59:54 <degorenko> hey o/
15:00:00 <mwhahaha> hi2u
15:00:01 <EmilienM> very short agenda today
15:00:09 <EmilienM> #link agenda https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160201
15:00:12 <clayton> o/
15:00:30 <skolekonov> hi
15:00:53 <angdraug> o/
15:01:16 <EmilienM> mfisch: you around?
15:01:26 <EmilienM> the only one topic is on him
15:01:34 <clayton> I can speak to it if he's not around
15:01:41 <EmilienM> nice
15:01:50 <EmilienM> #topic service_url only on localhost
15:01:58 <EmilienM> clayton, mfisch: o/
15:02:29 <mattymo> which module is this related to?
15:02:32 <clayton> short version is that we're moving to the service token only being available via local host for security reasons.  puppet will be the only thing that uses it
15:02:39 <clayton> keystone module
15:02:53 <mattymo> +1 and openrc support is working perfectly
15:03:14 <EmilienM> that's sounds reasonable
15:03:16 <clayton> we'd like to propose a change to allow specifying the service_url for keystone (instead of the admin url) and wanted to get feedback before going down that path
15:03:40 <EmilienM> clayton: do you have some doc about that?
15:03:47 <richm> hello
15:03:54 <clayton> mfisch may, I didn't even know he put it on the agenda until yesterday :)
15:03:56 <EmilienM> richm: hey, talking about puppet-keystone
15:04:08 <EmilienM> clayton: it was on last week's agenda
15:04:10 <mattymo> clayton, the only issue that might be possible is keystone listening only on SSL (and then you must use fqdn)
15:04:11 <clayton> He and I talked about it about two weeks ago.  he just got back in town last night
15:04:15 <EmilienM> we postponed it
15:04:34 <clayton> I was awol last week, we had a bit of snow to deal with :)
15:04:50 <EmilienM> richm: clayton | short version is that we're moving to the service token only being available via local host for security reasons.  puppet will be the only thing that uses it
15:05:07 <EmilienM> clayton | we'd like to propose a change to allow specifying the service_url for keystone (instead of the admin url) and wanted to get feedback before going down that path
15:05:15 <EmilienM> sorry to repeat, but richm missed that part
15:05:36 <EmilienM> I don't see any trouble in there, it sounds like a nice feature for improving deployment security
15:05:56 <EmilienM> I guess it will a bit more clear with some code
15:06:27 <EmilienM> thoughts?
15:06:58 <clayton> I suspect matt just wanted to make sure no one was opposed, or that there wasn't already a good way to do this before we went further
15:08:20 <richm> That sounds like a good idea
15:08:53 <EmilienM> clayton: is there any interaction with other projects?
15:09:07 <clayton> I don't think there would be
15:09:17 <EmilienM> or completely independant in keystoen itself
15:09:38 <clayton> I think it would all be in puppet-keystone.  if there was anything else I would expect only openstacklib, but that seems unlikely
15:10:48 <EmilienM> ok
15:11:03 <EmilienM> clayton: yeah, it would be great to come-up with a poc of code or even a patch
15:11:08 <EmilienM> so we can start looking & testing it
15:11:13 <EmilienM> I don't see any blocker
15:11:13 <richm> How can we find out if any other puppet module expects to be able to do token auth?
15:11:53 <clayton> richm: we recently changed our service token to be unique per keystone server and ran into no problems with other services, fwiw
15:12:12 <richm> I'm assuming "for each module ; pushd module ; git grep $something ; popd; done" is not sufficient?
15:12:49 <EmilienM> clayton: with puppet?
15:13:00 <clayton> richm: anything else using it would have to be running on a keystone node, since afaik the only way modules can get it right now is from the keystone.conf
15:13:00 <clayton> yes
15:13:39 <EmilienM> cool
15:13:49 <richm> Yes, and I understand that some deployers create a "dummy" keystone.conf with the token and any other necessary parameters on those nodes where keystone is not deployed in order to use keystone auth
15:14:40 <clayton> that seems horrible, but possible :)
15:14:49 <EmilienM> clayton: so can we maybe take an action on this?
15:15:00 <EmilienM> come up with a patch for next week? and we'll review it
15:15:06 <clayton> I'll talk to Matt and figure out where he wants to go next
15:15:06 <EmilienM> I mean, it's up to you guys
15:15:11 <EmilienM> cool
15:15:19 <EmilienM> clayton: anything else regarding this topic?
15:15:28 <clayton> nope, I appreciate the feedback
15:15:50 <EmilienM> good
15:16:02 <EmilienM> no more topics, I'll open discussion
15:16:05 <EmilienM> #topic open discussion
15:16:25 <EmilienM> if you have outstanding bugs / reviews / or if you have something to say, go ahead!
15:16:31 <igorbelikov> hey guys, wanted to talk about Fuel CI for puppet openstack modules
15:16:37 <EmilienM> w00t
15:16:42 <degorenko> wow
15:16:45 <EmilienM> igorbelikov: shoot
15:16:49 <igorbelikov> :)
15:17:32 <degorenko> igorbelikov, so, i guess you have good news :)
15:17:48 <igorbelikov> degorenko: yeah, in some way
15:17:49 <angdraug> yup, we've finally got the hardware for this, igorbelikov: how far along are you in setting it up?
15:18:11 <degorenko> oh, that's really good
15:18:25 <igorbelikov> angdraug: HW is ready, the only question is basically what and how we should run
15:18:32 <igorbelikov> so I wanted to discuss that
15:18:48 <mwhahaha> so we need to get zuul integration and a way to provide the modules into fuel
15:19:03 <mwhahaha> have we done that yet for fuel-ci?
15:19:04 <EmilienM> angdraug: we might want to have the same kind of jobs as TripleO has, in a separated queue, non-voting
15:19:35 <igorbelikov> EmilienM: yeah, the plan is to have it as a third-party CI and non-voting, at least for now
15:19:58 <EmilienM> ++
15:20:15 <bookwar_> mwhahaha: we don't need zuul for starting as a third-party ci, fuel ci will just provide non-blocking votes
15:20:20 <EmilienM> do you guys need something on our side?
15:20:26 <mwhahaha> no i mean to actually have it test stuff
15:20:34 <angdraug> igorbelikov: what about the second mwhahaha question, a way to pull puppet modules into fuel?
15:20:40 <mwhahaha> pulling the modules via zuul-cloner
15:20:46 <mwhahaha> sorry not just zuul
15:21:03 <igorbelikov> there are several ways to do it
15:21:12 <angdraug> I assume we're going to be using UCA packages in the deployment, right?
15:21:15 <EmilienM> yeah we have a script that does it in our integ scripts
15:21:18 <EmilienM> crinkle wrote it
15:21:30 <igorbelikov> all of them pretty easy to implement
15:21:44 <mwhahaha> right we need to integrate that part into the fuel build process, just wondering if anyone had done it yet :D
15:21:44 <EmilienM> most of the code is in there: https://github.com/openstack/puppet-openstack-integration/blob/master/functions
15:21:56 <EmilienM> feel free to steal it
15:22:03 <EmilienM> just make sure you send cookies to crinkle
15:22:14 <igorbelikov> EmilienM: thanks for the link, I'll take a look
15:22:26 <bookwar_> i'll add the link to blueprint here https://blueprints.launchpad.net/fuel/+spec/deployment-tests-for-puppet-openstack
15:22:39 <EmilienM> you guys using puppetfile?
15:22:42 <degorenko> igorbelikov, if you will have questions - you can ask me also :)
15:23:04 <xarses> EmilienM: mostly
15:23:22 <angdraug> hm, looks like a duplicate of mwhahaha's https://github.com/openstack/fuel-library/blob/master/deployment/update_modules.sh
15:23:29 <EmilienM> so this code I pasted, you can actually re-use it with zuul
15:23:45 <igorbelikov> EmilienM: I want to make a spec for this whole activity, is puppet-openstack-specs a proper place for this?
15:23:54 <mwhahaha> ours is not compatible with zuul-cloner so we would need to figure out that integration
15:24:00 <EmilienM> igorbelikov: no
15:24:04 <mwhahaha> we could just pull ours, then lay the CI version on top of it
15:24:05 <EmilienM> fuel is the right place
15:24:13 <igorbelikov> EmilienM: ok, got it
15:24:31 <EmilienM> we already have our CI in place, AFIK we're happy with it
15:24:38 <EmilienM> tell me if I'm wrong
15:25:04 <EmilienM> do we have anything else for today folks?
15:25:06 <angdraug> I agree, fuel-specs sounds like the right place
15:25:07 <igorbelikov> mwhahaha: can't we get clone upstream modules first and leave it to librarian to just use them?
15:25:13 <mwhahaha> no
15:25:32 <mwhahaha> well actually maybe, it might ignore them if already present
15:25:36 <mwhahaha> would have to test
15:25:42 <skolekonov> Can we use refs in https://github.com/openstack/fuel-library/blob/master/deployment/Puppetfile#L142 to pull a change request? If we clone from review.openstack.org
15:25:45 <mwhahaha> basically we need to figure out that order and how to wedge that in for this CI, that's all
15:26:10 <EmilienM> so the script crinkle wrote is able to take your puppetfile and clone modules with zuul-cloner
15:26:12 <EmilienM> just fyi ^
15:26:43 <mwhahaha> yea we need to play with it, i think it's going to be a combination of the scripts. just we need to figure out which script/which order to run stuff
15:26:58 <EmilienM> cool
15:27:01 <EmilienM> let us know if we can help
15:27:10 <EmilienM> I'll close the meeting in 30 seconds if anything else comes up
15:27:20 <EmilienM> if nothing else*
15:28:05 <EmilienM> thank you guys
15:28:07 <EmilienM> keep rocking
15:28:10 <EmilienM> #endmeeting