Skip to content

Instantly share code, notes, and snippets.

@kristiandrucker

kristiandrucker/spec.md Secret

Created December 8, 2016 22:09
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kristiandrucker/eaa863f5526c616f7452ca178fd6d241 to your computer and use it in GitHub Desktop.
Save kristiandrucker/eaa863f5526c616f7452ca178fd6d241 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
spec.md

.. This work is licensed under a Creative Commons Attribution 3.0 Unported License.

http://creativecommons.org/licenses/by/3.0/legalcode

========================================== Attached GPU as a main display source

Include the URL of your launchpad blueprint:

none

Some notes about the gpu attaching process:

  • Openstack Administrator will need to create or modify the flavors metadata and add gpu_attach=true to those that have a gpu and need to have the gpu as a main display source

  • The only downside will be that the novnc or any other console inside horizon or provided by libvirt will not work because the display will be rendered on the gpu

Problem description

The problem is when running a gpu instance, the gpu isn't a primary display source and that may affect some applications.

Use Cases

This case addresses directly attaching gpu to a instance as a main display source. There shouldn't be any changes to the end user, but the console will not work.

Proposed change

I propose a litle change in attaching gpu to an openstack instance. If it will be possible to add a flavor metadata like gpu_attach=true and then attach the gpu as a primary display source.

If a person would like to run a gaming or a rendering server that needs the display source to be provided by the gpu, this solution will enable it.

Alternatives

none

Data model impact

There should be small changes to the data model. It's just adding another metadata option and the openstack will modify the config to suite that option to attach gpu as a main display source.

REST API impact

none

Security impact

none

Notifications impact

none

Other end user impact

This feature is just flavor metadata based.

Performance Impact

Describe any potential performance impact on the system, for example how often will new code be called, and is there a major change to the calling pattern of existing code.

Examples of things to consider here include:

  • A periodic task might look like a small addition but if it calls conductor or another service the load is multiplied by the number of nodes in the system.

  • Scheduler filters get called once per host for every instance being created, so any latency they introduce is linear with the size of the system.

  • A small change in a utility function or a commonly used decorator can have a large impacts on performance.

  • Calls which result in a database queries (whether direct or via conductor) can have a profound impact on performance when called in critical sections of the code.

  • Will the change include any locking, and if so what considerations are there on holding the lock?

Other deployer impact

Discuss things that will affect how you deploy and configure OpenStack that have not already been mentioned, such as:

  • What config options are being added? Should they be more generic than proposed (for example a flag that other hypervisor drivers might want to implement as well)? Are the default values ones which will work well in real deployments?

  • Is this a change that takes immediate effect after its merged, or is it something that has to be explicitly enabled?

  • If this change is a new binary, how would it be deployed?

  • Please state anything that those doing continuous deployment, or those upgrading from the previous release, need to be aware of. Also describe any plans to deprecate configuration values or features. For example, if we change the directory name that instances are stored in, how do we handle instance directories created before the change landed? Do we move them? Do we have a special case in the code? Do we assume that the operator will recreate all the instances in their cloud?

Developer impact

Discuss things that will affect other developers working on OpenStack, such as:

  • If the blueprint proposes a change to the driver API, discussion of how other hypervisors would implement the feature is required.

Implementation

Assignee(s)

Who is leading the writing of the code? Or is this a blueprint where you're throwing it out there to see who picks it up?

If more than one person is working on the implementation, please designate the primary author and contact.

Primary assignee: none

Other contributors: none

Work Items

none

Dependencies

none

Testing

Testing should be done on gaming or professional graphics cards, running games, realtime rendering, 3D Modeling, anything that requires a gpu.

Documentation Impact

This change will have impact on this page http://docs.openstack.org/admin-guide/compute-pci-passthrough.html, by adding an optional section with the metadata setting the gpu as a main display.

References

Gaming on EC2 on a GPU instance: http://lg.io/2015/07/05/revised-and-much-faster-run-your-own-highend-cloud-gaming-service-on-ec2.html

History

    • Pika
    • Introduced
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment