14:32:16 <jklare> #startmeeting openstack_chef
14:32:17 <openstack> Meeting started Mon May  4 14:32:16 2015 UTC and is due to finish in 60 minutes.  The chair is jklare. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:32:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:32:21 <openstack> The meeting name has been set to 'openstack_chef'
14:32:31 <jklare> hello again
14:32:38 <j^2> o/
14:32:46 <sc`> \o
14:33:08 <jklare> so we are 3 right now i guess
14:33:28 <jklare> @core would be great if you all could join our meeting right now
14:33:28 <os-chef-bot> @j^2 @markvan @mattray @wenchma @jklare @cmluciano @zhiwei would be great if you all could join our meeting right now
14:33:32 <j^2> :)
14:33:43 <jklare> so i guess we can start with the topic on the board
14:33:51 <markvan__> hi
14:34:09 <jklare> #topic previous business
14:34:29 <jklare> so j^2 i guess you wrote that?
14:34:36 <aspiers> hi
14:34:46 <j^2> yeah
14:34:57 <j^2> i was trying to think of a template
14:35:09 <j^2> we’ll always have previous business right ;)
14:35:59 <sc`> c7 still requires some modifications to common to start to converge. still working on getting a converge
14:36:09 <jklare> ok, so we could probably discuss the progress of things from the previous meeting here, or add these things as topic by themselfes
14:36:23 <sc`> that's my 'old business' :)
14:36:33 <j^2> works for me
14:37:01 <jklare> the chefdk patches were all merged (except for chef-repo)
14:37:17 <jklare> until now i did not see any issues with the new gates
14:37:36 <sc`> which version of chefdk?
14:37:38 <jklare> the openstack-chef-repo patch is pushed and will hopefully be merged soon
14:38:04 <markvan__> for ubuntu, still have the outstanding libvirt issue: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1439280
14:38:04 <openstack> Launchpad bug 1439280 in nova (Ubuntu) "Libvirt CPU affinity error" [Undecided,Confirmed]
14:38:35 <jklare> sc` 0.4.0
14:39:04 <jklare> anything else for this topic?
14:39:06 <sc`> ok. was just curious since 0.5.0 was just released, followed up immediately by 0.5.1 that includes chef-client 12.3.0
14:39:14 <jklare> cool
14:39:31 <sc`> 12.3.0 has socketless chef-zero in local-mode
14:39:33 <jklare> does it include the new fauxhai version?
14:39:34 <markvan__> yup, chefdk 5.1 is out....I as going to run a quick test with it to see how we stack up against it
14:40:16 <markvan__> don't know about fauxhai yet
14:40:18 <sc`> jklare: no. 2.3.0 is still as it is from rubygems.org
14:40:48 <jklare> ok, so we still need to keep our workaround for this in common
14:40:53 <sc`> fauxhai needs a version bump for chefdk to pick it up out of the box, otherwise it still has to be worked around to get 7.1.json
14:41:22 <sc`> no reason to change common at this time
14:41:45 <jklare> ok, i guess we can move to the next topic?
14:41:45 <j^2> can some one take an action item to follow up on pushing the fauxhai
14:42:31 <j^2> jklare: sounds good
14:42:39 <jklare> and then there was silence
14:42:41 <jklare> ...
14:42:49 <jklare> ok next topic then
14:42:51 <sc`> i could take that on, but i feel it shouldn't be me
14:43:19 <jklare> #topic aspiers suse ha slides
14:43:36 <jklare> aspiers you still there?
14:43:36 <aspiers> http://www.slideshare.net/adamspiers/ha-cookbooksupstream in case anyone hasn't seen them yet
14:44:28 <aspiers> most of the slides are an FYI so you guys know what we're doing, but I would also love feedback on a way forward
14:44:48 <jklare> iirc the main point here was if and how we could include these ha cookbooks in the project (or link them properly)
14:45:30 <aspiers> yes, there is the question of sharing the HA core cookbooks
14:45:43 <aspiers> but there is also the question of how to handle HA-enabling of the OpenStack cookbooks
14:45:43 <sc`> ha reference deployments are definitely needed. it's still mostly documentation and When You Know You Know
14:46:05 <sc`> i'd toggle ha itself with a node attribute
14:46:05 <aspiers> sc`: SUSE OpenStack Cloud is the reference deployment ;-)
14:46:11 <sc`> aspiers: :)
14:46:30 <aspiers> actually, it's the only way to use them right now
14:46:39 <aspiers> since you need the synchronization primitives, and currently that requires Crowbar
14:47:02 <sc`> nod
14:47:03 <markvan__> yeah, unfortunately when we went looking into HA support early last year, we had some issues with how to use these, so we have gone can done our own pacemaker cookbook.  My team has seen your slides and is encouraged to see the progress made.
14:47:22 <aspiers> essentially doing HA support properly requires a good degree of orchestration
14:47:29 <aspiers> including synchronization primitives
14:47:39 <jklare> so for now we could just include a link to this slides in our documentation?
14:47:41 <aspiers> and the other challenge is how to cleanly insert sync points into the upstream cookbooks
14:48:04 <aspiers> see slides 31-32 in particular
14:48:09 <jklare> and maybe create a proper blueprint for enabling ha from our cookbooks
14:48:45 <jklare> somebody willing to do that?
14:48:54 <sc`> aspiers: off the top of my head, i thought something like zookeeper or consul might make a good stand-in. haven't tested the theory yet :)
14:49:10 <aspiers> sc`: maybe, I don't know enough about them
14:49:14 <markvan__> the issue with direct HA enablement within our cookbook means doing it with a narrow approach, which probably won't work for us.
14:49:30 <aspiers> markvan__: what do you mean by narrow approach?
14:49:45 <sc`> it's definitely a very prescriptive approach, whichever way it is
14:50:03 <markvan__> I think we need to instead focus on the HA building blocks that could be placed in the up stream cookbook and let folks handle HA in their own ways build on top
14:50:27 <sc`> +1. the orchestration bits can be left up to the implementer
14:50:32 <jklare> +1 for that markvan__
14:50:54 <jklare> but i think we should create a blueprint for this one
14:50:54 <aspiers> markvan__: sure - the corosync/pacemaker cookbooks provide the LWRPs and other building blocks, without being opinionated about the deployment technique
14:51:09 <aspiers> the LWRPs are definitely reusable right now
14:51:16 <aspiers> we just need to tidy up the git repo and CI stuff
14:51:29 <aspiers> and ideally extract a gem for the pacemaker bindings
14:52:40 <jklare> aspiers sure, but for now these things are a bit out of scope of the openstack chef stackforge projects i guess
14:53:04 <markvan__> My team is still digesting your slides, but I will ask them to start getting more involved with HA as it relatest to the upstream cooksooks.
14:53:22 <aspiers> jklare: yeah they are certainly not OpenStack-specific
14:53:40 <aspiers> so what's the best location for them?
14:53:45 <aspiers> if not stackforge?
14:54:10 <sc`> if they're agnostic enough, supermarket might make a good place
14:54:17 <sc`> but then you miss out on gerrit
14:54:30 <jklare> sc` sure, but someone has to care for them
14:54:31 <aspiers> github review is good enough for me TBH
14:54:43 <aspiers> SUSE is actively maintaining these
14:54:48 <aspiers> they are a core part of our product
14:54:59 <aspiers> and already deployed in production by big customers
14:55:07 <markvan__> right now, we have built a full HA on top of the existing cookbooks, so I'm a bit worried about making upstream HA changes without considering current use cases for users.
14:55:25 <aspiers> markvan__: is your implementation public?
14:55:33 <markvan__> yeah, I would like to see them get into the supermarket.
14:55:48 <cmluciano> are there any guards that you have been putting in place when adding the sensitive flag? Wasn’t sure if there was a backwards compatible way to do this
14:56:06 <markvan__> aspiers: not yet, that is our next step, to push out what we have so we can compare with your techniquies, especailly for pacemaker
14:56:36 <aspiers> the main challenge right now is that we are maintaining all our HA cookbooks under a single repo: https://github.com/crowbar/barclamp-pacemaker/tree/master/chef/cookbooks
14:56:50 <aspiers> this is easier for us but obviously sucks from an upstream perspective
14:57:01 <aspiers> since they are independent of Crowbar
14:57:08 <sc`> https://review.openstack.org/#/c/173415/14/attributes/default.rb
14:57:11 <aspiers> (except the crowbar-pacemaker cookbook, of course)
14:57:12 <sc`> toggle something like that
14:57:17 <markvan__> yeah, that makes them hard to use and find.  I think supermaket is the right fit for these types of cookbooks
14:57:31 <sc`> node['openstack']['ha']['enabled'] or something like that
14:58:00 <aspiers> sc`: we already do that https://github.com/crowbar/barclamp-keystone/blob/master/chef/cookbooks/keystone/recipes/server.rb#L66
14:58:27 <sc`> gotcha
14:58:27 <aspiers> SUSE Cloud does not enforce mandatory use of Pacemaker / HA
14:58:34 <aspiers> it's totally optional
14:58:39 <sc`> that's definitely the way i'd go
14:58:46 <sc`> provide the means, but don't enforce it
14:59:07 <aspiers> but polluting existing OpenStack cookbooks with "if ha_enabled" is ugly, which is why long term I suggest splitting them up into smaller recipes at sync points
14:59:14 <aspiers> as per slide 31
14:59:36 <aspiers> then you could have wrapper cookbooks
15:00:04 <sc`> yep. may even make sense to do some further refactoring of existing cookbooks to pair down the size of some of the recipes, but that's not for today
15:00:09 <aspiers> right
15:00:39 <aspiers> so are there any suggestions on a location for these cookbooks? TBH I could even host them under https://github.com/aspiers
15:00:56 <aspiers> or does supermarket actually provide git hosting?
15:01:02 <aspiers> I thought it was just a directory
15:01:12 <sc`> supermarket is just an index, so you'd have to use a github account somewhere
15:01:17 <aspiers> right
15:01:32 <aspiers> so I think this is probably the way to go then
15:01:33 <jklare> ok, maybe to summon this up we could agree that we do not include these cookbooks as part of the stackforge project for now, but would like to see them available via the supermarket. in addition to that someone should probably create a blueprint for ha-enablement so we could discuss the details of that without exceeding the frame of this meeting
15:01:43 <sc`> aspiers: yeah. that makes sense
15:01:55 <markvan__> jklare: +1 good summary
15:02:03 <aspiers> jklare: +1, and I offer to help reviewing that blueprint
15:02:22 <aspiers> although I don't know enough about upstream options for synchronization / orchestration to be able to write it myself
15:02:48 <jklare> ok, anybody else wants to take a action item for this blueprint?
15:03:41 <jklare> i see
15:04:00 <jklare> ok, i will try to create an more or less open one so we can beginn a discussion there
15:04:06 <aspiers> cool
15:04:16 <jklare> next topic?
15:04:36 <jklare> #topic core-members
15:05:21 <jklare> i basically added this one to open a dicussion about the process of adding new core members and evertyhing around it
15:05:49 <jklare> until now we do not have any defined process for adding new cores
15:06:25 <jklare> which lead to j^2 just adding members when they were participating in iirc and reviewing changes
15:06:43 <jklare> but since we are moving to the official openstack processes
15:06:50 <jklare> we probably should rethink this
15:07:12 <j^2> Agreed
15:07:14 <jklare> and define a way how to add core reviewer and maybe some guidelines for them
15:07:44 <jklare> there is this short infra guideline here http://docs.openstack.org/infra/manual/core.htm
15:07:58 <jklare> +l
15:08:09 <j^2> Maybe start an etherpad that we can dump what we think we should do?
15:08:24 <jklare> +1
15:08:42 <sc`> agreed. transparency is ever crucial
15:09:43 <sc`> i feel this is needed for the project to continue to prosper
15:10:05 <markvan__> I think the openstack process for cores is here: https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
15:10:34 <jklare> here is the etherpad https://etherpad.openstack.org/p/openstack-chef-core-reviewer-discussion
15:11:58 <sc`> though it wasn't my intention to spawn this topic, it's for the best
15:12:53 <jklare> ok, do we want to continue or start the discussion here and now or on the etherpad and during the next meeting?
15:13:04 <sc`> should probably take it to etherpad at this point
15:13:24 <sc`> unless we have time
15:14:07 <jklare> ok then lets move this topic to the etherpad
15:14:17 <jklare> any more topics to add?
15:14:48 <jklare> btw. shouldnt we be doing this meeting in an official meeting room?
15:16:38 <jklare> mhhh... ok maybe we can find out until next time
15:16:38 <sc`> there is a specific channel for that, isn't there?
15:16:52 <jklare> there are official openstack meeting rooms
15:17:16 <jklare> ok, if there are no additional topic i would end the meeting
15:17:24 <sc`> it'd make sense to use openstack resources
15:17:51 <jklare> #endmeeting