17:02:18 <sarob> #startmeeting training-guides
17:02:19 <openstack> Meeting started Mon Sep 15 17:02:18 2014 UTC and is due to finish in 60 minutes.  The chair is sarob. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:22 <openstack> The meeting name has been set to 'training_guides'
17:02:36 <sarob> morning/afternoon/evening all
17:02:36 <matjazp> hi al
17:02:41 <matjazp> all
17:02:42 <rluethi> hey
17:02:46 <sayali> hello
17:03:04 <dbite> hello
17:03:22 <matjazp> dbite: Wie Geht's? :)
17:03:26 <sarob> meganr with us?
17:03:45 <sarob> guten tag heir dbite
17:04:08 * rluethi shakes head
17:04:10 * dbite I cannot speak German :|
17:04:13 <dbite> damn
17:04:30 <sarob> dbite time to start, yo
17:04:38 <dbite> yeah
17:04:44 <sarob> #topic docs
17:04:47 <dbite> I am good
17:04:48 <sarob> and .... go
17:04:52 <dbite> and good day to all
17:05:13 <dbite> alrite, back to the topics
17:05:33 <dbite> we need to update the docs.openstack.org webpages with the current training docs
17:05:42 <dbite> I think the content up there is not from this release
17:06:06 <dbite> anyone interested in backports or should I take the task?
17:07:30 <sarob> dbite: ill take updating the wiki page
17:07:51 <sarob> #action sarob update the wiki page with the current training docs
17:08:10 <matjazp> sarob: ...and we all update subproject sections
17:08:17 <dbite> ok, I will take the rest of the updates
17:08:40 * dbite dguitarbite backports the required content
17:08:42 <sarob> matjazp: sure
17:09:43 <dbite> I need to discuss the openstack-doc-tools section with Andreas before I can work on it
17:09:51 <dbite> since we are in the same office, it will be a lot easier now
17:09:59 <sarob> dbite: righto
17:10:05 <dbite> the tools for automatically building the upstream content
17:10:14 <dbite> and also will be useful for future ppts
17:12:25 <sarob> #action dbite work with AJaeger on openstack-doc-tools for html, pdf, and ppt,
17:12:46 <dbite> any questions?
17:12:55 <dbite> if not, lets move on.
17:12:57 <sarob> dbite: not from me
17:13:03 <sarob> #topic infra
17:13:48 <sarob> are we discussing labs along with trainer tools?
17:14:18 <matjazp> trainer tools?
17:14:20 <dbite> sarob: trainer tools?
17:14:28 <sarob> build scripts
17:14:37 <sarob> trainer stuff
17:14:51 <dbite> I would not prefer to tag it under trainer tools, since this is also useful for students
17:14:58 <dbite> who are learning on their own
17:15:07 <matjazp> dbite: agree
17:15:15 <rluethi> and hopefully doc authors
17:15:17 <sarob> i guess i should have asking during docs
17:15:28 <dbite> rluethi: yes, I missed that
17:15:34 <sarob> never the less, whats up with infra
17:16:39 <rluethi> there's at least one nasty bug hiding in the lab scripts (or the code they use).
17:17:01 <matjazp> rluethi: ? whats that?
17:17:20 <rluethi> instances get DHCP only sometimes.
17:17:29 <rluethi> I suspect another race.
17:17:49 <dbite> I agree, its not exactly clear what is happening under the ML2 part
17:17:54 <sarob> rluethi: is there an ask or a bug on it?
17:17:58 <dbite> or its just hardware limitation
17:18:09 <dbite> sarob: we are kind of doing an unique deployment here
17:18:12 <matjazp> rluethi: you tried it on fast hw?
17:18:15 <rluethi> sarob: not yet. we're still working on it.
17:18:29 <rluethi> matjazp: yes. it occurs on fast hardware, too.
17:18:44 <rluethi> matjazp: even if it didn't, I want to figure out what's happening.
17:19:04 <sarob> dbite: i get that its different than the reqular deployment
17:19:20 <rluethi> matjazp: we should tell users: if your instances don't the DHCP, you may have insufficient resources.
17:19:39 <rluethi> matjazp: s/should/should not/ !
17:19:43 <sarob> dbite: if we dont mark it as a bug, then then its possible others using training guides are seeing the same problem
17:19:43 <matjazp> rluethi: I had problems in the past with slow HW... on fast hw it was ok
17:20:31 <sarob> rluethi: manually assigning IP as workaround?
17:20:56 <matjazp> rluethi: sure, but if it works on fast(er) HW, than you know where to look for a bug
17:20:57 <rluethi> sarob: last resort :).
17:21:06 <sarob> rluethi: few extra steps would be better than confusion
17:21:29 <sarob> rluethi: so add manual IP as troubleshooting step
17:21:55 <rluethi> sarob: I'll keep that in mind.
17:21:59 <matjazp> sarob: hmm... labs should work with such a basic stuff as DHCP and metadata server
17:22:30 <matjazp> rluethi: we don't have all-in-one config, right?
17:22:35 <sarob> rluethi: some of the user group were complaining of a similar problem but different cause
17:22:46 <rluethi> matjazp: not yet.
17:23:04 <rluethi> sarob: what was the problem and the cause?
17:23:38 <matjazp> rluethi: all-in-one configs were less problematic
17:23:53 <sarob> rluethi: consistently were unable to get dhcp assigned addresses, solved by using nat
17:24:00 <dbite> allinone should work
17:24:14 <rluethi> matjazp: you mean the problem is less reproducible? that's not what I am looking for :).
17:25:04 <rluethi> sarob: nat where? is that documented somewhere?
17:25:46 <sarob> i started to walk the person through submitting the bug
17:26:00 <sarob> doesnt look like it got submitted
17:26:07 <rluethi> sarob: bummer
17:26:08 <matjazp> rluethi: no, but if it works on all-in-one, than you know at least that config is ok. on slow hw all-in-one was working ok, multinode config didn't
17:26:38 <sarob> rluethi: dig around in my notes
17:26:49 <rluethi> matjazp: no, if it works on hardware, all I know is that the fast hardware may hiding a configuration bug.
17:27:00 <rluethi> s/hardware/fast hardware/
17:27:24 <dbite> matjazp: your logic for allinone has a flaw
17:28:04 <matjazp> rluethi: you could be hitting timeouts because of hw can't cope with all the processes/traffic
17:28:24 <rluethi> matjazp: true.
17:28:27 <dbite> if it works for allinone does not mean that it will work for multi node and/or is a test to guarantee or certify that the cluster should work since it all worked on one node
17:28:31 <sarob> rluethi: ah, he submitted it as ask #link https://ask.openstack.org/en/question/46557/cant-connect-from-laptop-to-new-openstack-intance-via-vbox/
17:28:41 <sarob> think that is the same person
17:28:42 <matjazp> dbite: I'm not saying it is true for all configs, I'm just saying what I encountered
17:28:47 <sarob> slim notes
17:28:52 <matjazp> old laptops
17:28:55 <sarob> no matter
17:29:06 <rluethi> sarob: thanks, I'll take a look.
17:30:08 <matjazp> hi MeganR
17:30:08 <rluethi> matjazp: we all agree we want an allinone config. and it will likely have lower hardware requirements than the cluster.
17:30:27 <dbite> sarob: I saw his question
17:30:30 <rluethi> matjazp: I just want a better criterion than "if DHCP fails, use all-in-one"
17:30:31 <dbite> and I know what is his problem
17:30:31 <MeganR> Hi - sorry to be so late, connection issues
17:30:40 <sarob> yes, allinone is good
17:30:42 <matjazp> rluethi: yes, we all agree here
17:30:54 <dbite> OVS will not work with bridged connections (VBOX Adapters) becuase you need the external network to be bridged from inside the VM
17:31:06 <dbite> bridged on bridged connections does not work
17:31:21 <dbite> rluethi: I agree
17:31:31 <sarob> dbite: makes sense
17:32:17 <rluethi> matjazp: especially considering that I have seen the DHCP problem on pretty decent hardware, too. just not as often.
17:33:01 <rluethi> matjazp: decent == i7 4 cores, 16 GB RAM, SSD
17:33:42 <matjazp> rluethi: yes, this looks like smthng else
17:34:34 <dbite> does anyone have the license for VMware workstation?
17:34:47 <matjazp> dbite: I have fusion on my mac
17:34:50 <dbite> I suggest trying the setup on VMware to figure out if this is an issue with Virtuabox
17:35:01 <dbite> KVM/Zen would also do the tricl
17:35:03 <dbite> *trick
17:35:16 <sarob> dbite: no, but wouldnt open version of fusion be good too?
17:35:30 <dbite> as far as I remember VMWare and KVM allows good support for nested virtualization, that may solve many of networking issues
17:35:33 <matjazp> aren't this scripts only for vbox?
17:35:50 <dbite> my suggestion is to just check if VirtualBox has an issue
17:36:02 <dbite> matjazp: yes, but you need to do some of the steps manually and then run the scripts
17:36:14 <sarob> matjazp: that was my assumption for test debug as well
17:36:31 <matjazp> dbite: can you write that somewhere? in a readme?
17:36:38 <rluethi> matjazp: a while back, I started work on a KVM backend, but there was no time to finish it. it's another item on the wishlist.
17:36:50 <dbite> I would love to see someone try it out with KVM, I will try it but I cannot promise much given the lack of time
17:36:59 <dbite> yes, if KVM works
17:37:09 <dbite> then we dont have to worry much about VirtualBox based labs
17:37:29 <rluethi> virtualbox is our only option on Windows.
17:37:30 <matjazp> dbite: hmmm.. not so sure
17:37:38 <matjazp> rluethi: exactly
17:37:42 <dbite> matjazp: Yes, I will try to do that soon
17:37:56 <sarob> dbite, rluethi: im trying to get some more people involved
17:37:56 <dbite> does KVM run on Mac?
17:38:05 <matjazp> dbite: no
17:38:14 <matjazp> dbite: its linux kernel
17:38:20 * dbite back to square one
17:38:26 <rluethi> dbite: only linux and solaris
17:38:35 <dbite> hmm, I see
17:38:35 <sarob> wouldnt this be a good alternate set of tasks to handoff to a few new contributors?
17:38:40 <matjazp> rluethi: solaris? didn't know that
17:38:58 <rluethi> matjazp: the opensource fork has a port.
17:39:06 <dbite> matjazp: I think it runs on Solaris, but not sure that it runs on all of their hardwares
17:39:20 <dbite> *hardware
17:39:44 <dbite> I think we should continue this discussion later on IRC or mailing lists
17:39:51 <rluethi> matjazp: so, strictly speaking it's not solaris proper but illumos.
17:40:02 <sarob> rluethi: wouldnt it be a bit easier at this point to just add static IP as a workaround?
17:40:28 <rluethi> sarob: I dunno. I haven't tried.
17:40:37 <dbite> sarob: it will not work
17:41:02 <dbite> the instances may get IP's but thoes IPs are just dummy IPs you cannot ping or access the VMs as required
17:41:09 <dbite> *thoes
17:41:37 <dbite> *those
17:41:53 <matjazp> sarob: static fixed IPs?
17:42:11 <matjazp> sarob: it would confuse students even more
17:42:49 <dbite> the problem is not with DHCP only
17:42:51 <matjazp> sarob: all docs are saying fixed IPs gets assigned by a DHCP server
17:42:52 <dbite> the networks do not work
17:43:02 <dbite> the DHCP lease is sent from Network Node to the Compute Node
17:43:08 <dbite> and it gets lost somewhere in all that jazz
17:43:53 <sarob> matjazp, dbite, rluethi: okay, i agree it needs to be fixed and a workaround would be confusing
17:44:22 <sarob> can we file a bug and start shopping it around?
17:44:44 <dbite> sarob: I say yes, but we need rluethi's vote on this too
17:45:02 <sarob> ask may be better, since its configuration and vbox related
17:45:17 <sarob> i dunno
17:45:19 <dbite> sarob:  I think it is valid for a bug under training guides
17:45:37 <rluethi> I'd try to figure it out ourselves first.
17:45:51 <sarob> rluethi: okey dokey
17:45:56 <rluethi> Either we fix it, or we get a better description of the problem.
17:46:12 <matjazp> rluethi: you were quite sucessfull this weekend with lab's bug squashing :)
17:46:14 <sarob> save more work on this for docs?
17:46:28 <sarob> you'all speak of incubation?
17:46:41 <rluethi> matjazp: except one bug that I fixed was introduced by yours truly.
17:47:58 <dbite> sarob: may be we should discuss this out loud on docs channel?
17:48:05 <dbite> because anne was asking last time after the meeting
17:48:20 <sarob> sure, we can
17:48:21 <dbite> about the incubation part, some questions she asked where above my understanding
17:48:31 <dbite> I think we should involve her in this discussion
17:48:33 <dbite> if possible
17:48:35 <sarob> i was more asking if this group felt ready
17:49:04 <sarob> annegentle isnt online right now
17:49:05 <matjazp> sarob: can you do a quick pro/contra for incubation? and what that changes in  this project?
17:49:08 <dbite> oh, sorry. I misunderstood
17:49:23 <sarob> #topic incubation discussion
17:49:29 <sarob> dbite: no prob
17:49:36 <dbite> matjazp: exactly what is on my mind
17:50:12 <dbite> annegentle asked the same questions, "what is that incubation will provide you that you are not getting at present?"
17:50:43 <sarob> #link https://wiki.openstack.org/wiki/Training-guides#Incubation_Plan
17:51:05 <sayali> I need to interrupt looking at the lack of time
17:51:09 <sayali> About the audio visual content, as dicussed last time I took a look at the last few summit videos that had been recorded. But we will not be able to slice these videos and use them since their liscense would not permit it. So what work around would everyone suggest?
17:51:37 <matjazp> sayali: can we ask Foundation to loose license?
17:51:39 <sayali> license*
17:51:51 <matjazp> or do we need to ask speakers?
17:51:57 <dbite> yeah, send it over the mailing list
17:52:07 <matjazp> I'm sure speakers would agree to it - more coverage for them
17:52:54 * matjazp looks if there's a lawyer around ;)
17:52:57 <rluethi> so basically the question is: who has the rights to relicense the content?
17:53:06 <sayali> Yep. As of now all the videos are under the Standard youtube license. We need the speaker/owner to make the license Creative common so that anybody can reuse it
17:53:25 <sayali> the owner of the video does as far as I know
17:53:43 <matjazp> sayali: just make a list of possible videos and we can start contacting them
17:53:52 <rluethi> sayali: maybe get the foundation involved so they can fix it at least for upcoming events!?
17:54:07 <sayali> rluethi: that would be a good idea
17:54:18 <sayali> matjazp: ok I could do that
17:54:47 <sayali> Also using the youtube video editor to slice the videos seems like a good option
17:55:10 <matjazp> sarob: who would be a good fit to ask at the foundation?
17:56:07 <dbite> matjazp: I think asking via the mailing list (i believe there is one for the foundation too) can be a good start
17:56:12 <sarob> matjazp: hmmm, prob lauren to start with
17:57:00 <sarob> dbite: i like that or community ml since tfifield and reed monitor it
17:57:08 <dbite> yeah
17:57:24 <sarob> real quick about incubation
17:57:28 <dbite> we could approach tfifield more easier to explain him the technical requirement
17:57:47 <matjazp> sarob: shoot
17:57:54 <sarob> when we started thinking about it, we were just creating the new repo
17:58:09 <sarob> now that we are in the openstack github org
17:58:35 <sarob> and the neutron and nova incubation sub project ideas floating around
17:58:53 <sarob> im not sure what incubation would mean at this point
17:58:56 <sarob> for us
17:59:20 <dbite> sarob: we are diverging a bit from openstack-manuals roadmap by adding the shell scripts, rst, more different content to be added soon with audio visual
17:59:22 <sarob> for people outside of the projects it means quality and officialiness
17:59:37 <sarob> dbite: yeah
17:59:46 <sarob> lets move this to docs
17:59:52 <sarob> as we are out of
17:59:53 <sarob> time
17:59:59 <dbite> sure
18:00:04 <sarob> thanks
18:00:06 <sarob> all
18:00:06 <matjazp> bye
18:00:12 <sayali> bye
18:00:13 <MeganR> bye
18:00:13 <sarob> #endmeeting