<div dir="ltr">Thank you Julia, for sacrificing yourself and going to Australia; I'm glad the koalas didn't get you :)<div><br></div><div>This summary is GREAT! I'm trying to figure out how we take all these asks into consideration with all the existing asks and TODOs that are on our plate. I guess the best plan of action (and a bit more procrastination) is to discuss this at our virtual mid-cycle meetup next week [1].<br></div><div><br></div><div>--ruby</div><div><br></div><div>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-November/124725.html">http://lists.openstack.org/pipermail/openstack-dev/2017-November/124725.html</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 14, 2017 at 11:18 AM, Julia Kreger <span dir="ltr"><<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings ironic folk!<br>
Like many other teams, we had very few ironic contributors make it to<br>
Sydney. As such, I wanted to go ahead and write up a summary that<br>
covers takeaways, questions, and obvious action items for the<br>
community that were raised by operators and users present during the<br>
sessions, so that we can use this as feedback to help guide our next<br>
steps and feature planning.<br>
Much of this is from my memory combined with notes on the various<br>
etherpads. I would like to explicitly thank NobodyCam for reading<br>
through this in advance to see if I was missing anything at a high<br>
level since he was present in the vast majority of these sessions, and<br>
dtantsur for sanity checking the content and asking for some<br>
elaboration in some cases.<br>
Ironic Project Update<br>
Questions largely arose around use of boot from volume, including some<br>
scenarios we anticipated that would arise, as well as new scenarios<br>
that we had not considered.<br>
Boot nodes booting from the same volume<br>
>From a technical standpoint, when BFV is used with iPXE chain loading,<br>
the chain loader reads the boot loader and related data from the<br>
cinder (or, realistically, any iSCSI volume). This means that a<br>
skilled operator is able to craft a specific volume that may just turn<br>
around and unpack a ramdisk and operate the machine solely from RAM,<br>
or that utilize an NFS root.<br>
This sort of technical configuration would not be something an average<br>
user would make use of, but there are actual use cases that some large<br>
scale deployment operators would make use of and that would provide<br>
them value.<br>
Additionally, this topic and the desire for this capability also come<br>
up during the “Building a bare metal cloud is hard” talk Q&A.<br>
Action Item: Check the data model to see if we prohibit, and consider<br>
removing the prohibition against using the same volume across nodes,<br>
if any.<br>
Cinder-less BFV support<br>
Some operators are curious about booting Ironic managed nodes without<br>
cinder in a BFV context. This is something we anticipated and built<br>
the API and CLI interfaces to support this. Realistically, we just<br>
need to offer the ability for the data to be read and utilized.<br>
Action Item: Review code and ensure that we have a some sort of no-op<br>
driver or method that allows cinder-less node booting. For existing<br>
drivers, it would be the shipment of the information to the BMC or the<br>
write-out of iPXE templates as necessary.<br>
Boot IPA from a cinder volume<br>
With larger IPA images, specifically in cases where the image contains<br>
a substantial amount of utilized or tooling to perform cleaning,<br>
providing a mechanism to point the deployment Ramdisk to a cinder<br>
volume would allow more efficient IO access.<br>
Action Item: Discuss further - Specifically how we could support as we<br>
would need to better understand how some of the operators might use<br>
such functionality.<br>
Dedicated Storage Fabric support<br>
A question of dedicated storage fabric/networking support arose. For<br>
users of FibreChannel, they generally have a dedicated storage fabric<br>
by the very nature of separate infrasturcture. However, with ethernet<br>
networking where iSCSI software initiators are used, or even possibly<br>
converged network adapters, things get a little more complex.<br>
Presently, with the iPXE boot from volume support, we boot using the<br>
same interface details for the neutron VIF that the node is attached<br>
Moving forward, with BFV, the concept was to support the use of<br>
explicitly defined interfaces as storage interfaces, which could be<br>
denoted as "volume connectors" in ironic by type defined as "mac". In<br>
theory, we begin to get functionality along these lines once<br>
<a href="https://review.openstack.org/#/c/468353/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/468353/</a> lands, as the user could<br>
define two networks, and the storage network should then fall to the<br>
explicit volume connector interface(s). The operator would just need<br>
to ensure that the settings being used on that storage network are<br>
such that the node can boot and reach the iSCSI endpoint, and that a<br>
default route is not provided.<br>
The question then may be, does Ironic do this quietly for the user<br>
requesting the VM or not, and how do we document the use such that<br>
operators can conceptualize it. How do we make this work at a larger<br>
scale? How could this fit or not fit into multi-site deployments?<br>
In order to determine if there is more to do, we need to have more<br>
discussions with operators.<br>
Action items:<br>
* Determine overall needs for operators, since this is implementation<br>
architecture centric.<br>
* Plan forward path form there, if it makes sense.<br>
Note: This may require more information to be stored or leveraged in<br>
terms of structural or location based data.<br>
Migration questions from classic drivers to Hardware types<br>
One explicit question from the operator community was if we intended<br>
to perform a migration from the classic driver to hardware types. In a<br>
sense, there are two issues here. The first being a perception of the<br>
work and the second is there a good way to cleanly identify, and<br>
transform classic drivers during upgrade.<br>
Action item:<br>
* For whatever reason the ironic community felt it was un-necessary to<br>
facilitate a migration for users from drivers to resource classes,<br>
even though we have direct analogs. The ironic community should<br>
re-evaluate and consider implementing migration logic to ease user<br>
* In order to proceed, Ironic does need to understand if operators<br>
would be okay if the upgrade process failed, that is if the<br>
pre-upgrade checks detected that the configuration was incompatible<br>
for a migration to be successful. This could allow an operator to<br>
correct their configuration file and re-execute the upgrade attempt.<br>
Ironic use Feedback Session<br>
<a href="https://etherpad.openstack.org/p/SYD-forum-ironic-feedback" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/SYD-forum-ironic-<wbr>feedback</a><br>
The feedback session felt particularly productive because developers<br>
were far out numbered by operators.<br>
Current Troubles/Not Working for Operators<br>
* Current RAID deployment process where we apply raid configuration<br>
generally during the cleaning step, prior to deploy.<br>
** One of the proposed solutions was the marriage of traits, deploy<br>
templates, and the application of deployment templates upon<br>
** The concern is that this will lead to an explosion of flavors, and<br>
some operators environments are already extremely flavor-full. “I<br>
presently run `nova flavor-list`, and go get a coffee”<br>
** The mitigating factor will be the ability to allow at-boot time<br>
definition by the user initiating the deployment, that additional<br>
traits could be proposed on the command line. This was mentioned by<br>
Sam Betts, and one of the nova cores present indicated that it was<br>
part of their plan.<br>
* UEFI iPXE boot - Specifically some operators are encountering<br>
issues, with some vendors hardware, that “should” be compatible,<br>
however is not actually working except in specific scenarios.<br>
** This is not an ironic bug.<br>
** In the specific case that an operator reported, they were forced<br>
into use of a vendor driver and specific settings, which seemed like<br>
something they would have preferred to avoid.<br>
** The community members, as long with the users and operators present<br>
agreed that a good solution would be to propose documentation updates<br>
to our repository that detail when drivers _do not_ work, or when<br>
there are weird compatibility issues that are not quite visible.<br>
** It may be worth considering some sort of matrix to raise visibility<br>
of drivers compatibility/interoperability moving forward. The Ironic<br>
team would not push back if an operator wishes to being updating our<br>
Admin documentation with such information.<br>
Action Items:<br>
* The community should encourage operators to submit documentation<br>
changes when they become aware of such issues.<br>
* The community should also encourage vendor driver maintainers to<br>
explicitly document their known-good/tested scenarios, as some<br>
hardware with-in the same family can vary.<br>
What Operators are indicating that they need<br>
Firmware Updates<br>
Our present firmware update model is dependent upon a hardware manager<br>
driving the process during cleaning, which presently requires the<br>
hardware manager to be built inside the ramdisk image. This is<br>
problematic as it requires operators to craft and build hardware<br>
managers that fit their needs, and then ensure those are running on<br>
the specific hosts to upgrade their firmware.<br>
While this may seem easy and reasonable for a small deployment, there<br>
is an operations disconnect in many organizations between who blesses<br>
new firmware versions, and who controls the hardware. In some cases, a<br>
team may be in charge of certifying and testing new firmware, while<br>
another team entirely operates the cloud. These process and<br>
operational constraints also prevent hardware managers from being<br>
shared in the open, because they could potentially reveal security<br>
state of a deployment. Simply put, operators need something easier,<br>
especially when they may receive twenty different chassis in a single<br>
While we discussed this as a group, we did seem to begin to reach an<br>
understanding of what would be useful.<br>
Several operators made it clear that they feel that Ironic is in a<br>
position to help drive standardization across vendors.<br>
What operators are looking for:<br>
* A framework or scaffolding to facilitate centrally managed firmware<br>
updates where the current state information is published upward, and<br>
the system replies with the firmware to be applied.<br>
** Depending on the deployment, an operator may choose to assert<br>
firmware upon every cleaning, but they need to be able to identify,<br>
the hardware, current firmware, and necessary versions by some sort of<br>
** Any version policy may vary across the infrastructure, based on<br>
either resource class, or hardware ownership concepts.<br>
** This may, in itself just be a hardware manager that calls out to an<br>
external service, and executes based upon what the service tells it to<br>
* Ironic to work with vendors to encourage some sort of standardized<br>
packaging and/or installation process such that the firmware updating<br>
code can be as generic as possible.<br>
One other note worth mentioning, some operators spoke of stress<br>
testing their hardware during cleaning processes. It seems like a<br>
logical thing to do, however this would be best something for a few<br>
operators to explicitly propose what they wish to test, and how they<br>
do it presently so we as a community can gain a better understanding.<br>
Action Items:<br>
* Poll hardware vendors during the next weekly meeting and attempt to<br>
build an understanding and consensus.<br>
* With feedback, we will then have to take the next step is trying to<br>
determine how to fit such a service into Ironic along with what<br>
ironic's expectations are for drivers regarding firmware upgrades.<br>
TPM Key Assertion<br>
Some operators utilize their TPMs for secure key storage, and need a<br>
mechanism to update/assert a new key to overwrite existing key data.<br>
The key data in the TPM is used by the running system, and we have no<br>
operational need to store or utilize the data. Presently some<br>
operators perform this manually, and replacing keys on systems running<br>
elsewhere in the world is presently a human intensive process.<br>
The consensus in the room was that this might be a good out of band<br>
management interface feature which could be in the management<br>
interfaces for the vendor drivers. We presently minimally use the<br>
management interface.<br>
>From a security standpoint, this is also something we shouldn’t store<br>
locally, but only be a clean pass-through conduit for the data, which<br>
makes explicitly out-of-band usage even more appealing with vendor<br>
Action Item: Poll hardware vendors during the next weekly meeting or<br>
two in order to begin discussion of viability/capability to support.<br>
This could be passthru functionality in the driver, but if two drivers<br>
can eventually support such functionality, we should standardize this<br>
Reversing the communications flow<br>
One of the often discussed items in security conscious environments is<br>
the need to be able to have the conductor initiate communication to<br>
the agent. While this model will not work for all deployments, we've<br>
had a consensus in the past that this is something we should consider<br>
doing as an optional setting.<br>
In other words, IPA could have a mode of operation where it no longer<br>
heartbeats to the API, where the conductor would lookup the address<br>
from Neutron, and proceed to poll it until the node came online. The<br>
conductor would then poll that address on a regular basis, much like<br>
heart-beating works today. We should keep in mind, that this polling<br>
operation will have an increased impact on conductor load.<br>
Several operators present in the session expressed interest, with<br>
others indicated this would be a breaking change for their<br>
environment's security model, and as such any movement in this<br>
direction must be optional.<br>
Action Item: Someone writes a specification and poll the larger<br>
operators that we know in the community for thoughts, in order to see<br>
if it meets their needs.<br>
Documentation on known issues and fixes or incompatibilities<br>
Operators would like to see more information on known driver issues or<br>
incompatibilities explicitly stated in the documentation. Additionally<br>
operators would like a single location for "how to fix this issue"<br>
that is not a bug tracking system.<br>
There seemed to be consensus that these were good things to document,<br>
and like the like this, and it seems like the community does not<br>
disagree. That being said, the operators are the ones who will have a<br>
tendency for us to be more aware of such issues.<br>
The best way for the operator community to help the developers, is to<br>
propose documentation patches to the ironic repository to raise<br>
awareness and visibility with-in our own documentation. We must keep<br>
in mind that we must curate this information as well, since some of<br>
these things are not necessarily “bugs”, much like the UEFI boot<br>
issues noted earlier.<br>
Automatic BIOS Configuration<br>
tl;dr: We are working on it.<br>
Use of System UUID in addition to MAC addresses<br>
Some operators would like to see changes in order to allow booting<br>
based upon a recorded system UUID. In these cases, the operator may be<br>
using the "noop" network interface driver, or another custom driver<br>
that does not involve neutron.<br>
To the reasons to support UUID based booting are extensive:<br>
* iPXE can attempt the system UUID first, so support for utilizing the<br>
UUID could remove several possible transactions.<br>
* The first ethernet device to iPXE may not be the one known to<br>
ironic, and may still obtain an IP address based upon the environment<br>
configuration/operation. This will largely be the case in an<br>
environment where DHCP is not managed by neutron. Presently, operators<br>
have to wait for the unknown interfaces to fail completely, and<br>
eventually reach a known network interface.<br>
** Possibly worse, the order may not be consistent depending on the<br>
hardware boot order / switch configuration / cabling.<br>
** Operators indicated that swapped cabling with Link Aggregates is a<br>
semi-common problem they encounter.<br>
* MAC addresses of nodes may just not be known, and evolving to<br>
support hard coded UUIDs does provide us some greater flexibility in<br>
the terms of being able to boot a node where we do not know nor<br>
control the IP addressing assigned.<br>
In addition to UUIDs, an operator expressed interest in having the<br>
same boot behavior, however with the IP address allocated, as opposed<br>
to the UUID. This also deserves consideration as it may be useful for<br>
some operators.<br>
Action Items:<br>
* We should determine a method of storage of the UUID if discovered or<br>
already known. Some operators may already know the address.<br>
** Suggestion from an operator: Maybe just allow setting of uuid when<br>
a node is created, like we do with ports, so that a operator or<br>
inspector could set the node uuid to be the same as the systems uuid,<br>
thus eliminating the need for another field.<br>
** Ironic contributor: Alternatively, we should just add a boolean<br>
that writes it out and offers it as an initial step, and then falls<br>
back to the MAC address based attempt.<br>
* Update template generation to support writing a symlink with the<br>
UUID and / or MAC addresses.<br>
* Explore possibility of doing the same with IP addresses.<br>
Diskless boot<br>
This is a repeat theme that has arisen before, and in many cases could<br>
be solved via the BFV iPXE functionality, however other operators have<br>
expressed need in the past for more generic boot options in order to<br>
boot their nodes. There has been some prior specifications on making<br>
generic PXE interfaces available for things such as network switches.<br>
As such, we should likely re-evaluate those specifications.<br>
Action Item: Ironic should re-evaluate current position, and review<br>
related specifications.<br>
Physical Location/Hardware Ownership<br>
This one didn't quite make the notes, but a couple attendees seem to<br>
remember it and it is worth mentioning.<br>
Presently, there is no ability to have a geographically diverse ironic<br>
installation where a single pane of glass is provided by the API. To<br>
add further complexity, ironic may be in a situation where it is<br>
managing hardware that the operator might not explicitly own, that<br>
needs to be in a delineated pool. We presently have no way to<br>
represent or control scheduling in these cases.<br>
This quickly leads to tenant awareness, as in an operator may have a<br>
tenant that owns hardware hardware in the datacenter. Naturally, this<br>
can get complex quite quickly, but it seems logical for many users as<br>
they have either trusted users that may wish to manually deploy<br>
hardware, and in many of those cases, it is desired that hardware be<br>
used by no other tenant. This concept may also be extended to a<br>
concept of "authorized users" who have temporary implied rights to<br>
interact with ironic based upon permissions and current ownership.<br>
To keep this short, the impacts of this are _massive_ as they are<br>
intertwined fundamental changes to how ironic represents data at the<br>
API level as well as to how ironic executes requests as the end goal<br>
would be to provide the ability to provide the granularity to say<br>
"These two conductors are for x environment" or the granularity of<br>
"your only allowed to see x nodes". As a result of all of this, it<br>
would be a huge API change. The current concept of which, is just<br>
build upon the existing 1.0 API as a 2.0 API.<br>
Action Item: TheJulia and Nobodycam volunteer as tributes... to start a spec.<br>
Ironic On-boarding Session<br>
The Sydney summit was the first attempt by the ironic team to execute<br>
an on-boarding session for the community. As such, the intent was to<br>
take a free form approach as an attempt to answer questions that<br>
anyone had for community members, which would provide feedback into<br>
what new contributors might be interested in moving forward.<br>
By in large, the questions that were asked boiled down to the<br>
following questions:<br>
Where do I find the code?<br>
This was largely a question of what repository contains what pieces.<br>
How do I setup a test environment?<br>
This was very much a question of getting started, which led into the<br>
next logical question.<br>
How do I test without real physical servers?<br>
The answer became Devstack or Bifrost, depending on your use case and<br>
desire to perform full-stack development or lightweight work with or<br>
along side Ironic.<br>
Can I test using remote VMs?<br>
Overall the answer was yes, but that you needed to handle networking<br>
yourself to bridge it through and have some mechanism to control<br>
power. Ironic-staging-drivers was brought up as a repository that<br>
might have useful drivers in these cases. Ironic should to look at<br>
improving some of our docs to highlight the possibilities?<br>
What alternatives to devstack are there?<br>
Bifrost was raised as an example. We failed to mention kolla as an option. :(<br>
How do we see community priorities?<br>
This was very easy for us, but for a new contributor coming into the<br>
community, it is not as clear. Ironic should consider improving<br>
documentation to make it very clear where to find this information.<br>
Action Items:<br>
* Some of Ironic's documentation for new contributors may need<br>
revision to provide some of these contextual details upfront, or we<br>
might need to consider a Q&A portion of the documentation.<br>
* The ironic community should ensure that the above questions are<br>
largely answered in whatever material is presented as part of the next<br>
on-boarding session at the Vancouver summit.<br>
Mogan/Nova/Ironic Session<br>
<a href="https://etherpad.openstack.org/p/SYD-forum-baremetal-ironic-mogan-nova" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/SYD-forum-baremetal-<wbr>ironic-mogan-nova</a><br>
The purpose of this session was to help compare, contrast, and provide<br>
background to the community as to the purpose behind the Mogan<br>
project, which was to create a baremetal centric user-facing compute<br>
API allowing non-administrator users to provision and directly control<br>
baremetal. The baremetal in mogan's context could be baremetal that<br>
already exists, or baremetal that is created from some sort of<br>
composible infrastructure.<br>
The Mogan PTL started with an overview to provide context to the<br>
community, and then the community shifted to asking questions to gain<br>
context, including polling operators for interest and concerns.<br>
Primarily, operator concern was over creating divergence and user<br>
confusion in the community.<br>
Once we had some operator input, we attempted to identify differences<br>
and shortcomings in Ironic and Nova that primarily drove the effort.<br>
What we were able to identify from a work-in-progress comparison<br>
document largely indicated that was additional insight into aggregates<br>
which was partly due to affinity/anti-affinity needs. Additional<br>
functionality exists in Mogan to list servers available for management<br>
and then directly act upon them, although the extent of what<br>
additional actions can be taken upon a baremetal node had not been<br>
As the discussions went on, the Ironic team members that were present<br>
were able to express our concerns over communication. It largely<br>
seemed to be a surprise that some of our hardware teams were working<br>
in the direction of composible hardware, and that the use model mogan<br>
sought could fit into our scope and workflow for composible hardware.<br>
Largely, for composible hardware, we would need some way to represent<br>
a node that a user wishes to perform an action upon. In some cases<br>
now, that is performed with placeholder records representing possible<br>
Naturally for ironic, making it user facing would be a very large<br>
change to Ironic's API, however these are changes, based on other<br>
sessions, that Ironic may wish to explore given stated operator needs.<br>
The discussion for both Ironic and Nova was more of a “How do we best<br>
navigate” instead of “If we should navigate” question, which in it's<br>
self is positive.<br>
Some of these items included improving the view of available physical<br>
baremetal. Regional/Availability zoning, tenant utilization of the<br>
API, and possibly hardware ownership concepts. Many of these items, as<br>
touched in the feedback session, are intertwined.<br>
Overall, the session was good in that we were able to gain consensus<br>
that the core issues which spurred the creation of Mogan are<br>
addressable by the present Ironic and Nova contributors. Complete<br>
gap/feature comparison remains as an outstanding item, which may still<br>
influence the discussion going forward.<br>
Baremetal Scheduling session<br>
<a href="https://etherpad.openstack.org/p/SYD-forum-baremetal-scheduling" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/SYD-forum-baremetal-<wbr>scheduling</a><br>
We were originally hoping to cancel this session and redirect everyone<br>
into the nova placement status update, but we soon found out that<br>
there were some lingering questions as well as concerns of operators<br>
that needed to be discussed.<br>
We started out in discussion and came to the realization that there<br>
could very well be a trait explosion in the attempt to support<br>
affinity and anti-affinity efforts. While for baremetal it could be a<br>
side-effect, it does not line up with the nova model. Conceptually, we<br>
could quickly end up with trait lists that could look something like:<br>
At some point, someone remarked “It seems like there is just no<br>
solution that is going to work for everyone by default.” The remark<br>
was not just resource class determination, but trait identification,<br>
but also encompassed scheduling affinity and anti-affinity, which<br>
repeatedly came up in discussions over the week.<br>
This quickly raised an operator desire for the ironic community to<br>
solve for what would fit 80% of use cases, and then iterate moving<br>
forward. The example brought up in discussion was to give operators an<br>
explicit configuration parameter that they could use to assert<br>
resource_class, or possibly even static trait lists until they can<br>
populate the node with what should be there for their deployment, or<br>
for that individual hardware installation in their environment.<br>
While, the ironic community solution is "write introspection rules",<br>
it seems operators just want something simpler that is a standing<br>
default, like an explicit default in the configuration file.<br>
Some operators pointed out that with their processes, they would<br>
largely know or be able to reconcile the differences in their<br>
environment and make those in ironic as-needed.<br>
Eventually, the discussion shifted to affinity/anti-affinity which<br>
could partially make use of tags, although that as previously<br>
detailed, would quickly result in a tag explosion depending on how an<br>
operator implements and chooses to manage their environment.<br>
Action items:<br>
* Ironic needs to discuss as a group and what the impact of this<br>
discussion means. Many of themes beyond providing configurable<br>
defaults to meet the 80% of users, have repeatedly come up and really<br>
drive towards some of the things detailed as part of the feedback<br>
* For "resource_class" defaults, Dmitry was kind enough to create<br>
<a href="https://bugs.launchpad.net/ironic/+bug/1732190" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>ironic/+bug/1732190</a> as this does seem like<br>
a quick and easy thing for us to address.<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>