| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-24 | |||
| 14:03:55 | dansmith | we clearly need a little more oversight on those objects I think | |
| 14:04:52 | dansmith | if we start taking those over the REST API we have to be even more squeaky clean than we are with our RPC APIs, since we don't control all the sending and receiving code together | |
| 14:05:10 | stephenfin | dansmith: For my own clarification, do you need to register objects if you do not want to send them over the wire? | |
| 14:06:03 | dansmith | stephenfin: you need to register them in order to receive them through the automatic deserializer, so it knows where to find an object implementation to use to deserialize a primitive | |
| 14:06:10 | sahid | dansmith: we are goin gto start that at a particular version, right? i'm interested to know what is the "someone" who is going to send a version 1.0? | |
| 14:06:28 | dansmith | stephenfin: if you don't need to do that, you still need to build the object, but not register it | |
| 14:07:30 | dansmith | sahid: I understand that there is no code that should be sending the object at the earlier version with that field set right now. That doesn't mean we just make tons of random changes with versions we can't support until some arbitrary point at which we say things are now stable. That version history will confuse people and provide counterexamples they may copy. | |
| 14:07:38 | stephenfin | dansmith: Hmm, to the best of my knowledge these are used only by nova rn, so we're not sending these over RPC nor the REST API. Therefore deserialization is not yet necessary | |
| 14:08:19 | stephenfin | Yeah, we should either be treating these as versioned objects or not doing so | |
| 14:08:20 | dansmith | stephenfin: yeah, so, if that's the case, we should be not registering them (which won't track their hashes) and leave them at 1.0 instead of recording unsupportable versioned changes | |
| 14:08:30 | dansmith | stephenfin: the problem is, | |
| 14:08:38 | dansmith | stephenfin: this is a library that anything could be picking up and using at any point, | |
| 14:08:54 | dansmith | so if you don't register/version them properly, then nobody can do that until you do | |
| 14:09:09 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/newton: Remove unused placement_database config options https://review.openstack.org/514685 | |
| 14:09:09 | dansmith | so maybe that means until release 2.0 of the library it's not usable across projects, which is okay I guess, | |
| 14:09:11 | mriedem | dansmith: sdague: johnthetubaguy: belmoreira: tonyb: ^ i think we should get that into newton before eol | |
| 14:09:27 | sahid | dansmith: we also have moved like that in os-vif, i'm not sure how that is going to confuse people. | |
| 14:09:31 | dansmith | but it's another weird thing you'd want to communicate to your users | |
| 14:09:57 | sahid | s/also/always | |
| 14:10:39 | dansmith | sahid: you have always had broken versioning? are you really arguing that "consistently broken" is less confusing or better? :) | |
| 14:11:01 | stephenfin | dansmith: So ultimately, it sounds like the easiest thing to do would be to introduce the changes I had ralonsoh drop from PS2 https://review.openstack.org/#/c/508498/2..4/os_vif/objects/subnet.py | |
| 14:11:04 | sahid | dansmith: well it's your point of view | |
| 14:11:23 | dansmith | library interfaces should be stable. library interfaces that exist to provide cross-service communication primitives should be .... *really* stable :) | |
| 14:12:23 | sahid | not sure i do understand what you try to say, we change a field so we bump the version, that seem simple | |
| 14:12:28 | stephenfin | +1 Consider it a point learned :) I'll go add those missing versioning functions and hope no one's deploying os-vif from master, heh | |
| 14:12:53 | dansmith | sahid: because just recording a version does not do anything if you can't support the old one | |
| 14:13:17 | dansmith | sahid: it's not a commit log, it serves an actual purpose, unless you break the rules and then it does nothing but communicates to people something you can't do | |
| 14:13:27 | ralonsoh | stephenfin: should I add a make_compatible in https://review.openstack.org/#/c/508498? | |
| 14:13:39 | sahid | it's just to keep history as a chnagelog is doing | |
| 14:13:41 | ralonsoh | stephenfin: and in https://review.openstack.org/#/c/509107/? | |
| 14:13:48 | dansmith | sahid: it is not | |
| 14:14:38 | sahid | okay okay you win, i'm not going to arguing all the day for something so minor :) | |
| 14:14:42 | sahid | please do what you prefer | |
| 14:14:58 | stephenfin | ralonsoh: Yes please, and sorry for sending you the wrong direction :( | |
| 14:15:07 | ralonsoh | stephenfin: no problem at all | |
| 14:16:15 | openstackgerrit | Eric Fried proposed openstack/nova master: Parse numbered & unnumbered resources & traits https://review.openstack.org/514091 | |
| 14:16:16 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Numbered groupings to GET /allocation_candidates https://review.openstack.org/514092 | |
| 14:16:58 | mriedem | sahid: breaking version compatibility isn't really a minor thing | |
| 14:17:11 | mriedem | it also affects whether or not you can backport patches | |
| 14:17:17 | sahid | mriedem: it was not the case | |
| 14:17:31 | dansmith | especially for a library to provide cross-service communication primitives | |
| 14:18:02 | sahid | os-vif is not shared by services as you and dansmith seem to think on the review | |
| 14:18:17 | dansmith | that is the *purpose* of the library | |
| 14:18:40 | dansmith | just because I can hammer this square peg into this round hole doesn't mean it's a good idea | |
| 14:19:14 | sahid | it's you point of view and i do not share it, but no worries we don't have to be always agreed :) | |
| 14:19:29 | dansmith | you don't agree that os-vif is supposed to be shared between services? | |
| 14:20:09 | dansmith | from the os-vif page: "Integration library between network (Neutron) and compute (Nova) providers" | |
| 14:20:11 | dansmith | that's the intent | |
| 14:21:22 | mriedem | sahid: is your argument / justification that since nova and neutron are not yet doing vif negotation using os-vif objects, it's not something we have to worry about? | |
| 14:23:04 | sahid | mriedem: the field has been updated, incrementing the version seem to be a good practice | |
| 14:23:13 | sahid | that is not going to break anything | |
| 14:24:07 | mriedem | it would break me if i were using version < 1.2 of that object and had the dhcp_server field set | |
| 14:24:28 | mriedem | and moved to >= 1.2 where dhcp_server no longer exists | |
| 14:24:41 | sahid | no, that can't happen | |
| 14:24:52 | mriedem | probably more clear to say, i have 1.2 with dhcp_servers set, and downgrade to 1.1 | |
| 14:25:06 | mriedem | there is no compatibility routine for converting dhcp_servers to dhcp_server | |
| 14:25:31 | sahid | but again, os-vif is not shared between service, you seem to forgot that point | |
| 14:25:45 | mriedem | sahid: can you clarify that point per my question above? | |
| 14:26:01 | mriedem | do you mean it's not shared because we haven't yet implemented the vif negotiation code between nova and neutron? | |
| 14:26:12 | mriedem | you realize that's the intent and goal with the library though right? | |
| 14:27:22 | sahid | mriedem: yes and it's probably why i do think incrementing the version seems to be a good pratice | |
| 14:29:44 | mriedem | so wouldn't good practice actually be treating this like it was being shared across services already and follow the rules? | |
| 14:30:12 | mriedem | rather than saying, "at version 1.4 we actually started caring" | |
| 14:31:54 | sahid | mriedem: i would say no, we don't want to add code and maintain code which is not necessary, i do prefer say that we start caring at version 1.4 | |
| 14:33:23 | sahid | seems to be a reasonable and usual way to use versioning | |
| 14:43:43 | cdent | mdbooth, or anyone else. I have a vague memory of a bug wherein a moved server could have an image removed out from under it because of a bug in cache handling. related to auto resize confirm. any recollections or clues to where to find such a thing? | |
| 14:44:03 | mdbooth | Yep | |
| 14:44:40 | mdbooth | https://review.openstack.org/#/c/462521/ | |
| 14:45:20 | cdent | mdbooth: thank you! | |
| 14:45:44 | mdbooth | cdent: The 'fix' is really a workaround | |
| 14:45:54 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Accept InternalError through the API https://review.openstack.org/514702 | |
| 14:46:25 | cdent | mdbooth: as is so often the case | |
| 14:46:25 | mdbooth | Because it turns out our datamodel doesn't currently allow us to easily identify when an image in the local image cache is still in use by the destination host of a migration | |
| 14:46:48 | mdbooth | Fixing the datamodel would be better, but this is also good on its own merits, I think | |
| 15:15:47 | openstackgerrit | sean mooney proposed openstack/os-traits master: add plathform security namespaces https://review.openstack.org/514712 | |
| 15:15:48 | openstackgerrit | sean mooney proposed openstack/os-traits master: add firmware (fw) traits namespace https://review.openstack.org/514713 | |
| 15:28:53 | openstackgerrit | Elod Illes proposed openstack/nova master: WIP: Transform scheduler.select_destinations notification https://review.openstack.org/508506 | |
| 15:31:24 | openstackgerrit | Merged openstack/nova stable/pike: fix nova accepting invalid availability zone name with ':' https://review.openstack.org/509656 | |
| 15:31:29 | openstackgerrit | Merged openstack/nova master: Move the idmapshift binary into privsep. https://review.openstack.org/495541 | |
| 15:41:30 | bauzas | dansmith: mriedem: do you know if jay is around by those days or just off ? | |
| 15:41:44 | bauzas | I'm just implementing the VGPU series and I'd like to hear some voice | |
| 15:41:46 | efried | bauzas He's doing all his new-hire stuff at his new job. | |
| 15:41:50 | bauzas | ah ok | |
| 15:41:58 | efried | Said he would probably be back tomorrow or the next day. | |
| 15:42:22 | bauzas | so I'll speak out loud, if anyone cares | |
| 15:42:36 | openstackgerrit | Merged openstack/nova master: Move loopback setup and removal to privsep. https://review.openstack.org/495664 | |
| 15:42:38 | efried | I'll listen. And maybe even care :) | |
| 15:42:53 | dansmith | I'll care. And maybe even listen. | |
| 15:43:08 | bauzas | given a pGPU can support different types for the same device, we supposingly said in the spec we'll use a whitelist for telling which type to use | |
| 15:43:57 | bauzas | now for Queens it's easy as we said we would only support a single type | |
| 15:44:14 | bauzas | so I'm basically accumulating all the available vGPUs for the same type | |
| 15:44:46 | bauzas | now, my question is more Rocky (but since I'm designing the internal interfaces now, I'd make my model resilient to the changes) | |
| 15:45:05 | bauzas | what if as an operator, I'm asking for 2 types? | |
| 15:45:21 | bauzas | then, I guess I'd use the nested RP model, and have a RP per type? | |
| 15:45:30 | bauzas | that's where I'm confused | |
| 15:45:49 | mriedem | stephenfin: please drop your +2 from this, it's wrong https://review.openstack.org/#/c/507151/ | |
| 15:45:59 | bauzas | I mean, it would probably better for me to just upload my current patch so we could discuss | |
| 15:46:05 | bauzas | nevermind the above | |
| 15:46:14 | bauzas | I'll just push something that will create a discussion | |
| 15:46:39 | efried | bauzas This is a good example of where traits != settings. | |