Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-15
22:10:24 mriedem ok
22:21:59 mriedem dansmith: if you guys have vgpu people internally besides bauzas that can take a look at this https://bugs.launchpad.net/nova/+bug/1752463
22:22:00 openstack Launchpad bug 1752463 in OpenStack Compute (nova) "Attaching virtual GPU devices to guests in nova" [Medium,Incomplete]
22:26:30 melwitt mriedem, dansmith: so we're agreed to approve https://blueprints.launchpad.net/nova/+spec/libvirt-cpu-model-extra-flags as a bp and we'll backport it, calling out in the backport why we're making an exception and backporting bp work. is that right?
22:26:54 dansmith melwitt: I'm cool with that yeah
22:27:51 dansmith mriedem: maybe, but that seems pretty low priority and can just wait for him to be back right?
22:28:24 mriedem dansmith: sure
22:37:01 melwitt mriedem: are you cool with the cpu model flags bp and the idea of backporting it?
22:37:51 mriedem i'm not crazy about it being a bp if we know we're going to backport it
22:38:04 mriedem i'd rather pretend it's not and say it's a bug fix
22:39:19 mriedem https://review.openstack.org/#/c/534384/5//COMMIT_MSG@28 definitely makes it sound feature-y too though
22:39:30 mriedem "besides the fix, you can also configure nova for other goodies!"
22:39:56 melwitt heh. yeah. this is definitely an odd case
22:40:55 mriedem now, if pcid as the extra flag is the only thing you'd care about if you only care about the fix,
22:41:24 mriedem then this could be a [workarounds] option with a boolean to set pcid or not,
22:41:27 mriedem and backport that
22:41:43 mriedem then the free-form wild west extra flags thing that is more of a feature could only be master
22:41:51 mriedem and we'd deprecate the workaround in master
22:42:00 mriedem dansmith: ^ what do you think about that?
22:44:26 dansmith I dunno, it seems like too much concern over a relatively minor thing
22:44:34 dansmith and I kinda expect that we'll backport the main thing ourselves anywaym
22:44:46 dansmith just so that people with queens and people with rocky don't need a different fix for this
22:44:55 dansmith but if that's how it has to go, then okay
22:46:21 mriedem i'm not the ptl, not my say, but i'd be more comfortable with that
22:46:34 dansmith I guess my point is,
22:46:49 dansmith we're going to backport the meat of the feature anyway, because we need it for the workaround
22:47:07 dansmith and constraining the workaround to one flag doesn't really do anything to make it safer,
22:47:19 dansmith unless the operator is going to just do crazy stuff with it (not sure what that would be even),
22:47:33 mriedem ^ is what i'm worried about, they try the 'other use cases' in stable,
22:47:39 mriedem and are all of a sudden reporting bugs about it
22:47:51 dansmith but if they're going to do that,
22:47:52 dansmith they'll do it with rocky when it's out
22:48:13 dansmith if we have a workaround, then people have to set that to make the thing work, and then when they roll to rocky (or S) and performance regresses for some reason they forgot about,
22:48:31 dansmith there will be bugs where we tell them that that workaround was a one-time deal and now they have to set pcid in this other field
22:48:44 dansmith just seems like it's too much monkeywork so we don't have a blueprint on a backport,
22:48:54 mriedem well, we'd use the workaround if it were set while it's deprecated, but we'd mark it deprecated to drop it later, but you'd have rocky to transition your tooling
22:48:56 dansmith when we can clearly point to not-our-fault reasons why this is needed and not high risk
22:49:15 dansmith yeah, it just doesn't seem worth the pain to me
22:49:50 mriedem precedent is another concern for me here,
22:49:57 mriedem true it's a no-op by default,
22:49:59 cfriesen dansmith: I agree with you, but I also suspect someone is going to try enabling pdpe1gb or vmx on queens.
22:50:08 mriedem but then people could use that justification against us later
22:50:12 dansmith cfriesen: so?
22:50:23 melwitt the workaround idea seems good until we get to the point where people would have to go from workaround -> full feature to not regress performance
22:50:33 cfriesen dansmith: so mriedem's point about it likely causing more bug reports against stable
22:50:49 mriedem melwitt: it's just updating your configs in rocky
22:50:51 dansmith cfriesen: but those bug reports will be against whatever release we allow the full feature in
22:50:54 mriedem to not use the deprecated option
22:51:10 dansmith mriedem: every time we do that it's upgrade pain and it just seems like we have too much of that already
22:51:25 cfriesen dansmith: not necessarily, nested vmx for example is buggy in older systems but may be stable by the time rocky is released
22:51:26 melwitt mriedem: but wouldn't you also have to add "pcid" to your rocky config elsewhere then?
22:51:27 dansmith I get the precedent thing
22:51:42 mriedem melwitt: yes, you'd do it on the new option
22:51:44 dansmith cfriesen: that's a super weak reason :)
22:52:02 dansmith cfriesen: because (a) I don't think it will be and (b) people can already do crazy stuff with lots of options
22:52:24 dansmith cfriesen: you could work around this by just defining your own cpu models in the libvirt system xml, and you can do way crazier stuff to your systems that way
22:52:55 cfriesen dansmith: true enough. for what it's worth, adding pdpe1gb seems to be generally fine.
22:53:06 dansmith heh
22:53:07 cfriesen for the subset of intel hosts I've dealt with anyway
22:54:27 melwitt we can just slap "experimental" on it on the backport, use at your own risk
22:54:45 dansmith it's not experimental but sure :)
22:55:32 dansmith melwitt: I need to be done for the day anyway,
22:55:44 melwitt well, what I mean is if you use it and it breaks something in queens/pike/ocata then we're probably not going to fix things to accommodate the various flags they enable
22:55:47 dansmith so you make the call, my input is all above
22:55:59 dansmith melwitt: it won't be any less experimental later,
22:56:03 dansmith it just lets you choose cpu flags
22:56:15 dansmith it will be just as dangerous in five years if you use it wrong
22:56:42 melwitt okay
23:20:06 openstackgerrit Eric Fried proposed openstack/nova master: Stop assuming initial provider generation is 0 https://review.openstack.org/548975
23:21:04 mriedem yikun: Kevin_Zheng_: replied with my opinion on the limited affinity spec options for how to model the limit in the API https://review.openstack.org/#/c/546925/2/specs/rocky/approved/allow-specifying-limit-for-affrinity-group.rst@49
23:21:45 efried jaypipes, alex_xu_: Trivial pep/tox fixes, ready for re+A --^
23:48:06 alex_xu_ efried: done
#openstack-nova - 2018-03-16
00:43:51 artom_ efried, if you're still around, I didn't want to pollute the mailing list with that's essentially just a "+1", but that update_provider_tree design update that you sent was really nice
00:44:17 artom_ For what it's worth, my opinion is that the precedent that this sets should be valued and repeated
00:47:50 Spaz-Home Morning folks
01:24:34 yikun mriedem, OK, thanks. : )
02:06:35 openstackgerrit Tetsuro Nakamura proposed openstack/nova-specs master: Support shared and dedicated VMs in one host https://review.openstack.org/543805
02:06:35 openstackgerrit Tetsuro Nakamura proposed openstack/nova-specs master: Support shared/dedicated vCPUs in one instance https://review.openstack.org/545734
02:25:38 mriedem 享受工作，朋友。
02:25:39 mriedem o/
02:28:29 Spazmotic Annnnnd morning from the Office.
02:30:49 jianghuaw_ Good morning.
02:31:47 jianghuaw_ Spazmotic, I saw your message on live-migration.
02:32:38 jianghuaw_ that's expected behavior to get the exception when block_migration is False but it's not shared storage.
02:32:59 jianghuaw_ Look this: https://developer.openstack.org/api-ref/compute/
02:33:07 Spazmotic Will do, will take a look soon
02:33:09 jianghuaw_ Set to False means the request will fail when the source and destination hosts are not on the shared storage.
02:33:44 jianghuaw_ Searching "Live-Migrate Server" there:-)
02:34:23 jianghuaw_ the above statement is included in the table of the detail for "Live-Migrate Server (os-migrateLive Action)"
02:37:20 Spazmotic I see... Interesting
02:37:47 Spazmotic I'll keep reading through it more completely so I can understand what it's doing differently then sir
02:37:53 Spazmotic thanks
02:38:34 jianghuaw_ np. you're always welcome:-)
02:52:27 Spazmotic Co workers had me doubting the migrate_data field again and how it gets passed around
02:52:31 Spazmotic Live migrate you too confusing for your own good
04:00:13 openstackgerrit Zhenyu Zheng proposed openstack/nova master: WIP https://review.openstack.org/553288
06:00:05 openstackgerrit Naichuan Sun proposed openstack/nova master: xenapi: Support live migration in pooled multi-nodes environment https://review.openstack.org/489451
06:15:58 openstackgerrit Merged openstack/nova master: placement: generation in provider aggregate APIs https://review.openstack.org/548249
06:19:49 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.openstack.org/548772
06:54:48 eandersson Maybe a silly idea... but would it be possible to hook into metadata changes (at least user initiated)?

Earlier   Later