Friday, 2017-07-28

*** JudeC has quit IRC00:00
openstackgerritMichael Johnson proposed openstack/python-octaviaclient master: Update python-octaviaclient docs for migration
johnsomDarn requirements changed before we merged that00:04
johnsomWill neeed re-reviews from the cores00:04
*** sshank has quit IRC00:05
johnsomAlso, I have posted the Pike-3 release.  Super thank you to the cores for powering through reviews to get this out.  We did a lot of work for this milestone.   Pike is going to he HUGE!  grin00:06
*** yamamoto has quit IRC00:14
*** yamamoto has joined #openstack-lbaas00:15
*** KeithMnemonic2 has quit IRC00:16
rm_workjohnsom: :P now if you want to help me test via a centos amp...00:17
rm_workpre/post patch ideally00:18
johnsomWe have a gate for that....  Grin00:18
rm_worki'm trying to test *in my env*00:18
rm_workbecause my laptop is fucked now00:18
rm_workif i start a parallels VM, my CPUs all immediately spike to 100% from "kernel_task" and it basically locks up00:18
rm_workand eventually just reboots00:18
rm_workno more local devstack for me00:19
* rm_work dusts off his centos devstack script to do more stacking in the cloud00:19
rm_workjohnsom: but yeah, specifically testing haproxy's response to draining00:20
johnsomI commented on that patch00:20
*** yamamoto has quit IRC00:20
rm_workyour second comment is a fair point00:21
rm_workthe first one...00:21
rm_worki actually had typed up the code to replace it00:21
rm_workand then realized00:21
rm_workthere's literally no point00:21
rm_workwe're handling all documented statuses00:21
rm_workit is effectively a NOOP that takes however many cycles00:22
johnsomBy just logging them?00:22
rm_workI mean look:00:22
rm_workjohnsom: ^^00:25
rm_workit's like00:25
rm_workseriously why00:25
rm_worksorry that's supposed to be HAPROXY_MEMBER_UP_STATUSES00:26
rm_workand what happens because of that00:26
rm_workis if we DO get a different status from HAProxy00:26
rm_workit's masked00:26
rm_workand makes it: A) impossible to track down; B) needs a new version of the amp to fix00:27
rm_workwhereas if we just let it push statuses through and we catchall on the receiving side... we can log weird statuses, and do something about that00:27
johnsomHmmm, fair point.  So you are arguing that we should do that on the controller side?00:28
rm_workand I did00:29
rm_workit's not even new00:29
rm_workthe log was already there00:29
rm_workjust impossible to hit since we sanitized on the amp side00:29
rm_workline 18500:29
rm_worki just had to add the ability to deal with DRAIN00:30
johnsomWhat I am trying to solve is if haproxy sends MAINT, the member is DOWN from a customer perspective.  With the code I see in it will just log it and leave it "ONLINE" for the user00:30
rm_workso we should deal with MAINT00:30
rm_worknot hide it00:30
johnsomRight, I think that is what I am arguing for too.00:31
rm_workok so MAINT is a possible status?00:31
rm_workis that DOWN?00:31
johnsomI am fine moving it to the controller.  I just think we need to enhance that logic.00:31
rm_workso... MAINT too?00:32
johnsomProblem is, HAProxy doesn't reallly document them all.  I had to dig into code to find what I did in the comment.00:32
johnsomMAINT, NOLB, MAINT (resolution), and whatever else is hidden in there00:32
johnsomI was trying to find a header that had them listed, but....00:33
rm_workwe could catchall with "UNKNOWN" along with the log00:33
rm_worki mean, time to dig through c code?00:33
rm_workbedis: o/00:34
johnsomYeah, that is what I did00:34
rm_workah rofl00:34
rm_workTHAT kind of header00:34
johnsomHe doesn't work there anymore00:34
rm_worki know00:34
rm_workbut he'd still know :P00:34
rm_workok so I'll allow for MAINT, and for anything else I'll use UNKNOWN and log00:35
johnsomgrep ST_F_STATUS stats.c00:35
johnsomOk, that is probably fair.  Will probably be a pain in our behind, but fair00:35
rm_workI'll call UNKNOWN = DOWN for neutron-lbaas00:37
rm_workalso MAINT = DOWN00:37
johnsomFor sure00:37
rm_workI wonder what those statuses mean for pools...00:40
rm_workwell whatever, we carry that status forward, right?00:40
johnsomI think we just query haproxy for the member records, then calculate the pool status ourselves.   Listener does have a different set of status, like FULL , etc.00:41
johnsomHmmm, ok, no the comment says we query pool there too00:42
rm_workit appears to come back00:43
rm_workthis is one of the last parts that I hadn't touched very much, lol00:43
johnsomI had at one point.00:44
johnsomI suspect pool (backend) is UP/DOWN/MAINT maybe NOLB00:45
rm_workMAINTENANCE | - The member is down for maintenance00:46
rm_workis that right?00:46
johnsomYeah, admin state down if we did it with the disable tag00:46
johnsomOh, I also see "DOWN (agent)"00:46
rm_workhmm i wonder if that's why my admin-state-down is also not working00:46
rm_worki need to poke at that00:46
johnsomThough we aren't using agent at the moment00:46
johnsomIs it not working, or is it just not reporting right?00:47
*** JudeC has joined #openstack-lbaas00:47
*** yamamoto has joined #openstack-lbaas00:48
johnsomMy money is on that it is working, but we aren't reporting it right which is the bug we talked about yesterday that I will fix when I get back, tuesday-ish00:48
rm_workoh, no00:48
rm_workwe PULL the member00:48
rm_workthat's how we make it "down"00:48
johnsomRight, currently00:48
rm_workwait, what bug are you aware of with it reporting?00:48
openstackLaunchpad bug 1706828 in octavia "admin_state_up == false, member still ONLINE" [Critical,Triaged] - Assigned to Michael Johnson (johnsom)00:48
rm_workyeah not my issue00:49
johnsomIt pulls the member, so it does go offline, but the status doesn't update right00:49
johnsomShould I put a bug in to convert to this new "client" model with barbican?00:54
rm_workwell i guess so00:55
rm_worksince we SHOULD convert00:55
rm_workbut we need to wait for the bug I put in to close00:55
rm_workor... actually I guess we don't00:55
rm_workgrrr why the hell did pyroute2 work fine before in unit tests and now it breaks00:56
rm_workaccording to everything i found, it NEVER worked on OSX00:56
rm_workbut it totally did until yesterday00:56
rm_workbut, now i can't run unit tests on OSX00:56
johnsomI don't know.  sanfern had the same thing happen.  It's a MacOS thing00:56
rm_workwell it DID work00:56
rm_worki never had problems00:57
*** catintheroof has quit IRC00:57
rm_workuntil i rebuilt yesterday00:57
*** leitan has quit IRC01:02
openstackLaunchpad bug 1707091 in octavia "Need to convert to barbican "Client" instead of importing modules" [High,Triaged]01:03
rm_workit's not even that01:03
rm_workneed to just change the location we import from01:03
rm_workthe client based imports were also removed01:03
johnsomWell, I think the go-forward way is to use the client do-bob to pick a version01:03
rm_workif you saw MY bug, they literally moved *every* entrypoint, even Castellan was broken01:03
rm_workhmm k01:04
openstackgerritJude Cross proposed openstack/octavia-tempest-plugin master: [WIP] Create scenario tests for Octavia
johnsomAt least that is how I read it01:04
*** leitan has joined #openstack-lbaas01:05
johnsomWe didn't get our cascading ACLs either, so we can't do the cool create listener solves your container access issue....01:06
rm_workwell, as someone said, we can technically do the ACLs on their behalf :/01:08
rm_workduring the request01:08
rm_workwhich is super gross to me01:08
rm_workbut might be a better *user experience*01:08
rm_workwhile still sacrificing SLIGHTLY less security than alternatives01:08
johnsomOnly if we make a ton of calls, but I thought even that didn't work as we didn't have all of the object IDs and you couldn't "discover" them via the API01:09
johnsomThe on behalf is my idea/plan.  Just need the API on barbican side to make it happen01:09
*** harlowja has quit IRC01:10
johnsomMaybe my understanding is wrong and from a container you can list all of the objects...  Still, too many API calls IMO01:10
openstackgerritAdam Harwell proposed openstack/octavia master: Properly handle more states from HAProxy health messages
rm_workjohnsom: ok there we go01:10
rm_workyeah you can discover them from the container01:10
rm_workjust can't "get the data"01:11
rm_workbut the container gives the object ids01:11
johnsomWell, if we can discover them, we can use the user's token to authorize our service account01:11
rm_workin fact that's really all a container contains :P01:11
*** leitan has quit IRC01:11
rm_workwe could do that01:11
johnsomWe should do that01:11
rm_workgross IMO, but I won't -2 :/01:11
johnsomYeah, but less gross than people blanket RBACing in the octavia account or having users run other commands to authorize an service account they don't know01:12
*** catintheroof has joined #openstack-lbaas01:18
rm_workoff for a bit01:18
rm_workmovie night01:18
*** sanfern has quit IRC01:19
*** catintheroof has quit IRC01:25
openstackgerritJude Cross proposed openstack/octavia-tempest-plugin master: [WIP] Create scenario tests for Octavia
*** leitan has joined #openstack-lbaas01:37
*** yamamoto has quit IRC01:53
openstackgerritJude Cross proposed openstack/octavia-tempest-plugin master: [WIP] Create scenario tests for Octavia
*** cpuga has joined #openstack-lbaas02:45
*** cpuga has quit IRC02:54
*** armax has quit IRC03:27
*** armax has joined #openstack-lbaas03:36
*** sanfern has joined #openstack-lbaas03:37
*** armax has quit IRC03:43
*** armax has joined #openstack-lbaas03:43
*** armax has quit IRC03:44
*** armax has joined #openstack-lbaas03:44
*** armax has quit IRC03:44
*** yamamoto has joined #openstack-lbaas03:48
*** leitan has quit IRC03:48
*** leitan has joined #openstack-lbaas03:49
*** cpuga has joined #openstack-lbaas03:51
*** yamamoto_ has joined #openstack-lbaas03:51
*** leitan_ has joined #openstack-lbaas03:52
*** leitan has quit IRC03:52
*** yamamoto has quit IRC03:53
*** yamamoto has joined #openstack-lbaas03:58
*** cpuga has quit IRC03:58
*** yamamoto_ has quit IRC03:58
*** leitan_ has quit IRC04:03
*** yamamoto_ has joined #openstack-lbaas04:16
*** yamamoto has quit IRC04:17
*** links has joined #openstack-lbaas04:20
*** yuanying has quit IRC04:28
*** amotoki_ has joined #openstack-lbaas04:29
*** harlowja has joined #openstack-lbaas04:32
*** yamamoto has joined #openstack-lbaas04:40
*** yamamoto_ has quit IRC04:41
*** aojea has joined #openstack-lbaas04:41
*** yuanying has joined #openstack-lbaas04:42
*** aojea has quit IRC04:46
*** yamamoto has quit IRC04:51
*** yamamoto has joined #openstack-lbaas04:53
*** cpuga has joined #openstack-lbaas04:56
sanfernHi johnsom , can we customize interface file in disk image-builder what we use in amphora?04:56
johnsomNetwork interface file?04:57
johnsomYes, to some degree.  Most of it should come in automatically from neutron, but we do have jinja templates for those files.04:58
johnsomWhat were you looking to change?04:58
sanfernwhat I observe is when we have net ipv6 only then amphora boots up and has ipv4 interface in the file, so amphora doesn't get ip assigned and controller cannot reach the amphora instance05:00
*** cpuga has quit IRC05:00
*** yamamoto has quit IRC05:01
johnsomHmm, that is created by cloud-init, we can't customize that05:01
johnsomThough it points to something wrong in your configuration05:01
sanfernif cloud-init is not assigning ip to a interface while booting what may be reason,05:04
johnsomSo, on nova boot, we tell nova the network to add an interface on.  Assuming that neutron network is only IPv6, nova should tell cloud-init, via config drive, how the interface needs to be configured.  This can be DHCP, slaac, or static ipv4 or ipv6 addresses depending on how the network is setup in neutron.05:05
*** aojea has joined #openstack-lbaas05:05
johnsomThat box you see on boot from cloud-init, that is where it writes out that interface file in the OS.05:05
johnsomTo debug....05:05
johnsomI guess, if you can get onto the instance, I would mount the config drive (I think it's just /dev/sr0 but it's been a while since I debugged config drive/cloud-init) and take a look at all of the configuration metadata stored there.05:06
johnsomAlso, check the cloud-init logs in /var/log, they should tell you what cloud-init decided05:07
sanfernok johnsom , thanks05:08
johnsomThis is an odd one since I booted up an amp with IPv6 when you asked a question before and it was succesful05:08
johnsomCloud-init docs are here:
johnsomThough I have found them only slightly useful05:09
johnsomThis section:
*** ssmith has joined #openstack-lbaas05:16
rm_worksanfern: i customize my net slightly05:20
rm_worklet me find the patch05:20
openstackgerritJude Cross proposed openstack/octavia-tempest-plugin master: [WIP] Create scenario tests for Octavia
*** JudeC has quit IRC05:21
rm_workvery minor05:21
rm_workbut I have to make the netmask constant05:21
rm_workbecause of the way our FLIPs work05:21
rm_work(this is inside the netns tho, for the VIP)05:21
rm_workso maybe not the same thing05:22
sanfernrm_work, api_server templates comes into pic after amphora boots up and have accessible ipv6 interface05:23
rm_workyeah ok05:24
rm_workso you don't even get an accessible interface05:24
rm_workthen yes as johnsom said, that isn't the amp image really, that's supposed to be set up by cloud-init05:24
rm_workcan you get into the VM via Spice or some out of band console?05:24
sanfernbut in my case initial boot up will not get assigned with ipv6 but neutron assigns IP05:24
sanfernI am able to get into instance05:25
rm_workok so you can see what's going on05:25
rm_workso you give it a management network that has ipv6 but it assigns an ipv4?05:25
sanfernin interface file has -iface ens3 net manual \n mtg 150005:26
sanfernIf I change this into - auto ens3 \n iface ens3 inet6 auto then reboot the instance it will get the ip05:27
*** harlowja has quit IRC05:28
sanferncloud-init logs shows 0- writing /etc/network/interfaces.d/50-cloud-init.cfg and nothing else in logs about network05:29
sanfernrm_work - no ip's will be assigned at all05:31
rm_workwell you can try changing it in the elements05:31
rm_worki do something ... similar too05:32
rm_worksanfern: ^^ that is how I disable DHCP on my boxes05:32
rm_workbut I think you could do something similar to make that file have "auto"05:33
rm_workjust do some sed magic05:33
rm_worki have ... 5 local patches to octavia05:34
rm_workthose are two of them05:34
*** kobis has joined #openstack-lbaas05:34
johnsomYou should not have to do that.  Cloud init should handle it05:35
johnsomSomething is wrong with the neutron or nova config is my guess05:35
*** kobis has quit IRC05:37
sanfernI am running newton neutron and nova05:37
*** aojea has quit IRC05:37
rm_workjohnsom: well, in our case, we do different shit05:38
johnsomYeah, so cloud init didn't get the neutron config05:38
rm_workyeah in his case, probably something is broken there05:38
rm_workunless the way his network is set up is that it relies on dhcp05:38
rm_workand the images are expecting cloud-init to do magic05:38
rm_workbut their cloud-init doesn't do that05:38
rm_workit's *possible* the network is set up that way right?05:38
johnsomEven if it was dhcp, the int would be up if cloud init got anything05:39
rm_workit sounds like the default config in the amp is to NOT use dhcp?05:39
rm_workin ubuntu or whatever they're running?05:39
rm_worki'm in centos and it tries to dhcp but we don't have dhcp so it hangs for like 5m lol05:39
johnsomThe default get overwritten by cloud init05:40
rm_workunless your network doesn't rely on cloud-init maybe?05:40
* rm_work shrugs05:40
rm_workmaybe that's un-possible05:40
*** aojea has joined #openstack-lbaas05:40
johnsomIt totally overwrites the file05:40
johnsomIt is likely a config issue in nova or neutron05:41
*** harlowja has joined #openstack-lbaas05:41
johnsomOr bug in newton05:41
rm_worki mean, what happens via cloud-init on some OTHER random VMs in your env05:42
johnsomBut I am pretty sure we had ipv6 lb-mgmt-net working in mitaka05:42
rm_workit should have yes05:42
rm_workbut it seems like cloud-init just isn't running anything?05:42
rm_workwhich wouldn't be our fault05:42
sanfernAnyone is using having only IPv6 in the environment05:42
rm_workwe have NO ipv6 :(05:42
rm_workcompletely disabled05:43
rm_workvery sucky05:43
sanfernwe also want lb-mgmt-net to be ipv605:44
*** cpuga has joined #openstack-lbaas05:56
johnsomYeah, ipv6 is the best for mgmt net05:59
*** cpuga has quit IRC06:01
sanfernjohnsom and rm_work I see neutron is applying net config cloud-init.logs06:03
sanferni.e. ipv406:03
*** oomichi has quit IRC06:05
*** yuanying has quit IRC06:05
*** oomichi has joined #openstack-lbaas06:06
*** yuanying has joined #openstack-lbaas06:06
*** aojea has quit IRC06:06
*** yuanying_ has joined #openstack-lbaas06:07
*** yuanying has quit IRC06:10
*** oomichi has quit IRC06:10
*** oomichi has joined #openstack-lbaas06:11
*** rcernin has joined #openstack-lbaas06:15
*** sticker_ has quit IRC06:23
*** yamamoto has joined #openstack-lbaas06:36
*** yamamoto has quit IRC06:44
*** yamamoto has joined #openstack-lbaas06:45
*** harlowja has quit IRC06:48
*** cpuga has joined #openstack-lbaas06:57
*** cpuga_ has joined #openstack-lbaas07:00
*** cpuga has quit IRC07:02
*** oomichi has quit IRC07:05
*** cpuga_ has quit IRC07:06
*** oomichi has joined #openstack-lbaas07:06
*** aojea has joined #openstack-lbaas07:22
*** amotoki_ has quit IRC07:24
*** yamamoto has quit IRC07:25
*** yamamoto has joined #openstack-lbaas07:27
*** gcheresh_ has joined #openstack-lbaas07:31
*** amotoki_ has joined #openstack-lbaas07:36
*** amotoki_ has quit IRC07:40
*** cristicalin has joined #openstack-lbaas07:41
*** amotoki_ has joined #openstack-lbaas07:44
*** JudeC has joined #openstack-lbaas07:52
*** ssmith has quit IRC07:57
*** yamamoto has quit IRC07:58
*** amotoki_ has quit IRC07:58
*** yamamoto has joined #openstack-lbaas07:59
*** cristicalin has quit IRC08:00
*** strigazi_ is now known as strigazi08:04
*** yamamoto_ has joined #openstack-lbaas08:13
*** yamamoto has quit IRC08:16
*** openstackgerrit has quit IRC08:18
*** openstackgerrit has joined #openstack-lbaas08:22
openstackgerritJude Cross proposed openstack/octavia-tempest-plugin master: [WIP] Create scenario tests for load balancers
*** JudeC has quit IRC08:23
*** yuanying_ has quit IRC08:35
*** yuanying has joined #openstack-lbaas08:35
*** yuanying has quit IRC08:35
*** yuanying has joined #openstack-lbaas08:36
*** cpuga has joined #openstack-lbaas09:03
*** cpuga has quit IRC09:07
*** cristicalin has joined #openstack-lbaas09:26
*** cristicalin has quit IRC09:37
*** sanfern has quit IRC09:54
*** sanfern has joined #openstack-lbaas09:54
*** sanfern has quit IRC10:23
*** yamamoto_ has quit IRC10:40
*** sanfern has joined #openstack-lbaas10:59
*** cristicalin has joined #openstack-lbaas11:15
*** yamamoto has joined #openstack-lbaas11:19
*** cristicalin has quit IRC11:20
*** yamamoto has quit IRC11:29
*** apuimedo has joined #openstack-lbaas11:37
*** AlexeyAbashkin has joined #openstack-lbaas11:40
*** AlexeyAbashkin has quit IRC11:47
*** catintheroof has joined #openstack-lbaas11:48
*** yamamoto has joined #openstack-lbaas11:51
*** rcernin has quit IRC11:55
*** catintheroof has quit IRC12:14
*** dosaboy has quit IRC12:14
*** rcernin has joined #openstack-lbaas12:16
*** strigazi is now known as strigazi_AFK12:20
*** cristicalin has joined #openstack-lbaas12:42
*** catintheroof has joined #openstack-lbaas12:50
*** cristicalin has quit IRC12:53
*** dosaboy has joined #openstack-lbaas12:57
*** yamamoto has quit IRC13:05
*** cpuga has joined #openstack-lbaas13:06
*** cpuga has quit IRC13:10
*** links has quit IRC13:16
*** bzhao has quit IRC13:29
*** bzhao has joined #openstack-lbaas13:29
*** yamamoto has joined #openstack-lbaas13:29
*** rcernin has quit IRC13:38
*** ssmith has joined #openstack-lbaas13:40
*** cpusmith has joined #openstack-lbaas13:41
*** ssmith has quit IRC13:45
*** sanfern has quit IRC13:50
*** sanfern has joined #openstack-lbaas13:50
*** strigazi_AFK is now known as strigazi_OFF13:58
*** rcernin has joined #openstack-lbaas14:01
*** yamamoto has quit IRC14:12
*** yamamoto has joined #openstack-lbaas14:12
*** AlexeyAbashkin has joined #openstack-lbaas14:18
*** armax has joined #openstack-lbaas14:26
*** atoth has quit IRC14:29
*** aojea has quit IRC14:36
*** harlowja has joined #openstack-lbaas14:51
*** cpuga has joined #openstack-lbaas15:07
*** cpuga has quit IRC15:12
*** rcernin has quit IRC15:13
*** fnaval has joined #openstack-lbaas15:15
*** fnaval has quit IRC15:15
*** fnaval has joined #openstack-lbaas15:16
*** links has joined #openstack-lbaas15:24
*** Alex_Staf has joined #openstack-lbaas15:40
*** aojea has joined #openstack-lbaas15:46
*** aojea has quit IRC15:50
*** harlowja has quit IRC15:51
*** Alex_Staf has quit IRC15:51
*** Alex_Staf has joined #openstack-lbaas15:54
*** yamamoto has quit IRC15:59
*** yamamoto has joined #openstack-lbaas15:59
*** yamamoto has quit IRC15:59
apuimedojohnsom: hi. Is there some way to configure octavia to detect if the destination subnet is routable from the VIP so that no port is created in the member subnet?16:06
*** aojea has joined #openstack-lbaas16:06
apuimedoOr even some way to disable the L2 mode altogether16:07
*** cpuga has joined #openstack-lbaas16:08
xgerman_apiuimedo I don’t think so. It will compare subnet ids and pluf the ones missing16:09
xgerman_please file a bug in Lauchpad for ojr consideration16:09
*** gcheresh_ has quit IRC16:09
*** aojea has quit IRC16:10
*** cpuga has quit IRC16:13
apuimedoxgerman_: I'm just adding octavia support for kuryr-kubernetes16:14
apuimedoand I was trying different options16:14
apuimedoso what I do now is I just specify as member --subnet the subnet of the VIP16:14
apuimedoso that no plugging happens16:15
xgerman_yeah, that works ;-)16:15
apuimedoin the Octavia design documentation it said that if subnet ID was not given it assumed l3 connectivity16:15
apuimedobut it seems subnet_id is a mandatory field for the lbaasv2 api16:15
apuimedo(or at least the CLI)16:15
xgerman_yeah, we probably didn’t get around implementing that — so if you file a bug we will get to it ;-)16:16
apuimedoxgerman_: very well16:17
johnsomYes, when the member is created use the same subnet id as the vip16:17
apuimedojohnsom: right. That's what I do16:18
xgerman_but it would be nice if we would fix it/be consistent with the docs16:18
apuimedoI was just wondering if I could save myself the trouble of retrieving the vip subnet id16:18
apuimedojohnsom: is the containerized/k8s compute driver development stopped?16:19
apuimedoI remember talk about nova-lxd in Atlanta16:20
xgerman_we lost the person working on that but it’s still on our roadmap16:21
*** armax has quit IRC16:21
apuimedoxgerman_: I have some design for it based on Kubernetes16:21
johnsomYeah, the developer we had working on it is no longer working on OpenStack.   We will continue, just had to shift priorities due to the reduces team size16:22
apuimedogood thing is, it gets rid of the control plane network, reduces a lot the need for the amphorae health monitor, etc16:22
apuimedoby reusing kubernetes pieces16:22
johnsomApuimedo curious about how keepalived would work with k8s16:22
xgerman_we actually like those pirces ;-)16:23
apuimedojohnsom: in my design it is handled by a sidecar container16:23
apuimedoxgerman_: the less code to maintain the better16:23
*** gcheresh_ has joined #openstack-lbaas16:23
*** leitan has joined #openstack-lbaas16:23
johnsomHmm, well, if you have the time to develop we will support you in Queens16:24
apuimedojohnsom: thanks16:24
*** aojea has joined #openstack-lbaas16:24
apuimedoI'll share the document before Denver (this time I can't attend)16:24
xgerman_sure K8 would take care of a big chink of our control plane…16:24
apuimedoxgerman_: yes. I plan some things that may be controversial16:25
johnsomSeems optimistic IMO16:25
xgerman_probably we would need to be an operator16:25
apuimedolike getting rid of the haproxy socket16:25
apuimedoand use configmaps16:25
apuimedobut of course, the amount of changes on the proposal are not all or nothing16:26
johnsomSounds like writing up a spec would be a good start16:26
johnsomHelp us with the vision16:26
xgerman_mmh, not sure how replacing the socket with a configmap would work — I can see a metrics/prometheus sidecar16:26
xgerman_but spec would be good16:27
*** armax has joined #openstack-lbaas16:28
apuimedoxgerman_: well, there's two options there16:28
apuimedoone option to keep the socket is you have a sidecar that sees the configmap changes and uses the socket as is done now16:28
apuimedothe other is to just use the configmap as the haproxy configuration16:29
apuimedowith rollouts16:29
apuimedo(two options I thought about, likely there's more)16:30
apuimedojohnsom: it should end up in a spec, agreed on that16:30
xgerman_well, you are replacing our agent with the configmap16:30
xgerman_got t16:30
xgerman_I thought you meant the haproxy stats socket…16:31
apuimedono, no16:35
apuimedothe agent16:35
apuimedothe stats, as you said, could very well be prometheus I guess16:36
*** JudeC has joined #openstack-lbaas16:41
*** openstackstatus has quit IRC16:41
*** openstack has joined #openstack-lbaas16:46
*** catinthe_ has joined #openstack-lbaas16:54
*** harlowja has joined #openstack-lbaas16:54
*** harlowja_ has joined #openstack-lbaas16:55
*** Alex_Staf has quit IRC16:56
*** catintheroof has quit IRC16:58
*** harlowja has quit IRC16:59
*** yamamoto has joined #openstack-lbaas17:00
*** leitan has quit IRC17:00
*** leitan has joined #openstack-lbaas17:02
*** leitan has quit IRC17:03
*** cpuga has joined #openstack-lbaas17:09
*** yamamoto has quit IRC17:10
-openstackstatus- NOTICE: The Gerrit service on is being taken offline for roughly 5 minutes to perform a database backup and reconfiguration17:12
*** cpuga has quit IRC17:13
*** junbo has quit IRC17:15
*** tongl has joined #openstack-lbaas17:23
*** JudeC has quit IRC17:28
*** openstackgerrit has quit IRC17:33
*** gcheresh_ has quit IRC17:41
*** aojea has quit IRC17:59
*** fnaval has quit IRC18:03
*** aojea has joined #openstack-lbaas18:05
*** catinthe_ has quit IRC18:08
*** cpuga has joined #openstack-lbaas18:10
*** catintheroof has joined #openstack-lbaas18:10
*** openstackstatus has quit IRC18:11
*** openstack has joined #openstack-lbaas18:15
rm_workapuimedo: err wait18:24
rm_workapuimedo: I do not have to specify the subnet on a member create18:24
rm_worki bet neutron-lbaas is bugged18:24
rm_workand it's a required field there when it shouldn't be18:24
rm_workin Octavia's LBaaSv2 API, it is definitely not mandatory to specify a subnet-id on member18:24
rm_workjohnsom: ^^18:24
*** amotoki is now known as amotoki__18:28
*** kobis has joined #openstack-lbaas18:30
*** tongl has quit IRC18:33
*** kobis has quit IRC18:33
*** kobis has joined #openstack-lbaas18:39
*** openstackstatus has quit IRC18:42
*** openstack has joined #openstack-lbaas18:46
*** kobis has quit IRC18:51
*** rtjure has quit IRC18:58
*** sshank has quit IRC19:07
*** kobis has joined #openstack-lbaas19:07
*** gcheresh_ has joined #openstack-lbaas19:08
*** sshank has joined #openstack-lbaas19:17
*** rtjure has joined #openstack-lbaas19:17
*** rtjure has quit IRC19:19
*** rtjure has joined #openstack-lbaas19:19
*** rtjure has quit IRC19:19
*** sshank has quit IRC19:20
*** rtjure has joined #openstack-lbaas19:20
*** rtjure has quit IRC19:21
*** rtjure has joined #openstack-lbaas19:21
*** rtjure has quit IRC19:23
*** rtjure has joined #openstack-lbaas19:24
*** rtjure has quit IRC19:26
*** rtjure has joined #openstack-lbaas19:27
*** rtjure_ has joined #openstack-lbaas19:27
*** rtjure has quit IRC19:29
*** rtjure has joined #openstack-lbaas19:29
*** rtjure_ has quit IRC19:29
*** rtjure has quit IRC19:29
*** aojea has quit IRC19:34
*** openstackgerrit has joined #openstack-lbaas19:38
openstackgerritKaitlin Farr proposed openstack/octavia master: Clean up python-barbicanclient imports
*** sshank has joined #openstack-lbaas19:40
*** sshank has quit IRC19:45
*** sshank has joined #openstack-lbaas19:58
apuimedorm_work: that's great to know20:02
apuimedorm_work: and yes, neutron-lbaas has a test that asserts that not passing the subnet raises20:02
rm_workwhat version are you on20:03
rm_workwe might be able to call that a bug and backport a fix20:03
rm_workI don't think anything bad happens if we remove that requirement20:03
rm_workaugh right, johnsom is traveling20:03
rm_workmaybe xgerman_ can remember20:03
rm_workor is he still on PTO?20:03
rm_worksometimes i feel like i'm the only one here <_<20:04
rm_worki think I don't take PTO enough20:04
*** catintheroof has quit IRC20:08
*** cpuga has joined #openstack-lbaas20:11
*** cpuga has quit IRC20:16
*** dayou2 has joined #openstack-lbaas20:26
*** dayou1 has quit IRC20:28
*** kobis has quit IRC20:35
*** kobis has joined #openstack-lbaas20:37
*** kobis has quit IRC20:37
*** kobis has joined #openstack-lbaas20:40
apuimedorm_work: I was checking master20:44
apuimedosame boat here. only one working at 1 or 2 am20:45
apuimedo(now it's not even 11pm though20:45
rm_workapuimedo: yeah but i mean between their last three vacations each i have not had a vacation, lol20:45
rm_workapuimedo: so you are running master?20:45
apuimedorm_work: I am20:45
rm_workif you're running master...20:46
apuimedowhen developing20:46
rm_workjust don't use neutron-lbaas20:46
rm_workyeah i meant in your real prod env20:46
apuimedorm_work: I'm readying kuryr-kubernetes pike release20:46
apuimedoso as long as something is in Pike...20:47
apuimedorm_work: I thought neutron-lbaas was necessary for this to work20:47
apuimedoin the octavia local.conf samples it is there20:47
rm_workhah yeah20:47
rm_workso as of *Pike*20:47
rm_workyou don't need it at all20:47
rm_workjust use Octavia20:47
rm_workthat's how we're deployed here20:47
rm_workbut I don't know how any of the deployment solutions are using it...20:48
rm_workI wrote my own deployment stuff (also to k8s)20:48
rm_workusing neutron-lbaas if you are able to run Octavia's Pike release (or `master`) is really ... bad20:48
rm_workyou're doubling your effort (deploying two projects) so you can use neutron-lbaas (a worse project) to communicate with Octavia :P20:49
*** tongl has joined #openstack-lbaas20:54
*** kobis has quit IRC20:55
*** kobis has joined #openstack-lbaas20:55
*** kobis has quit IRC20:55
*** gcheresh_ has quit IRC20:59
*** KeithMnemonic has joined #openstack-lbaas21:05
openstackgerritOpenStack Release Bot proposed openstack/python-octaviaclient master: Update reno for stable/pike
*** yamamoto has joined #openstack-lbaas21:08
apuimedorm_work: do you have an example devstack local.conf without neutron-lbaas?21:11
rm_workI deploy with that21:12
rm_workI run stackme.sh21:12
rm_workyou can kinda see21:12
*** cpuga has joined #openstack-lbaas21:12
rm_workbut you can look at the local.conf there21:12
*** yamamoto has quit IRC21:12
apuimedorm_work: thanks :-)21:14
apuimedorm_work: anything that helps me shorten deploy time and drops the silly 'specify subnet' restriction21:14
apuimedois great21:14
apuimedorm_work: python-octaviaclient?21:15
rm_workyeah i absolutely don't recommend using n-lbaas21:15
rm_workthere's other shitty bits too21:15
apuimedodoes that allow me to use openstack load balancer etc21:15
apuimedorm_work: oh. I love shitty bits21:16
apuimedosome examples?21:16
*** cpuga has quit IRC21:16
*** yamamoto has joined #openstack-lbaas21:16
*** yamamoto has quit IRC21:20
rm_workyou're dealing with two DBs21:21
rm_workso octavia is Truth and n-lbaas gets updates... sometimes21:21
rm_workit gets out of sync easily21:21
rm_workand we have to use the stupid event_streamer thing to try to keep it synced21:21
rm_workit's just dumb21:21
rm_workyou can disable the event_streamer in your octavia config once you don't have n-lbaas21:22
*** aojea has joined #openstack-lbaas21:26
apuimedorm_work: good to know21:30
apuimedothanks a lot for all these tips21:30
xgerman_rm_work sorry for abandoning you. The RAX requires me to submit a marriage certificate to insure my wife… so having everything still in boxes I thought let’s do a quick jaunt to the county clerk… and 3 hours later I amback21:31
xgerman_apuimedo I also wrote a proxy which send every request you make to n-lbaas straight to Octavia bypassing their DB21:31
*** tongl has quit IRC21:36
apuimedoxgerman_: what would civilization be without bureaucraxy21:38
apuimedofucking hell, only mistyping21:38
apuimedoxgerman_: but as rm_work said, it's not necessary for master nor pike, right21:39
apuimedodeployments won't need neutron-lbaas anymore21:39
apuimedois that right?21:39
xgerman_yes and no — if you use a 3rd party LB you will still need n-lbaas until vendors make new drivers…21:39
openstackgerritOpenStack Proposal Bot proposed openstack/neutron-lbaas master: Updated from global requirements
openstackgerritOpenStack Proposal Bot proposed openstack/neutron-lbaas-dashboard master: Updated from global requirements
apuimedoxgerman_: well, I can tell people that use 3rd party to just install n-lbaas then21:42
apuimedoxgerman_: do you know if f5 already did the new drivers?21:42
xgerman_nobody did — we still need to design/implement the new driver interface21:43
openstackgerritOpenStack Proposal Bot proposed openstack/octavia master: Updated from global requirements
openstackgerritOpenStack Proposal Bot proposed openstack/octavia-dashboard master: Updated from global requirements
apuimedoxgerman_: good to know21:49
rm_workapuimedo: yeah but if you are using Octavia for this installation... you don't need it21:51
*** cpusmith has quit IRC21:51
apuimedorm_work: I was now thinking on OVN's and DragonFlow's native load balancers21:52
apuimedoit'd be nice if they didn't require neutron-lbaas either21:52
rm_workwe're working on it21:53
rm_workbut need buy-in from vendors to help design the interface21:53
*** yamamoto has joined #openstack-lbaas21:55
apuimedorm_work: I think the important thing would be to make it easy to have hybrid drivers21:57
apuimedoso that vendors can implement gradually21:58
apuimedofor example start l4 only21:58
apuimedoand let normal amphorae for l721:58
xgerman_yeah, we gotta see how we skin that cat21:59
rm_workthere's a setup for a shim driver already22:00
rm_workso it might a simple port over from n-lbaas22:00
rm_workBrandon doesn't work on this anymore but I took it over kinda22:01
*** yamamoto has quit IRC22:12
*** cpuga has joined #openstack-lbaas22:13
*** cpuga has quit IRC22:18
*** sshank has quit IRC22:19
*** sshank has joined #openstack-lbaas22:27
*** aojea has quit IRC22:29
*** sanfern has quit IRC22:37
*** sanfern has joined #openstack-lbaas22:39
openstackgerritAdolfo Duarte proposed openstack/octavia master: Adds support for SUSE distros
*** yamamoto has joined #openstack-lbaas23:13
*** yamamoto has quit IRC23:21
*** rtjure has joined #openstack-lbaas23:32
openstackgerritMerged openstack/octavia-dashboard master: Get rid of removed Django code
*** sshank has quit IRC23:54

Generated by 2.15.3 by Marius Gedminas - find it at!