Thursday, 2019-07-11

*** spatel has quit IRC00:10
*** openstackgerrit has joined #openstack-lbaas00:33
openstackgerritMichael Johnson proposed openstack/octavia master: Make amphora use a single HAProxy instance  https://review.opendev.org/66806800:33
*** hongbin has joined #openstack-lbaas00:57
*** ricolin has joined #openstack-lbaas01:23
*** mithilarun has quit IRC01:29
*** spatel has joined #openstack-lbaas01:30
*** irclogbot_2 has joined #openstack-lbaas02:06
*** irclogbot_2 has quit IRC02:13
*** KeithMnemonic has quit IRC02:13
*** irclogbot_3 has joined #openstack-lbaas02:16
*** altlogbot_0 has joined #openstack-lbaas02:18
*** irclogbot_3 has quit IRC02:19
*** rcernin has quit IRC02:29
*** altlogbot_0 has quit IRC02:34
*** rcernin has joined #openstack-lbaas02:46
*** irclogbot_2 has joined #openstack-lbaas03:20
*** psachin has joined #openstack-lbaas03:21
*** irclogbot_2 has quit IRC03:25
*** psachin has quit IRC03:38
*** rcernin has quit IRC03:39
*** hongbin has quit IRC03:44
*** spatel has quit IRC03:50
*** altlogbot_1 has joined #openstack-lbaas03:54
*** rcernin has joined #openstack-lbaas03:55
openstackgerritNoboru Iwamatsu proposed openstack/octavia master: Add failover logging to show the amphora details.  https://review.opendev.org/66731603:56
*** altlogbot_1 has quit IRC03:59
*** gcheresh_ has joined #openstack-lbaas04:34
*** pcaruana has joined #openstack-lbaas04:55
*** ccamposr has joined #openstack-lbaas05:18
*** ccamposr__ has quit IRC05:20
*** yamamoto has quit IRC05:27
*** yamamoto has joined #openstack-lbaas05:33
*** gcheresh_ has quit IRC05:34
*** yamamoto has quit IRC05:40
*** gcheresh_ has joined #openstack-lbaas05:40
*** ajay33 has joined #openstack-lbaas05:40
*** mithilarun has joined #openstack-lbaas05:53
*** ccamposr__ has joined #openstack-lbaas05:57
*** gcheresh_ has quit IRC05:58
*** ccamposr has quit IRC06:00
*** mithilarun has quit IRC06:03
*** altlogbot_3 has joined #openstack-lbaas06:18
*** altlogbot_3 has quit IRC06:23
*** altlogbot_2 has joined #openstack-lbaas06:24
*** altlogbot_2 has quit IRC06:29
*** rpittau|afk is now known as rpittau06:33
*** yamamoto has joined #openstack-lbaas06:35
*** ricolin has quit IRC06:39
*** luksky11 has joined #openstack-lbaas06:39
*** yamamoto has quit IRC06:45
*** ricolin has joined #openstack-lbaas06:46
*** altlogbot_1 has joined #openstack-lbaas06:56
*** altlogbot_1 has quit IRC07:01
*** ianychoi_ is now known as ianychoi07:01
*** ivve has joined #openstack-lbaas07:04
*** gcheresh_ has joined #openstack-lbaas07:11
ivvejohnsom, sapd1: i solved the initial problem (from yesterday) however, when i poke the failover api it creates one new amphora and sets it in allocated, standalone. the lb's state enters pending_update and healthmanager keeps yelling that it can't reach the "other" amphora in the lb07:11
ivveso basically it looks like it created the backup and keeps whining about the master is not reachable. further poking failover won't work and i have tried manipulating updates on agent and fiddling with amphoras, but they are all immutable07:12
*** irclogbot_0 has joined #openstack-lbaas07:16
*** rcernin has quit IRC07:17
ivve(initial problem was dns, which is solved now)07:20
*** irclogbot_0 has quit IRC07:21
*** irclogbot_0 has joined #openstack-lbaas07:24
*** irclogbot_0 has quit IRC07:27
*** altlogbot_0 has joined #openstack-lbaas07:48
*** altlogbot_0 has quit IRC07:49
*** irclogbot_2 has joined #openstack-lbaas07:52
*** irclogbot_2 has quit IRC07:55
*** irclogbot_2 has joined #openstack-lbaas08:08
*** tkajinam has quit IRC08:10
ivveim getting some nova-api error regarding PortNotUsableDNS08:12
*** irclogbot_2 has quit IRC08:13
*** yamamoto has joined #openstack-lbaas08:32
*** ccamposr has joined #openstack-lbaas08:51
*** ccamposr__ has quit IRC08:53
*** ianychoi has quit IRC08:54
*** yamamoto has quit IRC08:55
*** yamamoto has joined #openstack-lbaas09:02
*** yamamoto has quit IRC09:02
*** yamamoto has joined #openstack-lbaas09:03
*** yamamoto has quit IRC09:07
*** yamamoto has joined #openstack-lbaas09:08
*** ianychoi has joined #openstack-lbaas09:38
*** yamamoto has quit IRC09:44
*** irclogbot_0 has joined #openstack-lbaas09:48
*** irclogbot_0 has quit IRC09:51
*** psachin has joined #openstack-lbaas10:13
*** altlogbot_2 has joined #openstack-lbaas10:26
*** altlogbot_2 has quit IRC10:29
*** altlogbot_3 has joined #openstack-lbaas10:34
straldiFor the problem of yesterday I try different way to configure the keystone section and auth section in octavia.conf but I have always the same problem. I try to put the debug to true and in the api log I found 2019-07-11 12:34:41.931 10793 DEBUG wsme.api [req-19024fa2-20e4-4433-a75e-4a7ff1c2a373 - - - - -] Client-side error: Validation failure: Missing project ID in request where one is required. format_exception /usr/lib/python2.7/site-packa10:37
straldibut the --project is not mandatory in client openstak loadbalancer create. I add I have in my openrc file the OS_PROJECT_NAME set10:38
*** altlogbot_3 has quit IRC10:39
*** altlogbot_3 has joined #openstack-lbaas10:40
*** irclogbot_1 has joined #openstack-lbaas10:40
*** altlogbot_3 has quit IRC10:45
*** irclogbot_1 has quit IRC10:45
*** altlogbot_1 has joined #openstack-lbaas10:56
*** altlogbot_1 has quit IRC11:01
*** tesseract has joined #openstack-lbaas11:21
*** yamamoto has joined #openstack-lbaas11:45
*** yamamoto has quit IRC11:53
*** altlogbot_2 has joined #openstack-lbaas11:56
*** altlogbot_2 has quit IRC12:01
sapd1ivve, oh, because the health manager has job from message queue, so it continue to failover loadbalancer. you can restart healthmanager. You have to check 2 amphora which are allocated for this loadbalancer, If you have only one, you can update status in your database from DELETED to ACTIVE then perform failover again.12:02
sapd1this is tricky.12:02
ivveok just status, no problem12:03
ivvesapd1: ill test that, thanks!12:04
*** boden has joined #openstack-lbaas12:12
*** henriqueof has joined #openstack-lbaas12:23
*** henriqueof has quit IRC12:28
*** irclogbot_1 has joined #openstack-lbaas12:32
*** KeithMnemonic has joined #openstack-lbaas12:33
*** irclogbot_1 has quit IRC12:35
*** luksky11 has quit IRC12:41
*** altlogbot_1 has joined #openstack-lbaas12:50
*** altlogbot_1 has quit IRC12:53
*** yamamoto has joined #openstack-lbaas13:23
*** luksky11 has joined #openstack-lbaas13:29
*** goldyfruit has joined #openstack-lbaas13:33
*** irclogbot_0 has joined #openstack-lbaas13:40
*** irclogbot_0 has quit IRC13:45
*** yamamoto has quit IRC13:51
dulekcgoncalves, johnsom: Hi! I assume that the Rocky version issue with HTTPS health monitors and not being able to set url_path is known?14:10
dulekcgoncalves, johnsom: We just stumbled upon it. My question is - for HTTPS can I just not set url_path and it'll default to "/"?14:12
johnsomdulek Rocky didn't support HTTPS health monitors14:12
dulekjohnsom: So this is incorrect: https://github.com/openstack/octavia/blob/stable/rocky/octavia/common/constants.py#L35-L38 ?14:13
johnsomdulek Well, I should clarify, it supports the "HTTPS" type, but that is a TLS handshake, not a "GET"14:14
dulekjohnsom: Oh, this actually does help me! :)14:14
dulekThough it's a bit hard now to code HM for both Rocky and Stein…14:15
dulekBut in my case it'll work as I can live with "/" being the url_path.14:15
dulekjohnsom: Thanks!14:15
*** gcheresh_ has quit IRC14:17
johnsomdulek Backend TLS came in Stein14:18
johnsomdulek In Stein, HTTPS becomes a GET, and we added TLS-HELLO14:19
johnsomstraldi That sounds like the keystone_auth configuration is unable to get the user's project information.14:20
*** yamamoto has joined #openstack-lbaas14:22
*** spatel has joined #openstack-lbaas14:23
*** spatel has quit IRC14:23
*** amuller has joined #openstack-lbaas14:27
dulekjohnsom: Can I discover that through versions? git blame doesn't help and there seems nothing on API reference about what version supports what?14:28
straldijohnsom yes seems like that, but  I don't know why. All the other commands (openstack server, network, subnet, image,...) for component nova, glance, neutron work fine. So it is only octavia is not working properly. Now I install only octavia may be I have to configure neutron with lbaas pointing octavbia?14:29
straldioctavia14:29
*** maciejjozefczyk has joined #openstack-lbaas14:29
johnsomstraldi We don't recommend using neutron-lbaas. It has been retired (code is removed from master). It also will not solve this issue.14:31
johnsomstralfi Try copying the keystone_auth configuration from your nova/neutron configuration files into the keystone_auth section in the octavia.conf. That isn't octavia code, it's a shared library we all use, so it should work the same.14:32
straldiyes I know and it is beacuse I decide to install only octavia on the top of my openstack infrastructure14:32
johnsomdulek I just noticed that myself. I don't even see the release note I thought was included in that change. I'm looking for zhao's patch now14:33
johnsomstraldi Yes, standalone works much better.14:33
maciejjozefczykjohnsom, Hello. Going back to the topic here: https://storyboard.openstack.org/#!/story/2006196.  What do you mean by 'planned persistent driver code interface'?14:34
*** gcheresh_ has joined #openstack-lbaas14:35
dulekjohnsom: Yeah, we get some fuzzy behaviors as it happened we have 3 devs and each one tests with Queens, Rocky or Stein. :D14:35
johnsommaciejjozefczyk So the current provider driver design is for transient use. There is no mechanism to spawn a long running thread. The plan was to add a "long running" plugin option for the Driver Agent. Your same driver code would hook both the current provider driver, but also a longer running hook in driver agent.14:35
johnsomdulek Worst case, you should get 400 back if you pick a combination that doesn't work, but this should be called out.14:38
dulekjohnsom: Hm, right, it was 400.14:39
maciejjozefczykjohnsom, Thanks. Do you have an open story for this?14:41
johnsomdulek The offending patch is here: https://review.opendev.org/#/c/475944/14:41
straldiI tried just now to put exactly the conf I found in neutron.conf for keystone_auth (keeping the correct username and password) I restart all octavia services but I have the same problem. The strange thing is that in octavia log (DEBUG) say Client-side error: Validation failure: Missing project ID in request where one is required.14:42
*** dalvarez has joined #openstack-lbaas14:42
straldiSo seems the project is mandatory, ahh I can create the loadbalancer using --project but I wold like to create the loadbalancer also without that aptional argument14:44
johnsomstraldi No, the project ID by default comes from your keystone credentials. Only if that is not available or if the admin overrides is the --project used. Then, if that is also not specified, it will error that we could not find user credentials.14:45
dulekjohnsom: Uhm… That patch is from 2017 and seems to be included even in Pike?14:46
straldii source my keystone_demo14:47
straldiunset OS_SERVICE_TOKEN14:47
straldiexport OS_USERNAME=demo14:47
straldiexport OS_PASSWORD='8c735bb4554444b7'14:47
straldiexport PS1='[\u@\h \W(keystone_demo)]\$ '14:47
straldiexport OS_AUTH_URL=http://192.168.60.171:5000/v314:47
straldi14:47
straldiexport OS_PROJECT_NAME=demo14:47
straldiexport OS_USER_DOMAIN_NAME=Default14:47
straldiexport OS_PROJECT_DOMAIN_NAME=Default14:47
straldiexport OS_IDENTITY_API_VERSION=314:47
straldiI have export OS_PROJECT_NAME=demo14:47
johnsomdulek Yeah, see that. It isn't the right one. I need to find Zhao's14:48
johnsomstraldi Do you have "OS_AUTH_TYPE=password" configured?14:49
straldiyes for sure14:49
johnsomstraldi Also, there are no other keystone errors in your API log?14:49
johnsomstraldi Would you be ok sharing your octavia.conf in a paste.openstack.org?  You can mark it private and send me the link directly if you would like.14:51
straldihere we are http://paste.openstack.org/show/754300/14:57
straldino need to be private. All ip is in my private subnet and all data is not secret14:58
johnsomdulek Blah, I think the changes to enable TLS on backends auto-magically changed that behavior. When the backend is TLS enabled, it auto-magically escalates the health monitor to a full HTTPS check. Still looking at Zhao's patches.14:58
johnsomstraldi Ok cool, give me a few minutes to look it over.14:58
*** gcheresh_ has quit IRC14:58
straldithanks very much14:58
dulekjohnsom: You see there's one thing you cannot do in a portable way now.15:00
*** yamamoto has quit IRC15:00
dulekjohnsom: Before this one I wasn't able to set url_path for HTTPS: https://review.opendev.org/#/c/604924/15:00
dulekjohnsom: And after this patch I can.15:00
*** yamamoto has joined #openstack-lbaas15:01
*** yamamoto has quit IRC15:01
johnsomdulek Yeah, I don't think either of the people involved in that work are online now15:01
dulek:)15:02
dulekOkay, fair enough. Thank you for help anyway!15:02
*** Vorrtex has joined #openstack-lbaas15:02
johnsomI can poke into it more (busy morning), but it might be worth opening a story if there is a change you would like to see.15:02
dulekI don't really see a useful change here. Rocky deployments with this issue are out there, I need to support them.15:05
dulekI can only figure out which API version = Rocky and work it around.15:05
johnsomdulek Rocky didn't have backend TLS, so all it can do is simple TLS checks15:05
johnsomURL path isn't valid on HTTPS on Rocky15:05
johnsomstraldi Are you using keystone v3 API?  Can you paste the output of "openstack endpoint list"?15:06
straldiyes I am15:07
johnsomstraldi Also, can you check that you have an "octavia" account?  You are using packstack right? They may be using the service account and not setting up an octavia account.15:07
maciejjozefczykjohnsom, Is there any open story this for 'long running' plugin option? Spec? Or just an idea?15:07
johnsommaciejjozefczyk I think there is a story or two. I just haven't had time to go dig for it yet. It might be mentioned in the provider driver specs.15:08
maciejjozefczykjohnsom, Ok, I'll try to find15:09
straldi johnsom here all your question: http://paste.openstack.org/show/754302/15:09
straldiNo I use packstack for nova, neutron, keystone, glance, cinder ... simply with this command packstack --install-hosts 192.168.60.171,192.168.60.94 but for octavia I install everything by hand15:11
*** pcaruana has quit IRC15:11
straldifollowing almost this docs: https://blog.zufardhiyaulhaq.com/manual-instalation-octavia-openstack-queens/ so create the user, the security group, the image amphora, flavor, ...15:14
dalvarezmaciejjozefczyk: johnsom sorry i may have lost something, so instantiating a driver per API call is by design and expected right?15:16
johnsomstraldi Since you are using keystone v3, let's try this. Remove the auth_uri line, then change the auth_url line to "auth_url=http://192.168.60.171:5000/v3"15:16
straldiok I'm tryng15:17
johnsomdalvarez Yes, it was a choice we made during the design phase.15:17
johnsomdalvarez It helps protect against poorly written drivers that leak resources. They are transient by design. It also is supposed to allow dynamic updates of the drivers, but I think I saw a report that stevedore isn't doing that as was expected.15:18
dalvarezjohnsom: got it, i guess there's good reasons for that but in ovn, it's causing us to instantiate new connection to OVSDB, getting a full dump of the db contents and process it, etc.15:18
dalvarezstevedore is apparently creating a new fresh instance every time but im not sure is that what's expected or a bug15:18
johnsomdalvarez Yeah, that sounds like a design issue on ovn. It sounds like  it's leaking resources there.15:19
johnsomdalvarez Yes, that is what it is supposed to be doing. It's just the "pick up new code" part that might not be working.15:19
dalvarezjohnsom: it's not really leaking anything, i mean, it's a new instance of the driver and it just connects to the db on startup15:20
straldiNow I have:15:20
straldi[keystone_authtoken]15:20
straldiwww_authenticate_uri=http://192.168.60.171:5000/15:20
straldiauth_url=http://192.168.60.171:5000/v315:20
straldiI remove auth_uri15:20
straldibut the same problem15:20
dalvarezjohnsom: how is that leaking?15:20
johnsomdalvarez So we can look at what you need and figure out a way to either fix the ovn side or switch over to using the driver agent (yet to be implemented)15:20
straldiI put also in  section [service_auth] the v315:20
johnsomdalvarez I thought the story said it was leaking connections to the ovsdb15:20
johnsomstraldi Can you remove the "www_authenticate_uri" too? Not sure what that is needed for.15:21
straldiyes15:21
dalvarezjohnsom: maciejjozefczyk what i read in the story is "From OVN perspective it is not optimal because it creates a connection to OVS dbs each time"15:21
johnsomdalvarez I'm in four conversations and listening to a meeting right now, so very time sliced here.15:22
dalvarezjohnsom: ack :) let's do it when you have the time to read the story15:22
straldisame problem15:23
dalvarezjohnsom: let's sync tomorrow when maciejjozefczyk or via the story as you suggested15:23
johnsomdalvarez Yeah, I would really like to capture the discussion in the story as then the folks offline now can also contribute.15:24
dalvarez++15:25
johnsomstraldi Also, I saw a commented line "# auth_strategy = noauth" That should not be noauth, but commented out should be the correct default of "keystone".15:25
johnsomstraldi Line 298 can be removed, event_stream_transport_url is not needed anymore. (this isn't the project ID problem though)15:27
straldiok I'm trying15:27
straldiok15:27
johnsomstraldi You do have a project named "services" right? Usually it's "service"15:28
johnsomThat would be the other change to keystone_auth I would check15:29
straldiyesss you find the misconfiguration.15:30
straldiauth_strategy = keystone solve15:30
straldithanks a lot15:30
straldiI commented also event_stream_transport_url15:30
straldithanks a lot15:30
johnsomstraldi Ok, cool. Also, in the service_auth section, remove the URI and update the URL to the /v3 we did for keystone_auth15:30
straldiI did15:31
johnsom+115:31
johnsomCool. Glad you are up and running15:31
straldiok now I will play a little bit with octavia and I will let you know the feeling. Thanks a lot15:32
ivvejohnsom: is there any workaround for PortNotUsableDNS_Remote atm ?15:32
johnsomivve I don't know what that is. Can you provide context? Octavia doesn't use DN15:33
johnsomDNS15:33
ivvethe error comes from nova-api when recreating amphorae15:34
ivveyou pasted it a few years ago in a meeting, its the only hit i can find :)15:34
ivveException during message handling: PortNotUsableDNS: Port ad8ae71d-4517-419b-8937-50737253416a not usable for instance 47eec7dc-13c0-4bed-9736-f4803fcc52fd. Value amphora-2a9a4ca9-5c88-415b-b874-8bb67ec28d78 assigned to dns_name attribute does not match instance's hostname amphora-e8b4dee6-65e4-4489-8742-bb8e5835d9be15:34
johnsomHmm, ok. We worked around that bug in neutron a long time ago. Is it back?15:35
ivveyea15:35
ivvewell this version is15:35
ivverocky15:35
johnsomYeah, it was newton where we worked around it if I remember. Whenever designate integrated with neutron and caused this.15:36
johnsommugsie Are you around?15:36
mugsieKinda15:37
ivvestill not tested latest stein in lab15:37
johnsomivve Here is our workaround code: https://github.com/openstack/octavia/blob/master/octavia/network/drivers/neutron/allowed_address_pairs.py#L55315:37
ivve(neutron)15:37
ivvechecking15:37
johnsommugsie So people are seeing PortNotUsableDNS errors again. I thought you all fixed that to not be a failure.15:38
johnsomHere is the full error if you don't have the scrollback:15:38
johnsomException during message handling: PortNotUsableDNS: Port ad8ae71d-4517-419b-8937-50737253416a not usable for instance 47eec7dc-13c0-4bed-9736-f4803fcc52fd. Value amphora-2a9a4ca9-5c88-415b-b874-8bb67ec28d78 assigned to dns_name attribute does not match instance's hostname amphora-e8b4dee6-65e4-4489-8742-bb8e5835d9be15:38
mugsieI thought it was fixed15:39
mugsieMust be a regression in neutron again15:40
johnsomI'm looking to see if our extension discovery code is also contributing.15:40
johnsomivve Can you check a few things for me?  If you do a "openstack extension list" do you see dns-integration in the list?15:41
ivveDNS Integration                                                                                                                         | dns-integration                 | Provides integration with DNS.15:42
johnsomivve Also, can you look in your octavia worker logs for the following message:15:43
johnsomJul 08 07:35:48 devstack octavia-worker[13140]: DEBUG octavia.network.drivers.neutron.base [None req-048a157e-7be7-476f-8ef7-9398f6bb5343 None None] Neutron extension dns-integration is not enabled {{(pid=13875) _check_extension_enabled /opt/stack/octavia/octavia/network/drivers/neutron/base.py:70}}15:43
ivvejust gonna enable debug, one sec15:43
*** maciejjozefczyk has quit IRC15:47
ivvenopes15:47
ivvejohnsom: doesn't seem to pop up15:48
colin-can i set a timeout for pending_create somehow?15:48
colin-there must be an upper bound i can enforce so that i don't have to change them in the db when they don't create15:48
colin-instead of 409 indefinitely15:48
johnsomivve Hmmm, What triggered the failover that caused the ERROR? manual failover or health manager? if manual which type loadbalancer or amphora?15:48
ivve2019-07-11 15:45:48.858 20 DEBUG octavia.network.drivers.neutron.base [-] Neutron extension dns-integration found enabled _check_extension_enabled /var/lib/kolla/venv/local/lib/python2.7/site-packages/octavia/network/drivers/neutron/base.py:6615:49
johnsomcolin- Yes! one minute, I will find it for you. The default is horribly long15:49
ivvejohnsom: manual failover via api (cli: openstack loadbalancer failover <uuid>15:49
ivve)15:50
johnsomcolin- [haproxy_amphora] connection_max_retries = 120 and [haproxy_amphora] build_active_retries = 120 are typical settings to shorten that timeout15:51
ivveit managed to rebuild one of my loadbalancers15:54
johnsomivve Sigh, somehow the workaround we put in place is no longer in our failover flow..... This task: FailoverPreparationForAmphora is missing.15:55
ivvebut the other 3 are getting this failure15:55
johnsomivve So this is a regression bug.15:55
ivveokay, so thats good atleast. found what is causing it15:55
ivveit worked for 1 out of 4 LBs15:55
ivvefor some reason unknown to me15:55
johnsomivve Can you open a story for us? https://storyboard.openstack.org/#!/dashboard/stories15:56
*** pcaruana has joined #openstack-lbaas15:57
ivvealmost done16:03
*** Vorrtex has quit IRC16:03
johnsomThank you16:03
ivvehttps://storyboard.openstack.org/#!/story/200620516:03
ivveshould i add some other vital info?16:04
*** mithilarun has joined #openstack-lbaas16:04
*** altlogbot_1 has joined #openstack-lbaas16:04
johnsomivee That is good enough. I have also added comments that will help whoever fixes this bug.16:06
ivveperfect16:06
colin-do those values elapsing without successful connection cause the LB state to go from PENDING_CREATE to something mutable?16:07
johnsomcolin- Yes16:07
colin-weird, ok, mine are stuck in PENDING_CREATE. this was true in rocky?16:07
*** altlogbot_1 has quit IRC16:07
colin-(2-3 days old at this point, still PENDING_CREATE)16:08
openstackgerritMichael Johnson proposed openstack/octavia master: Add warning log if auth_strategy is not keystone  https://review.opendev.org/67034216:09
johnsomcolin- It has been that way since mitaka-ish. If it's been more than an hour, and you didn't change those settings from the default, it likely means someone did a non-graceful shutdown of the controller while it was working on creating that LB.16:10
johnsomcolin- This is the work Ann is working on, the jobboard support, that will resolve that.16:11
colin-ok, the services have been up for several days and the retries/interval config i'm running should have reached its natural conclusion after two hours. will try to find something in the log data about why it wouldn't have transitioned out of PENDING_CREATE16:13
colin-get super uncomfortable changing this stuff in the db heh16:13
openstackgerritMichael Johnson proposed openstack/octavia master: Add warning log if auth_strategy is not keystone  https://review.opendev.org/67034216:15
*** luksky11 has quit IRC16:19
*** rpittau is now known as rpittau|adk16:20
*** rpittau|adk is now known as rpittau|afk16:20
*** ivve has quit IRC16:23
*** Vorrtex has joined #openstack-lbaas16:27
colin-was a value on my side that was responsible johnsom, did bad math on retries x timeout16:35
johnsomcolin- ok16:35
colin-had an arbitrarily high value on one16:35
johnsomYeah, they can get large....16:36
*** tesseract has quit IRC16:36
*** altlogbot_3 has joined #openstack-lbaas16:44
openstackgerritCarlos Goncalves proposed openstack/octavia master: Add active-standby scenario jobs to check queue  https://review.opendev.org/67035416:49
*** altlogbot_3 has quit IRC16:49
openstackgerritCarlos Goncalves proposed openstack/octavia master: Add active-standby scenario jobs to check queue  https://review.opendev.org/67035416:51
*** psachin has quit IRC16:52
*** yamamoto has joined #openstack-lbaas17:04
*** yamamoto has quit IRC17:10
*** ataraday_ has quit IRC17:12
*** altlogbot_3 has joined #openstack-lbaas17:22
*** altlogbot_3 has quit IRC17:25
*** gcheresh_ has joined #openstack-lbaas17:28
*** altlogbot_2 has joined #openstack-lbaas17:30
*** altlogbot_2 has quit IRC17:35
*** altlogbot_0 has joined #openstack-lbaas17:36
*** gcheresh_ has quit IRC17:40
*** altlogbot_0 has quit IRC17:41
*** altlogbot_0 has joined #openstack-lbaas17:43
*** altlogbot_0 has quit IRC17:45
*** ajay33 has quit IRC18:10
*** luksky11 has joined #openstack-lbaas18:44
*** mithilarun has quit IRC18:52
*** irclogbot_2 has joined #openstack-lbaas19:28
*** irclogbot_2 has quit IRC19:33
*** altlogbot_3 has joined #openstack-lbaas19:39
*** altlogbot_3 has quit IRC19:41
*** mithilarun has joined #openstack-lbaas19:42
*** irclogbot_0 has joined #openstack-lbaas20:12
*** gcheresh_ has joined #openstack-lbaas20:13
*** irclogbot_0 has quit IRC20:16
*** pcaruana has quit IRC20:31
*** Vorrtex has quit IRC20:44
*** mithilarun has quit IRC20:56
*** gcheresh_ has quit IRC20:57
*** altlogbot_1 has joined #openstack-lbaas21:00
*** altlogbot_1 has quit IRC21:05
*** mithilarun has joined #openstack-lbaas21:22
*** irclogbot_1 has joined #openstack-lbaas21:23
*** irclogbot_1 has quit IRC21:26
*** irclogbot_2 has joined #openstack-lbaas21:29
colin-if i have an amp that's stuck in a BOOTING state and delete the underlying nova resource before it's assigned to any pool or lb, will octavia housekeeping just purge the record and life carries on with no subsequent action (create/destroy)?21:31
*** irclogbot_2 has quit IRC21:32
johnsomIt won't get purged, no. but all that will be there is the "BOOTING" record21:32
colin-so i would couple the nova delete with a database edit for each amp to DELETED in order to clean that up completely21:33
johnsomYeah, I think so.21:33
johnsomAny idea how it got that way? Another non-graceful shutdown?21:33
colin-does the BOOTING state respect the same values we were discussing earlier? i think i'm still within the timeframe and am unsure why they aren't marked active yet21:34
colin-the worker isn't obsessing about them in the output or anything21:34
johnsomYes, I think it's a similar timeout. It is the state while we wait on nova to start the amp21:34
*** boden has quit IRC21:57
*** mithilarun has quit IRC22:00
*** mithilarun has joined #openstack-lbaas22:02
*** altlogbot_0 has joined #openstack-lbaas22:19
*** irclogbot_3 has joined #openstack-lbaas22:19
*** mithilarun has quit IRC22:21
*** altlogbot_0 has quit IRC22:23
*** irclogbot_3 has quit IRC22:24
*** mithilarun has joined #openstack-lbaas22:36
*** luksky11 has quit IRC22:37
*** mithilarun has quit IRC22:37
*** mithilarun has joined #openstack-lbaas22:49
*** tkajinam has joined #openstack-lbaas22:52
*** altlogbot_1 has joined #openstack-lbaas22:57
*** altlogbot_1 has quit IRC22:59
*** irclogbot_3 has joined #openstack-lbaas23:01
*** irclogbot_3 has quit IRC23:06
*** yamamoto has joined #openstack-lbaas23:07
*** irclogbot_1 has joined #openstack-lbaas23:09
*** yamamoto has quit IRC23:12
*** rcernin has joined #openstack-lbaas23:13
*** irclogbot_1 has quit IRC23:16
*** goldyfruit has quit IRC23:16
*** altlogbot_2 has joined #openstack-lbaas23:29
*** altlogbot_2 has quit IRC23:29
openstackgerritMichael Johnson proposed openstack/octavia master: Make amphora use a single HAProxy instance  https://review.opendev.org/66806823:48
*** goldyfruit has joined #openstack-lbaas23:50

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!