Earlier  
Posted Nick Remark
#openstack-nova - 2017-08-30
13:56:51 cdent so being able to say “put some allocations for both this migration uuid and this consumer uuid in one go”?
13:56:54 cdent jinx
13:57:11 dansmith without this, I could delete the instance allocation and create the migration one, but there's a race, or reverse that, but then I need twice the space available for a second
13:57:16 dansmith cdent: yes, that
13:57:59 dansmith cdent: so right now I'm doing the safer option which will fail if computes are full, but I think we should go for the atomic swap before we call this done
13:58:14 cdent one way to do that woudl be POST /allocations
13:58:31 cdent in fact I would say that’s probably the only way to do that
13:59:03 dansmith https://review.openstack.org/#/c/498949/1/nova/compute/manager.py
13:59:09 dansmith L3801 here is the first example
13:59:22 cdent yeah, I was just through there a few minutes ago
13:59:32 dansmith okay cool, so could you cook that up for us?
14:00:08 cdent yeah, shouldn’t be too hard, I’m trying to think what the body should look like
14:00:28 cdent we’ve already complained about this mismatch between GET and PUT on /allocations/{c_u}
14:00:51 cdent so if we’re considering changing the PUT format, then would be best to make POST similar to that
14:01:05 dansmith well,
14:01:26 dansmith POST of multiple things being slightly different than a PUT of one is less terrible than PUT/GET of a single thing being different
14:01:33 cdent we’ll also want to decide, sooner than later, if this POST is only for one project_id, user_id pair, or can be mixed?
14:01:38 dansmith but yeah, whatever we need to do..
14:01:56 cdent dansmith: yeah, sure, but it’s a question of list or dict being the fundamental structure
14:01:56 dansmith well, for this we only need it to apply to a single project/user
14:02:04 dansmith ack
14:02:27 cdent I’ve got a nine hour flight tomorrow, I’ll see if I can make it happen then
14:02:50 dansmith theoretically you wouldn't (or shouldn't) need atomic operations across tenants/users, but I'm also not sure there's a good reason to specifically design it not to work
14:03:18 dansmith cdent: cool, decide on these things, put it in a spec calling out the potential questions and we can go from there
14:03:29 cdent ✔
14:03:42 dansmith thanks!
14:04:26 cdent a pleasure. it feels like it’s been a while since I’ve written much code
14:05:45 cdent edleafe, jaypipes : if you have any ideas/concerns with what dan and I just discussed ^ please let me know before tomorrow morning (I’ll see about cooking a quick spec sooner)
14:10:42 mriedem o/
14:11:36 edleafe cdent: this would be a PUT against /allocations (no {consumer_uuid}), right?
14:12:05 cdent edleafe: I’m thinking POST as PUT would imply a replace of _all_ allocations
14:13:12 dansmith cdent: all allocations for any consumer specified in the body you mean
14:13:20 mriedem efried: can you redo this with the -x option for git cherry-pick? https://review.openstack.org/#/c/498463/
14:13:33 efried mriedem ...
14:13:38 cdent dansmith: a PUT to /uri means replace resource /uri
14:14:00 dansmith oh sorry I misread,
14:14:06 dansmith you were saying a PUT would imply replacing all
14:14:08 dansmith gotcha
14:14:08 efried mriedem Hmph, I cherry-picked it from gerrit; isn't that supposed to do the -x thing? Will redo.
14:14:11 edleafe cdent: yeah, what dansmith just said. POST is fortunately flexible.
14:14:12 cdent but POST to /uri means create some stuff using whatever semantics you want, and the semantics we want are “create some allocations for the multiple consumers ids we speak here"
14:14:28 mriedem efried: not if the change you're cherry picking from in gerrit isn't merged yet
14:14:37 efried mmkay
14:14:51 cdent efried: I got caught by that the other day and shook my tiny fist
14:15:22 efried mriedem Do you care if it's a new change set?
14:16:18 efried Actually, is the only difference the "(cherry picked from commit 9c7d73195e4fd1c890228e3223106ccf4f13e22b)" line?
14:17:06 efried howzat: https://review.openstack.org/#/c/498463/
14:18:29 efried (No bot post for stable? (Have I asked that before? (Seems like a reasonable thing to have; should be relatively few, and certainly noteworthy.)))
14:19:39 mriedem efried: patch bot post for stable would be fine, but you'd have to find out where that is configured; it's either in project-config or system-config
14:20:02 efried will dig
14:22:19 beagles moshele, I was going over https://bugs.launchpad.net/os-vif/+bug/1713590 with sean-k-mooney the other day.
14:22:20 openstack Launchpad bug 1713590 in os-vif "Plugging VFs no longer works without a readable phys_switch_id" [Medium,Triaged]
14:23:58 beagles moshele, it seems that ordering of the mechanism_drivers is a new backwards-compatibility-breaking requirement. Is there a use pattern outside of reordering configurations that could workaround the issue of direct ports getting "caught" by the ovs plugging?
14:25:01 beagles moshele, I was also expecting a failed bind to go to the next driver that supported that port type, but this apparently does not happen
14:25:56 beagles moshele, in short... how is this expected to work :)
14:29:22 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Move 'ipv6' opts to 'network' https://review.openstack.org/499168
14:29:29 efried mriedem https://review.openstack.org/499167
14:31:02 beagles sean-k-mooney, same question ^ :)
14:32:11 mriedem oh gantt
14:37:03 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Remove deprecated 'remap_vbd_dev' option https://review.openstack.org/499172
14:38:06 openstackgerrit Steve Noyes proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
14:44:39 moshele beagles: why reordering is not good?
14:44:59 beagles moshele, if somebody upgrades the packages but not the configuration for example
14:45:47 beagles moshele, in the tripleo change for example.. that is just an example. There will be users that will have custom environments and there is good possibility that they will miss the change
14:46:16 beagles moshele, and anybody not using tripleo or other deployment tools may also miss it
14:47:29 beagles moshele, once they upgrade booting new instances may fail or perhaps worse, become OVS offloaded ports when that was not their intention
14:47:37 beagles moshele, or am I misunderstanding the situation
14:48:15 gibi efried: if you are still looking for configuring the gerritbot to send stable notifications then I think here is an example for that https://review.openstack.org/#/c/499175/
14:48:43 moshele beagles: they failed they won't be ovs offload because you need to put the NIC in a specific mode
14:48:58 efried gibi Thanks! I proposed https://review.openstack.org/499167
14:49:35 beagles moshele, is there a way to create a port so it forces it be used as SR-IOV only
14:49:55 gibi efried: cool
14:50:07 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Remove '[conductor] topic' opt https://review.openstack.org/499179
14:50:21 beagles moshele, that statement also presumes that they want the offload plug path at all
14:51:12 moshele beagles: can you call me on the phone?
14:51:20 beagles moshele, I can try :)
14:52:01 moshele +97274129557
15:10:07 mriedem dansmith: cburgess: med_: have at it http://lists.openstack.org/pipermail/openstack-dev/2017-August/121654.html
15:17:52 openstackgerrit Artom Lifshitz proposed openstack/nova master: Test InstanceNotFound handling in 'nova usage' https://review.openstack.org/468514
15:19:28 openstackgerrit Dan Smith proposed openstack/nova-specs master: WIP: Add migration-allocations spec https://review.openstack.org/498510
15:20:04 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Move 'ipv6' opts to 'network' https://review.openstack.org/499168
15:22:55 openstackgerrit Artom Lifshitz proposed openstack/nova master: Add skip_latest_microversion decorator https://review.openstack.org/433585
15:22:55 openstackgerrit Artom Lifshitz proposed openstack/nova master: Run api sample tests against 2.latest https://review.openstack.org/430352
15:25:29 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Tweak connection_info translation for the new Cinder attach/detach API https://review.openstack.org/493324
15:25:29 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Add attachment_complete call to volume/cinder.py https://review.openstack.org/493323
15:25:30 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
15:40:21 openstackgerrit Matt Riedemann proposed openstack/osc-placement master: Fix the bug link in the readme https://review.openstack.org/499206
16:07:32 melwitt mdbooth, kashyap: I'd appreciate it if one of you could sanity check a patch of mine where I'm trying to save an updated domain XML after a volume swap https://review.openstack.org/#/c/498983
16:07:43 kashyap melwitt: Hi
16:07:51 kashyap Will check
16:08:33 melwitt thanks kashyap. the concern on the patch is whether it's correct to read the live config and use it to redefine the domain, or if that has any potential pitfalls
16:09:14 kashyap melwitt: Noted. I'd normally check w/ danpb on the live config thing, but let me see if I can figure it out first :-)
16:13:30 stephenfin mriedem: Is osc-placement something we're supporting? I was going to fix the docs for doc-migration a while back, but there's only one commit and it was 5 months ago
16:14:17 melwitt kashyap: k. I tested the patch locally with devstack and it seemed to work fine, i.e. the instance soft-rebooted successfully and I see the domain in 'virsh list'
16:14:44 sdague stephenfin: I thought mriedem was going to trigger a release
16:14:48 sdague it's not released yet
16:14:56 kashyap melwitt: Good. But just to note -- the blockRebase() API behaviour documented is still true
16:15:30 stephenfin sdague: Oh, maybe that's it. Wonder if the docs need to be fixed at some point so?
16:16:00 kashyap melwitt: Please report your testing there. I'll comment in a few
16:16:24 kashyap melwitt: Ah, you _did_ report

Earlier   Later