Open Stack

----- Original Message -----
> From: "Steve Gordon" <sgordon at redhat.com>
> To: "Guz Egor" <guz_egor at yahoo.com>, "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> 
> ----- Original Message -----
> > From: "Guz Egor" <guz_egor at yahoo.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > 
> > Adrian,
> > I disagree, host OS is very important for operators because of integration
> > with all internal tools/repos/etc.
> > I think it make sense to limit OS support in Magnum main source. But not
> > sure
> > that Fedora Atomic is right choice,first of all there is no documentation
> > about it and I don't think it's used/tested a lot by Docker/Kub/Mesos
> > community.
> 
> Project Atomic documentation for the most part lives here:
> 
>     http://www.projectatomic.io/docs/
> 
> To help us improve it, it would be useful to know what you think is missing.
> E.g. I saw recently in the IRC channel it was discussed that there is no
> documentation on (re)building the image but this is the first hit in a
> Google search for same and it seems to largely match what has been copied
> into Magnum's docs for same:
> 
>     http://www.projectatomic.io/blog/2014/08/build-your-own-atomic-centos-or-fedora/
> 
> I have no doubt that there are areas where the documentation is lacking, but
> it's difficult to resolve a claim that there is no documentation at all. I
> recently kicked off a thread over on the atomic list to try and relay some
> of the concerns that were raised on this list and in the IRC channel
> recently, it would be great if Magnum folks could chime in with more
> specifics:
> 
>     https://lists.projectatomic.io/projectatomic-archives/atomic/2016-February/thread.html#00009
> 
> Separately I had asked about containerization of kubernetes/etcd/flannel
> which remains outstanding:
> 
>     https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/XICO4NJCTPI43AWG332EIM2HNFYPZ6ON/
> 
> Fedora Atomic builds do seem to be hitting their planned two weekly update
> cadence now though which may alleviate this concern at least somewhat in the
> interim:
> 
>     https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/CW5BQS3ODAVYJGAJGAZ6UA3XQMKEISVJ/
>     https://fedorahosted.org/cloud/ticket/139
> 
> Thanks,
> 
> Steve

I meant to add, I don't believe choosing a single operating system image to support - regardless of which it is - is the right move for users and largely agree with what Ton Ngo put forward in his most recent post in the thread. I'm simply highlighting that there are folks willing/able to work on improving things from the Atomic side and we are endeavoring to provide them actionable feedback from the Magnum community to do so.

Thanks,

Steve

> > It make sense to go with Ubuntu (I believe it's still most adopted
> > platform in all three COEs and OpenStack deployments)     and CoreOS (is
> > highly adopted/tested in Kub community and Mesosphere DCOS uses it as
> > well).
> >  We can implement CoreOS support as driver and users can use it as
> >  reference
> > implementation.
> 
> 
> > --- Egor
> >       From: Adrian Otto <adrian.otto at rackspace.com>
> >  To: OpenStack Development Mailing List (not for usage questions)
> >  <openstack-dev at lists.openstack.org>
> >  Sent: Monday, February 29, 2016 10:36 AM
> >  Subject: Re: [openstack-dev] [magnum] Discussion of supporting
> >  single/multiple OS distro
> >    
> > Consider this: Which OS runs on the bay nodes is not important to end
> > users.
> > What matters to users is the environments their containers execute in,
> > which
> > has only one thing in common with the bay node OS: the kernel. The linux
> > syscall interface is stable enough that the various linux distributions can
> > all run concurrently in neighboring containers sharing same kernel. There
> > is
> > really no material reason why the bay OS choice must match what distro the
> > container is based on. Although I’m persuaded by Hongbin’s concern to
> > mitigate risk of future changes WRT whatever OS distro is the prevailing
> > one
> > for bay nodes, there are a few items of concern about duality I’d like to
> > zero in on:
> > 1) Participation from Magnum contributors to support the CoreOS specific
> > template features has been weak in recent months. By comparison,
> > participation relating to Fedora/Atomic have been much stronger.
> > 2) Properly testing multiple bay node OS distros (would) significantly
> > increase the run time and complexity of our functional tests.
> > 3) Having support for multiple bay node OS choices requires more extensive
> > documentation, and more comprehensive troubleshooting details.
> > If we proceed with just one supported disto for bay nodes, and offer
> > extensibility points to allow alternates to be used in place of it, we
> > should be able to address the risk concern of the chosen distro by
> > selecting
> > an alternate when that change is needed, by using those extensibility
> > points. These include the ability to specify your own bay image, and the
> > ability to use your own associated Heat template.
> > I see value in risk mitigation, it may make sense to simplify in the short
> > term and address that need when it becomes necessary. My point of view
> > might
> > be different if we had contributors willing and ready to address the
> > variety
> > of drawbacks that accompany the strategy of supporting multiple bay node OS
> > choices. In absence of such a community interest, my preference is to
> > simplify to increase our velocity. This seems to me to be a relatively easy
> > way to reduce complexity around heat template versioning. What do you
> > think?
> > Thanks,
> > Adrian
> > 
> > On Feb 29, 2016, at 8:40 AM, Hongbin Lu <hongbin.lu at huawei.com> wrote:
> > Hi team,  This is a continued discussion from a review [1]. Corey O'Brien
> > suggested to have Magnum support a single OS distro (Atomic). I disagreed.
> > I
> > think we should bring the discussion to here to get broader set of inputs.
> >    Corey O'Brien From the midcycle, we decided we weren't going to continue
> > to support 2 different versions of the k8s template. Instead, we were going
> > to maintain the Fedora Atomic version of k8s and remove the coreos
> > templates
> > from the tree. I don't think we should continue to develop features for
> > coreos k8s if that is true. In addition, I don't think we should break the
> > coreos template by adding the trust token as a heat parameter.  Hongbin Lu
> > I
> > was on the midcycle and I don't remember any decision to remove CoreOS
> > support. Why you want to remove CoreOS templates from the tree. Please note
> > that this is a very big decision and please discuss it with the team
> > thoughtfully and make sure everyone agree.  Corey O'Brien Removing the
> > coreos templates was a part of the COE drivers decision. Since each COE
> > driver will only support 1 distro+version+coe we discussed which ones to
> > support in tree. The decision was that instead of trying to support every
> > distro and every version for every coe, the magnum tree would only have
> > support for 1 version of 1 distro for each of the 3 COEs
> > (swarm/docker/mesos). Since we already are going to support Atomic for
> > swarm, removing coreos and keeping Atomic for kubernetes was the favored
> > choice.  Hongbin Lu Strongly disagree. It is a huge risk to support a
> > single
> > distro. The selected distro could die in the future. Who knows. Why make
> > Magnum take this huge risk? Again, the decision of supporting single distro
> > is a very big decision. Please bring it up to the team and have it discuss
> > thoughtfully before making any decision. Also, Magnum doesn't have to
> > support every distro and every version for every coe, but should support
> > *more than one* popular distro for some COEs (especially for the popular
> > COEs).  Corey O'Brien The discussion at the midcycle started from the idea
> > of adding support for RHEL and CentOS. We all discussed and decided that we
> > wouldn't try to support everything in tree. Magnum would provide support
> > in-tree for 1 per COE and the COE driver interface would allow others to
> > add
> > support for their preferred distro out of tree.  Hongbin Lu I agreed the
> > part that "we wouldn't try to support everything in tree". That doesn't
> > imply the decision to support single distro. Again, support single distro
> > is
> > a huge risk. Why make Magnum take this huge risk?  [1]
> >  https://review.openstack.org/#/c/277284/  Best regards, Hongbin
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> > 
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> > 
> > 
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> --
> Steve Gordon,
> Principal Product Manager,
> Red Hat OpenStack Platform
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Steve Gordon,
Principal Product Manager,
Red Hat OpenStack Platform