Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-19
15:25:34 kashyap mriedem: FWIW, I at least saw him on IRC briefly in the (CET) morning
15:28:08 bauzas mriedem: I can help
15:28:36 bauzas mriedem: lemme know which ones you'd like to see reviewed
15:28:41 bauzas for the moment, looking at LP
15:30:46 mriedem bauzas: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata+label:Code-Review=2
15:31:01 mriedem some of those might have things on pike yet
15:31:08 mriedem like https://review.openstack.org/#/c/539008/
15:31:13 bauzas mriedem: ack, will look at them ASAIC
15:31:20 mriedem thanks
15:31:37 bauzas 24 open bugs :p
15:31:41 bauzas woooot
15:45:48 sean-k-mooney hrw: kashyap is there a spec to enable Q35 proposed. i assume it will be via an image metadata item or perhaps a config option in the libvirt section of the nova.conf
15:46:00 kashyap sean-k-mooney: I updated the upstream QEMU doc to clearly spell out machine type requirements for PCIe features.
15:46:15 hrw sean-k-mooney: you set hw_machine_type = q35 in image and done
15:46:16 kashyap sean-k-mooney: Hmm, not that I know of; I have a TODO item to propose one, unless someone beats me to it
15:46:27 kashyap But yeah, currently what hrw tells above ^
15:46:38 hrw sean-k-mooney: and then you review https://review.openstack.org/#/c/545034/ to have slots for hotplug ;d
15:46:41 kashyap You can either set it via the machine type Nova image metadat property
15:46:47 kashyap Or via the global configuration option
15:47:26 hrw sean-k-mooney: as AArch64 porter I would love to see more and more people moving to Q35
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 hw_machine_type=x86_64=pc-q35-2.10
15:57:35 kashyap ...
15:57:35 kashyap [libvirt]
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 inadvertently."
16:29:35 mriedem compute host. Care must be taken not to remove or modify such providers
16:29:35 mriedem however, that it may contain providers not directly owned/controlled by the
16:29:35 mriedem the spec says, "Note,
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 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:11 efried cdent: It would, yes.
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

Earlier   Later