On March 3, we held a webinar talking about the release of Mirantis OpenStack 8.0, and we got a record number of questions — so many, in fact, that we’re going to need two blog entries to answer all of them! Here’s part one. Expect part two next week.
Q: A question on stability: Did I hear it right that certain fixes already available with Mirantis Openstack 8.0 might be included only in Mitaka? Does this also mean specific fixes might not be available with distributions from other vendors too?
A: Let’s take that question one piece at a time. Before releasing a version of OpenStack, Mirantis “hardens” it, fixing all bugs that we find and submitting those fixes back to the community. By default, those fixes become part of the “next” community release, so in general, you’re correct; other vendors’ distributions wouldn’t have those fixes. That means the “Vendor X” version of Liberty wouldn’t, in this case, have those fixes. Some fixes might eventually be backported — in this case, from Mitaka to Liberty — when they are made more universally available. At that point, should “Vendor X” decide to update its version of Liberty, it would then gain those fixes. For the moment, however, advanced changes are unique to MOS until they are accepted subject to community decision-making.
Q: Are Ironic bare metal nodes managed by Fuel?
A: This version of Fuel installs and manages the Ironic service and its network, however it does not manage the bare metal nodes that you later add. Flavors and Images for the bare metal nodes are managed through Horizon, and the IPMI power management is handled when launching and destroying instances. We are working to further integrate the node management in future releases. As the Ironic project continues to grow and add new features, we’ll work integrate them further into Fuel.
Q: Is there an update for Mirantis Plugins? What about Opendaylight and ElasticSearch?
A: Key partners, who create and maintain their own plugins, have had access to release candidates of MOS 8.0 for several weeks and are in the process of updating plugins and key integrations. Mirantis is also updating the Fuel plugins we maintain, and we expect these updates to be available in the next several weeks, as has been traditional after a new release. You may want to bookmark the Fuel plugins catalog and partner catalog, and watch for regular Mirantis update emails and UI messaging to be apprised of when specific updates become generally available.
Q: Are customized bootstraps officially supported by Mirantis?
A: Mirantis is providing the tooling to create and import your own customized bootstraps, and while the bootstraps themselves aren’t “supported” a professional services engagement can help define, create, import, and troubleshoot them.
Q: What about services such as FWaaS which are not core? Do you support them in production or just allow them to be used in your deployments with no guarantee?
A: This depends on the individual service. For the most part, Mirantis supports everything for which Fuel Plugins of a proper revision levels are available, and will of course consult on integrating non-core services for production customers. In some cases, we’ve become concerned about the practical quality/utility of non-core services for which plugins have been released, and have removed these plugins from current circulation. An example is the LBaaS plugin, which will return, we expect, now that OpenStack Octavia is production-ready.
Q: Can you elaborate on what you mean by “validated drivers”?
A: Mirantis has a transparent program (the Unlocked Partner Program) where makers of solutions (and drivers) can validate their products against specific versions of MOS and reference deployment architectures relevant to their primary use-cases. The first requirements of Unlocked partnership at the OpenStack Driver level are that a driver be upstreamed, that its development be CI/CD-enabled to drive automated testing against community trunk, and that the partner has obtained the OpenStack compatible mark from the Foundation. Thereafter, we prescribe a process whereby they create a MOS cloud, deploy their driver manually, document the process, and run tests before and after to validate cloud stability, plus whatever functional tests they require to ensure availability of the full scope (or limited documented scope) of solution features. We also require that Unlocked partners join TSAnet, which is a clearing-house for online compliance to SLAs and quick access to agreed-upon escalation pathways, so we can support validated solutions very reliably and escalate issues efficiently without deliberation or finger-pointing. Additionally, most validation processes conclude with the creation of educational materials, reference architecture documents, white papers and other collateral — besides deployment guides and other very basic assets — to ensure that joint customers understand joint solutions and have the perspective required to get best use of them.
Q: What are the supported hypervisors in Mirantis OpenStack 8.0?
A: Ubuntu KVM, RHEL KVM, vCenter, XenServer, QEMU
Q: Can you support multiple hypervisors within one OpenStack compute cluster?
Q: For all different options for hypervisors and HW who provides support for them for infrastructure flexibility? Mirantis?
A: We support Mirantis OpenStack and Mirantis developed fuel deployment plugins. Support for validated 3rd party items comes from their respective vendors.
Q: Where can I find the recording of the “What’s new in Liberty” webinar?
A: You can find it here: What’s New in OpenStack Liberty
Q: How many separate reference architectures are offered?
A: As of the time of this writing, 9 are available; you can find them on our resources page.
Q: How many compute nodes can Mirantis OpenStack 8.0 safely scale to?
A: We certify 200 out-of-the-box, but you can scale to 1000 with tuning.
Q: Could you tell us more about the reference architecture?
A: You can find a detailed discussion of the Mirantis OpenStack reference architecture at https://docs.mirantis.com/openstack/fuel/fuel-8.0/.
Q: Are the test suites available to consumers?
Q: How far can Ceilometer scale?
A: Ceilometer has been tested and scales to 50 nodes.
Q: When talking about stability/hardening, are you talking about Fuel, OpenStack, or both?
A: Both; we have always worked to harden OpenStack itself, and Fuel is now an OpenStack project.
Q: What happens if a patch is refused in the community edition of OpenStack?
A: That can happen if there is an alternate way of fixing a bug. In this case, while the bug is being resolved, you get our fix through Mirantis OpenStack. Ultimately, when we pick up the next release, we use the “alternate” fix so that Mirantis OpenStack remains close to trunk, and we don’t introduce “proprietary” code.
Q: Is StackLight an evolution of what Mirantis was previously calling the LMA Toolchain? Is it based on the ELK stack elements I keep reading about?
A: StackLight is an umbrella brand-name to deliver a state-of-the-art Logging, Monitoring and Alerting framework for OpenStack and private cloud deployments. StackLight includes a logging engine based on the ubiquitous ELK stack.
Q: We have a running OpenStack environment deployed with Fuel 7.0. Will there be a supported upgrade path to upgrade the existing environment to Liberty?
A: We publish a series of steps to perform in-service upgrade operations. As long as these steps are followed, yes the upgrade operation will be supported. However, for production environments, we recommend the Mirantis upgrade professional service to jointly evaluate the best choices and strategy for upgrade.
Q: Is it possible to explain interoperability testing?
A: This release saw the creation of internal teams around key partnerships such as Cloud Foundry to ensure that knowledgeable personnel could perform appropriate testing of these potentially complex environments. The process also involved the provisioning of authoritative labs for partners to ensure reliability. This cycle also involved a much greater volume of partners, as well as improved systematization and documentation of program requirements, deep database management of validation progress and status, and a complete revision of Hardware Compatibility List validations.
Q: Can we install 7.0 plugins in Fuel 8.0?
A: Each Fuel plugin includes a list of compatible MOS environments. Fuel allows “installation” of historical plugins to the Fuel Master, however Fuel restricts plugins that can be “deployed” into environments based on their validated versions. For example, 7.0 plugins can be deployed into MOS 7.0 environments, but not into MOS 8.0 environments, and 8.0 plugins can be deployed into MOS 8.0, but not into MOS 7.0. (Plugins are not backwards compatible.)
Q: We are a group of research students from the University, and we have started exploring Mirantis OpenStack 7.0 in a virtual environment. Can we use it for performance testing, VM allocation policy and HA fault tolerance experiments?
A: Proper expectations are all that are required. Performance of a virtualized virtual environment will be expected to underperform compared to a bare metal environment. Similarly, additional layers of abstraction may have impacts on VM allocation responses and HA fault tolerance procedures. That said, you’re free to experiment! Please do file issues found with the community.
Q: Is it necessary for me to learn OpenStack? I am a Cisco networking expert.
A: Yes! The whole world is moving to clouds. You might want to explore the OpenStack training classes on our website. They are the most popular in the industry, and vendor agnostic.
Q: Is there support for infrastructure with Docker?
A: Yes. The App Catalog project, Murano, has several Docker infrastructure and Docker related apps, all deployable in Mirantis OpenStack.
Q: Is there a path to use a community supported Fuel plugin in a commercially supported MOS installation, or does that void the warranty on the rest of the installation?
A: We recommend getting the plugin validated. There are paths to get the plugin validated, including a Professional Services engagement or the Partner Plugin Validation program.
Q: Do you think the Mirantis distribution will/can remain the top layer or do we (e.g. user/operator) need another layer/distribution to manage Mirantis with some other distro?
A: Mirantis OpenStack can/will absolutely remain the top layer for Infrastructure as a Service. For specific use-cases, such as hybrid clouds, you may find it useful to consider a number of cloud management platforms (CMP), however.
Stay tuned for part 2, and watch this space for more information about Mirantis OpenStack 8.0.