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.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.o...@rackspace.com>
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@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...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
