Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-24
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 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:25 cdent mdbooth: as is so often the case
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 stephenfin I do think I have a patch up to resolve just that though
15:48:41 bauzas yeah, that's my point
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 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:05 bauzas we should only have nested RPs if we need more than one inventory for a single resource provider
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
15:50:15 stephenfin *yes. Pages
15:50:37 mriedem sure, as long as someone can eventually find /X/index :)
15:51:03 efried edleafe Even if there's multiple possible types - if you determine which type at boot time, and one type is as good as another, then you still don't need nested to represent this.
15:51:07 stephenfin mriedem: One request: if you do pull brand new pages in, can you rename anything with underscore to use hyphens? It's one of my OCD things ;)
15:51:17 efried dansmith And at some point we'll have to talk about the mechanism by which you "configure" the thing you requested.
15:51:23 mriedem stephenfin: you mean the actual rst filename?
15:51:27 stephenfin mriedem: Yup, we've got work to do there. Try to find the SR-IOV docs at the moment
15:51:32 dansmith efried: that'd be virt specific
15:51:34 stephenfin Yup - that filename is reflected in the URL
15:51:37 bauzas yup
15:51:38 mriedem stephenfin: those are in the networking guide aren't they?
15:51:44 dansmith efried: unless you're talking about things like ironic raid layouts
15:51:58 stephenfin oops
15:52:11 efried dansmith Well, my understanding is that ironic is going to do such things via templates, and they'll represent a single template as a custom trait.
15:52:13 dansmith efried: what I meant was some quirk of the vgpu that allowed you to configure it one way or the other that didn't affect its resource usage
15:52:40 dansmith efried: right
15:52:49 edleafe efried: are you saying that a pGPU that is capable of multiple types, it cannot be configured to provide some of one, and some of another? IOW, does it always have to be all one type at boot?
15:52:53 efried dansmith ++. I don't really know how VGPUs are "deployed" so I'm kinda thinking of it like VFs.
15:53:17 efried edleafe That's what I don't know, specifically about VGPUs.
15:53:20 dansmith efried: there are some things you can do when you carve off a vgpu on some of the devices, like decide whether it gets a framebuffer or is just for compute, etc
15:53:45 bauzas edleafe: that's what we agreed in the spec
15:54:08 edleafe bauzas: just one type at boot?
15:54:32 bauzas I'm just having a testbox now that shows me for a single pGPU that I can have 11 different types
15:54:42 bauzas multiple that by 4 pGPUs
15:54:50 bauzas fortunately, all of them share the same types

Earlier   Later