I finally got a right-sized flavor for an OpenShift deployment: 25 GB Disk, 4 VCPU, 16 GB Ram. With that, I tore down the old cluster and tried to redeploy. Right now, the deploy is failing at the stage of the controller nodes querying the API port. What is going on?

Here is the reported error on the console:

<figure class="wp-block-image"></figure>

The IP address of 10.0.0.5 is attached to the following port:

$ openstack port list | grep "0.0.5"
| da4e74b5-7ab0-4961-a09f-8d3492c441d4 | demo-2tlt4-api-port       | fa:16:3e:b6:ed:f8 | ip_address='10.0.0.5', subnet_id='50a5dc8e-bc79-421b-aa53-31ddcb5cf694'      | DOWN   |

That final "DOWN" is the port state. It is also showing as detached. It is on the internal network:

<figure class="wp-block-image"></figure>

Looking at the installer code, the one place I can find a reference to the api_port is in the template data/data/openstack/topology/private-network.tf used to build the value openstack_networking_port_v2. This value is used quite heavily in the rest of the installers' Go code.

Looking in the terraform data built by the installer, I can find references to both the api_port and openstack_networking_port_v2. Specifically, there are several object of type openstack_networking_port_v2 with the names:

$ cat moc/terraform.tfstate  | jq -jr '.resources[] | select( .type == "openstack_networking_port_v2") | .name, ", ", .module, "\n" '
api_port, module.topology
bootstrap_port, module.bootstrap
ingress_port, module.topology
masters, module.topology

On a baremetal install, we need an explicit A record for api-int.<cluster_name>.<base_domain>. That requirement does not exist for OpenStack, however, and I did not have one the last time I installed.

api-int is the internal access to the API server. Since the controllers are hanging trying to talk to it, I assume that we are still at the stage where we are building the control plane, and that it should be pointing at the bootstrap server. However, since the port above is detached, traffic cannot get there. There are a few hypotheses in my head right now:

1. The port should be attached to the bootstrap device
2. The port should be attached to a load balancer
3. The port should be attached to something that is acting like a load balancer.

I'm leaning toward 3 right now.

The install-config.yaml has the line:
octaviaSupport: "1"

But I don't think any Octavia resources are being used.

$ openstack loadbalancer pool list

$ openstack loadbalancer list

$ openstack loadbalancer flavor list
Not Found (HTTP 404) (Request-ID: req-fcf2709a-c792-42f7-b711-826e8bfa1b11)

19 Jan 2020 12:55am GMT

If I use an IT instrument as a blog, subscribed in a Planet I pretend immediatly to view on Planet!!! As my post has no need to censorship!

18 Jan 2020 10:14pm GMT

18 Jan 2020 9:35pm GMT

Here's your report of what has happened in Fedora this week.

I will not hold office hours next week due to travel, but if you'll be at DevConf.CZ, you can catch me in person.

• Announcements
• Help wanted
• Releases
• CPE update

Announcements

• Orphaned packages seeking maintainers
• Long term FTBFS packages will be retired in February.
• Spins and labs must send a keepalive by 22 January.
• The start of the Fedora 32 mass rebuild is delayed until 27 January. The mass rebuild window will still end on 11 February, so no subsequent schedule dates are changed.

CfPs

<figure class="wp-block-table">

</figure>

Help wanted

• The COPR team wants your feedback on the work to happen in 2020. Vote online for your preferences.
• The Fedora Council wants your feedback on the draft mission statement.
• The Python Maintenance team wants your feedback on a minimization proposal

Releases

Fedora 32

Schedule

• 2020-01-21 Submission deadline for Self-Contained Changes
• 2020-01-22 Spins keepalive deadline
• 2020-01-27 Mass rebuild begins

Changes

<figure class="wp-block-table">

</figure>

Changes approved, rejected, or withdrawn will be removed from this table the next week. See the ChangeSet page for a full list of approved changes.

Fedora 33

Changes

<figure class="wp-block-table">

</figure>

Changes approved, rejected, or withdrawn will be removed from this table the next week. See the ChangeSet page for a full list of approved changes.

CPE update

• Anitya is being prepared for a new release (kanban board, GitHub milestone)
• RabbitMQ support for jms-messaging-plugin is merged
• UI around the Bugzilla override support in src.fedoraproject.org was reworked
• Erlang stack in Fedora was rebuilt so it woudl work on the s390x architecture
• OSBS aarch64 is in staging
  • Deploy OpenShift cluster on aarch64 boxes
  • Configured OSBS on the x86_64 and aarch64 OpenShift cluster in staging
  • Test build is failing

The post Fedora program update: 2020-03 appeared first on Fedora Community Blog.

17 Jan 2020 7:50pm GMT

Hello testers, the Kiwi TCMS team sat down together last week and talked about what we feel is important for us during the upcoming year. This blog post outlines our roadmap for 2020!

Project sustainability

The big goal towards which we are striving is to turn Kiwi TCMS into a sustainable open source project. For now this means several key areas:

1) Team
2) Technical
3) Community

Team

Right now we have a core team with 6 newcomers on-boarding. Engineering performance is all over the place with some people contributing too much while others contributing too little. More importantly there is no consistent pace of contributions which makes planning timely completion of technical tasks impossible.

At the moment we do operate as a bunch of disconnected people who happen to talk to each other from time to time.

We are going to adjust our internal processes and how we on-board new members. In fact we did our first "scrum-like" meeting this week and agreed to change our existing practice and strive to become better as a team!

Goal: to have a cohesive team at the end of the year which operates with a predictable capacity.

Goal: 1 PR/week/person as broad measure of individual performance.

Technical

The areas shown on the picture above will receive more priority.

Goal: complete remaining Telemetry features.

Goal: complete bug-tracker integration milestone.

Goal: all pylint issues resolved.

Goal: migrate all remaining legacy templates to Patternfly UI. See patternfly-migration milestone.

Goal: where FE sends AJAX requests to BE views replace with JSON RPC API instead.

Extra: start tackling the JavaScript mess that we have. This depends and is related to Patternfly migration and overall refactoring.

Extra: make it easier for downstream installations to extend and override parts of Kiwi TCMS in order for users to adjust the system to their own needs. The system is pretty flexible as-is but there have been requests, both online and offline, to provide some extra features! We'll start looking into them, likely making partial progress in the next 12 months.

Community

Last year Kiwi TCMS had massive success at every single conference that we've been to. Both project and team have been well received. While we are going to continue being part of various communities around the world we are trying to limit extensive travel and focus on functionality and partnerships which will increase Kiwi TCMS eco-system, make the project even more popular and drive further adoption!

Goal: extended GitHub integration via kiwitcms-github-app plugin.

Goal: release the following test automation framework plugins for Kiwi TCMS:

• PHPUnit plugin
• py.test plugin
• TestNG plugin
• Jenkins plugin
• Robot framework plugin
• Django plugin

For more information see test-automation-plugins milestone.

Ongoing: work with our partners from the proprietary and open source worlds. This is hard to quantify and lots of it doesn't actually depend on the team. However we are continuing to talk to them regularly. Expect new feedback to become available under GitHub Issues.

Extra: see what we can do about testing productivity! This has always been part of our mission but we have not been able to produce anything worth sharing. We do have ideas in this space but we are generally looking for partnerships and collaborations. It is very likely that there will not be very much progress on this front because it is hard to define it properly :-(.

Summary

At the end of the day most of these goals compliment each other and help drive all of them to completion. Many of the still on-boarding people have expressed desire to improve their Python & Django skills. Working to resolve issues in the above specific areas will give them this opportunity! I expect they will show good progress on their respective tasks so we can write more about them on this blog.

Happy testing!

17 Jan 2020 5:40pm GMT

A while ago as a spin-off of my project to improve support for Logitech wireless keyboards and mice I have also done some work on improving support for (Gaming) keyboards with a builtin LCD panel.

Specifically if you have a Logitech MX5000, G15, G15 v2 or G510 and you want the LCD panel to show something somewhat useful then on Fedora 31 you can now install the lcdproc package and it will automatically recognize the keyboard and show "top" like information on it. No need to manually write an LCDd.conf or anything, this works fully plug and play:

sudo dnf install lcdproc
sudo udevadm trigger

If you have a MX5000 and you do not want the LCD panel to show "top" like info, you may still want to install the mx5000tools package, this will automatically send the system time to the keyboard, after which it will display the time.

Once the 5.5 kernel becomes available as an update for Fedora you will also be able to use the keys surrounding the LCD panel to control the lcdproc menu-s on the LCD panel. The 5.5 kernel will also export key backlight brightness control through the standardized /sys/class/leds API, so that you can control it from e.g. the GNOME control-center's power-settings and you get a nice OSD when toggling the brightnesslevel using the key on the keyboard.

The 5.5 kernel will also make the "G" keys send standard input-events (evdev events), once userspace support for the new key-codes these send has landed, this will allow e.g. binding them to actions in GNOME control-center's keyboard-settings. But only under Wayland as the new keycodes are > 255 and X11 does not support this.

17 Jan 2020 1:39pm GMT

The Fedora CoreOS team is pleased to announce that Fedora CoreOS is now available for general use. Here are some more details about this exciting delivery.

Fedora CoreOS is a new Fedora Edition built specifically for running containerized workloads securely and at scale. It's the successor to both Fedora Atomic Host and CoreOS Container Linux and is part of our effort to explore new ways of assembling and updating an OS. Fedora CoreOS combines the provisioning tools and automatic update model of Container Linux with the packaging technology, OCI support, and SELinux security of Atomic Host. For more on the Fedora CoreOS philosophy, goals, and design, see the announcement of the preview release.

Some highlights of the current Fedora CoreOS release:

• Automatic updates, with staged deployments and phased rollouts
• Built from Fedora 31, featuring:
  • Linux 5.4
  • systemd 243
  • Ignition 2.1
• OCI and Docker Container support via Podman 1.7 and Moby 18.09
• cgroups v1 enabled by default for broader compatibility; cgroups v2 available via configuration

Fedora CoreOS is available on a variety of platforms:

• Bare metal, QEMU, OpenStack, and VMware
• Images available in all public AWS regions
• Downloadable cloud images for Alibaba, AWS, Azure, and GCP
• Can run live from RAM via ISO and PXE (netboot) images

Fedora CoreOS is under active development. Planned future enhancements include:

• Addition of the next release stream for extended testing of upcoming Fedora releases.
• Support for additional cloud and virtualization platforms, and processor architectures other than x86_64.
• Closer integration with Kubernetes distributions, including OKD.
• Aggregate statistics collection.
• Additional documentation.

Where do I get it?

To try out the new release, head over to the download page to get OS images or cloud image IDs. Then use the quick start guide to get a machine running quickly.

How do I get involved?

It's easy! You can report bugs and missing features to the issue tracker. You can also discuss Fedora CoreOS in Fedora Discourse, the development mailing list, in #fedora-coreos on Freenode, or at our weekly IRC meetings.

Are there stability guarantees?

In general, the Fedora Project does not make any guarantees around stability. While Fedora CoreOS strives for a high level of stability, this can be challenging to achieve in the rapidly evolving Linux and container ecosystems. We've found that the incremental, exploratory, forward-looking development required for Fedora CoreOS - which is also a cornerstone of the Fedora Project as a whole - is difficult to reconcile with the iron-clad stability guarantee that ideally exists when automatically updating systems.

We'll continue to do our best not to break existing systems over time, and to give users the tools to manage the impact of any regressions. Nevertheless, automatic updates may produce regressions or breaking changes for some use cases. You should make your own decisions about where and how to run Fedora CoreOS based on your risk tolerance, operational needs, and experience with the OS. We will continue to announce any major planned or unplanned breakage to the coreos-status mailing list, along with recommended mitigations.

How do I migrate from CoreOS Container Linux?

Container Linux machines cannot be migrated in place to Fedora CoreOS. We recommend writing a new Fedora CoreOS Config to provision Fedora CoreOS machines. Fedora CoreOS Configs are similar to Container Linux Configs, and must be passed through the Fedora CoreOS Config Transpiler to produce an Ignition config for provisioning a Fedora CoreOS machine.

Whether you're currently provisioning your Container Linux machines using a Container Linux Config, handwritten Ignition config, or cloud-config, you'll need to adjust your configs for differences between Container Linux and Fedora CoreOS. For example, on Fedora CoreOS network configuration is performed with NetworkManager key files instead of systemd-networkd, and time synchronization is performed by chrony rather than systemd-timesyncd. Initial migration documentation will be available soon and a skeleton list of differences between the two OSes is available in this issue.

CoreOS Container Linux will be maintained for a few more months, and then will be declared end-of-life. We'll announce the exact end-of-life date later this month.

How do I migrate from Fedora Atomic Host?

Fedora Atomic Host has already reached end-of-life, and you should migrate to Fedora CoreOS as soon as possible. We do not recommend in-place migration of Atomic Host machines to Fedora CoreOS. Instead, we recommend writing a Fedora CoreOS Config and using it to provision new Fedora CoreOS machines. As with CoreOS Container Linux, you'll need to adjust your existing cloud-configs for differences between Fedora Atomic Host and Fedora CoreOS.

Welcome to Fedora CoreOS. Deploy it, launch your apps, and let us know what you think!

17 Jan 2020 10:40am GMT

Service 'The Koji Buildsystem' now has status: good: Everything seems to be working.

17 Jan 2020 9:05am GMT

Service 'The Koji Buildsystem' now has status: major: koji is not responsive, the problem is under investigation

17 Jan 2020 8:08am GMT

This article should rather be called What software I started using in 2019 but I just didn't like that title. It is going to be the first post in a yearly series on this topic.

Admittedly, I have unconventional preferences on the user interface of applications, that I use daily. It manifests itself in a strong Vim modal editing addiction, tiling window manager and not having a mouse on my desk. I figured, that this series might be useful for other weirdos like me. Also, it will be fun to look back and see the year by year progression.

See /r/unixporn if you are aroused by these kinds of pictures.

My daily driver is Lenovo X1 Carbon, that I use almost exclusively for DevOps tasks. It has only 13" display so I usually go one maximized application per workspace. This is very conveniently achievable by using a tiling window manager, in my case Qtile.

Now, what changed in 2019? Quite a lot …

Vim for everything

I use Vim for almost a decade now, which is probably the longest I've sticked to some application. During that time, I repeatedly tried to use it as an IDE but inevitably failed each time. Let's remember eclim as my Java IDE. I work almost exclusively on projects written in Python, which can be beautifully done in Vim but because of a gap in my skills, I was reliant on PyCharm. Thankfully, not anymore.

My biggest issue was misusing tabs instead of buffers and poor navigation within projects. Reality check, do you open one file per tab? This is a common practice in other text editors, but please know that this is not the purpose of tabs in Vim and you should be using buffers instead. Please, give them a chance and read Buffers, buffers, buffers.

Regarding project navigation, have you ever tried shift shift search in PyCharm or other JetBrains IDE? It's exactly that thing, that you wouldn't even imagine but after using it for the first time, you don't understand how you lived without. What it does is, that it interactively fuzzy-finds files and tags (classes, functions, etc) that matches your input, so you can easily open them. In my opinion, this unquestionably defeats any other way of project navigation like using a file manager, NerdTree, or find in the command line.

Fortunately, both of these problems can be solved by fzf.vim, which quickly became one of my most favorite Vim plugins. Please read this section about fzf plugin.

I am forever grateful to Ian Langworth for writing VIM AFTER 11 YEARS, EVERYTHING I MISSED IN "VIM AFTER 11 YEARS" and VIM AFTER 15 YEARS articles. If you are a Vim user, those are an absolute must-read.

Urxvt

Although I spend a considerable amount of my work time in a terminal, I couldn't care less what terminal emulator I use. The majority of them support the exact same features and in the end, you are just sitting there and typing commands into a black screen.

After migrating from PyCharm to Vim, my time spent in the terminal increased even more. Thinking about it, I use terminal and web browser. That's it. Up until this point, I've been using gnome-terminal because it comes preinstalled with Fedora. While it is a perfectly fine piece of software, for me, it's customizability sucks. I just don't want to configure my core tools by clicking in a settings window. It has limitations, it is harder to manage in git, and so on.

Ultimately, the last straw that made me abandon gnome-terminal was its inability to use third-party color schemes. Among many others, there is a great project called base16 which defines palettes of colors for creating beautiful schemes and then provides configurations for countless applications. For most applications, the process is very simple. Put a color scheme file into an expected directory, then edit the config file and specify, which scheme you want to use. Unfortunately, it doesn't work that way for gnome-terminal. You need to run a hundred-line bash script and possibly do other shenanigans and hope for the best.

Currently, my terminal emulator of choice is Urxvt (aka rxvt-unicode). Here comes my sales pitch - Urxvt is an old, ugly-looking application with a horrible user interface. How about that? Joking aside, it looks terrifying at first sight. However, it can be easily configured through ~/.Xresources and with very little effort, it looks as beautiful as the terminal can get.

Color scripts from stark/Color-Scripts

Tmux

Tmux is a terminal multiplexer, tmux is a replacement for GNU Screen, tmux is steroids for your terminal, tmux is the greatest thing since free porn. You. Want. Tmux!

It allows you to:

• horizontally or vertically split the terminal window
• run a command, close the terminal window, and then attach to back to it when needed
• throw your mouse to trash
• add support for tabs, scrolling, searching, and everything that may be missing in lightweight terminal emulators

Recommended read - Boost Your Productivity In The Terminal With tmux

Weechat

The IRC protocol supports only plain-text communication. Sharing images, videos or audio can't be done directly, but rather by uploading it somewhere and embedding a link. That being said, there is no reason to not use a terminal client. I've finally migrated from HexChat (and previously XChat) to Weechat.

My weechat configuration looks quite chaotic in a small window like this. It is optimized for fullscreen.

Newsboat

RSS is a well-known method for subscribing news feeds from various websites. It appears to be stupidly simple to use and it is the most effective way to keep an eye on interesting articles. So why I haven't been able to use it? My typical pattern was - Why don't I use RSS? Then installing a client, subscribing some feeds, being happy, then forgetting that I have an RSS client. And then going back to step one.

Newsboat with a panel indicator seems to do the trick for me.

Check out Adam Šamalík's blog

Vimwiki

What is your current system of taking notes and managing to-do lists? Or do you even? For the longest time, my approach was to remember everything. Surprisingly enough, it worked fine throughout high school, college and all my previous jobs. However now, as I am growing older and my responsibilities increase, the beloved "if I don't remember it, it wasn't that important" philosophy is just not sufficient anymore. Also, repeatedly excusing myself during a work meeting, that I forgot to do something, was just unprofessional.

Well, where to keep notes and to-do lists? There is a gazillion of tools for desktops, smartphones, and everything. Apparently, they are even still making sketchbooks. Like … from paper. Who would know? Anyway, I had some criteria.

1. In my team, we have week-long sprints, so I want to track tasks for that period. While I want to write detailed information about them, as well as fragmenting them into sub-tasks, I am not interested in specifying attributes such as explicit deadlines, locations, projects, etc.
2. There may be tasks, that need to be done some specific day, so it would be useful to have also a page for each day.
3. No mouse! Tools that require me to click on buttons to create tasks, or dragging them with a mouse to reorder is a hard no-go. This is not negotiable.

I've been using Joplin for some time. It allows you to simply create notebooks and notes within them. Each note is a markdown page and you can do whatever you want in it. Joplin was serving its purpose, but I didn't really enjoy using it. First, it is written in Javascript and bundled with Electron, so it is kinda slow and clumsy. I was also missing my Vim key bindings (it has Vim mode now, so it shouldn't be a problem anymore), and finally, it used a different color scheme than the rest of my system. Which, simply speaking, bothered me. This could have probably been solved by using its CLI interface, but then I discovered and migrated to Vimwiki.

I would say, it has the same exact features, but it is a Vim plugin.

Notes and long term ideas on the left, weekly plan on the right

17 Jan 2020 12:00am GMT

Everybody knows that I have always been a firm believer in Gtk+'s potential to be a great cross platform toolkit beyond Linux. GIMP and Inkscape, as an example, are loyal users that ship builds for those platforms. The main challenge is the short amount of maintainers running, testing and improving those platforms.

Gtk+ has a few shortcomings one of them, one of the biggest ones is lack of a11y support outside of Linux. Since I have regular access to a modern OSX machine I decided to give this a go (and maybe learn son Obj-C in the process).

So I started by having a look at how ATK works and how it relates to the GTK DOM, my main goal was to have a GTK3 module that would walk through the toplevels and build an OSX accessibility tree.

So my initial/naive attempt is in this git repo, which you can build by installing gtk from brew.

Some of the shortcomings that I have found to actually test this and move forward:

• Running gtk3-demo creates an NSApp that has no accessibility enabled, you can tell because the a11y inspector that comes with XCode won't show metadata even for the window decorator controls. I have no idea how to enable that manually, it looks like starting an actual NSApp, like Inkscape and GIMP do would give you part of that.
• Inkscape and GIMP have custom code to register themselves as an acutal NSApp as well as override XDG env vars in runtime to set the right paths. I suspect this is something we could move to G and GtkApplication.
• The .dylib I generate with this repo will not actually load on Inkscape for some reason, so as of now I am stuck with having to somehow build a replacement gtk dylib for Inkscape with my code instead of through an actual module.

So this is my progress thus far, I think once I get to a point where I can iterate over the concept, it would be easier to start sketching the mapping between ATK and NSAccessibility. I would love feedback or help, so if you are interested please reach out by filing an issue on the gitlab project!

16 Jan 2020 5:49pm GMT

Finally, it's on it's way to updates-testing. This is 0.8.09, with Python 3. Please test, give karma/feedback, and enjoy!

16 Jan 2020 2:44pm GMT

We're happy to announce Kiwi TCMS version 7.3!

IMPORTANT: this is a critical security update for CVE-2019-19844: Potential account hijack via password reset form!

Also migrates to Django 3.0 and includes several other improvement and bug-fixes!

You can explore everything at https://public.tenant.kiwitcms.org!

Supported upgrade paths:

5.3   (or older) -> 5.3.1
5.3.1 (or newer) -> 6.0.1
6.0.1            -> 6.1
6.1              -> 6.1.1
6.1.1            -> 6.2 (or newer)

Docker images:

kiwitcms/kiwi       latest  4026ee62e488    556 MB
kiwitcms/kiwi       6.2     7870085ad415    957 MB
kiwitcms/kiwi       6.1.1   49fa42ddfe4d    955 MB
kiwitcms/kiwi       6.1     b559123d25b0    970 MB
kiwitcms/kiwi       6.0.1   87b24d94197d    970 MB
kiwitcms/kiwi       5.3.1   a420465852be    976 MB

cd path/containing/docker-compose/
docker-compose down
docker pull kiwitcms/kiwi
docker pull centos/mariadb
docker-compose up -d
docker exec -it kiwi_web /Kiwi/manage.py migrate

# starting from an older Kiwi TCMS version
docker-compose down
docker pull kiwitcms/kiwi:<next_upgrade_version>
edit docker-compose.yml to use kiwitcms/kiwi:<next_upgrade_version>
docker-compose up -d
docker exec -it kiwi_web /Kiwi/manage.py migrate
# repeat until you have reached latest

15 Jan 2020 11:00pm GMT

New status good: Everything seems to be working. for services: Ipsilon, Badges, Blockerbugs, Package Updates Manager, Fedora Infrastructure Cloud, COPR Build System, Documentation website, Fedora elections, Account System, Fedora Messaging Bus, Fedora Calendar, Fedora pastebin service, The Koji Buildsystem, Koschei Continuous Integration, Kerberos, Mailing Lists, Module Build Service, Mirror List, Mirror Manager, Fedora Packages App, Pagure, Fedora People, Package Database, Package maintainers git repositories, Fedora Container Registry, ABRT Server, Tagger, Fedora websites, Fedora Wiki, Zodbot IRC bot

15 Jan 2020 10:54pm GMT

New status scheduled: Everything seems to be working. for services: Ipsilon, Badges, Blockerbugs, Package Updates Manager, Fedora Infrastructure Cloud, COPR Build System, Documentation website, Fedora elections, Account System, Fedora Messaging Bus, Fedora Calendar, Fedora pastebin service, The Koji Buildsystem, Koschei Continuous Integration, Kerberos, Mailing Lists, Module Build Service, Mirror List, Mirror Manager, Fedora Packages App, Pagure, Fedora People, Package Database, Package maintainers git repositories, Fedora Container Registry, ABRT Server, Tagger, Fedora websites, Fedora Wiki, Zodbot IRC bot

15 Jan 2020 9:04pm GMT

The OpenShift installer is fairly specific in what it requires, and will not install into a virtual machine that does not have sufficient resources. These limits are:

• 16 GB RAM
• 4 Virtual CPUs
• 25 GB Disk Space

This is fairly frustrating if your cloud provider does not give you a flavor that matches this. The last item specifically is an artificial limitation as you can always create an additional disk and mount it, but the installer does not know to do that.

In my case, there is a flavor that almost matches; it has 10 GB of Disk space instead of the required 25. But I cannot use it.

Instead, I have to use a larger flavor that has double the VCPUs, and thus eats up more of my VCPU quota….to the point that I cannot afford more than 4 Virtual machines of this size, and thus cannot create more than one compute node; OpenShift needs 3 nodes for the control plane.

I do not have permissions to create a flavor on this cloud. Thus, my only option is to open a ticket. Which has to be reviewed and acted upon by an administrator. Not a huge deal.

This is how self service breaks down. A non-security decision (link disk size with the other characteristics of a flavor) plus Access Control rules that prevent end users from customizing. So the end user waits for a human to respond

In my case, that means that I have to provide an alternative place to host my demonstration, just in case things don't happen in time. Which costs my organization money.

This is not a ding on my cloud provider. They have the same OpenStack API as anyone else deploying OpenStack.

This is not a ding on Keystone; create flavor is not a project scoped operation, so I can't even blame my favorite bug.

This is not a ding on the Nova API. It is reasonable to reserve the ability to create Flavors to system administrators. If instances have storage attached, to provide it in reasonable sized chunks.

My problem just falls at the junction of several different zones of responsibility. It is the overlap that causes the pain in this case. This is not unusual

Would it be possible to have a more granular API, like "create customer flavor" that built a flavor out of pre-canned parts and sizes? Probably. That would solve my problem. I don't know if this is a general problem, though.

This does seem like it is something that could be addressed by a GitOps type approach. In order to perform an operation like this, I should be able to issue a command that gets checked in to git, confirmed, and posted for code review. An administrator could then confirm or provide an alternative approach. This happens in the ticketing system. It is human-resource-intensive. If no one says "yes" the default is no…and thing just sits there.

What would be a better long term solution? I don't know. I'm going to let this idea set for a while.

What do you think?

15 Jan 2020 5:18pm GMT