14:59:53 <mfisch> #startmeeting puppet
14:59:53 <openstack> Meeting started Tue Jul 21 14:59:53 2015 UTC and is due to finish in 60 minutes.  The chair is mfisch. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:59:57 <openstack> The meeting name has been set to 'puppet'
15:00:07 <mfisch> Emilien is out so he asked me to run it
15:00:16 <sbadia> o/
15:00:22 <mwhahaha> o/
15:00:23 <mfisch> We have a light agenda today
15:00:26 <mfisch> #link https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150721
15:00:26 <gchamoul> o/
15:00:44 <mfisch> #link agenda https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150721
15:00:49 * mfisch does not know the commands ;)
15:00:50 <vinsh> o/
15:00:57 <bogdando> o/
15:00:58 <clayton> here
15:01:05 <richm> hello
15:01:07 <sbadia> #topic :)
15:01:28 <mfisch> #topic old actions
15:01:45 <mfisch> The first one is the midcycle. We decided last week that it would be virtual
15:02:03 <mfisch> The agenda is still light, so please add to it
15:02:06 <mfisch> #link https://etherpad.openstack.org/p/puppet-liberty-mid-cycle
15:02:53 <mfisch> Second item is OpenStack integration CI. Emilien and pabelanger are working on this, but I dont think either is here
15:03:01 <mfisch> Does anyone have any updates on that topic?
15:03:14 <richm> There is a problem with tempest and v3 - I'm working on that today
15:03:37 <bogdando> #topic OpenStack integration CI
15:03:41 <bogdando> please
15:03:48 <mfisch> #topic OpenStack integration CI
15:03:51 <mfisch> yep thanks for the reminder
15:04:10 <mfisch> richm: whats the issue?
15:04:34 <richm> v3 works fine until the tempest tests start, then v3 auth stops working
15:05:19 <richm> or, to be more correct, doing v2 auth with users in the default domain stops working
15:05:28 <mfisch> Was there a patch recently about this?
15:05:32 <richm> it works fine up until the tempest tests start
15:05:44 <richm> yes, there is a patch currently out for review, that is not working
15:06:05 <richm> https://review.openstack.org/198561
15:06:41 <mfisch> there's a similar patch out there for a module that seemed hacky to me, I will look for it
15:07:18 <richm> there is a patch for puppet-tempest too
15:07:27 <mfisch> maybe that was it
15:07:34 <mfisch> it's doing a search and replace for v3 to v2.0
15:07:34 <richm> https://review.openstack.org/#q,Ia173e37cfdb1f4470780b7cbac4383b2ea86a142,n,z
15:07:50 <richm> hmm - ok - I will be debugging that today
15:07:56 <mfisch> thanks richm
15:08:04 <mfisch> okay next topic
15:08:15 <mfisch> #topic bp/enabling-federation
15:08:20 <mfisch> iurygregory: go ahead
15:08:22 <iurygregory> Hello people ^^
15:08:34 <iurygregory> I would like to discuss about the spec Enabling Federation (#link https://review.openstack.org/#/c/190361/)
15:09:13 <iurygregory> we already have some cards in trello about the efforts needed.  I would like to know if the current patch for the spec covers everything.
15:09:42 <iurygregory> Yesterday I talked to richm and we think is ok
15:09:45 <richm> yes
15:10:14 <mfisch> iurygregory: so what are you looking for, more feedback or +2 or both?
15:10:26 <iurygregory> both mfisch
15:10:41 <richm> both, yes
15:10:42 <iurygregory> if i need to add something i'll be glad to do it
15:10:56 <richm> and it probably needs a review by one of the Keystone devs
15:11:01 <mfisch> thats a good idea
15:11:10 <mfisch> iurygregory: can you reach out to someone from keystone on it?
15:11:26 <iurygregory> Rodrigo is dev in Keystone and work with federation ^^
15:11:31 <mfisch> perfect
15:11:39 <richm> ah, ok - then he has already reviewed it
15:11:56 <iurygregory> yes he give a +1
15:12:19 <iurygregory> i'll talk with him to know more keystone devs to review the spec too =)
15:12:21 <mfisch> okay so you need some +2 from here or more feedback
15:12:35 <mfisch> #link https://review.openstack.org/190361
15:12:53 <mfisch> please take a look everyone
15:13:18 <mfisch> iurygregory: anything else?
15:13:30 <iurygregory> nothing, thanks mfisch
15:13:35 <richm> note that the items in the trello - groups, identity providers, federation, etc. - are based on that bp, and work already done in other projects to enable Keystone federation
15:14:01 <mfisch> richm: where's the trello link?
15:14:11 <iurygregory> #link https://trello.com/b/4X3zxWRZ/on-going-effort
15:14:25 <saneax> Greeting folks
15:14:49 <mfisch> okay moving on
15:14:56 <mfisch> #topic default parameter policy
15:15:00 <mfisch> spredzy: go ahead
15:15:37 <spredzy> This week I've sent an email to the ML about an issue mgagne raised on a review about the value picked for meaning absent
15:15:52 <spredzy> #link https://review.openstack.org/#/c/202574/
15:16:06 <spredzy> If empty string isn't suitable
15:16:26 <spredzy> I wanted to get feedback on what string we should put here instead
15:16:31 <clayton> I thought setting a parameter to an empty string was the same as setting it to undef from a puppet 3.x standpoint anyway?
15:16:32 <mfisch> heat also has a setting that can be an empty string
15:16:41 <clayton> is that incorrect?
15:16:59 <spredzy> clayton, you can set an empty string
15:17:08 <clayton> ok, sounds like I'm wrong then :)
15:17:08 <spredzy> empty string is different than undef
15:17:26 <mfisch> clayton: this is legal
15:17:26 <mfisch> heat_config { 'DEFAULT/instance_user': value => ''; }
15:17:33 <spredzy> my worry is that even if we put nil
15:17:38 <spredzy> for example as the default value
15:17:52 <spredzy> what tells us no parameter in the whole openstack projects doesn't take 'nil' has a valid value
15:17:55 <richm> mfisch: what does that look like in the heat config file?
15:17:56 <clayton> I'd prefer something that's less likely to come up in real case.  <DEFAULT VALUE> or some such
15:18:07 <spredzy> instance_user=
15:18:08 <mfisch> richm: it looks like instance_user=
15:18:17 <mwhahaha> if we set undef as default value and the option does not accept undef, we should be checking for undef and erroring in puppet
15:18:28 <richm> and oslo.config parses that into CONF.instance_user == ''?
15:18:40 <spredzy> mwhahaha, the purpose here was to try to avoid the if $myvar { } else { } pattern
15:18:45 <spredzy> to make the manifest more readable
15:18:48 <mwhahaha> validate_string($myvar)
15:18:48 <mfisch> the heat case specifically is a special case
15:18:53 <mwhahaha> validate_array($myvar)
15:19:05 <spredzy> and not ask every contributor to do that for each and every new parameter
15:19:14 <mfisch> clayton has a good idea <PUPPET UNSET DEFAULT> or something
15:19:21 <xarses> spredzy: maybe a custom validate function that will wrap the logic?
15:19:39 <pabelanger> o/
15:20:07 <clayton> it just seems like we should be able to shove into the iniffile provider somewhere code that say something like if ! $value then ensure = 'absent'
15:20:07 <bogdando> IMHO, it would be nice to have a special value for every parameter in Oslo.config, which will hust raise an exception "Not configured"
15:20:16 <bogdando> just*
15:20:20 <mwhahaha> it would be advisable to add stricter validation to new (and existing) parameters
15:20:29 <bogdando> so we could use this as a defult in configuration management
15:20:33 <clayton> mwhahaha: perhaps, but this is a separate issue
15:20:35 <_ody_> o/
15:21:08 <mwhahaha> true, but if we use undef as our goto value for things and we know it's a required param, just validate it
15:21:12 <mattymo1> what does it mean when yo guys say o/ in the middle of a discussion?
15:21:20 <mattymo1> s/yo/you
15:21:20 <clayton> mattymo1: raising their hand
15:21:26 <spredzy> mwhahaha, xarses the idea here is really not to validate a parameter rather than have a unique way of setting a parameters that can set or unset if without and if and else block
15:21:29 <clayton> i.e. I'm here
15:22:09 <mfisch> it made me think you guys had a question ;)
15:22:16 <mwhahaha> spredzy: yes i get that, but is not using undef for this a better way as validation/checking exists elsewhere around undef specifically
15:22:33 <mwhahaha> if we are using some custom text string, that seems hokey and openstack specific
15:22:40 <clayton> yes, we all agree
15:22:44 <mfisch> is there a better way?
15:22:49 <sbadia> :)
15:22:49 <spredzy> problem with undef, is that it cannot be treaten
15:23:00 <spredzy> value: undef basically means skip me
15:23:11 <spredzy> for the ini_setting provider
15:23:12 <mwhahaha> i would argue that should be changed
15:23:14 <saneax> I guess the idea is to flag the module this is undefined and handle it?
15:23:31 <mwhahaha> where undef means don't define this value, ie remove it if exists
15:23:40 <xarses> spredzy: ok, so then are we back to creating some way to override inifile so that it can be seeded with some 'this value actually means make it absent'
15:23:43 <spredzy> this behavior is puppet specific, we can't change it
15:24:02 <spredzy> it might evolve in puppet 4 if I got it right but we're stuck with it in puppet 3.x
15:24:04 <bogdando> don't define this value != remove it if exists
15:24:23 <xarses> mwhahaha: we relie on undef == not set in multiple modules already
15:24:27 <spredzy> bogdando, we want to try to avoid the if/else check
15:24:35 <xarses> s/relie/rely
15:24:37 <mwhahaha> i know we use it, i just don't like it
15:24:42 <mwhahaha> :)
15:24:44 <bogdando> yes, got it. Could we just hide this to the ini provider?
15:24:55 <mattymo1> I'm in favor of using a key word of either absent or purged. there's no need to use these values anywhere in legit config
15:24:56 <angdraug> the problem with changing puppet's conventions is that every newcomer will be stumped by it
15:25:15 <bogdando> but we should make it also backwards compatible
15:25:21 <bogdando> or keep it so
15:25:51 <clayton> angdraug: I think we all agree that this solution is ugly, but the consensus in the past was that it was less ugly than 5 lines of if/else block which is the alternative
15:26:02 <bogdando> like, if undef meant "don't care" before, we should not change defaults to the "remove it"
15:26:18 <bogdando> as that would be not backward compatible
15:26:24 <xarses> so, we add some initialization parameter that can set the magic word for this modules inifile (or in the infile provider config for the file) and then hack on inifile implementation?
15:26:35 <spredzy> bogdando, I am not sure if we pass value: undef to the our config, it will go create the parent provider or will just skip it
15:26:49 <clayton> bogdando: This would be chagned in the next major release.  In theory it should be no change in behavior, since all those existing paramters we have in the manifests are already set to the upstream defaults
15:26:58 <angdraug> clayton: I'm just arguing in favor of magic word instead of undef
15:27:00 <bogdando> looks like a good action item to check against ini provider unit tests
15:27:07 <bogdando> how it behaves
15:27:18 <mfisch> I think the magic word is probably the best solution we have too
15:27:30 <bogdando> yes, magic words are good
15:27:34 <mwhahaha> i don't like the magic word unless it can be some explicit define
15:27:37 <iurygregory> ++
15:27:37 <spredzy> can we open up a vote maybe ?
15:27:43 <spredzy> here or in the ML
15:27:50 <spredzy> jsut to make sure the community agrees
15:27:53 <spredzy> and have a trace
15:28:05 <mfisch> I think here gets more traffic
15:28:15 <clayton> I don't think we really need a vote since to date no one has figured out how to make undef work
15:28:17 <mwhahaha> is the absent (no quotes) word special in puppet?
15:28:23 <mwhahaha> or does it get translated to a string
15:28:28 <clayton> mwhahaha: no, it's translated to a string
15:28:31 <mwhahaha> :/
15:28:41 <mwhahaha> to me i want something like that
15:28:41 <spredzy> mwhahaha, no but '' is valid so it can't be used
15:28:55 <mwhahaha> thats why i like undef because it actually has special meaning in the dsl
15:29:15 <xarses> mwhahaha: except undef already means not set
15:29:15 <clayton> I'd propose '<SERVICE DEFAULT>'
15:29:22 <xarses> instead of absent if not configured
15:29:34 <clayton> if services ever use that, let's file a bug against them.
15:29:48 <mfisch> <SERVICE DEFAULT> is somewhat self-explanatory
15:29:54 <spredzy> clayton, +1
15:30:06 <angdraug> +1
15:30:10 <mattymo1> I thought we wanted to suggest a purged value... not even service default?
15:30:15 <clayton> alternatively, if there are any characters we know that oslo.config doesn't properly handle in values, let's use that.
15:30:26 <spredzy> purged value will end up in service default
15:30:35 <mattymo1> oh right
15:30:36 <spredzy> if the param is not set, then it will use service default
15:30:38 <angdraug> lets not rely on other software's bugs
15:31:04 <mfisch> Why not propose somethign and run it by the OSLO team?
15:31:13 <mfisch> I cant see them using <SERVICE DEFAULT> for anything
15:31:14 <xarses> why dont we do something similar to the default setting method used in OCF scripts ? https://github.com/stackforge/fuel-library/blob/master/files/fuel-ha-utils/ocf/ns_haproxy#L36-71
15:31:27 <xarses> except probably in a one line function
15:31:43 <xarses> that would change the state to absent instead of set
15:32:30 <spredzy> xarses, not sure I see the whole picture here :/
15:32:40 <clayton> xarses: can you give us an example?
15:32:45 <xarses> I'll try to mock something up
15:33:52 <mwhahaha> seems like we're working around the ini file provider, can't we just extend that?  honestly from a templated file standpoint undef is normal for a value you don't want
15:33:53 <clayton> I'd suggest we have spredzy send an email to the list with suggestions for magic string and if people have strong opinions about other options we can have a CIVS vote or some such
15:34:02 <clayton> otherwise we go with <SERVICE DEFAULT>
15:34:26 <mfisch> I would like to wrap this up since I dont think we'll have a conclusion right now, so an email follow-up is a good idea
15:34:29 <bogdando> so, a magic word '<SERVICE DEFAULT>'. +1 for that to replace undef.
15:34:42 <spredzy> I will send the email with clayton suggestion
15:34:45 <mfisch> thanks spredzy
15:34:50 <mfisch> anything else on this?
15:34:51 <spredzy> xarses, please do answer with the mock you come up with
15:34:54 <xarses> mwhahaha: that thought from last week was that we need to get something to work before taking it back to puppet-inifile
15:35:01 <xarses> spredzy: it will take some time
15:35:19 * mwhahaha shrugs
15:35:24 <spredzy> xarses, ack, if you want just to draw the big picture in the email so people can grasp the idea
15:35:28 <spredzy> and have an opinion about it
15:35:29 <mwhahaha> i just see '<SERVICE DEFAULT>' full of typos
15:35:31 <mwhahaha> and not validatable
15:35:38 <spredzy> mainly so we can decide
15:35:40 <xarses> spredzy: but ya,
15:35:48 <bogdando> but it would be nice to ensure oslo.config will raise if it parses '<SERVICE DEFAULT>' out
15:36:12 <clayton> bogdando: agreed
15:36:14 <mattymo1> mwhahaha, not everyone types with mistakes 100% of the time
15:36:23 <spredzy> it will never parses it ad it will never get there
15:36:40 <spredzy> the idea is that id the value is '<SERVICE DEFAULT>' ensure => absent
15:36:49 <spredzy> so it should never end up in any configuration file
15:36:50 <bogdando> understood
15:37:01 <bogdando> but... you know
15:37:07 <bogdando> bugs happen
15:37:21 <clayton> spredzy: bogdando's suggestion would ensure no one using oslo.config could ever make <SERVICE DEFAULT> a valid value
15:37:48 <spredzy> ok got it my bad
15:38:00 <spredzy> mfisch, I think we can move to next topic will send the email to the ML
15:38:04 <mfisch> thanks spredzy
15:38:15 <mattymo1> spredzy, +1
15:38:19 <mfisch> #topic gerrit dashboard & disagreements
15:38:23 <mfisch> angdraug: this is you
15:39:20 <angdraug> I've proposed a change for the gerrit dashboard:
15:39:29 <angdraug> #link https://review.openstack.org/#/c/203903/
15:39:42 <sbadia> good idea
15:39:51 <angdraug> I think this should prevent reviews with a -2 from falling through the cracks
15:39:54 <mfisch> the problem is summarized on the mailing list but can you give a brief angdraug
15:39:58 <mfisch> hah good timing
15:40:03 <angdraug> )
15:40:15 <angdraug> I've identified a handful of examples that this query pulls up
15:40:29 <angdraug> we may go through all of them as an excercise and see how it works
15:40:42 <clayton> +1, I see no harm in adding it.
15:40:49 <angdraug> although it looks like we'll have to wait for emilien to come back to unblock them
15:41:01 <angdraug> #link https://review.openstack.org/190548
15:41:12 <angdraug> this one was discussed extensively on the same ML thread
15:41:13 <mfisch> +1 from me too
15:41:22 <spredzy> +! for me, find the idea really nice
15:41:30 <sbadia> yep and he is in pto :-/
15:41:30 <spredzy> +1*
15:41:47 <angdraug> to me it looks like emilien never noticed that his concern was addressed, probably because of ^^^ :)
15:41:47 <mfisch> I'm not familiar with how the dashboard is made, anyone can make one right?
15:42:19 <xarses> mfisch: correct, its based from custom url strings
15:42:28 <clayton> mfisch: yes, this patch is adding it to the examples in gerrit-dash-creator
15:42:42 <angdraug> mfisch: yes, all you do is run ./gerrit-dash-creator dashboard/puppet-openstack.dash and it will give you a url
15:42:50 <mfisch> I think we should just generate this one and make it our default
15:43:14 <angdraug> afaiu http://ghostcloud.net/openstack_gerrit_dashboards/ is generated from all dashboards in that repo
15:43:36 <bogdando> sounds great
15:43:37 <mattymo1> The value of a team dashboard is so that everyone can get a clear picture together. your gerrit default dashboard is not so well organized
15:43:38 <iurygregory> +1
15:43:50 <angdraug> btw as we discussed with mfisch yesterday we might want to add dashboard link to the wiki landing page like we did in fuel
15:43:58 <angdraug> #link https://wiki.openstack.org/wiki/Fuel#Development_related_links
15:44:02 <mfisch> angdraug: it was added this morning
15:44:28 <mfisch> so what are the actions on this? It needs to merge but we should also update the default goo.gl link too I think
15:44:30 <angdraug> ah, nice
15:44:54 <angdraug> I'd say wait for it to merge, shouldn't take too long, it already as +1's
15:45:00 <mfisch> ok
15:45:00 <angdraug> then update goo.gl link
15:45:20 <mfisch> after it merges sbadia can you update the link?
15:46:10 <mfisch> I can do it actually if sbadia is afk
15:46:20 <mfisch> #action mfisch to update review dashboard link after https://review.openstack.org/#/c/203903/ merges
15:46:26 <mfisch> I forgot to action spredzy and the ML :(
15:46:35 <mfisch> angdraug: anything else on this one?
15:46:41 <angdraug> no
15:46:47 <mfisch> thanks
15:46:50 <mfisch> #topic review throughput
15:46:51 <spredzy> #action spredzy send mail to the ML about '<SERVICE DEFAULT>' magic string
15:47:01 <angdraug> unless you want to go through reviews I linked, but I think they have to wait for Emilien
15:47:19 <mfisch> This is a friendly reminder to cores to please do reviews, I know some reviews have been sitting for awhile, so take a look this week
15:47:29 <mfisch> angdraug: I dont think it would be useful w/o him
15:48:15 <mfisch> I dont really need a discussion on that just want to reduce the backlog we have. I did a bunch yesterday and I think clayton did too based on my inbox
15:48:24 <mfisch> and we're running out of time, so I want to move on
15:48:37 <mfisch> #topic designate hooks patch (https://review.openstack.org/#/c/197172/)
15:48:40 <mfisch> clayton: ^
15:49:07 <clayton> I've sent an email about this and it's gotten one +2 so far.  I just wanted to bring it up again in case any one had questions or concerns about this approach
15:49:23 <clayton> assuming the designate patch is merged I suspect we would start working on a similar patch for keystone or heat
15:49:30 <mfisch> I am +2 as well but its not cool for me to merge your stuff unless its trivial
15:50:04 <clayton> nod, I was hoping emilien and/or colleen would have a chance to look at it again
15:50:08 <sbadia> mfisch: oups sorry, yep afk, sure, I'll update the link/wiki
15:50:34 <mfisch> neither is here today
15:51:05 <clayton> np, I'm ok with moving on then if no one has any questions or concerns
15:51:24 * sbadia trie to take a look also
15:51:40 <mfisch> this is our last topic, thanks sbadia
15:52:03 <sbadia> np :)
15:52:19 <mfisch> okay we have 8 mins left, anyone have a burning issue, bug, or review?
15:52:59 <mfisch> going once, twice...
15:53:12 <spredzy> hehe
15:53:18 <sbadia> seems ok :)
15:53:29 <mfisch> okay thanks everyone have a good week, enjoy your 7 minutes back
15:53:32 <mfisch> #endmeeting