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