Red Hat's OpenShift Platform as a Service (PaaS, for those following the buzzwords) offering is starting to get industry momentum.¹ ² What's more, there are only two major open source PaaS offerings³, and we currently have neither of them in Fedora.
We used to have OpenShift v1, but when v2 came along, it was just too difficult to keep all of the Ruby requirements in sync. (I remember some kernel-related pain, too, but I'm kind of hazy — that was several years ago.)
But now, there's a shiny new OpenShift v3, rewritten in Go. I'd like to talk about (and eventually if enough people think this is a good idea, officially propose) a 12-month (e.g, Fedora 24 and 25 cycle) initative to better our relationship with OpenShift, in order to put Fedora in a position of leadership in this important area of computing — and, thinking bigger, to advance the state of open source in this area by doing that.
Specifically (outcomes!⁴), I'd like to:
- Have OpenShift Origin v3 packaged in Fedora, so users Fedora users can deploy it locally and we can use it in Fedora Infrastructure.
- Establish good communication channels between Fedora userbase and upstream developers, so that PaaS innovators⁵ and maybe early adopters⁶ choose Fedora for their leading-edge deployments
- Increase PaaS knowledge and skills in the Fedora contributor community. Possibly have an OpenShift Origin instance running in Fedora infrastructure for contributor community use.
I think this is something on the order of an Objective rather than just a change/feature proposal because it's actually a rather tall order. On the technical side, currently OpenShift can't be easily packaged because it includes some 200+ Go libraries, and we don't even have approved Go packaging guidelines. This probably means we'd be asking for a very large bundling exception (note 'Active upstream Security Team' as part of the justification). On the less technical but still important side, I'd like to see related marketing and documentation, and coordination with Fedora Atomic and the Fedora Cloud WG, and possibly with Fedora Server as well (I know OpenShift node as server role is already under some consideration).
Thoughts, comments, thrown vegetables?
Notes:
1. http://www.redhat.com/en/about/blog/red-hat-cited-%E2%80%9Cvisionary%E2%80%9... 2. http://www.infoworld.com/article/2608445/cloud-computing/review--openshift-s... 3. The other is CloudFoundry, which I'm sure is fine, but which is kind of.... out of ecosystem. (I don't think it even officially runs on CentOS.) 4. http://fedoramagazine.org/lets-talk-about-fedora-project-objectives/ 5. https://en.wikipedia.org/wiki/Technology_adoption_lifecycle 6. ibid.
Disclaimer with my red hat on: this isn't an official message from Red Hat, and while other Red Hatters, including people involved in OpenShift, are _interested_, there isn't a specific request from Red Hat to do this.
On Tue, Sep 29, 2015 at 4:52 PM, Matthew Miller mattdm@fedoraproject.org wrote:
<snip good info>
I think this is something on the order of an Objective rather than just a change/feature proposal because it's actually a rather tall order. On the technical side, currently OpenShift can't be easily packaged because it includes some 200+ Go libraries, and we don't even have approved Go packaging guidelines. This probably means we'd be asking for a very large bundling exception (note 'Active upstream Security Team' as part of the justification). On the less technical but still important side, I'd like to see related marketing and documentation, and coordination with Fedora Atomic and the Fedora Cloud WG, and possibly with Fedora Server as well (I know OpenShift node as server role is already under some consideration).
Thoughts, comments, thrown vegetables?
Do you have someone in mind to lead this objective? If so, is there a reason they didn't propose this themselves?
josh
On Tue, Sep 29, 2015 at 04:56:19PM -0400, Josh Boyer wrote:
Do you have someone in mind to lead this objective?
Not that I've specifically talked to about that yet.
If so, is there a reason they didn't propose this themselves?
Release early release often? I wanted to start the conversation — this isn't a real proposal yet.
On Tue, Sep 29, 2015 at 5:07 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Sep 29, 2015 at 04:56:19PM -0400, Josh Boyer wrote:
Do you have someone in mind to lead this objective?
Not that I've specifically talked to about that yet.
If so, is there a reason they didn't propose this themselves?
Release early release often? I wanted to start the conversation — this isn't a real proposal yet.
Fair enough. I would hesitate to go too far down the road until a lead is identified. As they say, talk is cheap :). It's finding someone willing to start and sustain the work that counts.
Overall, I think this sounds reasonable. I have some concerns on plowing ahead without addressing either the lack of go packaging guidelines or the packaging guidelines in general. Nothing that makes me want to shut it down though.
josh
-- Remy DeCausemaker decause@redhat.com Fedora Community Lead & Council Member http://whatcanidoforfedora.org 308C A504 0B47 1503 C9D9 E670 E633 A79B 0BB0 F6D9
----- Original Message -----
From: "Matthew Miller" mattdm@fedoraproject.org To: "Discussions with the Fedora Council and community" council-discuss@lists.fedoraproject.org Sent: Tuesday, September 29, 2015 5:07:16 PM Subject: Re: for discussion: Fedora OpenShift as an objective
On Tue, Sep 29, 2015 at 04:56:19PM -0400, Josh Boyer wrote:
Do you have someone in mind to lead this objective?
Not that I've specifically talked to about that yet.
If so, is there a reason they didn't propose this themselves?
Release early release often? I wanted to start the conversation — this isn't a real proposal yet.
/me touches his nose really fast ;)
Not it, --RemyD.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ council-discuss mailing list council-discuss@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct https://admin.fedoraproject.org/mailman/listinfo/council-discuss
The Fedora Project's mission is to lead the advancement of free and open source software and content as a collaborative community.
On Tue, 2015-09-29 at 16:56 -0400, Josh Boyer wrote:
On Tue, Sep 29, 2015 at 4:52 PM, Matthew Miller mattdm@fedoraproject.org wrote:
<snip good info>
I think this is something on the order of an Objective rather than just a change/feature proposal because it's actually a rather tall order. On the technical side, currently OpenShift can't be easily packaged because it includes some 200+ Go libraries, and we don't even have approved Go packaging guidelines. This probably means we'd be asking for a very large bundling exception (note 'Active upstream Security Team' as part of the justification). On the less technical but still important side, I'd like to see related marketing and documentation, and coordination with Fedora Atomic and the Fedora Cloud WG, and possibly with Fedora Server as well (I know OpenShift node as server role is already under some consideration).
Thoughts, comments, thrown vegetables?
Do you have someone in mind to lead this objective? If so, is there a reason they didn't propose this themselves?
I'm having a conversation about Fedora Server and OpenShift with Joe Brockmeier later this morning. I'll include this as a topic of conversation and see where it leads.
On 09/29/2015 08:52 PM, Matthew Miller wrote:
But now, there's a shiny new OpenShift v3, rewritten in Go. I'd like to talk about (and eventually if enough people think this is a good idea, officially propose) a 12-month (e.g, Fedora 24 and 25 cycle) initative to better our relationship with OpenShift, in order to put Fedora in a position of leadership in this important area of computing — and, thinking bigger, to advance the state of open source in this area by doing that.
Interesting perspective.
How exactly do you come to the conclusion that Fedora shipping Red Hat product somehow automatically becomes being in position of leadership in the relevant computing area?
I'm being serious so explain me in detail how it achieves that compared to other distribution shipping the exact same set of applications or why users of said products will be deploying it on Fedora as opposed to RHEL/CentOS in their IT environment for example?
Once you have explained that to the wider audience to how come this is not just being discussed in the relevant WG that might ship that application stack or for that matter those actually driving the initiative to misuse the community for early adoption of Red Hat products now in the name of open shift form a WG themselves if said application stack does not belong with any of the excising WG or for that matter the existing ones dont want it as a part of their portfolio.
JBG
On Wed, Sep 30, 2015 at 03:06:48PM +0000, Jóhann B. Guðmundsson wrote:
But now, there's a shiny new OpenShift v3, rewritten in Go. I'd like to talk about (and eventually if enough people think this is a good idea, officially propose) a 12-month (e.g, Fedora 24 and 25 cycle) initative to better our relationship with OpenShift, in order to put Fedora in a position of leadership in this important area of computing — and, thinking bigger, to advance the state of open source in this area by doing that.
Interesting perspective. How exactly do you come to the conclusion that Fedora shipping Red Hat product somehow automatically becomes being in position of leadership in the relevant computing area?
That's neither my conclusion _nor_ what I'm suggesting. So, I'm not sure how to answer that.
I'm being serious so explain me in detail how it achieves that compared to other distribution shipping the exact same set of applications or why users of said products will be deploying it on Fedora as opposed to RHEL/CentOS in their IT environment for example?
This is basically asking if Fedora has value at all to end users in IT environments. I think, very strongly, that it does. It's not for every case by any means, but as I noted in my original message in this thread, it's a good match for innovators and early adopters.
But it's not _just_ the leading edge and test labs. Fedora is also useful in any case where the deployment need is a good match for the Fedora values — chiefly Features and First, but definitely Friends as well. (And on OpenShift in specific, it's pure open source, and unlike CloudFoundry isn't built around an "open core" — so, Freedom.)
Fedora as popular in these cases is seem borne out by our download statistics for Fedora Server, as well as my anecdotal experience, both personal as a former sysadmin and from the talking with people I do at this job.
Additionally, Fedora as a project benefits when we have upstream development close. We get the developer energy and access to engineering for bugfixes, and we can offer the developers a leading-edge platform to develop on and to test against. And having all of this in Fedora benefits users, because Fedora provides an easy and attractive integrated platform on which to try new stuff. That's why I suggest user-developer communication channels in Fedora as a direct part of the objective.
Once you have explained that to the wider audience to how come this is not just being discussed in the relevant WG that might ship that application stack or for that matter those actually driving the initiative to misuse the community for early adoption of Red Hat products now in the name of open shift form a WG themselves if said application stack does not belong with any of the excising WG or for that matter the existing ones dont want it as a part of their portfolio.
I don't understand what you're saying at all in this paragraph.
On Tue, Sep 29, 2015 at 10:07 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Sep 29, 2015 at 04:56:19PM -0400, Josh Boyer wrote:
Do you have someone in mind to lead this objective?
Not that I've specifically talked to about that yet.
If so, is there a reason they didn't propose this themselves?
Release early release often? I wanted to start the conversation — this isn't a real proposal yet.
OpenShift is a large complex platform, if we don't have buy in from the OpenShift teams themselves I think we'll end up in a situation where we're constantly chasing our tail and all the issues involved and it won't be pretty for anyone. Having dealt with OpenShift Enterprise on premise I feel this is something everyone needs to buy into for it to be a success otherwise you end up with a bad experience for all Fedora, OpenShift and worse the end user.
That said, a lot of the core lower level components of OpenShift v3, like kubernetes, are already packaged and actively maintained in Fedora, assuming they don't need massive forks and need to be maintained twice, and because it uses docker as the container format and supports any of them it means we don't need to deal with cartridges and hell surrounding those I feel it's more likely to be an easier task over all than the previous attempt..... but there's a bunch of assumptions there ;-)
On Tue, Sep 29, 2015 at 3:56 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Sep 29, 2015 at 4:52 PM, Matthew Miller mattdm@fedoraproject.org wrote:
<snip good info>
I think this is something on the order of an Objective rather than just a change/feature proposal because it's actually a rather tall order. On the technical side, currently OpenShift can't be easily packaged because it includes some 200+ Go libraries, and we don't even have approved Go packaging guidelines. This probably means we'd be asking for a very large bundling exception (note 'Active upstream Security Team' as part of the justification). On the less technical but still important side, I'd like to see related marketing and documentation, and coordination with Fedora Atomic and the Fedora Cloud WG, and possibly with Fedora Server as well (I know OpenShift node as server role is already under some consideration).
Thoughts, comments, thrown vegetables?
Do you have someone in mind to lead this objective? If so, is there a reason they didn't propose this themselves?
Having come to the Fedora Engineering team from the OpenShift team I think I'd be a good candidate and we're already going to be running OpenShift in Fedora Release Engineering for the OSBS(OpenShift Build Service) portion of the Layered Image Build Service[0]. However, I should note that the OpenShift installation there will not be user accessible, it's just going to effectively be a build target for Koji so if we have plans/hopes/dreams of running our own OpenShift for Fedora users, that's a whole different ball of wax.
I didn't really think we needed a mass proposal or anything so I didn't write one (though I think my plans/goals were a minor subset of what Matt is proposing), I've already been working with upstream a little bit on this and as of a few weeks back I've become involved with making sure the upstream release packages are in a good state (previous release had some issues so I volunteered to help).
It's all in my COPR space[0] which is where it started long ago when I was on the OpenShift team, but the plan was to ultimately end up in the Fedora Proper repositories, was just a matter of finding time and there's still no official packaging guidelines for golang. As an aside, a number of folks in the upstream group has permissions on my COPR for builds and it's largely been a shared effort so far.
-AdamM
[0] - https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service [1] - https://copr.fedoraproject.org/coprs/maxamillion/origin-next/
josh _______________________________________________ council-discuss mailing list council-discuss@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct https://admin.fedoraproject.org/mailman/listinfo/council-discuss
The Fedora Project's mission is to lead the advancement of free and open source software and content as a collaborative community.
On Thu, Oct 8, 2015 at 11:03 PM, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Sep 29, 2015 at 10:07 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Sep 29, 2015 at 04:56:19PM -0400, Josh Boyer wrote:
Do you have someone in mind to lead this objective?
Not that I've specifically talked to about that yet.
If so, is there a reason they didn't propose this themselves?
Release early release often? I wanted to start the conversation — this isn't a real proposal yet.
OpenShift is a large complex platform, if we don't have buy in from the OpenShift teams themselves I think we'll end up in a situation where we're constantly chasing our tail and all the issues involved and it won't be pretty for anyone. Having dealt with OpenShift Enterprise on premise I feel this is something everyone needs to buy into for it to be a success otherwise you end up with a bad experience for all Fedora, OpenShift and worse the end user.
+1
It is a pretty size-able amount of work that I think we would definitely need shared responsibility and a good working relationship with upstream.
That said, a lot of the core lower level components of OpenShift v3, like kubernetes, are already packaged and actively maintained in Fedora, assuming they don't need massive forks and need to be maintained twice, and because it uses docker as the container format and supports any of them it means we don't need to deal with cartridges and hell surrounding those I feel it's more likely to be an easier task over all than the previous attempt..... but there's a bunch of assumptions there ;-)
OpenShift is based on kubernetes but because of the magic of golang, it's all statically linked at compile time. Therefore, OpenShift actually caries the entirety of kubernetes as a bundled library which unfortunately means that the current inclusion and continued maintenance of kubernetes in Fedora isn't likely to mean much unless there's a guarantee that it will always match the specific version of kubernetes that OpenShift is based on for API compatibility and then we could effectively strip out the bundled version and use the packaged version at build time. I'm not sure which is a better option though because I'm not yet sure how we want to track all the security nuances of giant piles of statically linked code. We probably want some recommendations from the Security Team.
-AdamM
council-discuss mailing list council-discuss@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct https://admin.fedoraproject.org/mailman/listinfo/council-discuss
The Fedora Project's mission is to lead the advancement of free and open source software and content as a collaborative community.
On Fri, Oct 9, 2015 at 10:10 AM, Adam Miller maxamillion@fedoraproject.org wrote:
On Thu, Oct 8, 2015 at 11:03 PM, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Sep 29, 2015 at 10:07 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Sep 29, 2015 at 04:56:19PM -0400, Josh Boyer wrote:
Do you have someone in mind to lead this objective?
Not that I've specifically talked to about that yet.
If so, is there a reason they didn't propose this themselves?
Release early release often? I wanted to start the conversation — this isn't a real proposal yet.
OpenShift is a large complex platform, if we don't have buy in from the OpenShift teams themselves I think we'll end up in a situation where we're constantly chasing our tail and all the issues involved and it won't be pretty for anyone. Having dealt with OpenShift Enterprise on premise I feel this is something everyone needs to buy into for it to be a success otherwise you end up with a bad experience for all Fedora, OpenShift and worse the end user.
+1
It is a pretty size-able amount of work that I think we would definitely need shared responsibility and a good working relationship with upstream.
That said, a lot of the core lower level components of OpenShift v3, like kubernetes, are already packaged and actively maintained in Fedora, assuming they don't need massive forks and need to be maintained twice, and because it uses docker as the container format and supports any of them it means we don't need to deal with cartridges and hell surrounding those I feel it's more likely to be an easier task over all than the previous attempt..... but there's a bunch of assumptions there ;-)
OpenShift is based on kubernetes but because of the magic of golang, it's all statically linked at compile time. Therefore, OpenShift actually caries the entirety of kubernetes as a bundled library which unfortunately means that the current inclusion and continued maintenance of kubernetes in Fedora isn't likely to mean much unless there's a guarantee that it will always match the specific version of kubernetes that OpenShift is based on for API compatibility and then we could effectively strip out the bundled version and use the packaged version at build time. I'm not sure which is a better option though because I'm not yet sure how we want to track all the security nuances of giant piles of statically linked code. We probably want some recommendations from the Security Team.
Actually it turns out that the Fedora kubernetes maintainer is already using the OpenShift bundled kubernetes as the source for the kubernetes package[0] so there might already be plans to move the direction of aligning on the versions. It should be noted for posterity that the bundled kubernetes in the OpenShift source tree is unmodified upstream kubernetes and can be tracked back to an upstream git commit via the OpenShift godeps json[1].
-AdamM
[0] - http://pkgs.fedoraproject.org/cgit/kubernetes.git/tree/kubernetes.spec [1] - https://github.com/openshift/origin/blob/master/Godeps/Godeps.json
-AdamM
council-discuss mailing list council-discuss@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct https://admin.fedoraproject.org/mailman/listinfo/council-discuss
The Fedora Project's mission is to lead the advancement of free and open source software and content as a collaborative community.
On Fri, Oct 09, 2015 at 10:10:04AM -0500, Adam Miller wrote:
OpenShift is based on kubernetes but because of the magic of golang, it's all statically linked at compile time. Therefore, OpenShift actually caries the entirety of kubernetes as a bundled library which
Uhm, how is the bundling related to the static linking performed by the Go compiler? Those are orthogonal issues. We can build static binaries from archives or source code (shipped as separate Fedora packages and pulled in through BuildRequires) without doing any bundling at the SRPM level.
unfortunately means that the current inclusion and continued maintenance of kubernetes in Fedora isn't likely to mean much unless there's a guarantee that it will always match the specific version of kubernetes that OpenShift is based on for API compatibility and then
That seems to be the actual problem. The lack of any commitment to maintain a stable API.
council-discuss@lists.fedoraproject.org
-
Adam Miller -
Josh Boyer -
Jóhann B. Guðmundsson -
Lars Seipel -
Matthew Miller -
Peter Robinson -
Remy DeCausemaker -
Stephen Gallagher