09:03:39 <jamielennox> #startmeeting openstack-qa
09:03:40 <openstack> Meeting started Thu Aug 20 09:03:39 2015 UTC and is due to finish in 60 minutes.  The chair is jamielennox. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:03:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:03:43 <openstack> The meeting name has been set to 'openstack_qa'
09:03:55 <jamielennox> I have no idea how to lead a meeting - particularly one for qa
09:04:09 <jamielennox> however as i'm the only one with stuff on the agenda i may as well
09:04:15 <jamielennox> please let there me other people here
09:04:28 <jordanP> jamielennox, o/
09:04:51 <ylobankov> hi guys
09:04:57 <dmellado> hi all
09:05:55 <jamielennox> so i'm not sure what to do here - does anyone know if there was a plan to skip this week?
09:06:13 <jordanP> jamielennox, I haven"t heard such a thing
09:06:35 <jamielennox> i have no powers on qa, i feel we don't exactly have a quorum
09:07:30 <gmann> hi
09:07:32 <jordanP> afazekas, gmann me from the tempest core team are here, at least.
09:07:41 <jordanP> mkoderer, ping ?
09:07:46 <dmellado> how about just going over the agenda?
09:07:52 <gmann> may be oomichi forgot to send mail.
09:07:52 <jamielennox> #topic V3 identity in devstack
09:08:27 <jamielennox> i sent an email to the mailing list last week saying that we are trying to remove the v2 identity default in devstack
09:08:51 <jamielennox> this has the possible side effect of breaking anyone doing openstackclient identity commands directly (not using things in functions)
09:09:14 <jamielennox> last time i made a breaking change like this there was the general idea that it should be advertised better before hand
09:09:34 <jordanP> jamielennox, no way to be safe and not to break too much ?
09:09:37 <afazekas> hi
09:09:45 <jamielennox> however no-one has responded with any particular concerns to the email - which leads me to believe no one saw it
09:09:59 <jamielennox> jordanP: so if you are using the get_or_create functions that devstack ships then it's fine
09:10:08 <jamielennox> and there are a bunch of commands that are the same in v2/v3
09:10:35 <jamielennox> however things like create a project or create users can be different and i expect there are at least some third party CIs out there
09:10:46 <jamielennox> that use it that way
09:11:12 <jamielennox> One way or another this needs to happen. keysotne has been trying to deprecate v2 auth for ~4 cycles now
09:11:21 <dmellado> so then this change would only break 'theroically' 3rd party CIs?
09:11:28 <jamielennox> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/072048.html
09:11:34 <jamielennox> #link https://review.openstack.org/#/c/186684/
09:11:39 <jordanP> I guess you could send a gentle reminder on the ML, just to be safe. In the end sdague and dtroyer or ianw would have to approve the change
09:11:46 <jamielennox> i have no specific knowledge of anyone that is broken by this
09:11:57 <jamielennox> jordanP: that's the first link :)
09:13:07 <jamielennox> i kind of feel like i'm going to have to wait on that until we can get at least those 3 together
09:13:40 <jamielennox> alright
09:13:40 <jordanP> yeah....
09:13:47 <jamielennox> #topic TLS Support
09:13:54 <jamielennox> (i should have picked a better week :)
09:14:06 <jamielennox> #link https://review.openstack.org/#/c/187346/
09:14:23 <jamielennox> so currently there is supposed to be support for TLS in devstack via a stud proxy
09:14:36 <jordanP> #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_August_20th_2015_.280900_UTC.29 btw, the agenda is here
09:14:37 <jamielennox> this is broken by various services who forget about this case
09:15:07 <jamielennox> There are two patches that do pretty much the same job of fixing this
09:15:20 <jamielennox> the goal here is to at least get devstack gating with TLS support to stop it from getting worse
09:15:34 <jamielennox> sdague has come out against the patch saying we need to fix it in services
09:15:50 <jamielennox> i completely agree - however in the mean time devstack is broken and i would like to get these passed
09:15:58 <jordanP> what do you mean "in services" ?
09:16:27 <jamielennox> so the main issue i'm aware of is that when you do version discovery you need to know your current URL
09:16:53 <jamielennox> if your request has gone through a load balancer this is no longer what the service expects
09:17:16 <jamielennox> and the service will respond with fully qualified URLs that are based on a non-public host
09:17:45 <jamielennox> i feel the long term solution to this is just make all discovery services use relative URLS and ignore determining the host
09:18:29 <jamielennox> to pull this off though is a massive cross project effort with multi cycle deprecations
09:18:56 <jamielennox> and lets face it, they are often not effective
09:19:10 <jamielennox> i don't want to wait to fix devstack on implementing that plan
09:19:25 <jamielennox> ianw has already +2ed
09:20:12 <jamielennox> again, i'm interested in peoples opinions but i think it'll require getting some devstack-core together
09:20:43 <jordanP> I don't like having to hardcode public endpoint in the conf
09:20:52 <jordanP> but I understand that we need an intermediate step
09:21:13 <jamielennox> jordanP: agreed, i'll be honest i thought there was better support from load balancers on this one
09:21:29 <jamielennox> that the original request URL was passed through (i might be wrong and it is)
09:21:39 <jordanP> jamielennox, I remeber when I was an operator we had issue with heat behind a LB
09:21:53 <jamielennox> rcrit: any idea if the original request url is available behind a load balancer?
09:22:05 <jordanP> we had to fordward the HTTP_FORAWRD-PROTOCOL header
09:22:12 <jamielennox> because i know that for example in keystone if public_endpoint is not set in CONF then we take it from the request URL
09:22:29 <jamielennox> jordanP: yep, i've seen that as well, but that handles specifically TLS termination
09:22:33 <rcrit> jamielennox, I don't know.
09:23:08 <jamielennox> rcrit: when you get a chance can you have a look
09:23:17 <rcrit> but keystone is one of the services in the patch
09:23:40 <jamielennox> at the env vars and see if there is some indication of the original request URL
09:24:00 <jamielennox> it's hard to tell on devstack because the TLS terminator is on the same host as the servic
09:24:24 <jamielennox> if available that's a fairly easy path forward
09:24:27 <rcrit> you'd be able to tell by the protocol
09:25:06 <jordanP> that would be LB specific, some LB could forward or give a hint about the original URL, some other LB won't...
09:25:15 <jamielennox> alright, taking this meeting leadership thing by the horns
09:25:28 <rcrit> it could also differ service to service
09:25:40 <jamielennox> #action rcrit to determine if there is a standard way to get original request URL from behind a load balancer
09:25:43 <jamielennox> :)
09:25:57 <jordanP> :D
09:26:21 <rcrit> roger that
09:26:56 <jamielennox> i htink long term we want to go relative URLs but if we can at least deprecate the public_endpoint thing that'd be a good start
09:27:10 <jamielennox> i'll figure out who i need to chase on that one
09:27:49 <jordanP> jamielennox, do you know where exaclty this public_endpoint config is used ?
09:27:49 <jamielennox> #topic Open Discussion
09:27:53 <jamielennox> #undo
09:27:54 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0xa4c2b10>
09:28:11 <jordanP> (just for my info)
09:28:20 <jamielennox> jordanP: so when you do GET / on most services you get the versions back and a link to them
09:28:33 <jamielennox> for most services that's a fully qualified link
09:29:07 <jamielennox> originally you always had to set public_endpoint and that would become the base of those version links
09:29:38 <jamielennox> in keystone at least we deprecated that and we would take the current request URL as the base path
09:29:39 <rcrit> it defaults to the current host using http as the protocol
09:29:49 <jamielennox> because that had obviously gotten you to the service
09:30:06 <jamielennox> then we did the X-Forwarded-Proto thing for TLS
09:30:34 <jamielennox> but i would have thought there must be a way to determine the original URL
09:31:34 <jordanP> jamielennox, you can always have your LB add extra HTTP header
09:31:43 <jordanP> but it's not standard practise
09:32:19 <jamielennox> jordanP: yea, but then we need to figure out every load balancer, we could set a config to receive what that variable name was but i'd prefer just to get rid of the practice
09:32:40 <jamielennox> honestly i don't think many people are actually relying on the version and links in the response anyway
09:32:52 <jamielennox> i would be surprised if people noticed let alone were broken
09:33:01 <jordanP> yep
09:33:33 <jamielennox> anyway - i guess that's a cross project spec so i'll look at that
09:34:02 <jamielennox> #action jamielennox figure out a cross project spec for removing absolute links in projects
09:34:22 <jamielennox> #topic Anything Else
09:34:35 <jamielennox> theres a few tempest people - is there anything you are looking to discuss?
09:35:26 <jordanP> gmann, I am a bit overwhelm by your "Return complete response" work :)
09:35:46 <gmann> jordanP: sorry, stuck in nove thing
09:35:51 <jamielennox> jordanP: i'll happily topic it if you let me know what it is
09:36:03 <jordanP> jamielennox, that would be open discussion :)
09:36:16 <gmann> jordanP: so now we going for those first than UT
09:36:28 <jordanP> gmann, UT is done no ?
09:36:34 <jamielennox> jordanP: roger that
09:36:50 <jordanP> gmann, not really in fact, I've checked
09:36:57 <gmann> jordanP: no, actually progress was slow there and even that can be done on lib too
09:37:25 <jordanP> let's see how far Kenji Yasui can go
09:37:26 <gmann> jordanP: added one more guy today from my team lets see if that goes well :)
09:37:34 <gmann> jordanP: yea
09:38:27 <jordanP> gmann, Kenji Yasui is getting better and better. His patchsets 1 are mostly good now
09:38:43 <jordanP> we good expect good progress in the next week
09:38:51 <jordanP> granted we review his work
09:39:07 <gmann> jordanP: ok .
09:39:35 <dmellado> I also wanted to know if there's anyone around that knows what the current state for dhcpv6 in tempest (really in cirros)
09:40:09 <dmellado> I wanted to add dhcpv6 stateful scenario tests but as I discussed in last meeting it's still not fully supported
09:40:20 <dmellado> Last bug I found was this https://bugs.launchpad.net/tempest/+bug/1366326
09:40:20 <openstack> Launchpad bug 1366326 in CirrOS "ipv6 support" [Medium,Confirmed]
09:41:31 <jordanP> dmellado, so is there a bug with tempest ? I mean did you run Tempest with let's say ubuntu instead of cirros ?
09:41:33 <dmellado> jordanP: suggested to try manila approach but and use another image but I'm not really sure how that would pass the gate
09:41:40 <dmellado> jordanP: it's a cirros issue
09:41:54 <dmellado> using another image, if it supports dhcpv6 (not in cirros) it just works
09:42:05 <jordanP> dmellado, that's a good start
09:42:50 <jordanP> then I guess you should brought this topic to Cirros ML
09:42:57 <jordanP> make some noise... as usual :)
09:43:09 <dmellado> I'll do, let's see if we can get to have that implemented
09:43:31 <jordanP> yep, that's the only way I can think of
09:43:35 <dmellado> because tempest gate checks are limited to cirros image, usually, isn't it?
09:43:51 <jordanP> dmellado, yep. And this is not going to change as far as I can see
09:43:57 <jordanP> cirros image are very very convenient
09:44:11 <dmellado> roger that jordanP, I agree on that
09:44:23 <jordanP> switching to something else would really increase the requirements to run the gate jobs
09:45:05 <dmellado> I'll try to bring some noise to have ipv6 tools inside cirros, wish me luck XD
09:45:11 <dmellado> thanks jordanP
09:45:15 <jordanP> dmellado, did you read https://bugs.launchpad.net/tempest/+bug/1366326/comments/5 comment ?
09:45:15 <openstack> Launchpad bug 1366326 in CirrOS "ipv6 support" [Medium,Confirmed]
09:45:40 <jordanP> maybe you can work with this person to see if we made some progress
09:45:43 <jordanP> *he
09:45:46 <dmellado> yes, just read it, that's why I wanted to know about the status
09:45:54 <dmellado> I can check with him
09:46:49 <jordanP> that won"t be an easy task but full ipv6 in cirros would benefit to a lot of people
09:47:36 <jordanP> someone has something else to say ?
09:47:53 <jamielennox> #action jamielennox to copy all his topics to next week
09:48:07 <jamielennox> anyone else?
09:48:29 <jamielennox> alright - thanks for coming
09:48:48 <jamielennox> #endmeeting