10:32:32 <dguitarbite> #startmeeting training-labs
10:32:33 <openstack> Meeting started Wed Jan 27 10:32:32 2016 UTC and is due to finish in 60 minutes.  The chair is dguitarbite. Information about MeetBot at http://wiki.debian.org/MeetBot.
10:32:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
10:32:36 <openstack> The meeting name has been set to 'training_labs'
10:32:41 <dguitarbite> Hello guys.
10:32:46 <rluethi> hi
10:33:10 <dguitarbite> #topic Liberty Support
10:33:46 <rluethi> Seems to work now, at least for self-service networks.
10:33:58 <rluethi> and without the optional storage nodes.
10:34:03 <dguitarbite> Yes, I think we are almost done with Liberty
10:34:19 <rluethi> what is still needed is review and cleanup.
10:34:21 <dguitarbite> What remains is a final peer review and pair programming
10:34:26 <dguitarbite> to clean up. Yes!
10:34:49 <dguitarbite> #action dguitarbite rluethi Pair program to cleanup the Liberty patch before merging it.
10:34:55 <rluethi> also, take a look at the patches up for review that I split out from the Liberty patch.
10:35:24 <rluethi> some are needed for Liberty.
10:35:41 <dguitarbite> rluethi: Shall we ask for Bernd to give his +1 for liberty? Does that make sense?
10:36:06 <dguitarbite> #link https://review.openstack.org/#/c/272217/
10:36:12 <dguitarbite> #link https://review.openstack.org/#/c/272214/
10:36:19 <dguitarbite> #link https://review.openstack.org/#/c/271752/
10:36:32 <dguitarbite> rluethi: As of this patch: https://review.openstack.org/#/c/252297/
10:36:45 <dguitarbite> Shall we agree on fixing the ping command in install guides?
10:37:09 <dguitarbite> I see that depending on the network architecture and/or interface configuration, router may or may not be ping(able) from the network node.
10:37:32 <rluethi> yes, ask Bernd.
10:37:57 <dguitarbite> #action get rluethi, dguitarbite and berndbausch +1/+2/+1 for merging liberty patch.
10:39:11 <rluethi> brb
10:40:57 <rluethi> okay, the ping test in the install-guide shows the expected network setup.
10:41:01 <rluethi> which doesn't match ours.
10:41:20 <rluethi> so we need to fix our setup or convince the install-guide that they need to change theirs.
10:41:54 <dguitarbite> I think pinging the router from its relative namespace should be good enough to test if it is working. Because it always works.
10:42:03 <rluethi> right now, I need the iptable change to make the instance launch test script work on KVM with Liberty.
10:42:10 <dguitarbite> For instance there is nothing wrong with our cluster. The test is kind of flawed IMHO.
10:42:42 <dguitarbite> rluethi: that should be convincing enough for the install guides. For KVM based deployments, we should avoid tweaking the iptables.
10:42:54 <dguitarbite> Sounds like a compelling argument to get our patch merged in there.,
10:43:16 <rluethi> on my system, the ping test accurately predicts where the launch instance script fails, too.
10:43:42 <rluethi> maybe it's libvirt that needs fixing, not the install-guide.
10:44:30 <dguitarbite> rluethi: I believe that libvirt has many flaws.
10:44:41 <dguitarbite> But I am against tweaking the iptable rules set by libvirt,
10:45:20 <rluethi> so, what do you get on your system when you run "PROVIDER=kvm ./tools/repeat_test.sh -b -r 1"?
10:45:24 <dguitarbite> it just disrupts the entire system. For instance the L2 layer protocols were misbehaving on my workstation because the internal deployment tool for SUSE Cloud tweaked libvirt iptables rules to forward the traffic by passing the host machine
10:45:36 <dguitarbite> making it impossible for us to use things like "arp"!!!
10:46:06 <dguitarbite> rluethi: I can post the output for you but it was working for me till I found a bug in the test script. I am testing the cluster and the fix that I have.
10:46:37 <rluethi> It was working until you found a bug?
10:46:50 <dguitarbite> basically using `nova-manage service list --service compute` is not good anymore. We should prefer using `openstack compute service list --service nova-compute` instead.
10:47:01 <dguitarbite> yes, the bug was with this command.
10:47:16 <dguitarbite> I believe that this command is deprecated (I may be wrong here though).
10:47:31 <rluethi> fair enough, but that sounds entirely unrelated to the issue at hand.
10:47:56 <dguitarbite> just that the test scripts stopped and the cluster started rebuilding :| so I could not get an outcome.
10:48:17 <dguitarbite> Meanwhile I did manual testing of launch and instance, pinging it, ssh etc. and it works as expected!
10:48:23 <rluethi> #action rluethi dguitarbite check launch instance test script for deprecated commands
10:49:14 <dguitarbite> rluethi: May be it makes sense to aggregate all these commands into a separate function (if possible?/and/or if it makes sense?)
10:49:17 <rluethi> that probably means that your system's iptables have already been messed with.
10:49:32 <dguitarbite> rluethi: true.
10:49:35 <rluethi> "all these commands"?
10:49:56 <dguitarbite> in the test scripts, may be we create functions which return the output of the command rather than calling the commands directly.
10:50:04 <dguitarbite> May be thats a good idea?
10:50:49 <rluethi> let's see an example.
10:51:36 <dguitarbite> rluethi: ok, not a problem. But I think the only thing it will help us with is updating the commands based on the openstack cli/api version
10:51:42 <dguitarbite> May not be worth the effort.
10:52:17 <rluethi> for the iptables, we can add a message that tells KVM users that they need to enable an additional options to make it work.
10:52:36 <rluethi> YES_MESS_WITH_MY_IPTABLES=yes or something.
10:52:57 <rluethi> without that code, KVM won't work.
10:53:21 <rluethi> at least, that's what my tests on reasonably clean systems say.
10:53:34 <rluethi> debian, opensuse, fedora.
10:53:43 <dguitarbite> rluethi: Even with my workaround?
10:53:55 <dguitarbite> can you check it with my changes using network namespaces?
10:54:11 <rluethi> I told you already, that is cheating. I know that works.
10:54:17 <rluethi> But that's not the point.
10:54:31 <rluethi> you could ping localhost, too, that would work as well.
10:55:09 <dguitarbite> rluethi: How is that cheating? That is more than enough to test if the router is up  and the cluster should work with it!
10:55:27 <dguitarbite> Pinging the router from the network node is optional and I strongly believe that, that test case is not foolproof
10:55:30 <rluethi> it is cheating because it is not what the install-guide says what we should test.
10:55:57 <dguitarbite> rluethi: install-guides can be wrong. I will speak with Matt and see if he agrees with me.
10:56:16 <rluethi> yes. talk to matt.
10:56:18 <dguitarbite> I dont see a point in sacrificing our policy to not touch the host system.
10:56:31 <dguitarbite> rluethi: Awesome. He will wake up around 3~4 pm CET.
10:56:33 <rluethi> it is a collision of several policies.
10:57:12 <dguitarbite> I would prefer sacrificing accuracy with install-gudies over sacrificing host's machine of our users.
10:57:27 <dguitarbite> But you may be right here.
10:57:31 <rluethi> if you talk to him, maybe ask him to describe his physical setup and the configuration so we know what we are trying to replicate.
10:57:40 * dguitarbite sudo over confusing users ?? :\
10:57:52 <dguitarbite> ok, Ill keep this in mind.
10:58:07 <rluethi> problem is, as soon as you use KVM, you a program wildly manipulating iptables.
10:58:11 <rluethi> there is no way around it.
10:58:26 <rluethi> KVM users already signed up for this.
10:58:45 <dguitarbite> rluethi: yes! can we do the same using virsh instead? Atleast it would be less disruptive.
10:58:55 <rluethi> we can still add extra warnings, but so far all my tests indicated that we need the change.
10:59:46 <rluethi> you are very welcome to find a way to do it using libvirt's nwfilters or something else.
11:00:02 <dguitarbite> ok, Ill first speak to Matt.
11:00:21 <rluethi> I was happy to find _some_ plausible fix that worked.
11:00:37 <dguitarbite> Me too! Thanks for trying to fix it.
11:00:38 <rluethi> keep us posted.
11:01:12 <dguitarbite> Yes, Ill start a thread on Docs ML. Also invite people to test Liberty changes. Mostly advertise it for the install-guides specialty team to use it for Mitaka release.
11:01:22 <dguitarbite> rluethi: Anything else on this topic?
11:01:28 <dguitarbite> I think we should move on to other important topics.
11:01:54 <rluethi> I'd wait with advertising until we removed that bugs we know about :)
11:01:58 <rluethi> next topic
11:02:00 <dguitarbite> Yes
11:04:30 <dguitarbite> #topic Summit Talk(s)/Workshops.
11:04:51 <dguitarbite> #info dguitarbite rluethi decide on topics for a talk and workshop/hands-on session.
11:05:37 <rluethi> we need to hash this out by the end of this week.
11:05:49 <dguitarbite> Yes.
11:06:03 <dguitarbite> #action Submit talk proposals by end of this week to meet the dead line.
11:06:34 <rluethi> I have an idea or two for neat features we could present, but they are not up for review yet.
11:06:50 <dguitarbite> Ok! Lets get them merged then :D
11:06:56 <rluethi> they exist as working PoCs, though.
11:07:30 <dguitarbite> I am going to add a slide or two on de-centralized-pair-programming-and-review on a single patch (liberty patch)
11:09:02 <rluethi> Not sure what you mean. I can't wait to see that slide.
11:09:03 <dguitarbite> #topic python port
11:09:18 <dguitarbite> rluethi: Yes I will explain it later :)
11:09:51 <dguitarbite> Progress on python is slower than expected. I am still stuck designing XML handling part for Libvirt which I believe is around 80% progress for KVM backend.
11:10:12 <dguitarbite> I shall try my best again to get some momentum in this direction asap.
11:10:41 <rluethi> I would have used virsh instead of XML interfaces.
11:10:59 <dguitarbite> rluethi: Hmm, it is not so pythonic (if you know what I mean ;) )
11:11:10 <rluethi> XML is not pythonic, either.
11:11:36 <dguitarbite> I am trying to make it ... I'm using inheritance to parse and understand XML for KVM. But we can discuss this later on.
11:11:39 <dguitarbite> #topic AOB?!.&*$
11:11:59 <rluethi> I'm good.
11:12:11 <dguitarbite> rluethi: I discussed about the webpage and hosting tar/zip for training-labs in the last doc's team meeting. I hope to get this in soon.
11:12:28 <dguitarbite> #action dguitarbite send patch to openstack-manuals to publish training-labs webpage.
11:12:48 <rluethi> That would be awesome.
11:12:49 <dguitarbite> one good news is that we shall have a section on the official openstack training page redirecting to training-labs :)
11:12:59 <rluethi> We cannot go to Austin without it.
11:13:08 <dguitarbite> rluethi: true!
11:13:21 <dguitarbite> Im good too. Anything else to discuss?
11:13:42 <rluethi> No. Just don't forget to talk to Matt. It's important to get this straight.
11:14:03 <rluethi> If you find the time, try testing on a fresh setup.
11:14:09 <dguitarbite> Yes, I will do that soon (prob. today).
11:14:10 <rluethi> I use external SSDs for that.
11:14:17 <dguitarbite> rluethi: already started the test run.
11:14:42 <dguitarbite> Not on a fresh setup. What I do these days is `iptables -F && systemctl restart libvirtd.service`
11:14:52 <dguitarbite> its quite the same (hopefully!)
11:15:24 <rluethi> I don't think it is, but I am not sure it is relevant in this case. I'd have to look into it.
11:15:36 <dguitarbite> Yes. See you next week. Bye :)
11:15:50 <rluethi> see you before next week.
11:15:53 <rluethi> bye
11:16:00 * dguitarbite catch me if you can ;)
11:16:00 <dguitarbite> #endmeeting