14:01:29 #startmeeting Puppet-Openstack 14:01:30 Meeting started Mon Nov 17 14:01:29 2014 UTC and is due to finish in 60 minutes. The chair is sbadia. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:33 The meeting name has been set to 'puppet_openstack' 14:01:42 #chairs sbadia crinkle 14:01:46 o/ 14:01:53 nibalizer: \o 14:02:04 #topic Juno branching 14:02:30 To summarize, we had some discutions the last week about juno branching in our modules 14:02:47 (a thread on puppet-openstack ML) 14:03:12 we still miss some packages in debian and redhat for testing juno (before branching) 14:03:31 and some udpate of configuration files are still in progress (reviews) 14:03:43 (sorry missed the agenda…) 14:03:51 #link https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack 14:04:31 I remember EmilienM saying that we want to have integration tests ready before the juno release 14:04:41 yep, +1 14:05:20 so how long between the branch and the release? 14:05:33 because integration tests (or at least my version of it) is still not ready 14:05:47 it was just to talk about it, but so we have some sticking points before 14:05:55 (packaging) 14:05:57 i thought the branch and the release would happen at the same time? 14:06:11 okay 14:06:16 but not sure 14:06:17 crinkle: thats what i thought too 14:06:30 there is no time constraints 14:06:35 > 6months :-D 14:06:39 < 14:06:43 i think there are packages for rhel 7 and ubuntu, not sure about rhel 6 14:07:03 gchamoul: an idea about rhel6 ? 14:08:02 anyway here is the pending review for juno conf files 14:08:06 #link https://review.openstack.org/131566 14:08:16 #link https://review.openstack.org/131576 14:08:24 #link https://review.openstack.org/131572 14:08:26 I don't we will support Juno on RHEL6 14:08:34 know ! 14:08:40 oh okay 14:08:57 we are discussing about that internally 14:09:04 but don't have any clue 14:09:41 gchamoul: okay 14:11:31 #action take a look about params updates in juno (if everything was covered by previous review) 14:11:37 ok, next point? 14:11:51 sure 14:12:06 #topic Service validation 14:12:21 i think EmilienM may be in a plane 14:12:37 nibalizer: right he is ! 14:12:45 EmilienM just submitted a new interseting patchset 14:12:52 Yep indeed :-) 14:13:55 #link https://review.openstack.org/126458 14:14:06 comment are welcome… 14:15:04 ok :) everyone sleep 14:15:13 haha 14:15:34 I think I like the hash approach 14:15:43 would be interested in mgagne's thoughts 14:16:06 yep me too! 14:16:15 arg mgagne isn't here… 14:16:57 ok, we will discuss in the review then… 14:17:20 can I add a topic about service_ensure patchs ? 14:17:34 sure 14:18:01 #Topic manage_service (bug 1359823) 14:18:02 Launchpad bug 1359823 in puppet-swift "Possibility to disable service management" [Undecided,In progress] https://launchpad.net/bugs/1359823 14:18:18 #link https://review.openstack.org/#/c/115659/ 14:20:01 I had a comment on one of those... 14:20:13 to summarize, we have some patch already merged about 1359823 14:20:30 but indeed your comment, and spredzy comment are interesting 14:20:55 I'm in agreement with spredzy 14:20:55 hey everyone, sorry no backlog on this room, sbadia could you paste a litle bit of context please :) 14:21:09 spredzy: sure! 14:22:42 sbadia, thanks 14:23:31 patchs in ceilometer, glance, heat and neutron are already merged 14:23:37 Hmm if mgagne is not here it will be hard to have its point of view on this one 14:23:55 shoot, I should have commented on all of them instead of just one 14:24:08 If a new set of patchset needs to be done it doesn't seems like a problem to me, but as a user I expect $manage_service to do what it does on the whole puppet community 14:24:13 mmagr isn't here too :( 14:24:19 I feel really strongly that manage_service == false is absolutely not the same as ensure => stopped 14:24:22 sbadia, on a place I think 14:24:37 $manage_service != $ensure_service 14:24:43 sbadia: he is on a plane too ! 14:24:44 crinkle: i agree with that position 14:25:26 so :-/ ok 14:25:30 I can propose patches to fix the ones that have already been merged 14:26:22 I don't quite understand mgagne's point about HA setup 14:26:34 me too :/ 14:26:58 maybe we can discuss with him later in #puppet-openstack 14:27:01 we can re-discuss with martin and mathieu on the ml before 14:27:04 yep! 14:27:06 ok 14:27:08 ok 14:27:36 #action sbadia shoot a mail on the ML about manage_service issue 14:27:50 next topic then 14:28:02 #Topic Integration testing 14:28:12 nibalizer: need some help? 14:28:15 hi 14:28:23 * crinkle can review that patch 14:28:26 so the problem is that beaker doesn't work 14:28:27 yet 14:28:29 https://review.openstack.org/#/c/134371/ 14:28:40 is (i hope) the last patch to make beaker + nodepool play nice 14:29:09 hopefully after that we can land https://review.openstack.org/102020 14:29:25 then this as well but not as relevant here https://review.openstack.org/126086 14:29:40 the other thing though is we'll need to add integration testing lines to each project in zuul 14:29:48 which is kinda heavy in reviews for infra and will be slow 14:30:07 oh I didn't see the patches on infra! 14:30:15 to avoid the mess I introduced with the policy.json patch, we (w/ mathieu) had the idea of trying to set up a all-in-one maniest on top of which we would run is_expected.to compile, to make sure we don;t ahve duplicaate ressource error. Its basic its a begining but would allow us to detec those issue earlier 14:30:15 ok! thx spencer! 14:31:17 spredzy: in each module? 14:31:38 sbadia: so yea its in progress and im consistently poking it 14:31:40 it costs nothing :) 14:31:57 nibalizer: thanks :) 14:32:02 long road! 14:32:04 after we get int tests working at all we can discuss further/do work to make them global 14:32:07 yes thanks nibalizer ! 14:32:10 np np 14:32:18 sbadia, there idea was to have that on infra or something (just rought idea so far), and the test will be run for each commit 14:32:34 still need to work out the specifics 14:32:58 typically that stuff would go in spec/spec_helper_acceptance.rb in the module 14:33:14 but that could potentially call out to something in infra i guess 14:33:35 or not spec_helper_acceptance but the tests themselves i think 14:34:23 so i think thats it for integration? 14:34:50 sure 14:36:08 sbadia: next? 14:36:13 ok :) 14:36:31 crinkle: do you want to talk about aviator (recents patchset)? 14:36:39 sure 14:36:50 #topic Aviator 14:37:00 #link https://review.openstack.org/#/c/134843/ 14:37:06 #link https://review.openstack.org/#/c/134844/ 14:37:14 oops i guess the first one is failing lint 14:37:25 i've started a mailing list discussion 14:37:36 not a big deal for the lint :) 14:37:39 it seems like the leaning is to go with openstackclient over aviator 14:38:03 i think nibalizer's point about it being better maintained is pretty key 14:38:23 and the developers are really open to working with us to make it usable 14:38:30 since they want people to start using it 14:38:38 my only concern with using openstackclient instead of aviator, is we'll probably be giving up some amount of performance if we don't use the API directly. 14:39:36 just a point to consider. I think there are some things can be be done to alleviate that if you're dealing with a single tool though. like token caching and such 14:40:02 i hadn't thought of that 14:40:29 i'm not sure how to measure or evaluate that 14:40:42 you'll likely always have the fork/exec/parse overhead unless openstackclient can be run as a daemon 14:41:11 well, I know for us, getting a token can take a measurable amount of time, and every cli invocation gets a new token 14:41:40 I think performance loss can be ignored in this scene 14:42:05 I don't think it's even a loss compared to the current implementation, it's just a loss compared to direct API access 14:42:17 right 14:42:32 and it'd be easier to work with the openstackclient team to implement featuers to alleviate it, than to work with all the other client teams 14:42:46 ++ 14:42:57 does openstackclinet have a real team? 14:43:12 or is it part time volunteers from all the projects? 14:43:15 i think the team is dtroyer + stevemar 14:43:22 who are keystone people i think 14:43:22 no idea here, I'd never actually heard of it until crinkle pointed it out 14:43:47 I think crinkle is right, dtroyer + stevemar mostly 14:44:12 o/ yep, a few other occasional folks too 14:44:15 ok 14:44:23 \o 14:45:08 so you can read my ML post about this for my opinon but tl;dr i think openstackclient 14:45:13 stevemar: could you comment on dvorak's performance concern? 14:45:54 but i also want to re-itrate what i said before about how maybe democracy isn't the best tool, and the people (or just crinkle ) who have been building the providers should make the call 14:46:44 just to clarify, I'm not saying not to use openstackclient, I think there is clearly a good argument for it. I just wanted to point out one downside that I hadn't seen mentioned yet. 14:47:03 sure 14:47:12 dvorak, can you re-iterate your concerns surrounding performance, i just logged on 14:47:16 dvorak: that was clear to me, thanks for bringing it up 14:48:06 nibalizer, ++ it should be up to the folks building the providers 14:48:18 stevemar: I was just pointing out that having puppet have integrated native API access is likely to be faster than interfacing with an external CLI tool. If it's internal, you don't have the overhead of fork/exec/parsing the script. You can also cache tokens across requests. 14:48:42 I imagine there are changes that could be made to openstackclient to alleviate most of those issues 14:49:47 caching should be possible, especially if you create a single interactive session (like neutrons CLI) 14:49:48 or maybe OSC already does all of that. I'll admit ignorance here. 14:50:17 nod, if the puppet interface is written to use it in that mode, then I think that addresses almost all of my concerns 14:50:57 dvorak, then you can feed it commands, dtroyer had something in the works for that i believe 14:51:13 right now our puppet runs spend a lot of time making calls out to openstack CLI commands, so anything that makes that faster makes me happy :) 14:52:26 #info possible performance considerations with openstackclient, should use its caching features 14:52:47 anything else on this? I have some stuff for open discussion 14:53:01 which is to say me-- for not putting it on the agenda 14:53:09 ok for me :) 14:53:18 i'll continue to monitor the mailing list discussion and write a new spec for using openstackclient 14:53:31 ya the ML is the right place to have this discussion 14:53:53 #topic open discussions 14:54:14 i've proposed 2 changes to infra 14:54:23 https://review.openstack.org/#/c/134835/ and https://review.openstack.org/#/c/134834/ 14:54:46 they together add the ability for zuul/infra to publish to forge using puppet-blacksmith 14:55:42 this might be more valuable for -infra than this team 14:56:03 since we really we only push to forge for major relases? 14:56:14 do we up the forge releases when we backport stuff? 14:56:17 we push on minor releases 14:56:29 how would we share forge credentials? 14:56:39 well in this system you'd have to give them to infra 14:56:46 and it actually is worse 14:57:01 puppet-blacksmith is too stupid to take a config file as a config option right now 14:57:21 so we need to patch it so it can so the trusted node can switch back and forth between the -infra credintals and puppet/stackforge creds 14:57:43 i was looking into that late last night and didn't do it 14:57:45 :/ 14:57:45 but it looks reasonable 14:58:10 are you :/ about blacksmith being stupid or giving your creds to infra? 14:58:22 the switching back and forth sounds hacky 14:58:31 yep ^^ 14:58:43 nibalizer you would not give infra your creds 14:58:51 well the trusted node would have a .puppetforge-infra.yaml and .puppeforge-stackforge.yaml 14:58:55 (we dont want them) 14:59:02 and the job would know 14:59:16 ideally you would give our user enough perms to upload for you 14:59:28 yea i think those are equivalent? 14:59:37 i think the next meeting is about to kick us out, maybe continue this in #opsntack-infra? 14:59:47 if thats acceptable to clarkb 14:59:47 spellfail 14:59:53 i kno whe has not had burrito yet 15:00:04 or #puppet-openstack 15:00:08 crinkle: +1 15:00:15 thanks everyone! 15:00:20 thanks everyone 15:00:23 thx 15:00:28 o/ 15:00:29 #endmeeting