nova – Made by Mikal

Using the openstacksdk with authentication arguments

Post author:mikal
Post published:August 21, 2023
Post category:OpenStack

I wanted to authenticate against OpenStack recently, and had a lot of trouble finding documentation about how to authenticate just by passing arguments (as opposed to by using clouds.yaml or environment variables). Now that I have a working incantation, I figure I should write it down so I can find it again. Its also disappointing the OpenStack documentation doesn't appear to cover this particularly well... from keystoneauth1.identity import v3 from keystoneauth1 import session from openstack import connection auth = v3.Password( auth_url='http://kolla.home.stillhq.com:5000', username='admin', password='...', project_name='admin', user_domain_id='default', project_domain_id='default') sess = session.Session(auth=auth) conn = connection.Connection(session=sess) print([x.name for x in conn.list_servers()]) This code will authenticate using the arguments provided, and then list all the servers (instances) visible to that user. You're welcome.

Things I read today: the best description I’ve seen of metadata routing in neutron

Post author:mikal
Post published:May 8, 2017
Post category:OpenStack

I happened upon a thread about OVN's proposal for how to handle nova metadata traffic, which linked to this very good Suse blog post about how metadata traffic is routed in neutron. I'm just adding the link here because I think it will be useful to others. The OVN proposal is also an interesting read.

Nova vendordata deployment, an excessively detailed guide

Post author:mikal
Post published:February 4, 2017
Post category:OpenStack

Nova presents configuration information to instances it starts via a mechanism called metadata. This metadata is made available via either a configdrive, or the metadata service. These mechanisms are widely used via helpers such as cloud-init to specify things like the root password the instance should use. There are three separate groups of people who need to be able to specify metadata for an instance. User provided data The user who booted the instance can pass metadata to the instance in several ways. For authentication keypairs, the keypairs functionality of the Nova APIs can be used to upload a key and then specify that key during the Nova boot API request. For less structured data, a small opaque blob of data may be passed via the user-data feature of the Nova API. Examples of such unstructured data would be the puppet role that the instance should use, or the HTTP address of a server to fetch post-boot configuration information from. Nova provided data Nova itself needs to pass information to the instance via its internal implementation of the metadata system. Such information includes the network configuration for the instance, as well as the requested hostname for the instance. This happens…

How we got to test_init_instance_retries_reboot_pending_soft_became_hard

Post author:mikal
Post published:September 25, 2015
Post category:OpenStack

I've been asked some questions about a recent change to nova that I am responsible for, and I thought it would be easier to address those in this format than trying to explain what's happening in IRC. That way whenever someone compliments me on possibly the longest unit test name ever written, I can point them here. Let's start with some definitions. What is the difference between a soft reboot and a hard reboot in Nova? The short answer is that a soft reboot gives the operating system running in the instance an opportunity to respond to an ACPI power event gracefully before the rug is pulled out from under the instance, whereas a hard reboot just punches the instance in the face immediately. There is a bit more complexity than that of course, because this is OpenStack. A hard reboot also re-fetches image meta-data, and rebuilds the XML description of the instance that we hand to libvirt. It also re-populates any missing backing files. Finally it ensures that the networking is configured correctly and boots the instance again. In other words, a hard reboot is kind of like an initial instance boot, in that it makes fewer assumptions about…

Kilo Nova deploy recommendations

Post author:mikal
Post published:January 13, 2015
Post category:OpenStack

What would a Nova developer tell a deployer to think about before their first OpenStack install? This was the question I wanted to answer for my linux.conf.au OpenStack miniconf talk, and writing this essay seemed like a reasonable way to take the bullet point list of ideas we generated and turn it into something that was a cohesive story. Hopefully this essay is also useful to people who couldn't make the conference talk. Please understand that none of these are hard rules -- what I seek is for you to consider your options and make informed decisions. Its really up to you how you deploy Nova. Operating environment Consider what base OS you use for your hypervisor nodes if you're using Linux. I know that many environments have standardized on a given distribution, and that many have a preference for a long term supported release. However, Nova is at its most basic level a way of orchestrating tools packaged by your distribution via APIs. If those underlying tools are buggy, then your Nova experience will suffer as well. Sometimes we can work around known issues in older versions of our dependencies, but often those work-arounds are hard to implement (and…

How are we going with Nova Kilo specs after our review day?

Post author:mikal
Post published:December 15, 2014
Post category:OpenStack

Time for another summary I think, because announcing the review day seems to have caused a rush of new specs to be filed (which wasn't really my intention, but hey). We did approve a fair few specs on the review day, so I think overall it was a success. Here's an updated summary of the state of play: API Add more detailed network information to the metadata server: review 85673. Add separated policy rule for each v2.1 api: review 127863. Add user limits to the limits API (as well as project limits): review 127094. Allow all printable characters in resource names: review 126696. Consolidate all console access APIs into one: review 141065. Expose the lock status of an instance as a queryable item: review 127139 (abandoned); review 85928 (approved). Extend api to allow specifying vnic_type: review 138808. Implement instance tagging: review 127281 (fast tracked, approved). Implement the v2.1 API: review 126452 (fast tracked, approved). Improve the return codes for the instance lock APIs: review 135506. Microversion support: review 127127 (approved). Move policy validation to just the API layer: review 127160. Nova Server Count API Extension: review 134279 (fast tracked). Provide a policy statement on the goals of our API policies:…

Soft deleting instances and the reclaim_instance_interval in Nova

Post author:mikal
Post published:December 15, 2014
Post category:OpenStack

I got asked the other day how the reclaim_instance_interval in Nova works, so I thought I'd write it up here in case its useful to other people. First off, there is a periodic task run the nova-compute process (or the computer manager as a developer would know it), which runs every reclaim_instance_interval seconds. It looks for instances in the SOFT_DELETED state which don't have any tasks running at the moment for the hypervisor node that nova-compute is running on. For each instance it finds, it checks if the instance has been soft deleted for at least reclaim_instance_interval seconds. This has the side effect from my reading of the code that an instance needs to be deleted for at least reclaim_instance_Interval seconds before it will be removed from disk, but that the instance might be up to approximately twice that age (if it was deleted just as the periodic task ran, it would skip the next run and therefore not be deleted for two intervals). Once these conditions are met, the instance is deleted from disk.

Specs for Kilo, an update

Post author:mikal
Post published:December 3, 2014
Post category:OpenStack

We're now a few weeks away from the kilo-1 milestone, so I thought it was time to update my summary of the Nova specifications that have been proposed so far. So here we go... API Add more detailed network information to the metadata server: review 85673. Add separated policy rule for each v2.1 api: review 127863. Add user limits to the limits API (as well as project limits): review 127094. Allow all printable characters in resource names: review 126696. Expose the lock status of an instance as a queryable item: review 127139 (abandoned); review 85928 (approved). Implement instance tagging: review 127281 (fast tracked, approved). Implement the v2.1 API: review 126452 (fast tracked, approved). Improve the return codes for the instance lock APIs: review 135506. Microversion support: review 127127 (approved). Move policy validation to just the API layer: review 127160. Nova Server Count API Extension: review 134279 (fast tracked). Provide a policy statement on the goals of our API policies: review 128560. Sorting enhancements: review 131868 (fast tracked, approved). Support JSON-Home for API extension discovery: review 130715. Support X509 keypairs: review 105034 (approved). API (EC2) Expand support for volume filtering in the EC2 API: review 104450. Implement tags for volumes and…

Specs for Kilo

Post author:mikal
Post published:October 25, 2014
Post category:OpenStack

Here's an updated list of the specs currently proposed for Kilo. I wanted to produce this before I start travelling for the summit in the next couple of days because I think many of these will be required reading for the Nova track at the summit. API Add instance administrative lock status to the instance detail results: review 127139 (abandoned). Add more detailed network information to the metadata server: review 85673. Add separated policy rule for each v2.1 api: review 127863. Add user limits to the limits API (as well as project limits): review 127094. Allow all printable characters in resource names: review 126696. Expose the lock status of an instance as a queryable item: review 85928 (approved). Implement instance tagging: review 127281 (fast tracked, approved). Implement tags for volumes and snapshots with the EC2 API: review 126553 (fast tracked, approved). Implement the v2.1 API: review 126452 (fast tracked, approved). Microversion support: review 127127. Move policy validation to just the API layer: review 127160. Provide a policy statement on the goals of our API policies: review 128560. Support X509 keypairs: review 105034. Administrative Enable the nova metadata cache to be a shared resource to improve the hit rate: review 126705…

One week of Nova Kilo specifications

Post author:mikal
Post published:October 14, 2014
Post category:OpenStack

Its been one week of specifications for Nova in Kilo. What are we seeing proposed so far? Here's a summary... API Add instance administrative lock status to the instance detail results: review 127139. Add more detailed network information to the metadata server: review 85673. Add separated policy rule for each v2.1 api: review 127863. Add user limits to the limits API (as well as project limits): review 127094. Allow all printable characters in resource names: review 126696. Implement instance tagging: review 127281. Implement tags for volumes and snapshots with the EC2 API: review 126553 (spec approved). Implement the v2.1 API: review 126452 (spec approved). Microversion support: review 127127. Move policy validation to just the API layer: review 127160. Support X509 keypairs: review 105034. Administrative Enable the nova metadata cache to be a shared resource to improve the hit rate: review 126705. Containers Service Initial specification: review 114044. Hypervisor: FreeBSD Implement support for FreeBSD networking in nova-network: review 127827. Hypervisor: Hyper-V Allow volumes to be stored on SMB shares instead of just iSCSI: review 102190. Hypervisor: VMWare Add ephemeral disk support to the VMware driver: review 126527 (spec approved). Add support for the HTML5 console: review 127283. Allow Nova to access…