17:00:58 <dguitarbite> #startmeeting training-guides
17:00:58 <openstack> Meeting started Mon Jun 29 17:00:58 2015 UTC and is due to finish in 60 minutes.  The chair is dguitarbite. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:02 <openstack> The meeting name has been set to 'training_guides'
17:01:07 <dguitarbite> Hello
17:01:12 <dguitarbite> Roll call
17:01:21 <matjazp> here
17:01:27 <vigneshvar> hi
17:01:31 <rluethi> hey
17:02:01 <dguitarbite> I see that the agenda is outdated
17:02:20 <matjazp> dguitarbite: standard topics, I guess
17:02:25 <dguitarbite> Yes
17:02:26 <rluethi> yes
17:02:45 <dguitarbite> SO what is the important topic for today?
17:02:59 <rluethi> we fixed the bug. yay.
17:03:15 <rluethi> thanks, sayali, vigneshvar.
17:03:21 <dguitarbite> #topic training-labs
17:03:25 <vigneshvar> rluethi: :)
17:03:30 <dguitarbite> That is good news
17:03:48 <rluethi> it was yet another race.
17:04:26 <dguitarbite> https://review.openstack.org/#/c/196466/
17:04:44 <dguitarbite> This patch should solve the issue. I will run repeat test overnight
17:04:54 <dguitarbite> and report back the stats. prob next meeting
17:05:51 <vigneshvar> vigneshvar: I still have some doubts on it. Figuring it out
17:06:05 <matjazp> dguitarbite: we still need CI for the labs.. anyone has any idea where to get necessary infra for it?
17:06:46 <dguitarbite> matjazp, Yes
17:06:53 <rluethi> matjazp: the main problem with labs CI is still that we don't have a kvm backend yet.
17:07:02 <dguitarbite> We need KVM backend
17:07:06 <dguitarbite> rluethi, +1
17:07:27 <dguitarbite> And also the CI will be shared for testing the labs and install-guides. I guess we will run in parallel from this point on.
17:07:47 <dguitarbite> I suggest waiting a bit for the same. Hopefully we should have this out by Liberty release.
17:07:47 <matjazp> sure, but virtbox will stay, right? some ppl will try this on it regardless of the kvm option
17:07:55 <dguitarbite> matjazp, yes
17:08:02 <dguitarbite> We will add virtualbox support too.
17:08:24 <dguitarbite> It should be very similar. And with Python some issues on Windows should be resolved which we currently face with BASH.
17:08:41 <dguitarbite> matjazp, although the question of packaing python windows binaries is still hanging
17:08:47 <dguitarbite> but it works for sure.
17:09:22 <rluethi> matjazp: virtualbox support needs to stay in, agreed.
17:09:54 <rluethi> not needing KVM is one of our main advantages.
17:10:12 <matjazp> in the mean time, we should just do this CI thing in the beefier VM, install VBox and run scripts as they are..
17:10:29 <dguitarbite> matjazp, In future I also plan to add USB Booting Clusters
17:10:36 <dguitarbite> so the base OS should not matter much
17:10:48 <rluethi> matjazp: you lost me there. can you elaborate?
17:11:17 <dguitarbite> matjazp, The issue is to add VirtualBox related scripts for a few months. I am not sure if the infra team would be happy with that.
17:11:32 <dguitarbite> Meaning setting up the environment for VirtualBox!
17:11:39 <matjazp> we can do testing of bash scripts in the somwhat larger VM? OR if we can get it, in the bare metal box
17:11:54 <dguitarbite> Yes, we could do that
17:13:07 <rluethi> matjazp: which somewhat larger vm?
17:13:09 <dguitarbite> matjazp, Here is my plan
17:13:22 <matjazp> Ideal would be to put a fresh copy of OS on bare metal, install Vbox and test osbash scripts. It could even be a job that runs one a day, not necessary for every commit
17:13:36 <dguitarbite> 1. Get Training guides promoted from incubation. Get labs as seperate repository (training-labs) under training-guides
17:13:43 <dguitarbite> And then propose the CI changes
17:13:55 <dguitarbite> KVM backend would be added somewhere along the way.
17:14:26 <dguitarbite> I am going to sit and plan this thing out completely with Andreas Jaeger on Wed. Also meanwhile add the Landing page for training etc.
17:14:34 <matjazp> rluethi: we can put everything inside a large VM (large=more RAM), run cluster inside on Vbox, just to see if everything works.. I doubt it would be fast enough to test race conditions... or maybe, it would be even better, as it would be slow
17:14:45 <rluethi> matjazp: oh, you mean using the openstack ci infrastructure and install virtualbox there?
17:14:45 <dguitarbite> Just trying to figure out the best possible way and sequence, along with the least disruptive path.
17:15:22 <dguitarbite> matjazp, that should not be considered. I understand your logic, but the third level virt! would cause lots of races
17:15:34 <dguitarbite> and lead the jobs to fail or with so many exceptions that it would not make any sense
17:15:37 <matjazp> rluethi: well... yes, but I'm afraid we don't fit in onfra framework... no one want's Vbox as a dependency
17:15:46 <dguitarbite> We would need 1st level virt for the VM's
17:15:57 <matjazp> onfra=infra
17:16:00 <dguitarbite> and with the install-gudies automated testing, we will have more reasons to request the same.
17:16:05 <dguitarbite> *infra
17:16:57 <matjazp> dguitarbite: yes, but we don't have bare metal boxes, do we? so maybe race conditions would emerge even more frequently on SLOW nested VM
17:17:13 <rluethi> well, at least we have the scripts in place so everyone can test at home.
17:17:43 <rluethi> and with the new functionality, we can test starting from a snapshot which speeds things up a lot.
17:18:31 <dguitarbite> matjazp, We can request more stuff when we are independent project and also we can get better hardware (may be once a week or fortnight). Also having the install-gudies team with us would make it easier to achieve,
17:19:12 <dguitarbite> the worst case we get good KVM VM's, then we configure them to run the scripts directly (but networking issues) and I am not exactly sure how to do this one or even if its possible.
17:19:53 <vigneshvar> when we say testing we need to test with windows as well right
17:19:55 <dguitarbite> matjazp, and again netsted virtualization in KVM is much better (faster) w.r.t. virtualbox.
17:19:58 <sayalilunkad> Hello
17:20:04 <dguitarbite> vigneshvar, Not in the CI
17:20:06 <sayalilunkad> Sorry about the delay
17:20:07 <dguitarbite> sayalilunkad, hi
17:20:14 <vigneshvar> sayalilunkad: hi
17:20:25 <dguitarbite> vigneshvar, testing could be done on Windows but I cannot gurantee automated CI testing.
17:20:28 <matjazp> dguitarbite: it is, and it doesn't matter if the testing is really slow, we don't have a lot of changes in  the code
17:21:01 <matjazp> vigneshvar: is right.. if we "support" Win, than we should test it
17:21:09 <vigneshvar> But if we have nested virtualization we could do for both !! is n't it
17:21:23 <dguitarbite> matjazp, exactly. Once a fortnight works for our use-case. And also it would be easier to acquire this time during low load (sunday's for ex.) from the infra team.
17:22:11 <dguitarbite> vigneshvar, KVM support for netsted virtualization is inbuilt in the Linux kernel
17:22:26 <dguitarbite> and its much faster as it has very low overhead.
17:23:20 <vigneshvar> dguitarbite: I meant for testing virtual box , we could use a large kvm VM
17:23:42 <vigneshvar> and then test both windows as well as linux (vbox)
17:23:45 <dguitarbite> vigneshvar, yes, but that will not necessarily make it faster.
17:24:06 <vigneshvar> dguitarbite: True
17:24:15 <matjazp> vbox is slow and it doesn't support HW nested virt.... it is so slow that devstack I can't really run nested windows guests in a virtualised openstack... Just booting takes forewer :(
17:24:47 <dguitarbite> vigneshvar, I tried this some time back on a 32 GB i7 machine
17:24:51 <matjazp> *that IN devstack
17:25:04 <dguitarbite> Conclusion is similar to what matjazp says
17:25:25 <matjazp> dguitarbite: and that is a machine that almost noone in the training has with them
17:25:51 <vigneshvar> dguitarbite: I accept that. I just felt that testing might be incomplete
17:26:26 <dguitarbite> matjazp, I know. I was just trying to see if scaling up works in this case.
17:27:03 <matjazp> vigneshvar: if we could get a bare metal box (e.g. via ironic in openstack?), than this is all moot point
17:27:26 <rluethi> vigneshvar: we should aim for complete test coverage, but we take one step after the other and we may never get there :-)
17:28:18 <dguitarbite> #topic general-discussion
17:28:40 <vigneshvar> rluethi: right
17:28:45 <vigneshvar> matjazp: +1
17:30:07 <dguitarbite> rluethi, +1
17:31:53 <rluethi> so I guess we're done!?
17:32:07 <dguitarbite> I am quite busy this week. But by the end of the this week or early next week I will send an email to the docs ML with the plan.
17:32:28 <dguitarbite> rluethi, I guess so.
17:32:33 <dguitarbite> Any other topic?
17:32:50 <matjazp> what about shifting meeting time, as sean asked? discuss on ML?
17:33:12 <dguitarbite> I need to see the mail.
17:33:15 <sayalilunkad> tokyo summit sessions?
17:33:24 <sayalilunkad> I would like to keep one on the labs
17:33:33 <vigneshvar> sayalilunkad: +1
17:33:42 <sayalilunkad> and maybe a hands on too
17:33:50 <dguitarbite> I dont mind moving the meeting timing. May be make it much better for CEST this time.
17:33:54 <matjazp> sayalilunkad: sean can't be here until then
17:33:58 <rluethi> matjazp: sean didn't indicate any alternatives. "some other time" is not all that helpful.
17:34:27 <dguitarbite> rluethi, I assume we all discuss the common free time we all have most of the weeks.
17:36:07 <sayalilunkad> cool, we can discuss that on the ML
17:36:20 <rluethi> k.
17:36:49 <sayalilunkad> rluethi dguitarbite what do you guys think about the labs session for tokyo ?
17:37:15 <sayalilunkad> deadline for proposals is july 15th I guess
17:37:38 <rluethi> sayalilunkad: would love to do it, but whether I can afford to be there is uncertain
17:38:21 <sayalilunkad> we can always propose it, we need to get selected first :)
17:38:39 <rluethi> propose away.
17:40:20 <dguitarbite> sayalilunkad, I like the idea. We need to advertise a bit more about this.
17:40:31 <dguitarbite> Any other topic?
17:40:34 <sayalilunkad> ok, lets have a call soon then.
17:40:59 <vigneshvar> may be we should decide by this week
17:41:10 <dguitarbite> sayalilunkad, for the session more than hands on I would like to suggest joining the upstream-training part.
17:41:13 <dguitarbite> If that is ok with you.
17:41:36 <sayalilunkad> dguitarbite: I agree. Will write an email to stef about that
17:41:44 <dguitarbite> Ok, thanks :).
17:42:07 <dguitarbite> sayalilunkad, I guess you missed this but Roger has fixed the race with metadata. So we should have working Juno cluster!
17:42:46 <sayalilunkad> oh awesome! I am yet to take a look at that.
17:42:48 <matjazp> sayalilunkad: stef changed jobs
17:42:57 <matjazp> he is at dreamhost now
17:42:58 <dguitarbite> matjazp, what?
17:43:03 <dguitarbite> ok
17:43:23 <matjazp> not sure who will take his job at the foundation?
17:43:25 <dguitarbite> So will he not participate again?
17:43:30 <sayalilunkad> matjazp: oh. so doesn't hold his position witht he foundation?
17:43:53 <dguitarbite> I assumed that upstream-training was not exactly fixed to his role at Foundation If I am correct.
17:44:01 <matjazp> sayalilunkad: don't know, but I guess that he'll be busy with new assigments?
17:44:25 <matjazp> dguitarbite: sure, but he was the "go to guy" for that :)
17:44:35 <dguitarbite> matjazp, yeah
17:44:42 <dguitarbite> fingers crossed in that case.
17:44:55 <sayalilunkad> matjazp: ah yes.
17:45:19 <matjazp> maybe sean has some more info about upstream training... we should ask him over ML
17:47:26 <dguitarbite> So anything else?
17:47:38 <sayalilunkad> nope
17:47:41 <matjazp> I'm good
17:47:53 <rluethi> me too
17:48:01 <vigneshvar> nope
17:48:15 <dguitarbite> Ok, so lets end it.
17:48:32 <vigneshvar> bye
17:48:40 <matjazp> see you next week
17:48:58 <rluethi> bye
17:49:01 <dguitarbite> #endmeeting