Wednesday, 2018-06-27

« Tuesday, 2018-06-26 Index Thursday, 2018-06-28 »
*** longkb has joined #openstack-lbaas00:28
openstackgerritMichael Johnson proposed openstack/octavia master: Neutron-LBaaS to Octavia migration tool  https://review.openstack.org/55442000:36
johnsomMore progress, but not done yet00:36
*** blake has joined #openstack-lbaas00:51
*** blake has quit IRC00:55
*** JudeC_ has quit IRC01:06
*** hongbin has joined #openstack-lbaas01:28
openstackgerritJacky Hu proposed openstack/octavia master: fix tox python3 overrides  https://review.openstack.org/57297501:32
*** ramishra has joined #openstack-lbaas01:38
*** sapd has quit IRC02:36
*** sapd has joined #openstack-lbaas02:39
*** annp has joined #openstack-lbaas02:50
*** blake has joined #openstack-lbaas02:51
*** blake has quit IRC02:56
*** hongbin has quit IRC03:11
*** hongbin has joined #openstack-lbaas03:37
openstackgerritAllen proposed openstack/octavia-dashboard master: Show the 'Insert Headers' when listener protocol is 'HTTP' or 'HTTPS'  https://review.openstack.org/56496303:49
*** AlexeyAbashkin has joined #openstack-lbaas04:20
*** hongbin has quit IRC04:24
openstackgerritZhaoBo proposed openstack/octavia master: UDP jinja template  https://review.openstack.org/52542004:29
openstackgerritZhaoBo proposed openstack/octavia master: UDP for [2]  https://review.openstack.org/52965104:29
*** AlexeyAbashkin has quit IRC04:49
*** JudeC_ has joined #openstack-lbaas05:44
*** JudeC_ has quit IRC05:48
*** JudeC_ has joined #openstack-lbaas05:49
*** blake has joined #openstack-lbaas05:51
*** kbyrne has quit IRC06:15
*** kbyrne has joined #openstack-lbaas06:16
*** threestrands has quit IRC06:19
*** issp has joined #openstack-lbaas06:28
*** dmellado has joined #openstack-lbaas06:29
*** yboaron has joined #openstack-lbaas06:31
*** blake has quit IRC06:31
openstackgerritCristian Calin proposed openstack/octavia master: [amphora-agent] add local net to routing table 1  https://review.openstack.org/57799206:34
*** AlexeyAbashkin has joined #openstack-lbaas06:35
*** AlexeyAbashkin has quit IRC06:37
*** yboaron has quit IRC06:38
*** yboaron has joined #openstack-lbaas06:38
*** pcaruana has joined #openstack-lbaas06:44
*** nmanos has joined #openstack-lbaas06:45
*** JudeC_ has quit IRC06:51
*** kobis has joined #openstack-lbaas06:51
*** nmanos has quit IRC07:01
*** pcaruana has quit IRC07:02
*** peereb has joined #openstack-lbaas07:03
*** peereb has quit IRC07:04
*** peereb has joined #openstack-lbaas07:04
*** peereb has quit IRC07:05
*** peereb has joined #openstack-lbaas07:06
*** tesseract has joined #openstack-lbaas07:07
openstackgerritZhaoBo proposed openstack/octavia master: UDP for [2]  https://review.openstack.org/52965107:10
openstackgerritZhaoBo proposed openstack/octavia master: UDP for [3][5][6]  https://review.openstack.org/53939107:10
*** rpittau has quit IRC07:19
*** rpittau has joined #openstack-lbaas07:21
*** JudeC_ has joined #openstack-lbaas07:34
*** issp has quit IRC07:42
*** phuoc has quit IRC07:48
*** phuoc has joined #openstack-lbaas07:49
*** rcernin has quit IRC07:51
*** rcernin has joined #openstack-lbaas07:52
*** pcaruana has joined #openstack-lbaas07:57
*** feimingc_ has joined #openstack-lbaas07:59
*** nmanos has joined #openstack-lbaas08:00
*** issp has joined #openstack-lbaas08:11
openstackgerritCristian Calin proposed openstack/octavia master: [amphora-agent] add local net to routing table 1  https://review.openstack.org/57799208:17
openstackgerrithuangshan proposed openstack/octavia master: Improve resource quota response message  https://review.openstack.org/57831808:23
*** kobis has quit IRC08:26
*** nmanos has quit IRC08:32
*** rcernin has quit IRC08:47
*** nmanos has joined #openstack-lbaas08:47
*** nmanos has quit IRC08:55
cgoncalvesrm_work, hi. still awake? :)08:56
rm_work>_>08:56
rm_workmaybe08:56
*** salmankhan has joined #openstack-lbaas08:57
cgoncalveswanted your input on a review: https://review.openstack.org/#/c/568361/16/neutron_lbaas/db/loadbalancer/loadbalancer_dbv2.py@102708:57
cgoncalvesthe committer says that my comment would be an API change. I don't see why, maybe I'm missing something :S08:57
*** nmanos has joined #openstack-lbaas08:58
rm_workcgoncalves: technically it would change the results that are currently returned in some cases? possibly?08:59
rm_workso they are considering that an api change?08:59
rm_worknot insomuch as the form of the api request/response changes, but the values from a known request would differ after the change09:00
rm_workwhich is really a behavior change more than what I would call an API change ... but09:00
rm_workI can see how the argument could be made09:00
rm_workthough it basically means no bugs like this can ever actually be fixed :/09:00
*** kobis has joined #openstack-lbaas09:01
cgoncalvesrm_work, how? I mean, 'filters' is passed in as argument and right after the patch is updating 'filters' with... 'filters'09:01
rm_worki only looked at a glance but09:02
rm_workit looks like it would change the precedence?09:02
rm_workso right now the one passed in as an arg does *not* have precedence over the filters? but it would after your change09:02
rm_workthough i am honestly not even clear what part of the service this is even affecting09:03
rm_worki have almost intentionally blocked out all knowledge of neutron-lbaas to defend my mind09:03
cgoncalvesah, ok. I see his argument of API change. IMO 'l7policy_id' passed in as argument should always have precedence09:03
cgoncalvesbut updating to what I was suggesting *could* change that yeah09:04
rm_workcgoncalves: careful how deep you probe, for this way madness lies, and those who descend into the depths cannot be recovered09:04
cgoncalvesheh09:04
rm_worksoon, the scourge shall be purged from the land, and we will be safe! but until that day, the ever present danger lurks09:05
rm_workb̵͍̰̟̭͕̦̹e̝̭̩ͅw̮̣̰͈͍̫a҉̫̹r̤̪̲̬̗͞e̗̘̗09:06
cgoncalvesrm_work, soon for some is not so soon for others :(09:07
cgoncalvesok, I've +1'd it09:07
cgoncalvesjohnsom, xgerman_: https://review.openstack.org/#/c/568361/09:07
*** JudeC_ has quit IRC09:12
*** ianychoi has quit IRC09:14
*** ianychoi has joined #openstack-lbaas09:15
*** threestrands has joined #openstack-lbaas09:45
*** threestrands has quit IRC09:45
*** threestrands has joined #openstack-lbaas09:45
*** threestrands has quit IRC09:46
*** threestrands has joined #openstack-lbaas09:47
*** threestrands has quit IRC09:47
*** threestrands has joined #openstack-lbaas09:47
openstackgerritZhaoBo proposed openstack/octavia master: UDP for [2]  https://review.openstack.org/52965109:58
openstackgerritZhaoBo proposed openstack/octavia master: UDP for [3][5][6]  https://review.openstack.org/53939109:58
*** yboaron_ has joined #openstack-lbaas10:01
*** yboaron has quit IRC10:04
*** salmankhan has quit IRC10:06
*** salmankhan has joined #openstack-lbaas10:06
*** nmanos has quit IRC10:09
openstackgerritZhaoBo proposed openstack/octavia master: UDP for [2]  https://review.openstack.org/52965110:13
openstackgerritZhaoBo proposed openstack/octavia master: UDP for [3][5][6]  https://review.openstack.org/53939110:13
*** nmanos has joined #openstack-lbaas10:25
*** nmanos has quit IRC10:25
*** feimingc_ has quit IRC10:26
openstackgerritCristian Calin proposed openstack/octavia master: [amphora-agent] add local net to routing table 1  https://review.openstack.org/57799210:30
*** pcaruana has quit IRC10:31
*** nmanos has joined #openstack-lbaas10:44
*** yboaron has joined #openstack-lbaas11:05
*** yboaron_ has quit IRC11:07
*** kobis has quit IRC11:09
*** kobis has joined #openstack-lbaas11:11
isspHello, just a quick question, I am trying to upgrade de octavia db in a helm pod, and I have two different cases, I updated the db on a virtual machine running without containers and it worked perfectly in queens version, I tried the same but with a loci image (tried two times in latest and in queens) and I see the following error https://pastebin.com/XwPcZG2G any ideas about what am I doing wrong?11:19
*** atoth has joined #openstack-lbaas11:55
*** nmanos has quit IRC12:01
*** nmanos has joined #openstack-lbaas12:02
*** amuller has joined #openstack-lbaas12:14
*** fnaval has quit IRC12:20
*** ispp has quit IRC12:20
*** nmanos has quit IRC12:23
*** longkb has quit IRC12:23
*** fnaval has joined #openstack-lbaas12:32
*** nmanos has joined #openstack-lbaas13:04
*** vegarl has quit IRC13:24
*** vegarl has joined #openstack-lbaas13:26
*** yboaron has quit IRC13:28
*** kobis has quit IRC13:58
*** gans has joined #openstack-lbaas13:59
*** gans has quit IRC14:02
*** kobis has joined #openstack-lbaas14:03
*** nmanos has quit IRC14:06
*** kobis1 has joined #openstack-lbaas14:06
*** kobis2 has joined #openstack-lbaas14:07
*** kobis3 has joined #openstack-lbaas14:07
*** kobis3 has quit IRC14:08
*** kobis has quit IRC14:08
*** kobis1 has quit IRC14:10
*** kobis2 has quit IRC14:11
*** gans has joined #openstack-lbaas14:27
*** threestrands has quit IRC14:30
*** kobis has joined #openstack-lbaas14:33
*** gans has quit IRC14:54
*** kobis has quit IRC15:14
*** kobis has joined #openstack-lbaas15:21
*** peereb has quit IRC15:35
*** dlundquist has joined #openstack-lbaas15:38
johnsomissp I am not sure what is happening there. That database schema version, 0d23e7af0a30 is not a merged Octavia DB revision. It's not clear to me where it would be getting that.16:05
johnsommaybe try an "octavia-db-manage history" and see if that gives you any clues?16:05
*** ramishra has quit IRC16:08
isspI tried and didn't ring any bell, I create another and It works perfectly doing the upgrade..16:14
johnsomOk, yeah, I searched around and I don't see that revision, so not sure where it came from. Glad to hear you were able to resolve the issue16:14
*** issp has quit IRC16:15
*** kobis has quit IRC16:32
*** tesseract has quit IRC16:34
rm_workwait, octavia works with LOCI!?16:47
rm_workthat's ... exciting16:47
rm_worki didn't think it did16:47
rm_workYEAH nice, I see it in the list now!!!16:48
rm_workgreat!16:48
rm_worklook at the company we keep :P16:48
*** kobis has joined #openstack-lbaas16:49
*** kobis has quit IRC16:58
openstackgerritMichael Johnson proposed openstack/octavia master: Fix version discovery for the Octavia API  https://review.openstack.org/55946017:03
*** JudeC_ has joined #openstack-lbaas17:05
*** JudeC_ has quit IRC17:10
*** JudeC_ has joined #openstack-lbaas17:11
*** kobis has joined #openstack-lbaas17:46
*** salmankhan has quit IRC17:53
*** kobis has quit IRC17:56
*** atoth has quit IRC18:00
*** kobis has joined #openstack-lbaas18:48
*** atoth has joined #openstack-lbaas18:54
*** ajun has joined #openstack-lbaas18:58
*** ajun is now known as abaindur18:59
abaindurHi, I'm having some problems building the octavia amphorae image, and completely lost. anyone able to help and some questions?19:02
abaindurI tried to build it setting just a root password, ./diskimage-create.sh -r hunter219:03
abaindurbut it fails after quite some time with following error:19:04
abaindurhttps://gist.github.com/xagent003/8f688f85c7ffdd6d09ff5c175a2f697519:04
abaindurhttps://imgur.com/a/8o5lUyl19:04
abaindursecondly, I noticed the octavia repo has some elements. am I supposed to set DIB_ELEMENTS or DIB_LOCAL_ELEMENTS to this path? I am unfamiliar with some of the env variables mentioned here: https://github.com/openstack/octavia/tree/stable/pike/diskimage-create19:07
*** kobis has quit IRC19:07
*** kobis has joined #openstack-lbaas19:08
johnsomabaindur Hi.  It might be that the image you are building requires more disk space than the default.  Try "diskimage-create.sh -s 3" or more19:10
abainduri'd think it should work with the defaults19:11
abaindureither way i can try that. should i try with 4gb?19:12
johnsomYes, but the OS distributions keep increase the usage inside their images.  We have put recent patches out to fix that.  What version are you using?19:12
*** kobis has quit IRC19:12
johnsomYeah, 3 or more should solve it.19:12
abaindurDo you mean what version is my machine on?19:12
abainduror what image am i trying to build?19:13
johnsomWhat version of the octavia code are you using?19:13
johnsomPike?19:13
abaindurah. yes, latest stable/pike19:13
johnsomYeah, ok, so this patch: https://review.openstack.org/#/c/571822/ was put in to fix that, but a new stable release has not yet be cut that includes it.19:14
abaindurfor the diskimage-builder, I just did a "pip install diskimage-builder", no version specified. I couldn't find any OS branches on their github repo19:14
johnsomYeah, sadly they are not using stable branches19:14
johnsomOtherwise, the default should be fine. You should not need to use those environment variables unless you want to customize the image.19:15
abaindurok thanks! trying with 4 now. might take a while (took at least 15-20 min before failing on this slow dev VM)19:15
abaindurjohnsom: regarding my other question, what all env variables need to be set?19:16
abaindurthe diskimage-builder has some elements, as does octavia. Sorry this would be my first time using the diskimage builder utility and reading about elements19:16
johnsomJust creating a basic image, you should not need to set any of them. They are just there so you can override or customize the image19:16
abaindurwhat is the different betwen ELEMENTS vs. LOCAL_ELEMENTS ?19:17
abaindurjust for curiosity19:17
johnsomNo problem, we are happy to help and answer questions.  The diskimage-builder team also has an IRC channel #openstack-dib if you have diskimage-builder questions we can't answer19:17
abaindurthe octavia dock says:19:17
abaindur"The script will use the version of diskimage-builder installed on your system, or it can be overridden by setting the following environment variables: "19:18
abaindurDIB_REPO_PATH = /<some directory>/diskimage-builder19:18
abaindurDIB_ELEMENTS = /<some directory>/diskimage-builder/elements19:18
abaindurwhat would LOCAL_* be set for?19:18
johnsomYeah, so DIB_ELEMENTS lets you replace the elements used by default in the diskimage-create script.  DIB_LOCAL_ELEMENTS let's you add *additional* local custom elements for the image build19:19
johnsomELEMENTS are the names, ELEMENTS_PATH is the path to the directory that holds them19:19
rm_workabaindur: i do appreciate the password choice :)19:20
rm_workmy password is also *******19:20
johnsomlol19:22
johnsomCrazy that I wrote that script almost four years ago now19:25
*** amuller has quit IRC19:26
abaindurhaha thanks19:28
*** wayt has joined #openstack-lbaas19:29
abaindurjohnsom: thanks. is there any guidelines to elements for amphora? Like what might elements might be useful? Or is the default image good enough in 99% of all cases. I'm not sure what else may be needed in the amphorae image19:30
abainduror is it more for people seeking to build custom images without haproxy and other load balancers?19:31
johnsomabaindur The defaults are good for 99% of the case. The optional settings are just there for companies that need to add things like access control audit, or whatever.19:31
johnsomYou will have a full featured load balancer with those default settings, nothing is disabled or missing.19:32
rm_workthough i will take this moment to *highly recommend* you run at least Queens19:34
rm_workOctavia is cloud-version independent19:34
johnsomYes, true, you can run newer Octavia on older clouds19:34
johnsomUgh, looks like pypi is returning 503's...19:36
johnsomSlack was down, now pypi is returing 503's, seems like I should take a day off19:36
*** wayt has quit IRC19:36
abaindurwhat is missing in pike thats in queens?19:41
*** wayt has joined #openstack-lbaas19:41
rm_workstability :P19:42
abaindurOur neutron is still on pike, and we were still planning on using the neutron lbaas driver/plugin instead of octavia directly19:42
rm_workahh, would DEFINITELY recommend against that19:42
rm_workif at all possible, use octavia directly19:42
johnsomYeah, neutron on pike is fine.  It's fine back to Mitaka at least.19:43
rm_workespecially for a new deployment (not sure if yours is)19:43
johnsomYeah, agreed, if you can, don't use neutron-lbaas. It's deprecated19:43
rm_workand will cause a number of painful problems19:43
abainduri thogutht not until Rocky?19:43
johnsomNo, it went deprecated in Queens19:43
abaindurwe need lbaas driver due to AVI driver which we currently use being in lbaas plugin19:43
abaindurbut there is no avi driver in octavia19:43
johnsomWe will still do bug fixes for a while, but it is deprecated19:43
rm_workit isn't GONE yet, but it has been marked as deprecated19:44
rm_workabaindur: you can use both simultaneously in your cloud19:44
rm_workwe do that19:44
rm_workwe have neutron-lbaas with the a10 driver, and we also run octavia19:44
rm_workand they can be contacted via different endpoints19:44
johnsomFYI: https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation19:46
abainduryeah I saw that, it just seemed like at least until rocky, the neutron-lbaas plugin would call the octavia APIs via the octavia driver. and till then to not use octavia directly19:46
johnsomOh, hmmm, maybe I need to update that page. The intent was to go direct to Octavia starting with Pike19:47
abaindurhttps://docs.openstack.org/octavia/queens/reference/introduction.html19:48
abaindursorry thats where i meant19:48
abaindurIt is important for you to know that Octavia is not necessarily designed as a complete replacement for the Neutron LBaaS project. That is to say, Octavia is designed to “plug in” to Neutron LBaaS in the same way that any proprietary vendor solution would: through a Neutron LBaaS version 2 driver interface. You could think of Octavia as an “open source vendor” for Neutron LBaaS, rather than as a su19:48
abaindurbstitute for Neutron LBaaS. For this reason, we recommend that tenants configure load balancing services with Octavia through the Neutron LBaaS version 2 CLI and API.19:48
abaindurSoon, Octavia will supplant Neutron LBaaS as the load balancing solution for OpenStack.19:48
abaindurgiven that its on the queens documentation page, i assumed the full deprecation would occur in rocky or sometime later19:49
johnsomHmm, I know we updated that doc, but maybe it didn't get into the queens release.  I will take a note of that and make sure it gets updated.19:49
johnsomOh, geez, ok, so we missed that paragraph.19:50
johnsomOpps, ok, will fix that today.19:50
johnsomIt's wrong even in master.19:51
abaindurSO i dont forsee using AVI or octavia in the same deployment. given that what is the difference in terms of API for lbaas? it should be identical, right?19:52
abaindurjust to a different endpoint port?19:52
johnsomOctavia is a super-set of neutron-lbaas API. It adds new features, but is backward compatible with neutron-lbaas19:52
abaindurand if we are using octavia, that would mean we do not even need to install lbaas plugin into neutron or enabled the lbaas service plugin/octavia service provider, etc...19:53
johnsomOh, ok, yeah, it didn't get backported I guess.  Master does have it right: https://docs.openstack.org/octavia/latest/reference/introduction.html19:53
johnsomcores: https://review.openstack.org/57854419:54
cgoncalvescores^2: https://review.openstack.org/#/c/568361/19:55
*** JudeC__ has joined #openstack-lbaas19:56
*** JudeC_ has quit IRC19:57
abaindurjohnsom: It still failed with -s 419:58
abaindurthe diskimage build19:58
abainduri will try on another machine...19:58
johnsomabaindur Hmm, also maybe try with a virtenv and install the requirements.txt20:00
johnsom#startmeeting Octavia20:00
openstackMeeting started Wed Jun 27 20:00:37 2018 UTC and is due to finish in 60 minutes.  The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot.20:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.20:00
*** openstack changes topic to " (Meeting topic: Octavia)"20:00
openstackThe meeting name has been set to 'octavia'20:00
johnsomHi folks!20:00
cgoncalveso/20:00
*** Johnny has joined #openstack-lbaas20:01
johnsomI know Nir is on vacation today, so he won't be joining us20:01
johnsom#topic Announcements20:01
*** openstack changes topic to "Announcements (Meeting topic: Octavia)"20:01
*** Johnny is now known as Guest3644920:01
johnsomJust a friendly reminder, we have a priority review list for Rocky20:01
johnsom#link https://etherpad.openstack.org/p/octavia-priority-reviews20:01
johnsomWe have been making progress, thank you! However we still have more work to do20:02
*** AlexeyAbashkin has joined #openstack-lbaas20:02
rm_worko/20:02
johnsomAlso of note this week, we filed governance patches for upgrade tags20:02
johnsom#link https://review.openstack.org/57796720:02
johnsom#link https://review.openstack.org/57797020:02
johnsomIt looks like we have good support there, so likely in a week or two we will have the supports upgrades tags.20:03
johnsomSpecial shout out to cgoncalves for his work getting us to this point with upgrades20:03
cgoncalvesteam effort!20:04
nmagneziO/20:04
johnsomI think I also need to file for the standard-deprecation tag, which seems to have disappeared during the neutron-lbaas split.  We certainly qualify for that one too20:04
johnsomAny other announcements today?20:05
johnsom#topic Brief progress reports / bugs needing review20:05
*** openstack changes topic to "Brief progress reports / bugs needing review (Meeting topic: Octavia)"20:06
rm_workJust an FYI that apparently LOCI is supporting Octavia now -- just noticed today after someone mentioned they're using those.20:06
johnsomYeah, that is cool.20:06
johnsomWe probably should have a partner projects links page to keep track of this stuff.20:06
cgoncalvessorry for my ignorance. what is LOCI? xD20:06
johnsom#link https://github.com/openstack/loci20:07
johnsomLightweight OCI compatible images for OpenStack Projects20:07
cgoncalvesnice!20:07
johnsomSo, I finished up the "dual amphora down failover" patch. It is up for review.20:08
johnsomI then shifted to reviewing the UDP patches, as that is a feature I would like to get into Rocky.20:08
johnsomStill some work to do there, but good progress.20:08
johnsomWhile I waited on a update cycle with the UDP patches I have started work on the migration tool again.20:09
johnsomI should have it done today. I just have the L7 tables to do and some cleanup work.20:09
nmagneziI provide feedback on that migration tool next week when I'm in office again20:10
nmagneziI'll*20:10
johnsomHow do people feel about testing for that tool?  Is it worth me investing time in creating a periodic gate or would basic testing be good enough?20:10
johnsomTechnically to do it right it would be checking hundreds of fields, which for a one-time-use tool seems a bit much.20:10
cgoncalvesjohnsom, would anyone actually check results of a periodic gate?20:11
*** blake has joined #openstack-lbaas20:11
johnsomI am pretty sure I am the only one that occasionally looks at the periodic gates.....20:11
johnsomSince you can't bookmark it....  It's not easy to glance at20:12
cgoncalvesif you do... all good :)20:12
johnsom#link http://zuul.openstack.org/builds.html20:12
johnsomPipeline is "periodic" project is "openstack/octavia"20:13
johnsomSo, yeah, that was kind of my thought too.  I don't think I will invest time in building a gate for it. I will do a bunch of manual testing local though.  It also has a nice "trial run" setting.20:13
rm_worki mean, something as simple as "create a LB in n-lbaas, run script, use octavia to look at it" should be good enough?20:14
johnsomOnce it's posted for review, if you have environments with LBs running in neutron-lbaas and an Octavia database, you can do the trial run and let me know if anything fails.20:14
cgoncalveswhat about adding a voting job to your patch while it's under review? once it's good, you remove the job and have it merged?20:14
rm_workjust prove at least that the script runs and successfully exits20:14
*** abaindur has quit IRC20:15
johnsomYeah, it's just a trade off of my time.  If you all think a gate is worth it, ok, I will put something together.20:15
nmagnezirm_work +1. I was kinda thinking the same. I was trying to think about corner cases but for the legacy haproxy in namespace we don't even have support for L7 rules (last I checked)20:15
rm_worki think this is only octavia->octavia20:16
nmagneziSo shouldn't be too hard to create bunch of loadbalancers with different configs and migrate them20:16
rm_worknot migrating across providers20:16
johnsomThe work I am finishing is for migrating any provider, but no provider conversion, just straight across20:16
nmagnezibtw20:17
nmagnezi#link https://review.openstack.org/#/c/554420/20:17
johnsomYep, thanks.  Not sure what was up with that requirements thing given I didn't change the main requirements file, but we will see what happens.  Could be the main file is wrong and the new requirements management stuff is not so helpful anymore20:18
johnsomSo what I am hearing is a gate test is valuable to folks, so I will spend a day and set something up.20:20
johnsomAnyone have an other progress updates to share?20:21
johnsom#topic Talk about API versioning/microversioning20:22
*** openstack changes topic to "Talk about API versioning/microversioning (Meeting topic: Octavia)"20:22
johnsomSo I have posted an update to my version discovery patch:20:22
johnsom#link https://review.openstack.org/55946020:22
johnsomThe example output is here:20:22
johnsom#link http://paste.openstack.org/show/724425/20:22
johnsomPlease comment on the patch and if this path works for you, etc.20:23
johnsomThis is another one I want to get into Rocky.20:23
nmagnezi+120:23
xgerman_sorry for being late20:23
johnsomWe have less than a month left to get features into Rocky20:24
johnsom#link https://releases.openstack.org/rocky/schedule.html20:24
nmagnezijohnsom, btw re:periodic gate bookmarks, I think I was able to get this working as a URL: http://zuul.openstack.org/builds.html?pipeline=periodic&project=openstack%2Foctavia20:24
johnsomAny more discussion on versions beyond comments for the patch?20:25
cgoncalvesFYI, cinder also does microversions20:25
johnsomnmagnezi Ha, nice20:25
nmagnezi:)20:25
cgoncalves#link https://docs.openstack.org/cinder/ocata/devref/api_microversion_dev.html20:25
johnsomcgoncalves Yes, a few projects do.20:25
nmagnezicgoncalves, they have something like 3 major version20:26
nmagneziPainful.. :)20:26
cgoncalvesI asked a cinder core for feedback and he said it has been working pretty good for them20:26
cgoncalvesjohnsom, re: output of your patch http://paste.openstack.org/show/724425/20:27
johnsomJust to circle back on why I'm proposing not to jump into microversions right now is by default, if you don't specify a microversion, you always get the oldest API. To me, since so far we are "additive" it seems simpler to go down the path I have proposed.20:27
cgoncalvesit's a big strange having CURRENT as v2.1 but href is v2.020:27
johnsomcgoncalve Strange, but the beauty of it....  grin20:28
rm_workyeah, well20:28
rm_workideally i think we wouldn't have any version in the URL?20:28
* rm_work shrugs20:28
johnsomv2.1 indicates there is an expansion to the API, but since the v2.1 is fully compatible with the v2.0 version it can share a path20:29
johnsomThe alternative is to fork off paths for each dot release, or do the header microversion filter thing20:31
cgoncalvesI'd expect href ending with /v2 then :)20:31
johnsomWe could alias it if you want. We do need to keep /v2.0 for backward compatibility20:32
johnsomWe probably need to figure out how to handle the api-ref too20:32
rm_workdon't people normally just add "available in version 2.1 or greater" or whatever?20:33
rm_workfor new features20:33
johnsomYeah, probably. Part of the trouble here is the API woking group has zero guidelines or tools for this.20:34
rm_workyeah it would be nice if that was like... a field20:34
johnsom#link https://specs.openstack.org/openstack/api-wg/guidelines/discoverability.html20:35
johnsomYeah, it would be nice if the api-ref template had a way to handle that. I will look into how to update the api-ref20:36
johnsomThis publishing practice means that you must write inline information when an API has a change release-to-release. Inline text descriptions are the only way to convey the corresponding release information to the documentation consumer.20:37
johnsomTo quote that doc...20:37
johnsom#link https://docs.openstack.org/doc-contrib-guide/api-guides.html20:37
johnsomSo I guess comment on the patch?  I am open to aliasing /v2 and switching the api-ref over to that if that is cleaner. Or we can keep going down the /v2.0 and versions v2.1, v2.2, etc.20:39
*** abaindur has joined #openstack-lbaas20:40
johnsomOk, I guess I will come up with something.20:42
johnsom#topic Open Discussion20:43
*** openstack changes topic to "Open Discussion (Meeting topic: Octavia)"20:43
cgoncalvesto me aliasing /v2 would make sense but I don't have a strong opinion on this, at least right now. I'd be fine with incremental /v2.x20:43
johnsomOther topics today?20:43
cgoncalvesnot specific to Octavia but I take that many folks have been waiting for it for some time now. Red Hat OpenStack Platform 13 (Queens-based) has been released today and it features Octavia full support20:44
*** AlexeyAbashkin has quit IRC20:45
johnsomWahoo!20:45
xgerman_Wahoo —20:45
johnsomCongratulations folks that worked on OSP 13 support for Octavia.20:45
xgerman_If you ever need to install Octavia on OSP 12 I have some scripts…20:45
nmagnezixgerman_, good luck with that :-)20:45
xgerman_thanks, we will need it20:46
nmagnezixgerman_, or.. just OSP13 ;)20:46
cgoncalvesxgerman_, will you also write an upgrade script when the time comes? :)20:46
xgerman_I hope NOT…20:46
johnsomlol, yeah, upgrade is going to be interesting20:47
johnsomWell, if that is all, I will let us all get back to reviewing patches.20:47
cgoncalvesfear not! we have an upgrade guide upstream now \o/20:47
xgerman_:-)20:48
nmagnezijohnsom, that migration script will help us to move operators towards Octavia's direction. so it has *a lot* of value20:48
nmagnezi:)20:48
johnsomYeah, it's not a "move from old provider x to new provider y", but it is a good first step and will help many folks.20:48
johnsomOk, folks, have a good week!20:49
johnsom#endmeeting20:49
*** openstack changes topic to "Discussion of OpenStack Load Balancing (Octavia) | https://etherpad.openstack.org/p/octavia-priority-reviews"20:49
openstackMeeting ended Wed Jun 27 20:49:30 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)20:49
openstackMinutes:        http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-06-27-20.00.html20:49
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-06-27-20.00.txt20:49
nmagnezio/20:49
openstackLog:            http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-06-27-20.00.log.html20:49
*** JudeC_ has joined #openstack-lbaas20:56
*** JudeC__ has quit IRC20:56
*** kobis has joined #openstack-lbaas20:59
*** abaindur has quit IRC20:59
*** AlexeyAbashkin has joined #openstack-lbaas21:01
*** AlexeyAbashkin has quit IRC21:12
*** abaindur has joined #openstack-lbaas21:13
*** kobis has quit IRC21:25
*** kobis has joined #openstack-lbaas21:25
*** kobis has quit IRC21:30
*** rcernin has joined #openstack-lbaas21:50
rm_workhmm, i am noticing a lot of spam of RMQ issues on my API nodes :/22:18
rm_workhttp://paste.openstack.org/show/724463/22:18
rm_workjohnsom: ^^ if you have any thoughts22:18
rm_workI am not sure what is going on but it's looking somewhat detrimental to performance22:18
*** blake has quit IRC22:18
rm_workmisconfiguration of RMQ? on the octavia side or the rabbit side? >_>22:18
johnsomLooking22:18
*** abaindur has quit IRC22:19
rm_workthat's octavia api service output BTW, i just have it configured for JSON22:19
johnsomOh, hmm, odd22:19
rm_workinstead of normal whatever oslo.log does22:20
johnsomDo you have a haproxy or load balancer in front of your rabbit?22:20
rm_workno22:20
johnsomHmm, ok, I have seen those broken pipe messages when something in the flow times out the flow, like the client timeout in haproxy. That is why I asked22:20
rm_worki have a cluster of three RMQ servers, and i have all three listed in the transport URL... and rabbit is using SSL22:21
johnsomAnd there is a constant stream of this or just every once in a while?22:21
rm_workpretty constant22:22
rm_worklet me see22:22
johnsomI will ask the obvious question, the cert isn't expired on the rabbit host is it?22:22
rm_workheh22:22
rm_workwell, it's still *working* after new connections are created it seems22:22
rm_workso i think no22:22
rm_workthis looks like early closes22:22
johnsomThis is interesting: https://bugs.launchpad.net/oslo.messaging/+bug/165744422:27
openstackLaunchpad bug 1657444 in python-oslo.messaging (Ubuntu Artful) "Can't failover when rabbit_hosts is configured as 3 hosts" [High,Fix released] - Assigned to Felipe Reyes (freyes)22:27
rm_workhmmm22:27
johnsomClaims it keeps trying to go to the down instance22:27
rm_workhmm yeah though his shows failed on login creds or something22:28
rm_workand i think i'd see one of my rabbit nodes as down / the cluster with partitions22:28
rm_workgonna check my rabbit boxes22:29
johnsomAnother interesting thing:22:30
johnsomhttps://ask.openstack.org/en/question/78519/cinder-rabbitmq-timeout-problem-with-multiple-rabbit-hosts/22:30
johnsomNot sure it's smoking gun, but thought I would share22:30
rm_workhmm also seeing this on RMQ hosts22:33
*** abaindur has joined #openstack-lbaas22:33
rm_workhttp://paste.openstack.org/raw/724464/22:34
rm_worka lot... i bet it lines up22:34
rm_workthese two are interesting, but don't quite match22:37
rm_workthough the do illustrate that oslo messaging has ... issues, heh22:37
rm_workjohnsom: http://paste.openstack.org/show/724465/ interesting22:42
rm_worknew error22:42
rm_workjust noticed they're not all identical22:42
*** blake has joined #openstack-lbaas22:44
*** blake has quit IRC22:45
*** fnaval has quit IRC22:53
*** fnaval has joined #openstack-lbaas23:08
*** ianychoi has quit IRC23:16
*** ianychoi has joined #openstack-lbaas23:19
*** kobis has joined #openstack-lbaas23:41
*** abaindur has quit IRC23:42
*** kobis has quit IRC23:46
« Tuesday, 2018-06-26 Index Thursday, 2018-06-28 »

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