TripleO on OpenStack
A specification describing the work needed to enable doing TripleO development on OpenStack instances instead of using virsh directly. Change-Id: Idb94f2eb37a59780633fb4428f3b402b3bb6bfca
This commit is contained in:
Ben Nemec
parent
e53f94060c
commit
4f18778c95
|
|
@ -0,0 +1,169 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==========================================
|
||||
QuintupleO - TripleO on OpenStack
|
||||
==========================================
|
||||
|
||||
https://blueprints.launchpad.net/tripleo/+spec/tripleo-on-openstack
|
||||
|
||||
Currently resources such as networking and fake baremetal instances have to
|
||||
be created and managed manually via tools such as virsh. This means that an
|
||||
entirely separate set of tooling needs to be created, even though all of these
|
||||
operations should be doable in OpenStack itself. Rather than continue to
|
||||
iterate on the existing tools, it would be better to enable use of OpenStack
|
||||
directly and be able to use the tools that already exist for it.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Current known blockers to using OpenStack resources for TripleO development:
|
||||
* There is no virtual power driver for either nova-baremetal or ironic
|
||||
that can manage OpenStack instances.
|
||||
|
||||
* In a typical Neutron private network it will not allow things like
|
||||
DHCP traffic, probably due to address spoofing protection.
|
||||
|
||||
* It is not currently possible to PXE boot a Nova instance without using
|
||||
something like iPXE, which is not a workable solution for TripleO
|
||||
because the image is overwritten by the baremetal deployment process.
|
||||
|
||||
* Neutron needs to allow virtual IP use to test TripleO HA functionality.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
* Write a virtual power driver for OpenStack instances. I've already done
|
||||
this for nova-baremetal, but we should focus this work on Ironic since it
|
||||
would be a new feature.
|
||||
|
||||
* Work with the Neutron team to enable subnets without address spoofing (if
|
||||
that is, in fact, the reason DHCP on a private network does not work).
|
||||
|
||||
* Enable PXE booting in Nova. There is already a bug open to track this
|
||||
feature request, but it seems to have been abandoned.
|
||||
https://bugs.launchpad.net/nova/+bug/1183885
|
||||
|
||||
* Possibly related to the previous Neutron point, we need to be able to assign
|
||||
our own virtual IP addresses for our HA support, rather than just use the
|
||||
cloud's floating IP.
|
||||
|
||||
Once the above are all done, we can add instructions to devtest on how to
|
||||
run it against OpenStack instances.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
* There's no real alternative to writing a virtual power driver. We have to
|
||||
be able to manage OpenStack instances as baremetal nodes for this to work.
|
||||
|
||||
* Creating a flat Neutron network connected to a local bridge can address the
|
||||
issues with Neutron not allowing DHCP traffic, but that only works if you
|
||||
have access to create the local bridge and configure the new network. This
|
||||
may not be true in many (all?) public cloud providers.
|
||||
|
||||
* As noted earlier, using an iPXE image can allow PXE booting of Nova
|
||||
instances. However, because that image is overwritten during the deploy,
|
||||
it is not possible to PXE boot the instance afterward. Making the TripleO
|
||||
images bootable on their own might be an option, but it would diverge from
|
||||
how a real baremetal environment would work and thus is probably not
|
||||
desirable.
|
||||
|
||||
* I have not done any work with virtual IP addresses in Neutron yet, so it's
|
||||
unclear to me whether any alternatives exist for that.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
* The virtual power driver is going to need access to OpenStack
|
||||
credentials so it can control the instances.
|
||||
|
||||
* The Neutron changes to allow private networks to behave as flat networks
|
||||
may have security impacts, though I'm not exactly sure what they would be.
|
||||
The same applies to virtual IP support.
|
||||
|
||||
* PXE booting instances could in theory allow an attacker to override the
|
||||
DHCP server and boot arbitrary images, but in order to do that they would
|
||||
already need to have access to the private network being used, so I don't
|
||||
consider this a significant new threat.
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
This is intended as a developer-only feature.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
In my testing, my OpenStack virtual power driver was significantly slower
|
||||
than the existing virsh-based one, but I believe with a better implementation
|
||||
that could be easily solved.
|
||||
|
||||
When running TripleO on a public cloud, a developer would be subject to the
|
||||
usual limitations of shared hardware - a given resource may be oversubscribed
|
||||
and cause performance issues for the processing or disk-heavy operations done
|
||||
by a TripleO deployment.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
This is not intended to be visible to regular deployers, but it should
|
||||
simplify the CI deployment process by allowing use of standard infra tools
|
||||
for managing resources.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
If this becomes the primary method of doing TripleO development, developers
|
||||
would need access to an OpenStack-based cloud for development work. If this
|
||||
is used only in addition to the existing virsh-based environments then
|
||||
developer impact should be minimal.
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
bnemec
|
||||
|
||||
Work Items
|
||||
----------
|
||||
* Work with Ironic team to implement an OpenStack virtual power driver.
|
||||
|
||||
* Work with the Neutron team to enable the networking aspects mentioned above.
|
||||
|
||||
* Work with the Nova team to enable PXE booting of instances.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
This is primarily describing work to be done in other projects, so essentially
|
||||
all of the work items above are the dependencies.
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Hopefully this work will be easier to test in CI thanks to using standard
|
||||
OpenStack tooling.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
devtest will need to be updated to reflect the new setup steps needed to run
|
||||
it against an OpenStack-based environment.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
This is largely based on the discussion Devtest on OpenStack in
|
||||
https://etherpad.openstack.org/p/devtest-env-reqs
|
||||
Loading…
Reference in New Issue