| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-27 | |||
| 13:58:50 | superdan | you mean cachingscheduler only right? | |
| 13:59:08 | bauzas | superdan: I need to look at code, but I think we can run any scheduler driver code | |
| 13:59:13 | superdan | because I don't think we're promising to keep filters around for our own scheduler for other drivers | |
| 13:59:16 | superdan | sure, but, | |
| 13:59:20 | superdan | that's your problem if you do | |
| 13:59:30 | bauzas | that's one way to see it :) | |
| 13:59:40 | superdan | if you swap out the whole driver, but import our filters to use them... | |
| 13:59:55 | bauzas | but yeah, at least in-tree, we still have CachingScheduler and ChanceScheduler | |
| 14:00:02 | bauzas | both aren't calling placement | |
| 14:00:36 | superdan | heh, chancescheduler :) | |
| 14:00:44 | bauzas | tbc, while the former is production-targeted, I think we can safely drop chancescheduler | |
| 14:00:54 | bauzas | ... except we use it at lot in our functional tests | |
| 14:01:06 | bauzas | AFAIR | |
| 14:01:23 | bauzas | chancescheduler is just random(host) | |
| 14:01:31 | bauzas | it's not about chance | |
| 14:01:44 | sean-k-mooney | bauzas: we do stil allow out of tree scheduler driver but we dont gurarntee not to break them | |
| 14:02:01 | bauzas | I agree | |
| 14:02:16 | bauzas | I'm just saying we allow that, so communication is the key | |
| 14:03:13 | sean-k-mooney | in future we will likely want to narrow that to say if you run a out of tree driver it must call placement but there is not much add benifit to that vs the filter driver with just one custom filter | |
| 14:05:21 | sean-k-mooney | bauzas: the chance schduler could likely be ported to just a random weigher and a pass all filter for functional tests | |
| 14:09:56 | openstackgerrit | Merged openstack/nova master: placement: resource requests for nested providers https://review.openstack.org/554529 | |
| 14:10:11 | openstackgerrit | Merged openstack/nova master: Fix tox -e docs https://review.openstack.org/564631 | |
| 14:11:16 | openstackgerrit | Takahito Hirose proposed openstack/python-novaclient master: api_version decorator becomes an error in Python 3.5.0. https://review.openstack.org/564774 | |
| 14:21:38 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Make sure microversion < 2.62 does not show host(Id) for instance actions https://review.openstack.org/564782 | |
| 14:30:13 | sahid | mriedem, superdan, when you have a moment i commented on a patch we have worked on | |
| 14:30:16 | sahid | https://review.openstack.org/#/c/497457/30/nova/virt/libvirt/driver.py@7384 | |
| 14:30:38 | sahid | i think we will have to find a solution to address a specific case | |
| 14:43:18 | sean-k-mooney | mriedem: im going to be offlie for a while soon but ill try and respin https://review.openstack.org/#/c/553072/5 today. | |
| 14:45:12 | sahid | sean-k-mooney: don't set workflow -1, if you can't address the comments I will try next week | |
| 14:45:59 | sean-k-mooney | mriedem: ill also try and and set up a mixed lb and ovs devstack at the weekend/this evening to test https://review.openstack.org/#/c/551370/ and ill post the local.conf. i should be able to convert that into a ci job once i know what the local.conf need to look like. | |
| 14:46:23 | sean-k-mooney | sahid: well i set -1 since i plan to fix it myself later today once i get home. | |
| 14:46:43 | mriedem | sean-k-mooney: cool, thanks | |
| 14:49:57 | kashyap | mriedem: Fixed another typo in the config file: s/the you need to/then you need to/ in that change | |
| 14:50:03 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Lift the restriction of choices for `cpu_model_extra_flags` https://review.openstack.org/563926 | |
| 14:50:47 | mriedem | kashyap: did you see the comment from danpb? | |
| 14:50:50 | mriedem | on PS6 | |
| 14:50:54 | kashyap | mriedem: Oh, let me see | |
| 14:51:47 | kashyap | mriedem: Darn | |
| 14:51:58 | kashyap | In the original series, I _did_ canonicalize | |
| 14:52:11 | kashyap | (s/series/patch/) | |
| 14:52:36 | sean-k-mooney | kashyap: ya i was about to check if it was done in the previous patch | |
| 14:52:58 | kashyap | sean-k-mooney: In the original backported version we ignore the case | |
| 14:53:01 | kashyap | Hmm | |
| 14:53:47 | sean-k-mooney | kashyap: in that case you proably want a patch to just lowercase the flags then rebase https://review.openstack.org/#/c/563926/ on top | |
| 14:54:04 | sean-k-mooney | then we can backport the lowercsing seperatly | |
| 14:54:35 | kashyap | sean-k-mooney: Hmm, I'm a bit torn | |
| 14:54:46 | kashyap | Whether to just do the canonicalization to lowercase in this patch | |
| 14:54:52 | kashyap | (Which seems cleaner) | |
| 14:54:54 | sahid | sean-k-mooney: ok thanks | |
| 14:55:09 | kashyap | But there's the "What about backports" thing | |
| 14:55:12 | sean-k-mooney | kashyap: actully we have a choices element in the backport right? | |
| 14:55:40 | sean-k-mooney | kashyap: e.g. the backported verion only allows pcid | |
| 14:55:41 | kashyap | sean-k-mooney: We do, and also have: 'ignore_case=True' | |
| 14:55:54 | kashyap | sean-k-mooney: Yes, only 'pcid' was allowed | |
| 14:56:27 | sean-k-mooney | so for the backport if we always emit lowercase pcid then its fine to jsut canonicalise the names in https://review.openstack.org/#/c/563926 | |
| 14:56:55 | kashyap | sean-k-mooney: No, in the backport too we ignore casing. | |
| 14:57:00 | leakypipes | TheJulia: FYI, I'm reviewing the ironic instance_uuid prep_for_spawn() patch. Might take a little while. | |
| 14:57:46 | TheJulia | leakypipes: thanks, no worries :) I just don't want it to fall off radars :) | |
| 14:57:56 | leakypipes | yup, no worries. | |
| 15:01:56 | sean-k-mooney | kashyap: https://github.com/openstack/oslo.config/blob/master/oslo_config/types.py#L160-L164 this should lowercase it for you | |
| 15:02:33 | sean-k-mooney | oh wait no | |
| 15:02:46 | kashyap | Not really | |
| 15:02:49 | kashyap | Something like: | |
| 15:02:50 | kashyap | extra_flags = set([flag.lower() for flag in CONF.libvirt.cpu_model_extra_flags] | |
| 15:02:50 | sean-k-mooney | it returns value not processed_value | |
| 15:04:09 | sean-k-mooney | kashyap: ya that will solve it i was just hopping that the sting value would convert it to the canonical form pecifed in the choices field on your behalf | |
| 15:11:26 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 15:11:27 | openstackgerrit | Chris Dent proposed openstack/nova master: Isolate placement database config https://review.openstack.org/541435 | |
| 15:11:28 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Ensure that os-traits sync is attempted only at start of process https://review.openstack.org/553857 | |
| 15:12:10 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Add PLACEMENT_DB_ENABLED=True to the nova-next job https://review.openstack.org/564067 | |
| 15:21:51 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 15:21:52 | openstackgerrit | Chris Dent proposed openstack/nova master: Isolate placement database config https://review.openstack.org/541435 | |
| 15:21:53 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Ensure that os-traits sync is attempted only at start of process https://review.openstack.org/553857 | |
| 15:22:09 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Add PLACEMENT_DB_ENABLED=True to the nova-next job https://review.openstack.org/564067 | |
| 15:24:23 | openstack | bug 1766301 in OpenStack Compute (nova) "ironic baremetal node ownership not checked with early vif plugging" [Undecided,In progress] https://launchpad.net/bugs/1766301 - Assigned to Julia Kreger (juliaashleykreger) | |
| 15:24:23 | leakypipes | jroll, TheJulia: from bug #1766301's report: "This can be preproduced fairly easily with TripleO and a lack of a resource class defined on the flavor." | |
| 15:24:48 | leakypipes | jroll, TheJulia: from bug #1766301's report: I didn't think we allowed "disabling resource class defined on the flavor" for Ironic? | |
| 15:25:16 | TheJulia | leakypipes: turns out tons of people didn't get the memo that resource classes were required for baremetal | |
| 15:26:26 | leakypipes | TheJulia: the issue I have with the patch is that the solution for this problem (needing an atomic claim of resources) *was* the placement claiming resources for an instance. | |
| 15:26:48 | leakypipes | TheJulia: can this be reproduced *without* "disabling resource classes in flavors"? | |
| 15:27:38 | jgwentworth | when we talked about this last time, it can also happen if other things other than nova are calling ironic API | |
| 15:27:41 | dtantsur | leakypipes: imagine a rare case of nova co-existing with non-nova using ironic | |
| 15:28:00 | dtantsur | (which may not be actually rare) | |
| 15:28:05 | jgwentworth | so it seemed valid to us to go ahead and do the node reserve first | |
| 15:28:43 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Lift the restriction of choices for `cpu_model_extra_flags` https://review.openstack.org/563926 | |
| 15:29:04 | leakypipes | jgwentworth: other than Ironic, what virt driver needs to "reserve a node"? | |
| 15:29:52 | jgwentworth | leakypipes: none, but it doesn't seem unreasonable to offer virt driver "pre-spawn" and "cleanup-pre-spawn". we already did it, we just named it "setup_network_*" instead | |
| 15:30:08 | TheJulia | leakypipes: I think so, just have two consumers of ironic's api try to deploy the same hardware at the same time | |
| 15:30:12 | leakypipes | jgwentworth: for the record, "reserving a node" is precisely what the claim_resources() is doing in the scheduler when Ironic is involved in the request. | |
| 15:30:22 | jgwentworth | I suggested changing the name of the methods to be more generic and just use them for reserve and unreserve | |
| 15:30:27 | kashyap | mriedem: Does that look better: https://review.openstack.org/#/c/563926/8/nova/virt/libvirt/driver.py@3817 | |
| 15:30:49 | kashyap | mriedem: But it won't fix stable branches. | |
| 15:31:18 | kashyap | mriedem: How about sean-k-mooney's idea: Make the "casing normalization" patch on _top_ of the existing change | |
| 15:31:27 | kashyap | So that it can be backported to stable branches too? | |
| 15:32:26 | jgwentworth | leakypipes: yeah, but that won't help if something outside of nova is also using the ironic API, right | |
| 15:32:34 | jgwentworth | which is valid | |
| 15:32:59 | leakypipes | jgwentworth: seems like a poor reason to essentially put in a new locking mechanism into the virt driver API. | |
| 15:34:10 | leakypipes | TheJulia, jgwentworth: why do two consumers of Ironic's API try to deploy the same hardware at the same time? | |
| 15:34:25 | jgwentworth | well, it's not going to be "start locking mechanism" and "release locking mechanism", it should be generic like "pre spawn" "cleanup pre spawn". I thought that's a thing that virt drivers could want to do | |
| 15:35:08 | TheJulia | leakypipes: manual orchestration, disconnected orchestration, single hardware resource pools shared amongst teams using different tooling. | |