14:30:07 #startmeeting openstack_chef 14:30:07 Meeting started Mon May 11 14:30:07 2015 UTC and is due to finish in 60 minutes. The chair is j^2. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:30:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:30:10 The meeting name has been set to 'openstack_chef' 14:30:19 hey everyone! 14:30:45 i got my pour over coffee going and i’m ready to chair this meeting :D anyone around? 14:31:18 howdy 14:31:45 i’ll give everyone like 5 mins to check in then i’ll start with the agenda, cool? 14:33:04 k 14:34:47 #topic c7 repository 14:34:59 sc`: do we have any updates? 14:35:59 he’s probably still asleep, no worries 14:36:12 #topic libvirtd on ubuntu 14:36:21 markvan: do we have any movement here? 14:38:14 i’d like to get through the previous business so we can move on to pressing matters :) 14:39:02 @core anyone around? 14:39:02 @j^2 @markvan @mattray @wenchma @jklare @cmluciano @zhiwei anyone around? 14:39:03 j^2: there was an recent update with a proposed patch. but no feedback from ubuntu team on that yet 14:39:14 o/ 14:39:27 markvan: nice, than’s still progress, so that’s a plus then :) 14:39:42 I was going to tryout that patch today and post my results to help move this along, it's only 3 lines of code 14:40:36 and it's right in the middle of the Nova libvirt driver....so I wonder why other folks are not seeing this issue unless ubuntu has muked up the nova code 14:40:41 nice that’s great news, with the realse of kilo last week the earlier we can be moving on stable/kilo the better 14:40:49 o/ 14:42:02 can i take detour real fast? so i have the agenda up under irc at the moment, maybe we should update the agenda as we go through it so you can just copy paste what you write here to there? 14:42:32 sounds reasonable 14:43:00 nice 14:43:01 sure 14:43:07 sorry, back on track then :) 14:43:33 so that’s good, net-net positive movement on libvirtd which is gatting us for ubuntu 14:43:49 #topic fauihai 14:44:03 sc`: any update on fauxhai? 14:44:23 markvan: that can be you too ;) 14:46:08 #topic Thursday Meeting, is it still needed? 14:46:24 so its meeting now :D ? 14:46:40 ha! well played 14:47:08 i am in favor of a second meeting on thursdays to keep both meeting short 14:47:30 No update on fauxhai, still at version 2.3 14:47:54 yup, I like having Thur meeting 14:47:55 jklare: i really don’t think we need two meetings 14:48:33 to you point last week it was only created because we werent on irc all the time, and iirc markvan wanted to make sure people all met at a time at least twice a week 14:49:36 cmluciano, sc` any opinion on the thursday meeting ? 14:49:41 it’s a lot of overhead for two short meetings, i’d prefer one 60 min meeting, and honsestly have it on thrusday, though we conflict with the chef-hacking meeting which could be annoying in the longrun 14:50:03 i would acutally hate a 60min irc meeting 14:50:05 yeah, your right, having a second meeting was trying to help with timezones 14:50:07 i really don’t know what we should do here 14:50:11 that sounds like a lot 14:50:11 i think short meetings are much more effective 14:50:36 #vote 14:50:40 so rather have 2 times a 15-20min meeting sound much more attractive to me then a 60min one 14:50:41 damn 14:51:06 since we have at least 3 cores from non US times zones, I tihnk the 2nd meeting should be at their convenience and yeah keep it short 14:52:04 ok, so when should that be? 14:53:03 i could try to sync up with our friends from china and find a suitable time with them 14:53:34 or you could do the same thing without anyone from europe i guess 14:53:48 so basically the monday meeting is fine for europe and usa 14:53:54 jklare: that would be great, please post any proposed times that yall think of, and we can make a best effort to be there too 14:54:13 and thursday would be for asia and either europe or usa 14:54:26 yeah, would be nice to have one of the other non-US cores pick a good time for them and run a short meeting. 14:54:37 so this dovetails into an important point, this requires us to move this meeting to an openstack-meetingroom ASAP 14:55:19 and we’d have to be posted at that time, so we could have the offical one that is sactioned there, and then the “standup” 15 minute meeting later in the week? 14:56:06 that sounds ok to me 14:56:18 ok 14:56:19 any objections? 14:56:43 #topic offical time change for the meeting 14:57:03 this goes to the next step which is we need to move to the top of the hour 14:57:23 so 1600GMT according to the ML is ok, any last min objections? 14:57:39 no its fine 14:58:03 with this i can take an action item to get us in the offical meeting room, and update the relivant channels, *horrible pun there* 14:59:08 @core any other questions concerns? 14:59:08 @j^2 @markvan @mattray @wenchma @jklare @cmluciano @zhiwei any other questions concerns? 14:59:32 +1 14:59:36 not regarding this topic 14:59:49 i’ll give a min then jklare we’ve got your topics to go through 15:00:32 #topic Version bumps in master branch 15:00:41 jklare: go ahead 15:01:11 this one is acutally just something i thought about while going through some reviews 15:01:27 i was wondering why we are sometimes bumping the versions in master and sometimes dont 15:01:49 i thought we agreed a while ago that we do not want to bump the versions in master anymore 15:01:59 the only time we should bump master/development branch is when there a intra-dependency between cookbooks that needs to be called out. 15:02:02 it’s true it’s completly arbitrariy to the point where it really doesnt matter on master branch 15:02:17 and that is usually between Common and some other cookbook. 15:02:26 We have this all doc;d to some extent in the wiki 15:02:33 so it seems we have three different view points here 15:03:18 markvan: i thought it was best effort on master branch, stable we’re extremely explicit, but master not so much 15:03:28 Since we don't publish our cookbook (like in supermarket), there's no current need for fix versions to be bumped. 15:03:41 i thought we could just set the dependencies in master to the specific major version bump after the stable release 15:03:54 For master we DO bump the Minor version when some new major feature is added 15:04:27 ah 15:04:30 why? 15:04:45 semver because it’s additional work 15:04:52 jklare: ^^ 15:05:18 i do not get it j^2 ? 15:05:52 when you add a new feature, you add a x.Y.z bump, work = feature in this context 15:06:06 sure, but thats for stable things 15:06:06 It's more of a convience/communication method to others to be aware that something big went in, but it only happens in rare cases right now. So, we're trying to keep master clean of messing with versions unless we need them for dependencies (Berks files). 15:06:11 and if you do releases 15:06:21 we acutally do not do any releases from master 15:06:31 jklare: it’s all changes offically, we just enforce it for stable 15:06:56 Berks does not handle dependencies correctly without version change or commit level locks 15:07:27 ok, so i’d like to give 3 more mins for this topic, then we need to move on, we can table this for the next meeting 15:07:32 Berks does not handle dependencies correctly without version change or commit level locks 15:07:44 berks install will just install the latest version available in the master branch i think 15:07:48 * markvan finger check... 15:08:22 jklare: unless you tell it otherwise that is correct, but you can do the ~> matches and what not if you want 15:08:36 berks is bundler ;) 15:08:46 jklare: ytup, but that's only for the gates...on your local box it really helps to have the dependencies done with versions, else need to blast all cookbook each time 15:10:07 so yeah technically we don't need to bump the versions ever in master....but we decided a while back that dependency ones would be helpful for developer sanity... 15:10:26 #topic stable/kilo branching outlook 15:10:51 ok, we can do that, but for me it usually not completely obvious when to bump version here 15:10:53 with the release of kilo last week we need to be looking at stable/kilo sooner than later 15:11:28 jklare: check out the wording in the wiki, and maybe we can imrpove it and give more examples of when it would be needed to bump. 15:11:39 markvan: great idea 15:11:45 ok 15:12:21 so stable/kilo, thoughts? 15:12:31 Yup, first step to look at stable/kilo would be a walk thru on bugs and blueprints and see if anything is critical and not done. Then we can start closing down the remaing patches 15:13:10 we’re gated by the upsream distros, but i think we can start looking at the blueprints, and move forward with any low hanging fruit 15:13:55 maybe we could have a short session in vanvouver for that? 15:13:55 maybe we can take some time at the summit next week, verifying these together and get a game plan? 15:14:02 jklare: exactly 15:14:12 yeah, the upstream distros have been difficult dependency for us. would like to try some different approaches to that. 15:14:38 we can spend the dev meeting time walking through the bp and bugs together 15:14:55 it would be nice to have an actual agenda unlike paris 15:15:07 any objections to our dev time for that? 15:15:08 yeah, summit is great time to prep release for branching to stable. in mean time we can do thru bugs/blueprints and at least put our latest status in them. 15:15:27 markvan +1 15:15:33 j^2 +1 15:15:42 awesome 15:16:16 #topic gate jobs 15:16:21 jklare: you have the floor 15:16:24 ty 15:16:51 so this came up when i was looking at the broken gates for the openstack-chef-repo and what they actually should do 15:17:20 right now they basically run some lint checks, berks vendor and thats it 15:17:43 since we have all this code for the vagrant boxes and mark wrote a nice script for testing specific patches 15:18:02 we could and should probably try to include these things in our gates 15:18:41 to get started we could define a :integration task in our cookbooks, which pulls the chef-repo and spins up one of these boxes 15:18:47 i think that was the goal of openstack.chef.io jenkins env 15:19:08 This webpage is not available 15:19:20 but if we can put them in our actual gates that would be amazing 15:19:25 jklare: yeah it’s not real yet 15:19:54 i think we could define a job in the experimental queue 15:20:28 which simply could be 'chef exec rake integration-test' 15:20:35 :) i like it 15:20:50 yeah, any step in the direction of having some CI gate test would be great. 15:21:16 time check 9 mins 15:21:39 probably could play with this in just the repo gate right now to see if we can get it to work, then spread to the other cookbooks to use 15:21:49 sure 15:22:01 i will prepare an infra patch 15:23:14 #topic vancouver socializing 15:23:28 so i think we should attempt to meet up as much as we possibly can 15:23:53 i know that sounds obvious, but its a chance for us to get a lot done in a small amount of time 15:24:19 plus, we should plan on at least one dinner together any objections? 15:24:21 sure, would be great to start some sessions 15:24:33 question is when 15:24:50 any of you going to that ubuntu event on sunday? 15:25:08 i think we should put a topic for the dev meetup to figure it out, isn’t it on monday for us? 15:25:12 i need to confirm tha 15:25:19 i’m flying in on Sunday 15:25:40 yup, I head in on Sunday 15:26:26 i was thinking maybe we could meet on sunday or something and try to figure out the best times for some breakout sessions for us 15:27:09 i mean of there are the official sessions, but probably we can add some smaller working groups inbetween to make some progress on the stable/release etc. 15:27:48 agreed, let me get some times for a couple things and i’ll send something out the the ML 15:28:00 i can’t seem to find it with quick googling 15:28:33 cmluciano: are you coming to vancouver? 15:29:41 #endmeeting