Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-02-01
14:31:29 lyarwood mdbooth: sure, I'll rebase and push this along.
14:32:05 mdbooth lyarwood: Thanks!
14:33:54 mriedem bauzas: can you hit this as stable core? v
14:33:54 mriedem https://review.openstack.org/#/c/632720/
14:34:07 bauzas mriedem: of course yeah
14:42:00 openstackgerrit Eric Fried proposed openstack/os-resource-classes master: Add normalize_name utility https://review.openstack.org/634258
14:43:08 rha Hello. Anybody here, who's willing to do a review on: https://review.openstack.org/#/c/420026/ ? It should be rather straightforward I hope,
14:50:14 dansmith mriedem: I hadn't saved my comments on that serial number patch, so I just did and see that a new rev was postd
14:50:44 dansmith mriedem: I -1d the new one because I don't think we really should or need to deprecate that thing, but I'm not going to die on that hill
14:52:05 sean-k-mooney dansmith: Zhenyu Zheng send an email this morning saying he would push a new version following the discusssion on the ml thread
14:52:24 dansmith sean-k-mooney: you mean the new rev I mention above/
14:52:48 sean-k-mooney dansmith: i havent looked but i assume so
14:55:46 sean-k-mooney this is the mail i was refering too http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002285.html what would be your preference? keep the config option undeprecated
14:56:03 dansmith sean-k-mooney: that's what I just said, yes :)
14:56:40 sean-k-mooney well what i should of asked is that long term or just for stien
14:57:07 dansmith I don't think there's any reason to deprecate it at all
14:57:22 dansmith there's a potential use for it, it's not blocking other things, nor is it a large maintenance burden, etc
14:58:42 sean-k-mooney it is exposing host info to the guest in a non obficated way.
14:59:26 dansmith it is, which is a good reason to default it to unique, but it's not useful data.. meaning the only thing you could really use it for is to determine if two instances are on the same host
14:59:31 dansmith which you can already do
14:59:36 sean-k-mooney i dont really care i guess one way or another if there is a config but i do think it would be nice to have uniqe id be the default
14:59:43 dansmith agree
15:07:49 mriedem the point of the flavor extra spec and image property were for users that really needed the unique serial to be able to get that regardless of the underlying config, which most operators likely don't even know this exists. in a public cloud, the flavor/image are probably controlled by the operator anyway, so having said that, if you don't have the spec/image property, you could still control this with aggregates if needed, i.
15:07:50 mriedem efault unique everywhere, restrict via aggregate to hosts configured with host serial
15:07:52 mriedem if needed
15:09:02 mriedem and i think we've come full circle now because i think when this originally came up in a nova meeting as a specless blueprint, the idea was just a new config option choice
15:10:00 mriedem http://eavesdrop.openstack.org/meetings/nova/2018/nova.2018-10-18-14.00.log.html#l-199
15:30:06 mnaser dansmith: fyi the difference between the way hostId exposes things is that it hashes with a tenant_id so a tenant cant know its if on a box with another tenant
15:30:25 dansmith mnaser: yeah I know
15:30:33 mnaser the one exposed via the serial is not hashed, so technically i could keep retrying and spawn a vm on the same host knowingly
15:30:37 mnaser ok cool :)
15:30:49 dansmith yeah, but you also can't use that value anywhere in the api
15:31:00 dansmith I totes think it should be defaulted to unique
15:31:25 sean-k-mooney dansmith: im not sure about that but i dont want to specalate publicly
15:31:28 mnaser ++ i guess you just want to retain the ability to keep that old behaviour if a deployer wants to be
15:31:40 dansmith yes
15:31:46 dansmith because there's really no reason to just remove it
15:34:26 mriedem sean-k-mooney: couple small comments in https://review.openstack.org/#/c/626381/
15:35:45 sean-k-mooney mriedem: just on a call but ill respin shortly
15:43:44 mriedem stephenfin: alex_xu said he can take over https://blueprints.launchpad.net/nova/+spec/remove-force-flag-from-live-migrate-and-evacuate when he's back in a week so i'm just going to assign it to him
15:45:49 sean-k-mooney mriedem: i think he is currently flying to fosdem but ill let him know
15:47:17 openstackgerrit Elod Illes proposed openstack/nova stable/queens: Fix incompatible version handling in BuildRequest https://review.openstack.org/634439
15:48:39 mriedem zzzeek: thanks for https://bugs.launchpad.net/oslo.db/+bug/1814199 i can confirm with your patch to oslo.db that the SAWarning is gone from nova unit test runs on py35
15:48:40 openstack Launchpad bug 1814199 in oslo.db "soft_delete is wrong" [Undecided,New]
15:48:48 mriedem at least the one i recreated the with
15:49:05 mriedem isn't that oslo.db bug just a duplicate of https://bugs.launchpad.net/oslo.db/+bug/1814182 though? do we need both bugs?
15:49:06 openstack Launchpad bug 1814182 in oslo.db "SAWarning: Evaluating non-mapped column expression 'id' onto ORM instances; this is a deprecated use case. Please make use of the actual mapped columns in ORM-evaluated UPDATE / DELETE expressions." [Medium,Confirmed]
15:50:07 mriedem Oh I guess maybe you meant to use bug 1814182 as a workaround to pass in synchronize_session=False to soft_delete()?
15:50:08 openstack bug 1814182 in oslo.db "SAWarning: Evaluating non-mapped column expression 'id' onto ORM instances; this is a deprecated use case. Please make use of the actual mapped columns in ORM-evaluated UPDATE / DELETE expressions." [Medium,Confirmed] https://launchpad.net/bugs/1814182
16:02:43 openstackgerrit sean mooney proposed openstack/nova master: PCI: do not force remove allocated devices https://review.openstack.org/626381
16:15:24 openstackgerrit sean mooney proposed openstack/nova master: Libvirt: do not set mac when unplugging macvtap vf https://review.openstack.org/624842
16:15:25 openstackgerrit sean mooney proposed openstack/nova master: Add free for claimed, allocated devices https://review.openstack.org/616120
16:15:25 openstackgerrit sean mooney proposed openstack/nova master: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365
16:15:26 openstackgerrit sean mooney proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929
16:15:26 openstackgerrit sean mooney proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115
16:15:27 openstackgerrit sean mooney proposed openstack/nova master: libvirt: auto detach/attach sriov ports on migration https://review.openstack.org/629589
16:21:28 openstackgerrit sean mooney proposed openstack/nova master: libvirt: auto detach/attach sriov ports on migration https://review.openstack.org/629589
16:40:42 mriedem sean-k-mooney: i think you've got a pep8 error in that pci fix
16:41:23 openstackgerrit Matt Riedemann proposed openstack/nova master: Ignore SAWarnings for "Evaluating non-mapped column expression" https://review.openstack.org/634450
16:41:24 mriedem ^ should help with the subunit parser gate failures
16:46:39 openstackgerrit Matt Riedemann proposed openstack/nova master: Ignore sqla-migrate inspect.getargspec deprecation warnings https://review.openstack.org/634451
16:46:40 mriedem and this ^
16:58:04 openstackgerrit sean mooney proposed openstack/nova master: PCI: do not force remove allocated devices https://review.openstack.org/626381
16:58:32 sean-k-mooney mriedem: fixed. i added the comment after i ran pep8 locally
17:14:54 openstackgerrit Matt Riedemann proposed openstack/nova master: Share snapshot image membership with instance owner https://review.openstack.org/630769
18:00:39 openstackgerrit Hang Yang proposed openstack/nova stable/queens: Fix port dns_name reset https://review.openstack.org/633807
18:20:05 jroll mriedem | jroll: is https://blueprints.launchpad.net/nova/+spec/ironic-conductor-groups going to happen in stein or get deferred to train? <- I've been away all year but back monday, I should be able to knock it out in the next couple weeks
18:21:15 sean-k-mooney jroll: well it was approved
18:22:03 sean-k-mooney in theory the inial implematnion should already be available at this point but if one was ready for review shortly it might be possible
18:22:31 sean-k-mooney jroll: the real question would be how long do you think it would take to get something ready for a runway
18:22:36 jroll sean-k-mooney: I'm saying I can write the code in the next couple weeks, it's fairly trivial
18:23:11 sean-k-mooney well code freeze is march 7th
18:23:16 sean-k-mooney so you have at most 4
18:23:20 jroll I understand
18:23:22 jroll couple == 2
18:24:13 jroll I'm just saying what I can reasonably do, cores will have to decide if we should defer now or play it by ear :)
18:24:18 sean-k-mooney yes :) i was not sure if you were bing literal. but if it was ready for a runway slot in 2 weeks it would be tight but maybe
18:25:49 jroll indeed
18:25:50 sean-k-mooney jroll: i remember this being talk about breifly but honestly dont recall how bg the chagne is. reading it now it does seam quite small
18:27:59 sean-k-mooney this looks like a scalign feature i assuem it sone packet and cern would be interested in
18:29:14 sean-k-mooney jroll: the trickest bit might actully be getting the mutablity of the config option correct
18:31:31 jroll yep, that's for working jroll to figure out next week :)
18:58:39 mriedem pants-free jroll needs to go back to what he was doing
19:00:06 mriedem jaypipes: dansmith: efried: you want to slap these through so we can hopefully merge some code https://review.openstack.org/#/q/topic:bug/1814199+(status:open+OR+status:merged)
19:00:46 efried ...
19:01:01 mriedem http://status.openstack.org/elastic-recheck/#1813147
19:01:17 mriedem don't let the drop off in that graph distract you, ES is busted
19:02:38 fried_rice mriedem: So where's the patch that depends-on the oslo.db one that reverts this?
19:02:50 mriedem there isn't one
19:02:55 mriedem feel free
19:03:02 mriedem i have https://review.openstack.org/#/c/634455/
19:03:09 mriedem but that would have to be released anyway
19:03:56 fried_rice mm
19:04:12 fried_rice +A
19:04:32 mriedem thanks
19:33:38 mriedem fried_rice: a few questions in https://review.openstack.org/#/c/615705/
19:33:49 fried_rice ...
19:40:44 fried_rice mriedem: responded.
19:45:36 mriedem replied and approved
19:45:43 mriedem apparently my eyes don't work

Earlier   Later