On Fri, Oct 9, 2015 at 10:10 AM, Adam Miller <maxamillion@xxxxxxxxxxxxxxxxx> wrote: > On Thu, Oct 8, 2015 at 11:03 PM, Peter Robinson <pbrobinson@xxxxxxxxx> wrote: >> On Tue, Sep 29, 2015 at 10:07 PM, Matthew Miller >> <mattdm@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx >> 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. _______________________________________________ council-discuss mailing list council-discuss@xxxxxxxxxxxxxxxxxxxxxxx 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.
