*** fnaval has joined #openstack-lbaas | 00:00 | |
*** fnaval has quit IRC | 00:03 | |
openstackgerrit | Bar RH proposed openstack/octavia-tempest-plugin master: Update README https://review.openstack.org/529190 | 00:15 |
---|---|---|
openstackgerrit | Bar RH proposed openstack/octavia-tempest-plugin master: Update README https://review.openstack.org/529190 | 00:19 |
bar_ | {dayou, johnsom, rm_work} would you mind revoting on: https://review.openstack.org/#/c/523931/ ? | 00:26 |
*** threestrands has joined #openstack-lbaas | 00:26 | |
*** threestrands has quit IRC | 00:26 | |
*** threestrands has joined #openstack-lbaas | 00:26 | |
*** fnaval has joined #openstack-lbaas | 00:31 | |
openstackgerrit | Bar RH proposed openstack/octavia master: Fail-proof VIP deallocation task https://review.openstack.org/523931 | 00:32 |
*** fnaval has quit IRC | 00:34 | |
openstackgerrit | Michael Johnson proposed openstack/octavia master: ACTIVE-ACTIVE: Amphora driver updates https://review.openstack.org/529191 | 00:34 |
*** bar_ has quit IRC | 00:47 | |
*** bzhao has quit IRC | 01:10 | |
*** bzhao has joined #openstack-lbaas | 01:12 | |
*** bbzhao has joined #openstack-lbaas | 01:12 | |
*** yamamoto has joined #openstack-lbaas | 01:21 | |
*** yamamoto has quit IRC | 01:21 | |
*** annp has joined #openstack-lbaas | 01:23 | |
openstackgerrit | ZhaoBo proposed openstack/octavia master: Extend api to accept qos_policy_id https://review.openstack.org/458308 | 01:25 |
bzhao | rm_work, johnsom please have a look about https://review.openstack.org/458308 if you are free, thanks.. | 01:26 |
openstackgerrit | ZhaoBo proposed openstack/octavia master: Support UDP load balancing https://review.openstack.org/503606 | 01:30 |
*** yamamoto has joined #openstack-lbaas | 01:57 | |
*** threestrands has quit IRC | 03:03 | |
*** threestrands has joined #openstack-lbaas | 03:04 | |
*** threestrands has quit IRC | 03:04 | |
*** threestrands has joined #openstack-lbaas | 03:04 | |
*** threestrands has quit IRC | 03:05 | |
*** threestrands has joined #openstack-lbaas | 03:06 | |
*** threestrands has quit IRC | 03:06 | |
*** threestrands has joined #openstack-lbaas | 03:06 | |
*** threestrands has quit IRC | 03:07 | |
*** threestrands has joined #openstack-lbaas | 03:07 | |
*** krypto has joined #openstack-lbaas | 03:12 | |
*** threestrands_ has joined #openstack-lbaas | 03:57 | |
*** threestrands has quit IRC | 03:57 | |
*** threestrands_ has quit IRC | 03:58 | |
*** threestrands_ has joined #openstack-lbaas | 03:59 | |
*** yamamoto_ has joined #openstack-lbaas | 04:08 | |
*** yamamoto has quit IRC | 04:11 | |
*** sanfern has joined #openstack-lbaas | 04:18 | |
*** sanfern has quit IRC | 04:22 | |
*** armax has quit IRC | 04:44 | |
*** armax has joined #openstack-lbaas | 04:51 | |
*** armax has quit IRC | 04:51 | |
*** links has joined #openstack-lbaas | 04:57 | |
*** yamamoto_ has quit IRC | 05:10 | |
*** yamamoto has joined #openstack-lbaas | 05:32 | |
*** AlexeyAbashkin has joined #openstack-lbaas | 05:37 | |
*** AlexeyAbashkin has quit IRC | 05:42 | |
*** krypto has quit IRC | 06:10 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/neutron-lbaas master: Imported Translations from Zanata https://review.openstack.org/527600 | 06:13 |
*** gcheresh_ has joined #openstack-lbaas | 06:18 | |
*** ianychoi has quit IRC | 06:44 | |
*** yamamoto has quit IRC | 06:49 | |
*** threestrands_ has quit IRC | 06:57 | |
*** yamamoto has joined #openstack-lbaas | 07:04 | |
*** gcheresh_ has quit IRC | 07:06 | |
*** rcernin has quit IRC | 07:08 | |
*** yamamoto has quit IRC | 07:09 | |
openstackgerrit | Alex Stafeyev proposed openstack/octavia-tempest-plugin master: Added session persistence test. https://review.openstack.org/529243 | 07:18 |
*** yamamoto has joined #openstack-lbaas | 07:20 | |
*** gcheresh_ has joined #openstack-lbaas | 07:20 | |
*** yamamoto has quit IRC | 07:24 | |
*** gcheresh_ has quit IRC | 07:25 | |
openstackgerrit | Alex Stafeyev proposed openstack/octavia-tempest-plugin master: Added session persistence test. https://review.openstack.org/529243 | 07:27 |
*** sapd has quit IRC | 07:40 | |
openstackgerrit | Alex Stafeyev proposed openstack/octavia-tempest-plugin master: Added session persistence test. https://review.openstack.org/529243 | 07:40 |
*** sapd has joined #openstack-lbaas | 07:41 | |
*** gcheresh_ has joined #openstack-lbaas | 07:48 | |
*** yamamoto has joined #openstack-lbaas | 08:04 | |
openstackgerrit | Guoqiang Ding proposed openstack/octavia master: Fix the misspelling of "listener" https://review.openstack.org/529257 | 08:08 |
*** yamamoto has quit IRC | 08:09 | |
*** AlexeyAbashkin has joined #openstack-lbaas | 08:19 | |
*** Alex_Staf_ has joined #openstack-lbaas | 08:22 | |
*** sapd has quit IRC | 08:33 | |
*** yamamoto has joined #openstack-lbaas | 08:34 | |
*** sapd has joined #openstack-lbaas | 08:35 | |
*** yamamoto has quit IRC | 08:39 | |
*** yamamoto has joined #openstack-lbaas | 08:50 | |
*** yamamoto has quit IRC | 08:54 | |
*** yamamoto has joined #openstack-lbaas | 08:56 | |
*** yamamoto has quit IRC | 08:56 | |
*** gcheresh_ has quit IRC | 09:04 | |
*** yamamoto has joined #openstack-lbaas | 09:05 | |
openstackgerrit | Bernard Cafarelli proposed openstack/neutron-lbaas master: Use generic netcat syntax in base scenario https://review.openstack.org/529061 | 09:33 |
*** bcafarel has quit IRC | 10:15 | |
*** krypto has joined #openstack-lbaas | 10:24 | |
openstackgerrit | Nir Magnezi proposed openstack/octavia-dashboard master: Test requirements cleanup https://review.openstack.org/529288 | 10:25 |
*** salmankhan has joined #openstack-lbaas | 10:26 | |
*** gcheresh_ has joined #openstack-lbaas | 10:39 | |
*** gcheresh_ has quit IRC | 10:40 | |
*** bcafarel has joined #openstack-lbaas | 10:42 | |
*** annp has quit IRC | 10:53 | |
*** krypto has quit IRC | 10:56 | |
*** krypto has joined #openstack-lbaas | 10:57 | |
*** yamamoto_ has joined #openstack-lbaas | 11:08 | |
*** AlexeyAbashkin has quit IRC | 11:08 | |
*** gcheresh_ has joined #openstack-lbaas | 11:08 | |
*** yamamoto has quit IRC | 11:11 | |
*** reedip has quit IRC | 11:21 | |
openstackgerrit | Nir Magnezi proposed openstack/octavia-dashboard master: Test requirements cleanup https://review.openstack.org/529288 | 11:25 |
*** reedip has joined #openstack-lbaas | 11:35 | |
*** gcheresh_ has quit IRC | 11:43 | |
*** gcheresh_ has joined #openstack-lbaas | 11:50 | |
*** AlexeyAbashkin has joined #openstack-lbaas | 11:52 | |
*** salmankhan has quit IRC | 12:04 | |
*** salmankhan has joined #openstack-lbaas | 12:06 | |
bcafarel | nmagnezi: zuul is happy with https://review.openstack.org/#/c/529061/ now :) | 12:30 |
nmagnezi | bcafarel, looks good :-) | 13:01 |
*** gcheresh_ has quit IRC | 13:03 | |
*** dmellado has quit IRC | 13:05 | |
*** openstackgerrit has quit IRC | 13:13 | |
-openstackstatus- NOTICE: gerrit is being restarted due to extreme slowness | 13:14 | |
*** dmellado has joined #openstack-lbaas | 13:15 | |
*** dmellado has quit IRC | 13:19 | |
*** dmellado has joined #openstack-lbaas | 13:21 | |
*** yamamoto_ has quit IRC | 13:34 | |
*** krypto has quit IRC | 14:01 | |
*** krypto has joined #openstack-lbaas | 14:02 | |
*** krypto has quit IRC | 14:02 | |
*** krypto has joined #openstack-lbaas | 14:02 | |
*** devfaz has quit IRC | 14:07 | |
*** logan- has quit IRC | 14:08 | |
*** logan- has joined #openstack-lbaas | 14:10 | |
*** yamamoto has joined #openstack-lbaas | 14:10 | |
*** yamamoto has quit IRC | 14:23 | |
*** gcheresh_ has joined #openstack-lbaas | 14:29 | |
*** aojea has joined #openstack-lbaas | 14:38 | |
*** jniesz has joined #openstack-lbaas | 14:50 | |
*** aojea has quit IRC | 14:52 | |
*** gcheresh_ has quit IRC | 14:54 | |
*** yamamoto has joined #openstack-lbaas | 15:23 | |
*** yamamoto has quit IRC | 15:35 | |
*** armax has joined #openstack-lbaas | 15:44 | |
*** pcaruana has joined #openstack-lbaas | 15:51 | |
*** gcheresh_ has joined #openstack-lbaas | 15:58 | |
*** gcheresh_ has quit IRC | 16:12 | |
*** AlexeyAbashkin has quit IRC | 16:37 | |
*** links has quit IRC | 16:44 | |
*** Alex_Staf_ has quit IRC | 16:51 | |
*** krypto has quit IRC | 16:52 | |
*** krypto has joined #openstack-lbaas | 16:53 | |
*** krypto has quit IRC | 16:53 | |
*** krypto has joined #openstack-lbaas | 16:53 | |
*** salmankhan has quit IRC | 17:29 | |
*** salmankhan has joined #openstack-lbaas | 17:37 | |
*** bzhao has quit IRC | 17:52 | |
*** bzhao has joined #openstack-lbaas | 17:53 | |
johnsom | Test | 17:58 |
*** sapd_ has joined #openstack-lbaas | 18:01 | |
*** sapd has quit IRC | 18:01 | |
*** openstackgerrit has joined #openstack-lbaas | 18:05 | |
openstackgerrit | Merged openstack/neutron-lbaas master: Use generic netcat syntax in base scenario https://review.openstack.org/529061 | 18:05 |
*** AlexeyAbashkin has joined #openstack-lbaas | 18:08 | |
*** AlexeyAbashkin has quit IRC | 18:13 | |
*** krypto has quit IRC | 18:31 | |
*** bbzhao has quit IRC | 18:31 | |
*** krypto has joined #openstack-lbaas | 18:31 | |
*** bbzhao has joined #openstack-lbaas | 18:32 | |
*** salmankhan has quit IRC | 18:41 | |
*** bar_ has joined #openstack-lbaas | 18:48 | |
openstackgerrit | Bar RH proposed openstack/octavia master: Remove reliance on NeutronException message field https://review.openstack.org/527839 | 18:54 |
nmagnezi | johnsom, test ended successfully :D | 19:00 |
*** gcheresh_ has joined #openstack-lbaas | 19:03 | |
openstackgerrit | Bar RH proposed openstack/octavia-tempest-plugin master: Update README https://review.openstack.org/529190 | 19:27 |
*** pcaruana has quit IRC | 19:29 | |
*** gcheresh_ has quit IRC | 19:39 | |
*** gcheresh_ has joined #openstack-lbaas | 19:40 | |
*** gcheresh_ has quit IRC | 19:44 | |
*** pcaruana has joined #openstack-lbaas | 19:48 | |
*** pcaruana has quit IRC | 19:54 | |
*** rm_mobile has joined #openstack-lbaas | 19:56 | |
*** longstaff has joined #openstack-lbaas | 19:58 | |
johnsom | #startmeeting Octavia ] | 20:00 |
openstack | Meeting started Wed Dec 20 20:00:16 2017 UTC and is due to finish in 60 minutes. The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot. | 20:00 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 20:00 |
*** openstack changes topic to " (Meeting topic: Octavia ])" | 20:00 | |
openstack | The meeting name has been set to 'octavia__' | 20:00 |
johnsom | #endmeeting | 20:00 |
*** openstack changes topic to "Welcome to LBaaS / Octavia - Queens development is now open." | 20:00 | |
openstack | Meeting ended Wed Dec 20 20:00:24 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 20:00 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/octavia__/2017/octavia__.2017-12-20-20.00.html | 20:00 |
rm_mobile | o/ | 20:00 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/octavia__/2017/octavia__.2017-12-20-20.00.txt | 20:00 |
johnsom | #startmeeting Octavia | 20:00 |
openstack | Log: http://eavesdrop.openstack.org/meetings/octavia__/2017/octavia__.2017-12-20-20.00.log.html | 20:00 |
openstack | Meeting started Wed Dec 20 20:00:29 2017 UTC and is due to finish in 60 minutes. The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot. | 20:00 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 20:00 |
*** openstack changes topic to " (Meeting topic: Octavia)" | 20:00 | |
openstack | The meeting name has been set to 'octavia' | 20:00 |
rm_mobile | o/ | 20:00 |
johnsom | Try that again without the type-o.... | 20:00 |
xgerman_ | o/ | 20:00 |
johnsom | Hi folks | 20:01 |
longstaff | hi | 20:01 |
johnsom | #topic Announcements | 20:01 |
*** openstack changes topic to "Announcements (Meeting topic: Octavia)" | 20:01 | |
jniesz | hi | 20:01 |
johnsom | I plan to cancel the weekly IRC meeting next week. We will resume 1/3/18. | 20:01 |
xgerman_ | +1 | 20:01 |
johnsom | Many folks are taking some time off at the end of the year. | 20:01 |
rm_mobile | Yep | 20:02 |
johnsom | I will send out an e-mail after the meeting. | 20:02 |
johnsom | Also news, freenode (the IRC host for OpenStack) had a spam issue over the weekend | 20:02 |
rm_mobile | Lol yes | 20:02 |
rm_mobile | Such spam | 20:02 |
johnsom | There were offensive comments posted to rooms and they were direct messaging folks. | 20:02 |
*** kpalan1 has joined #openstack-lbaas | 20:03 | |
johnsom | Because of that you now need to be registered with freenode and logged in to post in some channels and to direct message folks. | 20:03 |
johnsom | I know some folks didn't get the notification of the change and were having trouble with IRC. | 20:03 |
nmagnezi | o/ | 20:04 |
johnsom | Let me know if you have folks having trouble and I can help get them setup on freenode. | 20:04 |
johnsom | There was a summary of the "1 year release cycle" discussion posted to the mailing list: | 20:04 |
johnsom | #link http://lists.openstack.org/pipermail/openstack-dev/2017-December/125688.html | 20:04 |
johnsom | At this point it seems like an ongoing discussion, but thought I would keep you posted. | 20:05 |
nmagnezi | thanks for that url. | 20:05 |
xgerman_ | my feeling it’s a done deal | 20:05 |
johnsom | Final announcement I have this week, we had a video conference hosted by RedHat to talk about the provider drivers. It was announced on the mailing list. There is a short summary of topics here: | 20:06 |
johnsom | #link https://etherpad.openstack.org/p/octavia-providers-queens | 20:06 |
*** pcaruana has joined #openstack-lbaas | 20:06 | |
johnsom | xgerman_ Yeah, I don't know. There is another 30+ message chain that has started up, so... | 20:07 |
nmagnezi | thanks for all attendees. i think we have a very good discussion. | 20:07 |
johnsom | +1 | 20:07 |
johnsom | Any other announcements today? | 20:07 |
nmagnezi | s/have/had | 20:07 |
nmagnezi | it's getting late for me. sorry :) | 20:07 |
johnsom | #topic Brief progress reports / bugs needing review | 20:07 |
*** openstack changes topic to "Brief progress reports / bugs needing review (Meeting topic: Octavia)" | 20:07 | |
johnsom | I have been focusing on Active/Active patches this week. | 20:07 |
johnsom | I have a data model patch up for review and have started on the amphora driver patch. | 20:08 |
johnsom | Mostly this is a breakdown of one of the older patches that was pretty large and needed some love. | 20:08 |
johnsom | Plus many reviews in the Active/Active space. | 20:08 |
nmagnezi | #link https://review.openstack.org/#/c/529191/ | 20:09 |
johnsom | I also reviewed the QoS again today. Looks pretty good to me. | 20:09 |
nmagnezi | #link https://review.openstack.org/#/c/528850/ | 20:09 |
johnsom | thanks nmagnezi | 20:09 |
johnsom | Any other progress updates? | 20:09 |
bar_ | octavia client for qos is ready | 20:10 |
bar_ | https://review.openstack.org/#/c/526217/ | 20:10 |
johnsom | Oh, cool. I will check out the update on that | 20:10 |
bar_ | great | 20:11 |
johnsom | It was good last time I checked though you couldn't delete the policy, which I expect is what you fixed. | 20:11 |
bar_ | right | 20:11 |
johnsom | #link https://review.openstack.org/#/c/526217/ | 20:11 |
johnsom | ^^^ get that in the minutes. | 20:11 |
johnsom | #topic Heat updates for Octavia | 20:12 |
*** openstack changes topic to "Heat updates for Octavia (Meeting topic: Octavia)" | 20:12 | |
johnsom | #link https://bugs.launchpad.net/heat/+bug/1737567 | 20:12 |
openstack | Launchpad bug 1737567 in OpenStack Heat "Direct support for Octavia LBaaS API" [Medium,New] - Assigned to Rabi Mishra (rabi) | 20:12 |
johnsom | There is a bug open to update Heat for the new Octavia endpoint. | 20:12 |
johnsom | The author is hoping to drum up support with "affects me" votes on the bug. So if you have an interest in Heat getting updated please voice your interest on the bug. | 20:13 |
*** pcaruana has quit IRC | 20:13 | |
johnsom | #topic Open Discussion | 20:14 |
*** openstack changes topic to "Open Discussion (Meeting topic: Octavia)" | 20:14 | |
johnsom | I didn't have anymore agenda items as I wasn't sure what the turnout was going to be. Are there other topics we would like to continue? | 20:14 |
kpalan1 | we are planning to add the octavia v2 api support in fog-openstack gem | 20:14 |
johnsom | Good question. | 20:14 |
johnsom | I don't know anyone working on that currently | 20:15 |
kpalan1 | an issue is created on their github. | 20:15 |
johnsom | kpalan1 Are you able to help with that? | 20:15 |
kpalan1 | yes i will working on it | 20:16 |
rm_work | that was the way I read it :P | 20:16 |
rm_work | "we are planning to add" :) | 20:16 |
jniesz | yes, we would like to contribute that | 20:16 |
rm_work | also: +A'd the QoS patch | 20:16 |
johnsom | Oh, oppps, got distracted looking it up | 20:16 |
xgerman_ | sweet | 20:16 |
johnsom | Cool, it looks like it currently only has lbaasv1 support.... Sad face | 20:16 |
johnsom | Oh, maybe not, I see it in the"requests" just not the models | 20:17 |
kpalan1 | waiting for active-active work to complete , we will be starting soon to add octavia v2 api support there, we need it internally forone of our chef based tool | 20:17 |
johnsom | kpalan1 Please feel free to ping us if you run into questions, etc. | 20:17 |
kpalan1 | sure, thanks | 20:18 |
bar_ | There're 2 issues/proposal that haven't been resolved in prior meeting: (1) the independent member API (no pool id) | 20:18 |
bar_ | (2) bind amphora agent patch | 20:18 |
rm_work | 1) I think we just need to vote on whether we think it will ever be useful to have shared member objects | 20:19 |
nmagnezi | rm_work, ^^ started to sleep in normal hours.. so we did not discuss this again :< | 20:19 |
johnsom | Right. Since we do have a good group here today, let's start at the top | 20:19 |
*** krypto has quit IRC | 20:19 | |
rm_work | nmagnezi: i told people that going to a normal schedule would not be a *good thing* for work :/ | 20:19 |
rm_work | but no one listens | 20:19 |
johnsom | Hahaha | 20:20 |
*** krypto has joined #openstack-lbaas | 20:20 | |
*** krypto has quit IRC | 20:20 | |
*** krypto has joined #openstack-lbaas | 20:20 | |
johnsom | So, independent members... | 20:20 |
johnsom | bar_ Do you want to give a quick summary again? | 20:20 |
bar_ | k, currently we access in octavia api to members, only by specifying both pool_id and member_id | 20:21 |
bar_ | member_id is unique, so why not ADD another API, to access by member_id alone | 20:21 |
*** rm_mobile has quit IRC | 20:21 | |
bar_ | that's the proposal | 20:21 |
rm_work | yeah I think this is full circle, right? | 20:22 |
rm_work | doing /v2.0/lbaas/member/ | 20:22 |
rm_work | because ... we don't really need to do shared members ever IMO | 20:22 |
rm_work | I would agree with this idea, don't need to know a pool_id to look up a member | 20:22 |
xgerman_ | so we only wanto to do GET and LIST ? | 20:23 |
xgerman_ | (read only) | 20:23 |
rm_work | hmm | 20:23 |
rm_work | I mean, I actually don't know why we couldn't do POST | 20:23 |
johnsom | I think there was a concern raised before about the relationship with pool and member today, that deleting a pool currently deletes it's members too. xgerman_ is that right? | 20:23 |
nmagnezi | xgerman_, why not update as well? | 20:23 |
rm_work | if you pass a pool_id | 20:24 |
xgerman_ | yes, we cascade the pool deletion to members | 20:24 |
rm_work | listeners are a sub-object on a LB, and those aren't *under* LB | 20:24 |
xgerman_ | but if we only provide read only I see that less of a concern | 20:24 |
rm_work | and they can be cascade deleted as well | 20:24 |
rm_work | I'm not sure what the cascade deletion has to do with it | 20:24 |
johnsom | I will say that we would have to maintain the current API paths, etc. for backward compatibility. Otherwise we are talking about LBaaSv3, which I really don't want to consider right now due to all of the other work going on. | 20:25 |
rm_work | lol yes | 20:25 |
rm_work | so we're talking about just adding another resource | 20:25 |
rm_work | like, member_standalone | 20:25 |
rm_work | at /member/ | 20:25 |
bar_ | technically, /members/ | 20:26 |
rm_work | err, yeah i always forget if our resource names are plural in the API >_> | 20:26 |
xgerman_ | since we could spend our time doing other things - do we have a use case why we need that? | 20:26 |
rm_work | it's ... easier to access? <_< | 20:26 |
rm_work | dunno | 20:26 |
johnsom | You would have to make pool_id mandatory on the member create calls | 20:27 |
rm_work | i'm just saying i'd vote to allow that | 20:27 |
rm_work | not that we should prioritize it | 20:27 |
johnsom | xgerman_ Very good question | 20:27 |
rm_work | if someone wants to spend their time doing something though, I can't stop them | 20:27 |
bar_ | xgerman_, I don't see much use, if members are not to be shared. | 20:27 |
rm_work | that's the point of open source, and why companies hire us anyway -- to set priorities | 20:27 |
bar_ | It would be easier to access, that's it. | 20:28 |
rm_work | yep | 20:28 |
johnsom | Agreed, but it would be another distraction from getting our major goals for the release done (act/act, drivers, flavor) | 20:28 |
xgerman_ | yeah, even if we don;t write it we will need to review it | 20:28 |
nmagnezi | so we can set it as "wish list" or something | 20:28 |
xgerman_ | yep | 20:28 |
rm_work | i'm just saying, if i saw code pop up that does this, I'd review it and be willing to +2 if it's good | 20:28 |
nmagnezi | rm_work, +1 | 20:29 |
rm_work | i think the point of the question was just "is this OK?" | 20:29 |
bar_ | Approved then? | 20:29 |
johnsom | Does this reach the spec bar or just an RFE? | 20:29 |
nmagnezi | i *think* we kinda all agree that read only direct access to members is okay, it's just not a prio | 20:29 |
xgerman_ | RFE — did we ever figure out versioning? | 20:30 |
johnsom | xgerman_ Like API micro-versioning? | 20:30 |
xgerman_ | like a client knowing that /members is available | 20:30 |
xgerman_ | (without tetsing every new path) | 20:31 |
johnsom | xgerman_ API discovery is still up in the air last time I checked the api-wg. We would need to change the client to support this. | 20:32 |
xgerman_ | ok, so we should threat lightly on API extensions | 20:32 |
xgerman_ | just my 2cts | 20:32 |
johnsom | #link https://specs.openstack.org/openstack/api-wg/guidelines/discoverability.html | 20:32 |
johnsom | Big fat TODO still | 20:32 |
rm_work | >_> | 20:33 |
rm_work | we so we DO have a version bit | 20:34 |
xgerman_ | yeah, I have seen too many clients relying on the user to define what’s possible — hate to see a —use-member-direct flag | 20:34 |
rm_work | but i imagine the client could try and fallback | 20:34 |
johnsom | We do have a version that would increment for this enhancement | 20:34 |
nmagnezi | rm_work, if a pool id was not provided, how should the client fall back? | 20:34 |
rm_work | nmagnezi: ah good point | 20:35 |
nmagnezi | :) | 20:35 |
rm_work | so if no pool-id is provided and the new endpoint isn't there.... <_< | 20:35 |
rm_work | then fail | 20:35 |
rm_work | I guess | 20:35 |
johnsom | Yep | 20:35 |
xgerman_ | ok, so we increment our version - client checks that and acts accordingly | 20:36 |
xgerman_ | … | 20:36 |
nmagnezi | i think that API versioning is a broader topic. for example we can say similar things about the upcoming QoS support | 20:36 |
johnsom | Right. <note cores need to watch for API additions and make sure the version minor updates> | 20:37 |
bar_ | +1 | 20:37 |
johnsom | Yep | 20:37 |
johnsom | We have overlooked that recently | 20:37 |
xgerman_ | +1 | 20:37 |
* johnsom slaps his own wrist | 20:37 | |
nmagnezi | johnsom, not we have two incentives not to :) | 20:38 |
xgerman_ | we should also add that to the API docs so someone knows which version has which AI | 20:39 |
xgerman_ | calls | 20:39 |
johnsom | I will take an action to go update the version starting with QoS. | 20:39 |
nmagnezi | xgerman_, do we have an API call to fetch the version number? | 20:39 |
xgerman_ | +1 (I can see us also lumoing all changes for a cycle together) | 20:39 |
johnsom | nmagnezi Yes | 20:40 |
xgerman_ | GET / | 20:40 |
johnsom | #link https://developer.openstack.org/api-ref/load-balancer/#api-discovery | 20:40 |
rm_work | xgerman_: agreed, for one cycle it's probably fine to lump stuff | 20:41 |
rm_work | and for those of us on master, "missing" features is less of a problem :P | 20:41 |
*** links has joined #openstack-lbaas | 20:41 | |
xgerman_ | but with one year cycles looming I would increment more often | 20:41 |
johnsom | Though I wonder if we should not have a numerical version here as well. Will have to go back and double check the api-wg | 20:42 |
rm_work | yeah we should just buckle down and be good about doing it i guess | 20:42 |
xgerman_ | +1 | 20:42 |
johnsom | +1 | 20:42 |
johnsom | You guys should fire your PTL | 20:42 |
johnsom | Grin | 20:42 |
rm_work | lol nope | 20:42 |
rm_work | 4 more years! :P | 20:42 |
nmagnezi | Ha | 20:42 |
nmagnezi | +1 Adam | 20:43 |
johnsom | Oye | 20:43 |
johnsom | Anyway, let's summary here.... | 20:43 |
rm_work | Yeah we could do version increments there too probably | 20:43 |
rm_work | cause just having "last updated date" is kinda weird | 20:43 |
rm_work | id=v2.0 is also weird | 20:43 |
johnsom | RFE it. Ok to add read-only paths, remember to bump the api minor version as a start | 20:44 |
rm_work | shouldn't we have like... ['major', 'minor'] at a minimum? | 20:44 |
johnsom | right? | 20:44 |
johnsom | rm_work Yeah, I am wondering too. I know this was a copy of neutron-lbaas, but that doesn't mean it's right.... | 20:44 |
rm_work | yeah certainly read-only is easier, but i still don't see why it couldn't be a full CRUD resource | 20:44 |
xgerman_ | yep, but major is v2 | 20:45 |
rm_work | johnsom: i wonder what we break if we add major/minor and just point it to the ID | 20:45 |
rm_work | or maybe actually | 20:45 |
rm_work | major=2 minor=0 | 20:45 |
rm_work | would be "now" | 20:45 |
xgerman_ | indeed | 20:45 |
johnsom | Well, if you ask too many questions here your answer will come to micro-versions.... | 20:45 |
rm_work | heh | 20:46 |
rm_work | k i'd probably be in favor of major/minor/micro | 20:46 |
rm_work | or something | 20:46 |
rm_work | what's the third one | 20:46 |
xgerman_ | nah, we just increase minor sequentially | 20:46 |
johnsom | https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html#version-discovery | 20:46 |
johnsom | #link https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html#version-discovery | 20:46 |
rm_work | kk | 20:46 |
rm_work | so we do THAT | 20:46 |
rm_work | that works | 20:46 |
rm_work | it has id | 20:47 |
cgoncalves | +1 for microversion | 20:47 |
rm_work | but also the real stuff | 20:47 |
johnsom | So... We are compliant today, just not supporting microversions yet | 20:47 |
rm_work | wooo standards | 20:47 |
*** links has quit IRC | 20:47 | |
rm_work | yep, +1 implement microversion | 20:47 |
rm_work | probably we should do that inside the cycle (it looks trivial) | 20:47 |
johnsom | id is the same as we have now | 20:47 |
xgerman_ | ok, microversions it is | 20:47 |
rm_work | so we have a first microversion for QoS and whatever else | 20:47 |
johnsom | Oye, ok... Please read the whole doc before deciding we want to jump on that. | 20:48 |
rm_work | and then we can try to be good about incrementing on API changes from now | 20:48 |
rm_work | ok will read | 20:48 |
johnsom | It can also make the client a bit of hell | 20:48 |
rm_work | should we do an official vote in January when we're all back? | 20:48 |
johnsom | Yes, let's hold off on the microversion stuffs | 20:48 |
xgerman_ | can’t we just do server and ignore client? | 20:49 |
johnsom | bar_ Did you get an answer out of that on the member API? | 20:49 |
rm_work | i mean ... the POINT is for the client, isn't it? | 20:49 |
johnsom | rm_work +1 | 20:49 |
bar_ | hmm, why only read-only path? | 20:49 |
rm_work | yeah i'm not sure i follow read-only either | 20:49 |
xgerman_ | I don’t like the ACCEPT Header stuff | 20:49 |
rm_work | i would just do it as a full thing | 20:49 |
rm_work | and we'll review | 20:49 |
rm_work | i think it'll be fine | 20:50 |
rm_work | when people see that it works | 20:50 |
rm_work | again though, some other stuff is probably higher priority | 20:50 |
rm_work | like finishing our tempest stuff (did you say you were going to look at that?) | 20:50 |
johnsom | Ok, maybe split the patches just in case someone comes up with a reason why the updates are a bad idea | 20:50 |
bar_ | I am. | 20:50 |
rm_work | kk | 20:50 |
bar_ | It's... neglected... | 20:50 |
johnsom | Oh yes, tempest is important. | 20:51 |
bar_ | I need to re-write some patches. | 20:51 |
johnsom | It is a community goal. I have updated our status to in-progress. | 20:51 |
bar_ | can we deprecate octavia/tests/tempest? | 20:51 |
bar_ | *deprecate=delete | 20:51 |
johnsom | Yes, it goes way with the tempest plugin patch | 20:51 |
johnsom | Though we need to time it with the overall tempest plugin switch over | 20:52 |
bar_ | Is it for Queens? | 20:52 |
johnsom | We need to have a working tempest plugin for queens, yes | 20:52 |
johnsom | #link https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html | 20:53 |
bar_ | ok. API proposal is approved? (though not prioritized) | 20:53 |
johnsom | Well, technically you would create the RFE story and we would approve it there, but essentially yes. | 20:54 |
bar_ | I see. | 20:54 |
johnsom | After the tempest plugin is done.... GRIN | 20:54 |
johnsom | just kidding | 20:54 |
bar_ | :-{ | 20:54 |
bar_ | :-) | 20:54 |
bar_ | I'm working on it | 20:54 |
johnsom | THANK YOU | 20:54 |
bar_ | bind amphora agent? | 20:54 |
johnsom | Ok, six minutes, bind amphora agent. This was about a better way to do it right? | 20:55 |
*** Alex_Staf has joined #openstack-lbaas | 20:55 | |
bar_ | rm_work, nmagnezi ? | 20:55 |
johnsom | Last I remember rm_work was going to comment/help with the "better" way | 20:55 |
bar_ | yeah, but nmagnezi and I have reservations.... | 20:55 |
rm_work | better way should just be to finally implement the amphora-api for update-config | 20:56 |
nmagnezi | basically bar's current implementation is to create the neutron port before we call "nova boot" so we'll know the IP in advance and configure amphora-agent.conf | 20:56 |
rm_work | and our initial connection to the amp can do a config update to set the right listening IP | 20:56 |
rm_work | yeah, and that's untenable for some types of networks | 20:56 |
nmagnezi | rm_work does not like that implementation and prefers an agent restart API call to update the file and reload config | 20:56 |
johnsom | nmagnezi We didn't do that because it doesn't work in some deployments if I remember | 20:57 |
nmagnezi | rm_work, what types of networks ?: ) | 20:57 |
bar_ | can we have different flows for different types of networks? Is it... done? | 20:57 |
rm_work | the kind where you can't choose the network that gets plugged to a new VM :) | 20:57 |
nmagnezi | johnsom, correct. rm_work's deployment does not support it for example. | 20:57 |
nmagnezi | rm_work, so how does nova knows? :) just wondering.. | 20:58 |
rm_work | nova figures it out internally | 20:58 |
rm_work | based on the HV that it schedules, it also schedules a network | 20:58 |
johnsom | I think originally nova-networks had an issue with it too. Like you couldn't boot without at least one nic | 20:58 |
cgoncalves | johnsom: true | 20:58 |
nmagnezi | rm_work, is that a thing in nova? or is it an internal solution you guys have? | 20:58 |
johnsom | nova networks is dead now BTW | 20:59 |
rm_work | I know it's not just me, too -- i talked to at least one other deployer that had the same issue | 20:59 |
rm_work | in our case it is a custom scheduler in nova, yes | 20:59 |
nmagnezi | johnsom, good riddance (nova network) | 20:59 |
xgerman_ | we also talked about taking it from DHCP/cloud init/? | 20:59 |
rm_work | yeah that might be possible | 20:59 |
johnsom | I will say, we still need the amp config update API. That is still a super valid need. | 20:59 |
xgerman_ | but we shouldn’t comingle the two | 21:00 |
rm_work | yes, and my point was that we should just take this opportunity to do it and use it | 21:00 |
nmagnezi | johnsom, for health manager list? (trying to recall) | 21:00 |
rm_work | yes | 21:00 |
johnsom | rm_work I know that is what was originally discussed | 21:00 |
johnsom | Ugh, meeting time is up.... | 21:00 |
johnsom | #endmeeting | 21:00 |
*** openstack changes topic to "Welcome to LBaaS / Octavia - Queens development is now open." | 21:00 | |
openstack | Meeting ended Wed Dec 20 21:00:54 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:00 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/octavia/2017/octavia.2017-12-20-20.00.html | 21:00 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/octavia/2017/octavia.2017-12-20-20.00.txt | 21:00 |
openstack | Log: http://eavesdrop.openstack.org/meetings/octavia/2017/octavia.2017-12-20-20.00.log.html | 21:01 |
*** Alex_Staf has quit IRC | 21:01 | |
johnsom | Just made it .. ha | 21:01 |
nmagnezi | well.. next year i guess.. | 21:01 |
bar_ | lol | 21:01 |
cgoncalves | hard stop there :) | 21:01 |
nmagnezi | ha | 21:01 |
openstackgerrit | Adam Harwell proposed openstack/octavia master: Switch to using PKCS12 for TLS Term certs https://review.openstack.org/504175 | 21:01 |
johnsom | nmagnezi yeah, HM list was one need | 21:01 |
xgerman_ | +1 | 21:01 |
nmagnezi | johnsom, what's the usecase here? in case an operator loads a new hm to an existing production env? | 21:02 |
xgerman_ | yep, or an ip changes | 21:02 |
johnsom | Yeah, all of the above. | 21:02 |
nmagnezi | aye | 21:02 |
rm_work | so, once we have that, we can solve this problem as well by just utilizing that call | 21:03 |
rm_work | and sending it the correct IP to bind | 21:03 |
nmagnezi | bar_, ^^ what do you think? | 21:03 |
bar_ | nmagnezi, need to understand better how it is implemented | 21:04 |
rm_work | we're literally polling to connect to the VM as it comes up, so the time it'd be listening on 0.0.0.0 is super low, and we have other security measures (client-cert-auth) that should already be fairly effective | 21:04 |
cgoncalves | IMO rm_work's proposal addresses not only the problem at hand but also enables use cases | 21:05 |
cgoncalves | if I understood it correctly, that is | 21:05 |
rm_work | not to mention that if someone did manage to beat us to hitting the rebind call, AND the managed to bypass our cert security ... we'd be unable to connect and quickly fail the VM, and it'd never go into service | 21:05 |
nmagnezi | johnsom, btw re: https://bugs.launchpad.net/heat/+bug/1737567 points to https://governance.openstack.org/tc/reference/projects/octavia.html which says.. we deprecate n-lbaas in Feb 2018 ? | 21:05 |
openstack | Launchpad bug 1737567 in OpenStack Heat "Direct support for Octavia LBaaS API" [Medium,New] - Assigned to Rabi Mishra (rabi) | 21:05 |
rm_work | cgoncalves: that's the idea | 21:05 |
cgoncalves | rm_work: how is that being pooled btw? | 21:05 |
rm_work | *polled? | 21:06 |
nmagnezi | johnsom, wanted to raise this in the open discussion but we ran out of time.. | 21:06 |
cgoncalves | oops yes :) | 21:06 |
johnsom | nmagenzi I think we also wanted to turn on debug, change the health heartbeat intervals, rotate the heartbeat key, etc. | 21:06 |
rm_work | cgoncalves: so when we spin a new Amphora, we sit in a loop trying to connect to it to make sure it's up and healthy, and i believe we do some initial config with it | 21:06 |
rm_work | if we never get a response (within configured timeout period), we assume the create failed (usually because nova broke or our image was bad or network isn't working) | 21:07 |
johnsom | nmagnezi We have not declared a deprecation for neutron-lbaas anywhere.... I don't see it on the governance site... | 21:07 |
rm_work | any of those cause us to just throw away that amphora as a failure | 21:07 |
nmagnezi | johnsom, neutron-lbaas ==> assert:follows-standard-deprecation | 21:08 |
nmagnezi | johnsom, i'm getting this wrong maybe | 21:08 |
*** Alex_staf has joined #openstack-lbaas | 21:08 | |
cgoncalves | rm_work: k. I'm wondering if it would be better to listen on the message bus for nova to tell the amp is up and then poll for the service | 21:08 |
nmagnezi | johnsom, he just wrote it in the bug "..and will deprecate the current neutron-lbaas extension starting Queens release (February 2018)" | 21:08 |
johnsom | nmagnezi Yes, we assert that we will follow standard deprecation policy, not that it is yet deprecated.... | 21:08 |
cgoncalves | rm_work: it would also be faster to react in case nova reports it failed to boot | 21:09 |
rm_work | nova tells us the amp is ACTIVE | 21:09 |
rm_work | before we start to poll | 21:09 |
rm_work | but from nova considering the amp is "up" to when our agent is actually listening ... is not clear | 21:09 |
rm_work | yes, if nova goes to ERROR or something we fail at that point | 21:09 |
johnsom | cgoncalves Nova claims it's up long before the kernel is even booted.... | 21:09 |
nmagnezi | johnsom, oh, alright. thanks for that answer. | 21:09 |
rm_work | the polling happens after Nova already says it's done | 21:09 |
bar_ | rm_work, given the security measures already applied on communication with the amphorae, is your solution significantly better than leaving the agent on 0.0.0.0? | 21:09 |
rm_work | bar_: honestly I don't really see a huge need to "fix" this | 21:09 |
cgoncalves | rm_work: ah ok, so we wait for the ACTIVE signal | 21:10 |
rm_work | but I can understand just not wanting to have extra ports open on networks that are bad | 21:10 |
rm_work | opening up to DDoS or something | 21:10 |
rm_work | cgoncalves: yes | 21:10 |
johnsom | bar_ This bug is OLD. It was in before we added the network namespace.... | 21:10 |
nmagnezi | johnsom, the agent runs on the root namespace | 21:10 |
rm_work | right | 21:11 |
johnsom | Right | 21:11 |
rm_work | but | 21:11 |
cgoncalves | k, I have no knowledge how it is implemented in octavia sorry :) | 21:11 |
rm_work | .... nothing else is plugged there | 21:11 |
rm_work | the danger was that the member networks used to be plugged there as well | 21:11 |
rm_work | and we didn't: A) want to take up a port on the VIP network; B) open our API to ddos on the VIP/member networks | 21:11 |
johnsom | cgoncalves No worries. Just noting that nova claims it is booted when it starts the HV process, not when anything is actually accessible/running. | 21:12 |
rm_work | now we're alone on the mgmt-net | 21:12 |
rm_work | i personally think running on 0.0.0.0 is not really a risk anymore | 21:12 |
rm_work | since the only thing that's typically plugged in that namespace is the mgmt-net | 21:12 |
johnsom | Really this is just down to checking a security box that we don't listen on 0.0.0.0 | 21:12 |
rm_work | yep | 21:13 |
bar_ | rm_work, does my patch fail amphora boot for you? | 21:13 |
rm_work | so, the other option that was proposed (getting the configured IP from cloud-init and setting our config from that) is also interesting, if someone has some idea how to do that | 21:13 |
rm_work | bar_: yes, it will | 21:13 |
rm_work | we cannot create ports ahead of VM creation | 21:14 |
rm_work | because we cannot specify a mgmt-net | 21:14 |
johnsom | I know how to do that, roughly | 21:14 |
rm_work | it has to be auto-assigned to us via the nova scheduler | 21:14 |
bar_ | rm_work, can you help me insert a flag that will skip that allocation in your deployment? is that something you would consider implementing? | 21:14 |
rm_work | I still don't see the point of complicating the flows with yet more port creation/plugging/cleanup | 21:15 |
rm_work | we already have enough of that | 21:15 |
bar_ | I hear you | 21:15 |
rm_work | I think if johnsom knows how to use cloud-init to do it, that would probably work fine | 21:15 |
johnsom | +1 | 21:15 |
rm_work | currently we juggle so many objects manually that need to be tracked and cleaned up that I am in a constant state of paranoia about how much orphaned stuff is floating around | 21:16 |
rm_work | security groups, ports, vms | 21:16 |
rm_work | I've seen all of these be orphaned in my environment for various reasons T_T | 21:17 |
johnsom | Yeah, I really like leaning on nova to create that port. It's better for bare metal too. | 21:18 |
rm_work | I'm working on a set of scripts to scan and link all objects we create so I can track what is possibly orphaned | 21:18 |
rm_work | probably when I'm done I'll throw it in contrib/ | 21:18 |
bar_ | Can nova alter the agent_configuration file? | 21:18 |
johnsom | No, but cloud-init could if we wanted. Or the agent can pick up cloud init data and update the config file | 21:19 |
xgerman_ | +1 | 21:19 |
xgerman_ | then there is the infmaous metadata service | 21:20 |
johnsom | Which is what cloud-init would use if we didn't disable it | 21:20 |
rm_work | yeah I guess we could just update the agent to look for cloud-init stuff on boot | 21:20 |
rm_work | *on start | 21:20 |
xgerman_ | or just the init script | 21:21 |
rm_work | and update its config before it even runs | 21:21 |
xgerman_ | for the service | 21:21 |
*** aojea has joined #openstack-lbaas | 21:21 | |
rm_work | yeah | 21:21 |
rm_work | true | 21:21 |
rm_work | pre-start | 21:21 |
rm_work | update config from cloud-init | 21:21 |
rm_work | that seems doable | 21:21 |
bar_ | I'm not convinced it will have much value, I must admit. There is not one that argues that it is an actual vulnerability, other than the root argument, which perhaps should be taken look of independently. | 21:24 |
bar_ | If we're satisfied with the current security measures, than it doesn't make sense to invest time in cloud-init solution, am I wrong? | 21:26 |
bar_ | *then | 21:26 |
rm_work | Yeah I'm not sure it's worth very much time | 21:26 |
bar_ | nmagnezi, are you still here? | 21:26 |
rm_work | just that people have a tendency to freak out when they see the 0.0.0.0 and hardly anyone actually knows how the namespacing works | 21:27 |
rm_work | I feel like the most common troubleshooting question here is "why don't I see my vip or member networks plugged, did something go wrong?" | 21:27 |
rm_work | anywho, i'm on vacation today so I'm gonna go back to doing that, have fun ya'll :P | 21:28 |
johnsom | o/ | 21:28 |
bar_ | rm_work, thanks for joining | 21:28 |
rm_work | I'm technically not back until 2018 but I can pop in if i see pings | 21:29 |
openstackgerrit | Merged openstack/octavia master: Extend api to accept qos_policy_id https://review.openstack.org/458308 | 21:34 |
*** threestrands_ has joined #openstack-lbaas | 21:36 | |
bar_ | johnsom, Is the qos client patch blocked due to versioning? | 21:39 |
johnsom | bar_ ummm | 21:40 |
johnsom | Give me a minute to look at it | 21:41 |
openstackgerrit | Adam Harwell proposed openstack/octavia master: Switch to using PKCS12 for TLS Term certs https://review.openstack.org/504175 | 21:43 |
johnsom | bar_ Any idea what the error is if they run it against a non-qos API? | 21:43 |
bar_ | johnsom, never tried it. | 21:43 |
johnsom | I think I can, just a minute | 21:43 |
johnsom | Ok, a few minutes, this stack doesn't have qos enabled... | 21:47 |
johnsom | stack@devstackpy27-2:/etc/neutron/plugins/ml2$ openstack loadbalancer create --vip-qos-policy-id test --vip-subnet-id private-subnet --name lb1 | 21:51 |
johnsom | Unknown attribute for argument load_balancer.loadbalancer: vip_qos_policy_id (HTTP 400) (Request-ID: req-0b708b91-1b38-4b64-bab9-3da6fe72d246) | 21:51 |
bar_ | is it good or bad? | 21:51 |
johnsom | bar_ I am fine with letting that through. It's not ideal, but at least is clear to the user what is wrong. | 21:52 |
bar_ | Did you try PUT? | 21:52 |
johnsom | no | 21:52 |
bar_ | openstack loadbalancer lb_id --vip_qos_policy_id qos_id | 21:53 |
bar_ | *loadbalancer set | 21:53 |
johnsom | Assuming I have one booted. glance is acting up and not acknowledging the tag | 21:53 |
*** longstaff has quit IRC | 21:56 | |
johnsom | bar_ Yeah, same exact error | 21:57 |
bar_ | great! | 21:57 |
*** aojea has quit IRC | 22:04 | |
bar_ | johnsom, should we update the example local.conf, now that this feature is merged? | 22:10 |
xgerman_ | yes | 22:10 |
xgerman_ | + we need a gate | 22:10 |
bar_ | a gate?? | 22:10 |
xgerman_ | yep, a jenkins gate where we have qos enabled and appropriate tempest tests | 22:11 |
bar_ | I see | 22:12 |
johnsom | Frankly we should improve the error message when neutron doesn't have QoS enabled: | 22:13 |
johnsom | stack@devstackpy27-2:~/project/testqosclient/python-octaviaclient$ openstack loadbalancer create --vip-qos-policy-id foo --vip-subnet-id private-subnet --name lb1 | 22:13 |
johnsom | The resource could not be found. | 22:13 |
johnsom | Neutron server returns request_ids: ['req-70b3cf2f-c04d-4fef-a4a5-313fb45b64ae'] | 22:13 |
johnsom | That is neutron's response that passes through our API..... | 22:14 |
bar_ | Note I already have a patch waiting for review about NeutronException, which was dependent on the QoS feature. | 22:15 |
johnsom | bar_ I think this is client side... | 22:16 |
*** kpalan1 has quit IRC | 22:16 | |
johnsom | But I am aware of your patch too | 22:16 |
bar_ | johnsom, oh, i see. yeah, my patch is server side... | 22:17 |
johnsom | bar_ | 22:18 |
bar_ | ? | 22:18 |
johnsom | https://www.irccloud.com/pastebin/1gEEXU2W/ | 22:18 |
johnsom | Though I think this might just be an overall issue with OSC.... | 22:18 |
johnsom | https://review.openstack.org/#/c/526217/5/octaviaclient/osc/v2/utils.py Line 157 | 22:18 |
johnsom | I think it's trying to go out and verify the policy ID and that is all that it gets back.... | 22:19 |
bar_ | Is there a foo qos_policy? | 22:20 |
johnsom | No because qos isn't enabled | 22:21 |
bar_ | You would like the client to mask that in a way? Or verify qos is enabled? | 22:21 |
johnsom | Well, I don't know if it's *our* bug or a bug in client_manager.neutronclient.list_qos_policies | 22:22 |
bar_ | right | 22:22 |
openstackgerrit | Merged openstack/python-octaviaclient master: Updated from global requirements https://review.openstack.org/528912 | 22:22 |
johnsom | I'm just thinking from an end-user, this doesn't tell me that QoS is disabled in neutron. | 22:22 |
johnsom | It implies that I just have the wrong ID | 22:23 |
johnsom | stack@devstackpy27-2:~/project/testqosclient/python-octaviaclient$ openstack network qos policy create test | 22:23 |
johnsom | NotFoundException: Not Found (HTTP 404) (Request-ID: req-8ff562d1-4f32-48c3-a9da-f83f74731e60), The resource could not be found. | 22:23 |
johnsom | Same not very useful error when you try to create a policy | 22:23 |
bar_ | Do we have similar run-time resource-availability verifications in octavia code? | 22:25 |
johnsom | Yes | 22:25 |
bar_ | ...similar to what you imply is required. | 22:25 |
bar_ | Can you direct me to such check-point? | 22:26 |
johnsom | https://github.com/openstack/octavia/blob/master/octavia/network/drivers/neutron/base.py#L50 | 22:27 |
bar_ | thx | 22:28 |
*** rcernin has joined #openstack-lbaas | 22:32 | |
*** aojea has joined #openstack-lbaas | 22:33 | |
bar_ | johnsom, do you want me to implement a similar checkpoint in the client? | 22:34 |
johnsom | bar_ Hmm, I'm really on the fence. It will just slow down the happy-path. Plus, will the commands still show up in --help? | 22:35 |
*** jappleii__ has joined #openstack-lbaas | 22:35 | |
johnsom | I guess it's a "nice to have for user experience" kind of thing | 22:35 |
johnsom | Really I think the neutron client should return a nicer message when an extension is missing. | 22:36 |
*** threestrands_ has quit IRC | 22:36 | |
bar_ | and/or... openstackclient should also implement similar checkpoints | 22:37 |
johnsom | Yeah, so, up to you. I'm not going to block your patch over it. If you are motivated I will support you in it | 22:37 |
*** Alex_staf has quit IRC | 22:37 | |
bar_ | johnsom, I will not pursue it at the moment. not as part of this patch at least. | 22:38 |
*** AlexStaf has joined #openstack-lbaas | 22:38 | |
johnsom | Ok, good plan | 22:38 |
johnsom | I think I can quickly test and +2 anyway | 22:38 |
bar_ | johnsom, wo-ho! | 22:39 |
bar_ | johnsom, did you read my private message? | 22:41 |
*** mixos has joined #openstack-lbaas | 22:41 | |
johnsom | didn't get one, try again? | 22:41 |
bar_ | sent you several | 22:42 |
johnsom | Are you registered and logged into freenode? | 22:42 |
bar_ | probably not | 22:42 |
johnsom | Yeah, they changed the security over the weekend to require you to be logged in | 22:42 |
johnsom | There was a bunch of bad spam happening | 22:43 |
bar_ | I see | 22:43 |
bar_ | how do "log in"? | 22:43 |
AlexStaf | Yeah there was wierd stuff | 22:43 |
bar_ | *how do I | 22:43 |
cgoncalves | bar_: /nickserv help register | 22:44 |
johnsom | http://freenode.net/kb/answer/registration | 22:44 |
johnsom | That page has the details | 22:44 |
bar_ | cgoncalves, johnsom, thx | 22:44 |
cgoncalves | (uh, oh! I'm registered for almost 11 years now :D) | 22:45 |
johnsom | Ha | 22:46 |
johnsom | I let mine drop for a long time then set it up again for OpenStack work | 22:46 |
*** AlexStaf has left #openstack-lbaas | 22:47 | |
cgoncalves | johnsom: could you please give https://review.openstack.org/#/c/525355/ some +2 love? :) | 22:49 |
johnsom | Ok, will take a look after I'm done with this qos client | 22:50 |
cgoncalves | sure. it's not urgent for me anyway. thanks | 22:50 |
*** mixos has quit IRC | 22:56 | |
*** belharar_ has joined #openstack-lbaas | 22:58 | |
*** bar_ has quit IRC | 22:58 | |
*** belharar_ has quit IRC | 22:58 | |
*** krypto has quit IRC | 22:58 | |
*** bar_ has joined #openstack-lbaas | 22:58 | |
*** aojea has quit IRC | 23:06 | |
openstackgerrit | Michael Johnson proposed openstack/octavia-tempest-plugin master: Update README https://review.openstack.org/529190 | 23:16 |
openstackgerrit | Michael Johnson proposed openstack/octavia master: ACTIVE-ACTIVE: Initial distributor data model https://review.openstack.org/528850 | 23:26 |
openstackgerrit | Bar RH proposed openstack/octavia-tempest-plugin master: Update README https://review.openstack.org/529190 | 23:29 |
johnsom | Opps, thanks | 23:29 |
bar_ | :-) | 23:30 |
bar_ | johnsom, the rest of them are broken too I'm afraid | 23:31 |
bar_ | I'll fix that.. | 23:31 |
openstackgerrit | Bar RH proposed openstack/octavia-tempest-plugin master: Update README https://review.openstack.org/529190 | 23:33 |
openstackgerrit | Bar RH proposed openstack/octavia-tempest-plugin master: Add missing __init__.py file https://review.openstack.org/529429 | 23:54 |
bar_ | johnsom, ^ | 23:54 |
johnsom | Ok, watching that | 23:55 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!