Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-04-23
16:17:25 sean-k-mooney my inclination is we shoud remove the grenade jobs form 2023.1 when stable/zed moves to unmaintained/zed
16:17:45 sean-k-mooney i lean to do ing that before the branch is renamed but we could do it after
16:18:09 elodilles sean-k-mooney: probably that will be needed after stable/zed will be deleted, but might be possible to keep it, we have to check when we get there
16:18:39 sean-k-mooney im not sure if we want to keep it
16:18:42 sean-k-mooney even if its possible
16:19:08 sean-k-mooney since upgrade supprot form unmainiend branches is not impleied and is actully expressly not supproted
16:19:09 elodilles if the job is passing then why remove it?
16:19:26 sean-k-mooney mainly to save gate resouces by not testing somethign we dont supprot
16:19:30 elodilles but yes, let's see first how it will behave :)
16:19:38 sean-k-mooney ack
16:19:50 bauzas cool
16:19:58 bauzas we could discuss this in the gerrit change
16:20:04 elodilles +1
16:20:12 elodilles last note from me:
16:20:15 elodilles #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:20:37 elodilles that's all about stable branches
16:21:36 bauzas cool
16:21:46 bauzas #topic vmwareapi 3rd-party CI efforts Highlights
16:21:51 bauzas fwiesel: anything ?
16:21:54 fwiesel #info Nothing to report.
16:22:26 fwiesel Just a short reminder or request for a second review of my proposed patch: https://review.opendev.org/c/openstack/nova/+/909474
16:22:44 bauzas OK, I'll try to look at it
16:23:25 fwiesel I understdoot that there was the idea to have a subteam for the vmwareapi driver. Is that the right time to raise that topic?
16:23:33 sean-k-mooney its relitivly short and i belive its correct but i agree it would be good to make a decision on that sooner rather then later
16:23:49 sean-k-mooney sure
16:24:06 dansmith oh yeah I need to look at that
16:25:31 fwiesel Thanks, that would be then all from my side.
16:28:13 bauzas ++
16:28:27 bauzas #topic Open discussion
16:28:32 bauzas nothing from me
16:28:37 bauzas sean-k-mooney: you had an item
16:28:50 sean-k-mooney yes its mainly a question fo paperwork
16:29:12 bauzas shoot
16:29:15 sean-k-mooney for the eventlet removeal work, ill create a bluepirnt eventlet-removal-part-1
16:29:23 sean-k-mooney i assume i shoudl also have a spec?
16:29:53 sean-k-mooney or do we want to review the blueprint first and see if we are ok with a specless blueprint
16:30:04 bauzas no
16:30:17 bauzas we said at the PTG that I'll automatically accept it as specless :)
16:30:41 bauzas in case we need to discuss some specific design nits for upgrade concerns, per say, then we could ask later for a spec
16:30:43 sean-k-mooney ok then ill work on a bluepirnt for the next meeting to define a semi detialed scope for this cycle
16:31:04 bauzas cool
16:31:20 bauzas I think we all agreed on the direction so we should be good
16:31:40 bauzas maybe the threadpools could have some concerns but we can discuss them in the implementation changes
16:32:00 sean-k-mooney ack that was basically all i wanted to confirm
16:32:02 bauzas for the workers using direct threads, I don't think we have any problems
16:32:30 sean-k-mooney well in generall i would prefer to aovid spawning raw thread outside of a pool in new places
16:32:35 bauzas we said we prefered to use parallel threads instead on concurrent ones
16:32:39 sean-k-mooney but as you said we can review that on the patches
16:33:08 bauzas there are different threads, right?
16:33:40 sean-k-mooney you will have to rephase that question, im not following.
16:33:41 dansmith what does "parallel instead of concurrent" mean?
16:33:44 bauzas like, for the services workers, it's not a problem, we would create all the threads when starting the service
16:34:07 sean-k-mooney your repheing to how we have a worker count for the schduler
16:34:20 bauzas dansmith: I mean that we would thread instead of greenthreading
16:35:00 sean-k-mooney ok yes we woudl be using pthreads/OS threads instead fo userland/green threads
16:35:02 dansmith bauzas: okay so you mean async instead of one of parallel or concurrent I think, but okay
16:35:18 sean-k-mooney in pything the gil means they are still concurrent not turely parallel
16:35:37 sean-k-mooney *in python
16:35:39 bauzas sure
16:35:51 bauzas we still have the GIL so they're not really paralled
16:35:59 bauzas but they're threads
16:36:05 sean-k-mooney yes
16:36:05 dansmith they're still parallel, IMHO
16:36:07 fwiesel Depends on the context... c-extensions may release the lock and run really in parallel
16:36:15 dansmith right
16:36:33 bauzas anyway, let me reexplain it
16:36:34 dansmith they're parallel but with a ton of shared/locked data structures :)
16:36:35 sean-k-mooney ya and there are other case wehre the gil is droped too
16:36:36 fwiesel Would help with the parsing of the huge xml documents we sometimes get in the vmwareapi
16:36:47 dansmith let's just move on, I think we know what we agreed
16:36:54 sean-k-mooney sure
16:37:09 bauzas we will use 'python threads" instead of "other concurrent/green threading way"
16:37:37 sean-k-mooney yes throught the api of a futureist executor in most cases
16:37:41 bauzas so, anything else to say?
16:37:53 sean-k-mooney nope
16:37:56 bauzas cool
16:37:59 bauzas thanks all
16:38:16 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-04-23-16.00.log.html
16:38:16 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-04-23-16.00.txt
16:38:16 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-04-23-16.00.html
16:38:16 opendevmeet Meeting ended Tue Apr 23 16:38:16 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:38:16 bauzas #endmeeting
16:38:27 fwiesel Thanks and bye
16:38:42 gibi o/
16:38:42 elodilles thanks o/
16:39:13 elodilles bauzas: the zed release patch: https://review.opendev.org/c/openstack/releases/+/916813
16:41:27 elodilles btw, it's probably useful to release now then form newer stable branches as well. i'll create stable release patches for those
16:59:40 elodilles here they are: 2023.1 - https://review.opendev.org/916815 ; 2023.2 - https://review.opendev.org/916816
17:00:10 elodilles i think we don't need a stable/2024.1 release yet
17:01:27 elodilles (this would be the content on caracal in the moment: https://paste.opendev.org/show/bq3vt56UP5WVQ9baFLUZ/ )
#openstack-nova - 2024-04-24
14:17:47 artom dansmith, sean-k-mooney, I think https://review.opendev.org/c/openstack/nova/+/915139/3 (the cpu_shared_set live migration fix) is at a point where it should be an easy-ish +2/+A - can we get that going? I've got a couple of whitebox changed that need it, which will allow us to cross a few tests off our list
14:18:21 sean-k-mooney ah ya i didnt get to reveiw that last week
14:18:40 sean-k-mooney i have 12 mins before my next meeting so ill take a look
14:21:37 artom Cheers :)
14:36:48 simondodsley is there a known prgramatic method to get the unique ID of a hypervisor? I know it is in the Nova DB but not sure which construct I can use to get that out through a python call
14:41:26 sean-k-mooney do you mean the compute node UUID
14:41:40 sean-k-mooney that is aviable to admins via the hypervior api
14:46:43 dansmith Uggla_: mind if I just quickly fix the truthiness nits in https://review.opendev.org/c/openstack/nova/+/915139/3/nova/virt/libvirt/migration.py and then I'll +2?
14:51:59 dansmith and also the commit message nit
14:52:07 dansmith (which is not really a nit, IMHO)

Earlier   Later