15:30:14 <j^2> #startmeeting openstack-chef
15:30:15 <openstack> Meeting started Thu Dec  4 15:30:14 2014 UTC and is due to finish in 60 minutes.  The chair is j^2. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:30:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:30:18 <openstack> The meeting name has been set to 'openstack_chef'
15:30:22 <j^2> Hey everyone!
15:31:19 <libsysguy> hey hey
15:31:25 <markvan> Howdy
15:31:48 <openstackgerrit> Jan Klare proposed stackforge/cookbook-openstack-network: Handle nil and empty string for cafile  https://review.openstack.org/136089
15:32:01 <j^2> I only have one thing i’d like to specificly talk about, is there anything you’d like to discuss? (open to everyone)
15:32:23 <libsysguy> yeah, I'd like to talk about ssl in the dashboard cookbook
15:32:46 <j^2> cool, any other topics?
15:32:58 <jklare> hey
15:33:38 <j^2> going once….
15:33:50 <jklare> is it allowed to +2 a change when i rebased it?
15:34:20 <j^2> the rule is “never +2” anything you have commited/changed or something like that
15:34:34 <j^2> in that spirt no i don’t think so
15:34:59 <j^2> ok, cool
15:35:13 <j^2> #topic ssl in the dashboard cookbook
15:35:22 <libsysguy> oh right to it then
15:35:22 <j^2> libsysguy: the floor is yours
15:36:13 <libsysguy> awesome.  Well I have been spending some time with the apache2 cookbook recently.  I noticed that we handle ssl in a strange way in that cookbook (assuming some paths, file names, etc)
15:36:37 <libsysguy> I was wondering if there would be a problem re-implementing ssl with something like: https://supermarket.chef.io/cookbooks/ssl_certificate
15:37:21 <libsysguy> we seem to be doing a lot of logic that seems to be implemented (more completely) in that cookbook
15:37:25 <j^2> leveraging it as a dependancy?
15:37:29 <libsysguy> yes
15:37:41 <j^2> is there an LWRP in there? I haven’t looked
15:38:03 <libsysguy> yes, ssl_certificate
15:38:20 <j^2> this sounds like a blueprint ;)
15:38:28 <libsysguy> definitely
15:38:44 <libsysguy> I was just unclear on what the policy was for deps, etc
15:38:55 <j^2> leveraging an LWRP to make our life easier seems like a good idea in general
15:39:03 <libsysguy> but I'd be happy to get in a spec
15:39:04 <markvan> Looks like a good way to go.
15:39:14 <j^2> traditionally? I have no idea, but i’m in the camp that this seems like a great idea
15:39:41 <markvan> Note that we have SSL in many places, like for MQ, and potentially each service
15:40:03 <libsysguy> I'l definitely like to leverage this everywhere
15:40:12 <markvan> so, starting with something like dashboard sounds reasonable, and then we can expand from that integration kionledge
15:40:19 <libsysguy> s/I'l/I'd/
15:40:19 <j^2> markvan: starting with the dashboard then we could move out to the rest of the cookbooks right?
15:40:29 <markvan> yup
15:40:53 <j^2> wow, it sounds like we are in agreement we should make this happen :P
15:41:01 <libsysguy> excellent
15:41:02 <markvan> The next obvious question:  is this a big enough change that we might consider it for kilo and not in juno?
15:41:40 <libsysguy> ah yes, I think we are close enough to the cut that it should get pushed to Kilo
15:41:49 <jklare> +1
15:42:08 <markvan> yes, I was thinking kilo here as well
15:42:12 <j^2> markvan: kilo
15:42:17 <j^2> we can do a vote :P
15:42:31 <libsysguy> do eet
15:42:43 <j^2> libsysguy: can you take the action item to make the blueprint? to start mapping this out?
15:42:50 <libsysguy> for sure
15:43:03 <libsysguy> action on all cookbooks or just the dashboard?
15:43:55 <j^2> #action libsysguy will start a blueprint for the inital mapping of gettting the ssl_cert cookbook in dashboard
15:43:58 <markvan> imo the bp/spec can cover dashboard in detail and maybe just point out that it can be done in the other cookbooks like for MQ.
15:44:07 <j^2> markvan: great idea
15:45:15 <j^2> :)
15:45:53 <libsysguy> it's added to my notebook as a todo :)
15:46:33 <j^2> cool, next topic?
15:46:49 <markvan> how about that infra change?
15:46:57 <j^2> #topic infra change
15:47:03 <j^2> markvan: floor is yours
15:47:07 <markvan> https://review.openstack.org/#/c/137134/
15:47:34 <markvan> Looks like Sean has stepped in here...and that usually means we need to change to make any more progress.
15:48:09 <j^2> :-/
15:48:51 <markvan> using "experiemental"   in job name is not going to fly, as it's the queue name and jobs can be placed in any queue.
15:49:23 <markvan> so if we call this just 'gate' job  is that good enough for now?
15:49:40 <j^2> i’m looking for the inline comments
15:50:03 <libsysguy> didn't the name have some significance as to how it was processed?
15:50:06 <j^2> The experimental in the name is intentional (also not syntactically needed) because as soon as this works smoothly we will just add another gate-{name}-chef-rake job (and delete the other three [lint,style,unit]) so we can run the gate job on the testes distros and use the experimental for the new distro releases.
15:50:34 <jklare> ^^
15:50:57 <jklare> i guess we can change the name if it hurts somebody
15:50:58 <j^2> i don’t really have an opinion here honestly
15:52:36 <j^2> any other thoughts?
15:52:52 <libsysguy> none from me - The Infra Newb
15:53:39 <j^2> maybe jklare can you add a note explaining (again) why you chose experimental?
15:53:47 <j^2> maybe that’ll suffice
15:53:51 <jklare> i am currently talking to sdague
15:54:02 <j^2> awesome
15:54:04 <jklare> i will figure out if we have to rename it or not
15:54:05 <jklare> :)
15:54:46 <markvan> humm, I think we should go with another name and stay away from experiemental.   maybe draft-gate-rake....  and then the gate-rake  ?
15:55:11 <j^2> oh, i like that
15:55:21 <j^2> draft is a great naming scheme
15:56:50 <j^2> cool, anyother thoughts on this?
15:57:51 <j^2> #topic client-cookbook
15:57:58 <j^2> this is the only thing i wanted to bring up :)
15:58:12 <j^2> we need another +2 from a core on it
15:58:20 <j^2> sorry
15:58:23 <j^2> +1 on the workflow
15:58:30 <j^2> https://review.openstack.org/#/c/126365/
15:58:45 <j^2> so we can have the begining of our client-cookook
15:59:02 <j^2> i also started on the neutron portion, and i wanted to get it on peoples radar
15:59:12 <j^2> neutron: https://review.openstack.org/#/c/138845/
15:59:48 <j^2> it semes i’ve never really wrapped my head around creating LWRPs, so this is a great learning experience for me, and anyone else who wants to learn them
16:00:06 <j^2> challenge is…I don’t know if i’m going off the rails here
16:00:26 <j^2> can i get some eyes on it to see if it’s at all in line on what it needs to be?
16:00:39 <j^2> thoughts comments?
16:00:58 <markvan> Yeah for neutron lwrp, I thought Fog handled this:  https://github.com/fog/fog/blob/master/lib/fog/openstack/network.rb  and you just need some simple wrappers here.
16:01:49 <j^2> markvan: yep that seems like the correct path
16:02:08 <j^2> i was starting with just shelling out to neutron, then going to try to create the wrappers
16:02:21 <libsysguy> so the client is just a lwrp wrapping fog?
16:02:28 <j^2> that’s the gist yeah
16:02:49 <j^2> that whole cookbook’ll be lwrps for things you want to do with your openstack cluster leveraging fog basicly
16:02:51 <markvan> not sure if there's a lighter way to use Fog directly
16:03:06 <libsysguy> yeah that is my thought
16:03:18 <libsysguy> but I am generally against wrappers :p
16:03:40 <j^2> yeah same here, but this gives resources to do “normal” openstack configurations
16:04:00 <j^2> make a network, make a vm, upload a object etc etc
16:04:02 <markvan> I just don't know if there's a way to avoid the basic lwrp definition
16:04:42 <j^2> and as mattray mentioned this is gains for two camps, users and builders of openstack
16:04:53 <markvan> so the lwrp "wrapper" should be pretty thin and leave the logic in the Fog library
16:05:16 <j^2> markvan: yep, basicly we tie the attributes to the options that the fog object would want
16:05:24 <j^2> then we converge :)
16:05:41 <j^2> example: https://review.openstack.org/#/c/138845/1/resources/neutron_network.rb
16:06:20 <j^2> the network creation only needs a name for the network, but the shared and external options are flipable
16:06:29 <markvan> I guess I don't mind the basic idea, but really want to keep the logic and guts in Fog such that it can change under us without have to fix lwrp all the time
16:07:02 <j^2> markvan: agreed, leverage fog to do the heavy lifting, i’m totally with you on this
16:07:57 <markvan> humm, one thing I noticed was the need for passing in all the user creds/url stuff, is there a way to push that into a common lwrp that can be used within this one?  such that each wrapp focuses on just the arrts they need?
16:08:04 <j^2> the challange as stated before though, is i’m not great at writing LWRPs, so any coding suggestions, eyes, would be helpful
16:08:25 <j^2> markvan: totally, i’me just trying to get the framework though
16:08:35 <j^2> markvan: i feel like that’s bikeshedding it ATM
16:08:43 <j^2> i just want something that works
16:08:57 <j^2> red green refactor ftw
16:09:55 <j^2> anyone have any suggestions on LWRPs that leverage a gem as the backend like fog?
16:10:10 <j^2> i havent done the research, that was something taht popped in my head this morning
16:10:25 <libsysguy> nothing from me
16:11:03 <j^2> there has to be something out there
16:11:09 <j^2> i’ll do some research and come back
16:11:33 <j^2> this is a dependancy to the testing-framework as i mentioned in the hangout, so i’m focusing hard on it
16:12:17 <markvan> yeah, should be someting out there.  also would like to understand if lwrp's can be subclassed, so you could put all the cred stuff up a level and leverage that by all the component specific ones
16:12:29 <jklare> OT: so i talked to sdague and clarkb and they suggested to name the job gate-{}-chef-rake, place it in the experimental queue and test the rake change on precise first. If we wanna also test on trusty later, we should create something like trusty-{}-chef-rake and place it in the experimental again.
16:13:06 <j^2> markvan: yeah theres no reason why you couldn’t do that, i just havent yet
16:13:57 <j^2> jklare: interesting
16:14:09 <markvan> jklare: interesting putting platform in the name
16:15:43 <j^2> cool, last topic, our catch all
16:15:51 <j^2> #topic General Discussion
16:16:03 <j^2> 15 mins, then i’ll bring this to a close, floor is open
16:17:33 <markvan> jklare: I guess I really prefer not to put trusty in the name, but maybe that's a discussion for later.   We can get the initial rake get in and working on precise, and then maybe clone that as the precise-gate-{}-chef-rake
16:17:57 <markvan> so we keep the generic for working with latest, like trusty or whatever?
16:18:50 <j^2> i think that’s a good idea
16:18:56 <jklare> i was thinking about reducing my change to basically adding a gate-{}-chef-rake job which runs also on precise and in the experimental queue
16:19:01 <markvan> or do even want to play with precise here?  goal is to get to trusty, why not just start there in first place?
16:19:02 <j^2> generic names are our generic tests
16:19:35 <jklare> after we get that in and running we can push it to trusty
16:19:44 <jklare> and discuss how to name it :)
16:20:09 <j^2> os-chef-bot: ping
16:20:09 <os-chef-bot> PONG
16:20:34 <markvan> humm, but do we need to waste the time getting precise working if it's not going to be used?    we want trusty for stable juno branch right?
16:20:36 <j^2> generic names are our generic tests
16:20:39 <j^2> i like that idea
16:20:43 <jklare> i think we should not go the other way around and add all the jobs to trusty in experimental queue, since thats a lot of code which we need to delete later
16:21:31 <jklare> i am not sure if my initial patch is a good idea, since it will basically try to address 2 different issues at once
16:21:45 <jklare> and we know how agile one can work in the infra project..
16:21:49 <j^2> heh
16:22:01 <markvan> jklare: I don't follow, why need to delete later.  we want trusty support as the goal, precise is just what were using now to make basic merges work.
16:22:36 <jklare> markvan: so we wanna solve 2 things: using rake; testing on trusty
16:22:59 <j^2> jklare: and that's feeling like two patches
16:23:03 <markvan> yup, and have that as default for juno
16:23:26 <jklare> markvan: if we do both at once we might run into more errors than we want to have and are able to solve in juno
16:24:01 <jklare> markvan: if we try to push for trusty first, then we need to add 3 additional jobs (since we dont have rake) for each cookbook
16:24:09 <markvan> yeah, that's a possibility, but I think it's worth trying that route first.
16:24:43 <jklare> so you would go for just renaming the job and sticking to solving 2 things at once?
16:25:36 <markvan> yup, that was my idea here.  trusty should not be that bad to get working with rake.
16:25:56 <j^2> 5 mins
16:27:16 <j^2> chaching! guys
16:27:18 <j^2> #link https://github.com/stevendanna/cookbook-r/blob/master/providers/package.rb
16:27:31 <j^2> ^^^ a "simple" example for the LWRP
16:27:48 <j^2> i'll be updating my code here soon
16:28:34 <jklare> markvan: ok, but i will remind you on this 'should not be that bad' ;)
16:28:52 <jklare> any other thoughts?
16:28:56 <markvan> let the fireworks begin...
16:29:22 <j^2> :)
16:29:59 <j^2> unless there is anything else anyone would like to bring up, i'd like to welcome libsysguy as a core reviewer again; and thanks for everyones time
16:30:19 <j^2> #endmeeting