| *** madhu_ak has quit IRC | 00:05 | |
| openstackgerrit | min wang proposed openstack/neutron-lbaas: Admin_state_up tempest test for health monitor https://review.openstack.org/178827 | 00:07 |
|---|---|---|
| *** rm_you has quit IRC | 00:09 | |
| *** rm_you has joined #openstack-lbaas | 00:15 | |
| *** sballe has quit IRC | 00:22 | |
| *** AndroUser has joined #openstack-lbaas | 00:29 | |
| *** AndroUser is now known as madhu_ak | 00:30 | |
| dougwig | ajmiller: you propose an experimental job first. | 00:32 |
| dougwig | madhu_ak, ajmiller: commented. | 00:37 |
| madhu_ak | Thanks dougwig | 00:39 |
| openstackgerrit | Akihiro Motoki proposed openstack/neutron-lbaas: Enable db migration head check https://review.openstack.org/199518 | 01:07 |
| *** vivek-ebay has quit IRC | 01:09 | |
| *** amotoki has joined #openstack-lbaas | 01:10 | |
| *** madhu_ak has quit IRC | 01:12 | |
| *** vivek-ebay has joined #openstack-lbaas | 01:13 | |
| *** vivek-ebay has quit IRC | 01:14 | |
| *** vivek-ebay has joined #openstack-lbaas | 01:14 | |
| *** vivek-ebay has quit IRC | 01:17 | |
| *** vivek-ebay has joined #openstack-lbaas | 01:28 | |
| *** vivek-ebay has quit IRC | 01:43 | |
| *** bitblt has quit IRC | 01:45 | |
| *** fnaval_ has quit IRC | 02:02 | |
| *** fnaval has joined #openstack-lbaas | 02:12 | |
| *** cing has joined #openstack-lbaas | 02:14 | |
| *** cing has quit IRC | 02:14 | |
| *** cing has joined #openstack-lbaas | 02:14 | |
| *** sbalukoff has quit IRC | 02:26 | |
| *** ganeshna has joined #openstack-lbaas | 02:55 | |
| *** rbrooker has quit IRC | 02:56 | |
| *** ganeshna has quit IRC | 03:08 | |
| *** ganeshna has joined #openstack-lbaas | 03:12 | |
| *** ganeshna has quit IRC | 03:17 | |
| *** ganeshna has joined #openstack-lbaas | 03:18 | |
| *** crc32 has joined #openstack-lbaas | 03:21 | |
| *** blogan_ has joined #openstack-lbaas | 03:36 | |
| *** amotoki has quit IRC | 03:37 | |
| *** vivek-ebay has joined #openstack-lbaas | 03:40 | |
| *** blogan_ has quit IRC | 03:47 | |
| *** kiran-r has joined #openstack-lbaas | 03:51 | |
| *** amotoki has joined #openstack-lbaas | 03:51 | |
| *** fnaval has quit IRC | 03:52 | |
| *** ganeshna has quit IRC | 04:02 | |
| *** sbalukoff has joined #openstack-lbaas | 04:03 | |
| *** ganeshna has joined #openstack-lbaas | 04:07 | |
| *** vivek-eb_ has joined #openstack-lbaas | 04:11 | |
| *** ganeshna has quit IRC | 04:11 | |
| *** vjay has joined #openstack-lbaas | 04:12 | |
| *** vivek-ebay has quit IRC | 04:13 | |
| *** ajmiller_ has joined #openstack-lbaas | 04:14 | |
| *** ganeshna has joined #openstack-lbaas | 04:14 | |
| *** amotoki has quit IRC | 04:17 | |
| *** amotoki has joined #openstack-lbaas | 04:23 | |
| *** kiran-r has quit IRC | 04:25 | |
| *** amotoki has quit IRC | 04:33 | |
| *** ganeshna has quit IRC | 04:34 | |
| *** vjay has quit IRC | 04:34 | |
| *** ganeshna has joined #openstack-lbaas | 04:37 | |
| *** woodster_ has quit IRC | 04:41 | |
| *** amotoki has joined #openstack-lbaas | 04:43 | |
| *** vivek-eb_ has quit IRC | 04:43 | |
| rm_work | ptoohill: poke | 04:54 |
| rm_work | ptoohill: ah, thought i saw you post something recently, but it must have just been my IRC client giving me super delayed notifications T_T | 04:54 |
| *** ajmiller_ has quit IRC | 05:07 | |
| *** ganeshna has quit IRC | 05:08 | |
| *** ganeshna has joined #openstack-lbaas | 05:11 | |
| *** ganeshna_ has joined #openstack-lbaas | 05:17 | |
| *** ganeshna has quit IRC | 05:18 | |
| *** numan has joined #openstack-lbaas | 05:19 | |
| *** ganeshna_ has quit IRC | 05:21 | |
| *** ganeshna has joined #openstack-lbaas | 05:31 | |
| *** ganeshna_ has joined #openstack-lbaas | 05:36 | |
| *** ganeshna has quit IRC | 05:36 | |
| *** ganeshna_ has quit IRC | 05:40 | |
| *** ganeshna has joined #openstack-lbaas | 05:43 | |
| *** ganeshna has quit IRC | 05:47 | |
| *** ig0r_ has joined #openstack-lbaas | 05:51 | |
| *** ig0r__ has quit IRC | 05:55 | |
| *** ganeshna has joined #openstack-lbaas | 06:01 | |
| *** davidlenwell has quit IRC | 06:06 | |
| *** davidlenwell has joined #openstack-lbaas | 06:08 | |
| *** Alex_Stef has joined #openstack-lbaas | 06:17 | |
| *** kiran-r has joined #openstack-lbaas | 06:19 | |
| *** nmagnezi has joined #openstack-lbaas | 06:22 | |
| *** crc32 has quit IRC | 06:23 | |
| *** _kiran_ has joined #openstack-lbaas | 06:48 | |
| *** kiran-r has quit IRC | 06:51 | |
| *** Tiancheng has joined #openstack-lbaas | 06:54 | |
| *** ganeshna has quit IRC | 06:57 | |
| Alex_Stef | hi all | 06:58 |
| Alex_Stef | I have a few question pls. Do we support lbbas ns (name spaces) migration? What version of ssl we support for Loadbalancing? what kind of connection is considered "opened connection" ( close wait? ) for LEAST CONNECTIONS LB | 07:01 |
| Alex_Stef | tnx | 07:01 |
| *** _kiran_ has quit IRC | 07:08 | |
| *** enikanorov2 has joined #openstack-lbaas | 07:13 | |
| *** apuimedo has joined #openstack-lbaas | 07:18 | |
| *** Miouge has joined #openstack-lbaas | 07:20 | |
| *** amotoki_ has joined #openstack-lbaas | 07:47 | |
| *** amotoki has quit IRC | 07:49 | |
| *** ganeshna has joined #openstack-lbaas | 07:52 | |
| *** kobis has joined #openstack-lbaas | 08:06 | |
| openstackgerrit | Phillip Toohill proposed openstack/octavia: Adding new network driver https://review.openstack.org/197858 | 08:06 |
| openstackgerrit | Phillip Toohill proposed openstack/octavia: Updates for containers functionality https://review.openstack.org/199954 | 08:15 |
| *** ganeshna_ has joined #openstack-lbaas | 08:17 | |
| *** ganeshna has quit IRC | 08:18 | |
| *** vjay has joined #openstack-lbaas | 08:23 | |
| *** ganeshna_ has quit IRC | 08:31 | |
| *** ganeshna has joined #openstack-lbaas | 08:38 | |
| *** ganeshna has quit IRC | 08:39 | |
| *** ganeshna has joined #openstack-lbaas | 08:40 | |
| *** kiran-r has joined #openstack-lbaas | 08:49 | |
| *** vjay has quit IRC | 08:52 | |
| *** Alex_Stef has quit IRC | 08:54 | |
| *** amotoki_ has quit IRC | 09:02 | |
| *** ganeshna_ has joined #openstack-lbaas | 09:06 | |
| *** ganeshna has quit IRC | 09:08 | |
| *** Alex_Stef has joined #openstack-lbaas | 09:14 | |
| *** ganeshna_ has quit IRC | 10:09 | |
| *** ganeshna has joined #openstack-lbaas | 10:09 | |
| *** mmdurrant has quit IRC | 10:09 | |
| *** ganeshna_ has joined #openstack-lbaas | 10:13 | |
| *** ganeshna has quit IRC | 10:16 | |
| *** ganeshna_ has quit IRC | 10:21 | |
| *** ganeshna has joined #openstack-lbaas | 10:22 | |
| *** ganeshna has quit IRC | 10:25 | |
| *** ganeshna has joined #openstack-lbaas | 10:25 | |
| *** Tiancheng has quit IRC | 11:06 | |
| *** ganeshna_ has joined #openstack-lbaas | 11:10 | |
| *** ganeshna has quit IRC | 11:11 | |
| *** ganeshna has joined #openstack-lbaas | 11:15 | |
| *** ganeshna_ has quit IRC | 11:16 | |
| *** ganeshna has quit IRC | 11:25 | |
| *** Miouge_ has joined #openstack-lbaas | 11:32 | |
| *** Miouge has quit IRC | 11:35 | |
| *** Miouge_ is now known as Miouge | 11:35 | |
| *** cing has quit IRC | 11:39 | |
| *** mmdurrant has joined #openstack-lbaas | 11:59 | |
| *** Miouge has quit IRC | 12:20 | |
| *** Miouge has joined #openstack-lbaas | 12:21 | |
| *** Tiancheng has joined #openstack-lbaas | 12:35 | |
| *** cing has joined #openstack-lbaas | 12:36 | |
| *** pserebryakov has joined #openstack-lbaas | 12:48 | |
| *** nmagnezi has quit IRC | 12:51 | |
| *** numan has quit IRC | 12:55 | |
| *** amotoki has joined #openstack-lbaas | 12:56 | |
| *** nmagnezi has joined #openstack-lbaas | 13:04 | |
| *** Tiancheng has quit IRC | 13:08 | |
| *** amotoki has quit IRC | 13:09 | |
| *** Miouge has quit IRC | 13:10 | |
| *** rbrooker has joined #openstack-lbaas | 13:13 | |
| *** Miouge has joined #openstack-lbaas | 13:15 | |
| *** amotoki has joined #openstack-lbaas | 13:16 | |
| *** Miouge has quit IRC | 13:17 | |
| *** Miouge has joined #openstack-lbaas | 13:18 | |
| *** amotoki has quit IRC | 13:28 | |
| *** amotoki_ has joined #openstack-lbaas | 13:28 | |
| *** rbrooker has quit IRC | 13:51 | |
| *** kiran-r has quit IRC | 13:58 | |
| *** amotoki has joined #openstack-lbaas | 13:58 | |
| *** pserebryakov has quit IRC | 14:00 | |
| *** amotoki_ has quit IRC | 14:01 | |
| *** amotoki has quit IRC | 14:03 | |
| *** jhova has joined #openstack-lbaas | 14:09 | |
| *** cing has quit IRC | 14:19 | |
| *** fnaval has joined #openstack-lbaas | 14:27 | |
| *** amotoki has joined #openstack-lbaas | 14:29 | |
| *** Alex_Stef has quit IRC | 14:45 | |
| *** mlavalle has joined #openstack-lbaas | 14:56 | |
| *** kobis has quit IRC | 14:56 | |
| *** vivek-ebay has joined #openstack-lbaas | 15:03 | |
| *** TrevorV has joined #openstack-lbaas | 15:03 | |
| *** vivek-ebay has quit IRC | 15:06 | |
| *** nmagnezi has quit IRC | 15:07 | |
| *** rm_you has quit IRC | 15:33 | |
| *** rm_you has joined #openstack-lbaas | 15:33 | |
| *** Miouge has quit IRC | 15:35 | |
| *** cing has joined #openstack-lbaas | 15:46 | |
| *** Miouge has joined #openstack-lbaas | 15:52 | |
| *** jschwarz has joined #openstack-lbaas | 16:00 | |
| *** nmagnezi has joined #openstack-lbaas | 16:02 | |
| *** bitblt has joined #openstack-lbaas | 16:03 | |
| *** Miouge has quit IRC | 16:13 | |
| *** Miouge has joined #openstack-lbaas | 16:22 | |
| *** vivek-ebay has joined #openstack-lbaas | 16:29 | |
| *** kiran-r has joined #openstack-lbaas | 16:33 | |
| *** vivek-ebay has quit IRC | 16:34 | |
| *** numan has joined #openstack-lbaas | 16:35 | |
| *** mgarza_ has joined #openstack-lbaas | 16:35 | |
| *** vivek-ebay has joined #openstack-lbaas | 16:38 | |
| *** madhu_ak has joined #openstack-lbaas | 16:40 | |
| *** bitblt has quit IRC | 16:45 | |
| *** Miouge has quit IRC | 16:47 | |
| *** sballe has joined #openstack-lbaas | 16:55 | |
| *** mmdurrant has quit IRC | 16:57 | |
| *** Miouge has joined #openstack-lbaas | 16:57 | |
| *** mmdurrant has joined #openstack-lbaas | 16:57 | |
| *** sbalukoff has quit IRC | 16:58 | |
| *** localloop127 has joined #openstack-lbaas | 17:00 | |
| *** cing has quit IRC | 17:02 | |
| *** sbalukoff has joined #openstack-lbaas | 17:10 | |
| *** rbrooker has joined #openstack-lbaas | 17:11 | |
| *** nmagnezi has quit IRC | 17:25 | |
| *** jschwarz has quit IRC | 17:27 | |
| *** enikanorov2 has quit IRC | 17:41 | |
| *** enikanorov2 has joined #openstack-lbaas | 17:53 | |
| *** SumitNaiksatam has joined #openstack-lbaas | 17:59 | |
| *** davidlenwell has quit IRC | 18:03 | |
| *** davidlenwell has joined #openstack-lbaas | 18:05 | |
| *** kiran-r has quit IRC | 18:09 | |
| TrevorV | ajmiller, xgerman you guys know where min is? | 18:13 |
| ajmiller | TrevorV she's sitting right next to me. | 18:13 |
| TrevorV | Could you have her jump in IRC my man? | 18:14 |
| ajmiller | Sure. We are having our scrum now, it might be a few minutes.. | 18:14 |
| TrevorV | Oh sorry I don't mean to interrupt | 18:14 |
| TrevorV | No rush | 18:14 |
| *** mwang2 has joined #openstack-lbaas | 18:22 | |
| *** mwang2_ has joined #openstack-lbaas | 18:23 | |
| *** rbrooker has quit IRC | 18:34 | |
| xgerman | TrevorV mwang2 filled me in | 18:46 |
| xgerman | so housekeeping has two jobs | 18:46 |
| TrevorV | filled you in? | 18:46 |
| TrevorV | Oh gotcha | 18:46 |
| xgerman | 1) Keep a pool of spare amphora | 18:46 |
| xgerman | 2) Clean up Amphora | 18:46 |
| xgerman | For (2) I think the health manager will issue commands on a queue | 18:46 |
| xgerman | right now the health manager keeps track of the state in the database - so theoreticlaly you could query the DB, too | 18:47 |
| TrevorV | blogan, ^^ if you're around maybe read and chime in here with us | 18:47 |
| xgerman | just thinking out loud | 18:47 |
| xgerman | yeah, I like a queue better for scalability... | 18:48 |
| xgerman | (and locking) | 18:48 |
| TrevorV | xgerman, as far as I understand Rax has somewhat de-prioritized the spare-pool concept, though I won't exclude it in my efforts after we get the bits we're primarily concerned with. | 18:48 |
| TrevorV | As for the deletion step, its a bit easier than I think you're thinking right now. | 18:49 |
| xgerman | well, I am ok with not doing (1) since we might jump straight to containers as well | 18:49 |
| TrevorV | Right now, as part of the LB deletion step, it actually issues commands to delete the physical amphora if there are no LB's on it. | 18:49 |
| openstackgerrit | Aishwarya Thangappa proposed openstack/neutron-lbaas: Modified base.py to include common functionalities of DataDrivenTests https://review.openstack.org/191217 | 18:49 |
| TrevorV | Meaning, there is a high potential there will be no need for a queuing system. | 18:49 |
| openstackgerrit | Aishwarya Thangappa proposed openstack/neutron-lbaas: Tempest tests for Listener using testscenarios. https://review.openstack.org/179818 | 18:50 |
| TrevorV | Basically the deletion step for an amp right now nukes the container/VM, and marks the amp "DELETED" in the DB. | 18:50 |
| openstackgerrit | Aishwarya Thangappa proposed openstack/neutron-lbaas: Tempest tests for Members using testscenarios. https://review.openstack.org/180436 | 18:50 |
| TrevorV | After <pick a period of time>, the housekeeper will delete older than that time entries in the DB. | 18:50 |
| xgerman | but that is triggered from the API via queue — so the health monitor would need a way to trigger that, too, as part of fail over | 18:51 |
| TrevorV | I don't know that I exactly follow. The health monitor will have that functionality built into itself, or are you talking about the "amphoraHealthManager" or whatever being a centralized location for these actions? | 18:52 |
| TrevorV | Health monitor just calling those actions? | 18:52 |
| xgerman | there is a HealthManager process which currently receives the health messages and writes them to the DB | 18:53 |
| TrevorV | Right | 18:53 |
| xgerman | so if a LB gets sick we need to replace it | 18:53 |
| xgerman | and the idea was to hand off the deleting to the housekeeper | 18:53 |
| TrevorV | Yeah, so it'll call the appropriate "delete amp" methods, and then at a regular interval the house-keeper would clean up the db entries. | 18:53 |
| xgerman | yeah, and originally we wanted the house keeper to also call nova | 18:54 |
| xgerman | but that might have been the wrong idea | 18:54 |
| TrevorV | I'm trying to remember. | 18:54 |
| TrevorV | So I don't know why the health manager should work any differently than the API delete LB call. | 18:55 |
| TrevorV | I mean, at a different layer, yes. | 18:55 |
| xgerman | yeah, and you are probably right | 18:55 |
| TrevorV | But the house-keeping stuff will be a separate process, and I don't think it should be started/spawned/ran by the health manager. | 18:55 |
| xgerman | yep | 18:55 |
| xgerman | health manager might need to run it’s own flows | 18:56 |
| TrevorV | Carlos from Rax has been doing the health manager stuff if I remember right, so I'll ask him shortly if that was his thought process as well. | 18:56 |
| TrevorV | Regardless though, I'm still curious where the health_mixin was supposed to fit in | 18:56 |
| TrevorV | As I told min, I don't see it being used by anything specifically at the moment | 18:56 |
| xgerman | yeah, I wanted to see some WIP so I understand where we are at | 18:56 |
| xgerman | health_mixi is the conduit the amphora_driver tells the health_manager what to write to the DB | 18:57 |
| xgerman | so basically the amphora driver get the health values and then calls the mixi (which is implemented in the health manager) | 18:57 |
| TrevorV | I don't see that though, did I miss something? | 18:58 |
| TrevorV | by amp driver you're talking about the REST API you wrote and the ssh_driver we're using, right? | 18:58 |
| xgerman | no, any amphora driver | 18:58 |
| xgerman | the amphora driver will have a way to determine the health and then the mixin writes it to the DB | 19:00 |
| xgerman | (or whatever we wa=nt to do) | 19:00 |
| TrevorV | So in the case of my ssh_driver, I don't use the health mixin. Should I have? | 19:00 |
| xgerman | so what is missing is Carlos’ piece to retrieve the health info and hand it to the mixin | 19:00 |
| TrevorV | Sorry about my confusion, I'm just trying to fit all the pieces together, ya know? | 19:02 |
| xgerman | yep | 19:02 |
| mwang2 | thank you xgerman to join in | 19:03 |
| blogan | im here | 19:04 |
| TrevorV | While I organize my thoughts I'll let blogan catch up on the scrollback | 19:05 |
| blogan | but yeah i think xgerman is right, the healthmanager should instantiate the health mixin in some form (perhaps its just instantiate the amp driver, not sure if we decided the how) | 19:05 |
| blogan | xgerman: i believe the mixin should not be used by the housekeeper, but only by healthmanager | 19:12 |
| blogan | xgerman: would you agree on that? | 19:12 |
| xgerman | yes | 19:12 |
| blogan | xgerman: and it looks like the amphora driver should inherit from this and the healthmanger instantias the amphora driver and just calls this method | 19:12 |
| xgerman | the other way around | 19:13 |
| blogan | ah the amphora driver starts the health manager | 19:13 |
| blogan | oh yeah i remember this now :) | 19:13 |
| xgerman | :-) | 19:13 |
| blogan | but i'm rethinking that now, bc we do have a healthmanager process start cmd already, and if the amphora driver starts this on instantiation, there's no reason to have that | 19:15 |
| blogan | whereas if the healthmanager just instantiated amp driver (through stevedore) we'd be able to keep that process instead of having to spawn a process in code | 19:16 |
| TrevorV | I'm also thinking health management should be different than the configuration of an amphora. | 19:16 |
| blogan | but cant remember if we already discussed that and it had issues | 19:16 |
| *** rbrooker has joined #openstack-lbaas | 19:19 | |
| xgerman | so the plan was that the health manager would fork a process and run some thing in the anphora_driver which receives the health info and calls the mixin | 19:22 |
| *** numan has quit IRC | 19:23 | |
| blogan | yeah so that invalidates having the cmd.health_manager.py, which that is nice to have bc its easy to see what agents are being run | 19:25 |
| blogan | also means when we got to having multiple o-cw processes, we aren't always going to spin up another health maanger process if we dont need it | 19:27 |
| xgerman | health manager also does the fail over flow | 19:30 |
| xgerman | or would you have o-cw do that | 19:30 |
| xgerman | ? | 19:30 |
| xgerman | the flows are sort of a library we can use everywhere | 19:30 |
| xgerman | also stats are supposed to come in to some degree that way | 19:33 |
| *** mixos has joined #openstack-lbaas | 19:36 | |
| blogan | yeah the way i'm thinking of doing this wouldn't be much different than we've proposed, other than the amp_driver does not spawn the process, it just provides the callbacks run whatever code teh amp_driver says it needs to be run for health management | 19:36 |
| * TrevorV disagrees with blogan on this, but I'm being overruled, so RIP me | 19:36 | |
| xgerman | the amp think will likely listen on some socket and ship the UDP packets up to the mixin | 19:37 |
| blogan | TrevorV wants something totally different | 19:37 |
| xgerman | a larch? | 19:37 |
| TrevorV | Its not "totally different", its just not direct coupling to the amp_driver. | 19:38 |
| blogan | xgerman: yeah what im saying is it would still do that, but it woudln't be responsible for spawning the process | 19:38 |
| xgerman | oh, ok, that’s cool with me | 19:38 |
| blogan | and it should be coupled with the amp_driver bc how the helath is determined is specific to teh amphorae | 19:38 |
| xgerman | yeah, since I felt the amp_driver would be a good place :-) | 19:39 |
| *** nmagnezi has joined #openstack-lbaas | 19:39 | |
| xgerman | but we also kicked the idea of a separate health driver around a few times | 19:39 |
| TrevorV | I agree it has ties to what type of amphora you're creating, but not the actual creation and update methods... meaning it should be able to exist as its own independent system. However, you disagree so whatever. | 19:40 |
| ptoohill | So, you are wanting its own methods not tied to the amp driver TrevorV | 19:41 |
| xgerman | health driver? | 19:42 |
| TrevorV | Yeah, but also no communication to the amp_driver because it shouldn't need to, IMO. If we think it should, then fine, but I don't think it should. | 19:42 |
| TrevorV | health drivers would be fine with me, for example, if someone wanted a poll model rather than a heartbeat push model. | 19:42 |
| ptoohill | If we split it up like that then each type of amphora would need its own health 'thing', if you 'couple it to the driver you get use the methods designed to work with that driver | 19:43 |
| ptoohill | im probably way out of loop here, ill stay quite | 19:43 |
| TrevorV | That's similar to blogan 's argument ptoohill so you're not way off | 19:44 |
| ptoohill | I guess i dont see why it wouldnt be tied to it considering we wrote a driver to handle that particular amphora, so instead of writing new things to handle the same things make use of what's there? | 19:44 |
| xgerman | well, some drivers might reuse code from the amphora driver (e.g. an ssh driver doing poll could do that) others are completely independent | 19:45 |
| TrevorV | However, I still think its not a problem decoupling it because you'll still call a method that's based on an interface to delete an amp, and the same for creating one, and that's that./ | 19:45 |
| TrevorV | that.*** | 19:45 |
| ptoohill | Octavia is like Ogre | 19:45 |
| ptoohill | It has layers | 19:45 |
| *** mwang2 has quit IRC | 19:45 | |
| xgerman | also we haven’t defined the health stuff very well — so the interface is still a bit “incomplete" | 19:46 |
| *** nmagnezi has quit IRC | 19:46 | |
| TrevorV | I guess what I'm getting at is I don't like what I'm going to call 'shadow-drivers' | 19:47 |
| *** mwang2_ has quit IRC | 19:47 | |
| TrevorV | If you make it individual code with a direct tie to the amp_driver, you then have a driverized health_manager without an actual driver layer and structure. | 19:47 |
| *** mlavalle has quit IRC | 19:47 | |
| openstackgerrit | Aishwarya Thangappa proposed openstack/neutron-lbaas: Added admin/non_admin api tests https://review.openstack.org/173423 | 19:48 |
| TrevorV | I'm arguing it shouldn't be that way. It should be an isolated piece that calls amp_driver methods without anything distinct in the call. | 19:48 |
| TrevorV | By that I mean the interface request, not the specific amp_driver request. | 19:48 |
| TrevorV | I may be confusing myself here. | 19:48 |
| xgerman | well, you got me confused | 19:49 |
| TrevorV | Give me a second to describe what I expect. | 19:49 |
| TrevorV | After I organize my thoughts. | 19:49 |
| xgerman | I can see how the code for the health piece can stand on his own in some implementations | 19:49 |
| TrevorV | Alright, so current implementations of amp_driver is "create/update/delete/get" for an amp. | 19:50 |
| TrevorV | I guess you could say its CRUD for amps, with an inclusion for stats and such from the amp. | 19:51 |
| TrevorV | Now we discuss the health management of existing and built amps. | 19:51 |
| TrevorV | Interface will have the following: "check_health", "update_db", and maybe something that does the processing of the health stuff. | 19:52 |
| TrevorV | This being an interface, for a PUSH model, check health will be a listening process receiving heartbeats that'll thread to process each heartbeat, right? | 19:52 |
| TrevorV | So if it was a POLL system, you'd have check health make a thread that then connects to the amp in whatever way implemented to get its status, and then call process | 19:53 |
| TrevorV | processing method | 19:53 |
| TrevorV | *** | 19:53 |
| TrevorV | After that, you update the db accordingly. | 19:53 |
| TrevorV | This action doesn't have any direct relationship to the amp_driver. | 19:53 |
| xgerman | well, health manager would | 19:53 |
| TrevorV | Or am I missing something? | 19:53 |
| xgerman | you basically got it | 19:54 |
| TrevorV | Right, so there is no direct coupling necessary for the amp_driver and the health_manager. | 19:54 |
| xgerman | yep, but the code need to go somewhere | 19:55 |
| TrevorV | That is unless I'm missing something, which is HIGHLY possible. | 19:55 |
| TrevorV | Yeah, in a "health_manager.py" or something | 19:55 |
| xgerman | so in the poll case you might want to reuse the way the amp driver talks to the ampohora | 19:55 |
| TrevorV | That spawns as its own process in the cmd stuffs, and doesn't have to contact the amp_driver for any reason other than to potentially delete an unhealthy amp and recreating it or what not | 19:55 |
| *** crc32 has joined #openstack-lbaas | 19:55 | |
| TrevorV | Alright, but you don't have to ask the amp_driver how it communicates. | 19:56 |
| TrevorV | You'd pick an amp_driver, and a hm_driver accordingly that both fit your deployment scenario, right? | 19:56 |
| xgerman | yep, I can see that possibility | 19:57 |
| TrevorV | I guess what I'm getting at is I don't like the idea of "ssh_poll_driver" and "ssh_listen_driver" and etc etc etc for all the diff ssh_drivers... It should be just ssh_driver, and then "poll_hm_driver" or something | 19:57 |
| TrevorV | If that's not what we want to do, then RIP my ideas | 19:58 |
| xgerman | it definitely has merit and we discussed it (rm_work is a proponent) — since the REST driver and ssh driver will likely share the same health driver | 19:58 |
| xgerman | but we wanted to keep it under the roof of the amp driver… but there is no technical rason not to split it out | 19:59 |
| xgerman | and if somebody needs it under the same roof they can just implement both interfaces on the same driver | 20:00 |
| *** nmagnezi has joined #openstack-lbaas | 20:04 | |
| TrevorV | Entirely possible xgerman . So blogan still wants to talk to me about it, so I'll swing over there after the meeting I'm in right now, and come back to discuss what we come up with | 20:06 |
| blogan | i think there's arguments for both | 20:09 |
| TrevorV | I don't know that I agree with the argument for the "shadow-driver" but we'll discuss here in a minute | 20:11 |
| TrevorV | good news, I got my answer about the amphora_health class ha ha ha. | 20:11 |
| xgerman | nice | 20:11 |
| blogan | got an answer with more questions | 20:11 |
| xgerman | at least that worked out | 20:11 |
| TrevorV | Well I can move forward with the house-keeping is my point | 20:12 |
| *** mwang2 has joined #openstack-lbaas | 20:12 | |
| blogan | true | 20:12 |
| TrevorV | But the health management does have may questions that should be answered asap | 20:12 |
| blogan | of course, but honestly we're only going to have one implementation of the health manager, so going from one design paradigm to the other would be little work | 20:14 |
| *** mlavalle has joined #openstack-lbaas | 20:17 | |
| xgerman | and don’t forget we have a fact to face in a week we can discuss that all in person and in detail | 20:17 |
| TrevorV | xgerman, I'm honestly okay with waiting until next week to get a full discussion on it, sure, but that may or may not stall crc32 in his work effort | 20:18 |
| xgerman | yeah, I don’t like to stall people but it shouldn’t matter for the socket code how we skin that cat | 20:19 |
| TrevorV | Yeah, but there are a lot of parts to the health manager, and if he finishes the bit that you just mentioned he'll be stalled on this discussion piece. | 20:20 |
| *** nmagnezi has quit IRC | 20:20 | |
| TrevorV | However, that's neither here nor there at this point | 20:20 |
| TrevorV | Like I said, I'm okay with waiting. | 20:20 |
| TrevorV | I will still talk with blogan here in a minute | 20:20 |
| xgerman | well, the database piece is written | 20:20 |
| TrevorV | Maybe he'll have some way to change my mind. | 20:20 |
| xgerman | :-) | 20:20 |
| TrevorV | xgerman, you're referring to the amphora_health table? | 20:21 |
| TrevorV | table/model? | 20:21 |
| xgerman | no, there is an implementation of the health mixi which updates the database | 20:21 |
| TrevorV | Your REST stuff utilizes it then? | 20:22 |
| TrevorV | Cuz I don't see the health_mixi being used in code anywhere that I've looked in current master | 20:22 |
| TrevorV | except for testing | 20:22 |
| xgerman | no, we did;’t get to the pice which gets stuff from the amphora | 20:22 |
| TrevorV | sorry, I always miss that bit. | 20:22 |
| TrevorV | Oh I thought you meant outside that one method that would be utilized by the health manager | 20:22 |
| TrevorV | You're talking about that, right? | 20:22 |
| xgerman | yep | 20:23 |
| TrevorV | Right right. I'm not talking about nuking that anyway, so yes that bit should be utilized. | 20:23 |
| TrevorV | We just have to figure out the other part that I'm concerned about. | 20:23 |
| blogan | crc32 can still get the code written as much, but we can decide wehre that code lives and how it gets loaded, not much of a stall | 20:26 |
| TrevorV | That's true. Yeah, no big deal then xgerman | 20:26 |
| blogan | ive told crc32 to just get the code written, we can prettyify it and decompose it at the meetup | 20:27 |
| xgerman | cool | 20:27 |
| crc32 | :/ | 20:48 |
| *** Miouge has quit IRC | 20:58 | |
| TrevorV | xgerman, blogan and I just finished talking, and we're sort of in agreement about it being driverized for now at least. | 21:01 |
| TrevorV | Basically since its pretty simple to 'undo' a driver setup, if we find that functionality will be tightly coupled, we'll just remove that driver functionality and tie it directly as he originally suggested | 21:01 |
| openstackgerrit | Trevor Vardeman proposed openstack/octavia: Configuring Housekeeping agent and functions https://review.openstack.org/199313 | 21:03 |
| openstackgerrit | Trevor Vardeman proposed openstack/octavia: Configuring Housekeeping agent and functions https://review.openstack.org/199313 | 21:04 |
| *** TrevorV has quit IRC | 21:06 | |
| *** vivek-ebay has quit IRC | 21:09 | |
| *** vivek-ebay has joined #openstack-lbaas | 21:12 | |
| *** vivek-ebay has quit IRC | 21:12 | |
| *** vivek-ebay has joined #openstack-lbaas | 21:13 | |
| *** mixos is now known as mixos-away | 21:16 | |
| *** apuimedo has quit IRC | 21:18 | |
| harlowja_ | https://review.openstack.org/164922 fyi folks | 21:28 |
| harlowja_ | mergeedd | 21:28 |
| blogan | harlowja_: nice! | 21:28 |
| blogan | harlowja_: i mean noice! | 21:28 |
| harlowja_ | thats hot | 21:28 |
| harlowja_ | lol | 21:28 |
| *** localloop127 has quit IRC | 21:29 | |
| *** mixos-away is now known as mixos | 21:35 | |
| *** mwang2 has quit IRC | 21:37 | |
| dougwig | holy novel. you people are having too much fun. | 21:38 |
| blogan | dougwig: you gonna read that novel? | 21:39 |
| dougwig | blogan: do i need to? | 21:40 |
| blogan | dougwig: well no, it'll be brought up at the midcycle im sure,b ut if you like to have an opinion | 21:41 |
| dougwig | yeah, just buried today. i'm sure you guys sorted it. | 21:41 |
| blogan | dougwig: ill bury you next week | 21:58 |
| *** amotoki has quit IRC | 22:02 | |
| xgerman | guys, when I do devstack I am seeing now for two days: | 22:03 |
| xgerman | https://www.irccloud.com/pastebin/RBySnJSx/ | 22:03 |
| xgerman | anybody has seen that before? | 22:03 |
| madhu_ak | dougwig: https://review.openstack.org/#/c/199754/ | 22:07 |
| madhu_ak | dougwig: addressed your comments and I am following you correctly | 22:07 |
| madhu_ak | if not, would like to have your views ;) | 22:07 |
| *** enikanorov2 has quit IRC | 22:09 | |
| *** mlavalle has quit IRC | 22:11 | |
| *** mixos has quit IRC | 22:15 | |
| *** vivek-ebay has quit IRC | 22:49 | |
| *** vivek-ebay has joined #openstack-lbaas | 22:49 | |
| *** apuimedo has joined #openstack-lbaas | 22:57 | |
| *** amotoki has joined #openstack-lbaas | 23:02 | |
| *** amotoki has quit IRC | 23:07 | |
| *** madhu_ak has quit IRC | 23:31 | |
| *** mgarza_ has quit IRC | 23:37 | |
| *** openstack has joined #openstack-lbaas | 23:39 | |
| *** chlong has quit IRC | 23:49 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!