10:31:29 <dguitarbite> #startmeeting training-labs
10:31:30 <openstack> Meeting started Wed Mar 23 10:31:29 2016 UTC and is due to finish in 60 minutes.  The chair is dguitarbite. Information about MeetBot at http://wiki.debian.org/MeetBot.
10:31:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
10:31:33 <openstack> The meeting name has been set to 'training_labs'
10:31:37 <dguitarbite> Hello
10:32:14 <dguitarbite> Julen are you here?
10:32:28 <dguitarbite> Roger is going to be late today.
10:35:33 <dguitarbite> julen: Hi!
10:35:40 <julen> hey!! here I am
10:36:20 <zzxwill> What's training_labs?
10:36:26 <julen> so, roger is coming later...
10:36:49 <dguitarbite> zzxwill: Its a project which deploys multi-node openstack cluster on VM's for users for training and POC's
10:37:04 <dguitarbite> julen: yes, Roger may join us after 12. If we are still working till then.
10:37:16 <zzxwill> Got it. Thanks:)
10:38:02 <dguitarbite> zzxwill: Checkout https://git.openstack.org/cgit/openstack/training-labs
10:38:41 <zzxwill> Sure.
10:38:55 <dguitarbite> julen: So what do we discuss today ;)
10:39:33 <julen> what about the PXE functionality we talked about on the e-mails?
10:40:15 <julen> I have been trying to work a little bit on that, but I am now stuck at some point
10:41:26 <julen> so... 1) create base, 2) clone base into another machine and 3) start executing cmds into the new machine trough ssh
10:41:58 <dguitarbite> julen: The point of PXE is to use them for DC based applications. The overhead may not be ideal for home computers
10:42:02 <dguitarbite> julen: Do you agree with me?
10:42:22 <dguitarbite> I would suggest sticking to kernel image and initrd ram disk ... is there something wrong with that?
10:43:45 <julen> hmm... I am not sure I understand...
10:44:19 <julen> do you mean, avoid the PXE functionality completely?
10:44:27 <dguitarbite> I meant that using the initrd and ramdisk for injecting the kernel to boot and then install the OS, what is wrong with that approach because PXE booting may need some additional resources.
10:44:39 <dguitarbite> julen: In a way, that is what PXE booting does does it not?
10:45:24 <julen> well... yes
10:47:05 <dguitarbite> But is there an additional overhead for PXE or you are just planning to emulate PXE environment for booting?
10:47:06 <julen> but I think it shouldn't need so many extra resources... It's just a single VM which does not need too much, since it's just the tftp and dhcp
10:47:28 <julen> wait, I'll explain it in more detail
10:47:37 <julen> so, this is the plan:
10:47:44 <dguitarbite> julen: Yeah, for baremetal this should be a good option. For VM based architecture its not a good ideae.
10:48:06 <dguitarbite> We are already running low on resources for the controller node. Trying our best to compress it as much as possible.
10:48:24 <dguitarbite> s/compress/consolidate/
10:49:57 <julen> 1) create a pxe_server from the base disk, 2) run a script on the pxe_server for configuring tftp and dhcp, 3) extract and hack an ubuntu image enabling boot with different settings for controller and compute(s)
10:50:49 <julen> 4) start a VM or a baremetal machine on the pxe_network and select the node we want to install
10:51:24 <julen> this way, one could install openstack with osbash also into baremetal
10:51:54 <julen> but the current install method would of course be preferred for local PoC installations
10:52:11 <julen> just that the pxe option would allow also for provisioning into metal
10:52:15 <julen> what do you think?
10:52:53 <dguitarbite> I think for baremetal its a good way to go ahead. Also for providing a way to create customized images.
10:53:12 <dguitarbite> How much effort do you think it takes to cover all different possibilities for real deployments ??
10:53:52 <julen> uff.. that sounds tricky...
10:54:23 <julen> but the point is just to make a PoC on standard hardware, right?
10:54:52 <julen> so, in principle, it should be enough with running the same scripts that run on the VMs
10:55:07 <dguitarbite> yes, I mean to say that can we figure out a simple one click way for covering all POC/common hardware installations? Ofcourse not meaning to support all the advanced server booting methods.
10:55:46 <dguitarbite> julen: I am interested in adding this as another way to install the cluster (plugin/backend). We should definatly sit together and brainstorm this during the summit.
10:56:00 <dguitarbite> btw. I am confirmed for the summit, unless I get issues with my VISA.
10:56:04 <julen> definitely
10:56:15 <julen> great! :D
10:56:18 <dguitarbite> But, I would not keep this as the only way to deploy the cluster.
10:56:27 <julen> of course not
10:56:41 <dguitarbite> Think about laptops having 4 GB ram, I can forsee a lot of problems trying to have another VM
10:56:43 <julen> the current way is definitely much more efficient and elegant
10:56:58 <dguitarbite> only for a specific use-case!
10:57:12 <dguitarbite> your way is also efficient and elegant but for other use-cases :)
10:57:27 <dguitarbite> How comfertable are you with Python?
10:57:44 <julen> aha! now I will tell you another use case: someone has a 4GB laptop, a switch AND another two old computers ;)
10:57:48 <dguitarbite> I would definalty do this in Python and not in BASH. It is getting incredibly complex right now and we should move to python soon/
10:59:45 <julen> well.. I feel quite comfortable with python, and it is definitely my language of choice for certain tasks, but remember.. I also decided to write my installer in Bash, and there was a reason for that
11:00:08 <julen> in bomsi, the only python part is the tool for editing ini files
11:00:33 <dguitarbite> julen: https://github.com/dguitarbite/labs-POC
11:00:43 <dguitarbite> julen: I want to rewrite everything but the guest scripts in Python
11:02:00 <julen> uff... that sounds like so much work!
11:02:22 <dguitarbite> julen: Yeah! That is a lot of work :D
11:03:29 <julen> well... but then... what about the PXE?
11:04:20 <julen> should I finish it?
11:05:13 <dguitarbite> Upto you I would say. But if you can wait till the summit it would be better so we can discuss it better and plan it.
11:05:21 <dguitarbite> Its barely a month to the summit now isnt it ;)
11:05:27 <julen> yes...
11:05:39 <dguitarbite> And my apologizes, I havent gotton enough time to reply to emails. I am getting super busy these days.
11:06:21 <julen> but the whole thing is quite simple to implement... I just get a little bit lost between all those wrappers :P
11:06:42 <julen> of course... no problemo :)
11:07:15 <julen> aha! rluethi:
11:07:18 <rluethi> hey
11:07:29 <dguitarbite> rluethi: Yo!
11:07:48 <rluethi> sorry, had another meeting, now done there.
11:08:18 <dguitarbite> rluethi: No worries :).
11:08:30 <julen> we were taking about the PXE functionality and the PoC python version of osbash
11:09:25 <julen> the python version is a lot of work, but it will be worth it at some point
11:10:19 <julen> and dguitarbite: suggested to wait until the summit to continue with the PXE functionality, but I think I am already pretty close
11:10:54 <rluethi> julen: If you have a PoC, that's always useful information to have.
11:11:45 <julen> one question... the ssh connections are made by forwarding 127:0.0.1:2230 (or another port) into the ssh of the VM
11:12:17 * rluethi is trying to catch up reading the log
11:12:18 <julen> but where is that port forwarding defined? I still could not find it
11:12:45 <dguitarbite> julen: For VirtualBox is done on the network interface from the host side
11:12:48 <rluethi> julen: port forwarding is defined in config/config.controller
11:12:53 <dguitarbite> There is a way to forward ports for NAT'ed connections
11:12:54 <rluethi> just grep for 2230 :)
11:13:18 <rluethi> of course, that's only on VirtualBox. No port forwarding on KVM.
11:15:23 <dguitarbite> Yes
11:15:26 <dguitarbite> For KVM there is another way
11:15:34 <dguitarbite> But lets spare the low level details as of now.
11:15:41 <dguitarbite> rluethi: Sup? Anything interesting to report?
11:17:26 <julen> not much more from my side
11:17:50 <julen> rluethi: how is it going with Mitaka?
11:17:52 <rluethi> just wanted to point out that I see PXE boot (and the VM it requires) as an option that could be useful for baremetal and that ideally we can test with VMs, too (on somewhat beefier machines)
11:18:24 <julen> exactly! :)
11:19:09 <rluethi> but it won't be used by default
11:19:21 <rluethi> regarding mitaka:
11:19:49 <dguitarbite> rluethi: You have summarized my exact point :)
11:19:58 <rluethi> I've been able to sort of make it work again by using mitaka instead of mitaka-proposed. For now.
11:20:41 <rluethi> Unfortunately, I've been to busy to clean it up and submit it. I will try to do it asap.
11:21:14 <rluethi> I am more worried about the zip file situation.
11:21:53 <rluethi> I don't think we have a working plan to fix that.
11:23:00 <dguitarbite> rluethi: Yes, gzip cannot create zip files
11:23:03 <dguitarbite> But do we need zip files?
11:23:25 <rluethi> we need something people can open on windows.
11:23:36 <dguitarbite> And for Mitaka, it makes sense to push the patch so we all can work on it. And also wait for a week or so after the release to stabilize it and merge it.
11:23:48 <dguitarbite> I think tar balls are supported on windows these days
11:23:53 <dguitarbite> Win Rar can open them
11:24:15 <dguitarbite> So do we need zip file extension? Because I can see a long discussion on infra
11:24:25 <dguitarbite> for them to install zip pacakge
11:24:34 <dguitarbite> So we need to make a decision here :)
11:25:37 <rluethi> tar is not supported on windows, but windows users can install additional software to unpack tar balls.
11:25:53 <rluethi> but that's exactly the kind of dependency we have worked so hard to avoid.
11:26:12 <rluethi> zip is supported out of the box, you don't need winzip like you used to in the old days.
11:27:14 <dguitarbite> rluethi: Ok, I will push for this then.
11:27:32 <rluethi> dguitarbite: yes, please. thank you.
11:27:40 <dguitarbite> I want to finish the zip and website for training-labs before the release preferably before the summit. Ill work hard on it :)
11:28:05 <dguitarbite> rluethi: My apologizes for delays I have not had enough time lately. But I will be free this weekend and next week :)
11:28:21 <dguitarbite> julen: Even for you :) Feel free to ping me.
11:28:35 <dguitarbite> The time is up and I am hungry, shall we continue on docs or emails?
11:28:37 <julen> hehe.. I will :)
11:29:33 <rluethi> okay, ttyl.
11:29:42 <dguitarbite> see you guys. Thanks for coming :)
11:29:44 <dguitarbite> #endmeeting