| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-09-27 | |||
| 19:18:34 | efried | at least for phase 1 | |
| 19:19:29 | Sundar | For e.g., say the device profile says: { resources:ACCEL_GPU=2; trait:GPU_FOO=required}. Then we would create 2 separate VARs. Each one could contain a copy like: {resources: ACCEL_GPU=1, trait:GPU_FOO=required} | |
| 19:19:39 | Sundar | So, there are 2 VARs, each requesting 1 resource | |
| 19:20:09 | efried | yes, that's as it should be. One VAR, one accelerator. | |
| 19:20:17 | Sundar | That means, the resources/traits go duplicated. Also, the semantics that both resources need to come from the same resource provider is lost from Cyborg's perspective | |
| 19:20:24 | Sundar | *got | |
| 19:20:36 | efried | So | |
| 19:20:53 | efried | I was thinking a device profile would be for *one* device. | |
| 19:20:54 | efried | But | |
| 19:21:17 | efried | then you can't, as you say, demand that two devices come from the same provider | |
| 19:21:28 | efried | or more generally, take advantage of granular syntax. | |
| 19:21:34 | efried | unless | |
| 19:22:02 | Sundar | Yes. Nova would have that info, and presumably can colocate them. But, if VCyborg needs that info to connect the accelerators together, or whatever, that is ruled out | |
| 19:22:03 | efried | we number the extra spec key using the same pattern as we do for the other resources | |
| 19:22:12 | efried | which is actually probably a better, more composable design. | |
| 19:22:18 | Sundar | Yes! | |
| 19:22:24 | Sundar | +1 | |
| 19:22:38 | Sundar | That is the proposal in the spec | |
| 19:22:48 | efried | it is? | |
| 19:23:02 | efried | I got the impression you had set up device profiles so they could contain more than one accelerator | |
| 19:23:29 | Sundar | Yes, I propose to take the device profile fields, cobvert them to extra spec granular syntax and fold them in | |
| 19:23:51 | Sundar | Yes, in the above example, we would convert that to: | |
| 19:24:12 | Sundar | resources2:ACCEL_GPU=2; trait2:GPU_FOO=required | |
| 19:24:49 | Sundar | The only sticking point is who does that numbering. I thought Cyborg or os-acc could do that. But the comments point out that there could be request groups in the flavor unrelated to device profiles or Cybirg | |
| 19:24:59 | Sundar | So, Nova should do the numbering. I am fine with that | |
| 19:25:31 | efried | Yeah, you should ask gibi how he did that for the network bandwidth PoC. Pretty sure he would have done it from the nova thing that parses the extra specs. | |
| 19:26:17 | Sundar | OK. I'll take a look at the spec you cited above, and ask him. | |
| 19:26:21 | Sundar | Thanks! | |
| 19:27:56 | Sundar | efried: This spec seems orthogonal to our needs, Do you have pointers to other specs from him on this topic? | |
| 19:28:06 | efried | Sundar: Here's where I suspect that is getting done: https://github.com/openstack/nova/blob/e658f41d686e4533640b101622f2342348c0316d/nova/scheduler/utils.py#L433 | |
| 19:29:35 | efried | Oh, the spec I cited above has nothing to do with renumbering request groups. That was just acking the fact that you're (probably) going to need a way to map a numbered group in the *request* to some piece of the allocation in the *response*. And placement has no way right now to help you with that - you basically have to reverse-engineer it yourself. | |
| 19:31:28 | efried | Let's say for example that your user wants two accelerators of the same type (say VGPU), doesn't care if they're from the same provider or not, and also wants to associate some other resource with each - let's say VRAM. | |
| 19:31:58 | efried | So the user specifies one dev profile with VGPU=1,VRAM=1024 and another with VGPU=1,VRAM=2048 | |
| 19:32:21 | efried | placement, in its infinite wisdom, decides to satisfy both accelerators from the same provider | |
| 19:32:41 | efried | so you get back an allocation with: VGPU=2,VRAM=3072 | |
| 19:33:17 | efried | And now you have to reverse-engineer that to figure out that you actually wanted one VGPU=1,VRAM=1024 and one VGPU=1,VRAM=2048 | |
| 19:33:46 | efried | Simple example, but add in more device profiles at the same time and/or try to generalize that reverse engineering, and it quickly becomes problematic. | |
| 19:34:03 | efried | That's what gibi proposed his spec for. | |
| 19:34:14 | Sundar | Yea, I got that | |
| 19:34:30 | efried | Because in placement, *while* we're calculating allocation candidates (but not after), we know which request group corresponds to which bit of each allocation request. | |
| 19:34:57 | efried | We just don't carry that information forward to the response, or preserve it internally in any way. | |
| 19:34:58 | Sundar | A related issue is that, if VRAM were not a standard resource, you may say accel:VRAM=2048 or something | |
| 19:35:33 | efried | um, rather not. If it's not a standard resource, it can be CUSTOM_VRAM, but it should still be tracked in placement. | |
| 19:35:51 | Sundar | Now, the accel extra spec has to go with the rest of the request group, for the device to be suitably configured during bind | |
| 19:36:01 | efried | If not, you're setting yourself up for resource contention problems that placement was expressly design to obviate. | |
| 19:37:26 | Sundar | OK, that was not a good example. What if I wnat to assign the GPU to host software like DPDK for cryptography, rather than to a VM? Then the dev prof may say accel:assign-to-host=true | |
| 19:38:43 | Sundar | This is not a trait | |
| 19:38:52 | Sundar | because it is not meant for scheduling, | |
| 19:39:02 | Sundar | only to control how the assignment is done | |
| 19:39:20 | efried | I don't understand that use case. But yeah, traits are another useful way to expose the problem. | |
| 19:40:52 | efried | If I ask for resource1=VGPU:1&required1=CUSTOM_FOO&resource2=VGPU:1, and I get back two allocations from different providers, I need to go figure out (based on traits? or what I already know about the providers?) which VGPU I'm supposed to apply to CUSTOM_FOO. | |
| 19:41:30 | efried | again, it's not sooper hard, but once you generalize it out, you end up essentially having to duplicate a ton of the placement logic. | |
| 19:42:03 | Sundar | Yes | |
| 19:43:48 | Sundar | OK, it still comes down to how gibi solved this problem, I suppose. I'll dig around. | |
| 19:44:04 | efried | *this* problem I don't think gibi solved. | |
| 19:44:08 | efried | He solved the renumbering problem. | |
| 19:44:50 | efried | I believe his PoC behaved quite similarly to what you're proposing - the resources/required gizmos live in the profile (the binding profile? or port? in his case) | |
| 19:45:18 | efried | and then he has to renumber those groups when he folds the profile in with the other flavor stuff. | |
| 19:45:38 | efried | They wrote up a blog post that walked through the PoC, and I think some of that becomes clear in the demo | |
| 19:46:11 | efried | https://rubasov.github.io/2018/09/21/openstack-qos-min-bw-demo.html | |
| 19:47:09 | efried | yeah, search for resource_request in the above doc and you'll see what I'm talking about. | |
| 19:48:02 | efried | each port profile looks like it gets to ask for resources for a single port. (I guess the actual VIF/VNIC resource is implicit? Not sure how that's working.) | |
| 19:48:14 | efried | So the resources/required keys are unnumbered in the port profile. | |
| 19:49:05 | efried | And then (not sure if this is in the doc, but I know it's true because it was in the original spec and I confirmed by asking the question in the room when they did the demo) those get numbered in a non-conflicting way when they get folded into the rest of the request. | |
| 19:55:33 | efried | Sundar: switching screens; ping me if you want to talk more. | |
| #openstack-cyborg - 2018-09-28 | |||
| 07:09:54 | openstackgerrit | YumengBao proposed openstack/os-acc master: Update os-acc doc https://review.openstack.org/604960 | |
| 11:20:32 | openstackgerrit | Xinran WANG proposed openstack/os-acc master: Add a parser to help nova parse the input device spec to cyborg. https://review.openstack.org/606036 | |
| #openstack-cyborg - 2018-09-29 | |||
| 16:17:04 | openstackgerrit | zhulingjie proposed openstack/cyborg-specs master: Update the Placement API link https://review.openstack.org/606603 | |
| #openstack-cyborg - 2018-09-30 | |||
| 02:05:10 | openstackgerrit | YumengBao proposed openstack/os-acc master: Update os-acc doc https://review.openstack.org/604960 | |
| #openstack-cyborg - 2018-10-04 | |||
| 04:55:35 | openstackgerrit | Sundar Nadathur proposed openstack/cyborg-specs master: Specification for device profiles. https://review.openstack.org/602978 | |
| 22:13:15 | openstackgerrit | Sundar Nadathur proposed openstack/cyborg-specs master: Update index with Stein specs. https://review.openstack.org/608095 | |
| #openstack-cyborg - 2018-10-05 | |||
| 00:03:56 | openstackgerrit | Sundar Nadathur proposed openstack/cyborg-specs master: Specification for device profiles. https://review.openstack.org/602978 | |
| 00:07:25 | openstackgerrit | Sundar Nadathur proposed openstack/cyborg-specs master: Specification for Cyborg Nova Placement interaction. https://review.openstack.org/603545 | |
| 02:00:42 | openstackgerrit | Merged openstack/cyborg-specs master: Update index with Stein specs. https://review.openstack.org/608095 | |
| 10:26:09 | openstackgerrit | Sundar Nadathur proposed openstack/cyborg-specs master: Specification for instance operations with accelerators. https://review.openstack.org/605237 | |
| 10:39:49 | openstackgerrit | Sundar Nadathur proposed openstack/cyborg-specs master: Specification for device profiles. https://review.openstack.org/602978 | |
| 10:41:57 | openstackgerrit | Sundar Nadathur proposed openstack/cyborg-specs master: Specification for Cyborg Nova Placement interaction. https://review.openstack.org/603545 | |
| #openstack-cyborg - 2018-10-08 | |||
| 09:54:22 | openstackgerrit | Sundar Nadathur proposed openstack/cyborg-specs master: Specification for Cyborg API workflows for instance operations. https://review.openstack.org/608624 | |
| 10:44:13 | openstackgerrit | YumengBao proposed openstack/cyborg master: Fix installation guide error https://review.openstack.org/608633 | |
| #openstack-cyborg - 2018-10-09 | |||
| 01:29:28 | jiapei | https://www.irccloud.com/pastebin/6rJoAMJz/ | |
| 03:00:07 | openstackgerrit | Nguyen Van Trung proposed openstack/cyborg master: Don't quote {posargs} in tox.ini https://review.openstack.org/608812 | |
| 08:47:28 | openstackgerrit | wangzhh proposed openstack/cyborg master: Add "Report device data to cyborg" https://review.openstack.org/596691 | |
| 08:58:25 | openstackgerrit | YumengBao proposed openstack/cyborg master: Update devstack installation guide https://review.openstack.org/608883 | |
| 12:10:13 | openstackgerrit | wangzhh proposed openstack/cyborg master: Add gpu driver https://review.openstack.org/574075 | |
| 12:12:31 | openstackgerrit | wangzhh proposed openstack/cyborg master: Add gpu driver https://review.openstack.org/574075 | |
| #openstack-cyborg - 2018-10-10 | |||
| 14:06:23 | Li_Liu | FYI, this week's cyborg meeting is on ZOOM | |
| 14:07:12 | Li_Liu | https://zoom.us/j/6637468814 | |
| 14:15:25 | edleafe | I won't be able to join the zoom conference, so please post a summary of any decisions made or questions raised, either here or in a post to the mailing list. | |
| #openstack-cyborg - 2018-10-11 | |||
| 04:00:08 | Sundar | @edleafe: I made a presentation of the suggested Cyborg device/data model, and explained the workflow from the PTG. | |
| 04:00:15 | Sundar | #link https://docs.google.com/presentation/d/1Anud3Qbcb0P3G245HpHduHhslx1MJljGD6wqPDy7o9E/edit?usp=sharing | |
| 04:27:19 | openstackgerrit | Li Liu proposed openstack/cyborg master: Let the fpga programming api call cyborg agent https://review.openstack.org/596507 | |
| 04:32:13 | openstackgerrit | Li Liu proposed openstack/cyborg master: Let the fpga programming api call cyborg agent https://review.openstack.org/596507 | |
| 10:28:49 | openstackgerrit | Xinran WANG proposed openstack/cyborg master: Resource report to placement https://review.openstack.org/601150 | |
| #openstack-cyborg - 2018-10-12 | |||
| 03:28:12 | openstackgerrit | Li Liu proposed openstack/cyborg master: Added Glance Client for Image downloading https://review.openstack.org/609906 | |
| 14:09:14 | openstackgerrit | Chuck Short proposed openstack/os-acc master: Change python3.5 job to python3.7 job on Stein+ https://review.openstack.org/610046 | |
| 14:09:40 | openstackgerrit | Chuck Short proposed openstack/os-acc master: Change python3.5 job to python3.7 job on Stein+ https://review.openstack.org/610046 | |
| #openstack-cyborg - 2018-10-14 | |||
| 04:14:35 | openstackgerrit | Li Liu proposed openstack/cyborg master: Added Glance Client for Image downloading https://review.openstack.org/609906 | |
| #openstack-cyborg - 2018-10-15 | |||
| 15:09:18 | mriedem | i'm not sure if anyone here has put any thought into the upgrade checkers goal https://storyboard.openstack.org/#!/story/2003657 | |
| 15:09:24 | mriedem | there are no upgrade release notes for cyborg | |
| 15:09:41 | mriedem | and with the project being so new, i don't know if it has had anything yet like even config option deprecation/removal | |