The Mirantis Blog
Kubernetes tutorials, product updates and featured articles
OpenStack Swift uses hash values to store objects. Hashing uses a mathematical algorithm to transform data, for instance a string, into a numeric representation.
Mirantis OpenStack Express 2.0 is designed to simplify and reduce the time required to import and manage guest images, launch VMs, create and attach volumes, and perform other basic administrative tasks. In this short video, we’ll begin by looking at MOX 2.0’s image features, and show how you can quickly create a new image from a reliable source.
We have created a VMware Virtual Appliance (vApp) that you can download, import to VMware, and that offers pre-configured virtual machines for Fuel, and OpenStack. These have sufficient memory, disk and networking pre-defined so that the guesswork is gone. Simply hydrate the Fuel master node with the latest Mirantis Openstack release and get going.
In previous blog posts we described the replication feature for Trove, and the implementation in the Client and the Task Manager in detail. In this post we describe some of the rationale for this implementation and the roadmap for features that provide performance and availability guarantees that are so critical for a database.
The user is able to issue the various replication related commands using the trove client (python-troveclient). In particular these commands are detach_replication, and extensions to the create and show commands. These commands and their outputs were described in the previous blog post.
As applications migrate to the cloud, the complexity of operating databases in this new environment has become apparent. It is hard to operate a significant database infrastructure, even when you have the luxury of doing it in a controlled data-center on dedicated hardware. The cloud introduces performance variability and an overhead due to virtualization, and provides an end user with a much lower level of control over the underlying hardware. In the public cloud, reliability of an individual virtual machine instance is considerably lower than that of a dedicated machine in a data-center. When operating a large fleet of servers, observed failures are much more frequent. All of these make operating a database in the cloud much more challenging.
Have you ever seen a problem in OpenStack where a VM loses its IP address? If you have, you know what a problem it can be -- especially if you have a large number of nodes and VMs. Your clients get frustrated as they start losing connectivity with their VMs for no obvious reason. Even the cloud support team gets frustrated, as everything appears to be working with no hints in the log files as to what might be wrong. In this blog post, I would like to share my experience with OpenStack networking, and specifically the DHCP subcomponent that is responsible for allocating an IP address to a VM.
It’s a great time to be an OpenStack company - you get the majority of data for marketing and product management by simply talking to customers and partners every day. Nevertheless, the landscape is quite competitive - so both for the community and for individual vendors, it’s important to build and prioritize the feature backlog wisely, all while being clear on who wants what. I’ll call “captain obvious” here, but still, the needs of the Enterprise are quite different from those of a service provider, a government, or some “web-scale” IT shop.
One of the great things about OpenStack is that it enables you to make the most out of the resources that you have, providing a self-service IaaS environment that lets you move faster and operate more efficiently. But what if you already have a virtualization system in place, such as VMware vCenter?
There are two kinds of people in IT/DevOps today: those who are already planning and eventually implementing cloud strategy, and those who are going to be doing it soon. The options you’re faced with are dizzying, often contradictory, and usually dangerously expensive. With all the choices in front of you, what’s the best way to get focused and find the ideal path forward? If OpenStack is the answer (or not), what’s the question?
Let’s talk about replication a bit. How much do you know about it? Why is it so important? In this two-part article series, we're going to look at replication in the context of a proposal to add these capabilities to Trove, the OpenStack Database project.
Cloud users today often also need to be cloud innovators: upgrading components, integrating new hardware, scaling up, and making lots of configuration changes. But how can you be sure the changes you make don’t break anything? Testing using Tempest is (part of) the answer.
Presentation by Nathan Kinder/Red Hat at the OpenStack Security Conclave Meetup in Redwood City CA on 1 May 2014.
If you're reading this blog, you probably know a good bit about OpenStack, and how it handles Infrastructure-as-a-Service (for cattle, basically). You might not, however, be as well-versed in VMware, which has been handling virtualization services (for pets, really) for quite some time now, and over the past couple of development cycles has become part of the OpenStack ecosystem.