Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-04-30
16:33:09 bauzas thanks gibi
16:33:17 gibi no problemo
16:33:18 bauzas #action gibi to run next nova meeting
16:33:24 bauzas gibi: shoot your own point
16:33:31 gibi just a heads up
16:34:15 gibi we started a small standup with Uggla_ about his manial series 30 mins twice a week. So far it is Uggla_ and me but eventually we need a second code for the series
16:34:26 bauzas count me on it
16:34:27 gibi and such core could benefit joining to these meetings
16:34:49 gibi bauzas: thanks, I will make sure you will have the invite
16:34:50 bauzas I already reviewed the series so I'd be happy to continue to shepherd it
16:35:10 bauzas gibi: cool, timezones will then match hopefully :)
16:35:16 bauzas (it was a joke)
16:35:20 gibi it will :)
16:35:28 gibi that is all
16:35:31 bauzas cool
16:35:36 bauzas and then that's all for me too
16:35:40 bauzas thanks all
16:35:42 opendevreview Takashi Kajinami proposed openstack/python-novaclient master: Remove old excludes https://review.opendev.org/c/openstack/python-novaclient/+/917685
16:35:44 bauzas was a productive meeting
16:35:48 bauzas see you :)
16:35:52 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-04-30-16.00.log.html
16:35:52 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-04-30-16.00.txt
16:35:52 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-04-30-16.00.html
16:35:52 opendevmeet Meeting ended Tue Apr 30 16:35:52 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:35:52 bauzas #endmeeting
16:35:54 Uggla_ bauzas, I will send you the invites
16:36:00 bauzas np
16:36:17 elodilles thanks o/
16:36:38 tkajinam thank you :-D
16:36:39 sean-k-mooney just a note f you want ot send a message to the list to invite other to join if they want to dont send the ical
16:36:59 sean-k-mooney if you send the ical to the list is will effectivly invite the list :)
16:37:27 gibi I think this will not go to the list :)
16:37:39 gibi we want t keep it focused
16:37:43 opendevreview Takashi Kajinami proposed openstack/os-resource-classes master: Remove old excludes https://review.opendev.org/c/openstack/os-resource-classes/+/917614
16:37:44 fwiesel thanks
16:37:58 sean-k-mooney which is fine. i likely wont join those meeting but if you want me to attend as a one off for a specific patch or topic ping
16:39:20 gibi sure, thanks
16:40:40 gibi btw if we already discussing this series I'm wondering if we are OK to have a sqlite specific db migration codepath https://review.opendev.org/c/openstack/nova/+/912518/1/nova/db/main/migrations/versions/d60bddf7a903_add_constraint_instance_share_avoid_.py
16:40:56 dansmith wow, really?
16:41:05 gibi our migraton testing fail without it
16:41:32 gibi so we either skip testing this migration or have an sqlite specific path
16:41:33 dansmith and it's a table drop/recreate? that seems incredibly unfortunate to me
16:41:42 gibi it is for sqlite
16:42:03 dansmith what is the actual problem?
16:42:21 sean-k-mooney we should not need that
16:42:21 gibi sqlite does not support altering constarint on a table without recreate
16:42:31 sean-k-mooney although i know ironic does some sqlite specific tweaks
16:42:50 dansmith the create_table includes mysql-specific stuff too
16:42:51 sean-k-mooney gibi: as in adding a foringkey
16:43:45 dansmith is this because we merged the migration before the implementation and then decided that we needed something different?
16:43:47 sean-k-mooney so this is the share mapping table
16:43:51 sean-k-mooney which does not exist right
16:44:03 sean-k-mooney so why do we need this drop table and recreate
16:44:10 sean-k-mooney did that merge last cycle?
16:44:16 gibi dansmith: we needed an exta constraint to prevent creating two sharemapping with the same share id and instance id
16:44:28 gibi sean-k-mooney: we merged the db code
16:44:37 dansmith ugh, that's very unfortunate
16:44:41 sean-k-mooney ... ok this partly why i didint want to do that
16:44:46 dansmith yeah seriously
16:45:13 dansmith but, if it's not used currently, can we just drop and recreate it for all backends? should be very non-impactful for an empty mysql table I think
16:45:34 sean-k-mooney ya i think i prefer ^
16:45:35 gibi dansmith: correct, the api code is not landed, so the table is empty
16:46:01 dansmith yeah, I'd prefer that, but.. also prefer not landing db code before implementation is ready for exactly this reason :(
16:46:35 gibi OK
16:46:52 sean-k-mooney we dont alwasy do this but my prerfered ordering is "driver -> object -> rpc ->db -> api -> docs"
16:47:28 gibi just a side note that in the other hand people are not happy with 30 patches in a series.
16:47:46 gibi driver uses object code I think
16:47:50 gibi object used db backing
16:48:22 sean-k-mooney it didnt need too but lets not rehash that
16:48:29 gibi anyhow thanks for the feedback, then this migration will be a drop / recreate for all backends
16:48:44 gibi Uggla_: ^^
16:48:57 opendevreview Rajesh Tailor proposed openstack/nova master: Fix KeyError on assisted snapshot call https://review.opendev.org/c/openstack/nova/+/900783
16:49:20 gibi I need to drop now. see you on thrusday
16:49:36 sean-k-mooney enjoy o/
16:49:39 Uggla_ gibi, seen
16:49:57 Uggla_ I will update to drop / recreate the table
17:20:52 frct1 Hello, could anybody from nova team review change to nova-api ? https://review.opendev.org/c/openstack/nova/+/917276 this fix #cloud-config provide over vendor_data2.json which is broken for now.
17:25:56 sean-k-mooney frct1: so any change shoudl really have test coverage to validate it
17:26:16 sean-k-mooney also this seams like a new feature
17:26:30 sean-k-mooney adding cloud init supprot to dymic veder data
17:27:32 frct1 Not a new feature, since its support declared by cloud-init (https://cloudinit.readthedocs.io/en/latest/reference/datasources/openstack.html#vendor-data), there is proposal to fix https://blueprints.launchpad.net/nova/+spec/dynamicjson-vendordata-cloud-config
17:27:47 sean-k-mooney in json format
17:28:01 frct1 Current DynamicJSON implementation strongly limit developers to return JSON encoded response from provider
17:28:09 sean-k-mooney right
17:28:13 sean-k-mooney we dont supprot any other format
17:28:20 sean-k-mooney only json
17:28:27 sean-k-mooney so that is the new feature your addign
17:28:43 sean-k-mooney allowign the raw respocne to be passed
17:28:43 frct1 I have to implement another vendor data provider ?
17:29:02 sean-k-mooney which also changes the returnd formate form a dict to a string
17:29:50 sean-k-mooney so the vendor data feature only supprot talking to rest api that return a json responce
17:30:29 bauzas folks, I'll be off tomorrow, see you on Thur
17:31:59 frct1 What are ways to solve it ? New vendor data provider ? It is possible is over-engineering to implement new one because cloud-init is only thing that expects cloud-init key in vendor_data2.json
17:44:19 sean-k-mooney frct1: the first step woudl really be to create a repoducer test case for the issue
17:45:07 sean-k-mooney do you have an example fo a valid respocne that has a cloud-init key?
17:52:47 frct1 yep: https://paste.openstack.org/show/bNmVjYg2Fmq3wpxtny9y/
17:53:27 sean-k-mooney ok well that not a valid respocne the content of the data return by the service has to be a valid json object
17:54:53 frct1 Yes, but in this case cloud-init will ignore cloud-config if it is presented in nested json even if cloud-init key present. There is discrepancy between cloud-init and nova implementation, because cloud-init support to run cloud-config provided in vendor data (https://cloudinit.readthedocs.io/en/latest/reference/datasources/openstack.html#vendor-data)
17:54:54 sean-k-mooney it should be something like this https://paste.openstack.org/show/bua9OEI0FpYb24kTIjHj/
17:55:24 sean-k-mooney frct1: right and nova does not supprot that so adding supprot would be a new feature

Earlier   Later