Atomic Bonds
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| 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 | 10.5446/54508 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
openSUSE Conference 201844 / 55
8
9
11
15
17
19
20
21
26
28
30
31
32
34
38
39
42
44
45
47
51
52
54
00:00
Computing platformCloud computingDistribution (mathematics)Computer virusCubic graphDistribution (mathematics)Service (economics)Computing platformProduct (business)Data managementSocial classQuicksortBitNeuroinformatikOpen setComputer animationUML
01:05
Data centerNeuroinformatikQuicksortPoint (geometry)Different (Kate Ryan album)MassService (economics)Server (computing)LaptopPoint cloudMobile WebPlastikkarteComputer animation
02:19
Arithmetic meanQuicksortModule (mathematics)Complex (psychology)Point cloudTwitterServer (computing)SoftwareComputer network
02:55
Execution unitSoftwareSoftware developerNeuroinformatikComplex (psychology)CASE <Informatik>Scaling (geometry)Data management
03:30
Service (economics)NeuroinformatikServer (computing)Commodore VIC-20
04:01
Server (computing)Patch (Unix)Configuration spaceScaling (geometry)Figurate numberComputer fileVirtual machineDrawing
04:43
Computer multitaskingNumberLogical constantQuicksortNeuroinformatikComputing platformSoftwareMathematicsCASE <Informatik>Perspective (visual)Scaling (geometry)Address space
05:51
Cloud computingView (database)Computing platformPoint cloudComputerFile formatDivisorArchitectureServer (computing)User interfaceVirtual realityIntegrated development environmentHypercubeOpen setPhysical systemOperations researchCovering spaceConfiguration spaceDatabase transactionWindows RegistryProxy serverStack (abstract data type)Discrete element methodScheduling (computing)Service (economics)Control flowVertex (graph theory)Data managementFunction (mathematics)Mathematical analysisSoftware frameworkElasticity (physics)Data recoveryIterationSpeech synthesisComputing platformMobile appCartesian coordinate systemAbstractionBitScheduling (computing)Multiplication signIntegrated development environmentLatent heatBootstrap aggregatingComputer clusterCloud computingFault-tolerant systemHigh availabilityVirtual realityData storage devicePoint cloudVirtual machineOperating systemServer (computing)Polar coordinate systemDivisorComputer architecturePiMedical imagingComputer configurationArmMachine codeCubic graphCasting (performing arts)Open setSoftware testingInstallation artDistanceMereologyCASE <Informatik>Service (economics)Module (mathematics)Data managementDatabase transactionChainInstance (computer science)Moment (mathematics)Windows RegistryProduct (business)Physical systemStandard deviationHazard (2005 film)Asynchronous Transfer ModeRevision controlSign (mathematics)WebsiteOperator (mathematics)MultilaterationArithmetic meanVirtualizationComputer animation
15:31
Inclusion mapService (economics)Computing platformEnterprise architectureQuicksortBitComputer programmingCasting (performing arts)Product (business)Cartesian coordinate systemDifferent (Kate Ryan album)Computer animation
16:20
Run time (program lifecycle phase)Database transactionPhysical systemOperations researchCoroutineSimilarity (geometry)Independence (probability theory)Cloud computingComputing platformAtomic numberCondition numberCore dumpInstallation artBitPhysical systemServer (computing)Database transactionView (database)Gene clusterVirtual machineSystem administratorMultiplication signService (economics)Cubic graphMereologyOperator (mathematics)Core dumpRevision controlWeightMathematicsArithmetic meanOperating systemRollback (data management)Moment (mathematics)Asynchronous Transfer ModeMechanism designWaveDifferent (Kate Ryan album)CubeAdditionDemosceneQuicksortDecision tree learningIndependence (probability theory)Software developerPoint cloudSoftwareMetropolitan area networkSpacetimePrototypeComputer configurationLibrary (computing)Maxima and minimaComputer animation
21:01
Physical systemSuSE LINUXService PackSoftwareSystem of linear equationsEnterprise architectureCodeParallel portDisintegrationSoftware testingPatch (Unix)Cloud computingComputing platformCubic graphBitQuicksortFactory (trading post)Physical systemCodeDerivation (linguistics)Computing platformService (economics)MathematicsSoftware developerHypermediaService PackProcess (computing)MereologySuite (music)CoroutineDistribution (mathematics)BuildingUsabilityException handlingLibrary (computing)SoftwareCodecPerspective (visual)Repository (publishing)Different (Kate Ryan album)Casting (performing arts)Hecke operatorDatabase transactionShared memoryRevision controlEnterprise architectureComputer animation
25:02
Euclidean vectorHypermediaDistribution (mathematics)ExplosionProduct (business)Software testingComputer-generated imageryDisintegrationProcess (computing)FreewareFactory (trading post)Point cloudRevision controlSoftwareBlogHypermediaPoint cloudMedical imagingFactory (trading post)Process (computing)WebsiteQuicksortMereologyRegular graphSoftware repositoryScripting languageProfil (magazine)Online helpModule (mathematics)Level (video gaming)Casting (performing arts)CodeSoftware developerConfiguration spaceSoftware bugComputer fileBlogUniform resource locatorMoment (mathematics)Standard deviationMetropolitan area networkWeb pageComputer configurationPhysical systemMoving averageDebuggerRule of inferenceCubeAsynchronous Transfer ModeEmailElectronic mailing listGame controllerSoftware testingCoroutineBitCongruence subgroupBinary codeDistribution (mathematics)Connectivity (graph theory)Cartesian coordinate systemLogicMathematicsCubic graphRight angleLatent heatBuildingFront and back endsRevision controlComputer animation
30:33
FreewareMedical imagingElectronic mailing listCubic graphDistribution (mathematics)Cartesian coordinate systemComputing platformMereologyService (economics)AreaTouch typingProcess (computing)Computer architectureWebsiteOpen setWindows RegistryGoodness of fitBit2 (number)AdditionArmCubeBootstrap aggregatingComputer fileCASE <Informatik>Moment (mathematics)Different (Kate Ryan album)Online helpSoftware testingStandard deviationRaw image formatCategory of beingNichtlineares GleichungssystemEmailQubitCoefficient of determinationQuicksortBuildingSingle-precision floating-point formatVotingReading (process)Term (mathematics)Multiplication signComputer animation
36:02
Videoconferencing
Transcript: English(auto-generated)
00:06
Oh, hello. Okay. So, yes. I'm Richard Brown. The Linux distribution engineer working on Cubic at SUSE. And Alex is going to introduce himself. Hi, my name is Alexander Hatziger, the release manager for SUSE container as a
00:25
service platform. And we're presenting. Well, yeah. We're presenting how we work together. So, the open SUSE Cubic, what is open SUSE Cubic and how that relates to SUSE's cast product and how we're collaborating together from the sort of SUSE and open SUSE side of
00:41
things. But just before we start all of that, I wanted to kind of give a little bit of a picture painting history lesson sort of thing. And why... What is this whole containerized world? Where are things going? What are things looking like? Why are we doing this? Why are we here?
01:01
And, you know, lately I've been getting more and more into retro computing and thinking actually about my first computer, which was a Commodore 64. And back then, a computer was completely disconnected from the world, sitting in your home, plugging into a TV, and you're just happily hacking away on this one disconnected device.
01:21
But, you know, if you think of the world today, of the computing you're actually using in your hand, end user computing, everything, you've got this massive sort of plurality of different devices, smart watches, phones, our computers on the desk, our computers on our laptops, our mobile stuff, and everything here is all interconnected in some way, probably
01:43
talking to some server somewhere in some data center. Maybe more than one server, actually more than three servers, in fact so many servers that in the end we just stop talking about servers and start calling it a cloud. But it's still ultimately a whole bunch of servers.
02:00
And this fact of computing, you know, that now sort of the general consumption point of computing is really, you know, you have some end user device and really a lot of the work is being done by some other thing in some backend somewhere, means the world is actually a very, very different place. And everything is way more interconnected, and that means everything is way more complicated.
02:25
You see that not just reflected in sort of the very sort of tangible sort of network servers, racks and clouds and that kind of thing, but even down to our software. The software we're writing these days more and more has a million different modules talking to a million different things, and that just breeds complexity and confusion
02:47
and difficulties with maintaining them and all this kind of stuff. So, you know, the general trend is towards turning everything into a module. You know, software is trying to get more and more modularized, more and more containerized
03:01
and dealt in a way of a smaller, easier, more manageable unit of consumption. So it's easier to figure out how to maintain it. It's easier for a developer to ship that software and have it reused in different ways or have it used interchangeably. So basically trying to turn computing into a collection of Lego bricks.
03:20
And this isn't just to try and solve the complexity problem or the interconnection problem, but also a case of operating at scale. The world has got bigger. More people are using all of this stuff. More people want to use all of this stuff. You want to have services that can scale up and scale down depending on the amount of users you have
03:43
or the amount of users that might be using this today or might not be using it tomorrow. And when you then start thinking about our old computers, our Commodore 64s, our personal server sitting in Iraq somewhere, we used to treat our servers like they were pets.
04:02
We would give them a name. My servers were all named after Jedi Knights from Star Wars films. And we lovingly look after them and we patch them carefully and we micromanage all of the configuration. But that doesn't work when you're doing all of this stuff at that kind of scale.
04:21
When you have so many servers that you don't have enough Jedi Knights left to name them all. And you can't SSH into each one and individually figure out how you're going to configure that ETC file on that machine. You don't want to treat your servers like pets anymore. You don't want to treat your machines like pets anymore.
04:42
You want to look at it much more like cattle. Just number them, put a tag on them, use them. If they end up causing you problems, kill them and eat them. And just move on and have this constant sort of farm of computers doing your work for
05:01
you. So you can move faster. So you can use this new software faster and faster and so you can deal with this world that we're now in. Not just from a community perspective, which I'll be talking about more lately, but everything I just talked about here applies equally true in the business world.
05:20
SUSE's business customers are trying to move in this world, wanting to use technology faster and at higher scale, at higher pace of change. And therefore the case becomes how does SUSE as a corporate company have a platform that addresses these concerns.
05:43
And this is why I hand over to Alex to talk about Casp. Thank you. There you go. Let me check. Does it work that way? Down. Down. One more. Down. Down. There we go. Here we go. Sorry. Okay. What I brought to this speech is I brought down SUSE Cast platform and divided it into
06:11
layers. I will go through them now one by one and just introduce you, which layers we have
06:21
here so you get a better understanding of what Cast platform is looking like, but this also applies for Cubic with some other namings here and there, obviously. So the first thing we have here is we have an infrastructure layer. So even the cloud has some kind of infrastructure that needs to run.
06:43
So SUSE Cast platform is capable of running on physical servers. So if you have some bare metal in your storage, you can get it out and install it plain there. You can also run it on your desktop machines if they are powerful enough.
07:01
More also what a decent idea is if you have some small factor PCs, which you can easily or conveniently stack on your desktop, and you can run a physical cluster on your desktop if you have some small machines. Raspberry Pi is not yet enabled, but this would also be another option once we start
07:23
supporting the ARM architecture. Then of course we support a couple of hypervisors. So we have VMware images out there. We have images for Hyper-V, also for KVM and XN.
07:43
I just realized the clouds are broken. The clouds are broken? VMware, OpenStack, and AWS. Exactly. So we are running the classical hypervisors. We are running on OpenStack, so if you have an OpenStack instance, you can scale out. We do a lot of testing also on OpenStack because it's pretty convenient.
08:04
Then there is, we're supporting public clouds like AWS and in the future also Microsoft Azure and Google Cloud Engine. So you will find our images there soon.
08:20
Then there used to be an operating system, which in our case is SUSE's MicroOS. It's on purpose or for purpose built SUSE Linux Enterprise based at the moment. It's less 12 SP3 based operating system.
08:43
We call it MicroOS. Don't get confused a bit by the name. It's not called, MicroOS does not aim at being small, although we're trying to be small because you're running maybe hundreds of distance. But this aims for the name of MicroServiceOS, so we're microservice oriented here, which
09:00
is one of the use cases for having CASP. So it can run all of those different modules in all those different containers. So having a bundled operating system in your CASP stack means that you're able to install it wherever you want. You can configure it.
09:22
We have transactional updates, we have a talk about, or we heard a talk about already from Ignatz. Tomorrow. Oh, it's tomorrow. Sorry. I was on the wrong studio. Sorry. You will hear more about transactional updates, which is a really neat feature, especially for cluster computing, because you have zero downtime for doing updates.
09:44
And transactional updates also moves out into the SUSE world, so it is applicable on Leap and on Tumbleweed. I'll talk about that more later. Yeah. Then you're able, with the operating system, to debug.
10:03
We have a tool chain module now enabled where you can debug a lot of stuff. And also you're able to install third party tools like monitoring or whatever is needed for your purpose. Then on top of that, there is running some kind of container execution or container
10:23
engine. At the moment, we are running the Docker engine as the first container engine. And in the next version, there will be a tech preview that we offer the possibility to run Cryo as a container engine if you're, for whatever reason, would like to, or prefer
10:46
it over Docker. Yeah. With that, you'll get access to the SUSE registry, which we roll out pretty soon, so you'll find signed containers in there.
11:03
So one of our other projects, the SUSE cloud application platform, already uses the SUSE registry to ship the product in the SUSE registry. So you can download it only from the registry. So there's containers, so containers are usually said to be very small, but they have containers
11:21
with about six gigabytes, so this is a pretty huge thing there. So that's not convenient for someone when it just goes to container because they're considered small. Yeah. And if you run a lot of containers, you want a container orchestration because you do not want to run or monitor your 50,000 containers on your own, so you need some
11:43
kind of orchestration and the quasi-standard or the 2B standard or the most used standard is Kubernetes. Who of you has heard of Kubernetes before? Yeah, okay, almost everyone, so I'm telling nothing new here really, but let's go a bit
12:04
into detail here. So it consists of two parts. We have a container scheduling, which takes care that your services are almost running all the time, so who can give you 100%, but 99.9, and then it becomes expensive
12:23
and provides you fault tolerance and high availability, so Kubernetes takes care that your container always runs if you define it that way and makes sure that the service is available
12:40
as you have defined it before. On the other side, there is container management, which gives you control over your containers. You can define in which environment your containers are about to run, how much resources your containers should get, where it could run, so if you have a hybrid cluster consisting
13:01
of bare metal and virtualised environments, you can define where to run it, if you have some heavy duty services, you can define that they should only run on bare metal if you decide or if your setup is like that. Yep, and then there is another specific thing, that's your cluster management, and there
13:26
we have Vellum, which we develop in-house, and Vellum is a UI for your purpose where you can bootstrap your cluster, where you're going to monitor your cluster, you can set up, you can see the health state of your nodes, you monitor while bootstrapping
13:44
which nodes are good, you can see the update status here. But Vellum doesn't care about the containers themselves. Exactly, that's why I said here it's cluster management, not container management, it takes care of the nodes registered for your system, and you can control them here, you can add
14:05
nodes to it, you can remove nodes to it, you can update nodes, you can define the update policy you want to apply to your cluster. Then there's an optional layer, if you need that, you can install an application ecosystem
14:25
like cloud application platform that abstracts your applications even more, if you're interested, go on our website and look for cloud application platform to know more about that, but this
14:40
is an abstraction layer, when you do not want to handle each and every container on your own, you can use SUSE cloud application platform, which is based on the Cloud Foundry project. And last but not least, SUSE cloud platform is designed to run cloud native applications,
15:01
so you have a very special way of how cloud application should run. Did I write it here? Yes, so it should be operational, observable, elastic, and resilient, and, of course, agile.
15:20
That buzzword may not, must be said, so, like that, and, yes, with that, back to you, Richard. Thank you. Here you go. Yes, so, the brief story of Cubic, because it's a very, very young project, only started last year, actually at OSC last year, really, is OpenSUSE, both inside SUSE and outside,
15:42
has taken a look at what SUSE is doing with this cast model, looking at these layers and trying to use these technologies in an enterprise sense, and kind of really looking at what are the applications in more of a broader community sense. So, yes, like I said, started a year ago.
16:00
It's a subproject in the OpenSUSE project, yet another under that big umbrella that we have these days, and it's focused on all of these different container technologies, most of them that you mentioned in the stack there, but also sort of broadening out a little bit as well, and we've now become the upstream for the cast program. So, really, we're kind of like the Martian explorers for this whole container world side
16:24
of things. It's obviously similar, coming from the same basic ideas, but already in a year, things have grown quite different, and that's really quite an exciting thing. So, we're independent from Casp, like everything in OpenSUSE, independent from SUSE, and we're basing all of the work we're doing inside OpenSUSE Tumbleweed.
16:41
I'll go into more details about that later. And more and more, we're targeting the latest upstream container technologies. So, for example, there is Vellum, and Vellum is contributed to as part of the cubic project, but in addition to that, we're looking at CubeADM, which in the last year has kind of flooded onto the scene, and that's really becoming the sort of upstream cluster
17:03
or bootstrapper for most Kubernetes clusters, and there's some really cool stuff that only Vellum can do that CubeADM can't, and there's some really cool stuff that only CubeADM can do that Vellum can't right now, so we're kind of looking at that and playing with that. A lot of the stuff with CRIO and Podman is happening inside the cubic space.
17:24
We have transactional updates and all of the development we're doing there, and I'll talk more about that in a little bit. And, yes, since starting Cubic, we've completely and utterly re-engineered the installation routine, so it's a million times more customisable than what the poor customers of Casp are using, so we can prototype new stuff and play around and generally
17:44
have a lot more options in there. So, in a nutshell, though, what are we really looking at is pretty much anything our community wants to look at in this container space. So, for example, Paul has his talk on Sunday in the hall next door at that time, and that's
18:01
an example of this. Yes, exactly. There's Paul. He's the one. And he's been experimenting with some stuff on Cubic. He'll be talking about that. In fact, I don't think you're using Kubernetes as a tool, so it's like a perfect example of the kind of crazier, more interesting stuff. Yes, so please come to his talk. I'm going to focus a little bit on the transactional update stuff, although Alex already
18:23
talked quite a fair bit about it, and with all of this highly orchestrated, having clusters of machines, running all of your services, looking after all of this stuff, this old sysadmin maxim is more true than ever. If you've got a cluster of nodes, even if it's five nodes, but if it's like five
18:43
nodes on two different clouds or whatever crazy arrangement you might have for running your clusters, you never want to touch that running system. It's just more work than it's worth half the time, but at the same time, you've still got to be secure and still got to be patched and still got to deal with those issues.
19:02
So for that, we have transactional updates in Cubic. It's an update that is totally atomic. It happens in a single operation, either it totally applies and the system totally changes to the new version of the operating system, or nothing at all happens, no software is changed, no libraries are changed, everything is just left exactly as it was, and as part
19:24
of that, none of those changes happening while the system is actually running, because your services are up, your things are running, you don't want to risk anything, you don't want to swap things around, and doing that properly in a single transaction and with the technologies we're using, we also want it to be totally and easily to roll back.
19:44
You do make a change, it all happens in one easy, swift move, and then when you test it or you then run it and you realise it doesn't quite work the way you want it to, you can throw that update away and immediately get back to running the system exactly how it was before you changed anything.
20:03
Transactional updates were originally designed as part of micro OS on the Casp side of things. It's really become the core feature inside both Cubic and Casp, it's definitely the most exciting thing we're working on. And as you saw in the Leap 15 announcement today, this feature is also available as a
20:21
transactional server mode in Leap 15 and Tumbleweed, so you can have a Leap 15 machine using this as its update mechanism. Just pick the transactional server system when you're installing it, but I won't go into any more details because Ignaz is over there, raise your hand, he's in this room tomorrow, going into more detail about that so you can see how that all works and how
20:44
to use it and have fun with it. With this different view on things, with OpenSUSE, with this slightly different view on things and looking at slightly different things from what Casp is doing, how do we
21:03
actually work together? Well, the story of Cubic and Casp working together isn't really that different from the story of OpenSUSE and SUSE working together. Tumbleweed is the star SUSE factory. Whatever, if it's SUSE or OpenSUSE, it doesn't matter, we're all building on the same code base and Tumbleweed is there as our nice, stable, always working, always
21:25
tested, always usable code base. It's the base system for all SLEE versions and even changes for service packs are going to factory first, which is the process we call factory first, which is a key part of
21:42
all SUSE Linux enterprise development. All development now follows the factory first policy, almost everything ends up complying with that policy. There's always some exceptions, especially in service packs, obviously, Tumbleweed moved so far that not all changes make sense to, you know, some libraries need back porting
22:00
and that kind of thing, but the intention is definitely still there. The main benefit this brings, both SUSE and OpenSUSE, from the SUSE side of things, it makes features a heck of a lot easier to get into SLEE. It makes, in fact, the transactional update feature being one example of that. It makes it easier for SUSE's partners and the community to contribute into the SLEE
22:23
code base. It makes that all more stable, which makes it all nice and more stable, more usable for everybody, which, in turn, makes everything nicer and more stable and more usable for everybody who's using OpenSUSE Leap, because that's where it also ends up afterwards. To display this sort of diagrammatically, it looks something like this.
22:44
Everything from, well, everything that SUSE cares about for SLEE comes from Tumbleweed when they start a new SLEE code base, and when they're working on a new SLEE service back, everything they possibly can take from Tumbleweed comes from there. With Casp, it's pretty much the same idea.
23:05
But we have this thing called Cubic. So in essence, Cubic is this subproject, we're focusing on this container stuff. From a code base perspective, though, every Cubic and Tumbleweed are pretty much interchangeable. It's the same repository, it's the same code base, it's the same project in OBS.
23:24
It's a different installation media and it's a different installation routine, because we're focusing just on this container side of things. So it's really just a derivative distribution of Tumbleweed. But all of the code is the same, and to change something in Cubic, you change something in Tumbleweed.
23:42
In the same kind of... mostly the same kind of sense. SUSE cast platform is a derivative of SLEE service packs. So if SUSE want to change something inside Casp, they can change that in that SLEE service pack. Or if the software in question doesn't come from that SLEE service pack, then they pull it from Cubic.
24:03
So all the kind of container stuff that doesn't exist in general SLEE is generally being pulled from Cubic. So to do that diagrammatically, you end up with something like this. So yeah, Tumbleweed feeds into SLEE. SLEE feeds into Casp, and Tumbleweed and Cubic all share in the same code base, but the Cubic
24:24
bits that are interesting for Casp end up in there. So to kind of put that sort of really a little bit too simply, all OpenSUSE development starts in Tumbleweed, all SLEE development starts in Tumbleweed. SLEE is based on Tumbleweed, Cubic is based on Tumbleweed.
24:44
Tumbleweed is kind of the heart of all of this, and yeah, if you really want to work with Casp, you know, you're working with Tumbleweed and SLEE is a derivative of both of those two things together. So if I've interested you enough that you want to start contributing to this and changing what we're doing
25:01
and seeing what we're doing, we could do with more people testing it. We have our ISOs, they're working quite nicely, but we're testing them only in OpenQA right now. There's more manual testing, it's always useful. So you can just go to the regular Tumbleweed download page, there is a Cubic option there.
25:21
You can install it on bare metals, you can install it on VMs. The installation routine, like I say, is nice and changed and simplified, so in fact it walks you through the system roles in far more detail than any other OpenSUSE distribution does. And when you find bugs, because I'm sure you will, you know, you file them in Bugzilla,
25:41
in OpenSUSE Tumbleweed as part of the Cubic component, if you think they're Cubic specific. Generally speaking, a lot of the bugs are shared between Tumbleweed and Cubic, so you file a Tumbleweed bug, we'll fix them there too. Obviously though, in this whole kind of agile, container-y, cloudy world,
26:00
a lot of people don't want to handle messing around with installing installation media, so we are working on VM and cloud images. That is the URL for the OBS project where they are right now. The develop project is there, in fact there is a factory project for them as well.
26:20
But the Cubic team, when we started looking at this, suddenly realised Tumbleweed doesn't have any VM images, and in fact the Tumbleweed release process doesn't have any way of releasing VM images yet. So that's something we're actively working on with the Tumbleweed team at the moment, figuring out, OK, we can build them, how do we test them, how do we do them as part of the standard Tumbleweed release process,
26:43
so when there's a new Tumbleweed snapshot, we're not just publishing a new ISO and a new repo, but we also publish a whole bunch of VM images for that as well as part of the whole thing. We're using for that kind of effort, we're using the factory mailing list, and we're mainly using the factory IRC channel, and we also have our own Cubic IRC channel as well.
27:05
If you're a packager, packaging, or interested in packaging, anything could have container-y. We have the... I really want to change the name, because obviously it comes from CASP, because they started first, but yeah, the develop-casp-controller-node-develop-project,
27:26
where most of the Cubic-specific stuff is being incubated, it's a standard develop project following the same rules and processes that we generally have in OBS for Tumbleweed. We could really do with some help with packaging, especially the more interesting new,
27:43
fast-moving upstream stuff, things like the latest Cryo and Podman, and the whole kind of Project Atomic build tooling has a lot of very interesting stuff, and we do have versions in there, but they're moving quickly, there's different ways of doing things, so please feel free to contribute.
28:00
On the Vellum side of things, even though we're looking at CubeADM, we still wanted to actually help with Vellum, and I'm looking forward to the day where Vellum is a key part of the Cubic standard cluster. All that development is being done in Git. Vellum is mostly a Ruby application, but there's sort of two components with Vellum.
28:21
You've got the front-end and a lot of the logic happening in Ruby, but the execution of changes to your cluster, the kind of orchestration of bootstrapping the cluster, it's all actually done using salt. The repo name is a little bit incongruous, it's not quite true, it's not another copy of salt, the binary that runs the salt stack.
28:43
The salt repo in the Cubic project actually has all of our salt states, all of our configuration for salt. And that's where we have all of the salt scripts and the salt profiles where we're defining how to change something on a Kubernetes cluster, how to bootstrap the cluster, what to do when, how, et cetera.
29:01
And that's something we could definitely do with a lot of help with not just updating for the pace of stuff in Tumbleweed, but those modules are incredibly useful for people who might be interested in just using them bare for running their own Kubernetes cluster, separate from using the more broad tools. There's a lot of very useful knowledge there for starting up a Kubernetes cluster,
29:24
moving the initial containers around and getting the base level done. But right now it's all very much focused on the Casp stuff and we want to make it more usable and more flexible for dealing with the faster stuff. So, please feel free to go there. It's GitHub, issues, pull requests, it's all open and very, very nice to use.
29:48
And almost last, yeah, we have the cubic website itself. So, there we have kind of a summary of everything I've talked about here. But also we're trying to turn it into sort of a very active sort of blog slash community
30:02
for showcasing what is happening in the cubic world of things. So, that's where you can read all the latest stuff about the transactional update features in Leap and Tumbleweed where you can read about the stuff we're doing with Podman. And if you're doing anything interesting in OpenSUSE, in the container kind of side of things,
30:22
we're interested in taking that blog post and putting it on there. It's very easy to contribute to articles because it's just a bunch of markdown and a Git repo. So, please, yeah, send us a pull request. And, yes, last but not least, anything else. It's an open project.
30:41
This is a very fast moving area of IT of the world. So, if you have any ideas of what you'd like to see inside Cubic, please get in touch. We have our mailing list. We have the Cubic IRC channel. Please join us and start with that, I guess. Does anybody have any questions, comments? Yes, Sergio.
31:02
Yeah, sorry. I think this one might be charged up enough so we can do both. It's about this Cubic images because if Cubic is the platform to run the containers, I don't understand what are these Cubic images. Are there applications that will be run in the containers on Cubic
31:20
or are images of the Cubic itself to run something else? Yeah, good question. So, they would be the VM images for your Cubic cluster for your Cubic platform. So, the OS bit. Fair to mention, actually, I've totally neglected to mention the stuff we're doing
31:43
on the container side itself. So, yeah. If you'll indulge me for a second. In addition to all of this in the Cubic team, we have people now working on the base containers for OpenSUSE and SUSE distributions. So, for example, the official Tumbleweed container in the Docker Hub is being done as part of the Cubic project.
32:03
And same with Leap, which I think has also been upgraded to Leap 15 today already. So, you can do your Docker pull from the Hub, from that registry, and get a proper, built properly, tested properly, OpenSUSE style, OpenSUSE quality, container image.
32:23
And one thing we're working with, but we're not quite there yet. It's a big collaborative thing. The OBS team have a bunch of features going into the OpenSUSE build service. And there is now a website you can already go to, registry.opensuse.org.
32:41
And that is an official container registry for the OpenSUSE project. And it basically reflects every single container built in every single project in every single part of the OBS. So, anybody with a home project in the OBS putting a Kiwi file there and building their own container you can get that container from registry to OpenSUSE.org.
33:04
It's all signed, wrote to read, done properly because the Docker Hub doesn't do that right. Ultimately, long term, that almost certainly will be the official place to get all of the containers for running things like Vellum and Kubernetes on a Cubic cluster.
33:22
It's just a case of not really being there yet. So, we've got the ISO images and stuff done. VM image is next. And that release process part of Tumbleweed which we haven't figured out. The container images will be the step right after that. That will probably answer it at the same time. But just, yeah, priorities.
33:42
Cool. Next question. Thanks, Alex. What architectures do you support with Cubic? At the moment only x86-64 Intel. I have absolutely no problem with talking about doing any other architecture.
34:01
So, in my home project in OBS, there's a little subproject called Cubic underscore rpy. And it works, kind of. Most of the issues that are actually stopping it working aren't issues with the Cubic base or with ARM in OpenSUSE. Most of the issues are things like Kubernetes where a cube ADM bootstrapping
34:23
has a million different timeouts and there's no way Raspberry Pi can do anything that quickly. So, yeah, it's kind of a case of dealing with upstream to make it more ARM friendly. So, yeah, definitely. In the kind of everything else category, this is one thing I would love to see people help push us along.
34:40
Because I kind of like the idea. Next question. Yeah, Panos. It's not a question, it's just a comment that I would like also to highlight
35:01
what Richard said is that Cubic is a new project and basically we can save it based on the community needs. So, just to give you an example that this is true. A couple of months ago I was looking in the rootless containers and what we do there in OpenSUSE. And now we have the test in OpenQA
35:21
so we're really proud of that because the Cubic might be only the only distribution out there that makes sure that rootless containers and OCI open containers initiative style of standardized containers are working for us. So, they will never be broken there in that case.
35:42
So, if you have any use cases bring them forth and they can be a reality. Thank you. Cool. If there's nothing else, then thank you very much.