| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-14 | |||
| 15:28:25 | mriedem | ack, thanks | |
| 15:30:46 | luyao | sean-k-mooney: OK, get it, they should be separate if there is no surprise. :) | |
| 15:44:20 | mriedem | sean-k-mooney: did you ever write a functional test for trying to delete a compute service while a server is in VERIFY_RESIZE status for the host? i vaguely recall that coming up when i wrote test_evacuate_then_delete_compute_service | |
| 15:45:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Convert legacy nova-live-migration and nova-multinode-grenade to py3 https://review.opendev.org/692374 | |
| 15:45:48 | sean-k-mooney | am no i rememebr that but i think i ended up getting pulled into something else | |
| 15:46:41 | sean-k-mooney | i think we were conserned the resize confim would fail if the source was deleted right | |
| 15:47:39 | sean-k-mooney | because we would not be able to do the source host clean up | |
| 15:47:50 | mriedem | likely yes | |
| 15:47:57 | mriedem | or same if the dest is deleted and you try to revert | |
| 15:48:08 | sean-k-mooney | ya | |
| 15:48:19 | mriedem | ok i'll just write those tests today | |
| 15:49:31 | sean-k-mooney | ill freely admint while is am begining to understand the functional test better of late i still am less comfortable writing them then i woudl like to be | |
| 15:49:52 | mriedem | copy/paste/modify | |
| 15:50:25 | mriedem | that + stackforge = highly paid professional software engineer | |
| 15:50:29 | sean-k-mooney | ya so that i can do but im trying to understand some of the fixture and how they related a llitle more os if i need to write one i can | |
| 15:50:50 | mriedem | well, the best way to learn is to get started | |
| 15:51:18 | sean-k-mooney | hehe which is a good segway for me to go back to writign the ones you asked for yesterday | |
| 15:52:44 | sean-k-mooney | when i do have them working they are a nice way to test the code. bauzas has been suggestign we try to do more test driven developemnt usign functional tests | |
| 15:53:54 | sean-k-mooney | i do tend to rely on deploying things on really hardware or nested vert more then i proably should in my intally dev sometimes | |
| 15:56:03 | sean-k-mooney | bauzas: might also be motivated by a lack of hardware to test his things | |
| 15:59:17 | openstackgerrit | Lee Yarwood proposed openstack/nova-specs master: Boot from volume instance rescue https://review.opendev.org/694063 | |
| 16:00:27 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Stop testing Python 2 https://review.opendev.org/687954 | |
| 16:06:37 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Convert legacy nova-live-migration and nova-multinode-grenade to py3 https://review.opendev.org/692374 | |
| 16:06:38 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Stop testing Python 2 https://review.opendev.org/687954 | |
| 16:08:22 | openstackgerrit | Stephen Finucane proposed openstack/nova master: zuul: Make functional job inherit from openstack parents https://review.opendev.org/688425 | |
| 16:18:27 | openstackgerrit | Lee Yarwood proposed openstack/os-traits master: Add COMPUTE_RESCUE_BFV trait https://review.opendev.org/694033 | |
| 16:20:02 | mriedem | lyarwood: i've got some things for your stable rescue disk device spec https://review.opendev.org/#/c/693849/ | |
| 16:21:16 | lyarwood | mriedem: ack thanks, just in yet another meeting, will review once this ends. | |
| 16:22:26 | mriedem | i should likely open a docs bug b/c we don't have any documentatoin about rescue | |
| 16:23:30 | mriedem | i guess https://docs.openstack.org/nova/latest/user/reboot.html kind of | |
| 16:25:34 | lyarwood | mriedem: yeah we can break that out into a seperate section tbh | |
| 16:27:10 | openstack | Launchpad bug 1852609 in OpenStack Compute (nova) "Reboot an instance in nova - split the rescue part out" [Undecided,New] | |
| 16:27:10 | mriedem | how about just a docs bug https://bugs.launchpad.net/nova/+bug/1852609 | |
| 16:39:58 | openstack | bug 1852610 in OpenStack Compute (nova) "API allows source compute service/node deletion while instances are pending a resize confirm/revert" [Medium,Triaged] https://launchpad.net/bugs/1852610 | |
| 16:39:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional recreate test for bug 1852610 https://review.opendev.org/694351 | |
| 16:56:28 | mriedem | dansmith: how are you feeling (besides gross) about this filter duplicate migrations change https://review.opendev.org/#/c/636224/ ? is there anything you want me to do there besides burn it all down and start over? | |
| 16:56:35 | openstackgerrit | Archit Modi proposed openstack/nova stable/queens: doc: fix and clarify --block-device usage in user docs https://review.opendev.org/694357 | |
| 16:57:23 | dansmith | besides, gross.. hmm.. is "procrastinatey" a word? | |
| 16:57:46 | mriedem | it is now | |
| 16:58:15 | mriedem | if we want to genericify that i can move it to NovaBase later | |
| 16:58:34 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Remove 'os-consoles' API https://review.opendev.org/687907 | |
| 16:58:41 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Remove 'nova-console' service, 'os-consoles' API https://review.opendev.org/687908 | |
| 16:58:48 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Remove 'nova-xvpvncproxy' https://review.opendev.org/687909 | |
| 16:59:25 | dansmith | mriedem: honestly, I want someone else to +W that so I can happily move onto the later patches and forget about it | |
| 17:00:09 | mriedem | stephenfin: efried: ^ | |
| 17:01:00 | stephenfin | in a meeting, but I'll take a look after (if efried doesn't grab it first) | |
| 17:03:44 | bauzas | efried: around ? | |
| 17:04:21 | bauzas | efried: I was evaluating how much checking the COMPUTE_NODE trait would help the placement audit command https://review.opendev.org/#/c/670112 | |
| 17:05:09 | dansmith | mriedem: replied about the upgrade aspect on that stable rescue thing | |
| 17:05:54 | dansmith | mriedem: not sure if you saw the previous discussion on that spec about it, but once I found out those properties already exist I figured there's no point in trying to be strict about them now, and it's actually less compatible if we do, since they're silently ignored today | |
| 17:07:03 | mriedem | true they are silently ignored today, they also aren't documented so i'm not sure anyone would know to use them | |
| 17:07:57 | dansmith | mriedem: yeah, so I figure if someone did have them in an image today, found out they didn't work, left them, then started to upgrade...shit stops working for no obvious reason | |
| 17:08:02 | dansmith | (until fully upgraded) | |
| 17:09:26 | openstackgerrit | Archit Modi proposed openstack/nova stable/queens: doc: fix and clarify --block-device usage in user docs https://review.opendev.org/694357 | |
| 17:09:27 | openstackgerrit | Archit Modi proposed openstack/nova stable/queens: Revert "openstack server create" to "nova boot" in nova docs https://review.opendev.org/693239 | |
| 17:10:08 | mriedem | replied in the spec | |
| 17:10:32 | mriedem | it might just be that the documented replies to my questions/edge cases are done in a follow up i could drop the -1 | |
| 17:11:08 | mriedem | as it reads today, the spec is very much like "if you're using libvirt and everything is fully upgraded, you're golden" but i think it's worth documenting if those aren't true and what happens | |
| 17:11:35 | mriedem | plus there is no liaison and that's just like, -5 | |
| 17:13:36 | dansmith | mriedem: well, fwiw, I asked him to remove the hard fail, and also encouraged him to remove some of the upgrade impact, | |
| 17:13:56 | dansmith | well, nevermind, that's more the BFV one | |
| 17:14:03 | dansmith | anyway, whatever | |
| 17:14:35 | mriedem | ok. i'm just asking that rather than remove things and leave questions (which i obviously had b/c it wasn't documented), i'm asking that we're clear about intent | |
| 17:14:54 | mriedem | so in a year or 2 people aren't like, "why does it work this way? was x considered?" | |
| 17:15:00 | dansmith | yeah, not arguing against that, | |
| 17:15:27 | dansmith | more like hoping I didn't lead him too astray asking him to pare down some of it, specifically around the start-failing-when-we-didn't-before stuff | |
| 17:15:40 | mriedem | ack | |
| 17:15:54 | mriedem | never lead sweet lee astray | |
| 17:18:39 | openstack | bug 1852610 in OpenStack Compute (nova) "API allows source compute service/node deletion while instances are pending a resize confirm/revert" [Medium,Triaged] https://launchpad.net/bugs/1852610 | |
| 17:18:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional recreate revert resize test for bug 1852610 https://review.opendev.org/694364 | |
| 17:20:07 | mriedem | sean-k-mooney: ^ and the one below it are the tests we talked about | |
| 17:21:44 | efried | bauzas: Hi, here now, sorry. | |
| 17:21:54 | bauzas | efried: no worries | |
| 17:22:31 | bauzas | efried: traits from a root RP aren't automatically cascaded to their siblings, right? | |
| 17:22:43 | efried | correct | |
| 17:22:47 | bauzas | efried: because I really want to iterate over the list of RPs | |
| 17:22:48 | efried | siblings/descendants | |
| 17:23:23 | bauzas | so in a world with nested RPs, I'll look over every RP and call its root RP to see whether it's COMPUTE_NODE | |
| 17:23:24 | efried | bauzas: I need to remind myself what you're doing here. If you really just want the compute node RPs, you ought to be able to do it with GET /resource_providers?required=COMPUTE_NODE | |
| 17:23:37 | efried | and not need to iterate | |
| 17:23:49 | bauzas | efried: I want to look at every RP to see whether it has orphaned allocs | |
| 17:24:01 | bauzas | efried: scrubbing if you prefer | |
| 17:25:04 | mriedem | how are you going to determine that for nested providers? | |
| 17:25:06 | bauzas | and for that, I'm 1/ looking at the RP, 2/ ask for its allocs, 3/ see whether those allocs are compute-related (and I was using RCs for this, but I could use traits), 4/ get instances and migrations from the compute it relases, 5/ do the comparison | |
| 17:25:34 | bauzas | mriedem: the code I wrote atm is getting the root RP and get its instance and migrations | |
| 17:25:44 | mriedem | trying to build in support for nested providers from the first iteration of that audit command seems like something that will keep it from ever getting done | |
| 17:25:48 | bauzas | mriedem: and then only comparing allocations of RCs we manage | |
| 17:26:03 | mriedem | bauzas: but like efried just said, you can get the compute node roots today | |
| 17:26:07 | bauzas | mriedem: that doesn't really overcomplexify the logic | |
| 17:26:08 | mriedem | or with that trait i guess | |
| 17:26:32 | mriedem | so, "i want to do x but the slow way" | |
| 17:26:42 | bauzas | mriedem: yup, that's what I'm changing as of now, instead of looking at Nova RCs, I'm just looking whether the root RP is havint the trait | |
| 17:26:45 | bauzas | having* | |
| 17:26:48 | efried | Okay, that was the missing piece: if we're truly not trying to implement support for nested (or sharing) then using the trait will get you back all and only roots in one query. | |
| 17:27:12 | efried | though I'm not fully grasping why we wouldn't include logic for nested right now. | |
| 17:27:18 | mriedem | efried: i'm not saying those aren't cases to consider, but i wouldn't in v1 | |
| 17:27:30 | mriedem | efried: he's been working on this for like a year | |
| 17:27:32 | bauzas | mriedem: the current patch is managing nested | |
| 17:27:34 | efried | heh | |
| 17:27:50 | sean-k-mooney | mriedem: thanks i have added them to my review list | |