Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-19
22:04:24 dansmith melwitt: what we need to avoid is returning unversioned data to the compute, which I don't think is solved purely by putting the straddle in quotas.py
22:04:37 melwitt dansmith: I was thinking of the Quotas object as an abstraction but wasn't think of the remotable methods part
22:04:45 dansmith melwitt: what we really need is a composite operation that just says "yo dawg, check this quota limit for me and raise if there's a problem" right?
22:05:00 dansmith melwitt: then all the data is on the conductor side and compute is just asking for a check instead of getting the data itself
22:05:03 melwitt dansmith: it's not but it would be doing the same thing it is now (without having a Quotas object version attached to it)
22:05:17 melwitt dansmith: yeah, that makes sense
22:05:39 dansmith melwitt: right now we remote the call to the quotas db code through the object action without returning data, right?
22:05:47 dansmith and your patch ends up with us returning that data to compute I think
22:05:54 melwitt dansmith: check_deltas is supposed to do that, but atm I'm confused as to where that occurs or if it solves the problem
22:06:29 melwitt check_deltas is the composite operation that calls count followed by limit_check
22:08:08 dansmith melwitt: where is check_deltas?
22:08:58 dansmith that must be something later in your patch series?
22:09:49 melwitt dansmith: third patch I think
22:10:29 melwitt dansmith: https://review.openstack.org/#/c/446239
22:11:10 cfriesen config option question: when specifying the "live_migration_inbound_addr" config option, is it expected that an ipv6 address will be enclosed in square brackets? Or should nova handle that when parsing the config option?
22:11:39 dansmith melwitt: ah yep.. that just takes resources and counts (from compute in this case), remotes to conductor where it looks at all the stuff and either explodes or doesn't, right?
22:13:17 openstackgerrit Eric Fried proposed openstack/nova master: WIP/PoC: nova.utils.get_service_url(group) https://review.openstack.org/458257
22:13:23 melwitt dansmith: it takes the deltas but it does the count and pulls the limits itself
22:13:54 dansmith melwitt: right, it just takes a resource and count, and explodes if the quota would be violated
22:14:09 dansmith melwitt: that's what we need yeah
22:14:34 clarkb cfriesen: I thought I could answer based on how we configure things in multinode testing but that appears to be an entirely ipv4 control plane :/
22:14:48 melwitt dansmith: if by count you mean delta, then yes. if you want to check if you have room for 5 more instances, you pass it 5 and then it will count how many instances your project and user have allocated, then it pulls the limits and compares
22:15:07 cfriesen clarkb: I'm wondering if maybe nova should do:
22:15:35 cfriesen migrate_data.target_connect_addr = utils.safe_ip_format(CONF.libvirt.live_migration_inbound_addr)
22:15:53 dansmith melwitt: yeah
22:17:21 melwitt dansmith: okay, so that solves that problem. so I need to figure out what to do about the db access methods I have in the Quotas object
22:18:11 melwitt I put them there as a universal place to call api/main db to do the right thing, and the caller should only be the quota driver in nova/quota.py
22:18:29 melwitt I think ...
22:18:56 dansmith melwitt: right but does compute call into nova.quota for anythign? I thought it did
22:19:09 dansmith if so, then your check_deltas conversion needs to come first
22:19:19 melwitt dansmith: it does, for the reserve/commit/rollback
22:19:24 openstackgerrit Peter Hamilton proposed openstack/nova master: Add configuration options for certificate validation https://review.openstack.org/457678
22:19:48 dansmith melwitt: yeah, then you need to do something in a different order I guess
22:19:50 melwitt dansmith: check_deltas only works if the quota has been converted to Countable
22:19:56 dansmith yeah
22:24:34 melwitt I shall think on it
22:25:03 melwitt my brain's too fried at the moment
22:28:23 eandersson Is there a way to extend the data in metadata? (e.g. adding tenant name)
22:53:45 mriedem eandersson: you can update the metadata associated with a server yes
22:54:09 mriedem eandersson: https://developer.openstack.org/api-ref/compute/#server-metadata-servers-metadata
22:54:42 mriedem https://docs.openstack.org/cli-reference/nova.html#nova-meta
23:04:53 mriedem melwitt: did you get a patch up for that ironic unit test failure?
23:05:20 melwitt mriedem: yes, https://review.openstack.org/458161
23:05:28 mriedem sweet
23:06:00 melwitt I think the only thing it misses out on is running the _wait_state function but I think one of the other unit tests runs it
23:06:10 melwitt double check it though
23:06:39 mriedem the commit message says it's covered in other tests
23:06:43 mriedem i guess you're lying
23:06:45 mriedem potentially
23:07:42 mriedem but yeah there are
23:07:45 mriedem off the hook this time witt
23:10:48 openstackgerrit Mathieu Gagné proposed openstack/nova master: Add ability to signal and perform online volume size change https://review.openstack.org/454322
23:10:56 melwitt haha
23:11:57 melwitt I thought I saw it covered in other tests but maybe I misunderstood something
23:12:38 mriedem +2
23:14:07 melwitt mriedem: thanks. at first I removed those overrides but then kept them to use in the assert_called_with to verify they're being passed along to the timer as expected
23:14:36 mriedem alright - that's fine for the configurable one, the module scope variable was just there for tricking the timer
23:14:46 melwitt oh
23:22:27 mriedem mdbooth: do you plan on rebasing this https://review.openstack.org/#/c/430213/ ? - something came into triage today that was a duplicate
23:23:18 mriedem sean-k-mooney: who is running the intel 3rd party ci now that wznoinsk is gone?
23:39:25 imacdonn mriedem, still around ?
23:41:29 mriedem imacdonn: yeah
23:42:11 openstack Launchpad bug 1662483 in OpenStack Compute (nova) "duplicate for #1683972 detach_volume races with delete" [Undecided,In progress] - Assigned to Matthew Booth (mbooth-9)
23:42:11 imacdonn hey .. re. https://bugs.launchpad.net/nova/+bug/1683972
23:42:20 imacdonn thanks, openstack
23:42:57 imacdonn I'm not sure it's really the same problem as the one you marked it a dup of .. it's slightly related, I guess
23:43:30 mriedem feel free to unduplicate it if you want, but i thought the solution was the same
23:43:36 mriedem lock on detach_volume in the compute manager
23:44:01 imacdonn my locking was way more extensive (and possibly way more wrong, but it works for me)
23:44:12 mriedem care to post your change?
23:44:18 mriedem i'm sure mdbooth would like to look at it
23:44:24 imacdonn but my case was overlap between attach and detach .. not two detach's
23:44:39 imacdonn if mdbooth is the right guy, I can get with him ... what TZ is he in ?
23:45:08 mriedem UK
23:45:27 mriedem so he'd be around in the morning
23:46:05 imacdonn OK, I'll look for him them ... I can post what I did somewhere, but I'm fairly sure it's not "right"
23:46:27 mriedem hard to know if you don't post it
23:46:40 mriedem posting to gerrit would be preferrable, else you could attach a patch file in the bug report
23:47:44 imacdonn I think it's too much of a hack to put in a review .. should I attach to my bug (the one marked as a dup) ?
23:49:41 mriedem nothing is too much of a hack to put it in a review - just put WIP in the prefix of the commit title
23:49:47 mriedem or -Workflow it in gerrit
23:49:53 mriedem no one is going to think less of you :)
23:50:15 imacdonn heh
23:50:45 imacdonn I'll take another look at it first ... don't want to embarrass myself any more than necessary :)
23:52:49 imacdonn I have another thing I wanted to get your opinion on (completely unrelated)
23:55:36 mriedem ok
23:55:52 imacdonn so when nova plugs an instance's vif into a neutron network that has MTU != 1500, something needs to set the MTU on the tap interface. Whose job is that? nova-compute? os_vif? the neutron l2 agent? ... ?
23:56:02 imacdonn asking because it's currently not getting done, and I'm not sure who to blame.
23:56:18 imacdonn For more detail, see https://ask.openstack.org/en/question/105521/whos-supposed-to-set-the-mtu-on-a-nova-instances-vifs-tap-interface/
23:56:52 mriedem sean-k-mooney: ^
23:57:02 mriedem imacdonn: in part it depends on the vif type
23:57:15 mriedem the libvirt driver isn't using os-vif yet for all vif types
23:57:35 imacdonn it is in my case .. vif_type is bridge
23:58:08 mriedem then i believe os-vif does it
23:58:28 imacdonn I think I have the terminology right there ... in any case, vif_plug_linux_bridge under os_vif creates the bridge
23:58:52 imacdonn then libvirt creates the domain, which creates the tap interface, and puts it on the bridge
23:58:57 mriedem does the network in neutron have the mtu attribute set?
23:59:06 imacdonn yes
23:59:40 imacdonn I've studied the code, and I can't find anything that's supposed to do the job
23:59:56 imacdonn I don't think os_vif can do it, because the tap interface doesn't exist yet

Earlier   Later