*** bharath has quit IRC | 00:15 | |
*** haigang has joined #openstack-lbaas | 00:56 | |
*** haigang has quit IRC | 01:18 | |
*** ctracey has quit IRC | 01:20 | |
*** ctracey has joined #openstack-lbaas | 01:22 | |
*** haigang has joined #openstack-lbaas | 01:38 | |
*** haigang has quit IRC | 01:40 | |
*** haigang has joined #openstack-lbaas | 01:41 | |
*** haigang has quit IRC | 01:49 | |
*** haigang has joined #openstack-lbaas | 01:53 | |
*** BrianShang_ has joined #openstack-lbaas | 02:25 | |
*** BrianShang has quit IRC | 02:28 | |
*** haigang has quit IRC | 02:56 | |
*** haigang has joined #openstack-lbaas | 02:57 | |
*** woodster_ has joined #openstack-lbaas | 03:05 | |
*** sbalukoff has quit IRC | 05:38 | |
*** kiran-r has joined #openstack-lbaas | 06:03 | |
*** haigang has quit IRC | 06:21 | |
*** woodster_ has quit IRC | 06:40 | |
*** Santosh_ has joined #openstack-lbaas | 06:51 | |
Santosh_ | Hi All | 06:53 |
---|---|---|
Santosh_ | There are couple admin test cases which are failing if there is validation in backend driver . https://review.openstack.org/#/c/177657 | 06:56 |
Santosh_ | Admin test cases with empty tenant id are passing with logging noop driver (as there is no validation) But these tests are faling with validation in backend driver(NetScaler) . Driver response is bad-request but it is propagated as "internal driver error " to plugin layer | 06:58 |
*** sbalukoff has joined #openstack-lbaas | 07:05 | |
*** kobis has joined #openstack-lbaas | 07:06 | |
*** BrianShang_ has quit IRC | 07:33 | |
*** BrianShang has joined #openstack-lbaas | 07:35 | |
*** rm_work has quit IRC | 07:59 | |
*** rm_work|away has joined #openstack-lbaas | 07:59 | |
*** rm_work|away is now known as rm_work | 07:59 | |
*** rm_work has joined #openstack-lbaas | 07:59 | |
*** apuimedo_ has joined #openstack-lbaas | 08:05 | |
*** openstackgerrit has quit IRC | 08:13 | |
*** openstackgerrit has joined #openstack-lbaas | 08:17 | |
*** apuimedo_ has quit IRC | 08:49 | |
*** apuimedo_ has joined #openstack-lbaas | 08:58 | |
*** apuimedo has quit IRC | 09:39 | |
*** apuimedo has joined #openstack-lbaas | 09:44 | |
*** apuimedo_ has quit IRC | 10:22 | |
*** apuimedo_ has joined #openstack-lbaas | 10:23 | |
*** john-davidge has joined #openstack-lbaas | 11:10 | |
*** woodster_ has joined #openstack-lbaas | 12:01 | |
*** openstackgerrit has quit IRC | 12:06 | |
*** openstackgerrit has joined #openstack-lbaas | 12:06 | |
*** jschwarz has joined #openstack-lbaas | 12:29 | |
*** openstackgerrit has quit IRC | 12:37 | |
*** openstackgerrit has joined #openstack-lbaas | 12:37 | |
*** openstackgerrit has quit IRC | 13:21 | |
*** openstackgerrit has joined #openstack-lbaas | 13:22 | |
*** mestery_ is now known as mestery | 13:32 | |
*** apuimedo_ has quit IRC | 13:50 | |
*** BrianShang has quit IRC | 14:10 | |
*** BrianShang has joined #openstack-lbaas | 14:12 | |
*** BrianShang has quit IRC | 14:20 | |
*** BrianShang has joined #openstack-lbaas | 14:21 | |
*** BrianShang has quit IRC | 14:26 | |
*** BrianShang has joined #openstack-lbaas | 14:32 | |
*** BrianShang has quit IRC | 14:36 | |
*** BrianShang has joined #openstack-lbaas | 14:38 | |
*** BrianShang has quit IRC | 14:42 | |
*** TrevorV_ has joined #openstack-lbaas | 14:43 | |
*** BrianShang has joined #openstack-lbaas | 14:43 | |
*** BrianShang has quit IRC | 14:47 | |
*** BrianShang has joined #openstack-lbaas | 15:07 | |
*** BrianShang has quit IRC | 15:11 | |
*** kbyrne has quit IRC | 15:12 | |
*** kbyrne has joined #openstack-lbaas | 15:16 | |
*** jorgem has joined #openstack-lbaas | 15:17 | |
*** sbalukoff has quit IRC | 15:24 | |
*** sballe has quit IRC | 15:28 | |
openstackgerrit | Trevor Vardeman proposed stackforge/octavia: Amphora SSH Driver https://review.openstack.org/160964 | 15:30 |
*** BrianShang has joined #openstack-lbaas | 15:31 | |
TrevorV | dougwig if I sent you gist of a sphinx error when building docs, do you think I could steal some of your time today to help me fix it? or is there a better source? | 15:51 |
*** BrianShang has quit IRC | 15:51 | |
*** BrianShang has joined #openstack-lbaas | 15:53 | |
*** kobis has quit IRC | 15:55 | |
*** mlavalle has joined #openstack-lbaas | 15:55 | |
*** BrianShang has quit IRC | 15:56 | |
*** BrianShang has joined #openstack-lbaas | 15:57 | |
*** jorgem1 has joined #openstack-lbaas | 15:59 | |
*** jorgem1 has quit IRC | 16:00 | |
*** BrianShang has quit IRC | 16:01 | |
*** jorgem has quit IRC | 16:01 | |
*** BrianShang has joined #openstack-lbaas | 16:03 | |
*** BrianShang has quit IRC | 16:08 | |
*** BrianShang has joined #openstack-lbaas | 16:10 | |
*** BrianShang has quit IRC | 16:13 | |
*** BrianShang has joined #openstack-lbaas | 16:15 | |
*** BrianShang has quit IRC | 16:19 | |
*** BrianShang has joined #openstack-lbaas | 16:21 | |
*** amotoki_ has joined #openstack-lbaas | 16:21 | |
*** amotoki has quit IRC | 16:21 | |
*** amotoki_ is now known as amotoki | 16:21 | |
*** madhu_ak has joined #openstack-lbaas | 16:24 | |
*** mwang2 has quit IRC | 16:26 | |
*** BrianShang has quit IRC | 16:33 | |
*** BrianShang has joined #openstack-lbaas | 16:35 | |
*** BrianShang has quit IRC | 16:39 | |
*** BrianShang has joined #openstack-lbaas | 16:41 | |
*** BrianShang has quit IRC | 16:49 | |
*** TrevorV_ has quit IRC | 16:49 | |
*** BrianShang has joined #openstack-lbaas | 16:53 | |
*** BrianShang has quit IRC | 16:56 | |
*** BrianShang has joined #openstack-lbaas | 16:58 | |
dougwig | TrevorV: i'm far from a sphinx master, but I'll look. maybe pastebin it here? | 17:00 |
*** logan2 has quit IRC | 17:05 | |
*** BrianShang has quit IRC | 17:05 | |
*** BrianShang has joined #openstack-lbaas | 17:07 | |
*** BrianShang has quit IRC | 17:13 | |
*** BrianShang has joined #openstack-lbaas | 17:14 | |
*** jorgem has joined #openstack-lbaas | 17:16 | |
*** kiran-r has quit IRC | 17:19 | |
*** BrianShang has quit IRC | 17:20 | |
*** jorgem has quit IRC | 17:20 | |
*** jschwarz has quit IRC | 17:21 | |
*** BrianShang has joined #openstack-lbaas | 17:21 | |
*** barclaac has joined #openstack-lbaas | 17:22 | |
barclaac | Good morning folks! | 17:24 |
barclaac | blogan: I saw you replies to a thread talking about needing Barbican for LBaaS. Here's the question: If I didn't need TLS support could I run LBaaS v2 without Barbican? | 17:24 |
rm_work | barclaac: yes, in theory, though I am not sure there is a simple way in code to "turn off TLS support" right now? | 17:25 |
rm_work | There might be, I am just not sure since I have been away for a while | 17:25 |
barclaac | I'm working on an internal roadmap and I'm trying to figure out if I can do the LBaaS in isolation. | 17:26 |
rm_work | yeah I would imagine it would be possible | 17:26 |
barclaac | I guess I'll just have to get some of the folks on the team here to test it. | 17:26 |
johnsom | I am pretty sure it requires some code enhancements to disable TLS | 17:27 |
rm_work | johnsom: well, theoretically, it should be possible to have TLS enabled for some backends and not for others? meaning it should be up to the backend plugin whether TLS is supported or not? | 17:29 |
rm_work | and in that case, does the driver do any validation on the data before things go async? | 17:29 |
rm_work | or could the user put in a "create LB" request including TLS, have it return a 200 or whatever, then have the driver throw the exception for "not implemented" on TLS afterwards, causing it to ERROR? | 17:30 |
johnsom | Right, I'm pretty sure he is asking about the ref driver | 17:30 |
barclaac | correct - ref driver only. | 17:30 |
rm_work | hmm, ok -- did ptoohill's changes to the ref driver to support TLS make it in? | 17:30 |
rm_work | I assume they did by now | 17:30 |
rm_work | really, I think the answer is to add the fields necessary to support the LocalCertStore option | 17:31 |
rm_work | so we can have TLS without barbican actually be an option | 17:31 |
rm_work | for dev/test deployments | 17:32 |
ptoohill | The TLS stuff did make it in | 17:32 |
rm_work | k | 17:32 |
barclaac | I think local cert store would work. | 17:32 |
ptoohill | Thats a big change to the data model and other parts | 17:32 |
rm_work | barclaac: right now the API does not take in raw cert/key data from the user | 17:32 |
rm_work | barclaac: so while the code for the local store "works", there's no way for Neutron to get anything from the user to store in it | 17:33 |
rm_work | the API *only* takes a "certificate_id" right now | 17:33 |
rm_work | which... if the user actually had access to the local store in order to put a cert/key there, would work | 17:33 |
rm_work | so it's possible to workaround it by putting the stuff there manually and passing in an ID that you set | 17:34 |
rm_work | which may be good enough to get you started | 17:34 |
ptoohill | But, if they don't need TLS at all, couldnt they just update to 'use' the local manager and not have to worry about barbican? | 17:34 |
rm_work | ptoohill: true, but what happens when the user passes in TLS data? | 17:35 |
ptoohill | It only takes an id, so unless its an id it will fail validation | 17:35 |
rm_work | do we have it set up to validate that they don't populate TLS fields? | 17:35 |
rm_work | ah | 17:35 |
rm_work | hmm interesting | 17:35 |
ptoohill | and if they do pass id's it would fail in the backend | 17:35 |
rm_work | alright | 17:35 |
rm_work | so I guess it's fine | 17:35 |
rm_work | it's just... <_< | 17:36 |
ptoohill | yea | 17:36 |
rm_work | not sure the errors that come back will be helpful to the user | 17:36 |
rm_work | but it should be fine | 17:36 |
ptoohill | I do take that back though, there no UUID validation because its actually a 256 char string :P | 17:36 |
rm_work | heh | 17:36 |
rm_work | but i think it tries to validate the cert from the storage mechanism on the initial call? | 17:37 |
rm_work | is that part sync? | 17:37 |
rm_work | or async? | 17:37 |
ptoohill | it validates up front | 17:37 |
ptoohill | so it would fail early | 17:37 |
barclaac | That would work for me. I could easily release note that TLS cert IDs will be accepted but just plain won't work. | 17:37 |
rm_work | because no ID that's passed in will be a valid cert_id, since the repository will be empty | 17:37 |
ptoohill | yep | 17:37 |
rm_work | barclaac: yeah that should be fine | 17:38 |
ptoohill | that would probably be the 'simplest' solution at this point if youre ok with it | 17:38 |
barclaac | OK. I'll get ony of my folks to verify but this sounds very workable for me | 17:38 |
Santosh_ | Hi All [12:26] <Santosh_> There are couple admin test cases which are failing if there is validation in backend driver . https://review.openstack.org/#/c/177657 [12:28] <Santosh_> Admin test cases with empty tenant id are passing with logging noop driver (as there is no validation) But these tests are faling with validation in backend driver(NetScaler) . Driver response is bad-request but it is propagated as "internal dr | 17:40 |
madhu_ak | Santhosh_ : I saw your patch, will add my comments on that. As a neutron admin, I am curious to know, can't he do anything he wants because he knows what to do and expect? | 17:44 |
madhu_ak | Santosh_ ^^ | 17:45 |
*** amotoki has quit IRC | 17:47 | |
*** bharath has joined #openstack-lbaas | 17:47 | |
*** fnaval has joined #openstack-lbaas | 17:48 | |
*** BrianShang has quit IRC | 17:48 | |
*** BrianShang has joined #openstack-lbaas | 17:50 | |
*** barclaac|2 has joined #openstack-lbaas | 17:50 | |
*** barclaac has quit IRC | 17:54 | |
Santosh_ | Test case looks invalid to me (as it is expecting create to be successful with empty tenant id). | 17:54 |
Santosh_ | Even though above tests will pass with logging noop as there is no validation by driver | 17:55 |
Santosh_ | "expecting create to be successful with empty tenant-id " is not correct | 17:58 |
*** kiran-r has joined #openstack-lbaas | 18:04 | |
john-davidge | blogan: ping | 18:06 |
*** sbalukoff has joined #openstack-lbaas | 18:08 | |
openstackgerrit | Michael Johnson proposed stackforge/octavia: Implements Octavia Controller Worker https://review.openstack.org/151496 | 18:10 |
*** xgerman has joined #openstack-lbaas | 18:13 | |
john-davidge | blogan: I have to drop, but if you see this please could you take another look at https://review.openstack.org/#/c/173005/ ? I think I've addressed your concern. Thanks | 18:16 |
openstackgerrit | min wang proposed stackforge/octavia: Fix Octavia complexity issues https://review.openstack.org/177035 | 18:20 |
rm_work | I think I don't hate @staticmethod as much as blogan does | 18:24 |
*** john-davidge has quit IRC | 18:24 | |
xgerman | I think nobody does :-) | 18:29 |
*** kiran-r has quit IRC | 18:29 | |
openstackgerrit | Aishwarya Thangappa proposed openstack/neutron-lbaas: Added admin/non_admin api tests https://review.openstack.org/173423 | 18:37 |
*** jorgem has joined #openstack-lbaas | 18:38 | |
blogan | @staticmethod should diaf | 18:44 |
blogan | but i can deal with it, but i don't think methods should be tagged as staticmethod just because they don't use self | 18:45 |
*** barclaac has joined #openstack-lbaas | 18:58 | |
rm_you | blogan: well, otherwise you're artificially restricting when the method can be run, for no reason | 18:58 |
rm_you | i have definitely had times where I was trying to do something and it was telling me "you must have an instance of <whatever>" for no good reason | 18:59 |
*** barclaac|2 has quit IRC | 19:01 | |
blogan | well why would you want to call a method that was meant to be a private instance method that happened to not use self? | 19:03 |
*** xgerman_ has joined #openstack-lbaas | 19:03 | |
blogan | from outside that class | 19:03 |
blogan | rm_you: and in that case, tagging it as a classmethod would solve your problem too | 19:04 |
blogan | johnsom: did you get my comment about having to retrieve the loadbalancer and amphora again in thsoe methods? | 19:08 |
rm_work | blogan: well, if it doesn't use self or cls, but is only intended to be used as a private instance method, someone has done some strange design | 19:11 |
rm_work | there's no real reason for something to BE a private instance method, unless it uses things from the instance <_< | 19:12 |
openstackgerrit | Anand Shanmugam proposed openstack/neutron-lbaas: Adding code to prevent vip port deletion from port api https://review.openstack.org/176016 | 19:12 |
*** xgerman_ has quit IRC | 19:13 | |
blogan | rm_work: you mean decomposing a large method into smaller digestable chunks even if those chunks don't use instance state is bad design? | 19:13 |
rm_work | in itself is not bad design, but expecting them to still be private instance methods is ???? | 19:14 |
rm_work | once you've done that, there's no point in them being restricted to either private or instance, really | 19:14 |
rm_work | other than having a clean namespace | 19:14 |
rm_work | people can run them all they want and it won't hurt your class -- now, keeping them "private" might be good to indicate that their functionality might change (and avoid introducing a contract) | 19:16 |
rm_work | but still zero reason for them to be instance restricted | 19:16 |
rm_work | all you'd be doing is forcing someone to make a fake/throwaway instance so they can call your function | 19:16 |
rm_work | which, again, I have done in the past | 19:17 |
rm_work | (while shaking my fist in the air at the original author) | 19:17 |
rm_work | just not a fan of being unnecessarily restrictive based on "one current view of the situation" | 19:18 |
blogan | i think if you're calling a private method from the outside you're doing it wrong | 19:22 |
blogan | or the class you're calling doesn't give you the public methods that you need | 19:23 |
rm_work | eh, sometimes there are situations when you need to do something the original developer didn't expect but don't want to patch their code directly | 19:39 |
rm_work | it happens | 19:39 |
blogan | monkey patch! | 19:40 |
johnsom | blogan Yes, I'm just not sure it matters in the flow. It's on my list to look at. The comment about the taskflow settings didn't make sense for me. Those are configurable items we set when starting up the tasklow engine. | 19:44 |
blogan | johnsom: yeah the taskflow settings i thought were taskflow defined, but you're right | 19:45 |
johnsom | Ok, cool | 19:45 |
blogan | johnsom: but it does matter in the flow because passing in the lb in the store, means lb.amphorae will always be an empty list, just like amphora.lb would always be None | 19:45 |
blogan | johnsom: so you do checks on if amphora.lb exists in the networkign tasks | 19:46 |
*** BrianShang_ has joined #openstack-lbaas | 19:46 | |
johnsom | Ah. Ok, I will look at that. I can create a task that refreshes those and rebind them into the flow | 19:46 |
blogan | johnsom: even though in the db that relationship exists, the amphora passed in has not been updated to reflect that | 19:46 |
*** BrianShang has quit IRC | 19:46 | |
johnsom | Right | 19:47 |
blogan | johnsom: okay that'd work, do you think there is a way to just do that in the task that updates them? so you don't always have to use that task over and over? | 19:47 |
*** crc32 has joined #openstack-lbaas | 19:48 | |
blogan | i guess with taskflow the proper way is to create a separate task to do that so it can revert | 19:48 |
johnsom | Yeah, probably. The only reason I would do another task is if I need to reuse it. | 19:48 |
blogan | yeah and im sure you will need to | 19:48 |
*** crc32 has quit IRC | 19:49 | |
blogan | johnsom: anyway im testing this with the actual drivers and actual neutron and nova | 19:49 |
johnsom | Me too | 19:49 |
johnsom | Fixing bugs as I go. | 19:50 |
blogan | yeah im trying to add comments as i find them, but learning taskflow int he process has slowed it down a bit | 19:50 |
blogan | that and i think i found a bug, write a huge comment only to find out that its not | 19:50 |
blogan | like the create lb without a READY amphora available, which you commented on | 19:51 |
johnsom | Tell me about it, the learning curve on a number of things has slowed it down. | 19:51 |
johnsom | I have everything down to pools working with a few workarounds (the amp IP issue, etc.) Members aren't being generated, so need to debug that. | 19:52 |
blogan | debugging taskflow is bit of a pita as well, but its just a change in mentality really | 19:53 |
johnsom | Good news is the pool is created now and updates correctly, so my basic taskflow premise seems to be working | 19:53 |
blogan | johnsom: yeah it looks like its working, but just gotta get around these bugs | 19:53 |
blogan | if this didn't have bugs i'd be worried something was wrong lol | 19:54 |
johnsom | With any luck I can get through the bugs today and create the rest of the objects. | 19:54 |
johnsom | FYI, we have a etherpad of known issues we are working on: https://etherpad.openstack.org/p/octavia_issues | 19:54 |
johnsom | Aish, Min, and German are helping out in parallel | 19:55 |
blogan | is #1 still an issue after your fix? | 19:55 |
johnsom | Al as well, but he is on vacation for a bit | 19:55 |
blogan | what a salcker | 19:55 |
johnsom | Yeah, I botched the fix | 19:55 |
blogan | and slacker | 19:55 |
blogan | well you're nto the first loo | 19:55 |
blogan | lol | 19:55 |
johnsom | The imported configs didn't have those settings even though I thought they did | 19:56 |
blogan | from keystonemiddleware? | 19:57 |
johnsom | Yep | 19:59 |
johnsom | One of us just needs to add those config settings independent of the imported configs. | 20:00 |
blogan | i honestly dont know why keystonemiddleware wouldn't register those options | 20:03 |
johnsom | Yeah, me either. I assume it's a matter of timing | 20:03 |
*** xgerman_ has joined #openstack-lbaas | 20:06 | |
*** barclaac has quit IRC | 20:13 | |
dougwig | is using lp for bugs something we don't want to do? | 20:13 |
dougwig | not arguing, serious question. | 20:13 |
johnsom | This isn't merged code, so not sure it's the right place. Really it was a place for me to put issues about the patchset so other folks on our team could help out. | 20:15 |
johnsom | Typically I think lp for bugs is a good thing | 20:17 |
dougwig | i'm cool either way. was just curious, thanks. | 20:20 |
* johnsom wondering if dougwig was talking on a different thread | 20:21 | |
dougwig | no, same thread. | 20:21 |
blogan | i was going to ask the same thing but i think with the enormous amounts of bug that anyone could find, it would all be noise, i was thinking bugs in lp would be put in place after teh demo | 20:22 |
xgerman_ | yep, lp for mered code/afterd emo | 20:36 |
xgerman_ | if it's for a patch jus put it in comments | 20:36 |
*** xgerman has quit IRC | 20:38 | |
*** mwang2 has joined #openstack-lbaas | 20:41 | |
*** crc32 has joined #openstack-lbaas | 20:43 | |
*** BrianShang_ has quit IRC | 20:52 | |
*** BrianShang has joined #openstack-lbaas | 20:53 | |
johnsom | Question on the jinja_cfg.py, line 36 has "ACTIVE_PENDING_STATUSES = constants.SUPPORTED_PROVISIONING_STATUSES +" but the check below for member is "member.operating_status in ACTIVE_PENDING_STATUSES" | 20:57 |
johnsom | Are we intentionally breaking the supported operating statuses here on purpose or are those mixed by accident? | 20:58 |
*** amotoki has joined #openstack-lbaas | 21:01 | |
*** BrianShang has quit IRC | 21:04 | |
*** BrianShang has joined #openstack-lbaas | 21:05 | |
*** BrianShang has quit IRC | 21:09 | |
*** BrianShang has joined #openstack-lbaas | 21:11 | |
*** BrianShang has quit IRC | 21:17 | |
*** BrianShang has joined #openstack-lbaas | 21:18 | |
*** BrianShang has quit IRC | 21:24 | |
*** barclaac has joined #openstack-lbaas | 21:24 | |
*** barclaac|2 has joined #openstack-lbaas | 21:25 | |
blogan | ptoohill: ^^ | 21:25 |
*** BrianShang has joined #openstack-lbaas | 21:25 | |
ptoohill | ? | 21:26 |
blogan | i woudln't think the operating status wouldn't be in the decision to render a member | 21:26 |
ptoohill | My comp is bugging and bouncing on/off irc. I dont see anything above the '^' | 21:26 |
blogan | just provisioning status | 21:26 |
blogan | 15:58:06 johnsom | Question on the jinja_cfg.py, line 36 has "ACTIVE_PENDING_STATUSES = constants.SUPPORTED_PROVISIONING_STATUSES +" but the check below for member is │ | 21:27 |
blogan | │ │ | "member.operating_status in ACTIVE_PENDING_STATUSES" │ | 21:27 |
blogan | │ │15:58:50 johnsom | Are we intentionally breaking the supported operating statuses here on purpose or are those mixed by accident? | 21:27 |
blogan | yikes | 21:27 |
blogan | weechat is not good at copying multiple lines | 21:27 |
johnsom | Question on the jinja_cfg.py, line 36 has "ACTIVE_PENDING_STATUSES = constants.SUPPORTED_PROVISIONING_STATUSES +" but the check below for member is "member.operating_status in ACTIVE_PENDING_STATUSES" | 21:27 |
johnsom | Are we intentionally breaking the supported operating statuses here on purpose or are those mixed by accident? | 21:27 |
*** barclaac has quit IRC | 21:28 | |
ptoohill | Not doing anything on purpose. This was basically pulled from what was in neutron-lbaas. Its quite possible this was something overlooked | 21:28 |
ptoohill | checking out code to jog memory | 21:29 |
johnsom | Cool, thanks | 21:29 |
*** BrianShang has quit IRC | 21:32 | |
ptoohill | This might have been leftover from something we needed in neutron-lbaas. though that may not be a thing anymore either and this coudl possibly change in both places. This checked shouldnt include 'DEGRADED' is what youre getting at here? | 21:32 |
*** BrianShang has joined #openstack-lbaas | 21:33 | |
ptoohill | I guess im not sure what the issue is with this as im kind of unclear with the statuses between neutron-lbaas/octavia. | 21:35 |
ptoohill | :/ | 21:35 |
johnsom | ptoohill Well, I wouldn't expect SUPPORTED_PROVISIONING_STATUSES in the operating_status | 21:35 |
ptoohill | Ok, then this may just be leftover that needed updating for octavia and was overlooked | 21:35 |
ptoohill | What should this be? | 21:35 |
ptoohill | oh | 21:36 |
blogan | member.provisioning_status? | 21:36 |
johnsom | We don't have provisioning_status on members | 21:36 |
ptoohill | im sorry, im doing things for v1 and having issues with comp and plumbers. today is fun day | 21:36 |
johnsom | Just operating_status | 21:37 |
blogan | lol good point | 21:37 |
blogan | well then i don't think we need that check at all then? why would operating status come into the decision of whether the member should be in the config? | 21:37 |
blogan | after the demo, we need to align the nlbaas and octavia apis as much as we can | 21:38 |
johnsom | I agree, the only thought I have is if we are using OFFLINE to exclude it from the config | 21:38 |
johnsom | blogan +1 | 21:38 |
johnsom | This stuff got me confused more than once.... | 21:38 |
blogan | i would think that check would be covered for enabled, because if it was haproxy that reported it being OFFLINE we'd still want it in the config | 21:39 |
*** BrianShang has quit IRC | 21:39 | |
johnsom | Right, I guess we have 'enabled' for excluding it. | 21:39 |
blogan | well its the result of neutron-lbaas's API changing a lot because Octavia's was done back when neutron-lbaas was much closer to this | 21:39 |
johnsom | So, yeah, maybe take the check for status out.... | 21:40 |
blogan | moving targets suck | 21:40 |
ptoohill | I can certainly do that. I apologize, a lot of this was 'cp', just hope I didnt miss much more >< | 21:40 |
dougwig | blogan: heh, you moved it. :) | 21:40 |
blogan | dougwig: i was trying to please everyone! | 21:40 |
*** BrianShang has joined #openstack-lbaas | 21:41 | |
blogan | ptoohill: we'll find whatever else has been missed | 21:41 |
blogan | but wouldn't hurt to comb over those jinja files for other things | 21:42 |
*** bharath has quit IRC | 21:42 | |
*** bharath has joined #openstack-lbaas | 21:42 | |
johnsom | I think montior.id is wrong in there too, but I have a problem where it's not finding the health_monitor on the pool so haven't hit it yet | 21:43 |
*** BrianShang has quit IRC | 21:46 | |
*** BrianShang has joined #openstack-lbaas | 21:48 | |
*** BrianShang has quit IRC | 21:55 | |
madhu_ak | Quick question: what is the use of admin_state_up field when creating loadbalancer? | 21:56 |
*** BrianShang has joined #openstack-lbaas | 21:57 | |
madhu_ak | If it is set to false, shouldn't the 'operating_status' set to DISABLED? | 22:01 |
*** BrianShang has quit IRC | 22:01 | |
madhu_ak | https://wiki.openstack.org/wiki/Neutron/LBaaS/API_2.0#Create_a_Load_Balancer <-- | 22:01 |
*** BrianShang has joined #openstack-lbaas | 22:03 | |
*** barclaac|2 has quit IRC | 22:05 | |
blogan | madhu_ak: yes it should | 22:06 |
madhu_ak | you meant, the operating_status should be disabled right? | 22:07 |
*** barclaac has joined #openstack-lbaas | 22:07 | |
madhu_ak | blogan ^^ | 22:08 |
blogan | madhu_ak: yes | 22:08 |
madhu_ak | so there is a bug then | 22:08 |
*** barclaac has quit IRC | 22:08 | |
*** BrianShang has quit IRC | 22:12 | |
madhu_ak | again provisioning status should be shown as OFFLINE when admin_state_up is set to False..Is that right? blogan | 22:13 |
*** BrianShang has joined #openstack-lbaas | 22:13 | |
ptoohill | youre asking about both provisioning and operating status madhu_ak ? | 22:17 |
madhu_ak | yes | 22:17 |
*** jorgem has quit IRC | 22:19 | |
*** BrianShang has quit IRC | 22:19 | |
ptoohill | I'm not quite positive to be honest. But i believe its just the operating status that will be set to offline. Im probably wrong about this as im still unclear/havnt dug in to fullly understand the statues | 22:23 |
ptoohill | madhu_ak: | 22:23 |
*** BrianShang has joined #openstack-lbaas | 22:23 | |
madhu_ak | yeah, IMO, it should be: operating_status=DISABLED and provisioning_status=OFFLINE when I set admin_state_up=False | 22:24 |
madhu_ak | ptoohill | 22:24 |
crc32 | madhu_ak: the operating status being set to DISABLED is only in the return of the statuses call. ITs not set in the database. | 22:25 |
crc32 | what behavior are you expecting? | 22:25 |
ptoohill | I think he wants to clear up that both operating status and provisioning status should have a status that is consistent with the admin_state_up=False. Though, what are you seeing now? | 22:27 |
*** amotoki has quit IRC | 22:27 | |
madhu_ak | https://gist.github.com/akmadhusudhan/e835204224c875be8a5c | 22:27 |
madhu_ak | this is the response I am seeing | 22:27 |
ptoohill | ah, then this may be a bug. crc32 did a lot with the status tree and could probably answer this better then me at this point | 22:28 |
*** BrianShang has quit IRC | 22:28 | |
crc32 | Just wondering but if you call statuses on the same loadbalancer what do you see? | 22:29 |
crc32 | I didn't mangle the return calls on any operations other then statuses. | 22:29 |
*** BrianShang has joined #openstack-lbaas | 22:30 | |
madhu_ak | yep, for the first time, I could see provisioning_status as pending update and then if I get it on the lb once again, I could it is showing as ONLINE | 22:30 |
madhu_ak | I just logged an issue, but feel free to edit the issue.. | 22:34 |
madhu_ak | https://bugs.launchpad.net/neutron/+bug/1449286 | 22:34 |
openstack | Launchpad bug 1449286 in neutron "lb's operating_status is not in DISABLED state when an user creates a loadbalancer with admin_state_up field as 'False'" [Undecided,New] | 22:34 |
crc32 | I was asking what you got when you hit statuses call. | 22:35 |
madhu_ak | okay let me check | 22:35 |
crc32 | the one that returns the entire tree | 22:36 |
madhu_ak | you meant, GET on: http://192.168.141.165:9696/v2.0/lbaas/loadbalancers/e1976562-b1f6-45cd-8e32-5b961f80fa24/ | 22:37 |
madhu_ak | ? | 22:37 |
*** BrianShang has quit IRC | 22:37 | |
crc32 | I'm building my deps now. There was supposed to be a call like /lbaas/loadbalancers/id/statuses or something like that. I'm looking through the docs for the actual call. | 22:38 |
crc32 | Looks like the doc has a bug in it as well. They show the call as "GET /lbaas/loadbalancers/loadbalancer_id/statuses " but then in the example the "statuses" portion of the URI is left off. | 22:39 |
madhu_ak | okay | 22:39 |
madhu_ak | I see what you are saying | 22:39 |
madhu_ak | https://gist.github.com/akmadhusudhan/d553621d8cb8293e5984 | 22:39 |
madhu_ak | when I do: GET http://192.168.141.165:9696/v2.0/lbaas/loadbalancers/e1976562-b1f6-45cd-8e32-5b961f80fa24/statuses | 22:40 |
madhu_ak | there it is showing correctly.. Is that we supposed to check in this way? | 22:41 |
madhu_ak | crc3 | 22:41 |
crc32 | "disabled" never hits the database. Its just dynamically returned in the status tree call. | 22:41 |
crc32 | but Im guessing it should be consistant as well. | 22:41 |
madhu_ak | aah, I see | 22:41 |
crc32 | I only worked on the dynamic tree part but I can see how its confusing. I'll ask brandon if we should modify the POST calls to reflect DISABLED as well. | 22:42 |
madhu_ak | yep crc32, you are right | 22:42 |
madhu_ak | do you think it should be okay with the issue that I logged on? | 22:43 |
crc32 | the idea was that we didn't want to return degraded if the user deliberatly set admin_state_up=False. | 22:43 |
*** BrianShang has joined #openstack-lbaas | 22:43 | |
madhu_ak | exactly..even I spent sometime to understand the use of admin_state_up field.. | 22:43 |
crc32 | yea I think it needs to be addressed since it confused me as well. I'll let the cores deside though. | 22:44 |
madhu_ak | actually we are writing tempest tests using ddt, so figured out the behavior now | 22:44 |
madhu_ak | thanks for the confirmation | 22:44 |
crc32 | provstatus can stay as "ACTIVE" though. Provisioning status is just there to show if the entity is in a transitional state. It can be active even if the operating status is degraded. | 22:44 |
madhu_ak | Is there a way to edit the doc myself? | 22:46 |
*** BrianShang has quit IRC | 22:47 | |
madhu_ak | okay, I think I can edit the doc, but will let the cores to decide though | 22:48 |
*** BrianShang has joined #openstack-lbaas | 22:49 | |
crc32 | I think this is probably a tad more confusing. | 22:51 |
madhu_ak | he he | 22:52 |
madhu_ak | :) | 22:52 |
*** BrianShang has quit IRC | 22:54 | |
*** bharath has quit IRC | 22:55 | |
*** BrianShang has joined #openstack-lbaas | 22:55 | |
*** bharath has joined #openstack-lbaas | 22:56 | |
*** mlavalle has quit IRC | 23:02 | |
*** BrianShang has quit IRC | 23:03 | |
*** BrianShang has joined #openstack-lbaas | 23:04 | |
*** crc32 has quit IRC | 23:08 | |
*** BrianShang has quit IRC | 23:10 | |
madhu_ak | dougwig, blogan, ptoohill: https://bugs.launchpad.net/neutron/+bug/1449286 | 23:11 |
openstack | Launchpad bug 1449286 in neutron "lb's operating_status is not in DISABLED state when an user creates a loadbalancer with admin_state_up field as 'False'" [Undecided,New] | 23:11 |
*** BrianShang has joined #openstack-lbaas | 23:20 | |
*** BrianShang has quit IRC | 23:24 | |
*** BrianShang has joined #openstack-lbaas | 23:25 | |
*** BrianShang has quit IRC | 23:36 | |
*** BrianShang has joined #openstack-lbaas | 23:37 | |
*** BrianShang has quit IRC | 23:43 | |
*** BrianShang has joined #openstack-lbaas | 23:48 | |
*** BrianShang_ has joined #openstack-lbaas | 23:52 | |
*** BrianShang has quit IRC | 23:53 | |
*** BrianShang_ has quit IRC | 23:56 | |
*** BrianShang has joined #openstack-lbaas | 23:58 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!