OpenShift in Fedora Infrastructure NEWS

by on 2018/06/03 at 2:56 pm
Posted In: fedora, linux

I thought I would share today some history, recent happenings and plans for OpenShift in Fedora Infrastructure.

We currently have two OpenShift clusters running in Fedora Infra (not counting two more dedicated to osbs, the container build system). One of these is our staging instance and the other our production instance. Astute readers who know OpenShift may ask why we even bother with a staging cluster, since a lot of workflows with OpenShift let you test and validate things and deploy them as you like. Well, there’s a few reasons we set things up this way: First we don’t have all that many apps moved into OpenShift yet, so they have to interact with all the rest of our staging deployments on vm’s. Also until recently it wasn’t easy to seperate routes in Openshift to make sure you were only sending staging messages to the staging network and not ever mixing in the production network (this has since been vastly improved, but haven’t taken advantage of the new functionality yet). Finally we wanted to make sure we had a test bed for deploying and upgrading the clusters without just having to do all that work in production. Or production cluster has 3 apps running in it currently: bodhi’s web frontend, waiverdb and greenwave. Or staging instance has those three, as well as a number of not quite completed apps: modernpaste, rats, release-monitoring, librariesio2fedmsg, and transstats.

Last week I went ahead and reinstalled both our staging cluster (on wed) and then our production cluster (thursday). I had actually upgraded our staging cluster from 3.7 to 3.9, but I wanted to make sure we could redeploy from the ground up. Production had been on version 3.6 (upgraded from 3.5). The nodes we were using were actually sized when we installed 3.5 and the requirements changed after that making them too small. I had re-installed the compute nodes ok, but the masters didn’t go as well, so I figured it would be a good time to just reinstall completely with the right sizes and 3.9. Additionally, support was added in 3.9 to use cri-o instead of docker containers and we wanted to take advantage of that, as well as adding persistent storage for our registery so we didn’t need to rebuild images all the time. There were various hiccups and issues in our config, but after staging we didn’t hit too many in production. All our apps are now using cri-o containers!

Our plans moving forward include:

  • Moving more apps into OpenShift. It’s still not as smooth as we would like to do initial config, but we hope to improve that and after an app is setup, it’s much nicer for everyone to maintain and deploy from there.
  • We want to improve our ansible setup for deploying / managing apps. Right now our roles and setup are very flexable, but if we change them to be more opinionated we can hopefully make it easier for people to run apps there.
  • As soon as our new cloud is up and running we plan to deploy a OpenShift there. I have been calling it a ‘dev’ env but I am not sure I think thats the right name now. It might be better to think of it as ‘manage your own’. We hope to give people who need it wide access there. The downside is of course if we do a reinstall everyone would have to redeploy their apps.
  • Someday we should just have our staging cluster to use for upgrades/re-installs and have all our apps in one prod cluster.
  • Someday it would be great to pull from upstream git a prod or a stg branch and build and deploy from it. Most of our apps currently are just using rpms, so it doesn’t save as much work on deployments.
  • We definitely want to move as many apps as make sense over, just will need some elbow grease.

It’s exciting to see all the improvements to OpenShift over the last year. It just gets better and better!

Comments Off on OpenShift in Fedora Infrastructure NEWS

Fedora 28 Released

by on 2018/05/01 at 3:32 pm
Posted In: fedora, linux

In case you didn’t hear it all the other places you would normally hear it: Fedora 28 is out. Get it! https://getfedora.org/

I updated my servers here at home last friday, as usual 0 problems at all with the upgrade. Upgrades really are painless these days.

Comments Off on Fedora 28 Released

Fedora Infrastructure hackfest 2018

by on 2018/04/15 at 3:33 pm
Posted In: ansible, fedora, linux, rawhide

Last week I had the pleasure of attending the 2018 Infrastructure Hackfest in Fredricksberg, VA. It was a very productive week and very nice to meet up face to face with a lot of folks I work with mostly over IRC and email.

Travel went pretty well for me (direct flights, 4-5 hours each way) and the hotel worked out nicely. I liked that the hotel had a big table (with power!) in the corner of the lobby for us to use in evenings for more hacking. Our day workspace was a classroom at a nearby grad college. Aside from some firewall issues monday morning (They were blocking everything but 80/443) it worked pretty well too. Lots of tables we could move around, and whiteboards/projector.

Monday we went over current package maintainer workflows and looked for improvements we could land. Pagure 4.0 (out very soon now) should let us fix the silly ‘get a pagure token for this and put it in a config file’ workflow. We also got bodhi to have a ‘waive’ button to waive test results from the web ui, along with showing what exact tests were missing or failing (so we can get rid of a hacky shell script on the wiki for this purpose). After workflows, we started on package maintainer docs rework. We wanted to move them out of the wiki and clean them up and reorg them. First we tried to identify all wiki pages that are related here and make sure we got all the popular ones, then we brainstormed some personas (new to packaging, upstream maintainer wanting to just package their project, someone who doesn’t have time to follow process and just wants the steps to do an update, someone who wants to know how it all works, etc), then we wrote up a bunch of things these people would want to do and tried to organize new docs for it. It’s not really yet in a state to get wide feedback, but hopefully soon it will be.

Tuesday we talked about reassigning some apps that were maintained by someone who moved to other work, then retired a few apps that have been limping along that we no longer want to spend time on: darkserver (which actually has been broken the last year or so), and summershum (which got checksums of source file uploads), which we never quite figured a use for. Next up was rawhide gating. We went over the proposal send to the devel list and got more detailed about what exact things we would need to do for it. It turns out that just adding some things to the update object we could handle the case of side tags and the work won’t be as big as we thought it would.

Wed was setting up a AWX instance. This is the upstream version of ansible tower. We hoped that using it would give us some good advantages. Unfortunately we hit a number of issues. If we tried to install with a external db the install failed, so we had to move back to a db in container next to the rest, then we got pretty far on configuring authentication and hit a bug preventing SAML from working, then finally we hit an issue where we couldn’t get our private repo mounted in the right container to allow us to have access to our secrets. There will be more discussion on this in the coming weeks and we can decide if the effort is worth it or if we should just keep on going the way we had been. As a side note we looked more at the loopabull setup we have. It has only one demo job in it, but it seems ready to add more into as soon as we would like. Look for us to use that more soon too.

Thursday was more work on rawhide gating and some discussion around openshift. Patrick took the projector and he and Randy got bodhi’s web frontend completely moved over to our openshift (but prod is still not pointing at these new instances until we are ready). We also did some more work on release-monitoring.org (anitya) and got it much further along. There were a number of tweaks and improvements to our openshift playbooks too.

Friday we just met at the hotel as everyone was traveling away, so we just worked on finishing some things up.

A few things that got done also over multiple days or between other issues:

  • jenkins.fedorainfracloud.org is now redirecting to centos-ci. This is the jenkins used by various pagure projects to test their code. We had been working on moving it, but hadn’t gotten to it. Now it’s all done except for a more perm redirect.
  • Various internal hardware/budgeting/ordering things were sorted out
  • Tracked down and fixed our old cloud when updates caused it to stop processing copr builders right.
  • Initial work was started on CAIAPI and the small flask based web frontend in front of it (This will replace fas2).
  • Priorities were added to the infrastructure issue tracker to help set expectations on what issues are waiting on what.
  • A new template was added to the infrastructure issue tracker to help us know what issues need to be done by and what they impact.
  • Some thoughts for making the weekly meetings more interesting or more accessable to the developers on the team were brainstormed.
  • We got RHEL 7.5 and openshift 3.9 all set to upgrade to after the upcoming freeze is over.

All in all, a very pproductive week of hacking on things. Many thanks to Paul Frields (stickster) for organizing everything and the Council/OSAS/Fedora Engineering for sponsoring things.

 

Comments Off on Fedora Infrastructure hackfest 2018

Rawhide notes from the trail: more rocky trail

by on 2018/04/07 at 4:19 pm
Posted In: fedora, linux, rawhide

It’s continued to be a bit of a rocky trail of late for rawhide.

The last 6 composes have failed due to:

  • 2018-04-03: New xorg-x11-server landed (1.20). However, tigervnc and xorg-x11-drv-vesa were not rebuilt for it yet, the broken deps caused the failure.
  • 2018-04-04: Same as 03, but the right folks fixed things this day.
  • 2018-04-05: pykickstart dropped python2-kickstart subpackage, which is needed by python2-img which is needed by appliance-creator. Untagged pykickstart for now.
  • 2018-04-06: The kde live media ran out of space.
  • 2018-04-07: The kde live media ran out of space. Bumped up the space slightly to allow it to (hopefully) complete.

I am looking forward to next week when we hope to get things setup for some gating in rawhide. I know it couldn’t handle all these issues, but it’s a start and we can add things as we know how to detect them in advance.

Comments Off on Rawhide notes from the trail: more rocky trail

Rawhide notes from the trail, a Milestone. No? Yes!

by on 2018/03/26 at 5:22 pm
Posted In: fedora, linux, rawhide

As many of you know, we had a long string of difficulties with getting rawhide to compose at all recently. This was mostly a combination of poor timing for things landing, people landing things at the last minute for Fedora 28, and various bugs.

Last week, we hit something that seemed to be pretty special: An actual finished compose. To explain, pungi (the tool that does the composing in Fedora land) has several states that a compose can be in: It can be “STARTED” which means that it started and is composing, or died in such a way it couldn’t properly note that to the compose. It can be “DOOMED” which means that one (or more) required deliverable items failed to compose. In the past this might still have meant part of the compose was shipped out anyhow, but not these days. That prevents the compose from going out at all, and releng folks have to look and make sure the issue that caused the problem is fixed. A compose can be “FINISHED_INCOMPLETE”: This means all the required deliverables are there, but optional/non blocking ones may or may not be. This is the status most of our composes have gotten in the past. Finally, a compose can be ‘FINISHED’ which means all parts of it successfully composed. We had our first “FINISHED” rawhide compose last week. So, break out the harmonica and start dancing right? well, not so fast. There was a bug in pungi where it would have some failed optional deliverables, but still report FINISHED. So, the FINISHED we had wasn’t really a true FINISHED (some ppc images were still failing). Finally late last week we got in a workaround for those last few images, and I am happy to report today that the FINISHED we got was a true, full, real, everything composed FINISHED.

I think some of the credit for this goes to the simple compose tracker that Dusty Mabe setup. This allowed us to track down and fix things that in the past we would just have written off that we don’t have time to fix. Thanks for the issue tracking Dusty! There was of course lots of hard work from many others as well to get to this point: Thanks Mohan, Patrick, Adam, Dennis, Sinny and others I am sure I am forgetting.

Congrats on a FINISHED compose, and lets see how long we can keep it that way.

Comments Off on Rawhide notes from the trail, a Milestone. No? Yes!