rm_you | madhu_ak: once you verify that it is still broken let me know, that should have taken care of it | 00:00 |
---|---|---|
rm_you | and gist me your exact steps so i can reproduce and debug | 00:00 |
madhu_ak | just restacked my devstack, running that scenario tests with your fix | 00:07 |
madhu_ak | rm_you, | 00:07 |
madhu_ak | rm_you, okay I dont see that error now. I am getting diferen error now. troubleshooting ... | 00:13 |
rm_you | hmmmmmm | 00:15 |
rm_you | it's possible it was masking something else further along the line | 00:17 |
*** yamamoto has quit IRC | 00:32 | |
madhu_ak | rm_you, I think I have to test manually one by one, so it can get clear information | 00:33 |
madhu_ak | rm_you, http://paste.openstack.org/show/488443/ this is wha I see after I create listener now. But still lb's status is hing in pending_update | 00:37 |
madhu_ak | hung* | 00:37 |
blogan | sbalukoff: ping | 00:37 |
madhu_ak | looking at logs on by one t see if I can get leads | 00:37 |
sbalukoff | blogan: Pong | 00:38 |
blogan | sbalukoff: you got time to talk a bit about the shared pools support in the single create call? | 00:38 |
sbalukoff | blogan: Sure. | 00:38 |
blogan | sbalukoff: so i think you understand the problem of not being able to reference a pool thats already been defined in the same request body | 00:39 |
sbalukoff | blogan: Perhaps I do, or perhaps I don't? | 00:40 |
blogan | sbalukoff: so what you've proposed is an option, but i was thinking that eventually we would support same request body reference by just looking at some kind of equality attribute, like a pool's name | 00:40 |
rm_you | madhu_ak: weird, that does not seem like it is related | 00:40 |
sbalukoff | blogan: that works, but we'll have to update the api types to accept it. | 00:40 |
blogan | sbalukoff: sounded like you did, in that if i want to say this pool is the default pool for 2 listeners in the same request body, thats tough because i can't give a default_pool_id | 00:40 |
sbalukoff | Also note: The way we're crawling through the request body, it helps to know where the pools are going to be, eh. | 00:40 |
sbalukoff | (ie. in a well-defined place) | 00:40 |
sbalukoff | So, for example... | 00:41 |
blogan | sbalukoff: i'm not sure it does, we could just have a dictionary of pools keyed off whatever identifier we want, and if that already exists we use that one, doesn't have to be directly under the lb | 00:41 |
sbalukoff | If the request had a load_balancer.pools array that contained pool definitions, we would know we need to get those set up first in the process because some of them are potentially going to be referenced by listeners and l7policies later on. | 00:41 |
sbalukoff | Sure. | 00:42 |
blogan | but how will the user reference them in the same request body? | 00:42 |
sbalukoff | I don't see why 'id' doesn't work. If you're going to be scripting stuff to create this request body, it's trivial to make up a UUID. | 00:42 |
blogan | so the user provides uuid? | 00:42 |
sbalukoff | And our API allows you to specify your own UUID, so long as nobody else is using it. | 00:42 |
sbalukoff | Technically the neutron-lbaas "user" already does. :) | 00:43 |
blogan | yeah but that was never intended for end-user use | 00:43 |
blogan | shhh no one should know about that! | 00:43 |
sbalukoff | Sure, but I don't see it hurting anything to do this, eh. | 00:43 |
sbalukoff | I mean, we could definitely go with some other identifier. | 00:43 |
sbalukoff | I don't have a strong opinion one way or another. | 00:44 |
sbalukoff | I was just thinking "don't we already have something that fits the bill in this case?" | 00:44 |
blogan | i do, i dont want to tie ourselves to allowing end-users to decide their own uuid | 00:44 |
sbalukoff | Why not? | 00:44 |
sbalukoff | A hidden "feature" is generally not a good idea, eh. | 00:44 |
sbalukoff | And if we can't get away with it with neutron-lbaas... | 00:45 |
madhu_ak | rm_you, hmm, checking | 00:45 |
sbalukoff | er.... can't get away from it... | 00:45 |
blogan | other than having to worry about more validation, which is just a db unique constraint, it feels icky | 00:45 |
sbalukoff | Then why not embrace it? | 00:45 |
blogan | nah the intent is for it ot be admin only | 00:45 |
sbalukoff | Oh-- so neutron-lbaas would be speaking the admin APi, when we get around to creating it? | 00:45 |
sbalukoff | Ok, so sure-- we can go with an arbitrary tag used for identifying a particular object in the same request body. | 00:46 |
sbalukoff | Again, I don't have a strong opinion on this. | 00:46 |
blogan | problem is, we probably dont have time to implement that in both octavia and neutron-lbaas | 00:47 |
sbalukoff | You mean, before Monday? | 00:47 |
blogan | yep | 00:47 |
blogan | and if single create calls goes in on Monday without this, then when we do want to add it in, thats another extension unfortunately | 00:48 |
sbalukoff | Right. So... I think I said this before: We go without it and just file this as a high priority bug in Octavia. | 00:48 |
blogan | which i guess isn't a big deal | 00:48 |
sbalukoff | It should be completely additive. | 00:48 |
sbalukoff | As in.... | 00:48 |
blogan | it would be, but still requires another extension | 00:49 |
sbalukoff | When we have entity-tags support in the single-create API... you can still do single-create without them. | 00:49 |
sbalukoff | Sure. | 00:49 |
openstackgerrit | Madhusudhan Kandadai proposed openstack/octavia: Add pre_test_hook to run gate jobs https://review.openstack.org/284946 | 00:49 |
rm_you | sbalukoff: caught up part way, agree with blogan, DO NOT want users specifying uuid for pools -- use "name" or something and enforce it is unique in the scope of the request | 00:50 |
blogan | alright thanks for talking it out, just wanted to make sure you knew it wasn't intentionally not supporting shared pools | 00:50 |
rm_you | we'd eventually like to move octavia in the direction of being the actual frontend api, in which case we'd need to solve this anyway | 00:50 |
sbalukoff | Again, I'm happy to merge this without share-pools support so long as a high-priority bug gets filed about it. | 00:50 |
rm_you | using neutron-lbaas as cover is short-term at best | 00:51 |
sbalukoff | Sure. | 00:51 |
sbalukoff | Agreed. | 00:51 |
blogan | and a pain to derploy | 00:51 |
rm_you | yeah i think the kind of complicated setups that involve shared-pools are not the target audience for single-create :P | 00:51 |
sbalukoff | Heh. Derploy. :D | 00:51 |
blogan | i really hate having to implement features twice | 00:51 |
sbalukoff | rm_you: You might be surprised. | 00:51 |
blogan | yeah i like derploy over deploy | 00:51 |
*** manishg has quit IRC | 00:52 | |
rm_you | target audience for single-create are people who want to loadbalance http to 3-4 backend nodes and are confused as to why that is complicated enough to require 6+ API calls | 00:52 |
sbalukoff | I guarantee you someone is going to complain about not being able to have the same backend pool for their HTTP and TERMINATED_HTTPS listeners. | 00:52 |
blogan | single create call as it is, still dramatically decreases the number of API calls required by (pulling out of ass) 75% | 00:52 |
sbalukoff | blogan: Agreed. | 00:52 |
*** Aish has quit IRC | 00:53 | |
sbalukoff | Been thinking about features we should push to add in the next cycle... after the deadline next week we should probably start an etherpad and get the discussion rolling on it, eh. | 00:59 |
rm_you | madhu_ak: try using: no SNI and a tls cert with NO intermediates | 00:59 |
rm_you | madhu_ak: if that works, try using a tls cert with an intermediate | 00:59 |
rm_you | madhu_ak: THEN try with adding SNI | 00:59 |
rm_you | which stage it breaks will help me a lot | 00:59 |
madhu_ak | actually its not a problem with SNI/TLS now. I think the error is the LB's status is hung in prending_update | 01:00 |
madhu_ak | so printing one by one and see where it is breaking | 01:00 |
rm_you | kk | 01:01 |
rm_you | madhu_ak: is this on master? i hope it is not broken on master O_o | 01:01 |
madhu_ak | yes. its on master :D :) ;) :( | 01:01 |
*** ajmiller has quit IRC | 01:01 | |
blogan | sbalukoff: if i had a vote, minimize features and increase stability and quality | 01:07 |
sbalukoff | blogan: Of course. | 01:07 |
sbalukoff | I mean: We have a good feature set. | 01:08 |
blogan | sbalukoff: yeah, just missing active/acive? | 01:08 |
sbalukoff | I'm just thinking about things like "our own CLI" and "authenticated API" | 01:08 |
blogan | and job board i guess | 01:08 |
sbalukoff | I suspect I'm going to get pressure to get active-active going. | 01:08 |
blogan | sbalukoff: yeah https://review.openstack.org/#/c/265065/ | 01:08 |
johnsom | We need to expose a bunch of timeout settings too | 01:08 |
blogan | if someone wants to take that over, by all means | 01:08 |
sbalukoff | Yarp. | 01:09 |
blogan | it won't be too hard, but i think i ran into an issue with us using the keystone_authtoken options for other use cases as its really meant to validate auth tokens | 01:10 |
blogan | but that was just a quick attempt, and i could be wrong | 01:10 |
johnsom | I told Doug I think we will want a design summit session. This was the primary topic I thought we could cover | 01:10 |
johnsom | Newton plans that is... | 01:10 |
blogan | johnsom: exposing timeouts? | 01:10 |
sbalukoff | Also starting mid-March, I expect to get increasing pressure to spend more time on internal stuff. It seems someone was paying attention when I was saying "Octavia is awesome and we should use it" and now they want my help making that happen. | 01:10 |
sbalukoff | What a pain! | 01:10 |
sbalukoff | Yes, I think we need a design session and that seems like a good use of it to me. | 01:11 |
blogan | sbalukoff: thats where i'm at now, and while i planned having a decrease in activity for octavia and neutron-lbaas, i didnt plan on it being this much, but this is temporary | 01:11 |
sbalukoff | *nod* | 01:11 |
blogan | don't we usually get a design summit session? | 01:12 |
*** crc32 has quit IRC | 01:12 | |
blogan | was that in flux this time around? | 01:12 |
sbalukoff | Well, I do hope that the Mitaka release sees a lot more adoption of Octavia. | 01:12 |
johnsom | I don't know, but I had the conversation | 01:12 |
sbalukoff | blogan: we have for the last several summits. Though we've had to share sometimes, and only had like 20 minutes to talk about stuff. | 01:13 |
johnsom | Maybe Texas just doesn't have room for us.... | 01:13 |
johnsom | Boom | 01:13 |
sbalukoff | In any case, I'll be there, and as usual, I expect to be mostly spending my time on Octavia Neutron-LBaaS stuff anyway. | 01:13 |
blogan | just austin bc it doesn't have room for highways | 01:13 |
blogan | well ill be at whatever we have | 01:14 |
blogan | i just know i dont have to do any talks! yippeeeee! | 01:14 |
blogan | i dont have to dread going to a summit this time, actually enjoy it | 01:15 |
sbalukoff | Haha! | 01:15 |
sbalukoff | Have they announced which talks got selected yet? | 01:15 |
blogan | i dont think so | 01:15 |
sbalukoff | Ok. | 01:15 |
johnsom | It will still be a few week | 01:16 |
johnsom | s | 01:16 |
sbalukoff | *nod* | 01:16 |
*** minwang2 has quit IRC | 01:18 | |
*** minwang2 has joined #openstack-lbaas | 01:22 | |
rm_you | i won't have time to do image prep and such for octavia demo this time.... will be off the week before the summit, literally flying back to TX the day it starts, straight to austin | 01:22 |
madhu_ak | rm_you, okay, upon investigating, when you create lb, list with tls, pool, lb's status is hung, hence members cannot be created using that pool as it is still waiting for lb to come ONLINE. So the error can be seen at: http://paste.openstack.org/show/488443/ | 01:26 |
rm_you | if you don't use TLS does it still break? | 01:27 |
madhu_ak | checking that too rm_you | 01:28 |
*** yamamoto has joined #openstack-lbaas | 01:29 | |
*** minwang2 has quit IRC | 01:29 | |
madhu_ak | checking whether I can create basic loadbalancer without using TLS.. | 01:29 |
madhu_ak | rm_you, yes, I am able to create members without using TLS | 01:32 |
rm_you | crap | 01:32 |
rm_you | hmm but it's on creating the POOL that it breaks?? not on creating the listener | 01:32 |
madhu_ak | yep. creating pool it breaks :( | 01:33 |
*** yamamoto has quit IRC | 01:34 | |
madhu_ak | rm_you, http://paste.openstack.org/show/488444/ when creating pool with tls, I get invalid status bcoz of lb'sstatus in pending_create. if I dont use TLS, I can see pool is being created along with members. | 01:36 |
madhu_ak | rm_you, leaving for the day, will keep you in the loop if I get ayy further leads | 01:41 |
madhu_ak | any* | 01:41 |
*** madhu_ak is now known as madhu_away | 01:41 | |
*** madhu_away is now known as madhu_ak|away | 01:41 | |
*** woodster_ has quit IRC | 01:46 | |
*** manishg has joined #openstack-lbaas | 01:47 | |
*** Bjoern_ has joined #openstack-lbaas | 01:58 | |
*** ducttape_ has joined #openstack-lbaas | 02:02 | |
*** bana_k has quit IRC | 02:05 | |
*** kevo has quit IRC | 02:12 | |
*** madhu_ak|away has quit IRC | 02:16 | |
*** yamamoto has joined #openstack-lbaas | 02:17 | |
*** sbalukoff has quit IRC | 02:23 | |
*** minwang2 has joined #openstack-lbaas | 02:27 | |
*** yamamoto has quit IRC | 02:32 | |
*** Bjoern_ is now known as Bjoern_zZzZzZzZ | 02:35 | |
*** ducttape_ has quit IRC | 02:36 | |
*** Bjoern_zZzZzZzZ has quit IRC | 02:42 | |
*** jwarendt has quit IRC | 02:46 | |
*** ducttape_ has joined #openstack-lbaas | 02:52 | |
*** Purandar has quit IRC | 02:58 | |
*** manishg has quit IRC | 03:00 | |
*** manishg has joined #openstack-lbaas | 03:03 | |
*** ducttape_ has quit IRC | 03:03 | |
*** ducttape_ has joined #openstack-lbaas | 03:04 | |
*** ajmiller has joined #openstack-lbaas | 03:08 | |
*** woodster_ has joined #openstack-lbaas | 03:09 | |
*** yamamoto has joined #openstack-lbaas | 03:32 | |
*** yamamoto has quit IRC | 03:38 | |
*** ducttape_ has quit IRC | 03:52 | |
*** manishg has quit IRC | 03:58 | |
*** minwang2 has quit IRC | 03:59 | |
*** minwang2 has joined #openstack-lbaas | 04:22 | |
*** armax has quit IRC | 04:26 | |
*** yamamoto has joined #openstack-lbaas | 04:34 | |
*** Purandar has joined #openstack-lbaas | 04:37 | |
*** yamamoto has quit IRC | 04:42 | |
*** manishg has joined #openstack-lbaas | 05:02 | |
*** fnaval has joined #openstack-lbaas | 05:05 | |
*** ajmiller has quit IRC | 05:07 | |
*** manishg has quit IRC | 05:17 | |
*** prabampm has quit IRC | 05:22 | |
*** fnaval_ has joined #openstack-lbaas | 05:38 | |
*** yamamoto has joined #openstack-lbaas | 05:38 | |
*** fnaval has quit IRC | 05:41 | |
*** yamamoto has quit IRC | 05:43 | |
*** prabampm has joined #openstack-lbaas | 05:47 | |
*** manishg has joined #openstack-lbaas | 05:48 | |
*** links has joined #openstack-lbaas | 05:48 | |
*** manishg has quit IRC | 05:53 | |
*** minwang2 has quit IRC | 06:00 | |
*** ducttape_ has joined #openstack-lbaas | 06:06 | |
*** Purandar has quit IRC | 06:09 | |
*** ducttape_ has quit IRC | 06:12 | |
*** yamamoto has joined #openstack-lbaas | 06:39 | |
*** yamamoto has quit IRC | 06:44 | |
*** manishg has joined #openstack-lbaas | 06:49 | |
*** prabampm1 has joined #openstack-lbaas | 06:53 | |
*** manishg has quit IRC | 06:54 | |
*** prabampm has quit IRC | 06:55 | |
*** fnaval has joined #openstack-lbaas | 07:23 | |
*** woodster_ has quit IRC | 07:26 | |
*** fnaval_ has quit IRC | 07:27 | |
*** yamamoto has joined #openstack-lbaas | 07:41 | |
*** yamamoto has quit IRC | 07:46 | |
*** sbalukoff has joined #openstack-lbaas | 07:49 | |
*** manishg has joined #openstack-lbaas | 07:50 | |
*** manishg has quit IRC | 07:55 | |
*** yamamoto has joined #openstack-lbaas | 08:42 | |
*** jwarendt has joined #openstack-lbaas | 08:42 | |
*** jwarendt has quit IRC | 08:47 | |
*** yamamoto has quit IRC | 08:47 | |
*** manishg has joined #openstack-lbaas | 08:51 | |
*** manishg has quit IRC | 08:55 | |
*** ihrachys has joined #openstack-lbaas | 09:00 | |
*** ihrachys has quit IRC | 09:11 | |
*** yamamoto has joined #openstack-lbaas | 09:44 | |
*** yamamoto has quit IRC | 09:49 | |
*** manishg has joined #openstack-lbaas | 09:52 | |
*** fnaval has quit IRC | 09:55 | |
*** manishg has quit IRC | 09:56 | |
*** links has quit IRC | 10:17 | |
*** fnaval has joined #openstack-lbaas | 10:19 | |
*** kobis has quit IRC | 10:23 | |
*** yamamoto has joined #openstack-lbaas | 10:45 | |
*** kobis has joined #openstack-lbaas | 10:45 | |
rm_work | What is doing SSH connections to our Amps in the scenario tests?? http://logs.openstack.org/74/285574/1/check/gate-neutron-lbaasv2-dsvm-scenario/5308a9c/console.html.gz#_2016-02-27_01_25_48_434 | 10:46 |
rm_work | or is that not our amps? | 10:46 |
*** yamamoto has quit IRC | 10:50 | |
*** manishg has joined #openstack-lbaas | 10:52 | |
*** manishg has quit IRC | 10:56 | |
openstackgerrit | Adam Harwell proposed openstack/octavia: Barbican Cert Manager fails to correctly parse intermediates https://review.openstack.org/285574 | 10:59 |
rm_work | Missed some tests, fixed. | 10:59 |
*** openstack has joined #openstack-lbaas | 23:33 | |
*** asimov.freenode.net sets mode: +ns | 23:33 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!