Re: [OpenStack-Infra] [nova][CI] GPUs in the gate
On Tue, 2019-05-07 at 13:47 -0400, Artom Lifshitz wrote: > Hey all, > > Following up on the CI session during the PTG [1], I wanted to get the > ball rolling on getting GPU hardware into the gate somehow. Initially > the plan was to do it through OpenLab and by convincing NVIDIA to > donate the cards, but after a conversation with Sean McGinnis it > appears Infra have access to machines with GPUs. > > From Nova's POV, the requirements are: > * The machines with GPUs should probably be Ironic baremetal nodes and > not VMs [*]. > * The GPUs need to support virtualization. It's hard to get a > comprehensive list of GPUs that do, but Nova's own docs [2] mention > two: Intel cards with GVT [3] and NVIDIA GRID [4]. Intel cards is a misnomer GVT is currently only supported by the integrated gpu on intel cpus which was removed form xeon cpus when GVT support was added. in the future with the descrete gpus from intel slated for release sometime in 2020 we should hopefully have intel cards that actully support GVT assuming that is on there gpu product roadmap but i can see how it would not be given they developed the tech for there integrated gpu. it would also be intersting to test amd gpus using there sriov approach but i think NVIDA tesla gpus would be the shortest path forword. > > So I think at this point the question is whether Infra can support > those reqs. If yes, we can start concrete steps towards getting those > machines used by a CI job. If not, we'll fall back to OpenLab and try > to get them hardware. > > [*] Could we do double-passthrough? Could the card be passed through > to the L1 guest via the PCI passthrough mechanism, and then into the > L2 guest via the mdev mechanism? i have a theory about how this "migth" be possible but openstack is missing the features requried to pull it off. i may test it locally with libvirt but the only why i think this could work would be to do a full passthough of the PF to an l1 guest using the q35 chipset with a viommu(not supported in nova) with hypervior hiding enabled and then run the grid driver in the l1 guest to expose a mdev to the l2 guest. ironic would be much simpler > > [1] https://etherpad.openstack.org/p/nova-ptg-train-ci > [2] https://docs.openstack.org/nova/rocky/admin/virtual-gpu.html > [3] https://01.org/igvt-g > [4] https://docs.nvidia.com/grid/5.0/pdf/grid-vgpu-user-guide.pdf > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] Feedback on git/repos on opendev.org
Hi, (please reply-all if you want me to see it - I am not subscribed to this list) I was heading to read the code for the kata zuul tenant, and had some niggles when trying to locate/navigate. I thought I'd at least drop the feedback here (thanks ttx). Some of it will be specific to my 'flow' Sooo, as I don't store the path to the repos in my head, I normally start out by going to git.openstack.org: That used to get me to (iirc) the top level cgit type interface, where I could then navigate down to the kata repos. It now takes me to the top level of opendev.org, but not to the git area, and it is not immediately obvious to me where the git area is. I found the git area under 'Explore' :-). The 'search' is a bit odd. It took me a moment to work out that it is alphabetical, if you ignore all the subdir prefix's (project names?). I'm not sure that is the most useful sort order tbh? Confused me for some time. And then, if you search for 'kata' in the default search box, you get **no matching repos**. Which, also, is not quite what I'd expect. Eventually I found the kata repos by sorting reverse-alphabetically and scrolling down :-) I know, the search is on 'repos', and not 'organisations' - but, if you just land on that page and search for something that happens to only have its name active at the project level (like kata), then you end up with no results. Maybe the search/results can be smarter, and provide the list of what it was searching for first (so in this case 'no repositories found'), and then some 'suggestions', like 'you may have been looking for organisation: kata'. Just thinking out loud. Thanks, Graham - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Feedback on git/repos on opendev.org
On Tue, May 14, 2019, at 11:18 AM, Whaley, Graham wrote: > Hi, > (please reply-all if you want me to see it - I am not subscribed to this > list) > > I was heading to read the code for the kata zuul tenant, and had some > niggles when trying to locate/navigate. I thought I'd at least drop the > feedback here (thanks ttx). Some of it will be specific to my 'flow' > > Sooo, as I don't store the path to the repos in my head, I normally > start out by going to git.openstack.org: > That used to get me to (iirc) the top level cgit type interface, where > I could then navigate down to the kata repos. It now takes me to the > top level of opendev.org, but not to the git area, and it is not > immediately obvious to me where the git area is. The old hosting system was cgit and we've moved to gitea as it renders code more nicely (for example can link to sections of code) and renders markdown and rst nicely. One thing we can probably do is redirect top level https://git.foo.org/ urls to https://opendev.org/explore so that you don't have to discover that tab yourself. > > I found the git area under 'Explore' :-). The 'search' is a bit odd. It > took me a moment to work out that it is alphabetical, if you ignore all > the subdir prefix's (project names?). I'm not sure that is the most > useful sort order tbh? Confused me for some time. > And then, if you search for 'kata' in the default search box, you get > **no matching repos**. Which, also, is not quite what I'd expect. Note that you can select among a number of sort orders. > > Eventually I found the kata repos by sorting reverse-alphabetically and > scrolling down :-) I know, the search is on 'repos', and not > 'organisations' - but, if you just land on that page and search for > something that happens to only have its name active at the project > level (like kata), then you end up with no results. Maybe the > search/results can be smarter, and provide the list of what it was > searching for first (so in this case 'no repositories found'), and then > some 'suggestions', like 'you may have been looking for organisation: > kata'. Just thinking out loud. Yup, I think gitea expects users to select the organizations tab and search on that if they are looking for an org and not a repo. However, I agree that the distinction is often confusing as a repo is fully qualified by both organization and repo name. I think this feedback is worth taking to gitea. We'll be happy to do that for you unless you would like to report it upstream. Let us know. (I think https://github.com/go-gitea/gitea/issues is the best venue for that) > > Thanks, > Graham > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] 2019 Denver Summit/Forum/PTG Recap
On 2019-05-13 13:49:44 -0400 (-0400), Clark Boylan wrote: [...] > we discussed if OpenDev would be an appropriate location for > throwaway repos and unfortunately we don't think we are there yet. > Gerrit currently won't scale to that use case for us. [...] Thinking about this a little more, what if we allowed personal sandboxes in Gerrit and just didn't wrap them in all the other replication, CI and general formality we do for normal repositories? Gerrit will allow you to grant access to paths with "$user" in them[*], of which WMF's[**] and some other deployments take advantage to that end. [*] https://gerrit-review.googlesource.com/Documentation/access-control.html#_project_access_control_lists [**] https://www.mediawiki.org/wiki/Gerrit/personal_sandbox -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] 2019 Denver Summit/Forum/PTG Recap
On Tue, May 14, 2019, at 11:41 AM, Jeremy Stanley wrote: > On 2019-05-13 13:49:44 -0400 (-0400), Clark Boylan wrote: > [...] > > we discussed if OpenDev would be an appropriate location for > > throwaway repos and unfortunately we don't think we are there yet. > > Gerrit currently won't scale to that use case for us. > [...] > > Thinking about this a little more, what if we allowed personal > sandboxes in Gerrit and just didn't wrap them in all the other > replication, CI and general formality we do for normal repositories? > Gerrit will allow you to grant access to paths with "$user" in > them[*], of which WMF's[**] and some other deployments take > advantage to that end. These are ref paths not repo paths. Are you thinking every user could have a single scratch space repo then have arbitrary refs within that repo? > > [*] > https://gerrit-review.googlesource.com/Documentation/access-control.html#_project_access_control_lists > [**] https://www.mediawiki.org/wiki/Gerrit/personal_sandbox > -- > Jeremy Stanley ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] 2019 Denver Summit/Forum/PTG Recap
On 2019-05-14 14:23:51 -0700 (-0700), Clark Boylan wrote: > On Tue, May 14, 2019, at 11:41 AM, Jeremy Stanley wrote: > > On 2019-05-13 13:49:44 -0400 (-0400), Clark Boylan wrote: > > [...] > > > we discussed if OpenDev would be an appropriate location for > > > throwaway repos and unfortunately we don't think we are there yet. > > > Gerrit currently won't scale to that use case for us. > > [...] > > > > Thinking about this a little more, what if we allowed personal > > sandboxes in Gerrit and just didn't wrap them in all the other > > replication, CI and general formality we do for normal repositories? > > Gerrit will allow you to grant access to paths with "$user" in > > them[*], of which WMF's[**] and some other deployments take > > advantage to that end. > > These are ref paths not repo paths. Are you thinking every user > could have a single scratch space repo then have arbitrary refs > within that repo? [...] It looks like the way they're doing it is granting users the ability to create (via push) their own personal branches in a common Git repository... so not quite the solution to throwaway repositories, more like user-namespaced throwaway branches in a single existing repository (e.g. opendev/sandbox). -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
