15:00:09 #startmeeting puppet-openstack 15:00:10 Meeting started Tue Jul 28 15:00:09 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:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:14 The meeting name has been set to 'puppet_openstack' 15:00:20 hi 15:00:22 #link agenda: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150728 15:00:30 ahoy 15:00:50 Greetings! 15:01:17 let's start our usual dance 15:01:20 #topic Review past action items 15:01:29 hi 15:01:44 hello 15:02:01 mfisch to update review dashboard -> DONE : updated on http://ghostcloud.net/openstack_gerrit_dashboards/ 15:02:24 spredzy send mail to the ML about '' magic string Done - Link : http://lists.openstack.org/pipermail/openstack-dev/2015-July/070602.html 15:02:25 hi 15:02:34 o/ 15:02:38 hello o/ 15:03:02 I was not here in the last meeting but I guess it was the 2 actions 15:03:12 #topic CI status 15:03:52 I would like some feedback on https://review.openstack.org/#/c/199712/ 15:04:00 it aims to get logs for our Puppet jobs 15:04:58 maybe it needs more work or maybe it's good as it 15:05:20 any thoughts? 15:06:02 About https://review.openstack.org/#/c/199712/13/spec/acceptance/basic_keystone_spec.rb 15:06:14 can that just be rolled into a rake task or something? 15:06:22 Jiri Stranskiy's comment seems valid 15:06:38 o/ 15:06:46 bogdando, mwhahaha: indeed, rake seems also a good option 15:07:00 I will investigate that way, thanks 15:07:26 in CI, we also made progress on tempest integration: https://review.openstack.org/#/c/198561 15:07:38 +1 for the rake task, it's not realy a test 15:07:55 thanks to Matthew (tempest PTL) and richm, we got simple code and it works quite good now 15:08:04 sbadia: ack, will update :) 15:08:26 nice for 198561 ! 15:08:28 #action EmilienM to update https://review.openstack.org/#/c/199712/ to use Rake instead of acceptance 15:08:48 and the last sub-item, is openstack integration 15:09:04 pabelanger: can you summarize a status? any blockers? 15:10:15 EmilienM: not really. Just working on getting our basic integration tests going. For the most part, just working to get the gate job going right now. Dealing with some gem issues, since some don't need to be installed when we actually run the puppet code 15:10:31 Hi all 15:10:32 diving into bundle install --without logic 15:10:53 mhh, why does it work for all our puppet beaker jobs? 15:11:28 well, reality is, you are installing un needed gems when you actaully launch beaker from the looks of it. 15:11:37 so, if you have a beaker gate job, you really don't need lint gems 15:11:57 so, you'd run bundle install --without development test 15:12:11 I think it's common to break the Gemfile into groups for that 15:12:23 eg https://github.com/puppetlabs/puppetlabs-inifile/blob/master/Gemfile#L21 15:12:36 right 15:13:00 but I'm looking at the installed gems when I run bundle install, it is pulling in both development and system_tests by default 15:13:27 either way, just testing things now for integration module, since we only really need r10k 15:13:29 pabelanger: have you reported the bug in LP ? 15:13:41 EmilienM: not yet, just figured it out this morning 15:13:44 and need to dive deeper into it 15:13:53 pabelanger: ok, good catch. Please do so we can track this work 15:14:41 we already slit the gems in our gemfile 15:14:47 haha but only in modulesync :) 15:14:55 hum. 15:15:01 and the initial msync wasn't launched yet :) 15:15:05 it's time to be consistent, isn't? 15:15:12 of course! 15:15:33 a thread has been launched earleir this afternoon http://lists.openstack.org/pipermail/openstack-dev/2015-July/070769.html 15:15:38 about that exact matter 15:15:44 sbadia: can you take an action to 1/ sync with pabelanger if msync/Gemfile is correct 2/ sync the files using msync across all modules? 15:15:49 https://github.com/openstack/puppet-modulesync-configs/blob/master/config_defaults.yml#L19 15:16:01 trying to sync with infra how we can use the same tooling to keep modules in sync 15:16:45 EmilienM: ok, of course 15:16:53 spredzy: nice, will read up on it today 15:17:10 #action sbadia & pabelanger: figure out Gemfile split in our modules 15:17:16 #action sbadia launch a initial msync on all our modules (ping cody) 15:17:17 pabelanger, ack thanks :) 15:17:23 thanks guys 15:17:36 pabelanger: anything else about openstack integration? 15:18:58 do we want to discuss using beaker or not for integration tests with the broader group? 15:18:58 EmilienM: not too much right now. Once I get the gate job working, we can flip that to voting. Then, we can really dive into how the puppet modules layout will look. I have a simple scenario001.pp going local, but expect much feedback on it in the coming days 15:19:43 crinkle: we can discuss about that now, we have the time I guess 15:20:06 pabelanger: cool. I would just re-use the keystone/acceptance/wsgi manifest which is IMHO a good start 15:20:45 so the question is: 15:21:00 do we want beaker jobs to gate puppet-openstack-integration repo? 15:21:12 like we gate other modules 15:21:40 I thought we had decided no? 15:21:54 we talked about this 15:22:05 we did, I was wondering if anyone else wanted to give input 15:22:17 I agree with no 15:22:20 the questions could also be: do we want to support this repo only in the openstack infra gate or could it be run on anyone's laptop too 15:22:59 crinkle: we disagreed and then agreed to say "no" for now until we get more experience with that thing. I think we can iterate later if we need to change that 15:23:04 it could still be run by developers, they just have to find their own vm to run it on instead of having vagrant provision it for them 15:23:31 EmilienM: ++ 15:23:34 the only thing I really want is: 15:23:51 Right, there is a single launch script, run_tests.sh, that will get the box setup to run. You just need to make sure you have a clean system to run it on. 15:23:53 if I submit a patch in scenario001.pp in puppet-openstack-integration repo, I would like a job that actually run this manifest and test it. 15:23:57 This is like how devstack works today 15:24:22 so until now, we're good in our design 15:24:48 it seems like we can go ahead if no more thoughts 15:24:49 okay let's proceed in this direction and iterate if necessary 15:24:55 cool 15:24:58 ! 15:25:07 #topic keystone v3 status 15:25:26 I created the topic just before the meeting so we can have a quick summary from richm 15:25:29 richm: o/ 15:25:33 support for groups is well under way - https://review.openstack.org/#/c/202409/ 15:25:38 need some reviews 15:25:39 just checking if you're aware of any blockers 15:26:30 trusts is proving to be difficult - having to support the self.instances/self.prefetch paradigm means figuring out a way to identify trusts uniquely - https://review.openstack.org/200996 15:26:40 gildub is still trying to figure that out 15:27:01 chem ran into a bug with identity providers - https://review.openstack.org/202689 15:27:17 it seems that openstackclient is printing python unicode strings instead of plain csv output 15:27:35 he will workaround with some ruby code hacks 15:27:56 I guess osclient would need to be from liberty, not kilo, right? 15:28:08 EmilienM: right, so the bug is not a blocker 15:28:23 well, if we can't test it now, it's a blocker to me 15:28:29 The Keystone devs are giving iurygregory pushback on the federation spec 15:28:32 we need to figure out if we can use Liberty packaging now 15:28:34 EmilienM: he can test it now 15:28:39 AFIK it's in a bad shape for RDO 15:28:50 richm: everything? 15:28:55 pushback? 15:29:23 The Keystone devs apparently want a lot more in the federation spec, and possibly they want to have a spec per provider 15:29:28 yes =/ 15:29:50 I'm waiting for a response to my query from the Keystone dev who nack'd the spec 15:30:00 We have agree that one spec is fine for federation 15:30:25 iurygregory: have you spoken to Marek? 15:30:54 not yet richm, 15:31:01 iurygregory: ok, no problem 15:31:05 after the keystone meeting i'll talk to him 15:31:09 richm: maybe check with ayoung too ? 15:31:22 ok 15:31:57 so summary - please review https://review.openstack.org/200996 and https://review.openstack.org/202409 15:32:21 I need to update/rebase https://review.openstack.org/176150 15:32:26 richm: ok thanks 15:32:42 I would like that review to be the "template" for the v3 conversion of the remaining puppet modules 15:33:03 nice 15:33:11 that's it from me 15:33:22 great 15:33:28 agenda is done 15:33:28 so 15:33:38 #topic open discussion, reviews and bug triage 15:33:45 #link https://review.openstack.org/157004 15:34:09 there's been a new -1 on this today from bogdando, but we still need to clarify the state of -1 from EmilienM 15:34:37 EmilienM: can you have a look and confirm whether only bogdando's comment remains to be addressed? 15:35:30 angdraug: I'll drop my -1 15:35:37 thanks! 15:35:38 I agree with bogdando though 15:35:42 yeah, me too 15:35:55 * sgolovatiuk nods 15:36:23 nothing else on the "disagreements" inbox section atm 15:36:39 cool, we're all happy then 15:36:50 any further comment on liberty? 15:36:56 IBerezovskiy: I read your comment 15:37:19 and we can't add 'liberty only' features while we're installing kilo in beaker 15:37:43 we need liberty packaging in our CI and we need it stable, because if it's beaking everyday, we'll have to revert and come back to kilo 15:38:02 I've heard liberty packaging is still very unstable in RDO 15:38:12 EmilienM, usually we do additional CI 15:38:13 I did some testing for UCA on keystone and it looks better now 15:38:21 sgolovatiuk: we? 15:38:28 one for Kilo and one for liberty 15:38:32 Mirantis 15:38:41 that kinda goes back to my point on the supporting multiple release mail (that I've neglected) 15:38:43 and do ab testing 15:38:59 EmilienM: Is it possible to participate this activity somehow? I mean packaging 15:39:20 xarses: for the reasons I mentioned, this is not possible 15:39:28 IBerezovskiy: packaging? We rely on RDO & UCA 15:39:46 ok, got it 15:40:02 there's also this: https://review.openstack.org/185187 15:40:19 xarses and I are talking about http://openstack-dev.openstack.narkive.com/og1yAf8j/puppet-supporting-two-openstack-releases-in-the-same-puppet-release 15:40:27 not sure if it's going to become stable faster than rdo, but imho worth watching 15:41:03 EmilienM: afaiu sgolovatiuk's point was that we could set up parallel non-voting beaker tests based on liberty packages 15:41:07 angdraug: I'm working close to packstack team, I'm checking with them. I think it's close to have something "stable" enough 15:41:29 angdraug: this is not that easy, our acceptance tests hardcode the version of OpenStack 15:41:55 ping 15:42:26 do we have anything else outstanding for today? 15:43:32 not related to puppet-openstack, but the thuesday (the 30/07) it's the puppet hack 15:43:36 #link https://puppetlabs.com/blog/join-us-puppethack-july-30 15:44:01 Thursday sorry… 15:44:14 sbadia: nice! I'll be there 15:44:33 maybe we can sync each others for who can participate? 15:44:40 me too, and spredzy also 15:44:43 yep! 15:44:44 I am registered 15:45:13 Hunner, _ody_, crinkle: do you also participate? 15:45:39 I won't be able to be online the whole day 15:46:24 I close the meeting in 1 minute, please raise your hand if we missed something 15:46:38 Yep! 15:46:57 Most likely I'll just have time to help other people, but not actually hack much though 15:47:21 And it's "open season" so openstack modules are totally in-bounds :) 15:47:45 Hunner: hehe :-) 15:47:55 Hunner: nice 15:48:09 Hunner: do you know the status of getting the modules 'Approved' ? 15:48:30 EmilienM: I can check on that and ping back in #puppet-openstack 15:48:36 Hunner: cool thx 15:48:38 I'll close the meeting by congratulating spredzy for his involvement in our group, I guess he'll be promoted (looking at vote results) 15:49:00 have a great day everyone, see you on #puppet-openstack ! 15:49:03 later 15:49:11 EmilienM, thank you for offering my name, and thanks all the voter for your +1 15:49:19 #endmeeting