diff --git a/doc/source/index.rst b/doc/source/index.rst index b70a7e8c..a9e55e7f 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -7,13 +7,15 @@ OpenStack Ironic Project Plans Priorities ========== -During each design summit, we agree what the whole community wants to focus -on for the upcoming release. This is the output of those discussions: +During each PTG (before Pike - each design summit), we agree what the whole +community wants to focus on for the upcoming release. This is the output of +those discussions: .. toctree:: :glob: :maxdepth: 1 + priorities/pike-priorities priorities/ocata-priorities priorities/newton-priorities priorities/mitaka-priorities diff --git a/priorities/pike-priorities.rst b/priorities/pike-priorities.rst new file mode 100644 index 00000000..070a8cd8 --- /dev/null +++ b/priorities/pike-priorities.rst @@ -0,0 +1,240 @@ +.. _pike-priorities: + +======================= +Pike Project Priorities +======================= + +This is a list of development priorities the Ironic team is prioritizing for +Pike development, in order of priority. The primary contact(s) listed +is/are responsible for tracking the status of that work and herding cats +to help get that work done. They are not the only contributor(s) to this work! +The number of primary contacts is limited to 2 maximum to simplify +communication. We expect at least one of them to have core privileges +to simplify getting changes in. + +Essential Priorities +~~~~~~~~~~~~~~~~~~~~ + ++---------------------------------------+-------------------------------------+ +| Priority | Primary Contacts | ++=======================================+=====================================+ +| `Standalone CI tests`_ | vsaienk0 | ++---------------------------------------+-------------------------------------+ +| `Generic boot-from-volume`_ | TheJulia, dtantsur | ++---------------------------------------+-------------------------------------+ +| `Rolling upgrades`_ | rloo, jlvillal | ++---------------------------------------+-------------------------------------+ +| `Reference architecture guide`_ | jroll | ++---------------------------------------+-------------------------------------+ +| Python 3.5 compatibility | JayF, hurricanerix | ++---------------------------------------+-------------------------------------+ +| Deploying with Apache and WSGI in CI | vsaienk0 | ++---------------------------------------+-------------------------------------+ +| `Driver composition`_ | jroll, dtantsur | ++---------------------------------------+-------------------------------------+ +| `Feature parity between two CLIs`_ | rloo, dtantsur | ++---------------------------------------+-------------------------------------+ +| `OSC default API version change`_ | mariojv, dtantsur | ++---------------------------------------+-------------------------------------+ +| `Rescue mode`_ | mariojv, JayF | ++---------------------------------------+-------------------------------------+ +| Finish node tags | zhenguo, dtantsur | ++---------------------------------------+-------------------------------------+ + +High Priorities +~~~~~~~~~~~~~~~ + ++---------------------------------------+-------------------------------------+ +| Priority | Primary Contacts | ++=======================================+=====================================+ +| `Specific fault support`_ | JayF, mariojv | ++---------------------------------------+-------------------------------------+ +| `Post-deploy VIF attach/detach`_ | sambetts, vsaienk0 | ++---------------------------------------+-------------------------------------+ +| `Physical network awareness`_ | sambetts, vsaienk0 | ++---------------------------------------+-------------------------------------+ +| `Routed networks support`_ | sambetts, vsaienk0 | ++---------------------------------------+-------------------------------------+ +| `Neutron event processing`_ | vdrok, vsaienk0 | ++---------------------------------------+-------------------------------------+ +| `Documentation reorganization`_ | JayF, TheJulia | ++---------------------------------------+-------------------------------------+ +| `IPA REST API versioning`_ | sambetts | ++---------------------------------------+-------------------------------------+ + +Optional Priorities +~~~~~~~~~~~~~~~~~~~ + ++---------------------------------------+-------------------------------------+ +| Priority | Primary Contacts | ++=======================================+=====================================+ +| `Split away the tempest plugin`_ | soliosg, jlvillal | ++---------------------------------------+-------------------------------------+ +| `Deploy steps`_ | yolanda, rloo | ++---------------------------------------+-------------------------------------+ +| Redfish driver | lucasagomes, jroll | ++---------------------------------------+-------------------------------------+ +| `Supported power states API`_ | dtantsur | ++---------------------------------------+-------------------------------------+ +| `Available clean steps API`_ | rloo | ++---------------------------------------+-------------------------------------+ +| `E-Tags in API`_ | galyna, vdrok | ++---------------------------------------+-------------------------------------+ +| `IPA authentication`_ | jroll, joanna | ++---------------------------------------+-------------------------------------+ + +Details +~~~~~~~ + +Standalone CI tests +------------------- + +We are working on a set of tests that can be run without nova present. We +expect this work to improve CI time, coverage and help test certain features +(e.g. adoption) that are not quite compatible with nova. + +Generic boot-from-volume +------------------------ + +This work allows generic hardware to boot from remote storage, allowing +diskless nodes to be managed by ironic. This also lays down the framework for +hardware-specific implementations to be built. + +Rolling upgrades +---------------- + +Many OpenStack projects are beginning to support rolling upgrades - we should +too. Let's do our part to make downtimes a thing of the past. This involves +code changes, new multi-node grenade CI jobs, and reviewer/developer +documentation. The target now is Ocata -> Pike rolling upgrades. + +Reference architecture guide +---------------------------- + +To help new deployers make the right choices, we need a document describing a +reference architecture for an ironic deployment, especially around +multi-tenant networking and co-existing with VMs. + +Driver composition +------------------ + +We've done most of the coding. Let's concentrate on stabilizing the feature, +writing new hardware types, polishing documentation and helping vendors with +onboarding. + +Feature parity between two CLIs +------------------------------- + +Let us make sure that all features implemented in the old ``ironic`` CLI are +available in the new OSC-based ``openstack baremetal`` CLI. + +OSC default API version change +------------------------------ + +Currently the default API version OSC sends to ironic is an old Kilo-era one. +We need to figure out the path towards making the latest version the default. + +Rescue mode +----------- + +This is necessary for users that lose regular access to their machine (e.g. +lost passwords). The spec was merged in Newton, the code is partially done, +let's put some effort into making progress here in Pike. + +Specific fault support +---------------------- + +Currently we communicate certain node errors via setting maintenance mode. +This is not obvious, and is a constant source of complaints from operators. +This work allows us to better communicate such failures, by providing a new API +for working with them. + +Post-deploy VIF attach/detach +----------------------------- + +We already support attaching and detaching VIFs to nodes as part of the +deployment process. Now we need to support the same for active nodes. + +Physical network awareness +-------------------------- + +We need to make sure instances are not scheduled on nodes that cannot +physically reach the networks they're connected to. This may require data +model changes around ports. This is required for `Routed networks support`_. + +Routed networks support +----------------------- + +Ironic should become aware of L2 segments available to connected networks as +well as which L2 networks are actually available to nodes to correctly pick +subnet (IP address) when doing provisioning/cleaning. + +Neutron event processing +------------------------ + +Currently ironic has no way to determine when certain asynchronous events +actually finish in neutron, and with what result. Nova, on the contrary, uses +a special neutron driver, which filters out notifications and posts some of +them to a special nova API endpoint. We should do the same. + +Documentation reorganization +---------------------------- + +For some time, our documentation has grown without strict definition of +structure, as well as difficulties getting documentation into the primary +OpenStack documentation. In the Pike cycle we plan on reaching a consensus of +direction for our documentation structure so we can better self-service as +OpenStack evolves to better support projects such as ironic. + +IPA REST API versioning +----------------------- + +IPA API is currently not versioned, which causes problems when ironic starts +relying on new features. Versioning similar to ironic API is expected to fix +it and simplify upgrades. + +Split away the tempest plugin +----------------------------- + +Currently we rely on certain hacks to make our CI use master version of the +tempest plugin on all branches. The QA team suggests moving our tempest plugin +to a separate branch instead, let's do it. We should also merge ironic and +ironic-inspector plugins for simpler maintenance and consumption. + +Deploy steps +------------ + +This is an effort to split parts of our monolithic deployment process into +steps, similar to cleaning. That will give driver authors a bit more freedom in +customizing the deploy process, and simplify potential additions to it +(like RAID, for example). + +Supported power states API +-------------------------- + +The `soft power/NMI spec +`_ +proposes exposing available power states in the API. We didn't implement this +part in Ocata, let us finish it now. + +Available clean steps API +------------------------- + +We need to expose available clean steps in the API, so that users know which +actions they can run during manual cleaning. This is a part of the +`manual cleaning spec +`_ +which was never implemented, despite the spec being marked as done. + +E-Tags in API +------------- + +We should add E-Tag support to our API to avoid race conditions during +concurrent updates. + +IPA authentication +------------------ + +Neither IPA API, nor the lookup/heartbeat endpoints it uses are currently +authenticated. While this issue is hard to solve completely in generic case, +we can at least consider reducing potential attack surface.