Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-24
13:58:41 mriedem tonyb: what's the status on newton eol? because i think i've got another worthwhile change for newton before eol
13:59:10 mriedem belmoreira: honestly we probably won't know much about cellsv1 issues here as none of us are running it
13:59:23 dansmith stephenfin: if we register it then we really shouldn't be breaking the rules because if someone were to send us a 1.0 version of that we couldn't even deserialize it
13:59:43 dansmith stephenfin: if we feel it's overly onerous to break the rules, then we might as well not even bump the version because we *can't* honor the old one
13:59:53 dansmith overly onerous to *not* break the rules Imean
14:01:12 stephenfin dansmith: Yeah, that makes sense. I guess we might want to revert part of https://review.openstack.org/#/c/508498/ too, in that case
14:01:27 belmoreira mriedem: dansmith: ok. thanks, I will go through these steps and I will let you know this goes
14:01:34 stephenfin (that's the one where I said not to do this versioning against ralonsoh's better instincts :))
14:02:05 dansmith stephenfin: eesh
14:03:25 dansmith stephenfin: well, it's done now, so maybe just reset the versions to 1.0, admit fault, and try to be clean going forward
14:03:40 dansmith reverting an unsupportable object version isn't particularly helpful either
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

Earlier   Later