Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-26
11:51:38 rm_work yes
11:51:59 rm_work the VIP is static and is known to the user
11:52:07 sean-k-mooney yep
11:52:14 rm_work and will always persist (it is unbound, and uses allowed-address-pairs)
11:52:22 sean-k-mooney ya
11:53:29 sean-k-mooney so even in routed network you could use a /32 route to make that available rigth even if the ha proxy vm ip is not in the same subnet range
11:53:30 rm_work so, i'm aware we will have problems if the aggregate fills up, but we have no choice :(
11:53:50 rm_work that'd be possible if we had a different network architecture, maybe
11:53:56 rm_work as it is, we cannot
11:54:11 sean-k-mooney well bgp would be able to supprot that
11:54:16 sean-k-mooney but ya ok
11:54:35 mlycka Hello. Is there a specific person responsible for adding new version templates and folders to nova-spec?
11:54:52 sean-k-mooney not really we have scripts that do it
11:55:20 mlycka Right right...when are you likely to run them for V?
11:55:39 sean-k-mooney mlycka: but you did remind me i need to go update my patch to move implemented specs
11:55:47 sean-k-mooney mlycka: usually not until after m3
11:55:58 rm_work yeah I would kill for working BGP :D
11:55:59 mlycka m3?
11:56:26 sean-k-mooney milestone 3 so i think start of april
11:56:49 mlycka Crud
11:57:18 sean-k-mooney we just past the spec freeze for U so we usally dont want to start reviewing new spec right away however you could put up a review against the backlog folder and just update it when its created
11:57:51 mlycka I need to move a blueprint proposal to V from U, 'cause I managed to miss my window by being busy and I need to restore it
11:58:26 sean-k-mooney ah ok well let me check something
11:58:42 mlycka Sure, thanks.
12:00:17 sean-k-mooney ok we dont have a script for the new folder although code is welcome. anyone can do it so you have two options. 1 propose a patch that creates the folder and copys the ussuirt template and renames it. 2 restore your spec and propose it to the backlog
12:00:48 sean-k-mooney if you go with option 1 just rebase your current spec on top
12:01:04 sean-k-mooney it just proably wont get looked at for a little bit
12:01:51 mlycka Yeah, that's fair enough. Is the template going to be the same for Victoria then?
12:03:40 mlycka Also, do I need to file a bug for that or is there an existing one or do I just propose a patch without a bug?
12:07:46 openstackgerrit Merged openstack/nova master: trivial: Remove FakeScheduler https://review.opendev.org/707224
12:07:53 openstackgerrit Merged openstack/nova master: conf: Deprecate '[scheduler] driver' https://review.opendev.org/707225
12:08:01 openstackgerrit Merged openstack/nova master: docs: Improve documentation on writing custom scheduler filters https://review.opendev.org/707226
12:08:13 openstackgerrit Merged openstack/nova master: trivial: Use recognized extra specs in tests https://review.opendev.org/708435
12:08:36 gibi sean-k-mooney, rm_work: mail is up on the ML http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012846.html
12:10:24 rm_work ok
12:10:52 rm_work so basically i guess i just keep running this filter and my patches as-is downstream, and try to participate in getting this moving forward upstream so eventually we can drop it :D
12:11:38 gibi rm_work: good strategy
12:16:40 sean-k-mooney gibi: thanks ill take a look at it in a while
12:18:11 sean-k-mooney gibi: before that however im going to try and go through https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/provider-config-file today and adress some/all of your comments
12:18:22 sean-k-mooney assuming they are not really hard
12:20:39 gibi sean-k-mooney: cool. ping me if you need some clarification. honestly I lost the context on that so I dont remember if my comments were hard or not
12:21:58 sean-k-mooney well i have not looked at the code before so you know better then i do :) but so far they look ok. i think dustinc is not really around much at the momenet/forseeable future so im going to try and help move it along a bit
12:24:23 openstackgerrit Balazs Gibizer proposed openstack/nova stable/rocky: Avoid circular reference during serialization https://review.opendev.org/709798
12:24:59 gibi this is a stable only bugfix so it need some non stable core to look at ^^
12:25:13 gibi bauzas, stephenfin: ^^
12:29:03 sean-k-mooney why is jsonutils.dumps being used instead of to_primitive?
12:29:55 openstackgerrit Marek Lyčka proposed openstack/nova-specs master: Adds spec infrastructure for Victoria https://review.opendev.org/710023
12:30:36 sean-k-mooney oh i guess you are trying to convert it to a dictionay
12:30:56 sean-k-mooney by round tripping the data through json
12:31:01 gibi sean-k-mooney: the legacy_spec is a dict form of a RequestSpec object
12:31:12 sean-k-mooney ya so we cant just use obj_to_primitive
12:31:15 gibi but it is a special dict form
12:31:22 sean-k-mooney becasue that wont give us what we want
12:32:09 gibi it would give us a different dict
12:32:44 sean-k-mooney yep so it wont work here
12:32:59 sean-k-mooney why do we need to use legacy requests specs in this case?
12:33:38 sean-k-mooney i taught we had already moved to ovo form in rocky but i guess not fully
12:36:32 openstack bug 1529084 in oslo.messaging "RPC fake driver should accept datetime items for data" [Undecided,Fix released] https://launchpad.net/bugs/1529084 - Assigned to Balazs Gibizer (balazs-gibizer)
12:36:32 sean-k-mooney oh its becasue of the workaround for bug #1529084
12:37:19 sean-k-mooney that intoduced the seriasiation and deserialisation but missed the fact it wont recurse to the nested ovos which is what you are fixing
12:39:03 sean-k-mooney another fix would be to fix the rpc fake dirver to accept datimes in dicst and remvoe the jsonutils calls entirely
12:39:47 gibi sean-k-mooney: since stein we doesn't use the legacy dict but pass around the ovo, but that is an RPC change it is not backportable
12:40:33 gibi sean-k-mooney: but yeah, we we can somehow remove the need of the json.loads(json.dumps(..) stuff that would also help
12:41:09 sean-k-mooney well the comment says its done beacase teh fake rpc driver does not support datetimes in dicts
12:41:16 sean-k-mooney so if we fix that then we could remove it right
12:41:31 sean-k-mooney i assume there was a reason bauzas didnt do that orgininally
12:41:43 sean-k-mooney other then this was faster
12:42:35 gibi I'm not sure what will happen if the dump an load is removed and then the rpc will try to serialize the dict again with ovos inside
12:42:48 sean-k-mooney gibi: anway i have not checked that setting default=... will work but your change looks resonable to me
12:43:43 gibi sean-k-mooney: the solution is basically change how the to_primitive works during dumps to trigger the ovo serialization instead of stuck in an infinite loop
12:44:09 sean-k-mooney ya i was assuming "default=jsonutils.to_primitive" if not set
12:44:14 openstack Launchpad bug 1864678 in oslo.serialization "jsonutils.to_primitive does not follow the protocol required by json.dump" [Medium,Triaged]
12:44:14 gibi I also filed a bug to oslo.serialization https://bugs.launchpad.net/oslo.serialization/+bug/1864678
12:44:24 sean-k-mooney so you are just passing an extra argment to it with functools.partial
12:44:32 gibi sean-k-mooney: yeas, that is the default by default (sic)
12:44:38 gibi sean-k-mooney: yes
12:45:18 sean-k-mooney yep so that all makes sense to me. its not the cleanest thing long term but its the minimal backportable change which is more important
12:46:03 openstack Launchpad bug 1529084 in oslo.messaging "RPC fake driver should accept datetime items for data" [Undecided,Fix released] - Assigned to Balazs Gibizer (balazs-gibizer)
12:46:03 gibi I'm not sure that the fix of https://bugs.launchpad.net/oslo.messaging/+bug/1529084 can be backported to pike
12:46:35 gibi and the the we can bump oslo.messaging version on the stable branches
12:47:03 gibi then remove the loads(dumps(..)) part from nova, and backport it to pike
12:47:05 sean-k-mooney you mean to rocky
12:47:17 gibi sean-k-mooney: rocky is the first stable that is affected
12:47:25 gibi I have to backport the whole thing to pike
12:47:28 sean-k-mooney ah you have other cherry picks
12:47:32 gibi as we have a failure downstream
12:47:40 gibi in pike
12:47:47 sean-k-mooney gotch ya
12:48:16 gibi so my target is to fix pike, and sure I will fix every broken stable along the way but I wan't to do this with minimal change
12:48:31 gibi a new oslo.messaging version would be a lot harder business
12:48:32 sean-k-mooney not a core but i +1'd it anyway since it makes sense after our disucsstion stephenfin its pretty quick if you can take a look
12:48:42 gibi sean-k-mooney: thanks!
12:53:25 sean-k-mooney hehe i some how dont think the intel pmem ci is going to work on rocky
12:53:40 sean-k-mooney they might want to fix that at some point
12:55:27 openstack bug 1864776 in OpenStack Compute (nova) "os-volumes-attachments API policy is allowed for everyone even policy defaults is admin_or_owner" [Undecided,In progress] https://launchpad.net/bugs/1864776 - Assigned to Brin Zhang (zhangbailin)
12:55:27 brinzhang gmann: is that true of bug 1864776?
13:01:43 brinzhang gmann: I was pushed the fixed patch https://review.opendev.org/#/c/709955/, and rebase this patch I was tested https://review.opendev.org/#/c/709929/1/nova/tests/unit/policies/test_volumes.py, it also need everyone contexts to authorize the admin_or_owner role
13:02:13 brinzhang gmann: I am not sure this bug is true, while you are free, pls review, thanks
13:48:21 openstackgerrit Stephen Finucane proposed openstack/python-novaclient master: Don't print user_data for 'nova show' https://review.opendev.org/708850
13:50:17 openstackgerrit Stephen Finucane proposed openstack/nova master: api: Add framework for extra spec validation https://review.opendev.org/704643

Earlier   Later