19 Jan 2020

feedFedora People

Adam Young: Shift on Stack: api_port failure

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 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='', 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

18 Jan 2020

feedFedora People

Luigi Votta: No censorship! Please!

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

Luigi Votta: Ubuntu as Fedora!

At least if you are in an UBUNTU environment and like to build the docs, as I was in Samba:
Go in to docs directory and than:
(mine was a docs-xml)

sudo apt install build-essential
sudo apt install xsltproc
sudo apt install fop
sudo apt install docbook

sudo make all

DOCS are very very important to READ!

18 Jan 2020 9:35pm GMT

17 Jan 2020

feedFedora People

Fedora Community Blog: Fedora program update: 2020-03

Fedora Program Manager weekly report on Fedora Project development and progress

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.



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

Conference Location Date CfP
Open Source Summit NA Austin, TX, US 22-24 Jun 2020 closes 16 Feb


Help wanted


Fedora 32



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

Proposal Type Status
Enable fstrim.timer by default System-Wide Accepted
Use update-alternatives for /usr/bin/cc and /usr/bin/c++ System-Wide Accepted
LTO by default for package builds System-Wide Accepted
Adopting sysusers.d format System-Wide Accepted
Move fonts language Provides to Langpacks System-Wide Accepted
GCC10 System-Wide Accepted
Golang 1.14 System-Wide Accepted
Restart services at end of rpm transaction System-Wide Accepted
Systemd presets for user units System-Wide Accepted
Enable EarlyOOM System-Wide Ready for FESCo
Mono 6.6 Self-Contained Accepted
Provide OpenType Bitmap Fonts Self-Contained Ready for FESCo
Additional buildroot to test x86-64 micro-architecture update self-Contained Ready for FESCo
Reduce installation media size by improving the compression ratio of SquashFS filesystem System-Wide Ready for FESCo
Deprecate python-nose Self-Contained Announced


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


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

Proposal Type Status
Binutils 2.34 System-Wide Accepted
Retire python26 Self-Contained Ready for FESCo
Retire python34 Self-Contained Ready for FESCo


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

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

17 Jan 2020 7:50pm GMT

Kiwi TCMS: Project roadmap 2020

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!

roadmap image 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


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.


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.


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:

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 :-(.


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

Hans de Goede: Plug and play support for (Gaming) keyboards with a builtin LCD panel

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

Fedora Magazine: Fedora CoreOS out of preview

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:

Fedora CoreOS is available on a variety of platforms:

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

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

Fedora Infrastructure Status: All systems go

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

17 Jan 2020 9:05am GMT

Fedora Infrastructure Status: Major service disruption

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

17 Jan 2020 8:08am GMT

Jakub Kadlčík: Software tips for nerds

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.


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 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:

Recommended read - Boost Your Productivity In The Terminal With tmux


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.


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


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

16 Jan 2020

feedFedora People

Alberto Ruiz: GTK: OSX a11y support

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:

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

Gwyn Ciesla: duplicity for EPEL-8

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

15 Jan 2020

feedFedora People

Kiwi TCMS: Kiwi TCMS 7.3

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

Changes since Kiwi TCMS 7.2


  • Update Django from 2.2.8 to 3.0.2


  • Update python-gitlab from 1.13.0 to 1.15.0
  • Update pygithub from 1.44.1 to 1.45
  • Update django-grappelli from 2.13.2 to 2.13.3
  • Bump django-uuslug from 1.1.9 to 1.2.0
  • Bump django-attachments from 1.4.1 to 1.5
  • Bump django-vinaigrette from 1.2.0 to 2.0.1
  • Update marked to version 0.8.0
  • Update prismjs to version 1.19.0
  • Generalize existing kiwitcms.telemetry.plugins handling code by renaming the entry point to kiwitcms.plugins
  • Refactor views to class based (Svetlozar Stoyanov)
  • Teach Kiwi TCMS to automatically report bugs to GitHub when the user selects such action. Fall back to opening a new browser window for manually entering the bug if something goes wrong


  • When migrating from the older Bug model to LinkReference skip bugs which are attached directly to test cases instead of test executions. See SO #59321756
  • Remove AutoField.max_length because it is ignored by Django 3


  • TestCase.update() method now allows to update the author field. Fixes Issue #630

Bug fixes

  • Modify template pass object as test_plan. Fixes Issue #1307 (Ed Oswald S. Go)
  • Enable version selection in test plan search page. Fixes Issue #1276
  • Apply percentage rounding for completed test executions. Fixes Issue #1230
  • Fix a logical bug in conditional expression when deciding whether or not reporting bugs to selected issue tracker is disabled


  • Add code of conduct. Fixes Issue #1185 (Rosen Sasov)
  • Add test for KIWI_DONT_ENFORSE_HTTPS. Closes Issue #1274
  • Replace ugettext_lazy with gettext_lazy for Django 3
  • Remove BaseCaseSearchForm.bug_id field
  • Refactor testcase edit view to class-based
  • Happy New Year pylint


GitHub integration

The hosted version of Kiwi TCMS ships with additional GitHub integration. See GitHub App announcement and github-app for more information!

Upcoming conferences

The next two events we are going to participate are:

If you are around come and say "Happy testing"!

How to upgrade

Backup first! If you are using Kiwi TCMS as a Docker container then:

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

WHERE: docker-compose.yml has been updated from your private git repository! The file provided in our GitHub repository is an example. Not for production use!

WARNING: kiwitcms/kiwi:latest and docker-compose.yml will always point to the latest available version! If you have to upgrade in steps, e.g. between several intermediate releases, you have to modify the above workflow:

# 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

Happy testing!

15 Jan 2020 11:00pm GMT

Fedora Infrastructure Status: All systems go

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

Fedora Infrastructure Status: There are scheduled downtimes in progress

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

Adam Young: Self Service Speedbumps

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:

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