Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-11-16
16:09:24 bauzas now placement-nova-tox-functional-py38 job works again :)
16:09:26 bauzas thanks !
16:09:55 bauzas #topic Release Planning
16:10:04 bauzas #info Yoga-1 is due Nova 18th #link https://releases.openstack.org/yoga/schedule.html#y-1
16:10:17 bauzas which is in 2 days
16:10:27 bauzas nothing really to say about it
16:10:32 bauzas #info Spec review day is today
16:10:52 bauzas I think I reviewed all the specs but one (but I see this one was merged ;) )
16:11:14 bauzas thanks for all who already reviewed specs
16:11:28 gibi yeah I think we pushed forward all the open specs
16:12:01 whoami-rajat Sorry If I'm interrupting but I had one doubt regarding my spec
16:12:04 bauzas we merged 3 specs today
16:12:41 bauzas whoami-rajat: no worries, we can discuss this spec if you want during the open discussion topic
16:12:52 whoami-rajat ack thanks bauzas
16:12:55 bauzas whoami-rajat: but what is your concern ?
16:13:07 bauzas a tl;dr if you prefer
16:14:03 bauzas for other specs, I'll mark the related blueprints accepted in Launchpad by tomorrow
16:14:21 whoami-rajat bauzas, so I'm working on the reimage spec for volume backed instances and we decided to send connector details with the reimage API call and cinder will do the attachment update (this was during PTG), Lee pointed out that we should follow our current mechanism of nova doing attachment update like we do for other operations
16:15:00 bauzas ok, if this is a technical question, let's discuss this during the open discussion topic as I said
16:15:26 whoami-rajat sure, np
16:15:42 bauzas ok, next topic then
16:15:46 bauzas #topic Review priorities
16:15:52 bauzas #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement)+label:Review-Priority%252B1
16:16:06 bauzas #info https://review.opendev.org/c/openstack/nova/+/816861 bauzas proposing a documentation change for helping contributors to ask for reviews
16:16:16 bauzas gibi already provided some comments on it
16:16:58 bauzas I guess the concern is how to help contributors to ask for reviews priorities like we did with the etherpad
16:17:29 bauzas but if we have a consensus saying that it is not an issue, I'll stop
16:18:02 bauzas but my only concern is that I think asking people to come on IRC and ping folks is difficult so we could use gerrit
16:19:09 gibi what is more difficult? Finding the reason of a faul in nova code and fixing it or joing IRC to ask for review help?
16:19:46 sean-k-mooney well one you "might" be able to do offlien/async
16:20:01 sean-k-mooney the other invovles talking to peopel albeit by text
16:20:25 sean-k-mooney unfortunetly those are sometime non overlaping skill sets
16:20:32 bauzas gibi: I'm just thinking of on and off contributors that just provide bugfixes
16:20:33 gibi doing code review is talking to people via text :)
16:21:12 bauzas but let's continue discussing this in the proposal, I don't wanna drag the whole attention by now
16:21:19 sean-k-mooney bauzas: for one off patches i think the expectaion shoudl still be on use to watch the patchs come in and help them
16:21:28 sean-k-mooney rather ten assuemign they will use any tools we provide
16:21:49 bauzas sean-k-mooney: yeah but then how to discover them ?
16:22:08 bauzas either way, let's discuss this by Gerrit :p
16:22:10 sean-k-mooney well if its a similar time zone i watch for teh irc bot commeting for the patches
16:22:24 sean-k-mooney if i dont recognise it or the name i open it
16:22:49 sean-k-mooney and then one of use can request the reqview priority in gerrirt or publicise the patch to others
16:23:15 bauzas that's one direction
16:23:46 sean-k-mooney if there is something in gerrit i can set im happy to do that on patches when i think they are ready otherwise ill just ping them to ye as i do now
16:23:55 bauzas either way, we have a large number of items for the open discussion topic, so let's move on
16:24:01 sean-k-mooney ack
16:24:09 bauzas #topic Stable Branches
16:24:23 bauzas elodilles: fancy copy/pasting or do you want me to do so ?
16:24:35 elodilles either way is OK :)
16:25:42 bauzas I can do it
16:25:44 bauzas #info stable gates' status look OK, no blocked branch
16:25:50 bauzas #info final ussuri nova package release was published (21.2.4)
16:25:55 bauzas #info ussuri-em tagging patch is waiting for final python-novaclient release patch to merge
16:26:00 bauzas #link https://review.opendev.org/c/openstack/releases/+/817930
16:26:05 bauzas #link https://review.opendev.org/c/openstack/releases/+/817606
16:26:09 bauzas #info intermittent volume detach issue: afaik Lee has an idea and started to work on how it can be fixed:
16:26:14 bauzas #link https://review.opendev.org/c/openstack/tempest/+/817772/
16:26:19 bauzas any question ?
16:26:25 elodilles thanks :)
16:27:40 bauzas looks like none
16:27:47 bauzas #topic Sub/related team Highlights
16:27:47 gibi the volume detach issue feel more an more like not related to detach
16:27:51 bauzas #undo
16:27:51 opendevmeet Removing item from minutes: #topic Sub/related team Highlights
16:28:05 gibi the kernel panic happens before we issue detach
16:28:07 elodilles gibi: true
16:28:21 gibi it is either related to the attach or the live migration itself
16:28:50 gibi I have trials placing sleep in different places to see where we are too fast https://review.opendev.org/c/openstack/nova/+/817564
16:28:52 bauzas which stable branches are impacted ?
16:28:57 gibi stable/victoria
16:29:01 bauzas ubuntu focal-ish I guess ?
16:29:20 bauzas ack thanks
16:29:21 elodilles (and other branches as well, but might be different root causes)
16:29:45 gibi I only see kernel panic in stable/victoria (a lot) and one single failure in stable/wallaby
16:30:08 gibi so if there are detach issues in older stable that is either not causing kernel panic, or we don't see the panic in the logs
16:30:33 bauzas I guess kernel versions are different between branches
16:30:41 bauzas right?
16:31:06 bauzas could we imagine somehow to verify another kernel version for stable/victoria
16:31:06 bauzas ?
16:31:06 gibi we tested with guest cirros 0.5.1 (victoria default) and 0.5.2 (master default) it is reproducible with both
16:31:23 bauzas ack so unrelated
16:31:31 gibi there is a summary here https://bugs.launchpad.net/nova/+bug/1950310/comments/8
16:32:19 bauzas #link https://bugs.launchpad.net/nova/+bug/1950310/comments/8 explaining the guest kernel panic related to stable/victoria branch
16:32:22 sean-k-mooney ya the fiew cases i looked at with you last week were all happing befoer detach
16:32:38 sean-k-mooney so its either the attach or live migration
16:32:44 gibi sean-k-mooney: I have more logs in the runs of https://review.opendev.org/c/openstack/nova/+/817564 if you are interested
16:32:52 sean-k-mooney i looked downstream at our qemu bugs but didnt see anythign relevent
16:33:09 sean-k-mooney gibi: sure ill try and take a look proably tomorrow
16:33:15 sean-k-mooney but ill open it in a tab
16:33:57 gibi sean-k-mooney: thanks, I will retrigger that patch for a couple times to see if the current sleep before the live migration helps
16:34:24 bauzas a good sleep always helps
16:34:39 bauzas :)
16:34:45 elodilles :]
16:34:46 sean-k-mooney when sleep does not work we can also try a trusty print statement
16:35:09 gibi sleep is not there as a solution but as a troubleshooting to see which step we are too fast :D
16:35:33 gibi and I do have a lot of print(server.console) like statements in the tempest :D
16:36:10 sean-k-mooney i think we can move on but its good you were able to confirm we were attaching before the kerenl finished booting
16:36:22 sean-k-mooney at least in some cases
16:36:57 sean-k-mooney that at least lend weight to the idea we are racing
16:37:05 bauzas ok, let's move on

Earlier   Later