| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-11 | |||
| 18:45:01 | openstackgerrit | John Garbutt proposed openstack/nova: Extract preallocate_for_instance https://review.openstack.org/418876 | |
| 18:45:02 | openstackgerrit | John Garbutt proposed openstack/nova: Pass objects into _create_ports_for_instance https://review.openstack.org/418512 | |
| 18:45:02 | openstackgerrit | John Garbutt proposed openstack/nova: Pass objects into _update_ports_for_instance https://review.openstack.org/418513 | |
| 18:46:17 | artom | claudiub|2, around? Can you take a look at https://review.openstack.org/#/c/415520/ and https://review.openstack.org/#/c/418100/? It's the virt driver patches for the continuation of device tagging, tagged attachment of nics and volumes | |
| 18:46:53 | artom | I'm not sure I have a specific ask as of yet, as their shape could change in response to reviews, but would something like that be doable for hyper-v? | |
| 18:50:37 | claudiub|2 | looking | |
| 18:50:54 | claudiub|2 | meanwhile, happy new year. :D | |
| 18:51:21 | artom | claudiub|2, thanks, same to you :) And happy orthodox christmas, if you're into that stuff ^_^ | |
| 18:52:06 | claudiub|2 | hm, i am orthodox, but my christmas was in 25th dec. :D | |
| 18:52:47 | claudiub|2 | artom: question: shouldn't the configdrive be regenerated, to also include the new tag? | |
| 18:53:12 | artom | claudiub|2, yeah, but that's trickier, since we need to wait for the instance to be off | |
| 18:53:27 | artom | We can't just yank it from underneath the guest while it's running | |
| 18:53:36 | artom | It may be mounted, etc | |
| 18:55:11 | claudiub|2 | hm, how about regenerating it on interface_attach, but don't attach it yet, and then attach the new one on power_on? | |
| 18:56:12 | openstackgerrit | Balazs Gibizer proposed openstack/nova: Improve flavor sample in notification sample tests https://review.openstack.org/419086 | |
| 18:56:19 | claudiub|2 | artom: also, i suppose you will want to merge this before the feature-freeze, right? | |
| 18:56:44 | artom | claudiub|2, in my wildest dreams, yeah :) | |
| 18:56:59 | artom | But I'm aware this is pretty last minute | |
| 18:58:28 | claudiub|2 | anyways. it is doable for hyper-v | |
| 18:58:28 | gibi | mriedem: I improved the flavor extra_specs part of the instance. |
|
| 18:58:32 | openstackgerrit | Dan Smith proposed openstack/nova: Don't bypass cellsv1 replication if cellsv2 maps are in place https://review.openstack.org/418141 | |
| 18:58:45 | claudiub|2 | i'll have to send up a patch for it then. :) | |
| 18:59:26 | claudiub|2 | doesn't seem like much to be done, imo. only that configdrive regeneration is a bit trickier | |
| 19:00:06 | claudiub|2 | artom: also, regarding device tagging, are pci devices tagged as well? | |
| 19:00:29 | artom | claudiub|2, don't think so... | |
| 19:00:47 | artom | There's no API for it | |
| 19:01:51 | mriedem | gibi: ok | |
| 19:02:18 | mriedem | GET /nova-core/jaypipes -> 200! | |
| 19:02:32 | mriedem | jaypipes: when you have 10 free minutes, could you please manhandle this? https://review.openstack.org/#/c/140045/ | |
| 19:03:26 | mriedem | claudiub|2: while you're around there were some comments in https://review.openstack.org/#/c/282407/ - i'm not sure if they are all valid though, so would be cool to respond to those sooner than later | |
| 19:05:29 | dansmith | mriedem: um, I think you mean personhandle | |
| 19:06:05 | mriedem | dansmith: do women womanhandle? | |
| 19:06:18 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova: Updated from global requirements https://review.openstack.org/415978 | |
| 19:06:27 | dansmith | mriedem: I feel like this is a trap | |
| 19:06:43 | mriedem | it is, and you haven't yet taken your corporate training course on this yet for 2017 | |
| 19:06:58 | dansmith | true story | |
| 19:08:41 | jaypipes | mriedem: hey yeah, I'm on it. spurious network connectivity and human bandwidth issues all this week, sorry. | |
| 19:15:08 | openstackgerrit | Gábor Antal proposed openstack/nova: Transform instance.volume_attach notification https://review.openstack.org/401992 | |
| 19:15:15 | edleafe | We need HA Jay | |
| 19:17:03 | jaypipes | edleafe: *I* need HA Jay :( | |
| 19:18:55 | jaypipes | :) | |
| 19:19:06 | claudiub|2 | artom: i see. :) | |
| 19:19:09 | JayF | I don't think you could even lift me, much less hand me over to someone ;) | |
| 19:19:32 | claudiub|2 | mriedem: replied. :) | |
| 19:21:22 | claudiub|2 | mriedem: although, not exactly sure how to treat a certain comment: Andrey Volkov was asking if there could be a way to warn operators that if they want to use hyper-v vnuma, they'd have to disable the numa spanning on the host. is there any other better way to do this (except release notes)? | |
| 19:24:21 | openstackgerrit | Gábor Antal proposed openstack/nova: Transform instance.volume_detach notification https://review.openstack.org/408676 | |
| 19:38:33 | EmilienM | I think I found something "weird" in nova-compute & nova-placement | |
| 19:39:01 | EmilienM | if you start n-cpu *before* n-placement, n-compute will never retry to register the placement services | |
| 19:41:02 | diana_clarke | dansmith: ^ was that what you were talking about yesterday? That you were going to change to keep retrying? Ignore me if I've missunderstood. | |
| 19:41:10 | openstackgerrit | Lee Yarwood proposed openstack/nova: libvirt: Ensure to_xml always returns an ASCII string https://review.openstack.org/402382 | |
| 19:41:12 | openstackgerrit | Lee Yarwood proposed openstack/nova: libvirt: utils.get_disk return the target dev of the root device https://review.openstack.org/402716 | |
| 19:41:13 | openstackgerrit | Lee Yarwood proposed openstack/nova: libvirt: Use the mirror element to detect when to pivot https://review.openstack.org/399735 | |
| 19:41:15 | openstackgerrit | Lee Yarwood proposed openstack/nova: libvirt: Make guest.BlockDevice only use the target dev of a disk https://review.openstack.org/402163 | |
| 19:41:15 | openstackgerrit | Lee Yarwood proposed openstack/nova: libvirt: Wait for abort_job to complete when not resizing https://review.openstack.org/382449 | |
| 19:42:09 | diana_clarke | dansmith: perhaps this patch? https://review.openstack.org/#/c/418590/ | |
| 19:43:00 | dansmith | EmilienM: diana_clarke yep | |
| 19:43:04 | EmilienM | oh wow | |
| 19:43:07 | EmilienM | but it's not only scheduler | |
| 19:43:09 | EmilienM | it's also compute | |
| 19:43:19 | dansmith | EmilienM: it's only compute, and it was intentional, but a little naive | |
| 19:43:50 | EmilienM | https://review.openstack.org/#/c/418590/4/nova/scheduler/client/report.py is run by nova-compute? | |
| 19:43:56 | dansmith | EmilienM: yes | |
| 19:44:02 | EmilienM | nice | |
| 19:44:06 | EmilienM | thanks! | |
| 19:44:07 | dansmith | EmilienM: it's the scheduler *client* which is the client of the scheduler, which would be compute | |
| 19:44:17 | EmilienM | we need this patch :D | |
| 19:44:25 | dansmith | EmilienM: I wrote it for you dude :) | |
| 19:44:48 | EmilienM | dansmith: yeah? I just found the bug in tripleo :-P | |
| 19:45:00 | EmilienM | we deploy placement but in some random cases, it was not starting. | |
| 19:45:18 | dansmith | EmilienM: I did, specifically to make the upgrade case a little more graceful | |
| 19:45:24 | dansmith | EmilienM: planning to backport that to newton | |
| 19:46:26 | EmilienM | dansmith++ | |
| 19:47:25 | EmilienM | dansmith: do you think https://review.openstack.org/#/c/418590/ can merge today? | |
| 19:52:16 | dansmith | EmilienM: you should hassle someone that can do something about it | |
| 19:52:28 | dansmith | EmilienM: jaypipes once was +2 on that and may grant your wish | |
| 19:56:02 | EmilienM | jaypipes: in case you have some time to review, please: https://review.openstack.org/#/c/418590/ | |
| 20:01:18 | mriedem | claudiub|2: you could emit a warning in the logs... | |
| 20:02:16 | mriedem | claudiub|2: i'd also get it into the numa docs in the admin guide: http://docs.openstack.org/admin-guide/compute-cpu-topologies.html - so tag the patch with DocImpact and leave a comment in the commit message about updating those docs? | |
| 20:02:31 | diana_clarke | mriedem: I wasn't sure what to work on instead, so I am going to keep playing with microversions & osc. We'll see how it goes. https://review.openstack.org/#/c/419108/ | |
| 20:03:28 | mriedem | dansmith: are you going to tweek the docs in a follow up to https://review.openstack.org/#/c/418590/ ? | |
| 20:03:38 | mriedem | i.e. http://git.openstack.org/cgit/openstack/nova/tree/doc/source/placement.rst?id=f5d7ea52c681611c2d85f344da643f9f630d1ef9#n108 | |
| 20:04:30 | dansmith | mriedem: tbh, it's not high on my list considering time available and the rush to unfsck the current stuff | |
| 20:04:38 | dansmith | mriedem: if you think it's a priority for right now then I will, | |
| 20:04:49 | dansmith | but if not, maybe we could find someone interested in doing it? | |
| 20:05:14 | diana_clarke | dansmith, mriedem: I can try and do it. | |
| 20:05:41 | dansmith | diana_clarke: cool, thanks | |
| 20:06:18 | mriedem | i don't really see how spamming the logs fixes the complaints i was hearing from the red hat people yesterday, | |
| 20:06:27 | mriedem | but if it's something you guys have agreed it makes your lives easier somehow, then ok | |
| 20:06:40 | mriedem | that's all, re: why i'm not rushing it in | |
| 20:07:01 | dansmith | mriedem: spamming the logs doesn't fix anything for us, continuing to try does | |
| 20:07:09 | openstackgerrit | Dan Smith proposed openstack/nova: Make metadata server know about cell mappings https://review.openstack.org/417962 | |
| 20:07:11 | openstackgerrit | Dan Smith proposed openstack/nova: WTFWIP: Multicell support for instance listing https://review.openstack.org/396775 | |
| 20:07:11 | openstackgerrit | Dan Smith proposed openstack/nova: Don't bypass cellsv1 replication if cellsv2 maps are in place https://review.openstack.org/418141 | |
| 20:09:05 | mriedem | ok so in a point release rhops rolls out creds to the newton computes and restarts nova-compute on them, right? which as long as they keep trying to connect to placement, it just happens whenever rhosp rolls out the placement service in an update for newton? i guess i just figured the restart that you need to do for the computes would come after placement is available, at which point we don't need the continual retry | |
| 20:09:52 | dansmith | mriedem: we can't really enforce that ordering, | |
| 20:10:06 | dansmith | in general, and for a couple different approaches to the upgrade | |
| 20:10:33 | mriedem | ok so you/we might avoid an unnecessary restart of the computes depending on the order of the upgrade | |
| 20:10:35 | mriedem | which is the point | |
| 20:11:10 | mriedem | w/o the patch, you could have deployed creds updates to the computes, restarted them, then rolled out placement, at which point you have to go back and restart all of the computes again | |
| 20:11:22 | mriedem | and it's that potential 2nd mass restart that is the point of the patch (trying to avoid it) | |