3:52 p.m.
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%8...
2.
http://www.infoworld.com/article/2608445/cloud-computing/review--openshif...
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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3:56 p.m.
On Tue, Sep 29, 2015 at 4:52 PM, Matthew Miller
<mattdm(a)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
4:07 p.m.
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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
5:16 p.m.
On Tue, Sep 29, 2015 at 5:07 PM, Matthew Miller
<mattdm(a)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
5:16 p.m.
--
Remy DeCausemaker
<decause(a)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(a)fedoraproject.org>
To: "Discussions with the Fedora Council and community"
<council-discuss(a)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(a)fedoraproject.org>
Fedora Project Leader
_______________________________________________
council-discuss mailing list
council-discuss(a)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.
11:03 p.m.
On Tue, Sep 29, 2015 at 10:07 PM, Matthew Miller
<mattdm(a)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 ;-)
10:10 a.m.
On Thu, Oct 8, 2015 at 11:03 PM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Tue, Sep 29, 2015 at 10:07 PM, Matthew Miller
<mattdm(a)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(a)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.
11:15 a.m.
On Fri, Oct 9, 2015 at 10:10 AM, Adam Miller
<maxamillion(a)fedoraproject.org> wrote:
On Thu, Oct 8, 2015 at 11:03 PM, Peter Robinson
<pbrobinson(a)gmail.com> wrote:
> On Tue, Sep 29, 2015 at 10:07 PM, Matthew Miller
> <mattdm(a)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(a)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.
3:27 p.m.
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.
7:05 a.m.
On Tue, 2015-09-29 at 16:56 -0400, Josh Boyer wrote:
On Tue, Sep 29, 2015 at 4:52 PM, Matthew Miller
<mattdm(a)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.
10:03 a.m.
On Tue, Sep 29, 2015 at 3:56 PM, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Tue, Sep 29, 2015 at 4:52 PM, Matthew Miller
<mattdm(a)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(a)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.
10:06 a.m.
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
11:16 a.m.
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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3120
days inactive
3130
days old
council-discuss@lists.fedoraproject.org
12 comments
8 participants
participants (8)
-
Adam Miller -
Josh Boyer -
Jóhann B. Guðmundsson -
Lars Seipel -
Matthew Miller -
Peter Robinson -
Remy DeCausemaker -
Stephen Gallagher