| *** crc32 has quit IRC | 00:06 | |
| *** markmcclain has quit IRC | 00:06 | |
| dougwig | crying reminded you of something? oh my. | 00:07 |
|---|---|---|
| *** fnaval has quit IRC | 00:08 | |
| *** banix has joined #openstack-lbaas | 00:13 | |
| *** banix has quit IRC | 00:21 | |
| mlavalle | blogan: you around? | 00:24 |
| *** xgerman_ has quit IRC | 00:25 | |
| dougwig | is there something anyone else can help with? | 00:30 |
| *** fnaval has joined #openstack-lbaas | 00:34 | |
| *** banix has joined #openstack-lbaas | 00:44 | |
| mlavalle | dougwig: I am running the tempest api test against LBaaS v2 and I am finding some unexpected behaviour | 00:45 |
| *** banix has quit IRC | 00:46 | |
| blogan | mlavalle: what sup | 00:46 |
| blogan | whats up | 00:46 |
| mlavalle | blogan:^^^^ | 00:46 |
| blogan | mlavalle: what kind of behavior? | 00:46 |
| mlavalle | blogan: so, I attempt and succeed in creating a pool: | 00:47 |
| blogan | dougwig: reminded me that i needed to go home, then write that email | 00:48 |
| mlavalle | blogan: {'status': '201', 'content-length': '307', 'connection': 'close', 'date': 'Wed, 30 Jul 2014 00:29:01 GMT', 'content-type': 'application/json; charset=UTF-8', 'x-openstack-request-id': 'req-f6ad7913-31ce-47af-a8cf-101fef696184'} | 00:48 |
| blogan | okay | 00:48 |
| mlavalle | blogan: {u'pool': {u'lb_algorithm': u'ROUND_ROBIN', u'status': u'DEFERRED', u'protocol': u'HTTP', u'description': u'', u'admin_state_up': True, u'tenant_id': u'6654344b5dfc443f9e5ecb0efff15040', u'healthmonitor_id': u'07b065f6-e85e-4f35-8fca-a16c6257869d', u'id': u'687e48c0-e068-4788-b0c2-d0e30a55d1b4', u'name': u'pool-412969261'}} | 00:48 |
| mlavalle | blogan: so far so good | 00:48 |
| blogan | yep | 00:48 |
| blogan | im assuming that healthmonitor does exist as well | 00:49 |
| mlavalle | blogan: correct | 00:49 |
| blogan | here comes the but.. | 00:50 |
| *** banix has joined #openstack-lbaas | 00:50 | |
| mlavalle | blogan: now I attempt to create a member associated with that pool. requests body is: {"member": {"subnet_id": "dd33f2c2-877f-4991-b4ff-cd408158bf9b", "protocol_port": 8080, "address": "10.100.0.14"}} | 00:50 |
| mlavalle | v2.0/lbaas/pool/687e48c0-e068-4788-b0c2-d0e30a55d1b4/members | 00:50 |
| blogan | okay | 00:50 |
| blogan | that looks like that should work | 00:50 |
| mlavalle | blogan: ^^^ thue uri | 00:50 |
| blogan | well wait | 00:50 |
| blogan | yeah | 00:51 |
| blogan | pools | 00:51 |
| mlavalle | blogan: but I get a 404 | 00:51 |
| blogan | yeah it should be v2.0/lbaas/pools | 00:51 |
| blogan | and then pool_id | 00:51 |
| mlavalle | ok, that's it | 00:51 |
| blogan | yep | 00:51 |
| mlavalle | let me try again | 00:51 |
| blogan | ok let me know ill bbiab | 00:52 |
| mlavalle | blogan: so the document is wrong…. it reads: POST /pool/{pool_id}/members | 00:53 |
| mlavalle | blogan: that is the source of the problem…. after I confirm it works with pools, i'll fix the doc | 00:53 |
| *** sbfox has quit IRC | 00:55 | |
| mlavalle | blogan: yep, it works with 'pools' in the uri. I'll fix the doc and the rest client in tempest | 00:55 |
| mlavalle | blogan: doc fixed | 00:58 |
| mlavalle | blogan: ok, pretty much confirmed that POST works for all the resources: loadbalancer, listeners, healthmonitors, pools and members….. got to go home now, will continue tomorrow | 01:01 |
| *** mlavalle has quit IRC | 01:04 | |
| blogan | ah damn just missed him | 01:27 |
| *** fnaval has quit IRC | 01:42 | |
| *** fnaval has joined #openstack-lbaas | 01:43 | |
| *** fnaval has quit IRC | 01:47 | |
| *** sbfox has joined #openstack-lbaas | 01:51 | |
| *** sbfox1 has joined #openstack-lbaas | 01:54 | |
| *** sbfox has quit IRC | 01:55 | |
| *** sbfox1 has quit IRC | 01:56 | |
| *** sbfox has joined #openstack-lbaas | 02:01 | |
| *** woodster__ has quit IRC | 02:05 | |
| *** fnaval has joined #openstack-lbaas | 02:08 | |
| *** HenryG is now known as HenryG_afk | 02:53 | |
| dougwig | blogan: ping? | 03:02 |
| blogan | dougwig: pong | 03:04 |
| dougwig | do you get tenant delete notifications? | 03:04 |
| blogan | is that a keystone thing? | 03:05 |
| dougwig | sure, but clearly some cleanup has to happen, right? | 03:05 |
| blogan | yeah, but i haven't had to deal with that | 03:05 |
| dougwig | someone here just suggested adding a delete_tenant hook in the drivers, would is actually an excellent idea. i'm just wondering if the plumbing is there. | 03:05 |
| blogan | then again I could see how the neutron API would be the one who deals with that | 03:05 |
| dougwig | /would is/which is/ | 03:06 |
| dougwig | neutron api can't clean up backends. i see some tenant_delete hooks in ml2 drivers. | 03:06 |
| blogan | no but the neutron api could grab all the tenants resources and call the plugin's delete method | 03:07 |
| *** sbfox has quit IRC | 03:07 | |
| blogan | i dont know if that is done or not, i actually doubt it is | 03:07 |
| dougwig | either it does, or backends leak resources. | 03:07 |
| dougwig | seems a slow way to go about it in most cases, too. | 03:07 |
| blogan | yeah, that's something we've had to deal with at rax, and well i don't think our solution is great either | 03:08 |
| blogan | im not sure if only a delete_tenant hook in the driver layer would be best, since all the entries in the database would need to be clenaed up too | 03:10 |
| blogan | and i doubt there's a delete_all_resources_by_tenant type of call in neutron | 03:10 |
| dougwig | presumably the neutron db will get cleaned by the existing tenant delete (just scoop up all the rows with that tenant id) | 03:11 |
| blogan | well i don't know how neutron handles a tenant delete, they may just keep it in the records | 03:12 |
| blogan | i'd just be guessing right now | 03:14 |
| *** banix has quit IRC | 04:20 | |
| rm_work | lol blogan working a 16 hour day again | 04:24 |
| rm_work | blogan: too bad RS gives no overtime T_T | 04:25 |
| blogan | rm_work: they used too back when i was hourly | 04:25 |
| rm_work | heh | 04:25 |
| rm_work | yeah | 04:25 |
| rm_work | salary is a bummer sometimes | 04:25 |
| rm_work | when you're pulling a blogan | 04:25 |
| blogan | it is but at least i dont have to worry about trakcin ghours | 04:26 |
| dougwig | i'm at 13. damn, i'm slacking. | 04:28 |
| blogan | im not really at 16, more like i dont know 10 with breaks calculated in | 04:31 |
| *** fnaval has quit IRC | 04:37 | |
| *** fnaval has joined #openstack-lbaas | 04:37 | |
| *** fnaval has quit IRC | 04:42 | |
| dougwig | i haven't had dinner yet. | 04:50 |
| blogan | you should probably eat | 05:07 |
| blogan | and im going to sleep | 05:07 |
| blogan | goodnight to all | 05:07 |
| *** evgenyf has joined #openstack-lbaas | 06:19 | |
| openstackgerrit | Stephen Balukoff proposed a change to stackforge/octavia: Documenting project direction and design https://review.openstack.org/110563 | 08:01 |
| *** openstackgerrit has quit IRC | 09:16 | |
| *** openstackgerrit has joined #openstack-lbaas | 09:17 | |
| *** evgenyf has quit IRC | 09:23 | |
| *** rohara has quit IRC | 09:44 | |
| *** blogan has quit IRC | 09:44 | |
| *** rohara has joined #openstack-lbaas | 09:44 | |
| *** blogan has joined #openstack-lbaas | 09:45 | |
| *** evgenyf has joined #openstack-lbaas | 09:55 | |
| *** samuelbercovici has joined #openstack-lbaas | 11:32 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 11:45 | |
| *** samuelbercovici has quit IRC | 11:48 | |
| *** samuelbercovici1 is now known as samuelbercovici | 11:48 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 12:01 | |
| *** samuelbercovici has quit IRC | 12:05 | |
| *** samuelbercovici1 is now known as samuelbercovici | 12:05 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 12:10 | |
| *** samuelbercovici has quit IRC | 12:13 | |
| *** samuelbercovici1 is now known as samuelbercovici | 12:13 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 12:22 | |
| *** HenryG_afk is now known as HenryG | 12:23 | |
| *** samuelbercovici has quit IRC | 12:25 | |
| *** samuelbercovici1 is now known as samuelbercovici | 12:25 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 12:27 | |
| *** samuelbercovici has quit IRC | 12:30 | |
| *** samuelbercovici1 is now known as samuelbercovici | 12:30 | |
| *** [1]evgenyf has joined #openstack-lbaas | 12:33 | |
| *** evgenyf has quit IRC | 12:35 | |
| *** [1]evgenyf is now known as evgenyf | 12:35 | |
| *** fnaval has joined #openstack-lbaas | 12:36 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 12:58 | |
| *** samuelbercovici has quit IRC | 13:02 | |
| *** samuelbercovici1 is now known as samuelbercovici | 13:02 | |
| *** fnaval has quit IRC | 13:13 | |
| *** fnaval_ has joined #openstack-lbaas | 13:16 | |
| *** samuelbercovici has quit IRC | 13:26 | |
| *** banix has joined #openstack-lbaas | 13:31 | |
| *** evgenyf has quit IRC | 13:35 | |
| *** fnaval_ has quit IRC | 13:37 | |
| *** fnaval has joined #openstack-lbaas | 13:37 | |
| *** fnaval has quit IRC | 13:42 | |
| *** rolledback has joined #openstack-lbaas | 13:50 | |
| *** rolledback has quit IRC | 13:55 | |
| *** rolledback has joined #openstack-lbaas | 13:56 | |
| *** jorgem has joined #openstack-lbaas | 14:55 | |
| *** xgerman_ has joined #openstack-lbaas | 15:03 | |
| *** jorgem has quit IRC | 15:11 | |
| *** jorgem has joined #openstack-lbaas | 15:13 | |
| *** jorgem has quit IRC | 15:17 | |
| *** jorgem has joined #openstack-lbaas | 15:18 | |
| *** sballe_ has joined #openstack-lbaas | 15:19 | |
| blogan | noooo not another rebase mess up! | 15:27 |
| ptoohill | good morning! | 15:28 |
| *** samuelbercovici has joined #openstack-lbaas | 15:28 | |
| *** samuelbercovici has quit IRC | 15:29 | |
| blogan | mestery ping | 15:30 |
| sballe_ | morning | 15:37 |
| *** trinaths has joined #openstack-lbaas | 15:47 | |
| *** woodster__ has joined #openstack-lbaas | 15:54 | |
| *** trinaths has left #openstack-lbaas | 15:54 | |
| rm_work | guten morgen | 15:54 |
| rm_work | sballe_: we're having issues getting on this virtual rooms thing | 16:03 |
| rm_work | xgerman_: ^^ | 16:03 |
| rm_work | is there another thing we could use? Webex? Google? | 16:03 |
| xgerman_ | just call the number | 16:03 |
| rm_work | hmm k | 16:03 |
| sballe_ | just call the number | 16:03 |
| sballe_ | (toll) 281.964.1607 (toll-free) 877.675.4345 PIN 884 7732 | 16:04 |
| sballe_ | I am not sure we need the virtual room | 16:04 |
| xgerman_ | the virtual room is optional :-) | 16:04 |
| xgerman_ | https://etherpad.openstack.org/p/lbaas_octavia_roadmap | 16:05 |
| *** markmcclain has joined #openstack-lbaas | 16:07 | |
| *** woodster__ is now known as woodster | 16:09 | |
| *** barclaac has joined #openstack-lbaas | 16:11 | |
| *** mlavalle has joined #openstack-lbaas | 16:15 | |
| *** sbfox has joined #openstack-lbaas | 16:28 | |
| *** sbfox has quit IRC | 16:31 | |
| *** sbfox has joined #openstack-lbaas | 16:32 | |
| *** sbalukoff has quit IRC | 16:45 | |
| dougwig | ok, there's my stupid question for the day. | 16:52 |
| *** Youcef has joined #openstack-lbaas | 17:01 | |
| *** rolledback has quit IRC | 17:09 | |
| dougwig | i assume that today's webex is again canceled. someone holler if i'm wrong. | 17:25 |
| dougwig | (i have nothing for the agenda.) | 17:25 |
| blogan | dougwig: i think its getting closer to where it is going to get back on | 17:42 |
| dougwig | if spontaneous design sessions are cropping up, it'd seem like it. | 17:43 |
| *** sbalukoff has joined #openstack-lbaas | 17:44 | |
| *** rohara has quit IRC | 17:44 | |
| *** rolledback has joined #openstack-lbaas | 17:45 | |
| blogan | i think they were just trying to get a gameplan together of where to start and what to thinking about when designing | 17:47 |
| sbalukoff | Hmmm? | 17:47 |
| rm_work | if you guys want to +1 https://review.openstack.org/#/c/107845/ | 17:48 |
| rm_work | that'd be good | 17:48 |
| rm_work | it's on what should be the final patchset, so no more clearing | 17:48 |
| rm_work | :) | 17:48 |
| sbalukoff | Yay! I'll see about reviewing that today. | 17:48 |
| rm_work | sbalukoff / blogan / xgerman_ | 17:48 |
| rm_work | heh | 17:48 |
| rm_work | thanks | 17:48 |
| rm_work | you reviewed it before I think, so it should be cake | 17:48 |
| blogan | time to nit! | 17:48 |
| sbalukoff | Haha! | 17:48 |
| rm_work | sbalukoff: if you nit this i swear to god | 17:49 |
| sbalukoff | blogan: You sound so eager. | 17:49 |
| blogan | rm_work: you would so nit mine, i know you would | 17:49 |
| * sbalukoff cracks his knuckles. | 17:49 | |
| rm_work | sbalukoff: take off your nit hat and leave it at home | 17:49 |
| rm_work | blogan: not at 26 patchsets i wouldn't T_T | 17:49 |
| sbalukoff | But that's how I express love, man. | 17:49 |
| blogan | rm_work: oh you have a pity level | 17:49 |
| rm_work | blogan: yes, you've reached it | 17:49 |
| sbalukoff | Haha | 17:49 |
| rm_work | which is why i'm offering to help manage your change for you :P | 17:49 |
| blogan | if you can manage it in such a way where it doesn't get random patch sets, that'd be great | 17:50 |
| dougwig | no nits from sbalukoff means he doesn't really like you. | 17:53 |
| *** jorgem has quit IRC | 18:01 | |
| *** jorgem has joined #openstack-lbaas | 18:01 | |
| *** jorgem has quit IRC | 18:02 | |
| *** jorgem has joined #openstack-lbaas | 18:02 | |
| *** barclaac|2 has joined #openstack-lbaas | 18:03 | |
| *** barclaac has quit IRC | 18:06 | |
| dougwig | blogan: oh, no worries on meetings organically starting. i'm recognizing that it's a sign of activity picking up, not being bothered by it. it's great, especially if it's not distracting us. | 18:14 |
| blogan | dougwig: not distracting me, i let jorge and adam take care of it from our side, im focused on getting this v2 stuff done | 18:15 |
| dougwig | ditto. | 18:15 |
| *** banix has quit IRC | 18:20 | |
| *** barclaac|2 has quit IRC | 18:26 | |
| *** jorgem has quit IRC | 18:35 | |
| sbalukoff | Sorry, didn't mean to be exclusive or anything. We basically talked about what is in this: https://review.openstack.org/#/c/110563 And came up with a few action items here: https://etherpad.openstack.org/p/lbaas_octavia_roadmap | 18:38 |
| *** jorgem has joined #openstack-lbaas | 18:39 | |
| dougwig | didn't think it was exclusive. it's all goo. | 18:55 |
| dougwig | d. | 18:55 |
| *** rolledback has quit IRC | 19:02 | |
| *** mestery has quit IRC | 19:12 | |
| *** mestery has joined #openstack-lbaas | 19:12 | |
| *** mestery has quit IRC | 19:14 | |
| *** mestery has joined #openstack-lbaas | 19:14 | |
| *** jorgem1 has joined #openstack-lbaas | 19:24 | |
| *** jorgem has quit IRC | 19:26 | |
| *** rolledback has joined #openstack-lbaas | 19:31 | |
| *** fnaval has joined #openstack-lbaas | 19:32 | |
| *** banix has joined #openstack-lbaas | 19:34 | |
| *** sbfox has quit IRC | 19:53 | |
| *** crc32 has joined #openstack-lbaas | 19:54 | |
| *** sbfox has joined #openstack-lbaas | 19:56 | |
| *** rolledback has quit IRC | 20:10 | |
| sballe_ | all, could you please add your talk submission to thei etherpad so we can check them out and vote for them? | 20:33 |
| sballe_ | https://etherpad.openstack.org/p/Kilo_LBaaS_talk_submissions | 20:33 |
| sballe_ | dougwig, blogan, jorgem1 ^^^^ | 20:35 |
| *** Pattabi has joined #openstack-lbaas | 20:48 | |
| Pattabi | anyone assigned to work on the neutron lbaas cli for the v2 datamodel based apis ? | 20:49 |
| *** fnaval has quit IRC | 20:50 | |
| dougwig | yes, ctracey | 20:50 |
| dougwig | did you have a question, or are you looking for something to work on? | 20:50 |
| *** fnaval has joined #openstack-lbaas | 20:50 | |
| Pattabi | thanks. i was asking because, i had updated the neutron cli for the new data model for my end to end testing | 20:51 |
| Pattabi | if no one is tasked to do i was planning to help out on that :-) | 20:51 |
| ctracey | i just got all units passing | 20:51 |
| ctracey | starting to break all the changes into their respective reviews | 20:52 |
| dougwig | ahh, nice, you should definitely talk to ctracey. you can also see his current code here: https://github.com/oslbaas/python-neutronclient/tree/objectmodel | 20:52 |
| ctracey | that will be updated shortly | 20:52 |
| dougwig | ctracey: i'm ready. i've been saving up -1's all week. | 20:52 |
| Pattabi | thanks .. will check it out and review too | 20:52 |
| dougwig | :) | 20:52 |
| ctracey | hah | 20:53 |
| *** fnaval has quit IRC | 20:55 | |
| Pattabi | have another question on the update APIs | 20:56 |
| ctracey | dougwig: so another nice way to get around "import errors"....nose | 20:56 |
| Pattabi | can i unset the default_pool_id for example on the listener object after it is set | 20:57 |
| Pattabi | similarly unset the healthmonitor_id on the pool object after it is set | 20:58 |
| dougwig | you should be able to disassociate, in theory. blogan will have to comment on if the code is stopping it for some reason. | 21:01 |
| dougwig | but if you can't, my first reaction would be that you've found a bug. | 21:01 |
| blogan | Pattabi: on listener's loadbalancer_id and default_pool_id you can set them to null, once they're null you can reassociate them | 21:03 |
| blogan | you just can't go straing from one loadbalancer_id to another | 21:03 |
| blogan | or pool | 21:03 |
| blogan | same with healthmonitor_id on pool | 21:03 |
| ctracey | blogan: not sure there is any way to do that from the CLI | 21:04 |
| ctracey | but that is a generic openstack thing | 21:04 |
| ctracey | not specific to this | 21:04 |
| dougwig | the v1 lb CLI have associate/disassociate commands for certain objects, for that. | 21:05 |
| dougwig | /have/has/ | 21:05 |
| ctracey | those are further API endpoints tho | 21:06 |
| ctracey | iirc | 21:06 |
| ctracey | termed actions i think | 21:06 |
| ctracey | if you *really* wanted it, you should be able to craft your own client routines | 21:07 |
| ctracey | nothing in the calls prevents it, afaik | 21:07 |
| ctracey | just weird from a UI perspective | 21:07 |
| Pattabi | how do i set them to null from the API / CLI ? | 21:11 |
| Pattabi | it is an optional paramater and if specified it has to be be a valid UUID | 21:12 |
| ctracey | that is precisely what I am saying | 21:13 |
| ctracey | there is no good way to do so...but that is no different than anything else openstack | 21:14 |
| dougwig | meow. | 21:15 |
| *** sbfox has quit IRC | 21:15 | |
| ctracey | woof | 21:24 |
| Pattabi | blogan: i will update my client routines/hack to validate this scenario of setting the default_pool_id and health_monitor_id to null | 21:45 |
| *** fnaval has joined #openstack-lbaas | 21:46 | |
| dougwig | i'd love to see an associate/dissasociate, that under the covers just called the update(null). that'd be more intuitive for users. | 21:46 |
| blogan | ctracey: i think its fine if there isn't a way to do it in the CLI. I don't this restriction will stay in, but more thought and time will need to be put in place for it to be removed | 21:47 |
| blogan | Pattabi: the validation is uuid_or_none | 21:48 |
| blogan | so it should allow none | 21:48 |
| Pattabi | i was looking at the code uuid_or_none method only | 21:48 |
| Pattabi | i need to figure out how to pass None as an object instead of string to the back end | 21:49 |
| *** markmcclain has quit IRC | 21:49 | |
| blogan | Pattabi: in the client? | 21:49 |
| Pattabi | using CLI if i set --default-pool-id None, it is passed as None string | 21:49 |
| blogan | Pattabi: ah, yeah I'm not sure how to do that, one thing that can be done is from the CLI allow just switching to another uuid, but do two requests, one is set it to None, then set it to the uuid they wanted | 21:50 |
| blogan | its a hack though | 21:50 |
| blogan | is there anyway to look for the string None and if its None then actually set it to None? | 21:51 |
| blogan | not sure how much access you have to that part that actually sends the request | 21:51 |
| dougwig | those are hacks compared to adding two commands for the link/unlink, which will work for 1:N or M:N. | 21:55 |
| *** sbfox has joined #openstack-lbaas | 21:57 | |
| blogan | dougwig: you're right | 21:57 |
| blogan | it would be better to add those commands | 21:57 |
| Pattabi | from the cli perespective, good to have link/unlink for default_pool_id and also for the health_monitor_id | 22:10 |
| *** Youcef has quit IRC | 22:12 | |
| *** banix has quit IRC | 22:12 | |
| dougwig | reminder: https://etherpad.openstack.org/p/neutron-lbaas-weekly-standup | 22:15 |
| Pattabi | i did modify the client CLI to handle the special case of None for default_pool_id to pass None Object and could see that the DB is updated properly with the None and could set it back again with a valid default_pool_id | 22:19 |
| Pattabi | blogan: sending 2 commands does in deed work | 22:21 |
| dougwig | Pattabi: did you talk to anyone about an exception for your driver? I still have it marked for Kilo here: https://etherpad.openstack.org/p/lbaas_reviews | 22:21 |
| dougwig | i'm wondering if that needs updating. | 22:21 |
| jorgem1 | Any agenda items for tomorrow LBaaS? | 22:28 |
| *** jorgem1 is now known as jorgem | 22:28 | |
| Pattabi | I did reach out to Kyle .. unfortunately he is not approving yet | 22:32 |
| Pattabi | i do have the complete implementation ready <dougwig> for brocade lbaas driver for v2 based data model | 22:33 |
| Pattabi | <dougwig> technically it is only only one implemneting the 4 different managers similar to the a10 driver | 22:34 |
| Pattabi | <jorgem> i would like to discuss if a framework support could be added to handle update failures/limitations on the vendor driver and update DB with the old value ? | 22:36 |
| jorgem | Are you talking about status updates? | 22:37 |
| blogan | Pattabi: you mean the something other than driver handling the status changes? | 22:37 |
| Pattabi | <blogan> and <jorgem> status updates are already available. this is for example, if an update of an property is not supported for a driver/vendor, would like the update to rollback to the old object in the database also | 22:38 |
| blogan | do you have a link to your driver code? | 22:38 |
| blogan | i think you're talking about flavors which are a work in progress for all advaned services in neutron | 22:39 |
| Pattabi | specific example in brocade load balancer case : update of a vip name is not supported. when name is updated via update_loadbalancer, driver can trhow an exception and update DB as FAILED. however, would like to revert the name to old value also | 22:40 |
| Pattabi | <blogan> i can upload the code to my git repository and send you the link for you to look at | 22:42 |
| blogan | Pattabi: really the loadbalancer name should only be updated in the neutron db, the driver doesn't have to actually do anything with that kind of an update | 22:42 |
| Pattabi | <blogan> the name could be set on the actual loadbalancer device also and we use ip address and name combination to locate the object on the device. thats why i want to ensure consistency between db and device | 22:45 |
| blogan | Pattabi: you should use the uuid for the loadbalancer for the name then, since that cannot be updated | 22:45 |
| Pattabi | <blogan> i do use id as name for other entities such as health monitor. in this case, i use name since it was available and it is more user friendly also | 22:47 |
| blogan | Pattabi: agree its more user friendly, but that user friendliness will not be exposed to an actual user, the user won't know what you name the loadbalancer device in the driver | 22:48 |
| Pattabi | <blogan> in either case, this was just an example. was wondering if having such a feature at the framework is helpful to provide an internal method at the plugin level to update the db with the old value | 22:49 |
| dougwig | if i understand you, you're basically wanting the driver code to be inside a database transaction that updates the neutron db, right? | 22:51 |
| blogan | i think he wants that same functionality at least | 22:51 |
| dougwig | right, i'm just trying to boil down. consider it a logical transaction if you will. | 22:52 |
| Pattabi | <dougwig> yes .. similar to _delete_db_loadbalancer method, can we have method _update_db_loadbalancer method | 22:52 |
| dougwig | that would be nicer behavior, but it's also can of worms. consider if the logical (or not) transaction commit then fails after a successful backend change. you're still out of sync, unless you notify the backend, which gives you another shot at being out of sync with the db. repeat. | 22:53 |
| dougwig | and for your example, you should not use name if you backend requires name to be unique, since neutron doesn't impose that restriction. | 22:54 |
| Pattabi | i mean it need not be in the same database transaction | 22:54 |
| dougwig | i'm using transaction in the atomic sense, not the db sense. | 22:54 |
| dougwig | or rather, the "atomic with rollback" sense. | 22:54 |
| blogan | Pattabi: can you give me a use case that cannot be solved by using an attribute that is immutable? | 22:56 |
| blogan | or just a use case that you might need a rollback on | 22:56 |
| Pattabi | driver will call db rollback only if there is a failure at the backend on the device .. otherwise, just the status update as it exists today | 22:57 |
| dougwig | Pattabi: also for your specific use case, i'd recommend that your driver simply update the neutron db, then throw the error. | 22:57 |
| blogan | because i've been leaning in favor of the driver not having to do any kind of status management, or db management at all (save for talking to the core plugin) | 22:57 |
| dougwig | (blogan's head just exploded.) | 22:57 |
| blogan | Pattabi: i think you should throw an exception in your driver and let the plugin handle the rollback | 22:58 |
| Pattabi | as i udnerstand, the plugin does not handle any rollback. is my understanding correct ? | 22:59 |
| dougwig | blogan: the plugin will mark it as ERROR. if you want it to stay ACTIVE, the driver must update the db (and not throw an exception, I guess.) | 22:59 |
| blogan | Pattabi: it'll just mark the entity as ERROR right now, that logic will get more useful | 22:59 |
| dougwig | before your auto-magic change, you could update the db and throw an error, and the CLI and Horizon would display the error but the object would remain happy. after your soon change, you can't throw that exception. | 22:59 |
| blogan | driver's can still throw an exception | 23:00 |
| dougwig | not if they want their objects to not be marked ERROR. | 23:00 |
| Pattabi | so in the update name example, if driver does not support update of the name, from driver I could update the name back to the old name and throw an error back to the plugin ? | 23:02 |
| dougwig | today, yes. but in the change blogan is making right now, you'd have to update the db, and not throw an exception, because soon, any exception from a driver will result in automatic ERROR for objects. | 23:03 |
| Pattabi | understood. but then how will the end user should know that the name was not updated. | 23:04 |
| Pattabi | any exception from a driver will result in automatic ERROR for objects --> i see this logic/code is already there in the plugin code | 23:06 |
| blogan | Pattabi: thats why I think if there is something that your driver does not support, you shouldn't do any kind of rollback | 23:08 |
| blogan | this is very similar to the flavor framework but not exactly because we're not talking about unsupported features | 23:09 |
| blogan | though in a sense we kind of are | 23:09 |
| blogan | this is definitely a gray area | 23:09 |
| blogan | So I think if your driver raises an exception, with a user friendly message, we can pass that on to the response in the API | 23:10 |
| dougwig | right, but how to stay ACTIVE? | 23:10 |
| blogan | and if we ever do support rollbacks then we can have a RollBackException type or something | 23:11 |
| blogan | so that the plugin can determine to keep in ACTIVE | 23:11 |
| Pattabi | any reason why status_descrption field is not supported for v2 ? | 23:11 |
| blogan | no one really wanted it | 23:12 |
| Pattabi | was thinking, having the user friendly message from driver int hat field and setting the status to FAILED will still be okay | 23:12 |
| blogan | it wasn't being used, though i could see the use case here | 23:12 |
| Pattabi | i actually used that field for v1 to reflect the driver exceptions / messages to the end user | 23:13 |
| blogan | well since this will be a synchronous call right now, returning it in the response body will give a message at least, it wont persist though | 23:13 |
| blogan | we can put it back in for sure, we probably should have just kept it | 23:13 |
| blogan | however, I think it'd still be good if the driver didn't need to touch the database at all and just communicated to the plugin with exceptions | 23:14 |
| blogan | and the plugin would then set the status description based on the exception | 23:14 |
| dougwig | blogan: yes, but we're not there yet, and no way can we bailing wire our way to that by juno. | 23:14 |
| blogan | dougwig: oh i know just thinking ahead | 23:14 |
| blogan | doesn't mean Pattabi can't start throwing those exceptions in his driver now | 23:15 |
| blogan | though they will need to be standardized for all drivers | 23:15 |
| Pattabi | right now my driver does not throw any exception back to plugin .. instead i catch all exceptions and update the db status to ERROR .. i guess it is not needed | 23:15 |
| blogan | Pattabi: with the update I'm about to push, yeah it won't be needed, and exception just being raised will be good | 23:16 |
| blogan | sorry to change the requirements/interface in midstream here | 23:16 |
| Pattabi | driver code any way needs to set the status to ACTIVE if successful is nt it ? | 23:17 |
| blogan | i think this is just much cleaner and keeps the drivers to only having to worry about what the drivers know best | 23:17 |
| blogan | nope, the plugin will take care of that | 23:17 |
| Pattabi | will this also be taken care at the plugin layer as part of _call_driver_operation method ? | 23:17 |
| dougwig | the change he's making now is because the addition of a DEFERRED state made driver logic overly complicated. which was in turn added because we're allow non-root objects to pretend to be root objects. | 23:17 |
| blogan | Pattai: correct | 23:17 |
| blogan | Pattabi: | 23:17 |
| Pattabi | awesome | 23:17 |
| blogan | and really i think its the right way to go | 23:18 |
| blogan | that way status management does not change based on what driver is being used | 23:18 |
| Pattabi | would wait for your change blogan and understand better | 23:18 |
| dougwig | (which i said to blogan on day 1 of our meetup, and was shot down. for the record.) :) | 23:18 |
| blogan | dougwig: you were shot down because of the agent case | 23:18 |
| blogan | but yes in the end you are right because that agent case can be handled differently but almost in the same way | 23:19 |
| dougwig | doesn't mean i wasn't right. just temporarily wrong. | 23:19 |
| * blogan bows down to dougwig, the omniscient | 23:19 | |
| *** banix has joined #openstack-lbaas | 23:19 | |
| dougwig | don't rain on my parade with sarcasm. | 23:19 |
| blogan | wasn't really sarcastic, you are right | 23:20 |
| dougwig | and omniscient? | 23:20 |
| blogan | what? | 23:20 |
| blogan | tahts a compliment | 23:21 |
| dougwig | your emote. | 23:21 |
| * dougwig case of text based disconnect detected. | 23:21 | |
| dougwig | that didn't flow at all nicely. | 23:21 |
| blogan | now my brain has exploded | 23:22 |
| * dougwig reboots. | 23:22 | |
| blogan | Pattabi: btw thank you for takign the time to look at this closely and asking good questions | 23:22 |
| *** mlavalle has quit IRC | 23:22 | |
| Pattabi | blogan: i reviewed and asking queations because i needed answers :-) | 23:24 |
| Pattabi | thanks for your patience blogan .. i really want to have my code upstream in juno ... unfortunately i have to deal with other logistics | 23:24 |
| blogan | Pattabi: well whatever lead you to these paths, you've definitely helped me find some good erros and some dumb errors, dumb on my part | 23:25 |
| *** woodster has quit IRC | 23:25 | |
| blogan | Pattabi: yeah getting thigns into Juno is going to be very tough | 23:25 |
| blogan | a lot of the things we want to get in are not going to make it in | 23:25 |
| blogan | woudl be nice ot have another driver that supports v2 though | 23:26 |
| Pattabi | agreed. if the concern not making in juno is because of code reviews and availability of the resources, could one of you provide a helping hand | 23:28 |
| blogan | Pattabi: i can definitely look at it, but the main concern is that there is just so much code reviews and only so much time for the core reviewers | 23:29 |
| dougwig | none of us are cores, and it's core availability that's the bottleneck for juno. otherwise, of course we would. | 23:29 |
| blogan | and I can only give you a +1 | 23:29 |
| blogan | dougwig: I'm going to leave the status mixin's in the base driver for now, but think I should remove the delete mixin | 23:31 |
| blogan | or just leave it for now | 23:31 |
| Pattabi | thanks <blogan> and <dougwig> .. will continue my integration and code reviews ...if it does not happen in juno at least i will try for kilo | 23:31 |
| blogan | Pattabi: i bet you'll get it in Kilo | 23:31 |
| Pattabi | if i need to upload my code for review how do i specify the dependencies in gerrit ? | 23:32 |
| blogan | git review -d {gerrit change #} | 23:32 |
| blogan | that'll essentially pull down the dependent gerrit code, and then you make your changes in a commit on top of that | 23:33 |
| blogan | but please be careful when you do a git review | 23:33 |
| dougwig | git review -d 105610 | 23:34 |
| Pattabi | thanks | 23:35 |
| blogan | Pattabi: read this thread on the ML | 23:35 |
| blogan | http://lists.openstack.org/pipermail/openstack-dev/2014-July/041470.html | 23:35 |
| blogan | thats why I ask to be careful on the git review part | 23:36 |
| Pattabi | blogan: tomorrow, i will sned you the link for the brocade driver code | 23:36 |
| blogan | Pattabi: ok that'll be good | 23:36 |
| Pattabi | in the mean time, i will prepare for the git review also for everyone to look at my code | 23:36 |
| blogan | by git review i mean the actual "git review" command, as it will push yoru code up into gerrit, and if done incorrectly will cascade into change all the dependencies' code as well | 23:37 |
| Pattabi | will see you tomorrow in the meeting .. got to go | 23:38 |
| blogan | see ya | 23:38 |
| blogan | dougwig: btw i have to make a new PS to the extension review anyway, I need to get changes from master in all the reviews | 23:39 |
| *** Pattabi has quit IRC | 23:42 | |
| *** sbfox has quit IRC | 23:48 | |
| xgerman_ | sbalukoff I am wondering if there is a flavor framework talk and/or if we need to propose one | 23:56 |
| *** banix has quit IRC | 23:57 | |
| *** jorgem has quit IRC | 23:57 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!