Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-16
15:55:21 dansmith which makes it expensive
15:55:26 dansmith and after you archive, it's too late
15:55:37 bauzas dansmith: correct me if I'm wrong, but archive_deleted_rows isn't yet cells-aware ?
15:55:40 dansmith but if you do it when you archive, then you can do it in O(n) just like archive is now
15:56:03 mdbooth lyarwood: On locking, I think that everything in api which checks instance/task state should be required to immediately and atomically modify task state. That's probably the level of locking required for rebuild.
15:56:07 dansmith bauzas: what does it matter if it is? whether you're doing one cell db or all of them, it's the same amount of work
15:56:07 mriedem bauzas: the delete_type arg is what tells you the type,
15:56:15 mriedem "soft_delete" or just "delete"
15:56:22 mdbooth I think we do that in many places, btw.
15:56:41 bauzas dansmith: sorry if I'm unclear, but that archive command would have to be run close to a child cell DB, right?
15:56:54 bauzas dansmith: if so, that would be an upcall, right?
15:56:54 sean-k-mooney jaypipes: looking at https://review.openstack.org/#/c/441183 im not sure that any os-vif change is required
15:57:03 dansmith bauzas: it's nova-manage, upcalls are fine
15:57:29 sean-k-mooney jaypipes: the contrial pluging for os-vif would live in the networking-contrail repo not os-vif normally
15:57:37 bauzas dansmith: mmm, okay, I need to consider that
15:57:42 mriedem bauzas: can we just focus on the hard delete case in the api as i pointed out in the review yesterday? and worry about how to best cleanup the soft delete orphans in a separate change?
15:57:53 dansmith yes, please
15:57:55 dansmith not deleting when we know we can is crazypants
15:57:55 mriedem they should be separate changes anyway
15:57:56 lyarwood mdbooth: would that not still allow something like volume-attach to get through?
15:58:10 lyarwood ah, not just me then
15:58:18 mdbooth lyarwood: Not if everything does it, no.
15:58:23 bauzas mriedem: dansmith: yeah, tbc, based on dan's good point, I'm just modifying https://review.openstack.org/#/c/391060/2/nova/compute/api.py to just verify delete_type
15:58:27 mdbooth It's not consistent, though.
15:58:38 bauzas and leave the soft-delete deletions be done differently
15:58:49 bauzas I need to go, ttyl
15:59:15 mriedem bauzas: i said that yesterday in the review :)
15:59:30 mriedem "So we can hard delete the request spec in the API when we hard delete an instance (the delete_type would tell you which it is)."
15:59:40 mriedem "If we care about adding a way to purge leaked request specs (request specs that are related to instances which are deleted), then we could provide a nova-manage command for that, e.g. nova-manage api_db purge_zombies, or something similar. I'd do the purge CLI in a separate patch btw."
15:59:44 mdbooth lyarwood: Anyway, as you say that's not really in scope.
16:01:56 mhenkel sean-k-mooney, Hello
16:02:05 sean-k-mooney jaypipes: that said if the plugin was ovs then yes i would have expected a patch to os-vif
16:02:07 sean-k-mooney mhenkel: hieulq
16:02:12 sean-k-mooney mhenkel: *hi
16:02:32 sean-k-mooney mhenkel: just dissusing your change
16:02:59 sean-k-mooney mhenkel: do im not sure jay is about currently
16:03:05 mhenkel I was just debating internally if we should upstream https://github.com/Juniper/contrail-nova-vif-driver/tree/master/vif_plug_vrouter to os-vif
16:03:35 mhenkel or keep it as a separate plugin delivered by contrail packages
16:04:33 sean-k-mooney mhenkel: currently the policy for plugins in os-vif is that they can only be fro the reference backends
16:04:37 mhenkel my personal preference would be to upstream
16:04:45 sean-k-mooney so ovs,linux bridge and sriov
16:04:49 mhenkel ah ok
16:05:23 sean-k-mooney that is something we could change but the resoning is that it allows you to maintain and update them faster yourself
16:05:42 mhenkel sean-k-mooney: yes, that I agree with
16:06:29 sean-k-mooney mhenkel: one thing that will be changing this cycle hopefully is that neutron will start passing os-vif vif object to nova
16:07:19 mhenkel sean-k-mooney: so we should be good with what I upstreamed so far?
16:07:23 sean-k-mooney mhenkel: when that happens the change you are proposing will nolonger be required as you will be able to spcify the plug to use for the ml2 mech dirver
16:07:31 sean-k-mooney mhenkel: yes
16:07:46 sean-k-mooney mhenkel: though one question
16:08:00 sean-k-mooney for contrial are you managin ovs or do you support other backends
16:08:35 mhenkel no ovs, we provide our own virtual router
16:08:39 openstackgerrit Dan Smith proposed openstack/nova master: Get instance availability_zone without hitting the api db https://review.openstack.org/439754
16:08:40 openstackgerrit Dan Smith proposed openstack/nova master: Avoid lazy-loading projects during flavor notification https://review.openstack.org/445697
16:08:43 openstackgerrit Dan Smith proposed openstack/nova master: Set instance.availability_zone whenever we schedule https://review.openstack.org/446053
16:08:45 openstackgerrit Dan Smith proposed openstack/nova master: Make conductor ask scheduler to limit migrates to same cell https://review.openstack.org/438025
16:08:51 mhenkel either as a kmod or in userspace using dpdk
16:09:03 sean-k-mooney mhenkel: ah ok. in that case what you have is perfect
16:09:34 mhenkel sean-k-mooney: so we just need to convince jaypipes to take back his -1 ;)
16:09:37 sean-k-mooney mhenkel: if you were managing ovs(with or without dpdk) you could upstream the changes that are required to the ovs plugin
16:09:45 mhenkel I see
16:10:26 sean-k-mooney mhenkel: yes but jaypipes will likely agree when he reads my comment
16:11:15 openstackgerrit Sujitha proposed openstack/nova master: Add helper method to add additional data about policy rule. https://review.openstack.org/434842
16:12:39 melwitt mriedem: on the regression test, do you know why you didn't need RetryFilter?
16:13:40 openstackgerrit Sujitha proposed openstack/nova master: Add helper method to add additional data about policy rule. https://review.openstack.org/434842
16:15:45 openstackgerrit Stephen Finucane proposed openstack/os-vif master: Use Sphinx 1.5 warning-is-error https://review.openstack.org/446616
16:16:35 bauzas mriedem: sorry if I misunderstood you
16:16:54 bauzas I don't want to play the French card, but...
16:17:18 bauzas I thought both of you were asking me to abandon that change and just use the manage command for purging
16:18:29 jroll dansmith: got a pointer to the work to expose custom classes in allocations? (is that happening yet?)
16:18:46 dansmith jroll: I think it is .. in jay's head at least
16:19:06 jroll dansmith: keep in mind I mostly have no idea how allocations work, so I'm not sure what's missing here. I guess it's that we can't yet create an allocation for CUSTOM_FOO?
16:19:18 dansmith jroll: we can we just don't
16:20:06 jroll dansmith: right, so one of the work items is to create those allocations, unless I'm missing something I don't see the dep
16:21:11 dansmith jroll: ah, okay I didn't interpret that work item as this thing, probably because the spec seems focused on just the flavor override and scheduling part
16:21:43 dansmith jroll: in that case, it should probably be "RT changes to allow drivers to expose allocations of custom things" and "make ironic driver do that thing"
16:21:44 jroll dansmith: feels like we need to handle it at the same time, else the node remains free to be scheduled to :)
16:22:01 dansmith jroll: I don't think so, we can do the allocation thing first
16:22:12 jroll ah, true
16:22:14 dansmith if jay is doing that he should probably be on the contributors too
16:22:58 jroll dansmith: okay, so I guess I'll rearrange the work items, split it into RT/ironic items, and add jaypipes. cool?
16:23:54 dansmith jroll: sure, but if you're going to include all that work in here, you probably need to add some wordy description of the allocation bits into the proposed change as well, because that's probably why I assumed this was only the flavor/scheduling work
16:24:21 jroll gotcha
16:24:53 jroll dansmith: I have no clue how that thing works, I'll add as a dep for now until I chat with jay
16:26:09 dansmith okay if he wants it all in this spec I'm sure he can just add it himself
16:27:39 jroll ya
16:28:34 mriedem lyarwood: so i was thinking, we should probably decouple the attachment_id and the rest of that series from the bdm.uuid patch, since that's getting overly complicated at this point
16:28:55 mriedem lyarwood: and it's been about 2 weeks, can we just decouple that from the series?
16:29:26 mriedem melwitt: adding the RetryFilter in makes it blow up for some reason
16:29:47 mriedem melwitt: you could pull it down and add that to see what i mean, but it seems to think that there is only one host,
16:30:00 mriedem i'm not sure if that's because both compute services have the same fake-mini node?
16:30:46 melwitt mriedem: yeah, I suspect it's trying to same host again. it still tests the bug since it is retrying, it's just probably not landing on the second host
16:31:08 lyarwood mriedem: yup happy to, I'll do that now before the call
16:31:10 mriedem melwitt: well, it dumps a message like "host1 in list, hosts already tried: host1"
16:31:19 lyarwood s/call/meeting/g
16:31:20 mriedem and then kicks it out,
16:31:30 melwitt mriedem: oh? I pulled it down a few minutes ago and am playing with it, just out of curiosity
16:31:30 mriedem i'm not sure why it doesn't see host2
16:31:47 mriedem my guess is the node values are the same, but i don't see why that should matter
16:31:59 openstackgerrit Jim Rollenhagen proposed openstack/nova-specs master: Add spec for custom resource classes in flavors https://review.openstack.org/446570
16:32:00 mriedem lyarwood: thanks

Earlier   Later