Wednesday, 2017-03-15

« Tuesday, 2017-03-14 Index Thursday, 2017-03-16 »
*** armax has quit IRC00:10
*** reedip has joined #openstack-lbaas00:26
*** catintheroof has joined #openstack-lbaas00:32
*** armax has joined #openstack-lbaas00:51
*** amotoki has joined #openstack-lbaas00:53
openstackgerritTuan Luong-Anh proposed openstack/octavia master: Indicating the location tests directory in oslo_debug_helper  https://review.openstack.org/44350301:22
*** catintheroof has quit IRC01:24
*** reedip has quit IRC01:25
*** catintheroof has joined #openstack-lbaas01:30
*** catintheroof has quit IRC01:32
rm_workdiltram_: looking at your patch, do you know why they didn't want to keep the configdrive iso mounted? your code reverses the behavior, so it does stay mounted forever, right?01:45
openstackgerritMichael Johnson proposed openstack/octavia master: Fix load balancer project_id handling on POST  https://review.openstack.org/44286501:52
rm_workjohnsom: quiet today01:55
rm_workanything interesting happening?01:55
rm_worksaw the lxd patch01:55
johnsomKind of quiet, yeah the lxd thing01:55
johnsomSome patches in nlbaas land01:55
rm_workso for https://review.openstack.org/#/c/444707/01:56
johnsomI worked on the new repo infra stuff and trying to get back to the LB API01:56
johnsomHa, yeah01:56
rm_workI dunno, without that we can never do depends-on for DIB right?01:56
rm_workand we'll see the breakage eventually01:56
rm_worki figured it might be BETTER to see it BEFORE it hits pypi01:57
rm_workthan after01:57
rm_workas far as impact goes01:57
rm_workmaybe we need a gate specifically for that?01:57
johnsomWell, you can exclude and/or pin versions with pypi01:57
johnsomThat isn't a half bad idea01:57
johnsomOk, dinner time, chat with you later01:59
*** amotoki has quit IRC02:05
*** amotoki has joined #openstack-lbaas02:05
*** gongysh has joined #openstack-lbaas02:14
*** cody-somerville has joined #openstack-lbaas02:28
*** cody-somerville has quit IRC02:28
*** cody-somerville has joined #openstack-lbaas02:28
*** csomerville has quit IRC02:28
*** dileepr has quit IRC02:39
rm_workjohnsom: but we can't, right? because of g-r02:39
*** csomerville has joined #openstack-lbaas02:44
*** cody-somerville has quit IRC02:47
*** sticker has joined #openstack-lbaas02:59
openstackgerritYang Li proposed openstack/neutron-lbaas master: Add 'create_time' for loadbalancer/listener/pool  https://review.openstack.org/44527503:00
*** KeithMnemonic has quit IRC03:05
*** reedip has joined #openstack-lbaas03:06
*** fnaval has joined #openstack-lbaas03:13
*** ducnc1 has joined #openstack-lbaas03:13
*** ducnc has quit IRC03:15
*** ducnc1 is now known as ducnc03:15
*** amotoki has quit IRC03:32
*** amotoki has joined #openstack-lbaas03:49
*** amotoki has quit IRC03:50
*** amotoki has joined #openstack-lbaas03:52
*** amotoki has quit IRC03:54
*** links has joined #openstack-lbaas03:56
*** amotoki has joined #openstack-lbaas04:22
*** gongysh has quit IRC04:39
*** amotoki has quit IRC04:39
*** fnaval has quit IRC05:02
openstackgerritOpenStack Proposal Bot proposed openstack/octavia master: Updated from global requirements  https://review.openstack.org/44575905:16
*** gongysh has joined #openstack-lbaas05:17
*** faizy has joined #openstack-lbaas05:28
*** amotoki has joined #openstack-lbaas05:30
*** amotoki has quit IRC06:00
*** blogan has quit IRC06:03
*** amotoki has joined #openstack-lbaas06:11
*** gcheresh_ has joined #openstack-lbaas06:17
*** armax has quit IRC06:20
*** aojea has joined #openstack-lbaas06:37
*** krypto has joined #openstack-lbaas06:59
*** eezhova has joined #openstack-lbaas07:11
*** gcheresh_ has quit IRC07:28
*** gongysh has quit IRC07:34
*** kobis has joined #openstack-lbaas07:36
*** kobis has quit IRC07:40
*** kobis has joined #openstack-lbaas07:42
*** tesseract has joined #openstack-lbaas07:44
*** aojea has quit IRC07:45
*** gongysh has joined #openstack-lbaas07:50
*** eezhova has quit IRC07:53
*** pcaruana has joined #openstack-lbaas08:05
*** eezhova has joined #openstack-lbaas08:29
*** amotoki has quit IRC08:35
*** krypto has quit IRC08:56
*** krypto has joined #openstack-lbaas09:10
*** krypto has quit IRC09:10
*** krypto has joined #openstack-lbaas09:10
*** belharar has joined #openstack-lbaas09:11
*** krypt0N has joined #openstack-lbaas09:14
*** krypt0N has quit IRC09:14
*** krypt0N has joined #openstack-lbaas09:14
*** csomerville has quit IRC09:16
*** krypt0N has quit IRC09:16
*** krypt0N has joined #openstack-lbaas09:16
*** krypto has quit IRC09:17
*** krypto has joined #openstack-lbaas09:19
*** krypt0N has quit IRC09:19
*** aojea has joined #openstack-lbaas09:24
*** gcheresh has joined #openstack-lbaas09:26
*** zioproto has joined #openstack-lbaas09:31
*** aojea has quit IRC10:08
*** openstackgerrit has quit IRC10:18
*** aojea has joined #openstack-lbaas10:24
rm_workkobis: can you rebase https://review.openstack.org/#/c/438240/ ?10:33
rm_workprobably doesn't matter actually, since that is not used yet I think10:33
rm_workkobis: where will you use api mode? 3rd party gates?10:34
*** aojea has quit IRC10:53
*** aojea has joined #openstack-lbaas10:56
*** gongysh has quit IRC11:01
*** krypto has quit IRC11:07
*** krypto has joined #openstack-lbaas11:09
*** krypto has quit IRC11:09
*** krypto has joined #openstack-lbaas11:09
*** amotoki has joined #openstack-lbaas11:14
*** amotoki has quit IRC11:21
*** sanfern has quit IRC11:29
*** sanfern has joined #openstack-lbaas11:29
*** amotoki has joined #openstack-lbaas11:38
*** aojea has quit IRC11:39
*** amotoki has quit IRC11:48
kobisrm_work: i'm working on a handler which will rpc octavia requests to my context. unlike the current handler which requires the context to be connected to octavia db etc11:54
kobisand - yeah i just need the o-api service11:54
*** openstackgerrit has joined #openstack-lbaas11:55
openstackgerritKobi Samoray proposed openstack/octavia master: Devstack plugin: API only mode  https://review.openstack.org/43824011:55
*** faizy has quit IRC11:59
*** aojea has joined #openstack-lbaas12:11
*** gongysh has joined #openstack-lbaas12:12
*** reedip has quit IRC12:52
*** reedip has joined #openstack-lbaas12:54
*** belharar has quit IRC12:55
*** faizy has joined #openstack-lbaas12:56
*** sanfern has quit IRC12:57
*** catintheroof has joined #openstack-lbaas12:59
*** belharar has joined #openstack-lbaas13:00
*** sanfern has joined #openstack-lbaas13:00
*** ianychoi has quit IRC13:01
*** links has quit IRC13:02
*** reedip has quit IRC13:11
*** reedip has joined #openstack-lbaas13:15
*** matt-borland has joined #openstack-lbaas13:15
*** aojea has quit IRC13:15
*** KeithMnemonic has joined #openstack-lbaas13:16
*** aojea has joined #openstack-lbaas13:19
*** aojea has quit IRC13:19
*** aojea has joined #openstack-lbaas13:19
nmagnezirm_work, hey13:23
rm_worko/13:23
nmagnezirm_work, i understand there was a DST change in the us?13:23
nmagnezirm_work, asking because of the weekly meeting :)13:23
rm_workguess so13:23
rm_workah yeah13:23
rm_workugh i don't think i'll be awake for that13:24
nmagnezirm_work, oh, it is now 1 hour ahead?13:24
rm_workno idea13:25
rm_workI just let my calendar tell me when things are13:25
rm_workbut i don't think i'd be awake for it either way :P13:25
nmagnezihah13:26
nmagnezialright13:26
nmagnezi:)13:26
rm_worki'm in JST13:26
nmagneziyup, I remember :)13:26
nmagnezibut don't you know if thet moved the clock 1 hour forward or backwards?13:26
rm_workhmmm13:28
rm_workmy meeting got earlier here13:28
rm_workso does that mean... they moved the clock ... forward?13:28
rm_workI hate DST13:29
*** KeithMnemonic has quit IRC13:29
rm_workI wear this shirt a lot: http://shirt.woot.com/offers/dont-spring-ahead13:29
openstackgerritNir Magnezi proposed openstack/octavia master: Auto detect haproxy user_group  https://review.openstack.org/42939813:32
nmagnezirm_work, lol. cool one!13:35
*** belharar has quit IRC13:40
*** aojea has quit IRC14:00
*** aojea_ has joined #openstack-lbaas14:04
*** links has joined #openstack-lbaas14:06
*** reedip has quit IRC14:09
*** reedip has joined #openstack-lbaas14:18
*** reedip has quit IRC14:24
*** cody-somerville has joined #openstack-lbaas14:24
*** reedip has joined #openstack-lbaas14:26
*** amotoki has joined #openstack-lbaas14:29
*** dasanind has quit IRC14:40
*** dasanind has joined #openstack-lbaas14:41
*** links has quit IRC14:42
*** cody-somerville has quit IRC14:43
*** csomerville has joined #openstack-lbaas14:43
*** aojea_ has quit IRC14:47
*** gongysh has quit IRC14:51
*** aojea has joined #openstack-lbaas15:05
*** gcheresh has quit IRC15:14
*** KeithMnemonic has joined #openstack-lbaas15:14
*** aojea has quit IRC15:15
*** aojea has joined #openstack-lbaas15:15
*** blogan has joined #openstack-lbaas15:19
diltram_rm_work: the problem is with privileges15:20
diltram_they made a code which at the boot time mounts the iso but in this way cloud-init doesn't use it15:21
diltram_because it's trying to mount image on it's own15:21
*** diltram_ is now known as diltram15:21
diltramrm_work: and even I was not able to find any configuration which resulted with reading data just from dir15:30
*** krypto has quit IRC15:31
*** amotoki has quit IRC15:33
*** voelzmo has joined #openstack-lbaas15:34
voelzmoHello dear friends of loadbalancing! Is it possible to ask a VM or port if it is a member of an lbaasv2 pool?15:35
voelzmo I'm struggling how to clean up lbaasv2 pool memberships when a VM gets deleted15:35
voelzmoas far as I saw, this isn't done automatically, right?15:35
johnsomIt is not done automatically15:36
johnsomThe only way is to do a member list and see if you have a match to your VM15:36
*** oomichi has quit IRC15:36
*** armax has joined #openstack-lbaas15:37
voelzmo@johnsom for all LBs, for all pools?15:39
voelzmothat might be a lot15:39
johnsomIt's per pool15:39
*** aojea has quit IRC15:40
voelzmoright, but I don't know which pools to look in, right? So I iterate over all LBs, list their listeners, iterate over all listeners to get the pools, iterate over all pools to list the members, to check if the VM is in there15:41
*** oomichi has joined #openstack-lbaas15:41
voelzmooh, there is a separate endpoint to only list all pools15:41
johnsomYes, it would be a bit of work15:41
voelzmoregardless of LB15:41
voelzmostill, it is iterating over all pools, listing their members, checking for the VM15:42
voelzmoseems like some work to do for every deleted VM15:42
voelzmoIs there a reason to not delete the membership when deleting the VM automatically?15:44
johnsomWe don't really want to be second guessing users and their intent by trying to automatically delete members.  You could use other automation tools to manage that if that is your intent.   However, if you would like an API that makes it easier to find the member records, feel free to put in an RFE bug15:44
voelzmo@johnsom what kind of automation tool would you suggest to manage that?15:44
johnsomWe don't even know if it is a VM or not, to us they are mostly just IP and port pairs.15:45
*** aojea has joined #openstack-lbaas15:46
diltramjohnsom: why in this new patch to project-config we're not using any more the {pipeline} var?15:47
johnsomSomething like heat15:47
johnsomdiltram Which patch?  I am guessing the tests are all templated15:48
*** reedip has quit IRC15:50
*** eezhova has quit IRC15:50
voelzmo@johnsom so you suggest to maintain state information for each VM that I spin up for the VMs lifetime?15:50
diltramwhich added gates for dashboard integration tests15:50
voelzmoThat seems like an unreasonable burden to the user for all larger use-cases15:51
diltramhttps://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/octavia.yaml#L26415:51
voelzmobtw: AWS deletes memberships in ELB and ALB on VM termination, so it doesn't seem to be very surprising for many users when that happens15:52
voelzmoand: are there use-cases in which a membership is still useful for something after deleting VM or port? What happens when I attach the port to a different VM, is traffic automatically routed to that VM over the LB then?15:53
diltramjohnsom: I'm pushing patch so I'm gonna change this also in it, ok?15:53
johnsomdiltram Yeah, I think that is fine15:54
johnsomI just copied the existing neutron-lbaas-dashboard config...15:54
rm_workvoelzmo: but VMs are not members of LBs15:57
rm_workvoelzmo: IPs are members of LBs15:57
rm_workthere's no link15:57
rm_work(no *direct* link)15:57
johnsomYeah, and the use case above is a valid one.15:57
voelzmo@johnsom  which use-case are you talking about? Not deleting the port and re-attaching it to a different VM? Does that work and traffic will be routed?15:58
rm_workif you would like to manage LBs and VMs together in this way, maybe an orchestration layer is needed? like, Heat maybe? not sure if it will do this for you or not15:58
*** eezhova has joined #openstack-lbaas15:58
rm_workvoelzmo: yes, that works15:58
johnsomYou can add google.com's IP and port as a member if you want.  Members are not always tied to VMs15:59
voelzmo@rm_work by suggesting something like heat you're saying (like @johnsom did before) that I should maintain state for VMs I create and their memberships in LB pools16:02
rm_workyes16:02
rm_workbecause octavia has no concept of a "member VM"16:02
rm_workjust "member IP"16:02
rm_workand nova is a completely separate service16:02
rm_workso, how would we even know when you delete a VM?16:03
voelzmothat might work in some cases, for our case (maintaining Cloud Foundry and its services) maintaining state about LB memberships isn't really a thing16:03
rm_workto us it might just look like the member went offline (if you have a health-monitor configured), and we would not remove it because it might come back up16:03
rm_workand if there is no health monitor... then we wouldn't even know the VM was gone16:03
rm_workthere just isn't a mechanism for discovering this kind of thing16:03
voelzmo@rm_work it is not like OpenStack services don't communicate, right? You're saying this as if all services are islands that don't talk16:03
rm_workin this case that is pretty true...16:04
voelzmoThat's what I just found out, and I'm saying this is pretty unfortunate16:04
rm_workunless you think Octavia should read all of Nova eventing, then look up every deleted VM's IPs, and compare against our list of IPs -- except, there will be tons of matches for everything, because IPs will overlap due to subnetting16:04
johnsomIt is expected that if the user want's that kind of automation they will use a desired state tool16:05
rm_workthe member IP (all Octavia knows) just isn't valid as a foreign key to nova16:05
voelzmoSo what I'm hearing are technical/implementation details that would not allow for this relation to be made. I didn't hear a compelling argument yet why this is a reasonable product decision16:06
voelzmoEssentially you're saying 'it is hard to do, so the user has to do it'16:07
voelzmowhich seems weird16:07
johnsomI am saying we have built a base service that is flexible to work on many different configurations that can be built upon with other tools to do new and different things.16:08
*** krypto has joined #openstack-lbaas16:08
*** voelzmo has quit IRC16:09
*** eezhova has quit IRC16:12
*** krypto has quit IRC16:14
*** voelzmo has joined #openstack-lbaas16:18
voelzmoSorry, had to catch a train16:18
*** KeithMnemonic has quit IRC16:25
xgermanfrom the weird world of SSL pass-through: https://github.com/kubernetes/kubernetes/issues/4085016:25
*** KeithMnemonic has joined #openstack-lbaas16:25
*** aojea has quit IRC16:26
rm_workvoelzmo: do you know the unix philosophy?16:28
xgermanI am with voelzmo just because we don’t talk much with nova this migt not be a calid use case16:29
voelzmoDo one thing and do it well?16:29
xgermanvoelzmo can you write a bug and mark it RfE and explain what we should do16:29
xgermanso w ehave that captured16:29
*** reedip has joined #openstack-lbaas16:30
xgermanthere are peoplewho want to migrate their AWS cloud toopenStack so that might be a necessary enhancement…16:30
johnsomJust like Amazon uses lambda for this, I am not sure we really should build a dependency on nova.....16:30
rm_workyes, we do this piece, so that our service can be easily used via orchestration along with a bunch of other services that do their piece16:31
voelzmoSure, can do, @xgerman. I first wanted to check if there is a way to do this before opening a ticket ;)16:31
xgermanwell, as we said there is heat, ansible, chef, you name them ;-)16:31
voelzmoIn this case it is cloud foundry bosh ;p16:32
*** kbyrne has quit IRC16:32
openstackgerritMichael Johnson proposed openstack/python-octaviaclient master: Initial setup of the python-octaviaclient repo  https://review.openstack.org/44605816:32
voelzmoAnd I guess it would be enough to react on ports being deleted, VMs might be a different story16:33
rm_workcan AWS ELB load-balance to IPs that aren't inside amazon's cloud?16:33
rm_worki'm trying to find out and i don't think it is possible16:34
rm_workthey don't take IPs, but ARNs16:34
voelzmo@rm_work you are right, that is not possible16:34
xgermanyeah, we support that16:34
voelzmoI understand16:34
rm_workso IMO this is a good differentiator16:34
*** faizy has quit IRC16:35
xgermanwell, we can still monitor ports and remove the member… if this is deemed useful/necessary16:35
voelzmoHowever, *when* im using internal ports for LB members, then it would make sense, agreed?16:35
openstackgerritBernard Cafarelli proposed openstack/octavia master: devstack: install qemu-kvm on RHEL-based distros  https://review.openstack.org/44605916:35
xgermanin OpenStack we always have a discussion between “convenient” functions and orchestration16:36
rm_workso how would it work? we take a nova ID along with the IP, then set up another daemon to subscribe to nova's event feed and watch for that ID being deleted?16:36
rm_workso long as all of that is optional, I have no problem with it16:36
*** kbyrne has joined #openstack-lbaas16:36
xgermanif we decide it is needed we could talk with nova to make that more staright forward for us16:36
rm_workdoes nova actually DO the eventing that I'm supposing it does?16:36
xgermanand if it is a big enough need they will do it16:37
xgermanDeciding that it is useful and figuring out how to do it are two steps16:37
rm_worki feel like it's a pretty minor need <_<16:37
rm_workif even a "need"16:37
xgermanyeah, it’s definitely in the “nice-to-have” area but I also work for people with ideas so…16:38
xgermanand if somebody volunteers to write the code…16:39
*** strigazi is now known as strigazi_AFK16:39
xgermanalso if we hang it on the port — neutron has some decent event queue to tell you which ports disappear16:40
*** voelzmo has quit IRC16:40
johnsomSeems like it would be a shame if every project wrote their own event listeners/register/trigger16:40
xgerman+116:40
openstackgerritMichael Johnson proposed openstack/python-octaviaclient master: Initial setup of the python-octaviaclient repo  https://review.openstack.org/44605816:42
rm_workso *is there* an "openstack eventing" project?16:45
rm_workthat'd admittedly be neart16:45
rm_work*neat16:45
rm_workif it read events from every service16:45
rm_workand you could set up triggers16:45
rm_worklike16:45
xgermanthat seems like an oslo thing, harlowja16:45
rm_worksee event A -> do API call B to service C16:45
rm_workusing fields from event A16:45
rm_workharlowja: get on that? :P16:46
xgermanyep, he should…16:46
johnsomSenlin was doing something like that with an eye to clustering16:50
diltramjohnsom: who has core in python-octaviaclient?16:50
rm_workdiltram: hopefully the same octavia core team?16:50
johnsomNo one yet, I just asked in infra for that16:50
diltramno :P16:50
rm_workah :P16:50
diltramok16:50
rm_workhmm i might have some time to help with the client stuff16:50
johnsomPatience....16:50
rm_workwe'll see16:50
diltram:P16:50
rm_workfuck, this patch chain for v2API is a PITA16:51
johnsomThere are lots of little steps to get these setup....16:51
rm_worksuper long and merge conflicts16:51
rm_workgetting merge conflict on 44287916:51
rm_workah you have a -W on that anyway16:52
johnsomYeah, I was working on that yesterday16:53
johnsomHad some strange thing going on with my devstack but I think I got it fixed.16:53
*** tesseract has quit IRC16:53
johnsomThat patch is only partially done16:53
rm_workok testing the API stuff today, will leave that one out for now16:55
rm_worki guess it's fine to merge later16:55
johnsomI hope to have it cleaned up today16:56
*** krypto has joined #openstack-lbaas16:57
*** krypto has quit IRC16:58
*** krypto has joined #openstack-lbaas16:58
*** krypto has joined #openstack-lbaas16:58
*** blogan_ has joined #openstack-lbaas17:10
johnsomOk, now the cores have core rights on the new repositories...   diltram17:11
diltramjohnsom: awesome :)17:11
johnsomI am still working on setting up the tempest and dashboard repos, but client should be open for business17:12
diltramstill processing ;(17:12
*** blogan has quit IRC17:12
johnsomYeah, strange17:15
*** blogan_ is now known as blogan17:17
openstackgerritMichael Johnson proposed openstack/python-octaviaclient master: Initial setup of the python-octaviaclient repo  https://review.openstack.org/44605817:20
johnsomOk, now I have +2 on it17:20
diltramme too :)17:21
rm_workme three :)17:23
xgermanI will look at it once I need it17:23
johnsomAll this and no reviews yet...  Grin17:24
johnsomThat is good, maybe you will catch something I missed in the templates17:24
*** krypto has quit IRC17:24
*** krypto has joined #openstack-lbaas17:24
*** krypto has quit IRC17:24
*** krypto has joined #openstack-lbaas17:24
*** pcaruana has quit IRC17:28
*** krypto has quit IRC17:30
*** krypto has joined #openstack-lbaas17:30
openstackgerritMichael Johnson proposed openstack/octavia-tempest-plugin master: Initial setup of the octavia-tempest-plugin repo  https://review.openstack.org/44608217:31
*** reedip has quit IRC17:38
openstackgerritMichael Johnson proposed openstack/octavia-tempest-plugin master: Initial tempest plugin for octavia-tempest-plugin  https://review.openstack.org/44608417:43
*** eezhova has joined #openstack-lbaas17:43
johnsomrm_work FYI, your presenter profile still says Rackspace...17:47
rm_worklol17:48
rm_workyeah i need to fix that17:48
*** ianychoi has joined #openstack-lbaas17:52
*** armax has quit IRC17:55
*** kobis has quit IRC18:05
*** eezhova has quit IRC18:15
harlowjarm_work sureeee18:15
harlowjalol18:15
harlowjai guess what kind of events do u mean18:16
harlowjalocal to process, generic blah blah?18:16
harlowjabasic observer pattern?18:16
harlowjaif ^ then ya, i've already got a library for that for u18:16
harlowjahttps://pypi.python.org/pypi/notifier18:16
harlowjabut depends on what u guys mean18:16
harlowjalol18:16
harlowjasounds more like u guys want something across services18:17
*** kobis has joined #openstack-lbaas18:26
*** armax has joined #openstack-lbaas18:30
xgermanharlowja we would like to “register” for a vm disappearing and then remove it from the mebers list18:30
harlowjaya, sounds nice18:30
harlowja:)18:30
*** krypto has quit IRC18:30
xgermanwell, somebody needs to make a notification framework for all of OpenStack ;-)18:31
rm_workharlowja: yeah I want a service that runs, and lets me set up triggers18:32
rm_worklike IFTTT18:32
rm_workyou know IFTTT?18:32
rm_workI want THAT, but for openstack18:32
harlowjaIFTTTTT18:32
harlowjaifit to18:32
harlowjau fit18:32
harlowjawe all fit18:32
rm_workthey did it for the whole internet, i think we can do it for a few services18:32
harlowjayes, i've seen this mentioned a few times before18:32
harlowjai think zaquar was trying to be that18:32
diltramjohnsom: what type of magic now is required to start devstack?18:32
harlowjaor macaroni18:32
harlowjaor whatever18:33
harlowjadon't think such things worked out :-/18:33
xgermancue - anyone?18:33
johnsomdiltram What magic do you speak of?18:33
diltramall gates are down18:33
xgermanharlowja indeed — I think they didn’t work out because they were not part of oslo18:33
harlowja:-/18:33
diltramand even on my VM I can't build devstack18:33
harlowjanice try18:33
harlowjalol18:33
harlowjaoslo isn't a big-hairy-beast that makes u do things18:34
harlowja:-P18:34
harlowjaunless i'm a big-hairy-beast18:34
harlowjahmmm18:34
harlowjalol18:34
xgermanyeah, the whole rpc stuff is already oslo - so only a small step to an rpc model which spans projecs18:35
harlowjawell sort of18:35
harlowjaoslo.messaging already has the notifications layer part18:35
harlowjait just doesn't have the catalog of things u can listen for, things u can subscribe for18:36
harlowjaand common and agreed formats18:36
harlowja*ie sort of a catalog18:36
xgermanyep, that would be the gap we need to tackle18:36
harlowjaya, i mean, all for trying to do this18:36
harlowjai think i've seen it tried before18:36
xgermancatalog of data fromats? remins me of the great SOAP days UDDI?18:37
harlowjajust requires projects do like care about this :-P18:37
harlowja*to like18:37
johnsomCould not resolve host: git.openstack.org18:37
*** krypto has joined #openstack-lbaas18:37
xgermanyep, but as a community we probably need to get away from just saying use heat and present a more itrgrated system18:38
xgermanif Amazon is the Windows of cloud, we are likely the FreeBSD of cloud18:38
*** voelzmo has joined #openstack-lbaas18:39
diltramjohnsom: nvm, patch which I'm trying to test is not rebased on dib-utils patch18:40
openstackgerritLubosz Kosnik (diltram) proposed openstack/octavia master: Adds a new feature to limit the amphora build rate  https://review.openstack.org/30330418:41
johnsomdiltram Well, there is a DNS issue too18:42
diltramjohnsom: just wondering if it's some real bug18:43
diltramor just infra issue18:43
rm_workdiltram: https://review.openstack.org/#/c/445003/ I was waiting to see the results of tests before +A, and they failed badly18:45
diltramrm_work: just saw it18:45
diltramjust thought that they failed as in the other patches :/18:46
rm_workonly the py3 ones should be failing18:46
rm_workand those only until my fix merges18:46
rm_workassuming people are OK with it18:46
rm_work(did you weigh in?)18:46
diltramrm_work: they didn't released the new version of tempest :/18:46
rm_workhttps://review.openstack.org/#/c/444707/18:47
rm_workthere is some sort of like... vote going on there18:47
rm_workjohnsom / xgerman ^^ i replied BTW18:48
*** catinthe_ has joined #openstack-lbaas18:48
diltramjohnsom, rm_work, xgerman: are you ok with changing scenario for voting and I can push this gate also to DIB18:49
diltramif they gonna change something what is breaking us they will not be able to merge it18:49
rm_workIMO yes18:49
rm_workco-gate is ideal18:49
rm_workif they'll accept it18:49
rm_workgreghaynes ^^18:50
greghayneshrm?18:50
diltramrm_work: the weird thing is that infra is not asking about permission to do this18:50
rm_worklolol18:50
xgermandiltram I would like that18:50
greghaynesare you all in the integrated gate?18:50
diltramthey just merge what I will propose :P18:50
rm_workyeah technically they do not18:50
rm_workbut18:50
rm_workit will get noticed and reverted quickly if they don't like it :P18:51
rm_workgreghaynes: integrated gate?18:51
diltramI know, but then it would be harder to tell why it's reverted18:51
greghaynestheres one big integrated queue for nova/neutron/heat/etc18:51
*** catintheroof has quit IRC18:51
greghayneswondering if you share a job with any of them aka if you co-gate with any of them18:51
rm_worknot sure18:52
rm_workthough what i mean by co-gate is18:52
diltramgreghaynes: your's test are not covering us in any way18:52
rm_workfor a DIB patch to land, our gate has to pass18:52
diltramthe same we have with barbican18:53
greghaynesright, you cant co-gate with us if you are in the integrated gate which is why I ask18:53
rm_workah18:53
*** voelzmo has quit IRC18:53
diltramwhen they're pushing some patch it's automatically tested with out code18:53
greghaynesdiltram: I'd recommend trying to find why that is and fix it18:53
greghaynese.g. why our coverage is letting things through that break you all18:53
diltramgreghaynes: I don't understand18:53
greghaynesbecause the integration points between dib and octavia are pretty small18:54
rm_workdiltram: so you want that to exist, before you would +2 https://review.openstack.org/#/c/444707/ ?18:56
greghaynesIf theres some specific 'this broke us' I can probably give some info on what coverage we must be missing...18:56
greghaynesI think the recent thing is we dont have a py3 dib test or somesuch18:57
diltramjohnsom: meeting?19:02
rm_workoh god is that now19:02
diltramyep19:02
rm_worki stayed awake longer than I meant to >_<19:02
rm_worki guess I'll go to it >_>19:02
diltram:P19:02
johnsomNo, it is in another hour19:02
johnsomDST19:02
rm_workAH k19:02
diltramehh19:02
diltramagain time changed on weekend :P19:03
johnsom20:00 UTC19:03
rm_workjohnsom: can you add me to your calendar event? :P19:03
rm_worklol19:03
diltramyeah, my calendar in telephone didn't refresh19:03
rm_workI don't think it limits attendees to rax emails19:03
rm_workoutlook should just do its thing19:04
*** krypto has quit IRC19:06
rm_workkinda wish i could do the meeting just to push https://review.openstack.org/#/c/444707/19:07
rm_workbut i really need to disappear19:07
diltramrm_work: I'm ok with it if we gonna add cross-project gate19:08
rm_worki think we should do it regardless19:08
rm_workbut i am pro-co-gate19:08
diltramwithout it we will never be able to move to voting gate19:08
rm_workah right19:13
rm_workbecause our gate would be too potentially unstable19:13
diltramxgerman: https://review.openstack.org/#/c/30330419:23
diltramrm_work: exactly19:23
xgermanthanks19:23
rm_workdiltram: maybe i should move the py3-functional fix out to a different CR <_<19:24
diltramespecially that barbican will not be able to merge anything if our gate will start throwing -119:24
rm_workdidn't expect this to be a huge debat19:24
rm_work*debate19:24
diltramrm_work: best choice19:24
rm_workok so, how about19:25
rm_workwe add our basic scenario for py2/py3 to DIB as non-voting19:25
rm_workwe merge this change and that change together19:25
*** eezhova has joined #openstack-lbaas19:25
rm_workand then we make it voting after everything is passing19:25
rm_worki'll depends-on this change with the project-config change19:26
diltramI'm ok with it19:26
rm_workcan you do the project-config thing now?19:26
diltramsure19:26
rm_workk19:27
*** zioproto has quit IRC19:31
diltramrm_work: https://review.openstack.org/44613919:31
diltramrm_work: or you want to make it in different way?19:32
rm_workeh either works19:32
diltram:P19:32
rm_workthis just means we wait for them to +A19:32
rm_workand then +A mine19:32
rm_workvs the other way19:32
diltramat first we should have project-config merged19:33
rm_workcorrect19:33
diltramI'm gonna remove this depends-on19:33
diltramdone19:33
openstackgerritAdam Harwell proposed openstack/octavia master: Install DIB from source so depends-on will work  https://review.openstack.org/44470719:34
rm_workthere19:34
rm_workyou can +2 now :P19:34
diltrambut like you told, the py3x functional must be moved to different CR19:35
rm_workMUST BE19:35
rm_workor *can be*? :P19:35
diltrammust be19:35
diltrambecause then we can change functional-py3x for voting19:35
diltramlike today19:35
diltram:D19:35
rm_workah.19:35
diltramrm_work: already made a project-config change - waiting for your CR to make it dependent19:37
rm_worki did19:37
rm_workbut updating again19:38
rm_workfor the other test19:38
diltramok19:38
openstackgerritAdam Harwell proposed openstack/octavia master: Install DIB from source so depends-on will work  https://review.openstack.org/44470719:38
openstackgerritAdam Harwell proposed openstack/octavia master: fix py3x test bug so functional tests will pass  https://review.openstack.org/44614419:39
rm_work^^19:39
diltramgreat19:41
*** ndahiwade has quit IRC19:45
rm_workjohnsom: just one quick nit/question https://review.openstack.org/#/c/446058/319:47
johnsomrm_work Ha, yeah, I think it stays, every repo has it.  I could go either way on it19:49
rm_workk whatever19:49
diltramrm_work: uploaded CR19:50
diltramhttps://review.openstack.org/#/c/446144/19:50
*** eezhova has quit IRC19:50
diltramgreghaynes: I completely disagree with your comments on CR19:50
greghaynesok, feel free to reply :)19:51
diltramcross-project gate is specificaly created to verify that any change made in project is not breaking anything in other one which is using yours19:51
greghaynessure, but there are two issues (that I tried to point out)19:51
rm_workeven so I agree with having a co-gate19:53
rm_workgiven the amount of breaks we've seen in the past19:53
rm_workand that we will now have a responsibility to another project to have working gates as well19:54
openstackgerritMerged openstack/python-octaviaclient master: Initial setup of the python-octaviaclient repo  https://review.openstack.org/44605819:54
rm_workand DIB is the cause of most of our breaks19:54
greghaynesand my comment there applies - can you provide examples where a break isnt better solved with functional testing19:55
rm_workno? but we can't test *everything*, the issue is that things break that we don't anticipate19:56
rm_workif we could have perfect tests for every possible thing, that'd be great19:56
rm_workbut that's not realistic19:56
diltramespecially that you're in charge of tests, you can change any functionality and related tests19:57
diltrameverything will be great19:57
diltrambut we again will be broken19:57
diltrambecause you're gonna change API/way of working19:57
rm_workright19:58
johnsomOctavia meeting starting soon on #openstack-meeting-alt19:58
rm_workchange feature -> change test to work with new operation of feature -> everything still passes19:58
greghaynesthat was exactly my question, can you provide examples of that19:58
diltramthis is why we need cross-project gate19:58
diltramrm_work: do you remember what was that? I didn't worked on this issues19:59
rm_worki guess I can grep through IRC logs for "DIB.*broken" and probably find most of the instances19:59
rm_workit's been 3-4 times in the last cycle19:59
diltramI know19:59
*** richbrowne has joined #openstack-lbaas20:06
*** richbrowne is now known as r-browne20:08
*** kobis has quit IRC20:08
*** r-browne has quit IRC20:09
*** kobis has joined #openstack-lbaas20:09
*** richbrowne has joined #openstack-lbaas20:09
*** kobis has quit IRC20:26
openstackgerritMerged openstack/octavia master: Devstack plugin: API only mode  https://review.openstack.org/43824020:31
openstackgerritAdam Harwell proposed openstack/neutron-lbaas master: Fix neutron-lbaas gates  https://review.openstack.org/44616920:32
*** gcheresh has joined #openstack-lbaas20:34
openstackgerritAdam Harwell proposed openstack/octavia master: fix py3x test bug so functional tests will pass  https://review.openstack.org/44614420:34
openstackgerritLubosz Kosnik (diltram) proposed openstack/neutron-lbaas master: Fix config import from neutron  https://review.openstack.org/44617120:36
openstackgerritAdam Harwell proposed openstack/neutron-lbaas master: Fix neutron-lbaas gates  https://review.openstack.org/44616920:38
*** matt-borland has quit IRC20:40
openstackgerritAdam Harwell proposed openstack/neutron-lbaas master: Fix neutron-lbaas gates  https://review.openstack.org/44616920:42
openstackgerritLubosz Kosnik (diltram) proposed openstack/neutron-lbaas master: Updating import for linux/interface opts  https://review.openstack.org/35247120:43
*** cody-somerville has joined #openstack-lbaas20:44
openstackgerritLubosz Kosnik (diltram) proposed openstack/neutron-lbaas master: Updating import for linux/interface opts  https://review.openstack.org/35247120:45
*** csomerville has quit IRC20:46
rm_workdiltram: that patch is totally different and DOES rely on the other patch you removed the depends-on for20:46
rm_workugh but i missed a pep8 thing20:49
diltrambecause this depends on is f...20:51
diltramhow it's possible that even without merging this previous code we require this one to be used20:51
rm_workthat patch is totally different20:52
rm_workit touches a similarly named thing20:52
rm_workbut not the same one20:52
openstackgerritAdam Harwell proposed openstack/neutron-lbaas master: Fix neutron-lbaas gates  https://review.openstack.org/44616920:53
diltramok I see20:53
rm_worki missed a file20:53
rm_worknow should be ok20:53
diltrambut if I'm right now we need to change just one line in this patch20:54
rm_workerr20:54
rm_worki think it still needs all of that?20:54
rm_workit's touching a different var from a different import20:54
diltrambut your fix will not work without changes from this Sindhu's patch20:55
rm_workno, it should be fine20:55
rm_workTHOSE haven't changed yet20:55
rm_workthey're completely different, just similarly named20:55
rm_workit's technically unrelated20:55
diltramok20:57
diltramyour right20:57
diltramso how I can now revert code to previous revision?20:57
rm_workerr20:57
rm_workcheckout the old revision20:57
rm_workand do a review20:57
openstackgerritLubosz Kosnik (diltram) proposed openstack/neutron-lbaas master: Updating import for linux/interface opts  https://review.openstack.org/35247120:58
nmagnezithey should really add a button for that ^ :P20:58
diltramdone20:58
rm_workoh nice20:58
diltramtrue :P20:58
rm_workthe +A even came back lol20:58
rm_workofc now it's in merge conflict lol20:59
diltramyay21:00
nmagnezijohnsom, i actually had a question about containers :)21:00
diltramit's awesome :/21:00
rm_workm-greene-: to my knowledge barbican for certificate-containers is still write-once21:00
openstackgerritLubosz Kosnik (diltram) proposed openstack/neutron-lbaas master: Updating import for linux/interface opts  https://review.openstack.org/35247121:01
johnsomnmagnezi Go for it21:01
nmagnezijohnsom, i know diltram is working on nova-lxd based amps. will you also be open to an addtional driver using kubernetes?21:01
johnsomnmagnezi I am open to anything if it will work....21:02
nmagnezifair enough :)21:02
nmagneziyou are saying that because there is a known issue with this?21:02
johnsomnmagnezi Concerns are around hot-plugging the neutron ports and if they will get rebooted randomly21:02
m-greene-rm_work: ok, was thinking ahead if the container will ever support update21:02
rm_workm-greene-: it was understood that at least for certificate-container type, that will never happen21:03
rm_workgeneric containers might be write-many21:03
rm_workbut cert-containers should never be21:03
johnsomYeah, that was part of the design (and a smart one if you ask me)21:03
rm_work:)21:03
rm_workjohnsom: https://review.openstack.org/#/c/446169/ followed by https://review.openstack.org/#/c/446144/ shortly21:05
rm_workwaiting on zuul21:05
rm_work*should* be good21:05
johnsomOk21:05
nmagnezijohnsom, I have homework to do in this area, so i don't 100% sure i know what is the issue with hot-plugging (i know this is a problem in general with containers). but can't kuryr help with this?21:05
rm_workok fff i gotta go21:06
diltramnmagnezi: not really21:06
rm_workfeel free to poke those patches if something breaks21:06
diltramthere is support for it in docker itself21:06
diltramwhat people said to us from your company21:06
nmagnezi"i don't 100% sure" wow i need to call it a day.. :D21:06
johnsomYeah.21:07
johnsomHA21:07
rm_workUGH yep there's the py27 fail21:07
johnsomI think that we just need to understand more about how you could make kubernetes more friendly to processing network streams and less "cloud app" like21:07
diltramagree21:08
johnsommoving web servers and such around is not a problem so much, but an LB processing a TLS network stream becomes a bit complicated.21:08
xgermanto be fair K8 has pet-sets which don’t move21:09
rm_workfix incoming21:09
diltramrm_work: kk21:09
*** richbrowne has quit IRC21:09
johnsomxgerman There you go, that may be a solution21:09
xgermandone and done :-)21:10
diltrambut still there is no support for hotplug21:10
xgermanaren’t they proxting the network everyhwere21:11
xgermanwell, the Kurier people wanted us to be a replacement for the kube-proxy21:11
xgermanso won’t work for them21:11
diltramthey do, this is why our security and all is broken21:11
nmagnezijohnsom, diltram, alright. thank you for the answers guys :)21:12
xgermanwell, today I chatted with somebody who is using Octavia to loadbalance the k8 etcd servers21:13
xgerman(among other things)21:13
johnsomnmagnezi Summary: Make it happen!  grin21:13
xgermanlol21:13
diltramxgerman: it's not hard to be made with k8s21:14
diltramit's all about how you're deploying your stuff21:14
nmagnezijohnsom, lol.21:14
nmagnezijohnsom, roger :)21:14
diltramif you have k8s on openstack it's easy21:14
openstackgerritAdam Harwell proposed openstack/neutron-lbaas master: Fix neutron-lbaas gates  https://review.openstack.org/44616921:14
rm_workdiltram: ok THAT should do it21:14
rm_workactually ran tests this time <_<21:14
xgermanwell, running etcd through and LN wouldn’t be my first thought21:15
diltramyou have my +221:15
diltramgoing home21:15
rm_workkk21:15
rm_workthanks21:15
rm_workgoing to sleep :)21:15
johnsomSee you folks21:15
diltramo/21:16
xgermano/21:16
rm_workhopefully you can +A that before you have to sign off21:16
johnsomI still have 3 hours, so it should happen21:16
rm_workcool21:17
*** eezhova has joined #openstack-lbaas21:17
rm_workhopefully i didn't mess it up on the fifth try :P21:17
openstackgerritMichael Johnson proposed openstack/octavia-dashboard master: Updating for octavia-dashboard  https://review.openstack.org/44617821:18
rm_workjohnsom: https://github.com/openstack/octavia/blob/master/octavia/tests/contrib/gate_hook.sh#L9821:26
rm_workthis file doesn't exist in octavia repo, only neutron-lbaas21:26
rm_workis that intended to only run when neutron-lbaas is the PROJECT21:27
rm_work?21:27
rm_workerr nm it can't be the PROJECT21:27
rm_workso uhhh21:27
rm_workhow does that work21:27
rm_workor does it not ever work21:27
rm_workugh back later21:28
johnsomMy guess is that it silently failes21:28
johnsomfails21:28
rm_workk21:28
rm_workbut we're -ex21:29
rm_workah well dunno21:29
* rm_work disappears21:29
johnsomActually, I don't think that runs.  I ended up running the octavia functional tests a different way.21:33
*** eezhova has quit IRC21:36
*** gcheresh has quit IRC21:44
openstackgerritShashank Kumar Shankar proposed openstack/octavia master: Run Octavia API in a WSGI server  https://review.openstack.org/44093422:10
*** armax has quit IRC22:19
*** aojea has joined #openstack-lbaas22:20
johnsomxgerman if you are still online: https://review.openstack.org/#/c/44614422:24
xgermank22:25
*** gongysh has joined #openstack-lbaas22:37
*** zioproto has joined #openstack-lbaas22:59
*** catinthe_ has quit IRC23:02
*** aojea has quit IRC23:14
*** aojea has joined #openstack-lbaas23:14
*** aojea has quit IRC23:18
openstackgerritMerged openstack/neutron-lbaas master: Fix neutron-lbaas gates  https://review.openstack.org/44616923:21
openstackgerritMerged openstack/octavia master: fix py3x test bug so functional tests will pass  https://review.openstack.org/44614423:21
openstackgerritAnkur proposed openstack/python-octaviaclient master: [WIP] Initialize plugin for OSC  https://review.openstack.org/44622323:26
*** diltram has quit IRC23:39
*** ndahiwade has joined #openstack-lbaas23:52
« Tuesday, 2017-03-14 Index Thursday, 2017-03-16 »

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