| johnsom | No need to duplicate. The rebind is optional, you can take it out and make the param on the task name match. | 00:12 |
|---|---|---|
| ptoohill | I added the one piece i need (though i need to do more) to the create_lb flow even and getting errors. ill check this in | 00:14 |
| ptoohill | The example can be found in the create_load_balancer flow, this isnt exactly what i want to do, but it shows error and negates your sample | 00:15 |
| ptoohill | https://review.openstack.org/#/c/199954/ | 00:15 |
| ptoohill | so i cant have another flow then is what it comes down to | 00:15 |
| ptoohill | unless its after the decider, and at that point its too late for me to inject stuff from a 'pre' flow | 00:16 |
| johnsom | Here is one without rebind: https://gist.github.com/johnsom/5ac6a9bd7d814743eab7 | 00:16 |
| ptoohill | The point where it breaks in my example is line 52 of load_balancer_flows | 00:16 |
| ptoohill | i get the rebind stuff, i was just poking at it, because it wouldnt solve what i need, though you made it sound like it would | 00:17 |
| johnsom | Ah, ok, so note, that flow is unordered. That means you task may not run before the others in the flow. | 00:18 |
| ptoohill | yea, so theres no way to reuse this stuff | 00:18 |
| ptoohill | this was yet just another example to show what error it gives | 00:18 |
| johnsom | Well, I would put that line is the flow before get_create_load_balancer_flow | 00:18 |
| ptoohill | ive tried to do it many ways | 00:19 |
| ptoohill | tried that | 00:19 |
| ptoohill | same error | 00:19 |
| johnsom | The unordered flow allows the active and standby to boot in parallel | 00:19 |
| ptoohill | graph flow doesnt like what im trying to do | 00:19 |
| ptoohill | its not the unordered flow | 00:19 |
| ptoohill | the data is there | 00:19 |
| johnsom | Ok, let me check this out and take a look at the bigger picture. | 00:20 |
| ptoohill | NotFound: Mapped argument 'network_ids' <= 'network_ids' was not produced by any accessible provider (2 possible providers were scanned) | 00:20 |
| johnsom | What line #? | 00:20 |
| ptoohill | doesnt give a line number, this is stack from rpc_errors | 00:20 |
| ptoohill | the closes related thing is from the controller_worker call | 00:20 |
| ptoohill | it doesnt even compile | 00:20 |
| johnsom | Ah, ok, give me a minute to have a look | 00:21 |
| ptoohill | File "/opt/stack/octavia/octavia/controller/queue/endpoint.py", line 45, in create_load_balancer | 00:21 |
| ptoohill | │------------+ │2015-12-13 18:12:39.106 22594 ERROR oslo_messaging.rpc.dispatcher self.worker.create_load_balancer(load_balancer_id) | 00:21 |
| ptoohill | File "/opt/stack/octavia/octavia/controller/worker/controller_worker.py", line 273, in create_load_balancer | 00:21 |
| ptoohill | │ | │2015-12-13 18:12:39.106 22594 ERROR oslo_messaging.rpc.dispatcher create_lb_tf.run() | 00:21 |
| ptoohill | Then a bunch of rpc stuff, then that network_ids message | 00:22 |
| johnsom | Ok, I'm not sure you can use defaults on task parameters. I haven't seen it and that might through the flow compile off. Second we need to add you flow in an outer linear flow to make sure it runs. Finally, I would double check that both of those tasks are returning something and not blowing the storage away. | 00:35 |
| johnsom | I'm running py27 now to see if I can get your error. Then I will code up a new get_create_load_balancer_flow in gist that should help. | 00:35 |
| ptoohill | That error is coming from graph flow code | 00:36 |
| ptoohill | The example i linkked was just quick to expose the error. Ive tried putting them in seperate flows, adding them to linear flows etc | 00:36 |
| ptoohill | i appreciate you taking time on this for me | 00:36 |
| johnsom | Not a problem, we are all a team | 00:37 |
| ptoohill | :) | 00:37 |
| ptoohill | my objective is to allow flows the ability to determine networking | 00:38 |
| ptoohill | in master, right now, some of the networking is decided outside, but the mgmt net and a few other checks are handled inside the create_amp task. I need to avoid that so we can reuse networks | 00:38 |
| ptoohill | and, i also need a different networking subflow, so my objective to to reuse the create_loadbalancer flow (because thatll work as is) but add things before and after | 00:39 |
| ptoohill | the failover flow is similar, except you attach the networks, not supply them while creating | 00:40 |
| ptoohill | or atleast the old stuff that i remembered | 00:40 |
| johnsom | Yeah, I made some semi-major changes to the failover flow as I have been adding active/standby | 00:41 |
| johnsom | Ok, take a look at this: https://gist.github.com/johnsom/b6cb5e1b630d2ccba9a9 | 00:41 |
| johnsom | That "should" let it compile | 00:41 |
| ptoohill | interesting | 00:41 |
| ptoohill | ill add that in | 00:42 |
| johnsom | Obviously it's hack-y code, but it should test the idea | 00:42 |
| ptoohill | Im not sure how to make it less hacky :/ | 00:43 |
| johnsom | well, constants and such. | 00:43 |
| ptoohill | gotcha | 00:43 |
| ptoohill | testing now | 00:44 |
| johnsom | fingers crossed | 00:44 |
| ptoohill | oh dear, reached quota -.- | 00:44 |
| johnsom | Ugh, yes, I hate that. I have been hitting that on my failover testing. Security groups | 00:45 |
| ptoohill | :P | 00:45 |
| johnsom | have been my headache | 00:45 |
| johnsom | I finally went in neutron.conf, jacked the numbers, and restarted neutron. | 00:45 |
| ptoohill | Ok, this seems to be working. and does help clear up misunderstanding regarding providers | 00:46 |
| johnsom | I've got two bugs in failover that have been giving me headaches. I'll get them hammered out this week. | 00:46 |
| ptoohill | the docs wasnt really giving a lot of hints about providers that the error was mentioning | 00:46 |
| ptoohill | so i went down the path of attempting to link it in the graph, but as long as its one big flow and not multiple flows patched itll work | 00:47 |
| johnsom | Ok, cool. Yeah, the unordered flow means all of those sub-flows and tasks, at that level, run in parallel, so the provides wasn't running in time for the other flows | 00:47 |
| ptoohill | well i was doing it outside of the unordered also, this is still a graphflow issue, but is resolved by one big flow | 00:47 |
| johnsom | Yeah, the docs and samples are horrible! I have aspirations to help them with that. | 00:48 |
| ptoohill | :) | 00:48 |
| ptoohill | Thanks again, sorry for being a pain | 00:48 |
| *** chlong has joined #openstack-lbaas | 00:48 | |
| johnsom | NP. I hope that gets you going again. If not ping me tomorrow. | 00:49 |
| ptoohill | I think this will work for me all the way, i just need to make sure i do similar to what you did with the outer flow | 00:49 |
| johnsom | I need to go put lights on the tree and crack open a brew | 00:49 |
| ptoohill | hope this will work with the 'post' things i need, well see | 00:49 |
| ptoohill | That sounds good | 00:49 |
| ptoohill | enjoy! :) | 00:50 |
| johnsom | Good luck! | 00:50 |
| *** rsanchez87 has quit IRC | 01:20 | |
| *** ljxiash has joined #openstack-lbaas | 01:24 | |
| *** mixos has joined #openstack-lbaas | 01:28 | |
| *** rsanchez87 has joined #openstack-lbaas | 01:37 | |
| *** ianbrown has quit IRC | 02:07 | |
| *** ianbrown has joined #openstack-lbaas | 02:08 | |
| *** bochi-michael has joined #openstack-lbaas | 02:17 | |
| rsanchez87 | Hi All, I realize it's not possible to use LBAAS (HAProxy) for multiple protocols on the same VIP, but how does one handle HTTP redirection to HTTPS for example? | 02:43 |
| *** ianbrown has quit IRC | 03:02 | |
| *** ianbrown has joined #openstack-lbaas | 03:02 | |
| *** manishg has joined #openstack-lbaas | 03:19 | |
| *** ljxiash has quit IRC | 03:25 | |
| *** ianbrown has quit IRC | 03:25 | |
| *** ianbrown has joined #openstack-lbaas | 03:25 | |
| *** ianbrown has quit IRC | 03:36 | |
| *** ianbrown has joined #openstack-lbaas | 03:36 | |
| *** ianbrown has quit IRC | 03:41 | |
| *** ianbrown has joined #openstack-lbaas | 03:41 | |
| *** manishg has quit IRC | 03:49 | |
| *** yamamoto has joined #openstack-lbaas | 03:55 | |
| *** prabampm has joined #openstack-lbaas | 04:43 | |
| *** ig0r_ has quit IRC | 04:50 | |
| *** ig0r_ has joined #openstack-lbaas | 04:55 | |
| *** ianbrown has quit IRC | 05:17 | |
| *** ianbrown has joined #openstack-lbaas | 05:17 | |
| *** mixos has quit IRC | 05:56 | |
| *** gomarivera has quit IRC | 06:04 | |
| *** bochi-michael has quit IRC | 06:06 | |
| *** yuanying has joined #openstack-lbaas | 06:11 | |
| *** ig0r_ has quit IRC | 06:12 | |
| *** numans has joined #openstack-lbaas | 06:15 | |
| *** kobis has joined #openstack-lbaas | 06:28 | |
| *** amotoki has joined #openstack-lbaas | 06:31 | |
| *** rsanchez87 has quit IRC | 06:48 | |
| *** rcernin has joined #openstack-lbaas | 07:02 | |
| *** bochi-michael has joined #openstack-lbaas | 07:03 | |
| *** openstackgerrit has joined #openstack-lbaas | 07:10 | |
| *** kobis has quit IRC | 07:12 | |
| *** nmagnezi has joined #openstack-lbaas | 07:13 | |
| *** bana_k has joined #openstack-lbaas | 07:18 | |
| openstackgerrit | Stephen Balukoff proposed openstack/octavia: Shared pools support https://review.openstack.org/256369 | 07:30 |
| *** eezhova has quit IRC | 07:36 | |
| *** chlong has quit IRC | 07:46 | |
| *** kobis has joined #openstack-lbaas | 08:03 | |
| openstackgerrit | Brandon Logan proposed openstack/neutron-lbaas: WIP - Get Me A LB https://review.openstack.org/257201 | 08:05 |
| sbalukoff | "Get Me A LB"? | 08:36 |
| *** kobis has quit IRC | 08:38 | |
| rm_work | :P | 08:38 |
| rm_work | nice blogan, lol | 08:38 |
| rm_work | good naming | 08:38 |
| rm_work | sbalukoff: I assume that's the single-call LB Create | 08:40 |
| rm_work | AKA "Get me a LB" | 08:40 |
| sbalukoff | That's what I'm guessing, too. But, I went ahead and put a -1 on it anyway. | 08:40 |
| rm_work | good call :P | 08:40 |
| sbalukoff | Haha | 08:40 |
| sbalukoff | Also, I'm starting to feel good about the Octavia shared pools patch. Third patchset is up there now. As far as I know, all I have yet to do is to add tests for new / altered functionality, and tell y'all you're stupid when you point out things I'm doing wrong. :) | 08:41 |
| sbalukoff | I should have patch set 4 with those new tests by EOD tomorrow. | 08:42 |
| sbalukoff | And since then there will be only two days until I'm gone on vacation, I intend to spend that time reviewing others' work. | 08:42 |
| rm_work | yeah I'm technically off until next year <_< | 08:44 |
| sbalukoff | Haha! | 08:44 |
| rm_work | but prolly going to try to finish up what I'm working on and do some reviews this week anyway | 08:44 |
| sbalukoff | You're a glutton for punishment. | 08:44 |
| rm_work | i didn't want to take my vacation all right now but if i don't take it i lose it <_< bleh | 08:45 |
| sbalukoff | Yeah, I know. | 08:49 |
| sbalukoff | :P | 08:49 |
| *** eranra has joined #openstack-lbaas | 08:50 | |
| sbalukoff | Hey Eran! | 08:50 |
| sbalukoff | How's it going? | 08:50 |
| * rm_work sleeps | 08:51 | |
| sbalukoff | Yep, I'mma go sleep as well. Have a good day, rm_work and eranra! | 08:51 |
| sbalukoff | (Er... night, as the case may be.) | 08:51 |
| openstackgerrit | Phillip Toohill proposed openstack/octavia: Updates for containers functionality https://review.openstack.org/199954 | 08:53 |
| *** bana_k has quit IRC | 09:00 | |
| openstackgerrit | Bo Chi proposed openstack/neutron-lbaas: Change status to INACTIVE if admin_state_up if false https://review.openstack.org/255875 | 09:04 |
| *** rm_you has joined #openstack-lbaas | 09:17 | |
| *** bochi-michael has quit IRC | 09:21 | |
| *** bochi-michael has joined #openstack-lbaas | 09:27 | |
| *** admin0 has joined #openstack-lbaas | 09:30 | |
| *** amotoki has quit IRC | 09:31 | |
| *** ig0r_ has joined #openstack-lbaas | 09:39 | |
| *** bharathm has quit IRC | 09:53 | |
| *** bharathm has joined #openstack-lbaas | 09:54 | |
| *** bharathm has quit IRC | 10:10 | |
| *** rcernin has quit IRC | 10:25 | |
| *** admin0 has quit IRC | 11:37 | |
| *** chlong has joined #openstack-lbaas | 11:39 | |
| *** kobis has joined #openstack-lbaas | 12:04 | |
| *** admin0 has joined #openstack-lbaas | 12:07 | |
| *** doug-fish has joined #openstack-lbaas | 12:23 | |
| *** rtheis has joined #openstack-lbaas | 12:30 | |
| *** doug-fish has quit IRC | 12:34 | |
| *** doug-fish has joined #openstack-lbaas | 12:39 | |
| *** barclaac has quit IRC | 12:43 | |
| *** ducttape_ has joined #openstack-lbaas | 12:44 | |
| *** barclaac has joined #openstack-lbaas | 12:49 | |
| *** ducttape_ has quit IRC | 13:00 | |
| *** bharathm has joined #openstack-lbaas | 13:11 | |
| *** bharathm has quit IRC | 13:15 | |
| *** numans has quit IRC | 14:11 | |
| *** admin0 has quit IRC | 14:16 | |
| *** eranra_ has joined #openstack-lbaas | 14:18 | |
| *** ajmiller has joined #openstack-lbaas | 14:19 | |
| *** eranra has quit IRC | 14:21 | |
| *** eranra_ has quit IRC | 14:22 | |
| *** neelashah has joined #openstack-lbaas | 14:23 | |
| *** yamamoto has quit IRC | 14:26 | |
| *** neelashah1 has joined #openstack-lbaas | 14:30 | |
| *** neelashah has quit IRC | 14:30 | |
| *** TrevorV|Home has joined #openstack-lbaas | 14:38 | |
| *** ducttape_ has joined #openstack-lbaas | 14:55 | |
| *** ajmiller has quit IRC | 14:56 | |
| *** ig0r_ has quit IRC | 15:04 | |
| *** ljxiash has joined #openstack-lbaas | 15:07 | |
| *** TrevorV|Home has quit IRC | 15:09 | |
| *** yamamoto has joined #openstack-lbaas | 15:15 | |
| *** nmagnezi has quit IRC | 15:22 | |
| *** eranra has joined #openstack-lbaas | 15:22 | |
| *** eranra_ has joined #openstack-lbaas | 15:28 | |
| *** ljxiash has quit IRC | 15:30 | |
| *** eranra has quit IRC | 15:32 | |
| *** eranra_ has quit IRC | 15:41 | |
| *** admin0 has joined #openstack-lbaas | 15:43 | |
| *** manishg has joined #openstack-lbaas | 15:47 | |
| *** manishg has quit IRC | 15:53 | |
| *** yamamoto has quit IRC | 15:56 | |
| *** yamamoto has joined #openstack-lbaas | 15:58 | |
| *** admin0 has quit IRC | 16:19 | |
| *** sbalukoff has quit IRC | 16:25 | |
| *** rsanchez87 has joined #openstack-lbaas | 16:41 | |
| *** rsanchez87 has quit IRC | 16:45 | |
| *** armax has joined #openstack-lbaas | 16:47 | |
| *** rsanchez87 has joined #openstack-lbaas | 16:48 | |
| *** manishg has joined #openstack-lbaas | 16:49 | |
| *** yamamoto has quit IRC | 16:59 | |
| *** jonesbr has joined #openstack-lbaas | 17:13 | |
| *** madhu_ak has joined #openstack-lbaas | 17:17 | |
| *** madhu_ak has quit IRC | 17:22 | |
| *** ducttape_ has quit IRC | 17:24 | |
| *** yamamoto has joined #openstack-lbaas | 17:28 | |
| *** bochi-michael has quit IRC | 17:34 | |
| *** doug-fish has quit IRC | 17:35 | |
| *** doug-fish has joined #openstack-lbaas | 17:35 | |
| *** doug-fish has quit IRC | 17:40 | |
| *** yamamoto has quit IRC | 17:46 | |
| *** manishg has quit IRC | 17:56 | |
| *** manishg has joined #openstack-lbaas | 17:56 | |
| *** kobis has quit IRC | 18:04 | |
| *** Aish has joined #openstack-lbaas | 18:07 | |
| blogan | anyone notice our massive job failures over the weekend and continuing to today? | 18:09 |
| blogan | http://docs-draft.openstack.org/44/255944/1/check/gate-neutron-lbaas-docs/dca3405//doc/build/html/dashboards/check.dashboard.html | 18:09 |
| johnsom | Nope | 18:10 |
| blogan | might be related to the grenade gate failure | 18:12 |
| johnsom | Yeah, I was just going to say that. | 18:13 |
| rm_work | bleh | 18:15 |
| rm_work | someone have it handled or should I look into it? | 18:15 |
| johnsom | The gernade issue with oslo.middleware is fixed. Not sure if that is related or not | 18:16 |
| rm_work | k | 18:16 |
| blogan | i thought it was just devstack settings | 18:16 |
| blogan | accoring to the ML at least | 18:16 |
| blogan | coudl be a different grenade job | 18:16 |
| johnsom | Yeah, could be we are thinking about two different issues | 18:17 |
| *** kobis has joined #openstack-lbaas | 18:17 | |
| *** kobis has quit IRC | 18:18 | |
| rm_work | anyone have the magic string to hide things with -W in the search filter for gerrit? | 18:19 |
| rm_work | so I can add it to project:openstack/octavia status:open | 18:19 |
| rm_work | in my bookmark | 18:20 |
| *** Aish has quit IRC | 18:20 | |
| rm_work | got it | 18:22 |
| rm_work | "project:openstack/octavia status:open -label:Workflow-1" | 18:22 |
| johnsom | neat | 18:23 |
| *** bana_k has joined #openstack-lbaas | 18:23 | |
| *** Aish has joined #openstack-lbaas | 18:24 | |
| blogan | could be all the WIP patches we've pushed up too, the minimal job had spike but has come back down, and that gets run a lot more than any other job | 18:25 |
| rm_work | so possibly legit failures? :P | 18:27 |
| johnsom | FYI I fixed up that api doc update. I didn't see the experimental tag blogan mentioned. At least in the rendered doc I saw it was stable | 18:27 |
| *** neelashah1 has quit IRC | 18:27 | |
| blogan | johnsom: might have been in thte table of contents then | 18:29 |
| blogan | one sec | 18:29 |
| blogan | i must be crazy | 18:29 |
| blogan | guess i shouldn't do all those drugs on the weekedn | 18:30 |
| blogan | could have sworn i saw it | 18:30 |
| blogan | oh well, i feel better | 18:30 |
| johnsom | grin | 18:30 |
| *** ig0r_ has joined #openstack-lbaas | 18:39 | |
| *** bharathm has joined #openstack-lbaas | 18:42 | |
| ptoohill | anyone having issues building lb today? im noticing some funky behavior and wanted to see if i was alone or not | 18:42 |
| * ptoohill is all alone | 18:49 | |
| rm_work | i'm still getting keystone errors trying to do TLS stuff <_< | 18:50 |
| rm_work | before it even gets close to Barbican | 18:50 |
| ptoohill | maybe i can help with that, these other issues im seeing like not being able to connect to instance on master and building configs on the instance in my patch | 18:51 |
| *** doug-fish has joined #openstack-lbaas | 18:55 | |
| ptoohill | Octavia is Oprah | 18:57 |
| johnsom | We are giving away cars now? | 18:58 |
| ptoohill | s/cars/bugs | 18:58 |
| *** madhu_ak has joined #openstack-lbaas | 18:59 | |
| ptoohill | Though this is probably just another thing affecting just me some how, but that doesnt explain issues in master | 19:00 |
| *** doug-fish has quit IRC | 19:00 | |
| *** doug-fish has joined #openstack-lbaas | 19:01 | |
| *** doug-fis_ has joined #openstack-lbaas | 19:03 | |
| *** doug-fis_ has quit IRC | 19:04 | |
| *** doug-fis_ has joined #openstack-lbaas | 19:04 | |
| *** doug-fish has quit IRC | 19:05 | |
| *** sbalukoff has joined #openstack-lbaas | 19:15 | |
| *** woodster_ has joined #openstack-lbaas | 19:26 | |
| *** bharathm has quit IRC | 19:31 | |
| openstackgerrit | Merged openstack/octavia: Updated from global requirements https://review.openstack.org/256496 | 19:37 |
| *** albertom has quit IRC | 19:45 | |
| *** ajmiller has joined #openstack-lbaas | 19:49 | |
| *** albertom has joined #openstack-lbaas | 19:52 | |
| *** Aish has quit IRC | 20:05 | |
| *** whydidyoustealmy has quit IRC | 20:07 | |
| *** shakamunyi has quit IRC | 20:07 | |
| *** bharathm has joined #openstack-lbaas | 20:22 | |
| *** madhu_ak has quit IRC | 20:28 | |
| *** jonesbr has quit IRC | 20:29 | |
| *** jonesbr has joined #openstack-lbaas | 20:32 | |
| *** neelashah has joined #openstack-lbaas | 20:32 | |
| *** ducttape_ has joined #openstack-lbaas | 20:38 | |
| *** harlowja has quit IRC | 21:04 | |
| *** madhu_ak has joined #openstack-lbaas | 21:05 | |
| *** Aish has joined #openstack-lbaas | 21:06 | |
| *** neelashah has quit IRC | 21:06 | |
| *** harlowja has joined #openstack-lbaas | 21:07 | |
| *** harlowja_ has joined #openstack-lbaas | 21:11 | |
| *** harlowja has quit IRC | 21:13 | |
| *** Aish has quit IRC | 21:18 | |
| openstackgerrit | Merged openstack/neutron-lbaas: Updated from global requirements https://review.openstack.org/256493 | 21:22 |
| *** ducttape_ has quit IRC | 21:39 | |
| *** manishg_ has joined #openstack-lbaas | 21:41 | |
| *** manishg__ has joined #openstack-lbaas | 21:42 | |
| *** manishg has quit IRC | 21:42 | |
| *** manishg__ has quit IRC | 21:43 | |
| *** manishg has joined #openstack-lbaas | 21:44 | |
| *** manishg_ has quit IRC | 21:45 | |
| *** chlong has quit IRC | 21:51 | |
| *** Aish has joined #openstack-lbaas | 22:11 | |
| blogan | yeah i can't even ping the amphorae anymore, something fishy is going on | 22:23 |
| *** crc32 has joined #openstack-lbaas | 22:27 | |
| *** ducttape_ has joined #openstack-lbaas | 22:27 | |
| *** crc32 has quit IRC | 22:28 | |
| *** crc32 has joined #openstack-lbaas | 22:29 | |
| *** jonesbr has left #openstack-lbaas | 22:31 | |
| johnsom | Joy. Thanks for the warning to not restack | 22:34 |
| blogan | lol | 22:36 |
| blogan | well its just got to be me bc the scenario jobs are running and passing, as far as i've seen | 22:39 |
| ptoohill | im having other issues with connection in the back in and some unexpected behavior | 22:45 |
| ptoohill | backend* | 22:46 |
| *** rtheis has quit IRC | 22:46 | |
| blogan | well i can't even ping a cirros image.... | 22:48 |
| blogan | bleh | 22:48 |
| ptoohill | lol | 22:49 |
| *** ducttape_ has quit IRC | 22:49 | |
| johnsom | My issue is after I failover an amp, I can't delete the load balancer. "security group is in use" | 22:51 |
| madhu_ak | I have seen the same issue "security group is in use" when running lbaas api tests ( using haproxy), but I normally clear db manually and run the tests, it passed for me. (Well, recollecting the experiences when I write lbaas api tests) .. | 22:55 |
| johnsom | Yeah, I think it's due the fact we now have "DELETED" status amps hanging around. | 22:56 |
| johnsom | I just need to track it down. | 22:56 |
| blogan | johnsom: we only have those in our db right? | 22:57 |
| blogan | johnsom: i see what you mean, they actually didn't get deleted in nova | 22:58 |
| blogan | johnsom: yeah that would be a problem, also when a nova instance is deleted, even after its gone from the list, it seems its take some unknown time for the security group to actually be released | 22:58 |
| blogan | johnsom: which is why there's a security group delete retry | 22:58 |
| blogan | might try upping that | 22:59 |
| blogan | anyway, figured my problem out, network namespaces are not being created | 22:59 |
| johnsom | This is a bug. There is still a port with the security group on it. | 22:59 |
| blogan | ahhh | 23:00 |
| blogan | what port? | 23:00 |
| blogan | the vip port or a port on an instance? | 23:00 |
| johnsom | It's one of the two vip neutron ports | 23:01 |
| blogan | there should only be one vip port per load balancer | 23:01 |
| openstackgerrit | Carlos Garza proposed openstack/octavia: Implementing EventStreamer https://review.openstack.org/218735 | 23:01 |
| openstackgerrit | Carlos Garza proposed openstack/neutron-lbaas: Implementing EventStreamer reciever for octavia https://review.openstack.org/241474 | 23:01 |
| johnsom | I have one port "94" that has the allowed address pairs on it with "93", then I also have a port with just the "93" address on it | 23:03 |
| johnsom | neutron port-list | 23:03 |
| johnsom | "94" port has owner compute:none, "93" port is owner neutron:LOADBALANCERV2 | 23:04 |
| blogan | yeah the 93 is the vip port | 23:04 |
| blogan | 94 is the instance port | 23:04 |
| blogan | 93 should have an actual name | 23:05 |
| blogan | but both of those still exist? | 23:05 |
| *** chlong has joined #openstack-lbaas | 23:05 | |
| blogan | after a failover? | 23:05 |
| blogan | wait, actually, don't you just want to transfer those ports over to a new amphora instead of deleting them? | 23:05 |
| rm_work | soooo | 23:06 |
| johnsom | yes, "93" has a name, "94" does not. Somehow "94" still has the sec group on it | 23:06 |
| rm_work | does neutron-lbaas ACTUALLY read the file /etc/neutron/neutron_lbaas.conf | 23:06 |
| rm_work | seems like the answer is "no"? | 23:06 |
| johnsom | Yeah, the scenario is create lb, failover lb, then delete lb | 23:07 |
| johnsom | delete lb fails | 23:07 |
| rm_work | what is that file even *for* | 23:07 |
| blogan | rm_work: it should | 23:07 |
| blogan | rm_work: if you want to do lbaas specific things | 23:07 |
| johnsom | rm_work the service providers are in there | 23:07 |
| johnsom | i.e. Octavia driver | 23:08 |
| rm_work | well, i basically had to copy all the config over from that to neutron.conf to get it to actually be set | 23:08 |
| blogan | rm_work: all about hwo you start neutron-server, i pass in neutron_lbaas.conf | 23:08 |
| rm_work | ah so devstack does --config-file /etc/neutron/neutron.conf | 23:08 |
| blogan | rm_work: or you could have done neutrnon-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/neutron_lbaas.conf | 23:08 |
| rm_work | by default, devstack does not include neutron_lbaas.conf on the commandline args for neutron-server | 23:08 |
| blogan | rm_work: yeah, which neutron used to automatically pull in neutron_lbaas.conf without specifying it, but now it doesn't | 23:08 |
| rm_work | loool | 23:09 |
| rm_work | ok then our devstack plugin is borked | 23:09 |
| johnsom | blogan when did that change? | 23:09 |
| blogan | johnsom: i don't remember | 23:10 |
| blogan | johnsom: just found it out one day while testing the allocates_vip setting in neutron_lbaas | 23:10 |
| blogan | wondering why it wasn't being picked up | 23:10 |
| rm_work | lol | 23:10 |
| rm_work | so that cost me 3 days | 23:10 |
| blogan | it took you 3 days to decide to ask? | 23:11 |
| johnsom | Hmm, ok. I don't have to hack things to get devstack going. I guess we have octavia as the default in config.py | 23:11 |
| rm_work | blogan: it took until I was pretty positive it wasn't being loaded to ask, yes | 23:11 |
| blogan | no devstack runs fine right now without being specified, its just if you want to change something from default thats in neutron_lbaas.conf | 23:11 |
| rm_work | "the config file for our project isn't being read" isn't something that comes to mind by default | 23:11 |
| rm_work | it's one of those *base assumptions* | 23:11 |
| rm_work | rofl | 23:12 |
| rm_work | "just if you want to change something from default" | 23:12 |
| rm_work | IE, if you want to actually set a value | 23:12 |
| blogan | well i mean normally if you have two config files, you have to specify both, it reading the neutron_lbaas.conf magically was the exception | 23:12 |
| johnsom | hahaha | 23:12 |
| johnsom | We make perfect choices for default, so, yeah it was redundant... hahaha | 23:12 |
| rm_work | sooooo devstack happily updates the neutron_lbaas.conf file with the config necessary to run | 23:12 |
| rm_work | IE, using a non-default password or IP | 23:13 |
| rm_work | and then it just sits there and doesn't get read | 23:13 |
| rm_work | so nothing works right because it just uses defaults :P | 23:13 |
| blogan | it works right for defaults :) | 23:13 |
| rm_work | >_< | 23:13 |
| rm_work | that isn't even close to being *actually working* | 23:13 |
| johnsom | Any color as long is it's black... | 23:14 |
| rm_work | You can have any color you want, as long as it's blakc | 23:14 |
| rm_work | LOL | 23:14 |
| rm_work | yes johnsom thanks | 23:14 |
| rm_work | so i'm not insane | 23:14 |
| blogan | works for black | 23:14 |
| blogan | ! | 23:14 |
| rm_work | >_< | 23:14 |
| blogan | i'm not saying its not a problem, just haven't had the time to go fix it myself, haven't really needed to, just got devstack running and then restarted the neutron-server with teh right command | 23:15 |
| blogan | thought i put in a bug for it though, but apparently not | 23:17 |
| *** doug-fis_ has quit IRC | 23:18 | |
| *** doug-fish has joined #openstack-lbaas | 23:18 | |
| blogan | https://bugs.launchpad.net/neutron/+bug/1526096 | 23:19 |
| openstack | Launchpad bug 1526096 in neutron "lbaas devstack plugin should start neutron-server with neutron_lbaas.conf" [Undecided,New] | 23:19 |
| blogan | there we go | 23:19 |
| *** doug-fis_ has joined #openstack-lbaas | 23:20 | |
| *** doug-fis_ has quit IRC | 23:21 | |
| blogan | my devstack problem is solved | 23:22 |
| johnsom | blogan, since the security group gets applied to both of those ports, I think we have an issue. When the first port is deallocate_vip'd it's going to fail to delete the security group because the second port still has it | 23:22 |
| *** doug-fis_ has joined #openstack-lbaas | 23:22 | |
| *** sbalukoff has quit IRC | 23:22 | |
| *** doug-fish has quit IRC | 23:23 | |
| blogan | johnsom: what are the steps before deallocate_vip is executed? | 23:24 |
| johnsom | UnplugVIP, DeleteAmphoraeOnLoadBalancer, and MarkLBAmphoraeDeletedInDB | 23:26 |
| *** ducttape_ has joined #openstack-lbaas | 23:26 | |
| blogan | johnsom: so you're getting totally new ips on the new amp from the failed one no? | 23:27 |
| blogan | totally new ports | 23:27 |
| johnsom | Not these IPs they are moving | 23:28 |
| johnsom | Oh, ports, let me look | 23:28 |
| johnsom | Nope, it looks like they just get moved. Same ids on the two ports. | 23:29 |
| blogan | the reason i ask is because if all you do is transfer the ports (except the mgmt port) then you don't need to unplug vip | 23:29 |
| johnsom | I think the only thing that changes is the management port | 23:29 |
| johnsom | the failure I am looking at is when the user deletes the lb | 23:30 |
| *** ducttape_ has quit IRC | 23:30 | |
| johnsom | Not during failover | 23:30 |
| blogan | ohhhh | 23:30 |
| blogan | sorry | 23:30 |
| johnsom | Np, it's confusing | 23:30 |
| blogan | so is this always an lb with a failover that happened? | 23:30 |
| johnsom | It seems to be that way. I might be wrong though. Just tracking it down | 23:31 |
| johnsom | Normally I can delete lbs, but that doesn't mean whatever I broke didn't break that too | 23:32 |
| blogan | well then, delete amphorae on load balancer should just delete all the load balancers, and remove the ports on that amphorae | 23:32 |
| blogan | unless, the failover disassociated those ports from the amphora | 23:32 |
| crc32 | https://review.openstack.org/#/c/241474/ <-- needs review | 23:32 |
| blogan | do those ports have a device_id? | 23:32 |
| crc32 | https://review.openstack.org/#/c/218735/ <-- needs more review | 23:32 |
| crc32 | Feel free to rubber stamp a +2 | 23:33 |
| johnsom | blogan yes, before failover they both have the same device ID. After failover it is a different ID at least on one | 23:34 |
| blogan | johnsom: okay i think a good test would be to see if a port that is transferred from one instance to another is deleted when that new instance is deleted | 23:35 |
| johnsom | At the point in deallocate_vip where it bombs, 93 still has a device_id, 94 does not | 23:35 |
| blogan | bc that seems like what is happened | 23:35 |
| blogan | 94 is device_owner:compute? | 23:35 |
| * blogan reads scrollback | 23:35 | |
| blogan | ah yeah that might be the problem | 23:35 |
| blogan | 94 is the instance port | 23:35 |
| johnsom | 94 is compute:None, it does not go away when the instance is deleted via nova | 23:36 |
| blogan | so either the device_id doens't get updated to the new amphora's id on failover, or the device_id is being cleared out at some point | 23:36 |
| johnsom | Cool, thanks for helping to track this down! I will check that. | 23:36 |
| blogan | johnsom: try this, create another instance with that port, see if device_id gets populated, if it doesn't update that port's device_id with the amphora_id and then delete | 23:37 |
| blogan | the instance | 23:37 |
| blogan | hell i can probably test this out myself real quick | 23:37 |
| blogan | bc im curious now | 23:38 |
| blogan | and i now have a working devstack | 23:38 |
| johnsom | I'm going to reset, run again and check that device_id after failover | 23:38 |
| *** doug-fis_ has quit IRC | 23:43 | |
| johnsom | Ok, that is strange. Just created an lb. The two ports have two different device ids here. About to fail over and see what happens | 23:45 |
| blogan | johnsom: the vip port will have the lb id | 23:46 |
| blogan | johnsom: bc its only for the lb, the instance port was created by nova, so it'll have the instance id | 23:46 |
| johnsom | the compute:none port has the same device_id as the mgmt port | 23:47 |
| blogan | johnsom: yep, that makes sense, they're both on the same amphora | 23:47 |
| blogan | johnsom: yeah found the problem | 23:49 |
| blogan | johnsom: so when you transfer the port, and booth the instance with that port, that port's device_id will get populated with the new amphora's id BUT | 23:49 |
| blogan | johnsom: when that new amphora is deleted nova only clears out the device_id and device_owner, it doesn't delete the port | 23:50 |
| blogan | johnsom: i assume its because nova has no way to know if that port was originally created by nova or some other service/user | 23:50 |
| blogan | so we need to explicitly delete that port from neutron | 23:50 |
| johnsom | Ok. I will make it so. | 23:52 |
| blogan | johnsom: i'm thinking of how we will do that in the network driver, which i'm not sure we can, the proper place would be deallocate_vip i think | 23:52 |
| blogan | and that does get a vip object, so you'd have to go vip.loadbalancer.amphorae i guess, that should give you all the port_ids | 23:53 |
| blogan | wish there was a way to tell nova to also delete this port when that instance is deleted, but i guess thats all underneath | 23:56 |
| johnsom | Ok, I follow you. Yeah. Can't hurt to delete it explicitly though (with a try block). | 23:57 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!