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

kanku - Bridging the gap between OBS and developers

00:00

Formal Metadata

Title
kanku - Bridging the gap between OBS and developers
Title of Series
Number of Parts
55
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
A convenient way to work with your OBS built images kanku is designed to give you a better integration of your kiwi images built in Open Build Service (OBS) into your development and testing workflow. It provides a framework for simple automation of complex setups, e.g. to prepare your development environment or run simple tests. This talk will give an overview of the motivation/goals and basic concepts/architecture of kanku.
44
Computer-generated imageryElectronic meeting systemWeightComputer animation
Doppel-T-TrägerCartesian coordinate systemMusical ensembleSystems integratorMedical imagingSoftware testingArtificial lifeFront and back endsMultiplication signINTEGRALComputer animation
Asynchronous Transfer ModeArchitectureClient (computing)Computer-generated imageryConfiguration spaceComplex (psychology)Computer iconServer (computing)Component-based software engineeringDemonTask (computing)Asynchronous Transfer ModeServer (computing)Connectivity (graph theory)MathematicsProof theoryBuildingMultiplication signVirtual machineSoftware testingDemo (music)Rollenbasierte ZugriffskontrolleLaptopHydraulic motorMusical ensembleSoftware
Computer fileMobile appMedical imagingVirtual machineVirtual realityConfiguration spaceArrow of timeProcess (computing)Source codeJSON
Software developerLaptopAsynchronous Transfer ModeEmulationRegulärer Ausdruck <Textverarbeitung>Virtual machineAsynchronous Transfer ModeInterrupt <Informatik>Integrated development environmentSource codeMedical imagingComputer animation
Asynchronous Transfer ModeLaptopSoftware developerScheduling (computing)Open setServer (computing)Maxima and minimaVirtual machineAsynchronous Transfer ModeMedical imagingServer (computing)Scheduling (computing)Directory serviceTask (computing)CodeLaptopVirtualizationProcess (computing)Web 2.0Projective planeMobile appSeries (mathematics)Electronic GovernmentHydraulic jumpWeb pageData managementPhysical systemComputer iconMUDMusical ensembleComputer animation
Task (computing)Context awarenessTelecommunicationComputer configurationAsynchronous Transfer ModeDistribution (mathematics)Server (computing)Social classConvex hullKolmogorov complexityReduction of orderMaxima and minimaSoftware testingContext awarenessRow (database)CANopenServer (computing)InformationMusical ensembleProcess (computing)Service (economics)Medical imagingProjective planeDescriptive statisticsView (database)VirtualizationYouTubeTelecommunicationEmailOcean currentInstance (computer science)Revision controlVirtual machineWeb 2.0Slide ruleTask (computing)Data storage deviceSource codeQR codeSet (mathematics)Domain nameComputer configurationCASE <Informatik>DatabaseSocial classDemonComplex (psychology)Message passingDistribution (mathematics)Utility softwareFront and back endsBus (computing)Software testingLaptopWorkloadFlow separationComputer animation
Software testingVirtual machineMusical ensembleMedical imagingCrash (computing)Computer animation
Software testingVideoconferencingMusical ensembleComputer animation
Transcript: English(auto-generated)
Hello everyone, my name is Frank, also known as Moses, today I'm gonna talk about one of my favorite projects, it's called Kanku, and this talk has the under title, Bridging
the Gap between OBS and Developers. I started working as OBS backend developer in 2015 at SUSE, and at this time we didn't
have integration tests for our application images, and the first questions I would have asked to the audience, who of you is using OBS actively, okay, the second question would
be, who already built images, KVM images with Kiwi in OBS, okay, and who of you knows vagrant and used it, okay.
Today I want to talk about the motivation behind Kanku, I would like to give you an overview of the modes of Kanku, and we will talk about the basic concepts and the architecture.
The motivation and goals. As I already said, when I started in the OBS team, we had no tests for our OBS appliance
images, and I made some changes in the setup, and I wanted to test them, and then I started with a small proof of concept, just to fire up a virtual machine via KVM
with a bit, and do this regularly scheduled, to have a nightly build, or a nightly test of our builds.
After a few weeks, this POC was really getting more and more working for me, and then I thought about a command line tool to use this on my laptop, and this was
the time when the developer mode was developed, and yeah.
For the overview, I will try to explain the developer mode, the server mode, the basic concepts like the jobs, the tasks, the handlers, and the utilities, and the
components which work inside Kanku. Now I will start a short demo.
Here we see the Kanku init command, which creates a basic configuration file for your Kanku job, then normally you run a Kanku app which downloads the image from the OBS,
and fires up a virtual machine in your virtual environment on the local machine. After that, you can do a Kanku SSH to log into this machine and start developing.
Sorry for this short interruption. The developer mode is designed to make it easier for you to work with the images you created on your local machine to get an environment where you can start straight on developing.
All packages are installed, and you only have to check out the source code, or, for example, Kanku can do this also for you, so only start developing. Jobs are triggered manually in this state. This is Kanku app command.
We will see later in the server mode which other trigger modes are possible. Later on, I invented the offline mode, which is very useful for me because I'm travelling
much, and then you have a cached image on your laptop, for example, and can fire up a machine while being offline. Kanku can also share your project directory with the virtual machine, so you can switch
between developing on your local machine and run the code inside this virtual machine, for example.
Then the server mode. There are two modes in the server mode. It's distributed, or it's standalone. Standalone means it runs only on one machine, or you can scale over with more than one server to make it more scalable.
The jobs can either be triggered, or they can be scheduled. There is the Kanku scheduler which enables you to run your tasks regularly, or they can be triggered, event-driven, for example, by RabbitMQ, or via web UI where you just start by clicking your job.
For me, it's very convenient to fire up a virtual machine on the server, so I can develop with my colleagues on this virtual machine without giving them access to my
laptop or something like that. Now we come to the basic concepts, the jobs, the tasks, and as you can see, the
handles and the utils. We start with the jobs. A job is a set of one or more tasks.
You can use loose coupling. These tasks are normally only one handler is specified, but we come to this on the next slide. There is a job context which is used for the communication between these tasks.
So, for example, if you run an OBS check to check for the latest image which was built inside OBS, this information is stored in the context, and the next handler, like the image download, can take this information, downloads the image, and stores
the path to the local image inside the context for the next handler, like the create domain handler.
A task runs exactly one handler with defined options. Here you can see a small context snippet for the create domain.
Option in this case is only the domain name. Most of the options or all of the options are documented in POD in the corresponding handlers in the source code. So, at the moment, it's a bit, yeah, you have to be aware of how to read a Perl
documentation with Perl doc in the installed source tree. Tasks will only execute at once, but you can have several tasks with the same
handler. As already said, there is always a job context which stores the information for the communication between tasks.
Here we have the handler classes which are normally located under opt-cancu-lib-cancu handler. They normally have three methods, prepare and execute, and then finalize
method, and they have multiple distribution nodes. This is required if you run it in a distributed set-up. For example, there is a port forwarding handler which can be run on the master
server and can port forward ports to the virtual machine, so you can easily access, for example, the web server or the SSH server from the virtual machine over the master server, and the information is displayed in the web
UI. Then there are worker-only handlers like create domain, which you only run on one specific machine, or a handler can be run on all servers, like remove domain, because when you run a remove domain, you want to remove
this current instance from all of the servers that you don't run into name conflicts after restarting the job.
Then we have the util classes. They are mainly helpers for the handler classes to reduce the complexity or to make functionality available for all the handler classes where you may use
it. Now we come to the basic architecture, and the jobs get triggered.
They get created in an SQLite database. As already said, there is a trigger daemon which can read from a message bus the web UI or the CLI command, because all of the commands you can do
on the CLI, you can also, everything you can do in the web UI, you should be able to use the CLI for it to trigger it via REST.
Then we have the ConcoDispatcher. In distributed mode, it uses RabbitMQ to distribute the workload over the several Conco worker machines.
Then the job is running, and the virtual machine is created via libvit command. Here I prepared a small cheat sheet, how to install Conco, how to set it up,
and run your first project. This will be available on GitHub. If you recognise the URL and the QR code at the beginning, this is the URL
to this presentation. There you can find the cheat sheet. Yes, please test it, use it, or, if you want, contribute,
contributions are very welcome. Or, on GitHub, you can also open issues, or if you have some questions, you can find me as Moses on Freenode, or also in the public available
documentation on GitHub. You can find further information. Yes. Are there any questions? Yes? I haven't understood well, I think because I don't have enough knowledge
of the backend of OBS. So, does Conco is the tool to be able to make the build process of my
images on my laptop without needing an external OBS appliance? It's not to build your images on your laptop. This you can do with OSC. But once you checked in your image description and OBS built an image for
you, then Conco can help you to fetch these images from the OBS, the latest image, and fire up a virtual machine with exactly this image. Did this answer your question? Yes, thank you. Okay.
Any further questions? Okay. Thank you for your attendance.