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