Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-19
15:47:48 kashyap sean-k-mooney: FWIW, I sent that (hopefully) clarifying patch -- https://lists.nongnu.org/archive/html/qemu-devel/2018-02/msg04905.html
15:50:39 hrw sean-k-mooney: as then they will share similar issues as we have on aarch64 ;D
15:57:06 kashyap sean-k-mooney: So these are the two possibilities with Nova:
15:57:13 kashyap (1) Image metadata property:
15:57:19 kashyap $ openstack image set --property hw_machine_type=x86_64=pc-q35-2.10 Fedora27_Template
15:57:22 kashyap (2) Nova conf:
15:57:35 kashyap [libvirt]
15:57:35 kashyap ...
15:57:35 kashyap hw_machine_type=x86_64=pc-q35-2.10
15:58:32 kashyap sean-k-mooney: The remaining item in Nova is graceful handling of "distributions shipping 'q35' by default".
16:03:19 openstackgerrit Jay Pipes proposed openstack/os-vif master: zuul: Enable functional tests in gate https://review.openstack.org/530961
16:07:47 sean-k-mooney kashyap: yep that all makes sense to me. operator can set in in nova.conf if they want to force it by default or tenant can request it in image metadata if there image requires q35 features to work e.g. vIOMMU support
16:09:20 sean-k-mooney kashyap: hrw it seams pretty strait forward to add Q35 support so a specless blueprint might be sufficent. will ye be at the ptg next week?
16:10:59 kashyap sean-k-mooney: Yes, at least I'll be there
16:11:17 kashyap (And nod to your previous comment, too)
16:16:50 mriedem dansmith: left a comment in https://review.openstack.org/#/c/544698/2/nova/tests/unit/db/test_sqlalchemy_migration.py - if you're meh on that, then i'll +2 anyway
16:19:01 dansmith mriedem: I'm pretty meh
16:23:10 efried jaypipes, cdent: edleafe: mriedem found a discrepancy in the update_provider_tree spec that I'd like to discuss and clear up.
16:23:21 cdent was just reading that
16:23:55 efried Here's the scenario: my compute node is aggregated with a sharing provider. The sharing provider happens to be part of its own tree. We want the sharing provider itself to be included in the ProviderTree that u_p_t gets - that's for sure.
16:23:58 efried But
16:24:30 efried Do we want to include the sharing provider's whole tree? Or just the provider itself, as a "root" even if it isn't really a root in its own tree?
16:25:14 efried jaypipes: I want to say you and I discussed this briefly when I was writing the code and decided on the latter, but thinking through it again, I'm not convinced that's The Right Thing.
16:25:31 edleafe efried: sounds like you have a huge recursion problem if you include trees of trees of trees of ...
16:25:38 mriedem i assume the compute driver got an n-1 view of things it doesn't control
16:25:43 mriedem edleafe: yes agree
16:26:06 jaypipes mriedem: I don't understand what you mean by an "n-1 view"
16:26:12 efried edleafe: Well, we have explicit boundaries. We definitely don't go and spider out to the sharing provider's aggregate-associated providers.
16:26:13 mriedem 1 removed
16:26:24 efried ^ that
16:26:37 mriedem so the virt driver gets the compute node + the sharing provider aggregate, but none of that things children
16:26:39 edleafe efried: another way to look at it: would the compute node ever need to know about /interact with any of the shared provider's tree other than the SP itself?
16:26:51 efried Arguably the unrelated bits of the sharing provider's tree are n-2 - but I'm not sure that's a horrible thing.
16:27:17 cdent I think edleafe's question is the crux.
16:27:33 efried edleafe: No. But. I don't feel great about the caveat that it would show up as a root even if it's not a root. Rather have more information (that's not used) in the tree than have some of it be inaccurate?
16:27:38 mriedem if the virt driver shouldn't mess with stuff outside of the compute node's tree, it should just be able to see that there is a relationship, right? but not the whole other thing's tree, lest the virt driver gets the idea it has access to update that other thing (which it shouldn't do)
16:27:59 efried Yeah, I agree with that.
16:28:02 mriedem i can't tell if it being a root or not matters
16:28:07 efried That's the thing.
16:28:18 efried We *do* want the virt to be able to mess with the sharing provider.
16:28:19 mriedem if my virt driver shouldn't mess with the sharing provider, why do i care if it's a root or not?
16:28:37 mriedem why?
16:28:45 jaypipes mriedem: this goes back to the powervm virt driver structure.
16:28:55 cdent efried: yes we do, but for those sharing providers that we want to mess with, do we want them to existing in a nested hieararchy? I would think/hope not.
16:28:57 jaypipes mriedem: they want the ability to manage storage pools in their virt driver.
16:28:59 efried As one example, yes. I think VCenter also had an example.
16:29:09 cdent vcenter's example is basically the same
16:29:15 edleafe efried: if the shared provider is the one with the inventory, it would be the one we allocate against, no? Why do we need its root provider?
16:29:35 mriedem the spec says, "Note,
16:29:35 mriedem however, that it may contain providers not directly owned/controlled by the
16:29:35 mriedem compute host. Care must be taken not to remove or modify such providers
16:29:35 mriedem inadvertently."
16:29:37 jaypipes edleafe: the virt driver doesn't allocate.
16:29:45 dansmith mriedem: rc2 is tagged, yeah? are we good to land the compute rpc thing now?
16:29:49 efried mriedem: Yes, there's that too.
16:29:50 sean-k-mooney jaypipes: just regarding those 2 os-vif changes you +2'd i am happy to merge them too but i think there may be an alternitive way to adress https://review.openstack.org/#/c/531358/ that would also work on centos but it might be tricky to do in the gate so ill run it by ye in dublin.
16:29:53 mriedem dansmith: sure
16:29:57 mriedem dansmith: i haven't looked at it yet
16:30:00 edleafe jaypipes: but I thought we were talking placement
16:30:17 jaypipes edleafe: we're talking virt driver's use of the ProviderTree struct
16:30:27 dansmith mriedem: okay, it's fairly straightforward and would like to land that soon before we break it of course
16:30:50 efried That's for e.g. sean-k-mooney's cases when there's like a bandwidth provider that's owned by neutron, but is part of the compute node's tree structure.
16:30:57 mriedem dansmith: i am now in update_provider_tree land
16:30:59 jaypipes sean-k-mooney: feel free to approve them then and we'll discuss in Dublin
16:31:10 edleafe jaypipes: sure, but we're also talking about shared providers linked to a compute node
16:31:14 dansmith mriedem: good luck with that
16:31:47 sean-k-mooney jaypipes: cool. i need to talk to stephen about how to add custom jobs via zullv3. i think i understand but i would like to get a linux bridge job there also
16:32:02 cdent can we, at least temporarily, make guideance that shared providers don't nest? Does that get us further down the road without having to predict everything?
16:32:07 mriedem efried: jaypipes: it doesn't seem like a good idea for the nova virt driver to be modifying things that aren't directly under nova's control, like compute resources - because if nova says it can mess with storage and network sharing providers, then cinder/neutron can also be mucking with those right? and we have a fun split brain problem.
16:32:11 efried cdent: It would, yes.
16:32:11 kashyap sean-k-mooney: I need to run to my Dutch class now; will add the blueprint tomm or later when I get back.
16:32:18 cdent or rather, if they do nest, we don't care about it
16:32:37 edleafe ^^ that
16:32:59 cdent because all we really need to know (for now) is that they are there
16:33:01 efried mriedem: Up to this point, virt.PowerVM has full control over the Shared Storage Pool. We want to keep it that way in Placement-land.
16:33:06 jaypipes mriedem: I'm not saying that it's my *preferred* architecture for a virt driver. but it is what it is..
16:33:36 sean-k-mooney efried: at least for the bandwidth case the provider would not be a shared provider but it was going to be associated to the neutron agent by an aggregate
16:34:03 efried sean-k-mooney: Okay, maybe it was neutron owning the NICs/PFs?
16:34:12 mriedem efried: are those SSP's restricted to a single nova-compute service?
16:34:17 sean-k-mooney efried: in that case also not shared
16:34:21 mriedem or can multiple virt drivers be monkeying with the same SSP?
16:34:35 efried mriedem: The latter. We recognize and accept the caveats of co-management.
16:34:46 sean-k-mooney neutron would be creating RPs in the compute node tree in both cases however
16:34:54 efried ^
16:35:37 sean-k-mooney mriedem: SSP?
16:35:48 mriedem shared storage pool
16:35:48 efried sean-k-mooney: Shared Storage Pool, PowerVM style in this case.
16:35:58 sean-k-mooney oh ya ok
16:36:27 mriedem ok so the spec says the virt driver can see these other things but shouldn't modify them, but then you're saying you totally do want to modify them and that's the intent
16:36:38 efried mriedem: No, those are different things.
16:36:42 mriedem in other words, update_provider_tree is a blank check to the virt driver
16:37:11 mriedem as we've seen with the RT managing allocations,
16:37:17 mriedem this is probably goign to end badly
16:37:34 efried The networky examples in sean-k-mooney's camp are going to be providers in the tree that's rooted at the compute node RP. Those are the ones virt should avoid mucking with.
16:37:36 sean-k-mooney efried: oh speaking of PowerVM as an aside it support PCI devices corret but does not expose pci address am i rembering that correctly. i mentioned it on stephenfin's numa aware vswitch spec but was not sure if i remembered correctly
16:38:05 efried sean-k-mooney: I haven't made it all the way through that spec yet, but will look out for that, thanks.
16:38:47 mriedem so non-compute child resource providers - don't touch; non-compute shared aggregate providers, go nuts
16:38:55 efried mriedem: Blank check, sort of. It's going to be important for the virt driver to understand what it's doing with its providers.
16:39:31 mriedem do you have an example of what a virt driver would need to do with a shared provider aggregate?
16:39:31 efried mriedem: The caveats are just caveats. If a virt driver figures out some way it's going to co-manage the providers neutron creates... that sounds weird but doable.

Earlier   Later