----- Original Message ----- > From: "Steve Gordon" <sgor...@redhat.com> > To: "Guz Egor" <guz_e...@yahoo.com>, "OpenStack Development Mailing List (not > for usage questions)" > <openstack-dev@lists.openstack.org> > > ----- Original Message ----- > > From: "Guz Egor" <guz_e...@yahoo.com> > > To: "OpenStack Development Mailing List (not for usage questions)" > > <openstack-dev@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/cl...@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/cl...@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.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 > > > > -- > Steve Gordon, > Principal Product Manager, > Red Hat OpenStack Platform > > __________________________________________________________________________ > 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 > -- Steve Gordon, Principal Product Manager, Red Hat OpenStack Platform __________________________________________________________________________ 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
