Earlier  
Posted Nick Remark
#openstack-nova - 2022-02-21
15:38:20 sean-k-mooney gibi: ok so you are writign up a bug for this
15:38:39 sean-k-mooney and are going to try an capture this old context
15:39:04 gibi yes
15:39:17 gibi I try to write up what couplings I found
15:39:23 gibi the Whitelist.__init__ is one example
16:08:46 gibi I did the write up https://bugs.launchpad.net/nova/+bug/1961587/comments/2
16:11:20 opendevreview Alexey Stupnikov proposed openstack/nova master: Run clean up calls when queued live migration is aborted https://review.opendev.org/c/openstack/nova/+/828570
16:48:05 kashyap Finally ... Linux kernel wants to consolidate /dev/random and /dev/urandom. Removes much confusion - https://lwn.net/SubscriberLink/884875/0c09a5929fef859c/
16:48:42 kashyap "it would seem there are no huge barriers to removing the final distinction between /dev/random and /dev/urandom—other than the names, of course"
16:53:35 opendevreview Ghanshyam proposed openstack/nova master: Modify remaining APIs as per RBAC new guidelines https://review.opendev.org/c/openstack/nova/+/828994
16:54:08 opendevreview Ghanshyam proposed openstack/nova master: Separate flavor extra specs policy for server APIs https://review.opendev.org/c/openstack/nova/+/829626
16:54:25 opendevreview Ghanshyam proposed openstack/nova master: Complete phase-1 of RBAC community-wide goal https://review.opendev.org/c/openstack/nova/+/829866
16:56:24 dansmith gibi: where did the compute node stuff go in this? https://review.opendev.org/c/openstack/nova/+/828369/20
16:56:45 gibi dansmith: on a call, I will ping you soon
16:56:50 dansmith gibi: I was going to circle back and see how that was shaping up, but it looks like a lot was dropped in the latest rev so something much have changed
16:56:51 dansmith sure
16:59:49 chateaulav dansmith: see patchset 19
17:00:37 dansmith chateaulav: what about it? no comments on there about a change in direction that I see
17:00:44 dansmith chateaulav: or do you mean ps20 was an accident?
17:01:41 chateaulav we discussed this morning about dropping initial riscv support in this cycle. I can make note in the review of the discussion from irc.
17:01:54 dansmith ah okay
17:02:06 chateaulav dansmith: i wanted to ensure code had no issues with the support removed
17:02:07 dansmith that's why I was asking here, figured there was some discussion not captured there
17:02:15 chateaulav totally
17:18:19 chateaulav dansmith: let me know if you have any questions. and also see the DNM from gibi for a more complete capture of the issue and related bug that was submitted. https://review.opendev.org/c/openstack/nova/+/829989
17:18:29 dansmith chateaulav: I just commented on that
17:26:05 gibi dansmith: chateaulav is correct we do not try to extend the Arch enum any more so the ComputeNode OVO backporting issue can be ignored now
17:26:14 gibi at least for the current release
17:26:56 dansmith yep, I'm caught up having seen your DNM
17:27:07 gibi dansmith: thanks for the comment on https://review.opendev.org/c/openstack/nova/+/829989
17:27:26 gibi dansmith: the separate ListObject thing might work
17:27:38 dansmith worth a try I think
17:28:02 dansmith and in that case, the list object becomes more of a "this is what specs the remote side supports" which can have its own legit translation logic in the backport
17:28:03 gibi dansmith: so in the next release if we want riscv support then we can try that
17:28:07 dansmith ++
17:28:38 gibi if it does not work then we can still make a minimum service version check on the new compute before publishing support for new archs
17:28:48 dansmith there could be a situation in the future where we supported arm and then it split into arml and armf, such that we need to translate those two into one or something
17:28:52 dansmith yep, for sure
17:29:23 gibi dansmith: ohh that arm thingy is a nice example where we need specific translation in the supported list
17:29:30 dansmith yeah
17:29:34 gibi OK I think this is settled
17:29:38 gibi thanks
17:30:51 dansmith cool
17:33:43 gibi chateaulav: I checked the first patch of the series it looks good to me. I will continue with the rest tomorrow
17:58:49 chateaulav awesome thanks gibi
17:59:10 melwitt gibi: feel free to mark the nova bug I reported as a duplicate
17:59:12 melwitt I didn't realize it was already out there
20:51:18 opendevreview Merged openstack/nova stable/xena: Clean up allocations left by evacuation when deleting service https://review.opendev.org/c/openstack/nova/+/816954
20:51:25 opendevreview Merged openstack/nova master: trivial: Add a white space in an error message https://review.opendev.org/c/openstack/nova/+/823223
20:53:11 opendevreview yuval proposed openstack/nova master: Lightbits LightOS driver https://review.opendev.org/c/openstack/nova/+/821606
20:57:54 opendevreview Merged openstack/nova master: nova-next: Drop NOVA_USE_SERVICE_TOKEN from subnode https://review.opendev.org/c/openstack/nova/+/816740
20:58:01 opendevreview Merged openstack/nova master: Vmware: Fix spelling in test https://review.opendev.org/c/openstack/nova/+/806348
20:58:08 opendevreview Merged openstack/nova master: Correct test error https://review.opendev.org/c/openstack/nova/+/773634
22:32:33 opendevreview Julia Kreger proposed openstack/nova master: Ironic - Handle instance/node host on rebalance https://review.opendev.org/c/openstack/nova/+/813897
22:33:51 opendevreview Julia Kreger proposed openstack/nova master: Ironic - Don't query the API for instance counts https://review.opendev.org/c/openstack/nova/+/829613
23:11:40 opendevreview Merged openstack/nova master: Raise InstanceNotFound on fkey constraint fail saving info cache https://review.opendev.org/c/openstack/nova/+/826942
23:11:48 opendevreview Merged openstack/nova master: VmWare: Use of id shadows built-in function https://review.opendev.org/c/openstack/nova/+/806390
23:11:56 opendevreview Merged openstack/nova stable/xena: Prevent leaked eventlets to send notifications https://review.opendev.org/c/openstack/nova/+/816487
#openstack-nova - 2022-02-22
01:36:15 opendevreview Minghong Hou proposed openstack/nova master: db: Retrieve VirtualInterface objects by UUID, not address https://review.opendev.org/c/openstack/nova/+/828819
01:46:37 opendevreview melanie witt proposed openstack/nova master: libvirt: Register defaults for undefined hw image properties https://review.opendev.org/c/openstack/nova/+/800708
06:32:56 opendevreview Minghong Hou proposed openstack/nova master: db: Retrieve VirtualInterface objects by UUID, not address https://review.opendev.org/c/openstack/nova/+/828819
07:39:25 opendevreview yuval proposed openstack/nova master: Lightbits LightOS driver https://review.opendev.org/c/openstack/nova/+/821606
08:06:18 opendevreview Felix Huettner proposed openstack/nova stable/stein: Gracefull recovery when attaching volume fails https://review.opendev.org/c/openstack/nova/+/829859
08:07:08 opendevreview Felix Huettner proposed openstack/nova stable/rocky: Gracefull recovery when attaching volume fails https://review.opendev.org/c/openstack/nova/+/829860
08:07:53 opendevreview Felix Huettner proposed openstack/nova stable/queens: Gracefull recovery when attaching volume fails https://review.opendev.org/c/openstack/nova/+/829861
09:09:13 opendevreview Elod Illes proposed openstack/nova stable/queens: Fix sphinx doc job https://review.opendev.org/c/openstack/nova/+/830327
11:05:05 opendevreview Fabian Wiesel proposed openstack/nova master: Transport context to all threads https://review.opendev.org/c/openstack/nova/+/827467
11:42:13 opendevreview Balazs Gibizer proposed openstack/nova master: Fix eventlet.tpool import https://review.opendev.org/c/openstack/nova/+/830383
11:50:40 chateaulav gibi: with a multi patch series, like i have. when i go to update, do i rebase back to the driver patch and then make the appropriate changes, or do I have to submit the whole series for review each time even though the objects patch has the first +2?
11:51:22 chateaulav i hope that makes sense, just want to make sure i fully understand and am not creating to much work for you guys
12:00:05 sean-k-mooney chateaulav: the object patch is the base patch so you dont have to rebase that to work on the following patch
12:00:17 chateaulav ok
12:00:47 sean-k-mooney you have 2 ways to do it you can write a patch at the end to adress the issues and then do an interactive rebase to squash merge it into the patch its fixign
12:01:08 sean-k-mooney our you can start with a interactive rebase and mark the commits you want to alter for editing
12:01:25 sean-k-mooney in both cases you tell git to keep the base object patch exactly as is
12:01:45 chateaulav ok, good, thats what im doing then. just wanted to make sure
12:02:01 sean-k-mooney then when you finish the rebase it will have only modified the following commits and the git review at the end will not update the first review
12:02:22 sean-k-mooney you can also pass -R to git review to ensure it does not do any automatic rebases for you
12:05:38 sean-k-mooney gibi: did you see ralonsoh comments on https://review.opendev.org/c/openstack/neutron/+/829247
12:06:01 sean-k-mooney gibi: while form a nova perspeictive it looks like the port is fully updated apprently its not fully updated in the db
12:12:37 opendevreview yuval proposed openstack/nova master: Lightbits LightOS driver https://review.opendev.org/c/openstack/nova/+/821606
12:16:25 gibi sean-k-mooney: now read ralonsoh's comment
12:17:26 gibi sean-k-mooney: I'm not a neutron expert so it can very well be that the change is not persisted
12:17:33 sean-k-mooney the fact that what ralonsoh commented is possibel today speaks to a larger problem in neutron IMO but i guess for now you just need to ensure the db version is also updated
12:17:52 sean-k-mooney gibi: i think its possible perseited but only in memory
12:17:52 ralonsoh sean-k-mooney, what other problem?
12:18:11 sean-k-mooney ralonsoh: teh fact that you can partly update a port but later api calls will show it as updated
12:18:15 sean-k-mooney even though the db is not
12:18:52 sean-k-mooney it suggest there is a problem with caching or how neutron is retriving data
12:19:14 gibi ralonsoh: if you happen to have a pointer where shoudl the mac_address be updated in neutron for this to work then please let me know that will help me updating the patch properly
12:19:16 ralonsoh sean-k-mooney, no no, this is not the case
12:19:40 ralonsoh gibi, yes, let me work on this today (or tomorrow morning)
12:19:44 ralonsoh I'll focus on this
12:20:05 sean-k-mooney ralonsoh: the unit test are doing a port show to get the port after it was updated, and you said you could see the chage in port show/list
12:20:06 gibi ralonsoh: thanks
12:20:21 sean-k-mooney eventhough you also said the db record still had the old mac
12:20:37 sean-k-mooney so there is clearly a disconenct in my and your understanding
12:20:41 ralonsoh sean-k-mooney, yes, this is because you populate the port dictionary (the one that is going to be in the JSON) with the port register info
12:20:51 ralonsoh and other related db registers
12:21:32 ralonsoh sean-k-mooney, the port dictionary comes from how neutron was implemented 10 years ago

Earlier   Later