| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-16 | |||
| 13:57:56 | KeithMnemonic | frickler i will let you know what i find out. so far it seems some sort of access issue with the backend rbd disk during an evacuation | |
| 14:06:30 | openstackgerrit | Dan Smith proposed openstack/python-novaclient master: Add aggregate-cache-images command and client routines https://review.opendev.org/687141 | |
| 14:07:55 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Microversion 2.80: Add user_id/project_id to migration-list API https://review.opendev.org/675023 | |
| 14:09:30 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Add aggregate-cache-images command and client routines https://review.opendev.org/687141 | |
| 14:15:03 | bauzas | mriedem: sorry, got some network issues last hour, just saw your ping | |
| 14:16:29 | bauzas | mriedem: FWIW, what I do with the audit command is that I look at all the RPs and then look at all the allocations | |
| 14:16:48 | bauzas | if some allocation is not either related to an instance or a migration, I tell it | |
| 14:20:08 | mriedem | with an option to delete the allocation? | |
| 14:21:22 | bauzas | yup | |
| 14:21:46 | bauzas | mriedem: I still have an issue with some placement call because I need to pass a microversion | |
| 14:21:57 | bauzas | but for the moment, I'm updating some unittests | |
| 14:22:32 | mriedem | do you filter the resource providers at all based on inventory or trait to know they are compute nodes, e.g. GET /resource_providers?resources=VCPU:1 | |
| 14:22:46 | mriedem | to like weed out things we won't care about | |
| 14:23:45 | mriedem | MEMORY_MB would probably be more appropriate given PCPU could complicate things now if a node never reports VCPU inventory | |
| 14:34:17 | bauzas | mriedem: we get all allocations but we skip those not related to nova RCs https://review.opendev.org/#/c/670112/7/nova/cmd/manage.py@2794 | |
| 14:40:44 | openstackgerrit | Dan Smith proposed openstack/nova master: Fix up some feedback on image precache support https://review.opendev.org/688172 | |
| 14:40:45 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Add image precaching docs for aggregates https://review.opendev.org/687348 | |
| 14:40:45 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Log some stats for image pre-cache https://review.opendev.org/688173 | |
| 14:43:01 | openstackgerrit | Merged openstack/nova-specs master: Add 'Feature Liaison' spec process https://review.opendev.org/685857 | |
| 14:46:59 | mriedem | bauzas: i'm saying we could optimize here https://review.opendev.org/#/c/670112/7/nova/cmd/manage.py@2921 by filtering out providers that aren't going to be compute nodes | |
| 14:47:08 | mriedem | i.e. providers that don't provide MEMORY_MB inventory | |
| 14:47:22 | mriedem | although, | |
| 14:47:31 | mriedem | i guess that would break ironic node providers... | |
| 14:47:32 | mriedem | so nevermind | |
| 14:48:12 | bauzas | mriedem: well, maybe we could use consumer types once it's done | |
| 14:48:36 | bauzas | ie. asking for RPs having some "Nova" consumer type | |
| 15:13:13 | mriedem | bauzas: not that i was actively reviewing it, but approving a policy change like https://review.opendev.org/#/c/685857/ without at least the majority of the core team acking it seems wrong | |
| 15:13:34 | mriedem | i guess my fault for not being more involved | |
| 15:13:46 | efried | https://www.zdnet.com/article/the-openstack-train-keeps-chugging-on/ Nova features are mentioned (albeit pretty inaccurately) | |
| 15:14:00 | mriedem | i heard there is a cyborg spec! | |
| 15:14:10 | mriedem | the marketing machine does it's job again | |
| 15:14:14 | mriedem | *its | |
| 15:14:16 | efried | ikr | |
| 15:15:36 | mriedem | i guess that was because of https://releases.openstack.org/train/highlights.html#cyborg-accelerator-life-cycle-management | |
| 15:22:44 | efried | I guess now that we've made such a big deal about SEV, AMD had better find someone to support it. I like how they plastered SUSE's departure all over the place without connecting the two at all. | |
| 15:34:26 | mriedem | "we" :) | |
| 15:36:21 | dansmith | ugh. | |
| 15:40:49 | dansmith | mriedem: a couple questions on your reviews from that client patch | |
| 15:40:51 | dansmith | if you please | |
| 15:48:22 | bauzas | mriedem: I feel bad then, my apologies | |
| 15:48:38 | mriedem | dansmith: replied | |
| 15:48:38 | bauzas | mriedem: we can honestly revert the change for asking at least for more | |
| 15:49:24 | bauzas | mriedem: do you want me to provide the revert change (and then the revert of revert) ? | |
| 15:49:27 | bauzas | efried: WFY ? | |
| 15:49:29 | mriedem | no | |
| 15:49:44 | mriedem | i'd say if someone on the core team has a stink about what was merged we can amend later | |
| 15:50:05 | bauzas | ok, I can write a ML email to mention it got merged then | |
| 15:50:20 | mriedem | sure | |
| 15:50:26 | bauzas | and ask for people to provide some change if they disagree with some stuff | |
| 15:50:28 | bauzas | ok, doing | |
| 15:50:33 | bauzas | mriedem: and again, apologies | |
| 15:51:07 | bauzas | FWIW, those were my notes for the +2 "OK, after commenting a lot about this spec process, I think I'm quite +2 with it, even if I could still have some concerns. Given it's important to have a consensus about this, I think it's more important to just accept it and then providing other follow-ups if there would be some points." | |
| 16:00:41 | efried | bauzas: I already wrote an email mentioning it's merged. | |
| 16:00:55 | bauzas | efried: ack | |
| 16:01:40 | efried | http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010158.html | |
| 16:02:18 | efried | Let's be honest, if we waited for a majority of cores, we would be waiting forever. Not because they necessarily object, but because they don't care. | |
| 16:03:03 | mriedem | that's why i said it's fine to just amend if people care or take issue with it at this point | |
| 16:03:08 | efried | ++ | |
| 16:21:04 | mriedem | dansmith: replied on https://review.opendev.org/#/c/688832/ - that's just a wip right now that i pushed late last night, it's definitely not in final form, | |
| 16:21:12 | mriedem | i'm working on a recreate test for the latent same-cell resize bug | |
| 16:22:12 | openstackgerrit | Eric Fried proposed openstack/os-traits master: Add COMPUTE_NODE trait https://review.opendev.org/688969 | |
| 16:26:09 | melwitt | mriedem: question on this in case you didn't see https://review.opendev.org/687427 | |
| 16:28:19 | dansmith | mriedem: aight | |
| 16:30:12 | dansmith | mriedem: so on this object-or-id thing, | |
| 16:31:05 | dansmith | mriedem: if I take either are you expecting me to validate the uuid if it was given, or just pass that in the body? Like, leave the actually-check-with-glance part in the CLI shell, and just make the python API able to do either, but not validate? | |
| 16:37:20 | dansmith | mriedem: I guess based on the other examples, just include and not validate | |
| 16:37:48 | mriedem | the cli would get the image from glance based on name or id, | |
| 16:37:55 | mriedem | the python api binding method would just pass through | |
| 16:38:09 | dansmith | yeah | |
| 16:38:13 | mriedem | that's how other api methods like create, rebuild, rescue work | |
| 16:38:25 | dansmith | I'm not a fan, but consistency is more important for usre | |
| 16:39:48 | mriedem | if going directly to the api we'll barf and return a 400 if the image doesn't exist | |
| 16:39:49 | mriedem | so i think we're ok | |
| 16:40:17 | dansmith | yeah | |
| 16:45:44 | mriedem | melwitt: replied, thanks | |
| 16:46:06 | melwitt | ack thanks | |
| 16:46:30 | openstackgerrit | Dan Smith proposed openstack/python-novaclient master: Add aggregate-cache-images command and client routines https://review.opendev.org/687141 | |
| 17:00:29 | openstackgerrit | Eric Fried proposed openstack/nova master: Always trait the compute node RP with COMPUTE_NODE https://review.opendev.org/688979 | |
| 17:11:17 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional recreate test for bug 1848343 https://review.opendev.org/688980 | |
| 17:11:17 | openstack | bug 1848343 in OpenStack Compute (nova) "MigrationTask rollback can leak allocations for a deleted server" [Medium,Triaged] https://launchpad.net/bugs/1848343 | |
| 17:11:17 | mriedem | dansmith: here is a pretty simple recreate of that latent allocation leak bug ^ | |
| 17:12:12 | dansmith | schwing | |
| 17:16:58 | mriedem | this is your reward https://www.youtube.com/watch?v=vKDx_66nnAw | |
| 17:17:25 | efried | ye gods, save me from SRV | |
| 17:17:34 | efried | <eyeroll> | |
| 17:19:10 | dansmith | I will say | |
| 17:19:31 | dansmith | I didn't think you could get too much SRV, but living in Austin made it clear that you can | |
| 17:19:40 | efried | exactly | |
| 17:20:04 | dansmith | which is too bad, because SRV is awesome and Austin just kinda messes that up | |
| 17:20:06 | efried | because you not only get SRV, you get every freaking SRV clone ever | |
| 17:20:27 | efried | though I've never been a fan of that style of blues personally. Way too homogeneous. | |
| 17:20:48 | efried | but SRV+clones took it from meh to active dislike | |
| 17:22:59 | melwitt | same thing in houston, I grew to hate SRV from oversaturation | |
| 17:51:14 | mriedem | it's all about hotdish | |
| 17:51:24 | mriedem | and bad sports teams | |
| 17:59:24 | openstackgerrit | Merged openstack/python-novaclient master: Microversion 2.80: Add user_id/project_id to migration-list API https://review.opendev.org/675023 | |
| 18:01:04 | openstackgerrit | Ghanshyam Mann proposed openstack/nova-specs master: Re-propose policy-defaults-refresh spec for Ussuri https://review.opendev.org/686058 | |
| 18:01:36 | KeithMnemonic | frickler I will let you know what I find out. my guess is it is some config issue in this one env, as so far i can not reproduce it | |
| 18:01:52 | gmann | melwitt: I added you as 'Feature Liaison' in policy spec re-proposed for U. https://review.opendev.org/#/c/686058/ | |
| 18:01:58 | KeithMnemonic | ah did not see i posted already, too much going on today | |