We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Open Build Service - Development Roadmap

00:00

Formal Metadata

Title
Open Build Service - Development Roadmap
Subtitle
Past, Present & Future
Title of Series
Number of Parts
57
Author
Contributors
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The Open Build Service is the central development tool of the openSUSE project. Are you an openSUSE packager and build.opensuse.org is your browser home page? Then this talk is for you! Moises (@mdeniz) and David (@dkang) from the OBS community gives you a little report on what has happened since oSC16, what is currently happening and what is planed to happen until next years openSUSE Conference.
55
Thumbnail
26:08
Open setBuildingService (economics)Software developerService (economics)Computer animationUML
Service (economics)Right angleClosed setLecture/ConferenceMeeting/Interview
Software developerOpen setBuildingService (economics)Computer animation
BitView (database)Web pageLecture/ConferenceMeeting/Interview
Service (economics)Physical systemGeneric programmingOpen setBuildingConsistencyFingerprintDistribution (mathematics)Binary codeFile formatSource codeWeb pageConsistencyMultiplication signComa BerenicesCASE <Informatik>Computer architectureRight angleService (economics)Physical systemData structureServer (computing)MereologyBuildingPoint (geometry)Computer animation
Data structureOscillationBitServer (computing)Web browserWeb 2.0Line (geometry)Data structureMereologyRuby on RailsPhysical systemCartesian coordinate systemInterface (computing)CodeProgram flowchart
Time evolutionEvoluteConnectivity (graph theory)Multiplication sign
Distribution (mathematics)MiniDiscFile formatBuildingPower (physics)ArmPowerPCFunction (mathematics)Repository (publishing)Revision controlMobile appFile formatVirtual machineInstance (computer science)Fiber bundleMultiplication signComputer architecturePowerPCRepository (publishing)Function (mathematics)Medical imagingInternet service providerDistribution (mathematics)VirtualizationBuildingComputer animation
User profileWeb pageSource codeRevision controlView (database)Computer fileMultiplicationOpen setBranch (computer science)Repository (publishing)Public key certificateKey (cryptography)AlgorithmBuildingService (economics)Distribution (mathematics)Computing platformSoftware developerACIDComputer-generated imagerySource codeComputer fileRow (database)Profil (magazine)Web pageResultantInstance (computer science)Medical imagingDescriptive statisticsKey (cryptography)Template (C++)Dot productComputer clusterElectronic mailing listXMLComputer animation
Web 2.0
DivisorMathematicsSoftware testingSuite (music)Human migrationIndependence (probability theory)Computer fileState of matterSoftware frameworkOpen setGroup actionMeasurementPhysical systemChi-squared distributionMessage passingDigital filterEvent horizonFrequencyDecimalText editorVisual systemSoftware testingProjective planeMedical imagingSuite (music)VideoconferencingMultiplication signDebuggerVisualization (computer graphics)Game controllerComputer fileEndliche ModelltheorieFrequencyStudent's t-testCodeSoftware frameworkCategory of beingPhysical systemView (database)EmailMessage passingStatisticsMereologyInstance (computer science)NumberOpen setSemantics (computer science)Computer configurationAttribute grammarBus (computing)Right anglePole (complex analysis)CASE <Informatik>Condition numberWeb 2.0Front and back endsTwitterBuildingElectronic mailing listUnit testingFile formatWeb pageComputer animation
Service (economics)Point (geometry)Bit
Service (economics)Open setBuildingContinuous integrationNumberDistribution (mathematics)Repository (publishing)SoftwareSelf-organizationLevel (video gaming)Associative propertyService (economics)NumberWeb 2.0Continuous integrationComputer animation
Cartesian closed categoryHypermediaMeeting/InterviewComputer animation
Transcript: English(auto-generated)
Hello, everybody. We are here to talk about the open build service roadmap, more or less, talking about the past, and somehow about the present, and also I hope that the close future, right?
So we are Moises and David. We work together in the OBS team that is called Build Service Team, right? We work from Canary Islands. So we are here now just for this, the conference, I mean.
I want to show you a little bit, an overview of OBS for who doesn't know how it works or what it does. So we are now taking a look at the phrase that we have in the web page for the open service that says that we are a generic system that can build and distribute binary packages
from sources in a reproducible, automatic and consistent way, right? So this is a very big phrase, right? So I can show you how it works, more or less.
When you are just a packager along in your house and you want to package something and distribute to some users out there, you have your source and then you have to build something, maybe in the simple case for one architecture, one format of the package for one distribution, this is just one build.
If you change something, you only need to rebuild and send it, right? But what if you want to have more users there and then you have to, I don't know, have more distributions, more architectures, and more package formats, right? So that will be a lot. You will get crazy, right? Because each time you change a comma because you are back fixing something, then you have
to build like 30 things. So that's why OBS is to the rescue. We do it automatically, we can reproducibly do it, so done. You are winning. You don't have to build the things by hand.
That's the good point of it. We are talking about now the structure a little bit, because the OBS server part is divided in two applications right now, one in Ruby on Rails, the other in Perl. If you are a user, you can deal with our system by the web UI, so using a browser,
or you can have using the common line interface that is OSC written in Python, right? This deals with the API. It's actually separate code in our code base that we want to already mix, but we are on it. Those talk to the bacon and get the builds done and the things out.
Okay, now we are sharing the time, so David, it's your turn. Hi, everybody. We are talking about the evolution of the components of OBS. So, at the beginning, we support, of course, your own distributions, and also all of those.
That's with us in your own public OBS instance. We support and we update all the versions of all of those, and we distribute to all people. So, now we support the package format like RSpec from RPM, this from Devia,
and also like KV and live builds. After, we support also Colax and RPM package builds, and from later also AppImage and Snap.
The support architecture, in your own instance, for a long time, we support almost 40 architectures, and now we only have 10 of them. The most of them, you recognize are like Intel, ARM, and PowerPC.
The outputs, we have packages, repositories, and also KV. KV of course supports providers, most of them like ISO, virtual machines, Dockers,
and we also provide bundles like AppImage and Snap. So the last main feature, we have Moises. Yeah, again here. Then talking about the last features in the last year, right? So, we have improved a list for KULO that is here right now.
The loading of the profile page. Before it was many lists there that loaded all the records all together and then show it in JavaScript, then you can package it. Now it is server-side, so you only have to load the things that you need, right?
Talking about a big, big feature, because it is KV, you can have build descriptions and build from it, so you already know maybe KV. Also we have the multi-build thing that is popping out in the UI now. Now you can have in one source container a description of which files are creating
which binary packages out there. So you can see in the right side that you can have both build results, so you can see what is going on with each. Also the GPG key and the SSL cert, you can now load it by the UI, so you have
a dialogue here, and if you have both or each, you can see a button for the loading. This is something new also, and I don't know if in our public instance it is shown now, because there are some dots there, but we have image templates, so that means
that you have a package with all set up with a KV thing there, and then you can just branch from it and work and put your stuff on. So you can just branch from those templates there and create your appliance, right?
Now David, it is your turn. Okay, the future. We have a workshop to think about what we want to do in the future, what we want to change, what we want to achieve. So the first one is refactor and change the web UI. Why? Because it's old.
Not that we showed the web UI and we saw it's old-fashioned, it's like, why? So for first, we have to mirror the tests, tweets. Now right now we have many tests and we want to change to RSpec. Not because with many tests it's bad, but we have smoke tests, where you only click
and visit the page and say, oh, it worked fine. You have huge files with huge tests, so maybe a gazillion of code then, and also they only test a workflow. They don't do me tests, sorry, unit tests or controller tests.
Only workflow and that's enough. And it needs a backend to run these tests. RSpec support is more modern, but not more better, but it's new. We will try another smoke test, you have small file with test property done or property
reported in these files, and independent tests and no need to back end, thanks to the VCR. Now, we also try to increase the coverage with one of your goals, because right now
we have 89% and we try to reach maximum possible. The front end, we have some new technologies like Vue, React, maybe also do it in vanilla
JavaScript, we don't know. And also new frameworks from CCS like Miriam, Semantic UI, Bulma, Foundation, we don't know. We have a look at them and when we start we saw one of them or something new appear and we will see.
Why? Like I said before, it's old-fashioned, we have old frameworks from GS and old frameworks from CCS like Bento, and because it's not responsive. We want now also introduce a health monitoring like InfluxDB to measure the numbers of users
we have, also the open and closed reviews, the package that saved it, updated, to have a collection of statistics and to have more data than now is my part.
We have in the format days, we have Hermes and on top of it a notification system, and we want someone to get rid of this, so it's gone right now. Now we want to have another notification system, better than just sending emails, and that's
why we are going to base on Ruby and Q, thanks to Kulo again, for having a list push a message instead of polling, because now time open QA, for instance, just polls there. Also we want to have better filtering for just not saying I want to be just notified
if something pops up in a package that I'm entering on, but also I can say only in that project or I want to have it in the case of something, so many conditionals and many other kind of filtering, right? Besides that, we have a thing about having frequency like before, and also having a digest
instead of just sending a notification each time, so something that maybe once a day have all the things inside and then you just read them. We want to have more channels even, so not only email or SS, so maybe others we have to figure out what, but the good thing is that based on a message bus we can just
talk to it, other tools, not only for people, right? And this is one big thing for us is just creating something that helps people to deal with the kivy files, why? Because this is an XML, you don't know the options that you can have in each attribute,
so the values that you are doing well or not, so you don't have any clue if you don't read the documentation, right? So we want to help people to do it easily, supposedly, so we are doing something visual inside the OBS.
And this is pretty new, it's just because before we had kivy creating Docker images but we wanted or needed just native support for kivy Docker files, right? So we can now create, I hope in no time, building native Dockers from Docker files.
And that's it. Maybe we are now talking about a little bit, not talking about, at least pointing to other talks that are holding here for related somehow to OBS. So now we are in the OpenBill service realm up, for sure you have lost the reposible
bills from Bernard because it passed or not, maybe. I encourage you to go to the continuous integration with OpenBill service of Marmuel and Christian
and also to the SUSE package hub from Wolfgang. Also on Saturday we have all of those. I also encourage you to go to OBS number by Anna and of course of anchor, it's very interesting and also by the OBS package, OBS amplions, a talk and also a workshop
done by Simon and Adrian and also by Wolfgang, the next one and Alex.
And also we have another one on Sunday about packaging by Simon and reposible discussions by Bernard. So, any questions? We are finished, right? If you have any questions, if not, we can go lunch.
No? One, two, three, then go. Thank you so much. Thank you very much.