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