| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-03 | |||
| 22:19:03 | sean-k-mooney | shelving is intented to be the way for tenant to consume less resouces when a vm is not activly needed | |
| 22:19:53 | sean-k-mooney | in a public cloud when an instnace is shelved you are normally only changed for the disk usage in glance and not the cpu/ram/devices consumed by the flavor | |
| 22:20:25 | sean-k-mooney | since shut down vms still consume the cpu/ram/disk from a billing/usage point of view its more or less the same as if its running | |
| 22:40:13 | CeeMac | Thanks sean-k-mooney, I've just found a list of states in the api-ref parameters file. Just need to work out where the logic is queried so I can validate which of the states are 'counted', but in the interim I'll look into shelving options and document that up for our users. | |
| 22:42:34 | CeeMac | I guess while the instance is 'there' its effectively holding a reservation against the CPU and ram resources? Hence its metered for prospective billing/accounting purposes. | |
| 22:48:58 | melwitt | CeeMac: afaict, the state is not considered, it's only the launched_at/terminated_at https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/simple_tenant_usage.py#L51 so shelving would be the way to stop/resume usage | |
| 22:52:35 | melwitt | and you are correct, while the instance exists it is holding a reservation against resources. even when it's shut down | |
| 22:53:21 | melwitt | the shelve API was added to provide an easier way to remove/restore an instance from holding resources | |
| 22:53:38 | CeeMac | Thanks melwitt that seems to confirm it. OK, shelving it is then! | |
| 22:54:20 | CeeMac | I like to try and understand the logic behind things when/where I can :) | |
| 22:55:34 | melwitt | +1 :) | |
| 23:00:31 | CeeMac | Oh, I remember reading about this a while back actually. Do you happen to recall the setting for how long an instance can remain shelved before it gets offloaded / deleted and what the default is? | |
| 23:01:30 | melwitt | https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.shelved_offload_time | |
| 23:02:16 | melwitt | default is 0 for immediate offload | |
| 23:02:48 | josephillips | melwitt: taking the oportunity about shelved offload | |
| 23:03:04 | josephillips | is posible configure if a image is shelved move the storage backend too? | |
| 23:06:08 | melwitt | not completely sure I understand the question but if you shelved a volume backed instance it will snapshot the volume as well | |
| 23:06:23 | josephillips | yes | |
| 23:06:29 | josephillips | but will keep on the same backend | |
| 23:06:37 | josephillips | example if i shelved a image | |
| 23:06:41 | josephillips | a vm sorry | |
| 23:06:54 | josephillips | is a waste of resource keep on SSD | |
| 23:07:01 | josephillips | i prefer move the volumes to a HDD backend | |
| 23:07:06 | josephillips | this is posible? | |
| 23:08:18 | melwitt | oh, I see. I'm afraid I don't know if there's a way to do that | |
| 23:09:01 | CeeMac | So once the instance is offloaded there is another timer before it is completely deleted? Or it will stay shelved indefinitely? | |
| 23:09:37 | CeeMac | I seem to recall seeing a reference to that but can't find it now | |
| 23:09:50 | melwitt | josephillips: I'm thinking I wonder if you could do like a volume migrate via the cinder API to accomplish that, after it's been shelved | |
| 23:10:10 | josephillips | yeah is possible doing via cinder manually | |
| 23:10:23 | josephillips | the idea is doing automatically | |
| 23:10:42 | josephillips | via horizon | |
| 23:11:46 | melwitt | oh, ok, yeah sorry. it would "seem" that could be a relatively easy thing to add to osc/horizon as kind of a batch operation | |
| 23:11:58 | josephillips | yep | |
| 23:12:56 | melwitt | CeeMac: I think it stays shelved indefinitely | |
| 23:14:55 | CeeMac | Great, thanks. I'll experiment some tomorrow. Sleep now :) | |
| 23:15:10 | CeeMac | Thanks again for the help/info | |
| 23:15:50 | melwitt | np, gnight o/ | |
| #openstack-nova - 2020-06-04 | |||
| 08:41:43 | bauzas | good morning Nova | |
| 08:47:32 | gibi | bauzas: good morning | |
| 09:04:04 | xiaolin | hello guys, I'm trying to run openstack on a host with MIPS architecture, but got an error "Instance failed to spawn: libvirtError: internal error: unexpected host-model CPU for mips64el architecture" while creating an instance. | |
| 09:04:18 | xiaolin | Anyone can guide me how I can contribute a fix to upstream? need I report a bug first? | |
| 09:18:05 | openstack | Launchpad bug 1863728 in OpenStack Compute (nova) "Nova can't create instances for a different arch" [Wishlist,Invalid] | |
| 09:18:05 | gibi | xiaolin: does this similar to what belmoreira requested here? https://bugs.launchpad.net/nova/+bug/1863728 | |
| 09:19:50 | gibi | xiaolin: we will discuss ^^ today during the PTG https://etherpad.opendev.org/p/nova-victoria-ptg | |
| 09:27:50 | xiaolin | gibi: The problem I encountered is not similar to what belmoreira requested | |
| 09:28:51 | alex_xu | gibi: sean-k-mooney does neutron already report physical network interface resource provider? accroding to the spec https://specs.openstack.org/openstack/neutron-specs/specs/rocky/minimum-bandwidth-allocation-placement-api.html | |
| 09:28:51 | xiaolin | gibi: the host and instance are both MIPS architecture | |
| 09:30:40 | gibi | xiaolin: I see. Then I don't have a direct answer. the libvirt error suggest that something is missing from the libvirt side. Are you able to start a VM purely with libvirt / virsh on your host? | |
| 09:30:49 | belmoreira | gibi xiaolin unfortunately I won't be able to join | |
| 09:31:17 | gibi | belmoreira: thanks for the headsup, we will discuss it anyhow | |
| 09:31:46 | gibi | alex_xu: neutron reports SRIOV PF and OVS bridge as RP in placement with physnet and vnic type trait | |
| 09:31:58 | alex_xu | gibi: got it | |
| 09:32:05 | gibi | alex_xu: but only if bandwidth is defined in the agent conf for these devices | |
| 09:32:22 | alex_xu | gibi: just read the cyborg sriov doc, begin to think about..cyborg will report any RP for PF... | |
| 09:32:46 | alex_xu | s/report any/report another/ | |
| 09:32:56 | xiaolin | gibi: Yes, I can start a VM purely with libvirt / virsh on my host | |
| 09:33:36 | gibi | alex_xu: I guess we have to decide if neutron or cyborg owns the PF | |
| 09:33:40 | alex_xu | gibi: ok, if they are totally two feature, should be ok. Since those cyborg PF's RP should be managed by cyborg...not sure how cyborg and neutron merge them... | |
| 09:33:53 | alex_xu | gibi: yea, that is something to decide | |
| 09:36:06 | gibi | xiaolin: please look at the host-model documentation https://docs.openstack.org/nova/latest/admin/configuration/hypervisor-kvm.html#specify-the-cpu-model-of-kvm-guests you might need to configure the nova a bit differently for using your hardware. | |
| 09:37:11 | gibi | xiaolin: also I hope kashyap could help from libvirt perspective | |
| 09:41:52 | xiaolin | gibi: Thank you. I will read the documentation | |
| 10:12:21 | kashyap | xiaolin: Oh, MIPS ... you are the first I've come across here :) | |
| 10:12:59 | kashyap | gibi: xiaolin: So the error "unexpected host-model" simply means, MIPS in libvirt doesn't have the notion of 'host-model' | |
| 10:13:07 | kashyap | So, let me check what's possible there... | |
| 10:15:41 | kashyap | xiaolin: What you could try is: launch your `qemu-system-mips -cpu help` (or whatever the MIPS QEMU binary is called) | |
| 10:15:53 | kashyap | xiaolin: On the Compute host, and configure that as an explicit CPU model in Nova: | |
| 10:16:09 | gibi | kashyap: thanks for the help :) | |
| 10:16:55 | kashyap | cpu_mode = custom | |
| 10:16:55 | kashyap | [libvirt] | |
| 10:16:56 | kashyap | cpu_model = $My_MIPS_CPU_FIXME | |
| 10:17:00 | kashyap | gibi: Happy to be useful :) | |
| 10:32:49 | sean-k-mooney | alex_xu: they way the cyborg driver work there is no filtering so yes it would report any PF that the driver could manage | |
| 10:33:19 | sean-k-mooney | gibi: today nova owns the pf not neutron | |
| 10:33:35 | sean-k-mooney | neutron only owns the bandwidth | |
| 10:34:11 | sean-k-mooney | when we start reporting pci device to placement form nova we will be the ones creating the inventories for the VFs | |
| 10:43:30 | gibi | sean-k-mooney: today neutron creates the PF RPs and reports bandiwdth inventory on it, when we start reporting VF inventory from nova we need to agree with neutron who creates the PF RP or we have to create two RPs for a PF one from neutron perspective and one from nova perspective and then connect them somehow | |
| 10:44:23 | sean-k-mooney | gibi: nova need to do it because it needs to be consitient with non nic pci devices | |
| 10:44:42 | sean-k-mooney | unless we are going to specal case when the device has a physnet tag on the pci whitelist | |
| 10:44:57 | sean-k-mooney | which we coudl do but then we need two different code paths | |
| 10:45:20 | sean-k-mooney | gibi: ideally it would end up being one RP | |
| 10:45:49 | sean-k-mooney | unless we extend placemets data model with a way to link rps | |
| 10:54:04 | sean-k-mooney | gibi: quick question do you want a blueprint or a spec to track the machine type recodeing work? | |
| 10:54:56 | sean-k-mooney | as part of that i would like to start reporing avialble machine types as traits to placemnt and the schdlueling on that | |
| 10:55:49 | sean-k-mooney | e.g. if we do a move opperation on an exsting instance i want to ensure we land it on a host that supports that machine type | |
| 10:56:16 | sean-k-mooney | and if we are creating a new instance and you request a machine type in the image i want to ensure we land on a host that supports that too | |
| 10:56:29 | sean-k-mooney | both of which would be done by a prefilter | |
| 10:57:04 | sean-k-mooney | just addign the required tratit based on the instance system metadata or image metdata | |
| 11:00:12 | gibi | sean-k-mooney: sorry I was lunching. | |
| 11:00:19 | sean-k-mooney | no worries | |
| 11:01:02 | gibi | sean-k-mooney: agree that it would be nice to have on RP for one physical entity (like a PF or other PCI device) | |
| 11:01:29 | gibi | sean-k-mooney: I just wanted to note that this might requires changes both from nova and neutron | |
| 11:01:56 | gibi | btw placement has two ways today to link RPs, one is the parent-child relationship and the other is aggregates | |
| 11:02:44 | sean-k-mooney | yep altought i was thinking more of something like a symlink | |
| 11:03:00 | gibi | sean-k-mooney: I guess you don't need db schema rpc or REST API changes for the machine type recording work so I think a bp is enough | |
| 11:03:15 | sean-k-mooney | aggreate wont work because we can do member of in this case | |
| 11:03:39 | gibi | sean-k-mooney: yeah aggregates would be a bit ugly I agree | |
| 11:03:45 | sean-k-mooney | and parent-child likely wont work because we neither nova or neutron knows the uuid/name that will be used for the RP | |
| 11:04:05 | sean-k-mooney | that said we can work this out when we need too | |
| 11:05:56 | sean-k-mooney | gibi: are you ok with also doing the traits reporting and prefileter in the same specless blueprint. | |