Highlights of the OBS frontend development - Sprint 33
Another Sprint is over and here is what the OBS frontend team has achieved in the last two weeks (2018-02-19 to 2018-03-02).
EC2 Cloud upload
The last few sprint reports we already showed our efforts to implement a cloud upload feature. This sprint a lot of changes have been made to the EC2 cloud uplod.
First of all, we improved the list of jobs for uploading to the cloud and now we also show the details field. The details field for instance shows the created AMI id.
Our Amazon EC2 uploader makes use of the fantastic Enceladus ec2uploadimg project in the background. While uploading, ec2uploadimg creates several resources like a helper instance or storage volumes. In case of a successful upload, all these resources get cleaned up. However, we also implemented the possibility to abort an upload. In that case, these resources stay and it is necessary to clean them up manually. Not very nice.
Therefore, in this sprint, we implemented an automatic cleanup in case of an aborted upload. We implemented this directly in Enceladus and sent a pull request back upstream.
Until now all this was hidden behind a feature flag. This sprint we also tested all different regions in Amazon EC2 and decided to finally release it to the public. You can read more about it in our cloud upload blog article.
Setup telegraf on the production server
As a long term goal, we want to be able monitor how OBS is used by our users. So that we better understand what we need to improve and ensure that we do the right things when we implement features or change workflows within OBS. For that we needed to install telegraf on metrics.opensuse.org. During this sprint we packaged and installed telegraf on that instance.
Notifications for “Request state was changed” do not seem to work
Some time ago thardeck reported that OBS does not send notifications when the state of a request changes to ‘new’. We’ve investigated the issue and tried to solve it, but in the end we realized that there is no easy solution for this and have to revert our patch.
Instead we generated a follow up card and documented our findings there. We look forward to get this solved soon.
Document Rubocop process of agreeing on style rules
A project as complex and big as OBS certainly needs good documentation. Not only for end users, but also for developers. That’s why we started to document the subsystems of OBS, how we deploy and release our stable versions and many more things.
And since we find coding style quite important we spend some time in this sprint to agree and document on how we want to handle updates of Rubocop. All this is based on our previous efforts of applying Rubocop style rules to OBS. The result can of course be found in our developer wiki.
Like every sprint we were increasing our test coverage. This time we extended PackageController#save_meta tests to cover the holes and have it fully covered. What was missing? Only a few lines that can be checked in PR#4532.