| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-02 | |||
| 11:13:41 | stephenfin | sean-k-mooney: the data volume would have a boot_index of -1, no? | |
| 11:13:50 | stephenfin | since it's a data volume, not a boot volume | |
| 11:14:09 | lyarwood | haha I don't think it does | |
| 11:14:09 | sean-k-mooney | well it typically would not be set as bootable in cinder at all | |
| 11:14:26 | stephenfin | so would you just not set it? | |
| 11:14:39 | sean-k-mooney | i dont know | |
| 11:14:40 | stephenfin | so instead of: | |
| 11:14:41 | stephenfin | if image is not specified, the first volume specified gets boot_index of 0 and the rest get -1; if it *is* specified, all volumes get boot_index of -1 | |
| 11:14:45 | stephenfin | I should say: | |
| 11:14:48 | sean-k-mooney | i assumed -1 means last possibel | |
| 11:14:57 | sean-k-mooney | or not bootable | |
| 11:14:58 | lyarwood | `To disable a device from booting, set the boot index to a negative value or use the default boot index value, which is None.` | |
| 11:15:06 | lyarwood | I've always just left it as None | |
| 11:15:10 | stephenfin | if image is not specified, the first volume specified gets boot_index of 0 and the rest get nothing; if it *is* specified, no volume gets a boot_index | |
| 11:15:25 | sean-k-mooney | yes | |
| 11:15:30 | sean-k-mooney | that would work | |
| 11:15:50 | lyarwood | yup | |
| 11:15:52 | stephenfin | so 'server create --image IMAGE --volume VOLUME ...' -> boot from image with an attached data volume (2 block devices) | |
| 11:15:59 | sean-k-mooney | yes | |
| 11:16:01 | stephenfin | so 'server create --volume VOLUME ...' -> boot from volume (1 block devices) | |
| 11:16:06 | stephenfin | s/so/and/ | |
| 11:16:23 | sean-k-mooney | yep | |
| 11:16:24 | lyarwood | stephenfin: does the first one use BDMs for both block devices or just the volume? | |
| 11:16:24 | stephenfin | okay, cool. That's what I was thinking all along but clearly didn't word it well. That should be easily doable | |
| 11:16:41 | lyarwood | stephenfin: and provide the image via imageRef | |
| 11:16:50 | stephenfin | probably just the volume with a separate imageRed | |
| 11:16:51 | stephenfin | *f | |
| 11:16:55 | lyarwood | cool | |
| 11:17:01 | stephenfin | seeing as it's easier | |
| 11:17:05 | stephenfin | presumably | |
| 11:17:08 | lyarwood | I was going to say if it did bdms for both we could nuke that | |
| 11:17:16 | sean-k-mooney | lyarwood: is there an advantate to use the bdm and setting the image one to local | |
| 11:17:21 | lyarwood | as yeah it's easier to use imageRef | |
| 11:17:54 | lyarwood | sean-k-mooney: no IMHO, given how weird osc already is about this stuff I was just checking it wasn't using them | |
| 11:18:05 | sean-k-mooney | ack | |
| 11:18:59 | stephenfin | sean-k-mooney: as for your concerns RE: --image-property: I share them https://github.com/openstack/python-openstackclient/blob/master/openstackclient/compute/v2/server.py#L812-L814 | |
| 11:19:02 | stephenfin | it's on the chopping block | |
| 11:19:12 | stephenfin | or will be soon | |
| 11:19:58 | sean-k-mooney | well my concern was actully that we approved overriding image properties on the command line in the pass at the spec stage | |
| 11:20:04 | sean-k-mooney | but it never got implemented | |
| 11:20:22 | sean-k-mooney | so that really should not exist because if we ever revived that it would be a problem | |
| 11:20:24 | stephenfin | you really do need to play around with this stuff to realize the ugliness of some of the interactions | |
| 11:20:34 | stephenfin | lots of good stuff there but so many rough edges too | |
| 11:20:41 | stephenfin | sean-k-mooney: agreed | |
| 11:20:56 | sean-k-mooney | are you going to add --ephemeral | |
| 11:21:42 | stephenfin | it's already there | |
| 11:21:42 | sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/virt-image-props-boot-override.html just in case people were not aware of this | |
| 11:21:51 | stephenfin | I added it last cycle | |
| 11:22:12 | stephenfin | OSC is effectively feature complete from a nova perspective now, IMO. The only thing I haven't done is the host evacuate commands | |
| 11:22:13 | sean-k-mooney | oh not in in the version i have installed locally then | |
| 11:22:37 | stephenfin | you need 5.5.0 | |
| 11:22:52 | stephenfin | which should have been 6.0.0, since we removed stuff /o\ | |
| 11:23:06 | sean-k-mooney | i just installed the latest release | |
| 11:23:07 | stephenfin | that ship has sailed though | |
| 11:23:23 | sean-k-mooney | i had 5.4.0 | |
| 11:23:53 | sean-k-mooney | stephenfin: you could revert that and do a 5.5.1 | |
| 11:24:17 | stephenfin | good point | |
| 11:24:23 | stephenfin | I'll discuss in the SDK team meeting tomorrow | |
| 11:26:14 | sean-k-mooney | stephenfin: looking at my old history it looks like i have been doing it in 3 commands volume create, boot and attach | |
| 11:26:31 | sean-k-mooney | when i dont do it one go in horizon | |
| 11:27:27 | sean-k-mooney | oh by the way my cloud should be back runnign for people to use again later this week | |
| 11:28:14 | sean-k-mooney | it technicall is already deployed now with ceph but i have not tweek it form the default or configure the flaovr/networkign yet | |
| 11:36:57 | opendevreview | Merged openstack/nova-specs master: Add no user token when get Cyborg client https://review.opendev.org/c/openstack/nova-specs/+/787178 | |
| 12:00:03 | gibi | sean-k-mooney: I think the current consumer type impl only suggest a basic usage summary per type https://review.opendev.org/c/openstack/placement/+/679441/18/placement/tests/functional/gabbits/consumer-types-1.37.yaml#130 | |
| 12:01:14 | gibi | sean-k-mooney: and of course consumer type is now visible in the allocation | |
| 12:01:39 | gibi | sean-k-mooney: so right now the client would need to list all the allocation then filter it on the client side by the consumer type / host / project | |
| 12:01:55 | gibi | sean-k-mooney: I don't think it is hard to add those filters to the placement API if one needs it | |
| 12:04:29 | nightmare_unreal | is there a way to find kernel version of hyperviser through openstack command ? | |
| 12:07:02 | gibi | nightmare_unreal: I don't think so | |
| 12:12:22 | sean-k-mooney | gibi: ya i dont think it would be hard to do either | |
| 12:13:51 | sean-k-mooney | gibi: what do you think about the idea of a premtiable consumer type with a prefilter that just looks for and extra spec and changes it | |
| 12:14:18 | sean-k-mooney | again im not planning to work on that this cycle but eventually i think it would be a nice feature to support | |
| 12:14:59 | sean-k-mooney | im partly using this as a tought experiment to reason about addtional usecase fo consumer types | |
| 12:16:57 | gibi | sean-k-mooney: I see that the external service needs to determine which instance can be preempted. I don't get why this needs to be a placement query. It can be a nova query as well. | |
| 12:17:18 | gibi | the external service want to find servers to delete | |
| 12:17:23 | gibi | nova api deals with servers | |
| 12:17:30 | sean-k-mooney | we dont currently have a way to list nova instance by flavor extra spec do we? | |
| 12:17:30 | gibi | so for me it fits nova API better | |
| 12:17:39 | sean-k-mooney | or by server property | |
| 12:17:43 | gibi | sean-k-mooney: I don't think so, that query also needed | |
| 12:19:08 | sean-k-mooney | i mean john and co proved you can do it already with the poc they did so ya you can do it vai nova | |
| 12:20:22 | gibi | if the external service try to preempt any kind of allocation not just servers then I would vote for extending the placement api | |
| 12:21:53 | sean-k-mooney | ya i remember talking to jay an cdent about possible evoltuion of placment to supprot timed allcoation for blazar reservations at one point | |
| 12:22:18 | sean-k-mooney | the concensous at the time was blazar shoudl manage the timing itself at least for now | |
| 12:22:52 | sean-k-mooney | but i have wondered if we ever woudl want to have differnt type fo allcoation in the futrue that had semantic meanign to placemnt | |
| 12:23:19 | sean-k-mooney | consumer types while not an alocation type would provide a way to do that without placment knowing about it | |
| 12:23:24 | gibi | sean-k-mooney: is timed allocation ~= reservation? | |
| 12:23:33 | sean-k-mooney | gibi: yes | |
| 12:23:49 | gibi | yeah that would be an interesting thought experiment | |
| 12:24:13 | gibi | I don't know how alive blazar is these days | |
| 12:24:44 | sean-k-mooney | for now i think im going to leave it there and instead look at your reparenting spec then i need to get back to the smartnic one | |
| 12:26:35 | gibi | there are soo many interesting things to work on :) | |
| 12:26:44 | gibi | thanks for looking at re-parenting | |
| 12:27:07 | sean-k-mooney | gibi: for timed allocation to work i think you would need some kind of web hook callback in placment that could call our external events api to tell us it expired but ye i should focus on thing that people are actully working on for a bit | |
| 12:28:24 | gibi | sean-k-mooney: that would be a bit similar to the external event that neutron sends us when a bound port is deleted. nova then unplugs the vif | |
| 12:28:44 | sean-k-mooney | yep that was exactly what i was thinking of | |
| 12:28:45 | gibi | sean-k-mooney: so basically placement would tell us that the allocation is expired and nova would ~delete~ the instaance | |
| 12:28:57 | sean-k-mooney | yep | |
| 12:29:09 | sean-k-mooney | or tell balzar if that is the endpoint you regestred | |
| 12:29:13 | gibi | the delete would be a bit harsh but maybe shelve offload or snapshot would be ok | |