| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-29 | |||
| 13:41:25 | alex_xu_ | dansmith: what's different with cyborg cache manager... | |
| 13:41:33 | jaypipes | and frankly, that's what I *thought* the agreement was in Dublin, but granted, I only made the tail end of the discussion. | |
| 13:41:34 | dansmith | I don't think that programming in a dynamic device needs to be resource class | |
| 13:41:46 | dansmith | jaypipes: same | |
| 13:42:04 | dansmith | alex_xu_: it's not, as I said above in the earlier example | |
| 13:42:58 | jaypipes | dansmith: it *could* be done via a custom resource class, but then again, I find a nice simplicity in just having a standard resource class called FPGA_CONTEXT (or something like that) and decorating those pre-programmed slots (providers) with particular traits | |
| 13:43:10 | dansmith | sure it could, I said "need" | |
| 13:43:11 | efried | edleafe: The RC-vs-trait discussion is a tangent. The issue is whether/when it's okay to modify RPs "on the fly". And how on-the-fly is "on the fly"? | |
| 13:43:23 | dansmith | jaypipes: it needs to be class per type of device, but yeah | |
| 13:43:49 | edleafe | efried: I don't agree it's a tangent. If you model your resources correctly, the whole discussion goes away | |
| 13:44:05 | dansmith | efried: if you have a preferred trait of HAS_SSL, you get one without it, you claim it in scheduling, it's cool IMHO for cyborg to trait it up when it does the programming | |
| 13:44:26 | alex_xu_ | dansmith: I must misunderstand this words "it's not great, and it could certainly be abused past my tolerance level," It means yes... or no.. | |
| 13:44:51 | efried | dansmith: That would be cool. jaypipes are you on board with that? | |
| 13:44:51 | dansmith | alex_xu_: that was referring to people doing other things, not this | |
| 13:45:39 | jaypipes | I'm cool with what dansmith just said, yes. | |
| 13:45:41 | edleafe | dansmith: that's a totally legit use case | |
| 13:45:48 | jaypipes | here are the things I do *not* want to see: | |
| 13:46:04 | jaypipes | 1) agents, including the virt driver, using the traits API as a servicegroup/status API. | |
| 13:46:05 | dansmith | alex_xu_: sorry I see why that was confusing I mixed that into other thoughts when I re-read | |
| 13:46:21 | jaypipes | 2) *Consumer requests* causing traits to be set against a provider. | |
| 13:47:04 | dansmith | jaypipes: 2 meaning something like nova setting traits on providers of has-instances or has-10-instances, or something like that yeah? | |
| 13:47:26 | dansmith | or has-some-volumes-attached-to-host-right-now-yo | |
| 13:47:55 | mriedem | bottom 6 patches in the placement-req-filter series have a +2 https://review.openstack.org/#/c/544730/ | |
| 13:47:57 | jaypipes | It is that latter point that I am afraid of, since it means we essentially throw out all the scheduling heuristics that are now made in placement (since we would no longer be able to filter on providers having a trait but would need to add some mechanism to detect providers that *could have* a trait on them, if certain conditions apply) | |
| 13:48:08 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes Multiple GPU types https://review.openstack.org/557065 | |
| 13:48:08 | efried | jaypipes: #2 is a bit sticky, though, innit? The consumer requests an instance with FPGA with function X, cyborg finds a previously-unfettered device suitable for use and flashes it with function X, then sets a trait saying it's got function X on it now. Is that "consumer requests causing traits to be set"? | |
| 13:48:12 | dansmith | jaypipes: yup | |
| 13:48:29 | dansmith | efried: it has given that device capability | |
| 13:48:48 | bauzas | jaypipes: dansmith: very simple spec about providing a config option for defining a list of pGPUs a specific type would be supported https://review.openstack.org/557065 | |
| 13:48:51 | dansmith | it has changed the device in some meaningful way that means it can do things | |
| 13:48:58 | efried | dansmith: tbc, *I* am fine with that scenario. I'm asking if it violates jaypipes' #2 | |
| 13:49:12 | jaypipes | efried: it would, yes. | |
| 13:49:16 | bauzas | dansmith: jaypipes: if you can review it quickly, that would unblock me from using n-r-p for libvirt vGPUs | |
| 13:49:27 | dansmith | jaypipes: o.O | |
| 13:50:02 | bauzas | mriedem: dansmith: I'll sponsor https://review.openstack.org/#/c/544730/ and above | |
| 13:50:14 | dansmith | jaypipes: now I'm confused :) | |
| 13:50:16 | jaypipes | efried: if cyborg configures its inventory/traits dynamically *at the time and due to a specific request from a consumer*, I have an issue with that | |
| 13:50:35 | dansmith | jaypipes: heh, that's what you just said you were okay with | |
| 13:50:45 | mriedem | alex_xu_: interesting idea to deprecate the backup API in https://review.openstack.org/#/c/511825/ - you should probably start a ML thread on that if you want wider input | |
| 13:50:46 | jaypipes | dansmith: it's a difference in timing. | |
| 13:51:06 | dansmith | jaypipes: no, I said above "sets the trait when programming" | |
| 13:51:19 | alex_xu_ | mriedem: will do that later | |
| 13:51:22 | jaypipes | dansmith: when is the programming done. | |
| 13:51:44 | jaypipes | dansmith: that was a question, sorry.. when is the programming of the slots done? | |
| 13:52:03 | jaypipes | dansmith: if it's done after GET /allocation_candidates, then that won't work. | |
| 13:52:13 | dansmith | jaypipes: sure it will | |
| 13:52:23 | jaypipes | dansmith: since clearly the trait won't be useful in filtering out destination providers. | |
| 13:52:29 | alex_xu_ | jaypipes: dansmith note, for programmable fpga, it inventory always 1 | |
| 13:52:32 | dansmith | jaypipes: it would be preferred | |
| 13:52:56 | alex_xu_ | there is no race like we tweak traits in the fly for gpu | |
| 13:53:07 | dansmith | jaypipes: hangout? | |
| 13:53:11 | jaypipes | dansmith: sdure | |
| 13:53:12 | jaypipes | sure | |
| 13:53:20 | jaypipes | set it up. I will coffee up. | |
| 13:53:35 | jaypipes | let me grab a pug for emotional support. | |
| 13:53:39 | dansmith | https://hangouts.google.com/call/vBep88lVuQCIThVzSqUZAAEE | |
| 13:54:06 | mriedem | powervm interface attach/detach bp patch needs another +2 https://review.openstack.org/#/c/546813/ | |
| 13:54:15 | dansmith | e'yone's invited of course | |
| 13:56:43 | openstackgerrit | Claudiu Belu proposed openstack/nova master: tests: autospecs all the mock.patch usages https://review.openstack.org/470775 | |
| 13:59:06 | bauzas | dansmith: just for sanity, left some comments on https://review.openstack.org/#/c/544730/16 but +W'd it | |
| 14:10:26 | openstackgerrit | Claudiu Belu proposed openstack/nova master: tests: autospecs all the mock.patch usages https://review.openstack.org/470775 | |
| 14:10:27 | openstackgerrit | Claudiu Belu proposed openstack/nova master: WIP: replace spec with autospec https://review.openstack.org/557299 | |
| 14:11:28 | mriedem | bhagyashris: at least one more update in here i think https://review.openstack.org/#/c/511825/ | |
| 14:17:26 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Fix bad management of _TRAITS_SYNCED flag https://review.openstack.org/557722 | |
| 14:17:33 | cdent | mriedem: that ^ fixes it in my tests | |
| 14:18:34 | mriedem | let's recheck it a few times | |
| 14:20:02 | bhagyashris | mriedem: ok thank you for review. you mean to depricate the create backup api and newly introduce deleteBackup api will delete the backup using the rotation parameter | |
| 14:21:16 | mriedem | claudiub: can you update this quick? https://review.openstack.org/#/c/557377/ | |
| 14:21:46 | mriedem | bhagyashris: no, the alternative is to simply deprecate the createBackup API, and not introduce a new deleteBackups API | |
| 14:22:07 | mriedem | since createBackup can all be done using orchestration of existing nova/glance APIs | |
| 14:22:33 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Filter resource providers by forbidden traits in db https://review.openstack.org/556472 | |
| 14:22:34 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Filter allocation candidates by forbidden traits in db https://review.openstack.org/556660 | |
| 14:22:34 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Parse forbidden traits in query strings https://review.openstack.org/556819 | |
| 14:22:35 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Support forbidden traits in API https://review.openstack.org/556820 | |
| 14:24:15 | jaypipes | mriedem: amen, brother. | |
| 14:25:01 | mriedem | makes me curious when/why createBackup was added | |
| 14:25:12 | mriedem | but was likely so long ago that any blueprint for it has little to no detail | |
| 14:25:22 | jaypipes | mriedem: correct. | |
| 14:26:00 | openstackgerrit | Claudiu Belu proposed openstack/nova master: vmware: Fixes _detach_instance_volumes method https://review.openstack.org/557377 | |
| 14:27:15 | bhagyashris | mriedem: ok i am not getting this: cleanup the backups using a rotation value controlled client-side | |
| 14:27:49 | mriedem | bhagyashris: createBackup can be totally done using existing compute and image APIs today, without the actual createBackup API, | |
| 14:28:02 | mriedem | i can snapshot an instance with specific metadata to indicate it's a backup | |
| 14:28:12 | dansmith | alex_xu_: if that "what are you saying" was a joke, that was excellent :P | |
| 14:28:16 | mriedem | and then i can, as a tenant user, delete older backup snapshots in glance | |
| 14:28:57 | mriedem | bhagyashris: my point being, you as the tenant (or script, or external service, whatever) can do all of the createBackup stuff without the compute API (nova) doing it for you | |
| 14:29:17 | alex_xu_ | dansmith: I'm good at pretend to not understand what you guys saying | |
| 14:29:24 | dansmith | haha | |
| 14:29:35 | bauzas | dansmith: again, one comment on https://review.openstack.org/#/c/544729/16 but not holding me to +W | |
| 14:29:53 | bauzas | dansmith: tl;dr: I guess we're talking of aggregate UUIDs, not names | |
| 14:30:11 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Support forbidden traits in API https://review.openstack.org/556820 | |
| 14:30:37 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Allow scheduling only to enabled cells (Filter Scheduler) https://review.openstack.org/550527 | |
| 14:30:38 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Add --enable and --disable options to nova-manage update_cell https://review.openstack.org/555416 | |
| 14:30:38 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Update the cells FAQs and scheduler maintenance docs. https://review.openstack.org/556459 | |
| 14:30:59 | mriedem | bauzas: good point | |
| 14:31:17 | bauzas | I don't want to throw the whole series | |
| 14:31:23 | bauzas | since the code will still work | |
| 14:31:31 | bauzas | at least until that point | |
| 14:31:36 | mriedem | if we wanted to use a ListOfUUIDsField, we'd want to do that now | |
| 14:31:45 | dansmith | bauzas: list of uuids is not enough | |
| 14:31:48 | bauzas | mriedem: not really | |