Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-24
15:08:41 sfinucan I didn't grasp that nuance until this morning
15:09:30 bauzas jaypipes: mmm, can't find where we call DELETE /allocations in the compute manager, but only in the RT
15:09:42 sean-k-mooney sfinucan: no i havent atleast not lately. correct that is why im working on https://review.openstack.org/#/c/441590/
15:10:09 sean-k-mooney i am hoping to implement the nova neutron negociation this cycle if i can ever finish the supprot for ovs-dpdk in kolla
15:10:15 jaypipes bauzas: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L716-L731
15:10:38 jaypipes bauzas: that's called at the end of the manager's _delete_instance() method.
15:10:49 bauzas ok, seeing it noxw
15:10:54 bauzas we force a RT update
15:11:00 bauzas which will delete the allocation, gotcha
15:11:02 jaypipes bauzas: the _update_resource_tracker() call eventually calls the scheduler client.
15:11:06 jaypipes right.
15:11:14 sean-k-mooney sfinucan: the host_info object discribes what vif types are supported by each plugin and it will with that patch allso describe what port profiles are supporte db each vif_type per plugin
15:11:27 bauzas jaypipes: okay, no explicit allocation delete, RT handles that
15:11:45 bauzas jaypipes: thanks, so nothing needed from a scheduler claims spec perspective
15:11:51 bauzas jaypipes: except the local delete problem
15:12:01 sean-k-mooney sfinucan: this object will be serialsed into the neutron binding profile and read by the mechanisum drivers as part of the port binding call.
15:12:11 jaypipes bauzas: no, that's still called for soft deletes.
15:12:20 sfinucan sean-k-mooney: Nice. I wasn't aware of host_info either
15:12:23 bauzas jaypipes: local delete != soft delete
15:12:37 jaypipes bauzas: no?
15:12:38 bauzas jaypipes: if the RPC compute service is down, we local delete in the api worker
15:12:57 bauzas totally unrelated to soft deletes, which are just a specific VM state
15:12:59 jaypipes bauzas: right. the api worker sets instance to SOFT_DELETED
15:13:04 bauzas no no
15:13:07 bauzas sec
15:13:07 jaypipes no?
15:13:14 bauzas yet another fun
15:13:22 sfinucan sean-k-mooney: Do you think there's value in documenting the built-in plugins, in that case, as done here https://review.openstack.org/#/c/459258/2
15:14:01 bauzas jaypipes: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L2001 and https://github.com/openstack/nova/blob/master/nova/compute/api.py#L2027-L2032
15:14:05 sfinucan i.e. the plugins themselves along with a little summary of how a given VIF type works in the given plugin/networking backend
15:14:08 sean-k-mooney sfinucan: so the other part of this is that in the future the mapping we currently do between teh existing vif types and the os-vif ones will go away with neutron specifying plugin,vif_type and port prifile in a single os-vif object as a responce to nova in the port binding call
15:14:15 sean-k-mooney sfinucan: ill take a look at it now
15:14:33 mriedem melwitt: dansmith: some easy dead code cleanup in conductor https://review.openstack.org/#/c/434615/
15:14:35 bauzas jaypipes: mriedem mentioned a bug report because we do delete the instance but we don't delete the allocation
15:14:51 bauzas jaypipes: https://bugs.launchpad.net/nova/+bug/1679750
15:14:52 openstack Launchpad bug 1679750 in OpenStack Compute (nova) "Allocations are not cleaned up in placement for instance 'local delete' case" [Medium,Confirmed]
15:15:04 bauzas FWIW, I'll assign myself to the bug since it's related to the claims spec
15:15:09 mriedem jaypipes: we don't soft delete in the api if the compute host is down
15:15:28 mriedem jaypipes: we send out notifications saying we're soft deleting, but really we don't
15:15:30 mriedem we hard delete that mofo
15:15:41 sean-k-mooney sfinucan: so i dont think we should have redefinition of the vif types per plugin but i would be ok with referencing the vif types that are definded globally
15:15:41 mriedem this has been keeping gibi awake at night
15:16:06 sean-k-mooney sfinucan: essentailly like you have done with the glossary
15:16:26 sean-k-mooney define each fo them as a term or link back to the singel definition.
15:16:28 dansmith mriedem: I don't think that's dead code
15:16:31 mriedem jaypipes: https://review.openstack.org/#/c/443764/1/nova/compute/api.py@2066
15:16:32 bauzas oh man, just got an email asking me to take all my holidays before end of May
15:16:40 bauzas that's going to be legendary
15:16:53 sfinucan sean-k-mooney: Basic VIF definitions do exist - see 'doc/source/vif_types'
15:16:59 sfinucan bauzas: dibs!
15:17:43 mriedem dansmith: you can't upgrade the schema if you don't have cell0 in ocata
15:17:46 sean-k-mooney each plugin could discibe the the vif types it support but i would prefer to auto generate that documention form https://github.com/openstack/os-vif/blob/e133b8a3771ce6a49594af83b90586bdd88630ae/vif_plug_ovs/ovs.py#L67-L83 if we could
15:17:53 bauzas I'm always ashamed to speak about that here, but if I would take all my holidays, it could probably require me to stop working right after I come back from BOS :/
15:18:02 dansmith mriedem: unless you have an empty database because you're installing ocata for the first time
15:18:03 bauzas like not working for May
15:18:16 dansmith mriedem: and if you miss putting that record in, you get a unhelpful error condition
15:18:21 mriedem dansmith: if you have any empty db, how are you creating instances?
15:18:23 jaypipes mriedem: lovely..
15:18:25 sean-k-mooney sfinucan: any chance we could use something like your sphix click intergration to do taht
15:18:40 sean-k-mooney if not im sure i coudl script something up
15:18:57 dansmith mriedem: you had an empty database when applying the schema migrations, which made it past the cell0 check, then you start creating instances without doing your cell record setup
15:19:02 mriedem dansmith: this https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api_migrations/migrate_repo/versions/030_require_cell_setup.py
15:19:13 dansmith mriedem: right but that doesn't do anything for a fresh install
15:19:15 mriedem oh the gd flavor thing
15:19:21 mriedem ffs
15:19:52 mriedem jaypipes: yes soft delete is a turd
15:19:55 mriedem which should be flushed
15:21:21 mdbooth +1
15:21:38 sean-k-mooney sfinucan: basically in the docs job all we would need to do is load os-vif. loop over all the in tree plugins, call discribe and template our a descripts into a folder and then have sphinx auto include it in the docs that way its automatic and always up to date
15:22:37 sfinucan sean-k-mooney: I could but it might be overkill
15:22:50 sfinucan Realistically, how often are those lines going to change
15:23:25 sfinucan and, iirc, the plan is not to add any more plugins in os-vif (they should live in separate repos)
15:23:38 sean-k-mooney not that often we could just make it a requirement for adding more vif_types or port profiles to existing plugins as part of ongoing reviews
15:23:50 sean-k-mooney yep
15:24:31 mriedem dansmith: ok left a reply - but if we don't have cell0 to bury, we still have the build requests to list 'instances' and delete that 'instance', but we don't update the vm_state on the build request to ERROR
15:24:43 mriedem so those 'instances' just get stuck in scheduling state until you delete them (i think)
15:24:50 sean-k-mooney more vif types will be added to both plugins though and more port poriles but it wont be a large overhead to manually update the docs.
15:25:19 sfinucan sean-k-mooney: Yeah, I don't think it would be too much of a requirement
15:25:36 sfinucan docs usually help reviews anyway because they give way more context
15:26:33 sean-k-mooney sfinucan: one of the requests i got from the neutron folks was to allow os-vif to plug non vm interfaces so they could use it to plug the dhcp,l3 and tunnel ports when its intergrated into neutron
15:26:52 sean-k-mooney i opened some bugs for those with too do to fill them out later
15:27:47 dansmith mriedem: yep, but we have to have the big red warning I think
15:28:31 mriedem yeah i suppose.
15:28:45 sean-k-mooney we will need about 5 or 6 new vif_types to cover that (patch,vif_pair,vxlan,gre,geneve) i think im missing one but basically same pattern as vms and form and os vif point of view we dont really care what uses the port anyway.
15:29:00 mriedem dansmith: if we wanted to get the instance into ERROR state, we'd have to deserialize the build_request.instance, set it's vm/task state and then update the build_request right?
15:29:07 sfinucan sean-k-mooney: nova wouldn't care about those new ones, right?
15:29:41 dansmith mriedem: I dunno if that would do it, but perhaps.. I'm not too concerned about that I guess, since this is early setup you failed to do, so API semantics aren't that big of a deal, but..
15:30:16 sean-k-mooney on the one i was missing was tap. correct nova should not care though the tap vif type which is basically the existing generic vif type(i would proably just use that) could be used with calico
15:31:59 sfinucan sean-k-mooney: Yup, sounds good to me so
15:32:14 sfinucan sean-k-mooney: Going back to those docs then, I could probably put a note in saying that those supported vif_types are exposed using that host_info object, right?
15:33:11 sean-k-mooney sfinucan: yes if you could make them a link or somehow include the previous defintions of the docs from the global definiton that would also be good
15:33:43 sean-k-mooney i would prefer not to have multiple definitions of the same vif_type that could get out of sync if sphix supports that
15:33:57 sean-k-mooney if not its fine we can just keep them in sync with reviews
15:34:50 mriedem dansmith: fair enough
15:35:08 mriedem at some point if i care i might see how hard it is to reproduce and change the build request to error, but i might not care later either
15:36:04 dansmith heh
15:37:57 sfinucan sean-k-mooney: Ah, there is a difference. The general vif_type overview is provided in doc/source/vif_types
15:38:21 sfinucan The ones that we've added refer to how a given VIF is implemented for a given backend
15:38:53 mriedem lyarwood: huzzah! https://review.openstack.org/#/c/459316/
15:38:53 sean-k-mooney sfinucan: thats the thing the vif_type is ment to be completly independent form that backend impelmtation

Earlier   Later