| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-20 | |||
| 19:42:59 | mriedem | so this | |
| 19:43:00 | mriedem | self.vcpus_used = self.vcpus_total | |
| 19:43:00 | mriedem | self.free_disk_mb = 0 | |
| 19:43:00 | mriedem | self.free_ram_mb = 0 | |
| 19:43:00 | mriedem | """Consume nodes entire resources regardless of instance request.""" | |
| 19:43:02 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Merge flavor extensions controller code https://review.openstack.org/516104 | |
| 19:43:03 | cfriesen | but some of the filters don't | |
| 19:43:06 | dansmith | I don't know all the details, but before placement came and kindof distracted us I thought we were about good to remove that | |
| 19:43:36 | mriedem | the ironic driver will consume all memory_mb/disk_gb/vcpu inventory on a node in placement | |
| 19:43:40 | dansmith | the docs are mostly aimed at just ironic deployments though where there's no reason not to enable the dedicated thing right? | |
| 19:43:47 | mriedem | so that IronicHostState is irrelevant | |
| 19:44:09 | mriedem | *IronicNodeState | |
| 19:44:15 | cfriesen | yeah...there's not a lot of info on how to set up hybrid. I did talk with Julia at the summit about some of this. | |
| 19:45:33 | mriedem | sdague: easy api extension merge-a-roo https://review.openstack.org/#/c/516104/ | |
| 19:45:45 | cfriesen | currently we modified NUMATopologyFilter.host_passes() to just return True for ironic nodes...wondering if this is something to push upstream | |
| 19:46:32 | mriedem | can ironic report numa capabilities? from what i gather, lots of people rely on the CapabilitiesFilter for ironic | |
| 19:46:44 | cfriesen | no idea. :) | |
| 19:46:45 | mriedem | *ComputeCapabilitiesFilter | |
| 19:51:46 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix some incorrect option references for scheduler filters https://review.openstack.org/521645 | |
| 19:59:18 | openstackgerrit | Andrey Kurilin proposed openstack/python-novaclient master: [ci] Use pseudo-random names for new resources https://review.openstack.org/479777 | |
| 20:01:18 | openstackgerrit | Dan Smith proposed openstack/nova master: Alternate fix for validating image on rebuild https://review.openstack.org/521186 | |
| 20:14:45 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Deprecate the IronicHostManager https://review.openstack.org/521648 | |
| 20:28:33 | mriedem | sean-k-mooney: i'm confused, is this a nova bp for just work that is all done in os-vif? https://blueprints.launchpad.net/nova/+spec/vif-port-profile | |
| 21:03:03 | efried | jaypipes What is the proper way to talk about a RP's association with an aggregate? Can I say the RP is *in* the aggregate? | |
| 21:03:12 | jaypipes | efried: yes | |
| 21:03:14 | efried | k | |
| 21:03:23 | efried | jaypipes So here's what I'm thinking. | |
| 21:04:24 | efried | jaypipes Today the report client keeps aggregate associations outside of ProviderTree. I believe we need to move what is currently SchedulerReportClient._provider_aggregate_map into ProviderTree. Specifically, _Provider has a set() of aggregate UUIDs. | |
| 21:05:23 | efried | jaypipes Because the virt driver will ultimately be in charge of assigning aggregate associations, so we'll want the same suite of methods on ProviderTree to ask if a given RP is "in" an aggregate, add (or replace) aggregate associations; etc. | |
| 21:06:17 | efried | jaypipes Same thing for traits, which is where that change set of a couple hours ago was coming from - to be followed up by SRC methods to populate/query it. | |
| 21:11:14 | jaypipes | efried: not sure the virt driver will be responsible for associated an aggregate to a provider -- unless the virt driver is also creating those aggregates. Does PowerVM do that? | |
| 21:11:40 | jaypipes | efried: for traits, yeah, totes agree. | |
| 21:12:18 | efried | jaypipes In the only real world case we have right now - shared storage pool - yes. I can't think how else the aggregate would get created. | |
| 21:12:45 | jaypipes | efried: it was originally intended to be created by an admin or an external agent (for example, Cinder...) | |
| 21:14:03 | efried | jaypipes Yeah, I suppose I can see that. In our case, we use SSP for ephemeral, so it would have to be more like the admin. It would just be another step they have to do when they're setting up the host. | |
| 21:14:22 | jaypipes | efried: understood. | |
| 21:14:26 | efried | jaypipes BTW, is there any rule against me using the same UUID for an aggregate and a RP that's in it? | |
| 21:14:42 | efried | I mean, I'm sure you'll say that's not a good idea, but is anything gonna stop me? | |
| 21:15:00 | jaypipes | efried: not a good idea, but nothing will prevent you from doing that. | |
| 21:15:14 | efried | k | |
| 21:18:18 | efried | jaypipes Okay, so one more thing: If we're moving aggregates (and adding traits) to ProviderTree, we could keep track of the last-refreshed time in either place. I'm assuming we'd like to keep doing that part at the SRC rather than in ProviderTree? | |
| 21:18:55 | efried | since he's the one doing the refreshing. | |
| 21:21:43 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove the deprecated TrustedFilter and related options https://review.openstack.org/521659 | |
| 21:26:07 | jaypipes | efried: yes | |
| 21:26:15 | efried | ight | |
| 21:30:15 | openstackgerrit | Dan Smith proposed openstack/nova master: Add regression test for rebuild with new image doubling allocations https://review.openstack.org/521153 | |
| 21:30:16 | openstackgerrit | Dan Smith proposed openstack/nova master: Fix doubling allocations on rebuild https://review.openstack.org/521662 | |
| 21:38:22 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use the RequestSpec when getting scheduler_hints in compute https://review.openstack.org/515461 | |
| 21:38:23 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Pass RequestSpec to ConductorTaskAPI.build_instances https://review.openstack.org/515495 | |
| 21:47:37 | openstackgerrit | Dan Smith proposed openstack/nova master: Fix doubling allocations on rebuild https://review.openstack.org/521662 | |
| 21:57:06 | efried | jaypipes Confirm: We weren't actually using the SRC aggregate map for anything yet? | |
| 22:12:37 | mriedem | efried: what happened here? https://review.openstack.org/#/q/status:abandoned+topic:bp/add-trait-support-in-allocation-candidates | |
| 22:12:44 | mriedem | is that all superseded by jay's other series? | |
| 22:13:15 | efried | mriedem Most of it, yes. | |
| 22:13:20 | efried | Let me look for outliers... | |
| 22:14:20 | efried | mriedem Yeah; alex_xu started off doing the refactor one way; then jaypipes did it a different way and jaypipes "prevailed" :) | |
| 22:14:50 | mriedem | ok, the new series isn't tracked in launchpad as far as i can tell so i don't know what's going on there | |
| 22:17:06 | efried | mriedem TBH, add-trait-support-in-allocation-candidates may be superseded by granular-resource-requests, depending on timing. | |
| 22:17:22 | hangyang | Hi there, I have some questions for time sync in vm and its KVM host. I have some RHEL7 instances in Ocata openstack cluster. The VMs are not running ntpd and after suspend/resume, I notice there is a time drift between the VM and its KVM host and the VM will never catch up with host. But for stop/start, the vm can keep time in sync with its host. Any idea about how to solve the suspend issue? Should I run ntpd in the guest | |
| 22:17:29 | efried | mriedem See my comments in https://review.openstack.org/#/c/479776/ | |
| 22:17:36 | efried | (which is the last open one tracked by that bp) | |
| 22:23:15 | efried | mriedem Since you seem to be looking, the rest of the ksa patches are gonna be based on https://review.openstack.org/#/c/490057/ | |
| 22:23:27 | efried | ...which I believe you once referred to as "scary". | |
| 22:23:51 | mriedem | yes | |
| 22:24:12 | mriedem | i'm going through all of our queens blueprints and tracking latest status in https://etherpad.openstack.org/p/nova-queens-blueprint-status | |
| 22:24:14 | mriedem | if you must know | |
| 22:24:25 | mriedem | only about 35 more to go | |
| 22:24:35 | flwang | mriedem: sorry for chiming in | |
| 22:24:46 | flwang | mriedem: question about the poverVM driver, does it support Power 720 series? | |
| 22:26:39 | efried | flwang I *think* so. Note that we have a dedicated #openstack-powervm channel - though it's not going to help you much today as everyone else is on vacation already. But let me see if I can find out that answer for sure... | |
| 22:27:21 | flwang | efried: BIG thanks from an ex-IBMer | |
| 22:29:03 | tonyb | dansmith: What are the ds* flavors in devstack used for? | |
| 22:29:07 | efried | flwang The answer is: nope, P8 and up. | |
| 22:29:59 | tonyb | flwang: I have a 720 in my garage, and yeah no KVM, PowerVM or even wemu(TCG) love there :( | |
| 22:30:53 | flwang | really? that's a pitty | |
| 22:31:13 | flwang | but I found this https://www-01.ibm.com/events/wwe/grp/grp020.nsf/vLookupPDFs/Demo%20days%20LoP%20-%20Cloud%20on%20Power%20-%2018%20Mag%202015/$file/Demo%20days%20LoP%20-%20Cloud%20on%20Power%20-%2018%20Mag%202015.pdf | |
| 22:31:16 | flwang | see page 18 | |
| 22:32:26 | efried | flwang Was just about to say: *PowerVC* supports 720. | |
| 22:32:59 | efried | flwang It runs through HMC, not community code, but the interface is seamlessly identical I believe. | |
| 22:33:48 | flwang | efried: I see. so that only means PowerVC can via HMC manage 720, right? | |
| 22:33:58 | jaypipes | efried, mriedem: off for the night. will review all the things in the morning. | |
| 22:34:01 | efried | flwang Correct | |
| 22:34:10 | efried | jaypipes Have a good evening. | |
| 22:34:21 | efried | jeez, it got late | |
| 22:34:28 | flwang | efried: where can i double check if there is a KVM/PowerVM support for Power 720? | |
| 22:34:31 | tonyb | efried: Yeah but not helpful for people lik me that don't have an HMC or PowerVC, still I only use mine for testing yaboot which is nearly dead on 64-bit anyway ... longlive grub! | |
| 22:35:36 | efried | flwang Let me PM you an email address to get that conversation started... | |
| 22:35:46 | flwang | efried: thank you so much | |
| 22:37:13 | tonyb | that'd be kinda cool from a geeky POV | |
| 22:38:14 | mriedem | tonyb: i'm sure mrodden and lbragstad would like to help with that | |
| 22:38:36 | tonyb | mriedem: \o/ | |
| 22:39:50 | tonyb | the more I think about it the more fun I think that'd be | |
| 22:40:27 | efried | tonyb I'll review your code :) | |
| 22:48:06 | tonyb | efried: :) | |
| 23:04:37 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: libvirt: Allow multiple volume attachments https://review.openstack.org/267587 | |
| 23:04:37 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285 | |
| 23:11:22 | ildikov | mriedem: so quickly, did you think of something like this for the Nova side check: https://review.openstack.org/#/c/330285/148..149/nova/compute/api.py ? | |
| 23:14:32 | mriedem | ildikov: close | |
| 23:14:34 | mriedem | but -1 | |
| 23:14:37 | mriedem | muwahahahaha | |