Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-06-02
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 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:42 stephenfin it's already there
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 gibi so for me it fits nova API better
12:17:30 sean-k-mooney we dont currently have a way to list nova instance by flavor extra spec do we?
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
12:29:26 gibi snapshot + delete
12:30:03 sean-k-mooney basically i was thinging you would pass a url to call back an a payload to send whne cratign the payload
12:30:08 sean-k-mooney *alloction
12:31:45 sean-k-mooney gibi: not sure if that is a good idea or not but for nova we would make the payload be an extrenal event payload allocation-exired-event possible with an acction or encode the action in a flavor extra spec or image property
12:32:16 sean-k-mooney i had not fully tought though the full semantics but ya that was the general thing i had in mind
12:33:15 gibi sean-k-mooney: yeah these sounds like a workable set of ideas
12:35:21 sean-k-mooney gibi: by the way i hope you dont mind i fast appoved the cyborg admin client spec i notice that you went and fixed the blueprint
12:36:50 sean-k-mooney given the time zone differece i did not think the nits justifed asking them to respin or submit a followup
12:38:07 gibi sean-k-mooney: no problema
12:38:28 gibi sean-k-mooney: I did not notice the missing bp until I tried to approve the bp after I saw the spec merged
12:40:29 opendevreview Stephen Finucane proposed openstack/os-vif stable/ussuri: [Stable Only] Drop lower constraints testing https://review.opendev.org/c/openstack/os-vif/+/794210
12:41:23 opendevreview Stephen Finucane proposed openstack/os-vif stable/train: [Stable Only] Drop lower constraints testing https://review.opendev.org/c/openstack/os-vif/+/794211
12:41:44 stephenfin gibi: lyarwood: Would appreciate eyes on those to unblock the other patches in os-vif ^
12:41:51 stephenfin that's what we agreed last week, iirc
12:41:55 stephenfin also, sean-k-mooney: ^
12:42:10 gibi on it
12:42:36 sean-k-mooney more or less although i didnt end put trying to fix it beyond victoria
12:44:22 gibi stephenfin: note that I have no +2 rights :)
12:44:34 stephenfin oh, lovely
12:45:01 stephenfin so I guess I need to poke elodilles ?
12:46:27 sean-k-mooney well actully i forgot to bring this up
12:46:40 sean-k-mooney anyone agaisnt me creating an os-vif-release team for stable
12:47:13 sean-k-mooney i would like to be able to do stable review there too
12:47:29 sean-k-mooney i can bring it up on the next nova meeting
12:47:52 sean-k-mooney i ment to do it last week and forgot this week
12:47:53 stephenfin I'd just add core to stable-core, personally. Probably something for the next meeting
12:48:40 gibi I'm not against it, we need agreemet from stable cores though :)
12:48:42 sean-k-mooney i could i wanted to add a new group to not need to add people to nova-stable-maint for os-vif stable
12:48:50 lyarwood yup I'm not against that
12:50:08 sean-k-mooney gibi: im +2 on the reparenting spec too but i did not give +w to allow melwitt and other to review
12:50:45 gibi sean-k-mooney: ack, thanks
12:56:57 sean-k-mooney stephenfin: should you have not cherry picked the stable train patch form stable ussuri
12:57:48 stephenfin no point. It was just merge conflict hell and they're stable only
12:58:40 sean-k-mooney well normally stable only patches would be cherry picked
12:58:47 sean-k-mooney but ok
12:59:08 sean-k-mooney if its generally effectivly a rewrite then ill change the -1 to +1
13:29:23 opendevreview Lee Yarwood proposed openstack/nova master: libvirt: Do not destroy volume secrets during _hard_reboot https://review.opendev.org/c/openstack/nova/+/793463
13:45:15 sean-k-mooney oh ok
13:46:20 sean-k-mooney i guess its ok to not destroy the secreat for had reboot
13:46:24 sean-k-mooney *hard
13:46:41 sean-k-mooney soft reboot calls hard reboot also by the way if it does not soft reboot after a time out
14:47:27 mdbooth sean-k-mooney: Incidentally, I've always felt that was a misfeature. Soft and hard reboots are quite different things. If the user asks for a soft reboot and it doesn't work, they should get an error (asynchronously, obvs).

Earlier   Later