14:00:20 <topol> #startmeeting interop_challenge
14:00:21 <openstack> Meeting started Wed Sep 14 14:00:20 2016 UTC and is due to finish in 60 minutes.  The chair is topol. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:25 <openstack> The meeting name has been set to 'interop_challenge'
14:00:31 <tongli> o/
14:00:36 <markvoelker> o/
14:00:37 <topol> Hi everyone, who is here for the interop challenge meeting today?
14:00:46 <skazi> o/
14:00:52 <Rockyg> o/
14:01:00 <catherine_d|1> o/
14:01:17 <topol> The agenda for today can be found at:
14:01:18 <topol> #link https://etherpad.openstack.org/p/interop-challenge-meeting-2016-09-14
14:01:18 <topol> We can use this same etherpad to take notes
14:01:44 <topol> #topic review action items from previous meeting
14:02:00 <topol> #link http://eavesdrop.openstack.org/meetings/interop_challenge/2016/interop_challenge.2016-09-07-14.00.html
14:02:19 <topol> tongli topol check on ATT NFV workload scripts.
14:02:19 <topol> tongli and topol to check with MarkBaker on write up/point to some docs instructing people how to get going (juju + NFV)
14:02:46 <topol> I don't believe we got anything on this. MarkBaker you around?
14:03:08 <luzC> o/
14:03:19 <topol> I think we are running out of time for this to make it for Barcelona
14:03:58 <luzC> sorry to be late, what is the topic?
14:04:12 <topol> especially based on foundation feedback which I will get to later
14:04:13 <eeiden> Hey all -- sorry was out of the office for about a week and a half. I'm 90% sure we have a workload ready to go, just need to get in contact with the owner.
14:04:53 <topol> eeiden, okay let see what shows up.
14:05:08 <topol> luzC we are reviewing action items from last meeting
14:05:16 <luzC> cool, thanks
14:05:34 <topol> Next action was fredli, will take the action to find out about the DT cloud.
14:05:41 <topol> any update on DT cloud?
14:05:59 <JASON__> Hi, all
14:06:30 <topol> Rockyg, any idea about DT cloud?
14:06:55 <pilgrimstack> Hi from OVH
14:07:01 <JASON__> We will get the answer from DT cloud by end of this week
14:07:06 <Rockyg> JASON__,    topol just asked about dt cloud.  any update?
14:07:17 <topol> JASON__, cool
14:07:23 <Rockyg> thanks
14:07:30 <JASON__> we have forwarded the message to them in last week
14:07:40 <topol> pilgrimstack what does OVH stand for just curiously?
14:08:00 <topol> #action JASON__, Rockyg  to check on DT cloud
14:08:25 <tongli> @topol, both Huawei public cloud and DT cloud, I think.
14:08:39 <JASON__> BTW , We are prepare the testing on HW cloud since last meeting with tongli
14:08:46 <pilgrimstack> topol: what do you mean? what do you want to know?
14:08:50 <JASON__> Got it
14:08:50 <Rockyg> tongli, yes, right
14:09:05 <topol> #action JASON__, Rockyg  to check on Huaweii cloud as well
14:09:12 <JASON__> I will pass the message to all of your guys asap
14:09:26 <topol> pilgrimstack, its an acronym correct?  Like IBM is Intenrational Business Machines
14:09:32 <JASON__> Sure, topol
14:09:42 <JASON__> I will report the progress
14:10:14 * topol I didnt know what OVH stood for as an acronym.  And since your cloud is working with the workloads wanted to know :-)
14:10:28 <JASON__> we have team to support the testing , but i need tongli help as well .
14:10:45 <topol> JASON__ you may have tongli :-)
14:11:00 <JASON__> thanks , topol .
14:11:12 <pilgrimstack> haha, good question, their is many different stories :p the main one is "On Vous Heberge" in french which means "We Host You"
14:11:36 <topol> pilgrimstack, That works. Thanks
14:12:05 <tongli> @pilgrimstack, thanks for pointing me to a different region. BTW, both region worked.
14:12:13 <topol> next item Rockyg to post request for clouds to openstack-ops ML
14:12:48 <topol> Rockyg were you able to do that?
14:12:58 <Rockyg> oh.  dang.  that was me, too?  dang. today
14:13:28 <topol> ok perfect.  #action Rockyg to post to openstack-ops ML
14:13:35 <JASON__> @tongli, rocky, do you know the progress of DefCore guideline
14:13:46 <topol> next item catherine_d|1 to provide new wiki section for volunteer a cloud acct/who to contact
14:13:49 <topol> this was done
14:13:56 <catherine_d|1> yup
14:14:01 <topol> Thanks!
14:14:20 <topol> next item pilgrimstack1 to run workload and also get tongli acess
14:14:30 <Rockyg> link, please?
14:14:47 <topol> I believe this is done.  tongli is able to succesfully run on OVH
14:15:17 <tongli> @topol, yes. OVH worked well in terms of interop.
14:15:45 <tongli> so did OSIC cloud. with no issues.
14:15:52 <topol> catherine_d|1 where did you add this?
14:16:30 <topol> yes, towards the end we will cover where workloads are successfully running. we have a list
14:16:36 <JASON__> @all , when the deadline of testing ?
14:16:42 <catherine_d|1> one sec ..
14:17:20 <topol> JASON__ we agreed two weeks before Barcelona.  But But sooner is always much better
14:17:30 <luzC> tongli on OSIC cloud you are changing terraform workload to use Ansible instead right?
14:17:31 <JASON__> thanks.
14:17:37 <topol> especially since the foundation is reviewing stuff
14:17:51 <topol> okay todays agenda items
14:18:08 <tongli> @luzC, yes, terraform won't work against many clouds since the multiple endpoints issue,
14:18:27 <topol> yes, the terraform issue is on todays agenda
14:18:28 <tongli> that can not be resolved by changing scripts.
14:18:40 <topol> we'll get there folks. I promise
14:18:45 <topol> #topic Update from meeting/demo with OpenStack Foundation Jonathan Bryce
14:19:05 <topol> Demo went well.  Jonathan most like the LAMPStack workload because it was a true enterprise app with security rules, etc.  This is the app he wants folks to see running across multiple cloud targets
14:19:38 <topol> He had an upcoming production call where they will discuss how to show off.
14:20:39 <topol> So everyone should focus on that workload as the priority since that is the one that fits best into the foundations messaging on this topic during the Barcelona keynote day 2
14:21:15 <JASON__> got it
14:21:19 <catherine_d|1> Rockyg: https://wiki.openstack.org/wiki/Interop_Challenge  under the " Test Candidate Process" with tongli: 's contact info
14:21:28 <hj-hpe> Sorry, I got late to the party this morning
14:21:49 <topol> so this workload uses advanced features like security groups that not all clouds support.  Jonathan's preference was that we stick with this workload because it is a true enterprise workload
14:21:56 <Rockyg> thanks
14:22:30 <topol> and Jonathan was okay if a few clouds could not run this workload.  That just leaves room for improvement
14:23:02 <topol> I would suspect as part of the Keynote they will have several of us up on stage representing the different participating vendors. We’ll keep you posted.
14:23:10 <topol> I also expect we will be asked for quotes from the different vendors on the importance of interop/value of the the work.
14:23:37 <topol> #action please figure out who is the right executive in your company that is supposed to handle quotes for the press.  We will need to have PR folks contact them and will need to move quickly on that.  Check with your OpenStack Board member rep.
14:23:52 <topol> They typically do it or know who should
14:24:34 <topol> several folks were in attendance with the meeting with Jonathan. Anything else folks would like to mention?
14:24:55 <topol> MarkVoelker, Rockyg? ^
14:25:22 <topol> markvoelker
14:25:23 <Rockyg> Other than the demo went well, nope.
14:25:23 * markvoelker has nothing further
14:25:29 <topol> cool
14:25:40 <topol> next topic:
14:25:56 <topol> #topic  Interop-challenge code repository, should we establish a more responsive project?
14:26:24 <topol> So Im getting lots of complaints that where we are trying to host the workloads reviews/merges are taking too long
14:26:42 <topol> someone suggested #link https://github.com/openstack/defcore
14:27:14 <Rockyg> met with the app ecosystem wg.  They are interested, but timeline might be too long.
14:27:52 <markvoelker> Currently that repo has three cores: myself, hogepodge, and eglute.  I'm not opposed to creating a contrib directory or something if it's helpful.
14:28:26 <tongli> @markvoelker, that repo is quite big, that is only my concern.
14:29:18 <topol> tongli as part of the demo do you have to clone the repo or that step is already done?
14:29:20 <tongli> @markvoelker, not against using it though.
14:29:36 <topol> where does it being a large repo impact us?
14:30:09 <luzC> I think because of the nature of the workloads is better to keep them on osops-tools-contrib
14:30:26 <luzC> but not sure how to accelerate the review process
14:30:31 <topol> luzC can we get faster reviews?
14:30:51 <luzC> probably posting on the ops channel when pending reviews are in the queue
14:31:16 <luzC> looking for the ptl (if any)... not sure how that particular group works
14:31:52 <topol> luzC, K please see if we can get reviews speeded up.
14:32:27 <topol> we have other repos where we could make everyone cores. tongli has OpenStaclk kiloeyes
14:32:59 <topol> tongli has big patches that need reviewed I believe
14:33:02 <tongli> https://review.openstack.org/#/q/project:openstack/kiloeyes
14:33:29 <topol> #action luzC to see if we can get reviews speeded up
14:33:51 <tongli> that repo was created for a different purpose, I own it but it is a openstack big tent project.
14:33:51 <topol> tongli did your big patches get reviewed yet?
14:34:01 <tongli> if we want to remake that repo, I am ok.
14:34:08 <tongli> @topol, no.
14:34:17 <markvoelker> #link https://review.openstack.org/#/c/366784/ < tongli's big patch
14:35:02 <markvoelker> tongli is this still WIP or has it settled now?  I noticed several new patchsets coming in over the past couple of days after I initially reviewed it
14:35:13 <tongli> mark reviewed the earlier version, but since then I have made a lot of changes, mainly to add ansible docker swarm tests
14:36:06 * markvoelker notes for future reference that it would probably be easier to attract core reviews if the changes were broken out into separate reviews...this patch does 3 different things.
14:36:07 <tongli> @markvoelker, now the patch is final, not WIP.
14:36:11 <markvoelker> thanks
14:36:16 <markvoelker> I'll review it again
14:36:40 <luzC> me too
14:36:44 <markvoelker> (and run it again)
14:36:48 <tongli> @markvoelker, not plan to change anything unless something really bad found.
14:37:18 <topol> given the foundation is most excited about this workload and its hopefully final, this problem may not be as big an issue
14:37:35 <topol> does that seem correct to everyone?
14:38:09 <topol> let's see if we can make the current repo work
14:38:31 <topol> unless folks have a better suggestion?
14:38:53 <topol> luzC, markvoelker, tongli thoughts?
14:39:09 <markvoelker> Fine by me
14:39:14 <luzC> +1
14:39:23 <topol> K
14:39:27 <tongli> @topol, ok, I will keep sending the request for review emails to the defcore channel
14:39:39 <topol> next topic
14:39:53 <topol> #topic Tenant network assumption in the workloads
14:39:58 <tongli> probably going to piss off few, but brad will take them to lunch in barcelona.
14:40:16 <topol> lunch, beers, both
14:40:20 <topol> some vendors do not expose or support tenant network, lampstack workload has been modified to accommodate that setup. A tenant network is no longer needed
14:40:40 <topol> so tongli, question on this
14:41:22 <topol> when tenant network is no longer required  you no longer use the security groups stuff correct?
14:41:43 <tongli> security group is still needed.
14:41:59 <tongli> when tenant network is not exposed, the script just does not use one.
14:42:14 <rohit404> ^ topol: nice to have the flexibility for non-tenant networks (provider networks i assume)
14:42:23 <tongli> security groups created against like all hosts not on specific subnet.
14:43:06 <tongli> it is more of flat network vs overlay network.
14:43:13 <tongli> the script now handle both.
14:43:26 <tongli> if you do not have a tenant network, leave that parameter blank.
14:43:32 <topol> ok good.  so even with the non-tenant network we don't lose our enterprise features with port egress and ingress?
14:43:34 <tongli> but security group is required.
14:43:57 <tongli> if your cloud does not allow security group, the script fails.
14:44:18 <tongli> @topol, right. we do not lose anything.
14:44:31 <tongli> will use whatever the cloud default to.
14:44:43 <topol> tongli, ok good. so hopefully these changes allow more clouds to run the workload.
14:44:44 <tongli> but security group is still required.
14:44:53 <topol> ok cool.
14:44:56 <tongli> rright.
14:44:57 <tongli> right.
14:45:03 <topol> thanks for doing this tongli
14:45:05 <JASON__> i suggest we need to check with cloud service guys
14:45:19 <topol> next topic and its a biggie
14:45:32 <topol> #topic Terraform falls over when multiple endpoints for a service (such as compute server) exist from a cloud,
14:46:00 <topol> so Tong ran into this in the OSIC cloud.
14:46:16 <topol> appears to be a well know bug in TerraForm.
14:46:31 <tongli> terraform has code specifically detect if a OS service has multiple endpoints, if there is, the code simply throw an error and quit
14:46:47 <tongli> this is a problem I can not overcome by changing the work load scripts.
14:46:56 <topol> and the only way Tong got around this was to create an Ansible playbooks for the docker swarm workload
14:47:07 <topol> tongli did I get everything correct on this?
14:47:18 <tongli> so I rewrote the work load scripts using ansible which also allows one to run work load a lot easier
14:47:23 <markvoelker> For clarity: you mean like a cloud for which there are multiple regions?  Or a cloud which supports both KEystone v2 and v3?  Or...?
14:47:45 <tongli> @markvoelker, not multiple regions.
14:47:45 * topol that question is for tong:-)
14:48:03 <topol> two nova endpoint versions?
14:48:11 <tongli> @markvoelker, say your cloud in a region supports couple v2 and v2.1 endpoints,
14:48:18 <tongli> terrafrom will fail in this case.
14:49:06 <tongli> say your cloud supports both compute 2.0 and 2.1 endpoints, terrafrom will fail.
14:49:27 <topol> so anyone know any terraform experts?
14:49:32 <tongli> I suspect this will be quite common. OSIC does that, that is where I found the issue.
14:49:33 <markvoelker> Is it checking the catalog, or just using what's in "GET / http://myapiserver:8774/" ?
14:50:12 <tongli> @markvoelker, I think terraform OS cloud module checks against keystone to get various service endpoints.
14:50:29 <tongli> you may notice in the work load tests, we only give keystone endpoint.
14:50:58 <tongli> there is no any other endpoints given. cloud modules work under the cover for different service endpoints.
14:51:09 <tongli> which is actually a good thing for interop.
14:51:25 <tongli> this in a way testing how keystone works.
14:51:44 <topol> so we can check with the bluebox team since they have experience with TerraForm.  unless anyone knows of a better terraform guru
14:51:47 <markvoelker> Ok, guess that explains why a lot of folks haven't run into this then.  Most private cloud catalogs I see only contain one nova endpoint even if it supports v2 and v2.1.
14:52:18 <tongli> as long as there is one end point per service , it is fine.
14:52:19 <topol> markvoelker ++ but in OSIC  its gameover :-)
14:52:30 <tongli> does not matter 2.0 or 2.1
14:52:57 <tongli> but I can not be 100% sure. I also noticed that terraform states some version supports on openstack.
14:53:06 <tongli> I am a bit worried about continuing using it.
14:53:13 <tongli> vs ansible , it just uses shade.
14:53:41 <topol> so tongli and I can check with our gurus. But tongli provided ansible because we are nervous about this
14:53:44 <markvoelker> So topol, what's the ask here?  You want us to re-run using the ansible version of the workload?
14:53:54 <tongli> terraform was created using go lang, so the OS module will have to be recreated a lot of what shade does.
14:54:10 <topol> hmmm.  good question markvoelker
14:54:27 <topol> what do you recommend?
14:54:33 * markvoelker notes that tong's patch referenced above contains the new code
14:54:42 <tongli> @markvoelker, I would say yes, if your cloud is already working with terraform and lampstack,
14:54:54 <tongli> running ansible script takes even less time for docker swarm.
14:55:09 <tongli> it will also show when the script started and how long it took to finish.
14:55:32 <topol> that would be helpful if folks could try the new ansible script. if terraform already works my view is you still get the checkbox
14:55:43 <topol> but under our lessons learned we need to flag this
14:55:44 <tongli> the instruction is here for docker swarm. https://review.openstack.org/#/c/366784/7/ansible/dockerswarm/README.md
14:55:47 <markvoelker> IMHO it seems like there's some knowledge uncovered here that people would want to know about.
14:56:02 <topol> markvoelker DEFINITELY
14:56:20 <topol> markvoelker you are reading my mind
14:56:21 <tongli> @markvoelker, +1
14:56:35 <markvoelker> I would kinda hate to see us tell people not to use the terraform version at all anymore if only a handful have run it so far and it's uncovered something interesting.
14:56:47 <markvoelker> Personally I don't mind running both versions...they're quick.
14:56:54 <topol> markvoelker cool
14:57:03 <tongli> right.
14:57:13 <topol> I agree. Let's ask folks to try and run both.
14:57:31 <luzC> agree
14:57:41 <tongli> if just use ansible one, you only need to setup ansible env.
14:57:46 <topol> #action all  try and run both terraform and ansible of docker swarm
14:57:48 <tongli> not both ansible and terraform.
14:57:53 <topol> okay last item
14:58:04 <topol> #topic Tong needs to test on other folks public clouds ASAP. Here are the cloud Tong has tested against
14:58:18 <topol> OSIC - lampstack and docker swarm both successful
14:58:18 <topol> OVH - lampstack and docker swarm both successful
14:58:18 <topol> IBM Bluebox - lampstack and docker swarm both successful
14:58:19 <topol> RAX Public Cloud-As far as we can tell RAX public cloud does not support security groups  LAMPStack will not run
14:58:21 <topol> Mirantis ?
14:58:24 <topol> Huawei ?
14:58:25 <topol> any updates to this
14:58:35 <topol> RAX public is an issue.
14:58:38 <JASON__> DT?
14:58:40 <JASON__> maybe
14:58:50 <rarcea> so, for SUSE we are testing inhouse and will report the results soon
14:59:01 <topol> JASON__  yes please :-)
14:59:03 <tongli> RAX cloud does not support security group, both test won't run, not only lampstack.
14:59:09 <topol> rarcea. cool let us know
14:59:23 <topol> eglute need your guidance on RAX public
14:59:51 <topol> #action tong and brad to ask eglute about running on RAX public and security group support
15:00:28 <topol> so folks based on foundation input please try and run LAMPStack workload first since they will want to demo that
15:00:47 <topol> #action all please prioritize testing of LAMPStack
15:00:48 <tongli> I think Mr. Bryce is pretty happy with use of ansible.
15:01:10 <tongli> he made some comments on ansible, do not remember exact words.
15:01:19 <topol> I think we covered everything and we are out of time. pelase folks keep running workloads. Bug us if you need help!!!
15:01:24 <topol> Thanks everyone!
15:01:32 <JASON__> thanks
15:01:57 <topol> #endmeeting