Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-10-10
08:52:01 opendevreview ribaudr proposed openstack/nova master: Add helper methods to attach/detach shares https://review.opendev.org/c/openstack/nova/+/885753
08:52:01 opendevreview ribaudr proposed openstack/nova master: Add instance.share_attach notification https://review.opendev.org/c/openstack/nova/+/850501
08:52:03 opendevreview ribaudr proposed openstack/nova master: Add instance.share_detach notification https://review.opendev.org/c/openstack/nova/+/851028
08:52:03 opendevreview ribaudr proposed openstack/nova master: Add shares to InstancePayload https://review.opendev.org/c/openstack/nova/+/851029
08:52:05 opendevreview ribaudr proposed openstack/nova master: Add instance.share_attach_error notification https://review.opendev.org/c/openstack/nova/+/860282
08:52:05 opendevreview ribaudr proposed openstack/nova master: Add instance.share_detach_error notification https://review.opendev.org/c/openstack/nova/+/860283
08:52:07 opendevreview ribaudr proposed openstack/nova master: Reports instance events to the DB regarding attaching and detaching a share https://review.opendev.org/c/openstack/nova/+/927088
08:52:07 opendevreview ribaudr proposed openstack/nova master: Add libvirt test to ensure metadata are working. https://review.opendev.org/c/openstack/nova/+/852086
08:52:09 opendevreview ribaudr proposed openstack/nova master: Add virt/libvirt error test cases https://review.opendev.org/c/openstack/nova/+/852087
08:52:09 opendevreview ribaudr proposed openstack/nova master: Manila shares admin guide documentation https://review.opendev.org/c/openstack/nova/+/871642
11:41:41 opendevreview Takashi Natsume proposed openstack/python-novaclient master: Replace neutronclient with openstacksdk https://review.opendev.org/c/openstack/python-novaclient/+/932057
11:46:41 opendevreview Takashi Natsume proposed openstack/python-novaclient master: Replace neutronclient with openstacksdk https://review.opendev.org/c/openstack/python-novaclient/+/932057
12:38:30 opendevreview sean mooney proposed openstack/nova stable/2024.1: repoduce post liberty pre vicoria instance numa db issue https://review.opendev.org/c/openstack/nova/+/932064
12:38:58 opendevreview sean mooney proposed openstack/nova stable/2024.1: allow upgrade of pre-victoria InstanceNUMACells https://review.opendev.org/c/openstack/nova/+/932065
12:41:50 sean-k-mooney1 elodilles: ^ you have some downstream victoria clouds right. that would technially be useful for them but im hoping you dont have downstream pre victoria clouds that have nto upgraded to at least victoira so it might now be relevent anymore
12:43:11 sean-k-mooney given how old that bug is and that it does not afffect any isntance after victoria im not very motivated to backport this upstream but just wanted to highlight it to you in case it was useful to you
12:44:38 sean-k-mooney tkajinam: i think you are the 4th person to start replacing neutron clinet with the sdk if you have that working your amazing if you dont i guess that makes you human but still pretty awsome
12:45:01 sean-k-mooney oh your patches are for nova-client not nova
12:45:24 sean-k-mooney still nice to see although im hoping we can remove nova-client in the next 1-2 years entirly
12:46:04 tkajinam I'm not really touching "kill clients" so far but I know it may give me a lot of thing to do in heat :-P
12:46:07 sean-k-mooney it would be nice to start the converstaion "can we formally deprecate the python binding in 2025.1, for removal in 2026.1"
12:46:38 sean-k-mooney tkajinam: i know neutorn want to kill there client in the next 1-2 slurps and i think we should try to do the same
12:46:55 sean-k-mooney but ya it wont happen for a while
12:47:26 tkajinam I understand that point but honestly I'm not too sure about its feasibility
12:47:47 tkajinam for the past 1 year I'm almost the only person taking care of all heat repos.
12:47:57 sean-k-mooney well the only reaosn we didnt freeze the python bidnign before last cycle was osc
12:48:17 sean-k-mooney that is no longer a usecase as osc is now using the sdk
12:48:30 tkajinam ok
12:48:53 sean-k-mooney so i dont realy expect use to continue to extend the python binding in nova-clinet anymore for new api. just the sdk
12:48:58 tkajinam I'm ok to freeze the client code now. I may need some more time before it is actually retired.
12:49:10 tkajinam following what was done for neutronclient in the past
12:52:23 elodilles sean-k-mooney: ACK, thanks, i'll review and see if i can backport :) maybe it can help others :]
12:54:10 tkajinam as we expect some big changes needed for eventlet removal and py313 support I'm hoping that we don't add yet another big topic for a few cycles
12:54:34 tkajinam that's my own hope but people may want more short timeline for different things.
12:56:57 sean-k-mooney well the move to sdk started before the eventlet topic
12:57:06 sean-k-mooney but ya we will see how things pan out.
12:57:29 sean-k-mooney i know we are all pretty streched so we dont want to break things just for the sake of it
12:57:57 sean-k-mooney what i would hope however is that heat for example could elelct to only use the sdk for new apis to not accure new tech debt
12:58:17 sean-k-mooney even if it does not start the removal of the old client code in the near term
13:02:11 sean-k-mooney elodilles: alot of our downstream customer are startign to jump form train to wallaby so that bug is now finally manafesting. out side of enterpise distrobutions i would not expect many clouds to really be running pre victoira code today
13:03:42 elodilles well, we always see really old versions when community asks around about used versions in deployments, so who knows
13:03:54 sean-k-mooney because of hardware age reasons many of our custoemr using wallaby before did fresh installs on new hardware instead of upgrading so this only came up now after 4 years.
13:04:54 sean-k-mooney ya i mean it happens, compaines deploy a cloud, it works well enough for there needed and dont upgrade it because of small teams and then they realsie they are massivly out of date with no clear way to catch up
13:05:03 elodilles that's true, though, probably new install is easier for many operators
22:55:26 opendevreview melanie witt proposed openstack/os-traits master: DNM trait https://review.opendev.org/c/openstack/os-traits/+/932152
23:02:18 opendevreview melanie witt proposed openstack/nova master: api: Add microversion 2.97 to add image_type to block_device_mapping_v2 https://review.opendev.org/c/openstack/nova/+/930968
23:02:19 opendevreview melanie witt proposed openstack/nova master: WIP trait, filter, request spec https://review.opendev.org/c/openstack/nova/+/932153
#openstack-nova - 2024-10-11
00:20:27 opendevreview melanie witt proposed openstack/nova master: WIP trait, filter, request spec https://review.opendev.org/c/openstack/nova/+/932153
04:51:20 opendevreview OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.opendev.org/c/openstack/nova/+/929719
12:03:41 sean-k-mooney melwitt: have you tought about a new api to deiscover which iamge backend are supproted on a give cloud, also i woudl expect to want to be able to also set ad default image backed in the falvor or image
12:04:47 sean-k-mooney doing it via the bdms is fine for advanced users but im not sure how good the ux is in general
12:07:14 sean-k-mooney i have a few other tought on "nice to have" capablity that could be part of this work like adding "on_shared_storage=True/false" to server show or maping strage backends to placment aggreates to ensure we can schdule to the same storage pool when an isntnace is on shared storage
12:07:59 sean-k-mooney im not sure if you have tought about any of those elements in https://review.opendev.org/q/topic:%22nova-imagebackend-poc%22
13:57:00 dansmith sean-k-mooney: yeah I don't love using BDMs for that either, but it's probably the vehicle we need for being able to express that we want to be root-on-shared and ephemeral-on-local
13:57:16 dansmith I think probably the reason I don't like it is because I don't like BDMs in the first place
13:57:32 dansmith they're just obscure and opaque and I have to look up how to use them every time I need to
13:57:46 sean-k-mooney well having this in the bdm makes sense. havign that as the only wya ot express it is another matter
13:58:27 sean-k-mooney i was more or less thinking of having the ablity to default it via the flavor or image and if you want diffent backends per disk then overried with bdm
13:58:59 sean-k-mooney i.e. hw:root_image_backed=rbd hw:ephmeral_image_backend=lvm
13:59:10 sean-k-mooney and if you need something more complex only then go to bdm
13:59:18 dansmith yeah I read what you said.. and maybe, but the user really shouldn't even know that lvm or rbd are in use
13:59:56 sean-k-mooney well it may be approaty if we have an api for listing the types.
14:00:04 sean-k-mooney but without that i agree
14:00:35 sean-k-mooney we could also have an abstration i.e. hw:root_image_backed=local|shared_storage
14:00:44 sean-k-mooney that would be more cloudy
14:00:59 sean-k-mooney and offten that asll you care about
14:01:20 dansmith yeah, I think enumerated types (like volume types) is the thing we need.. shared/local isn't enough, IMHO
14:01:55 dansmith because if someone wants local cheap slow file-on-disk, faster lvm, shared rbd, shared iscsi box, etc
14:46:20 jlejeune hello, do you know where can I find the mysql/mariadb compatible versions depending on the openstack releases ? is there a compatibility matrix somewhere ?
14:50:14 jlejeune because I have issue when I want to upgrade from bobcat to caracal, when 'nova-manage db sync' tries to create nova_cell0.share_mapping table on mariadb 11.5.2
15:30:05 jlejeune it seems to be related to the charset
15:38:10 jlejeune the utf-8 charset has been removed on mariadb > 10.6
15:40:07 sean-k-mooney dansmith: ya i like the idea of having storage_classes as an opace api constrcut defiend by the admin that a user then just selct form like volume types
15:40:53 sean-k-mooney jlejeune: for better or worse nova does not define the charater type to use in our schema
15:41:14 sean-k-mooney but yes there were chagnes to the charset and utf-8 specifically there is a replacement you can use
15:41:36 sean-k-mooney i think its utf8mb4
15:42:00 jlejeune indeed it's utf8mb3
15:42:37 sean-k-mooney utf8mb4 is the replacement
15:42:39 jlejeune but the charset utf8 is hardcoded in migrations scripts
15:43:23 sean-k-mooney i dont think its is in nova
15:43:29 sean-k-mooney but it may be in your installer
15:44:50 sean-k-mooney oh https://github.com/openstack/nova/blob/master/nova/db/main/migrations/versions/8f2f1571d55b_initial_version.py#L274-L275
15:44:58 sean-k-mooney that a bug
15:45:11 jlejeune hé hé
15:45:53 sean-k-mooney that should be utf8mb4
15:45:57 jlejeune :)
15:46:04 amorin there are some latin1 as well
15:46:05 sean-k-mooney i guess depending on your release there may be an alias for that
15:46:52 sean-k-mooney yes so we had a discussion about if nova can move to perscifbeing a charset to use a long time ago and i tought we agrreed no
15:47:07 sean-k-mooney this was incontext to maigin to a case sensitive coalation type
15:47:39 sean-k-mooney which is a slictly diffent topic
15:47:56 sean-k-mooney looking at https://dev.mysql.com/doc/refman/5.7/en/charset-charsets.html and 9.0
15:48:15 sean-k-mooney utf8mb4 shoudl be viable for a wide range of release
15:48:41 sean-k-mooney utf8 exists in 5.7 but not in 8.0+
15:48:45 sean-k-mooney im not sure when it was removed
15:49:16 sean-k-mooney jlejeune: can you file a but for this.
15:49:59 jlejeune I can for sure, but it will wait for monday :)
15:50:03 jlejeune I have to go
15:50:07 sean-k-mooney no worries
15:50:19 jlejeune see you

Earlier   Later