bhyve Enterprise Working Group - bhyve+jails manageability work stream

C

cmoerz

Recently, Greg Wallace at the FreeBSD Foundation started the Enterprise Working Group to further improve FreeBSD adoption in enterprise settings. I recently joined and am now actively volunteering in it. We operate according to the FreeBSD code of conduct and the group is open for anyone interested - please feel free to sign up via the interest form!

I took on the work stream for improving bhyve+jails management tools. It originated from particular pain points voiced by an enterprise user of bhyve and jails.

As FreeBSD is open to all, I too want to keep the work stream I'm leading open to other voices. I plan to set up a few online calls, separate from our regular work group calls, to collect a broader set of requirements and better understand our community's needs surrounding bhyve and jails manageability. You can either watch the wiki page for the dates once I post them or shoot me a PM if you're interested to participate; I will also send them out on the work group - so if you join, you'll receive them automatically.

We started a preliminary product requirements document, which is publicly accessible and I'd love to get any feedback, questions or insights you're willing to share - basically AMA about the work group, bhyve and jails management et al!
 
Foundation received inputs from enterprise stakeholders about gaps of FreeBSD’s enterprise capabilities. This led to the formation of the Enterprise Working Group.
Click to expand...

Hmm, 'Chicken or the egg' problem? What FreeBSD can bring to the corporate/enterprise market? And/or what can the corporate/enterprise market provide for FreeBSD ? For example, a corporation can hire at least one full-time person to improve the problems/gaps in FreeBSD to the extent that the corporations require ;-)
 
Yes, you're making a valid point.

It's also a balancing act of what to put into FreeBSD "the OS" (=base) and what to keep in ports.

At the end of the day, FreeBSD is a community effort and we're all better of by working together. That's what the Enterprise Workgroup is for - to raise awareness (on activities as well as FreeBSD in general), provide a forum for coordination, communication and prioritizing our available resources and energy.

IMHO this also helps regular end users at the end of the day, because it improves communication in general, increases transparency on decisions, plans and activities.

And of course, if more developers, project managers, tests, writers, etc. join the continuing work on FreeBSD, we all stand to gain from it.
 
cmoerz said:
[...] It's also a balancing act of what to put into FreeBSD "the OS" (=base) and what to keep in ports.
Click to expand...
From your preliminary product requirements document:
-- Expected results
The goal is that FreeBSD gets an officially supported bhyve VM and jail manager in base.
Click to expand...
-- Assumptions and Constraints
Tooling in base - limits languages and frameworks to C, Shell and Lua
Click to expand...
I wonder, as you are referring to the decision between base versus ports as a "balancing act", why commit yourself at this early stage that it is expected to end in base? As a still to be developed tooling why, for example, should you limit yourself to languages in base or to the probably more restrictive design-develop-implement-test cyle of everything that is in base?

I think that having it in base as the expected result, limits the implementation language* unnecessarily. There are other languages, such as C++ or Rust ( ZFS on Object Storage by George Wilson et al. comes to mind) that could be applied that would provide adequate OS-interfacing when necessary. That all depends on what developers you'll be able to attract. I'm not saying that it must be one of these two, but as you mention "[..] raise awareness (on activities as well as FreeBSD in general), provide a forum for coordination, communication ..." where coordination IMO also would also entail having a clear set of end user objectives or basic functionalities that could, in principle benefit any developer/implementer in whatever language; that may include some of the developers of already existing solutions of course. I also think that an end user is not that interested in the implementation language, unless installing-using-updating becomes bothersome.

Serious tool development can be done in/for ports as for example Poudriere proves (even dualized with ports-mgmt/poudriere and ports-mgmt/poudriere-devel). I think that ports will give you more freedom when there isn't necessarily some "core" set of developers and that contributors may come and go more regularly in a start-up phase, but perhaps also when something has yet to become more crystallised. For this case, what are the most desirable/essential properties of having it in base rather than in ports, apart from the most obvious advantage that "everyone gets it" when installing FreeBSD? Perhaps also useful to ask developers in base (Core team?) what kind of continuous (developer) support they expect to be in place for software in base.

___
* Perhaps you could extend the table of existing software to include its implementation language, e.g.: FreeBSD Jail Manager Features & Support Matrix
 
Thank you for your feedback, Erichans! You're making some great points and I hope to be able to improve the PRD further with your inputs.

You appear to experience the cognitive dissonance I was feeling at the beginning when we started the PRD; I clearly have not managed to iterate the document sufficiently to convey that some degree of clarity has emerged in terms of paths forward.

base or ports? Yes, you're completely right, it probably is smarter to look at ports, particularly because it is an open eco system with many more options than base. During our recent calls, what we realized is that there is a functionality gap of what enterprise users are expecting and what bhyve (and jails) can deliver. These gaps likely need some filling in base and there's already some pieces there that simply need to be connected in the right manner. Then, on top of that, ports can build further. There's ideas floating around for adding some elements in the kernel as well as having a library that provides a simple interface to leverage the additional functionality. That would allow ports to make use of it quickly while base can figure things out a little slower.

So why was there this limitation for base in the first place? Basically, that's what the first stakeholder suggested when he approached Greg Wallace. That's not to say that this is necessarily the right way of doing things - he complained about lack of support and low responsiveness to bug reports in the existing ports. So the document simply started from his (subjective) point of view and is now iterating further as we have more conversations and look at the existing code base more closely.

Poudriere, like drm-kmod, are certainly great examples for ports that live close to base and work well in their context. Maybe we'll have something like that eventually for bhvye and jails as well.

That's the pro and con of the work group - we're first doing some talking and planning before we move into the execution. Some might prefer a more hands on approach in simply trying and evolving things - since the "customers" we're talking to need a high degree of stability and reliability, the work group's approach is more compatible with that.

Again, thank you for taking the time to communicate those points - you're absolutely right: we won't likely ever be able to build the do-all can-all jails+bhyve manager into base any time soon. It would likely contradict the KISS principle and in recent conversations some already said that cbsd, which apparently can do almost everything, is overkill and too complex. That strengthens my belief that we'll likely be looking at working on multiple ends and not just base to make things easier/better. This might also include looking into existing ports and how to help them out.

The more I'm working on this work stream, the more it looks like it's turning into a long term program: there might be the goal to add specific things into base, but there's going to be multiple smaller activities/projects to deliver on the overarching goal of making bhyve (+jails) management better even for the out-of-the-box experience.

If you have the time, please consider joining us in our next work group call! I mean what I wrote/said: this is an open forum and we do welcome feedback and input!

Also, thank you for the matrix, I'll look into adding languages as well!
 
Update: We held our 4th Enterprise Workgroup Meeting last week Friday; unfortunately we did not manage to fit everything into the time frame due to time constraints. Nonetheless, we could see there's a lot of progress happening.

The point on opening up group signup was raised, Greg will be looking into it. I did not manage to raise smbfs because of the time constraint.

It appears there is some consensus that for bhyve+jails, we'll look at designing/drafting something to manage jail/vm state. This would be useful for both - jails as well as bhyve.

I'll be looking into improving documentation on requirements as well as ongoing activities. There's a bunch of great ideas and concepts - we'll need to figure out a way on how to coordinate and move them forward without imposing more governance than necessary.

Clearly, as with any open source effort, there's a "not invented here" risk when creating new things; with the current approach, we'll be looking at foundation work that - if set up right - will benefit all jails+bhyve users down the road. It will keep all options for existing, future and new ports open. It won't break existing things but will make development easier and improve stability if used.

The recording is live on Youtube, the minutes are online, so are the slides. The wiki also has been updated.

Let me know if you have any questions!
 
Thanks, bear in mind the archives don't provide clickable links. So, for anything that a person might want to click: maybe good to have it in the wiki.
 
You must log in or register to reply here.
Back
Top