10:33:18 #startmeeting training-labs 10:33:19 Meeting started Wed Mar 9 10:33:18 2016 UTC and is due to finish in 60 minutes. The chair is dguitarbite. Information about MeetBot at http://wiki.debian.org/MeetBot. 10:33:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 10:33:23 The meeting name has been set to 'training_labs' 10:33:31 Hello 10:34:00 hi 10:34:10 #topic release-cycle 10:34:46 I had a chat with dhellmann on Monday evening (CET) where he clarified the release cycle and version numbering for training-albs 10:35:23 k? I didn't know there was such a thing. 10:35:43 rluethi: Its to make the process more clear and simpler also follow existing trends for a proper release cycle. 10:35:57 I would like to get our teams vote on the model that made the most sense. 10:36:10 is there a link? 10:36:20 no, Ill tell you about it now. 10:36:37 well.. but we cover all the release cycles... 10:36:57 it does not make much sense to make a "training-labs Liberty" 10:37:09 so, starting with release cycle: We have one big release every 6 months 10:38:04 and we decided to have a milestone in the middle every 3 months, this milestone would be the point where we shift our focus on the guest side scripts 10:38:18 for the next release in sync with install-guides team. 10:38:40 so we have a release ==> branch + tag (tags would provide stable points for our users) 10:38:49 milestone ==> Another tag 10:40:34 So the intermediary release should ideally freeze the work on lib and scripts for the last release on the master and then start working on the next release. 10:40:46 This also allows us to have a logical version numbering. 10:41:47 the version numbering is X:Y:Z where X=> Major release (Liberty, Mitaka) Y => Milestones Z => Bug Fixes and Backporting 10:42:10 I currently don't see a reason to oppose this, but the implications are unclear to me. 10:43:23 rluethi: It makes the release process simpler and also provides our users with better way to consume our stable releases. 10:44:18 does it involve creating a new repository for each release? 10:44:40 Most of our merged patches are things we want our users to have ASAP instead of having them wait for a release. 10:44:40 But if we keep building trunk packages for every changeset merged, I don't see a problem (yet). 10:44:43 julenl: certainly not a repo, probably a branch. 10:44:48 julenl: No, just a branch 10:45:12 We tag the branch for stable releases like 1.1.0 which means that the users should have a stable release at that tag 10:45:46 at present we are just branching 10:46:06 I see... 10:46:07 the problem with just branching is that, all the backports that would potentially break the cluster are considered as stable release. 10:46:21 With a tag we can differentiate this 10:46:32 what about naming the releases after the last openstack release supported? 10:46:42 well, usually the tip of each branch is already the best, most stable version of each release. 10:47:30 that makes sense 10:47:58 not sure what a release that is going to add to that. 10:48:30 yes, this is correct 10:48:51 rluethi: I agree with you but that means a lot of work to make sure that the stable branch is really stable. 10:48:55 If we have release tags 10:49:17 Let's try it I guess and see how it plays out. 10:49:44 rluethi: yes, we should try it out 10:50:03 I would say that the release team has the experience which we should exploit rather than learning it the hard way 10:50:32 Since we are going to publish the training-labs website soon, it makes sense to be prepared :) 10:50:41 Anything against the version numbering? 10:51:31 not from my side 10:51:52 I don't have enough information to be for it or against it. Let's try it. 10:52:15 rluethi: ok, Ill send a patch to the right repositories. For the team it should not change anything. 10:52:30 We are just adding tags at a point the cluster is the most stable on every branch except the master :) 10:52:44 I guess it will make it fit better within the rest of the projects, using a similar approach 10:52:52 julenl: Yes. 10:53:15 rluethi: My apologizes if I am not able to explain properly. 10:54:52 rluethi: ping? May be we could have a short call today evening so I can explain this to you much better with --verbose -vvv 10:55:00 dguitarbite: NP. It may also be due to my being constantly distracted. 10:55:24 * dguitarbite same here 10:55:30 so next topic? 10:55:36 #topic summit-talks 10:55:49 next :/ 10:55:49 any news on that? 10:55:51 Unfortunately both the training-labs talks were rejected. 10:56:00 what? :O 10:56:02 I have another talk which got accepted so that means that I will go for the summit. 10:56:05 where did you see that? 10:56:34 I got an email from the foundation. May be I misread something. 10:56:39 * dguitarbite digging through the emails 10:57:09 I got the email, too. 10:57:27 hmm... i didn't 10:57:30 * dguitarbite sigh** with releif 10:57:44 when was that? 10:57:44 Saves me two weeks of vacation and a bundle of money. Yay me. 10:57:47 julenl: how about your talk? Can you try to search with the email domain speakersupport@openstack.org 10:58:00 rluethi: Yay! I dont want to go but have to go :\ 10:58:39 hmm... I didn't get any message yet... 10:59:05 julenl: Ok, may be they are still considering your talk. Best of luck :). 10:59:21 julenl: But we can hangout in Austin for sure :) 10:59:23 So next topic? 10:59:55 #topic any-other-beezneez? 10:59:58 ouf course! :) 11:00:05 julenl: :D 11:00:30 about that bug on OSX 11:00:45 I just tried the latest version and it worked fine for me 11:00:58 what is the bug? 11:01:04 Or I did not read the email's yet 11:01:10 * dguitarbite is busier than he knows 11:01:16 #link: https://bugs.launchpad.net/labs/+bug/1471753 11:01:16 Launchpad bug 1471753 in openstack-training-labs "Lab provisioning failed on OS X" [Undecided,Incomplete] 11:01:59 I edited our bugs and I will close them if we don't get confirmation that they are still relevant. 11:02:28 good 11:02:37 rluethi: Alright, lets wait for a couple of days may be a week or so. We dont have to close the bug immediately. We dont have to confirm the bug :). 11:03:10 also, we have a few patches waiting for review. 11:03:25 there's also the zip file issue. 11:03:29 and mitaka. 11:03:34 well... I kind of, unconfirmed it. It worked for me, but I am used OSX Mavericks 11:03:42 rluethi: The zip file issue will be fixed. I have to use gzip instead of zip 11:03:53 Just need some free time and then Ill fix it :). 11:04:29 julenl: Yes, may be its a specific race for his environment. May be he is overloading his system or something. For me things work fine but I have a Skylake chip with MacBook 12 11:04:51 dguitarbite: That will not work. I added a comment to the review explaining that. 11:05:07 rluethi: I will review your patches soon. I am sorry. And also for the gzip patch I will update it. 11:05:26 dguitarbite: you cannot use gzip. doesn't work for that use case. 11:05:28 THe problem is that I have to use find to feed the **correct** files 11:05:35 rluethi: I know :). 11:05:39 rluethi: Ill fix it. 11:05:50 dguitarbite: how? 11:06:04 using find to push the required files to gzip 11:07:19 dguitarbite: I don't see how this could possibly work. did you try it? 11:07:50 rluethi: Trying it out. Sorry for the vague replies, Ill update the patch and you can see it for yourself :) 11:08:00 rluethi: But I'm sure it will work. 11:08:02 I am really curious now. 11:08:14 * dguitarbite Should have seen it coming 11:08:27 I have the Mitaka port pretty much ready. 11:08:47 rluethi: Wow! That is awesome. I have to also do finish the release cycle thingy 11:08:53 At least I can launch a VM. 11:08:56 Wow! :) 11:08:57 #action dguitarbite fix zip file generation. 11:09:10 #action dguitarbite Finish release model for training-labs 11:09:17 I found a few bugs in the install-guide in the process. 11:09:18 #action rluethi push mitaka patch soon 11:09:33 #action dguitarbite finish work with training-labs landing page 11:09:41 One is rather odd, I need to submit a bug and have it confirmed. 11:09:45 julenl: So do you want to take up something? 11:09:56 if there's something I can do... sure 11:10:22 I am still trying to get that execution flow 11:10:31 julenl: What ever interests you. So for now we could focus on Mitaka release and then start merging some nice features from BOMBSI 11:10:54 dguitarbite: ok... 11:11:21 julenl: awesome. Lets sync up soon. 11:11:22 ok, anything else? I really need to rush. 11:11:26 rluethi: ping me when you have something I can test 11:11:37 julenl: will do. 11:11:39 rluethi: please push the mitaka patch asap so we could all test it :) 11:11:51 ah! 11:11:55 one last little thing 11:11:58 julenl: You could also start testing and reviewing all the patches on gerrit 11:12:06 julenl: shoot 11:12:25 dguitarbite: yes... I still have to find out how to do that 11:12:41 julenl: Ok, I can give you some pointers it should be easy :) 11:12:52 I was thinking of an idea for some sort of "rebranding" 11:13:17 julenl: Yes, I'm agnostic to the names. As long as they make sense, I'm open to any suggestions. 11:13:20 osbash performs the installation mainly by executing the code remotely via ssh 11:13:32 no no... wait.. :P 11:14:33 * rluethi is waiting. 11:14:37 so, maybe I could try to present BOMSI as a ISO based installer, while osbash would be more like a ssh and bash based configuration manager 11:14:54 what do you think? 11:15:26 by they way, if someone wants to give it a try, I just tested on clean ubuntu and suse, and it worked... 11:15:31 julenl: I would like the approach of this integration but I would be against creating ISO's may be the UI part and the bootable flashdrives :D 11:15:33 "configuration manager" can mean a hundred things. 11:16:00 by the way, on Windows we don't use ssh (because it's not there by default) 11:16:14 dguitarbite: sure 11:17:07 rluethi: Hmm... you are right, I should think more about that 11:17:10 There may be reasons to have an option for building ISOs, but we need to study the pros and cons. 11:17:11 julenl: How about discussing this in more detail? So we are clear on what you mean by config. manager and more. Lets have a chat later on IRC and decide the meeting. 11:17:45 dguitarbite: sure, let's do that 11:18:11 Awesome. So lets wrap up today. Ill shoot an email. 11:18:15 Bye guys. 11:18:23 bye 11:18:31 bye 11:18:45 #action dguitarbite review rluethi's patches. 11:18:51 #endmeeting