| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-26 | |||
| 11:49:39 | sean-k-mooney | only the vip needs to stay the same | |
| 11:49:46 | sean-k-mooney | sorry | |
| 11:49:59 | sean-k-mooney | octavia the vip is assigned to the vm you are booting | |
| 11:50:48 | sean-k-mooney | rm_work: the vip is the public loadblancer ip right? | |
| 11:51:06 | sean-k-mooney | the one that applciation will use to connect to the services that are behind it | |
| 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 | sean-k-mooney | oh its becasue of the workaround for bug #1529084 | |
| 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: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 | gibi | I also filed a bug to oslo.serialization https://bugs.launchpad.net/oslo.serialization/+bug/1864678 | |
| 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: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 | gibi | I'm not sure that the fix of https://bugs.launchpad.net/oslo.messaging/+bug/1529084 can be backported to pike | |
| 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: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 | brinzhang | gmann: is that true of bug 1864776? | |