15:00:12 <EmilienM> #startmeeting puppet-openstack
15:00:12 <openstack> Meeting started Tue Feb 16 15:00:12 2016 UTC and is due to finish in 60 minutes.  The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:16 <openstack> The meeting name has been set to 'puppet_openstack'
15:00:18 <EmilienM> o/
15:00:32 <mfisch> bon matin
15:00:35 <EmilienM> #link meeting URL https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160216
15:00:36 <degorenko> hey o/
15:00:48 <EmilienM> mfisch: I love when you speak french.
15:01:05 <mfisch> pas ne probleme
15:01:17 <IvanBerezovskiy> hi
15:01:33 <EmilienM> #topic Review past action items
15:02:03 <EmilienM> investigate release:cycle-with-milestones and if we need to follow other projects schedule -> see ML, we have a thread about Mitaka beta tag and release discussion
15:02:09 <EmilienM> sends a proposal to ML about pushing first mitaka beta tag -> done
15:02:23 <mwhahaha> o/
15:02:24 <EmilienM> investigate concat issue on https://review.openstack.org/#/c/276961/ -> degorenko reviewed it, not sure we actually need this patch
15:02:49 <EmilienM> mfisch: I think we can skip the pki topic, since we merged your patch
15:02:52 <degorenko> there is no update for patch
15:02:55 <mfisch> EmilienM: we did?
15:02:59 <degorenko> so yeah, i'm not sure about this :)
15:03:02 <EmilienM> mfisch: we did
15:03:05 <Hunner> o/
15:03:13 <mfisch> no we didnt that I see
15:03:19 <mfisch> oh nm
15:03:23 <mfisch> its waiting on Jenkins
15:03:26 <EmilienM> yes
15:03:28 <mfisch> ok skip it!
15:03:36 <EmilienM> #topic mitaka beta release
15:04:10 <EmilienM> are you agree if I push a first tag by this week or early next week?
15:04:21 <mfisch> I think a beta tag is a good idea
15:04:39 <EmilienM> zigo: fyi ^
15:04:55 <EmilienM> I also talked with rdo folks, they'll also use it
15:04:56 <mfisch> it should not imply any support though
15:05:05 <EmilienM> right
15:05:06 <zigo> o/
15:05:17 <EmilienM> this tag is not considered as stable
15:05:22 <EmilienM> but just useful for packagers
15:05:44 <EmilienM> great, so by lazy concensus, I'll push a tag
15:06:00 <EmilienM> #action EmilienM to push a mitaka beta tag
15:06:00 <zigo> Exactly. I don't expect maintenance, just a reference point. I could open a launchpad bug and write: "Using mitaka b3 tag, with puppet-cinder, I had <description-of-the-issue>"
15:06:04 <zigo> That's the whole point.
15:06:10 <mfisch> yep
15:06:16 <EmilienM> cool
15:06:18 <mfisch> we can find issues sooner then probably
15:06:20 <zigo> So that we all know what we're talking about.
15:06:41 <EmilienM> any question about the beta release?
15:06:56 <zigo> Also, I want to make sure I'm using a package set designed to work together. ie: openstack-lib meant for puppet-nova, for example.
15:08:04 <EmilienM> zigo: that's the idea
15:08:10 <zigo> We don't for sure need to wait for beta 3, if you'd produce a b2.1 for example, even now, I'd use it.
15:08:13 <EmilienM> zigo: our CI is testing modules together
15:08:16 <zigo> The sooner the better.
15:08:30 <EmilienM> zigo: sure, we are release independants
15:08:36 <EmilienM> so we basically do what we want
15:09:02 <EmilienM> I'll just keep an open window if people want to land patches before the tag
15:09:13 <EmilienM> and produce the tag by the end of the week or early next week if CI is not broken
15:09:46 <EmilienM> #topic keystone-manage bootstrap
15:09:56 <EmilienM> so we have this new bug: https://bugs.launchpad.net/puppet-keystone/+bug/1545767
15:09:57 <openstack> Launchpad bug 1545767 in puppet-keystone "puppet-keystone needs to transition to keystone-manage bootstrap" [Critical,Confirmed] - Assigned to Sofer Athlan-Guyot (sofer-athlan-guyot)
15:10:09 <chem> I've started to look into
15:10:12 <EmilienM> which is I would say pain in the *ss
15:10:30 <chem> nothing to show yet
15:10:40 <EmilienM> basically, we'll have to redefine the way we bootstrap keystone
15:10:54 <EmilienM> and use `keystone-manage bootstrap` tool
15:11:13 <EmilienM> maybe for this one we need a blueprint
15:11:38 <chem> the kind of just run once and after forget about it, is awkward to implement :)
15:11:57 <chem> I'll start with a bluebrint unless somebody else want to do it :)
15:12:38 <EmilienM> the tl;dr is: the use of ``admin_token_auth`` is deprecated in favor
15:12:40 <EmilienM> +    of using the ``keystone-manage bootstrap`` CLI
15:13:03 <EmilienM> chem: you can go ahead, you have enough background in puppet-keystone to lead this work if you want to
15:13:15 <chem> ack
15:13:29 <EmilienM> richm is not around but we also need to ask for his help maybe
15:13:35 <chem> will start with a blueprint of whatever idea come to my mind :)
15:13:41 <EmilienM> mfisch: feel free to also look if you have time
15:13:44 <mfisch> ok
15:13:59 <EmilienM> we don't have to fix it for Mitaka
15:14:01 <mfisch> I know its deprecated but wonder how long the admin token will be around
15:14:18 <EmilienM> admin_token_auth is only deprecated so we can still use it
15:14:25 <mfisch> I'd be happy to help with a blueprint chem
15:14:31 <EmilienM> cool, thanks guys
15:14:38 <chem> mfisch: cool :)
15:14:49 <EmilienM> #action mfisch and chem to initiate a blueprint about admin_token_auth deprecation
15:15:12 <EmilienM> #topic switch creating cinder types to providers
15:15:18 <EmilienM> #link https://review.openstack.org/#/c/273513/
15:15:20 <EmilienM> degorenko: o/
15:15:22 <degorenko> hey :)
15:15:28 <degorenko> i mostly done with trhis patch
15:15:36 <degorenko> thanks to chem for reviewing and help me :)
15:15:46 <EmilienM> chem is our hero of the week
15:15:48 <degorenko> i have a couple of questions
15:15:51 <chem> hoho
15:16:20 <degorenko> 1) question to chem: i've addressed your comment yesterday :)
15:16:30 <degorenko> 2) do we need some cache for list types? :)
15:16:36 <chem> degorenko: looking
15:16:47 <degorenko> if there is no any blockers - i guess we can land it, i've tested it on my env
15:16:54 <EmilienM> I think so, if we end up with a lot of types... might be useful to cache them
15:16:59 <degorenko> and also there are two patches to openstack-integration
15:17:14 <degorenko> EmilienM, ack, then i will add such possibility
15:17:32 <chem> degorenko: you're only doing one request here, I don't think you need to cache the resulting structure
15:17:39 <EmilienM> degorenko: that can be in a future patch I think since you don't introduce a regression
15:17:44 <chem> EmilienM: I do not agree :)
15:17:50 <EmilienM> the previous implementation did not have any cache
15:18:36 <degorenko> chem, cache for list types - in case of we want to create many types, but i'm not sure, that we can have such case
15:18:46 * EmilienM reading again https://review.openstack.org/#/c/273513/11/lib/puppet/provider/cinder_type/openstack.rb
15:18:49 <degorenko> like it done now for aggregates
15:18:53 <degorenko> in nova
15:19:34 <chem> self.instances is called only once and 'volume type list' as well I think
15:19:41 * chem grepping
15:20:10 <degorenko> it should be called for every resource with this type, shouldn't it?
15:20:19 <EmilienM> I also thought that
15:21:15 <chem> self.instance called once at prefetch time
15:21:22 <chem> and so is volume type list
15:21:45 <_ody_> correct.  I was just about it ask if the worry was the number of resources created or the number of times the cinder api would be hit
15:21:57 <_ody_> (chem's correct I mean)
15:22:08 <EmilienM> we worry about #2
15:22:16 <EmilienM> I think?
15:22:25 <degorenko> yes
15:22:43 <chem> EmilienM: that's what I'm saying no need to cache something that is called only once, no ?
15:22:50 <EmilienM> ok, my bad
15:23:19 <degorenko> chem, so, if we have a couple resource of one type we anyway have one self.instances calling for all of them?
15:24:02 <_ody_> Nah.  self.instances runs for an instance of the provider, not an instance of a type.  So it should only run once.
15:24:04 <chem> degorenko: not sure I fully understand the functional side of it, but on the puppet side self.instances will be called onec
15:24:34 <chem> in the prefetch to find out the type that exists or the one that should be created
15:24:45 <degorenko> _ody_, ah, ok, got it
15:25:02 <degorenko> then yes, looks like we don't need to cache it
15:25:08 <degorenko> because we have only one provider here
15:25:10 <degorenko> for now
15:25:21 <chem> exactly :)
15:25:21 <EmilienM> degorenko: have you seen all chem's comment on the patch?
15:25:37 <degorenko> EmilienM, i've addressed it, no?
15:25:50 <EmilienM> degorenko: https://review.openstack.org/#/c/273513/11/spec/unit/provider/cinder_type/openstack_spec.rb
15:25:57 <degorenko> ah, you are about type :D
15:26:01 <degorenko> typo*
15:26:15 <degorenko> yeah, ok, i will update it, sure
15:26:29 <EmilienM> I think after that, we're ready to land it
15:26:35 <EmilienM> will wait for chem's +1 though
15:26:39 <degorenko> nice, thanks everyone
15:27:01 <EmilienM> #topic Open Discussion, Bug and Review triage (submit modules to triage here)
15:27:09 <IvanBerezovskiy> can I start about horizon?
15:27:14 <EmilienM> IvanBerezovskiy: go ahead!
15:27:19 <IvanBerezovskiy> I want to provide an ability to run collectstatic&compress for horizon on ubuntu/debian packages:
15:27:22 <IvanBerezovskiy> #link https://review.openstack.org/#/c/280181/
15:27:27 <IvanBerezovskiy> Now this exec resource is defined only in case of rpms.
15:27:31 <IvanBerezovskiy> But sometimes (e.g. usage of custom theme) we need to re-run collectstatic&compress again even for ubuntu/debian packages.
15:27:35 <IvanBerezovskiy> zigo blocks this change because as he says it can break Debian horizon package completely.
15:27:39 <IvanBerezovskiy> but my point is to do not trigger collectstatic&compress by default, just to provide an ability for this.
15:27:43 <IvanBerezovskiy> With this patch users will be able to trigger it from orchestration level if needed
15:27:47 <IvanBerezovskiy> so, I wanna know your opinion here
15:28:01 <zigo> Well, it does indeed !!!
15:28:21 <degorenko> zigo, it will not :)
15:28:29 <EmilienM> if $::os_package_type == 'rpm' and $compress_offline
15:28:38 <EmilienM> it works only on rpm systems?
15:28:42 <zigo> Do only compress, not collectstatic, and I'll aproove.
15:29:02 <IvanBerezovskiy> zigo: I don't run anything by default
15:29:03 <skolekonov> We don't talk only about Debian packages here
15:29:04 <IvanBerezovskiy> for debian
15:29:08 <zigo> degorenko: IT WILL !!!
15:29:14 <degorenko> zigo: NO
15:29:18 <zigo> YES
15:29:21 <degorenko> because we have refrechonly property
15:29:21 <EmilienM> hey kids
15:29:37 <zigo> The static "folder" in Debian is a SYMLINK.
15:29:44 <zigo> You can't write stuff in there AT ALL.
15:29:48 <degorenko> we don't touch anything
15:29:51 <EmilienM> yep, the refreshonly helps here
15:30:01 <degorenko> we just move declaring exec stuff under if to main block
15:30:09 <zigo> In Debian, no collecstatic should happen at all.
15:30:11 <degorenko> we will NOT run it by default
15:30:12 <zigo> Zero.
15:30:14 <zigo> Niet.
15:30:23 <mwhahaha> you know it fails on rdo
15:30:45 <skolekonov> zigo, again, we don't talk about Debian packages itself. Packages can follow Debian schemes but be different in fact
15:31:09 <zigo> Well, the patch is replacing os_package_type by operatingsystem.
15:31:11 <zigo> That's wrong.
15:31:24 <degorenko> where?
15:31:28 <skolekonov> Agree, we should use os_package_type here
15:31:47 <IvanBerezovskiy> zigo, please take a look on latest patchset
15:31:49 <zigo> degorenko: Well, look at the patch yourself, it's easy to search...
15:32:08 <zigo> Oh, ok, let me look again.
15:32:10 <degorenko> zigo: are you looking at latest patch set?
15:32:17 <degorenko> or just for old version?
15:32:20 <zigo> Doing now.
15:32:54 <zigo> What I've -1 is the latest patch at https://review.openstack.org/#/c/280181/
15:33:04 <zigo> We're talking about the same thing, right?
15:33:18 <degorenko> but here no any changes of os_package_type
15:33:53 <skolekonov> zigo, yep, https://review.openstack.org/#/c/280181/4/manifests/init.pp
15:33:55 <zigo> Hum...
15:34:09 <zigo> It looks like I missread the patch.
15:34:18 <zigo> Too many beers yesterday evening? :P
15:34:25 <skolekonov> :)
15:34:30 <zigo> Ah no...
15:34:35 <zigo> You're removing the conditional, no ?
15:34:46 <zigo> There used to be:
15:34:51 <skolekonov> zigo, yes, bu he leaves refreshonly => true,
15:34:56 <IvanBerezovskiy> no, I am moving 'exec' resource out of condition
15:35:08 <zigo> if $::os_package_type == 'rpm' {
15:35:15 <zigo> before the collectstatic.
15:35:18 <zigo> That's now removed.
15:35:21 <zigo> I don't agree with this.
15:35:22 <mwhahaha> zigo: refreshonly means it only gets run when it's notified
15:35:27 <mwhahaha> it's not always run
15:35:35 <mwhahaha> that i think is your misunderstanding
15:35:43 <degorenko> ^ that's what i'm talking about :) thanks
15:36:03 <zigo> Don't you want to do "refreshonly" in case of Debian then?
15:36:10 <mwhahaha> so it exists but won't be executed until the item on line 400
15:36:10 <degorenko> no
15:36:13 <zigo> Like, how will it change theme in Debian?
15:36:18 <EmilienM> of anyone else has patches or bugs, please send it here
15:36:27 <degorenko> there are no changes for debian at all
15:36:29 <zigo> Is the compress called?
15:36:34 <skolekonov> no
15:36:39 <zigo> Well, it should ! :)
15:36:55 <degorenko> zigo: it will not, because it will not run
15:36:56 <zigo> To what I've experienced, when changing a theme, I need to run compress in Debian.
15:37:13 <skolekonov> That's another problem I guess
15:37:17 <skolekonov> To re-run compress
15:37:19 <zigo> Horizon guys said it wouldn't be necessary for Mitaka, but I'm not sure if the feature was implemented.
15:37:27 <zigo> Right...
15:37:48 <IvanBerezovskiy> now we don't run collectstatic&compress from module for debian, I am keeping the same approach
15:38:11 <zigo> I've voted +1 then.
15:38:20 <degorenko> \o/ nice
15:38:23 <IvanBerezovskiy> thanks
15:38:26 <EmilienM> finally
15:38:27 <zigo> But really, when switching theme, we shall re-run compress.
15:38:35 <skolekonov> Thanks, looks like we understood each other
15:38:46 <IvanBerezovskiy> EmilienM: sorry for taking to much time, but finally we've found solution
15:38:50 <EmilienM> cool -- do we have anything else for today?
15:38:54 <IvanBerezovskiy> s/to/too
15:38:56 <EmilienM> IvanBerezovskiy: no problem, meetings are here for that
15:39:03 <zigo> Well, *I* am sorry for my missunderstanding of the patch.
15:39:07 <EmilienM> and zigo will pay beers in Austin
15:39:12 <zigo> Thanks for your patience.
15:39:16 <zigo> Will do.
15:39:29 <zigo> Not sure I'll drink many myself, considering the effect it had on me today... :P
15:39:31 <EmilienM> I'll let the meeting open one more minute if someone has anything else
15:40:15 <zigo> Well, something to add: can someone add the offline compress stuff when changing theme ? :)
15:40:35 <zigo> Or was it implemented in Horizon that we don't need it?
15:40:38 <EmilienM> zigo: please file a bug in launchpad/puppet-horizon so it's in our radar - thanks
15:40:45 <EmilienM> I have no idea
15:40:47 <zigo> Will do.
15:40:53 <EmilienM> thanks folks
15:40:57 <IvanBerezovskiy> thanks
15:41:05 <EmilienM> have a nice week and take care. Also eat vegetables, it's good for you.
15:41:08 <EmilienM> #endmeeting