| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-24 | |||
| 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. | |
| 15:47:21 | efried | bauzas You would model your pGPU as the RP. It would have inventory of VGPU. And it would have one trait for each vGPU type it supports. | |
| 15:47:43 | efried | bauzas Then when you ask for a vGPU, you would specify as a required trait which type you want to be created. | |
| 15:47:47 | mriedem | stephenfin: docs question - we now have a nova/user/index but nothing links to that from the main index right? | |
| 15:47:50 | mriedem | so how do people find it? | |
| 15:48:03 | edleafe | efried: no, that's what nested RPs should be doing | |
| 15:48:05 | mriedem | or is that wip? | |
| 15:48:07 | efried | bauzas And then [something TBD] tells virt which types you want to create. | |
| 15:48:21 | dansmith | efried: well, you can't do that if it has a limited number of each type it can provide | |
| 15:48:25 | efried | edleafe Nested only applies if you want to pre-create the vGPUs of a specific type. | |
| 15:48:29 | stephenfin | mriedem: That's WIP. sdague, asettle and I have been working through some ideas on how to structure that | |
| 15:48:32 | dansmith | efried: in that case you'd need to expose two sets of inventory (i.e. be two providers) | |
| 15:48:41 | bauzas | yeah, that's my point | |
| 15:48:41 | stephenfin | I do think I have a patch up to resolve just that though | |
| 15:48:42 | efried | edleafe or if you want to limit the number of each type you can create on the fly. | |
| 15:48:48 | bauzas | it's not an easy answer to me | |
| 15:49:05 | bauzas | we should only have nested RPs if we need more than one inventory for a single resource provider | |
| 15:49:05 | mriedem | stephenfin: ok i'm moving some missing stuff from the old user guide, and was wondering if i should put it in the user index or in the main index - guessing the user index since the main index will point htere | |
| 15:49:20 | efried | dansmith bauzas I'm thinking of the case where the vGPUs are created on the fly, and they can be of any type, and that type gets determined at boot. | |
| 15:49:25 | bauzas | that's a tautology, I assume, but that would mean we would need to track consumption of those resources separately | |
| 15:49:27 | edleafe | efried: bauzas asked: 10:45 < bauzas>| then, I guess I'd use the nested RP model, and have a RP per type? | |
| 15:49:43 | dansmith | efried: yeah, if it's just a configuration thing, then that's fine | |
| 15:50:06 | stephenfin | mriedem: That would be my thinking yes pages in '/X' belong in '/X/index' | |
| 15:50:09 | edleafe | efried: if there is only one type, then nested isn't needed, of course | |