| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-17 | |||
| 08:21:26 | openstackgerrit | Takashi Natsume proposed openstack/nova master: Remove six.text_type (2/2) https://review.opendev.org/728117 | |
| 09:35:35 | openstackgerrit | Wenping Song proposed openstack/nova master: delete sub resource provider when delete resource provider https://review.opendev.org/719163 | |
| 09:48:25 | openstackgerrit | sunhao proposed openstack/nova stable/train: hardware: Raise useful error for invalid mempage size https://review.opendev.org/735950 | |
| 10:04:23 | stephenfin | bauzas: Care to review https://review.opendev.org/#/c/734658/ ? | |
| 10:04:32 | bauzas | I can | |
| 10:04:42 | stephenfin | ta | |
| 10:04:47 | bauzas | fwiw, I want to look at runways | |
| 10:47:25 | brinzhang0 | stephenfin: hi, we encounter an issue, and I register a blueprint, can you review it? https://blueprints.launchpad.net/oslo.cache/+spec/enable-sasl-protocol | |
| 10:48:14 | brinzhang0 | stephenfin: thanks | |
| 11:57:11 | openstackgerrit | Alexandre Arents proposed openstack/nova master: Snapshot: offload glance upload in a native thread https://review.opendev.org/734776 | |
| 11:57:17 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Extend is_ipv6_supported() to cover more error cases https://review.opendev.org/736167 | |
| 12:02:35 | openstackgerrit | Alexandre Arents proposed openstack/nova master: Limit the number of concurrent snapshots https://review.opendev.org/736169 | |
| 12:17:27 | openstackgerrit | Sean McGinnis proposed openstack/nova master: Use unittest.mock instead of third party mock https://review.opendev.org/714676 | |
| 12:27:58 | openstackgerrit | Sean McGinnis proposed openstack/nova master: hacking: force explicit import of python's mock https://review.opendev.org/708768 | |
| 12:41:47 | openstackgerrit | Merged openstack/nova master: libvirt: Don't allow "reserving" file-backed memory https://review.opendev.org/734658 | |
| 13:00:15 | openstackgerrit | Alexandre Arents proposed openstack/nova master: Limit the number of concurrent snapshots https://review.opendev.org/736169 | |
| 13:04:23 | openstackgerrit | Alexandre Arents proposed openstack/nova master: Snapshot: offload glance upload in a native thread https://review.opendev.org/734776 | |
| 13:37:45 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/ussuri: libvirt: Don't allow "reserving" file-backed memory https://review.opendev.org/736219 | |
| 14:02:19 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Extend is_ipv6_supported() to cover more error cases https://review.opendev.org/736167 | |
| 14:24:19 | TheJulia | Greetings nova folks, would nova be generally amenable if the ironic virt driver had a capability for a user of reserving a physical baremetal machine but not actually triggering the deployment. We're thinking this would basically be a trait, and we could teach ironic to just ignore the deploy if the trait is present, but we woudl also likely update permissions so the user is "leased" the physical node. | |
| 14:25:09 | dansmith | TheJulia: you mean exclude machines with that trait set from the scheduling decision right? | |
| 14:25:28 | TheJulia | well, mark it in use/active in nova | |
| 14:26:00 | TheJulia | and tell ironic "hey, this user asked for and is now allocated this hardware" and then the user can pivot APIs to perform super advanced operations | |
| 14:26:32 | dansmith | meaning nova just "reserves" the node in ironic but does nothing with it, assuming the user is going to do stuff with it out of band? | |
| 14:26:50 | TheJulia | no, more like we just skip the final step telling ironic to perform the deployment | |
| 14:27:01 | dansmith | how is that different? | |
| 14:27:39 | TheJulia | today we actually trigger a deployment which means the machine is delivered in an active state | |
| 14:28:00 | dansmith | I mean how is what you said not what I said? | |
| 14:28:17 | sean-k-mooney | TheJulia: this sound more like a blazar usecase | |
| 14:28:27 | dansmith | if nova reserves the node (i.e. in placement) but just doesn't ask ironic to do anything with it, that's what you're asking right? | |
| 14:28:30 | dansmith | sean-k-mooney: agreed | |
| 14:28:43 | sean-k-mooney | that said we have a trait for marking a compute node as down today | |
| 14:28:56 | sean-k-mooney | if it was a maintaince usecase then that woudl be approporte to use | |
| 14:29:04 | sean-k-mooney | we dont really have a reservation concept in nova however | |
| 14:29:10 | sean-k-mooney | not sure how we would cleanly add one | |
| 14:29:11 | dansmith | sean-k-mooney: I think TheJulia is asking for the opposite of that, for nova to do everything we would normally do to boot on a node, but just ... not boot on the node | |
| 14:29:40 | dansmith | sean-k-mooney: which is basically making nova a reserve-but-don't-touch service, which wouldn't be sensical for anything other than resources that already exist (i.e. physical machines) | |
| 14:29:41 | sean-k-mooney | dansmith: right so still run through the schduler and select the node | |
| 14:29:58 | TheJulia | Lets just drop this because this discussion is just going to not be productive | |
| 14:30:23 | sean-k-mooney | we had a concept of allowing boot to put instancve into states other then active. e.g. the boot to shelved usecase | |
| 14:30:44 | sean-k-mooney | would something like that make sense | |
| 14:31:01 | sean-k-mooney | TheJulia: ^ im just not sure what state you would want the instance to be in Nova | |
| 14:31:03 | TheJulia | sean-k-mooney: possibly, I'll pass along the idea | |
| 14:31:13 | dansmith | sean-k-mooney: you mean "we discussed that thing once upon a time" :) | |
| 14:31:15 | TheJulia | sean-k-mooney: ideally active to nova's perception | |
| 14:31:32 | sean-k-mooney | dansmith: yes | |
| 14:32:03 | dansmith | sean-k-mooney: I think the goal here is to use nova's scheduler but not the nova-compute part, which would kinda be akin to "we provision empty VMs on the hypervisor and then you do what you want with them, | |
| 14:32:10 | sean-k-mooney | TheJulia: so rather then a trait if i was to propose something like this i would proably use an extra spec | |
| 14:32:16 | dansmith | which goes against the whole "don't manage our VMs out of band" goal | |
| 14:32:40 | sean-k-mooney | dansmith: right it would conflict with that | |
| 14:32:43 | dansmith | and it would make alllll the other operations you can do on an instance have to be disabled somehow | |
| 14:33:03 | sean-k-mooney | we did have some driver that wanted to prespawn some vms and reallocate one on a boot request in the past right | |
| 14:33:05 | dansmith | like, what does it mean for you to do a reboot or rebuild or anything else on an instance in that case | |
| 14:33:36 | dansmith | I dunno about that | |
| 14:33:54 | sean-k-mooney | TheJulia: do they just not want to do the provisioning e.g. would boot without and image be an alternitive | |
| 14:35:43 | sean-k-mooney | TheJulia: actully ignoring the schduling bit is there a reason they cant just deploy using ironics api | |
| 14:37:12 | sean-k-mooney | presumable ironic could claim the resouces in placment when you go to ironic directly so that nova/placement would know the host is in use | |
| 14:50:09 | TheJulia | sean-k-mooney: trying to focus on the discussion call I'm on right now, I'll answer afterwards | |
| 14:51:05 | sean-k-mooney | TheJulia: no worries im watching an internal call too | |
| 15:18:17 | melwitt | gmann: have you seen this gate bug before? "ls: cannot access 'uwsgi*': No such file or directory" https://zuul.opendev.org/t/openstack/build/5c1bfbb79c314b11b518a8af51441a00/log/logs/grenade.sh.txt#5354 | |
| 15:18:59 | gmann | melwitt: yeah that is ongoing fixes in devstack, and we have merged all the stable branch fix now | |
| 15:20:19 | dansmith | since monday I think | |
| 15:20:19 | melwitt | gmann: ah thanks, I missed that | |
| 15:20:41 | melwitt | I had a thing on stable (stein) fail zuul overnight | |
| 15:21:10 | gmann | yeah, | |
| 15:21:14 | melwitt | so I was wonderin | |
| 15:21:34 | gmann | but grenade multinode job is still issue, fixing in ussuri by backporting running zuulv3 native - https://review.opendev.org/#/c/735948/1 | |
| 15:22:51 | gmann | train and stein might need to make it n-v till we backport the grenade zuulv3 till stein. that is we are discussing in qa channel | |
| 15:25:39 | melwitt | ok I'm seeing neutron-grenade-multinode and nova-grenade-live-migration and grenade-py3 failing on stein | |
| 15:28:50 | melwitt | and then nova-live-migration is failing with "/opt/stack/new/devstack/lib/infra: line 32: virtualenv: command not found" on stein https://zuul.opendev.org/t/openstack/build/509288c2a75a49609c2f7f4b2e158a60/log/logs/devstack-subnodes-early.txt#2948 | |
| 15:33:01 | gmann | melwitt: yeah, that need devstack-gate fix which is not preferred so i am trying to backport the grenade zuulv3 till train. | |
| 15:45:09 | melwitt | gmann: ok, thanks. devstack-gate is branchless I assume? | |
| 15:45:27 | gmann | melwitt: yeah. | |
| 15:49:25 | melwitt | gmann: thanks. have you heard of the other failure before "/opt/stack/new/devstack/lib/infra: line 32: virtualenv: command not found"? for nova-live-migration | |
| 15:54:02 | gibi | melwitt: could this be due to http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015425.html ? | |
| 15:55:13 | melwitt | gibi: oh maybe, thanks. I missed that, was looking for "gate" in ML | |
| 15:55:19 | gmann | melwitt: that is same issue grenade multinode job facing | |
| 15:55:29 | gmann | and need fix in devstack-gate | |
| 15:56:04 | melwitt | oh, the error message was different so I didn't realize it was related | |
| 16:11:09 | TheJulia | dansmith: the goal is more, have the nova-compute driver ask ironic to hold the node, set appropriate values to represent the user has possesion of it and allow the user to do the needful. | |
| 16:11:41 | TheJulia | sean-k-mooney: the conundrum is the users expect to use nova, and currently get resources via nova today, and what they are doing is basically going and making internal invasive chagnes inside the deployed instance to re-install the instance using a kickstart | |
| 16:11:58 | dansmith | TheJulia: yeah that's the same as what I said, just with nova-compute being slightly involved in the enablement of the out-of-band activities | |
| 16:12:26 | TheJulia | Well, it may be logical to enable setting the "leasee" field in ironic's api anyway | |
| 16:12:39 | TheJulia | which would allow operators to optionally grant direct api rights | |
| 16:13:05 | TheJulia | I guess there could always be a trait that populates itself that just signals "don't actually deploy this machine, just allocate it" | |
| 16:13:15 | dansmith | that's akin to nova setting up a libvirt VM and then tolerating the user or admin mucking with the underlying VM XML | |
| 16:13:18 | TheJulia | and we could do that under the hood in ironic fairly easily. | |
| 16:13:21 | dansmith | which today we declare as "not okay" | |
| 16:15:12 | TheJulia | Well, we should still eventually store who asked for the thing and if we have community consensus behind a "delayed deployment" trigger, then that is totally up to the operators and their running policy to decide if they want to permit or not to meet their use cases | |
| 16:17:23 | sean-k-mooney | dansmith: for what its worth we had someone asking about pxe booting nova instance a few weeks ago | |
| 16:18:01 | sean-k-mooney | they were confused by the fact that if you enable the qemu boot menu via the image porperty you can select pxeboot as an option in the boot menu via the console | |
| 16:18:24 | sean-k-mooney | but could not figure out how to configure it which makes sense since we dont support you pxe booting the vms booted by nova | |
| 16:18:27 | dansmith | sean-k-mooney: you mean asking again | |
| 16:19:04 | sean-k-mooney | it came up on irc like a month ago i assuem it has come up before | |
| 16:19:09 | dansmith | many times | |
| 16:19:44 | dansmith | I dunno if there would be any ironic parallels here, but changing the image from inside the guest means that anything we do after that based on the image metadata will be wrong | |
| 16:20:06 | sean-k-mooney | i basically just said thats not supported sorry, it just a leaky abstraction | |
| 16:20:18 | dansmith | like attaching a device and using the correct device model, or migrating somewhere that looks at image metadata for OS properties, etc | |
| 16:20:26 | sean-k-mooney | dansmith: well so i have heard of people upgradeing form like 16.04 to 18.04 | |
| 16:20:37 | sean-k-mooney | but then you get into the pets vs cattle debate | |