| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-29 | |||
| 13:41:33 | sean-k-mooney | were there pending change sstill need after v47 | |
| 13:42:07 | stephenfin | I don't see anything, but I haven't been involved until now | |
| 13:43:01 | sean-k-mooney | if more changes can be done via followups i would personally prefer to start merging the code and adress it that way gibi johnthetubaguy how would you feel about that | |
| 13:43:50 | sean-k-mooney | i think the code was perfectly resonable to merge even at the end of last cycle but im sure we can still tighten the schema definitions and testing | |
| 13:44:14 | sean-k-mooney | i just dont want perfect to be the enemy of good enough and delay this again | |
| 13:44:55 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Update keypairs in saving an instance object https://review.opendev.org/683043 | |
| 13:49:36 | stephenfin | dansmith: Can you look at https://review.opendev.org/#/c/683043/ again today? | |
| 13:50:18 | gibi | sean-k-mooney: I have to re-review the patch to see if everything is resolved or not | |
| 13:51:38 | gibi | sean-k-mooney: restricting the schema later is a backward incompatible change which would be expensive so I'm on the side to do something that is pretty solid | |
| 13:51:43 | gibi | it is like an API | |
| 13:52:06 | sean-k-mooney | sure but until we have a release with this im not sure we need to be as strict | |
| 13:52:32 | sean-k-mooney | e.g. we coudl treat the scema as a 0.X and then bump to 1.0 when we are happy and release with that | |
| 13:53:12 | gibi | sean-k-mooney: 0.x could work, indicating that it is beta and can change in a backward incompatible way | |
| 13:53:43 | dansmith | stephenfin: I just glanced at it and he didn't do what I prescribed (you said he did), but I haven't looked closely at why he thinks that will work | |
| 13:54:07 | dansmith | just FYI in case you didn't examine it closely | |
| 13:55:34 | stephenfin | You'd suggested calling '_save_extra_generic' and 'self.obj_reset_changes' from '_save_keypairs', and he's just put 'self.obj_reset_changes' into '_save_extra_generic'. That looked functionally equivalent to me | |
| 13:57:07 | dansmith | but keypairs isn't an extra field | |
| 13:57:37 | dansmith | I said | |
| 13:58:07 | dansmith | "the generic save handler" but "save_extra_generic" is specifically for fields in instance_extra, which I think keypairs is not in, no? | |
| 13:58:46 | dansmith | or maybe I'm confusing keypairS with keypair | |
| 13:59:09 | stephenfin | I think it is | |
| 13:59:21 | stephenfin | Yeah, it's part of _INSTANCE_EXTRA_FIELDS | |
| 14:01:12 | dansmith | right, okay.. Instance has its own (key_name, key_data) from when we could only have one | |
| 14:02:31 | stephenfin | TIL (that those fields existed) | |
| 14:02:58 | stephenfin | anyway, since it's in _INSTANCE_EXTRA_FIELDS we'll trigger the correct code path https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L788-L790 | |
| 14:03:24 | dansmith | aye | |
| 14:03:43 | stephenfin | and calling 'self.obj_reset_changes' on a nested object field would presumably always be the correct thing to do in that path | |
| 14:04:53 | dansmith | I'm not sure about that, I need to check something.. because there are cases where we do and don't delegate that to sub-objects | |
| 14:05:01 | dansmith | since originally all sub-objects would have their own save handler, | |
| 14:05:13 | dansmith | we initially (at least) didn't reset through like that | |
| 14:05:57 | dansmith | I'mma pull it down and look | |
| 14:06:10 | dansmith | https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/base.py#L629 | |
| 14:06:18 | dansmith | that's why we have recursive= | |
| 14:07:24 | dansmith | heh, he makes fake_instance() do recursive=True | |
| 14:15:21 | stephenfin | so instead of https://review.opendev.org/#/c/683043/15/nova/tests/unit/fake_instance.py@143 we could have kept that as-is, and added 'inst.keypairs.obj_reset_changes()' | |
| 14:15:47 | stephenfin | any reason that would be preferable, given "there are cases where we do and don't delegate that to sub-objects" | |
| 14:15:49 | stephenfin | ? | |
| 14:16:34 | dansmith | I dunno, yet, I'm poking.. | |
| 14:16:42 | stephenfin | ack | |
| 14:16:43 | dansmith | aren't you a typing pedant such that assertFalse(len(of thing)) feels wrong to you? | |
| 14:17:44 | stephenfin | Yeah /o\ I considered changing it when rebasing and decided not to for some reason. Happy to change if it's not just me | |
| 14:18:50 | dansmith | I stared at "false is not 4" for a few moments when I broke the test on purpose... :) | |
| 14:19:12 | stephenfin | bauzas: Mentioned this Friday but it was a bit late. Care to take a look at https://review.opendev.org/#/c/706013/ when you've time? | |
| 14:20:54 | bauzas | stephenfin: sure I can try | |
| 14:22:13 | bauzas | stephenfin: humpf, I think you can't do this https://review.opendev.org/#/c/706013/6/nova/objects/migration.py | |
| 14:22:20 | bauzas | dansmith: ^ | |
| 14:22:44 | bauzas | stephenfin: if you want to change an object field, you can't just change its type directly | |
| 14:23:05 | bauzas | you need to provide another field and, | |
| 14:23:06 | stephenfin | bauzas: dansmith looked at it in the past. It's kosher. The serialized objects look identical, and the validation works as it did | |
| 14:23:18 | bauzas | you need to depracate the other | |
| 14:23:23 | bauzas | deprecate* | |
| 14:23:35 | bauzas | hmmm, ok | |
| 14:24:01 | stephenfin | There would be an issue if I was changing from e.g. StringField to ObjectField or IntegerField, but MigrationTypeField is an EnumField | |
| 14:25:03 | dansmith | bauzas: I haven't looked at what he's offering, but in the past, if we've converted the field type from string to enum and the enum has every possible historical value in it, we've allowed it | |
| 14:25:36 | dansmith | i.e. as long as it won't break existing clients.. the field type doesn't go over the wire, just the assumption that it's de-serializable by the type on the remote side | |
| 14:25:37 | bauzas | well, now I understand | |
| 14:25:46 | bauzas | yeah, stephenfin explained it | |
| 14:26:03 | dansmith | bauzas: I know, but if you're me you wouldn't take stephenfin's word for it, so.. :D | |
| 14:26:20 | dansmith | hence, I assume, the name drop above | |
| 14:26:29 | bauzas | because when deserializing the new object, then the old compute could still be able to create its object | |
| 14:26:48 | bauzas | dansmith: haha | |
| 14:26:51 | dansmith | bauzas: yeah | |
| 14:26:56 | stephenfin | dansmith: correct. Validation through association | |
| 14:27:06 | bauzas | okay, I'll provide a comment then | |
| 14:27:06 | dansmith | bauzas: I think we've done worse things than string->enum even :) | |
| 14:27:15 | bauzas | just to make sure people understand why I'm accepting it | |
| 14:27:31 | dansmith | does it have a code comment about the type changin? | |
| 14:27:40 | dansmith | if not, you could/should -1 probably and demand it | |
| 14:27:58 | dansmith | just so people know that older clients could be less strict | |
| 14:28:06 | stephenfin | The type isn't changing | |
| 14:28:19 | dansmith | it's going from string to enum right? | |
| 14:28:32 | stephenfin | Nope. It was an EnumField with 4 allowed values. It's still an EnumField with four values | |
| 14:28:35 | stephenfin | https://review.opendev.org/#/c/706013/6/nova/objects/migration.py | |
| 14:29:00 | stephenfin | I've just making it a custom enum field so I have constants I can reference | |
| 14:29:01 | dansmith | oh, even less of a thing then, nevermind | |
| 14:29:19 | dansmith | yeah that's definitely not visible to RPC, so whatever | |
| 14:30:46 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/train: Guard against missing image cache directory https://review.opendev.org/738455 | |
| 14:31:15 | bauzas | stephenfin: dansmith: yeah, it's just changing the EnumField to be a specific one | |
| 14:31:40 | bauzas | but, tbc, I don't want to see other changes just changing types without thinking about this | |
| 14:32:30 | bauzas | stephenfin: fwiw, I'd also have loved if you could have cut this change in two and not adding two properties as well in the same | |
| 14:32:42 | bauzas | given this wasn't needed | |
| 14:33:14 | stephenfin | It wouldn't really help though | |
| 14:33:37 | bauzas | anyway, reviewing it | |
| 14:33:56 | stephenfin | You'd save about four lines in the first patch (the properties), and then you'd have to review a second patch that's reworks virtually everything you changed in the first one | |
| 14:54:36 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM: Test the state of VMware NSX 3pp CI https://review.opendev.org/734114 | |
| 15:17:45 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/train: Guard against missing image cache directory https://review.opendev.org/738455 | |
| 17:21:18 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Warn at controller start if there are older than N-1 computes https://review.opendev.org/738482 | |
| 17:38:08 | openstackgerrit | Merged openstack/nova master: objects: Add MigrationTypeField https://review.opendev.org/706013 | |
| #openstack-nova - 2020-06-30 | |||
| 04:15:12 | openstackgerrit | Merged openstack/nova stable/queens: Reproduce bug 1862633 https://review.opendev.org/729539 | |
| 04:15:12 | openstack | bug 1862633 in OpenStack Compute (nova) "unshelve leak allocation if update port fails" [Medium,Fix released] https://launchpad.net/bugs/1862633 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 06:04:18 | openstackgerrit | Alexandre Arents proposed openstack/nova master: Limit the number of concurrent snapshots https://review.opendev.org/736169 | |
| 07:05:35 | aarents | Good morning Nova, | |
| 07:05:50 | aarents | basic gerrit workflow question , should I rebase this https://review.opendev.org/#/c/734776/ , because I repushed nits on https://review.opendev.org/#/c/736169 (first one is on top of 2nd) | |
| 07:14:18 | bauzas | good morning nova | |
| 07:14:21 | bauzas | aarents: /me looks | |
| 07:15:01 | bauzas | aarents: indeed but I can +W it | |
| 07:15:12 | bauzas | since stephenfin and dansmith accepted it | |
| 07:16:26 | aarents | bauzas: thanks, doing | |
| 07:16:36 | bauzas | aarents: ping me when you're done | |
| 07:16:51 | aarents | k | |