14:32:16 #startmeeting openstack_chef 14:32:17 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:32:21 The meeting name has been set to 'openstack_chef' 14:32:31 hello again 14:32:38 o/ 14:32:46 \o 14:33:08 so we are 3 right now i guess 14:33:28 @core would be great if you all could join our meeting right now 14:33:28 @j^2 @markvan @mattray @wenchma @jklare @cmluciano @zhiwei would be great if you all could join our meeting right now 14:33:32 :) 14:33:43 so i guess we can start with the topic on the board 14:33:51 hi 14:34:09 #topic previous business 14:34:29 so j^2 i guess you wrote that? 14:34:36 hi 14:34:46 yeah 14:34:57 i was trying to think of a template 14:35:09 we’ll always have previous business right ;) 14:35:59 c7 still requires some modifications to common to start to converge. still working on getting a converge 14:36:09 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 that's my 'old business' :) 14:36:33 works for me 14:37:01 the chefdk patches were all merged (except for chef-repo) 14:37:17 until now i did not see any issues with the new gates 14:37:36 which version of chefdk? 14:37:38 the openstack-chef-repo patch is pushed and will hopefully be merged soon 14:38:04 for ubuntu, still have the outstanding libvirt issue: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1439280 14:38:04 Launchpad bug 1439280 in nova (Ubuntu) "Libvirt CPU affinity error" [Undecided,Confirmed] 14:38:35 sc` 0.4.0 14:39:04 anything else for this topic? 14:39:06 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 cool 14:39:31 12.3.0 has socketless chef-zero in local-mode 14:39:33 does it include the new fauxhai version? 14:39:34 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 don't know about fauxhai yet 14:40:18 jklare: no. 2.3.0 is still as it is from rubygems.org 14:40:48 ok, so we still need to keep our workaround for this in common 14:40:53 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 no reason to change common at this time 14:41:45 ok, i guess we can move to the next topic? 14:41:45 can some one take an action item to follow up on pushing the fauxhai 14:42:31 jklare: sounds good 14:42:39 and then there was silence 14:42:41 ... 14:42:49 ok next topic then 14:42:51 i could take that on, but i feel it shouldn't be me 14:43:19 #topic aspiers suse ha slides 14:43:36 aspiers you still there? 14:43:36 http://www.slideshare.net/adamspiers/ha-cookbooksupstream in case anyone hasn't seen them yet 14:44:28 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 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 yes, there is the question of sharing the HA core cookbooks 14:45:43 but there is also the question of how to handle HA-enabling of the OpenStack cookbooks 14:45:43 ha reference deployments are definitely needed. it's still mostly documentation and When You Know You Know 14:46:05 i'd toggle ha itself with a node attribute 14:46:05 sc`: SUSE OpenStack Cloud is the reference deployment ;-) 14:46:11 aspiers: :) 14:46:30 actually, it's the only way to use them right now 14:46:39 since you need the synchronization primitives, and currently that requires Crowbar 14:47:02 nod 14:47:03 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 essentially doing HA support properly requires a good degree of orchestration 14:47:29 including synchronization primitives 14:47:39 so for now we could just include a link to this slides in our documentation? 14:47:41 and the other challenge is how to cleanly insert sync points into the upstream cookbooks 14:48:04 see slides 31-32 in particular 14:48:09 and maybe create a proper blueprint for enabling ha from our cookbooks 14:48:45 somebody willing to do that? 14:48:54 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 sc`: maybe, I don't know enough about them 14:49:14 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 markvan__: what do you mean by narrow approach? 14:49:45 it's definitely a very prescriptive approach, whichever way it is 14:50:03 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 +1. the orchestration bits can be left up to the implementer 14:50:32 +1 for that markvan__ 14:50:54 but i think we should create a blueprint for this one 14:50:54 markvan__: sure - the corosync/pacemaker cookbooks provide the LWRPs and other building blocks, without being opinionated about the deployment technique 14:51:09 the LWRPs are definitely reusable right now 14:51:16 we just need to tidy up the git repo and CI stuff 14:51:29 and ideally extract a gem for the pacemaker bindings 14:52:40 aspiers sure, but for now these things are a bit out of scope of the openstack chef stackforge projects i guess 14:53:04 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 jklare: yeah they are certainly not OpenStack-specific 14:53:40 so what's the best location for them? 14:53:45 if not stackforge? 14:54:10 if they're agnostic enough, supermarket might make a good place 14:54:17 but then you miss out on gerrit 14:54:30 sc` sure, but someone has to care for them 14:54:31 github review is good enough for me TBH 14:54:43 SUSE is actively maintaining these 14:54:48 they are a core part of our product 14:54:59 and already deployed in production by big customers 14:55:07 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 markvan__: is your implementation public? 14:55:33 yeah, I would like to see them get into the supermarket. 14:55:48 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 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 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 this is easier for us but obviously sucks from an upstream perspective 14:57:01 since they are independent of Crowbar 14:57:08 https://review.openstack.org/#/c/173415/14/attributes/default.rb 14:57:11 (except the crowbar-pacemaker cookbook, of course) 14:57:12 toggle something like that 14:57:17 yeah, that makes them hard to use and find. I think supermaket is the right fit for these types of cookbooks 14:57:31 node['openstack']['ha']['enabled'] or something like that 14:58:00 sc`: we already do that https://github.com/crowbar/barclamp-keystone/blob/master/chef/cookbooks/keystone/recipes/server.rb#L66 14:58:27 gotcha 14:58:27 SUSE Cloud does not enforce mandatory use of Pacemaker / HA 14:58:34 it's totally optional 14:58:39 that's definitely the way i'd go 14:58:46 provide the means, but don't enforce it 14:59:07 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 as per slide 31 14:59:36 then you could have wrapper cookbooks 15:00:04 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 right 15:00:39 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 or does supermarket actually provide git hosting? 15:01:02 I thought it was just a directory 15:01:12 supermarket is just an index, so you'd have to use a github account somewhere 15:01:17 right 15:01:32 so I think this is probably the way to go then 15:01:33 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 aspiers: yeah. that makes sense 15:01:55 jklare: +1 good summary 15:02:03 jklare: +1, and I offer to help reviewing that blueprint 15:02:22 although I don't know enough about upstream options for synchronization / orchestration to be able to write it myself 15:02:48 ok, anybody else wants to take a action item for this blueprint? 15:03:41 i see 15:04:00 ok, i will try to create an more or less open one so we can beginn a discussion there 15:04:06 cool 15:04:16 next topic? 15:04:36 #topic core-members 15:05:21 i basically added this one to open a dicussion about the process of adding new core members and evertyhing around it 15:05:49 until now we do not have any defined process for adding new cores 15:06:25 which lead to j^2 just adding members when they were participating in iirc and reviewing changes 15:06:43 but since we are moving to the official openstack processes 15:06:50 we probably should rethink this 15:07:12 Agreed 15:07:14 and define a way how to add core reviewer and maybe some guidelines for them 15:07:44 there is this short infra guideline here http://docs.openstack.org/infra/manual/core.htm 15:07:58 +l 15:08:09 Maybe start an etherpad that we can dump what we think we should do? 15:08:24 +1 15:08:42 agreed. transparency is ever crucial 15:09:43 i feel this is needed for the project to continue to prosper 15:10:05 I think the openstack process for cores is here: https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess 15:10:34 here is the etherpad https://etherpad.openstack.org/p/openstack-chef-core-reviewer-discussion 15:11:58 though it wasn't my intention to spawn this topic, it's for the best 15:12:53 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 should probably take it to etherpad at this point 15:13:24 unless we have time 15:14:07 ok then lets move this topic to the etherpad 15:14:17 any more topics to add? 15:14:48 btw. shouldnt we be doing this meeting in an official meeting room? 15:16:38 mhhh... ok maybe we can find out until next time 15:16:38 there is a specific channel for that, isn't there? 15:16:52 there are official openstack meeting rooms 15:17:16 ok, if there are no additional topic i would end the meeting 15:17:24 it'd make sense to use openstack resources 15:17:51 #endmeeting