<html><body><p>I tend to agree that multiple os support is OK (we can limited to popular ones first, like redhat os, ubuntu os) But we not tend to cover all OS, it would much burden for maintain, and extra small requirements should be maintain by 3-rd party if possible(through drivers).<br><br><br><br><br>Thanks<br><br><br><br>Best Wishes,<br>--------------------------------------------------------------------------------<br>Kai Qiang Wu (Î⿪ǿ Kennan£©<br>IBM China System and Technology Lab, Beijing<br><br>E-mail: wkqwu@cn.ibm.com<br>Tel: 86-10-82451647<br>Address: Building 28(Ring Building), ZhongGuanCun Software Park, <br> No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193<br>--------------------------------------------------------------------------------<br>Follow your heart. You are miracle! <br><br><img width="16" height="16" src="cid:1__=8FBBF5FADFDF932E8f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Steve Gordon ---01/03/2016 08:25:46 pm-------- Original Message ----- > From: "Steve Gordon" <sgordon"><font color="#424282">Steve Gordon ---01/03/2016 08:25:46 pm-------- Original Message ----- > From: "Steve Gordon" <sgordon@redhat.com></font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Steve Gordon <sgordon@redhat.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">"OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">Martin Andre <maandre@redhat.com>, Josh Berkus <jberkus@redhat.com></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">01/03/2016 08:25 pm</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt>----- Original Message -----<br>> From: "Steve Gordon" <sgordon@redhat.com><br>> To: "Guz Egor" <guz_egor@yahoo.com>, "OpenStack Development Mailing List (not for usage questions)"<br>> <openstack-dev@lists.openstack.org><br>> <br>> ----- Original Message -----<br>> > From: "Guz Egor" <guz_egor@yahoo.com><br>> > To: "OpenStack Development Mailing List (not for usage questions)"<br>> > <openstack-dev@lists.openstack.org><br>> > <br>> > Adrian,<br>> > I disagree, host OS is very important for operators because of integration<br>> > with all internal tools/repos/etc.<br>> > I think it make sense to limit OS support in Magnum main source. But not<br>> > sure<br>> > that Fedora Atomic is right choice,first of all there is no documentation<br>> > about it and I don't think it's used/tested a lot by Docker/Kub/Mesos<br>> > community.<br>> <br>> Project Atomic documentation for the most part lives here:<br>> <br>> </tt><tt><a href="http://www.projectatomic.io/docs/">http://www.projectatomic.io/docs/</a></tt><tt><br>> <br>> To help us improve it, it would be useful to know what you think is missing.<br>> E.g. I saw recently in the IRC channel it was discussed that there is no<br>> documentation on (re)building the image but this is the first hit in a<br>> Google search for same and it seems to largely match what has been copied<br>> into Magnum's docs for same:<br>> <br>> </tt><tt><a href="http://www.projectatomic.io/blog/2014/08/build-your-own-atomic-centos-or-fedora/">http://www.projectatomic.io/blog/2014/08/build-your-own-atomic-centos-or-fedora/</a></tt><tt><br>> <br>> I have no doubt that there are areas where the documentation is lacking, but<br>> it's difficult to resolve a claim that there is no documentation at all. I<br>> recently kicked off a thread over on the atomic list to try and relay some<br>> of the concerns that were raised on this list and in the IRC channel<br>> recently, it would be great if Magnum folks could chime in with more<br>> specifics:<br>> <br>> </tt><tt><a href="https://lists.projectatomic.io/projectatomic-archives/atomic/2016-February/thread.html#00009">https://lists.projectatomic.io/projectatomic-archives/atomic/2016-February/thread.html#00009</a></tt><tt><br>> <br>> Separately I had asked about containerization of kubernetes/etcd/flannel<br>> which remains outstanding:<br>> <br>> </tt><tt><a href="https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/XICO4NJCTPI43AWG332EIM2HNFYPZ6ON/">https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/XICO4NJCTPI43AWG332EIM2HNFYPZ6ON/</a></tt><tt><br>> <br>> Fedora Atomic builds do seem to be hitting their planned two weekly update<br>> cadence now though which may alleviate this concern at least somewhat in the<br>> interim:<br>> <br>> </tt><tt><a href="https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/CW5BQS3ODAVYJGAJGAZ6UA3XQMKEISVJ/">https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/CW5BQS3ODAVYJGAJGAZ6UA3XQMKEISVJ/</a></tt><tt><br>> </tt><tt><a href="https://fedorahosted.org/cloud/ticket/139">https://fedorahosted.org/cloud/ticket/139</a></tt><tt><br>> <br>> Thanks,<br>> <br>> Steve<br><br>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.<br><br>Thanks,<br><br>Steve<br><br>> > It make sense to go with Ubuntu (I believe it's still most adopted<br>> > platform in all three COEs and OpenStack deployments) and CoreOS (is<br>> > highly adopted/tested in Kub community and Mesosphere DCOS uses it as<br>> > well).<br>> > We can implement CoreOS support as driver and users can use it as<br>> > reference<br>> > implementation.<br>> <br>> <br>> > --- Egor<br>> > From: Adrian Otto <adrian.otto@rackspace.com><br>> > To: OpenStack Development Mailing List (not for usage questions)<br>> > <openstack-dev@lists.openstack.org><br>> > Sent: Monday, February 29, 2016 10:36 AM<br>> > Subject: Re: [openstack-dev] [magnum] Discussion of supporting<br>> > single/multiple OS distro<br>> > <br>> > Consider this: Which OS runs on the bay nodes is not important to end<br>> > users.<br>> > What matters to users is the environments their containers execute in,<br>> > which<br>> > has only one thing in common with the bay node OS: the kernel. The linux<br>> > syscall interface is stable enough that the various linux distributions can<br>> > all run concurrently in neighboring containers sharing same kernel. There<br>> > is<br>> > really no material reason why the bay OS choice must match what distro the<br>> > container is based on. Although I¡¯m persuaded by Hongbin¡¯s concern to<br>> > mitigate risk of future changes WRT whatever OS distro is the prevailing<br>> > one<br>> > for bay nodes, there are a few items of concern about duality I¡¯d like to<br>> > zero in on:<br>> > 1) Participation from Magnum contributors to support the CoreOS specific<br>> > template features has been weak in recent months. By comparison,<br>> > participation relating to Fedora/Atomic have been much stronger.<br>> > 2) Properly testing multiple bay node OS distros (would) significantly<br>> > increase the run time and complexity of our functional tests.<br>> > 3) Having support for multiple bay node OS choices requires more extensive<br>> > documentation, and more comprehensive troubleshooting details.<br>> > If we proceed with just one supported disto for bay nodes, and offer<br>> > extensibility points to allow alternates to be used in place of it, we<br>> > should be able to address the risk concern of the chosen distro by<br>> > selecting<br>> > an alternate when that change is needed, by using those extensibility<br>> > points. These include the ability to specify your own bay image, and the<br>> > ability to use your own associated Heat template.<br>> > I see value in risk mitigation, it may make sense to simplify in the short<br>> > term and address that need when it becomes necessary. My point of view<br>> > might<br>> > be different if we had contributors willing and ready to address the<br>> > variety<br>> > of drawbacks that accompany the strategy of supporting multiple bay node OS<br>> > choices. In absence of such a community interest, my preference is to<br>> > simplify to increase our velocity. This seems to me to be a relatively easy<br>> > way to reduce complexity around heat template versioning. What do you<br>> > think?<br>> > Thanks,<br>> > Adrian<br>> > <br>> > On Feb 29, 2016, at 8:40 AM, Hongbin Lu <hongbin.lu@huawei.com> wrote:<br>> > Hi team, This is a continued discussion from a review [1]. Corey O'Brien<br>> > suggested to have Magnum support a single OS distro (Atomic). I disagreed.<br>> > I<br>> > think we should bring the discussion to here to get broader set of inputs.<br>> > Corey O'Brien From the midcycle, we decided we weren't going to continue<br>> > to support 2 different versions of the k8s template. Instead, we were going<br>> > to maintain the Fedora Atomic version of k8s and remove the coreos<br>> > templates<br>> > from the tree. I don't think we should continue to develop features for<br>> > coreos k8s if that is true. In addition, I don't think we should break the<br>> > coreos template by adding the trust token as a heat parameter. Hongbin Lu<br>> > I<br>> > was on the midcycle and I don't remember any decision to remove CoreOS<br>> > support. Why you want to remove CoreOS templates from the tree. Please note<br>> > that this is a very big decision and please discuss it with the team<br>> > thoughtfully and make sure everyone agree. Corey O'Brien Removing the<br>> > coreos templates was a part of the COE drivers decision. Since each COE<br>> > driver will only support 1 distro+version+coe we discussed which ones to<br>> > support in tree. The decision was that instead of trying to support every<br>> > distro and every version for every coe, the magnum tree would only have<br>> > support for 1 version of 1 distro for each of the 3 COEs<br>> > (swarm/docker/mesos). Since we already are going to support Atomic for<br>> > swarm, removing coreos and keeping Atomic for kubernetes was the favored<br>> > choice. Hongbin Lu Strongly disagree. It is a huge risk to support a<br>> > single<br>> > distro. The selected distro could die in the future. Who knows. Why make<br>> > Magnum take this huge risk? Again, the decision of supporting single distro<br>> > is a very big decision. Please bring it up to the team and have it discuss<br>> > thoughtfully before making any decision. Also, Magnum doesn't have to<br>> > support every distro and every version for every coe, but should support<br>> > *more than one* popular distro for some COEs (especially for the popular<br>> > COEs). Corey O'Brien The discussion at the midcycle started from the idea<br>> > of adding support for RHEL and CentOS. We all discussed and decided that we<br>> > wouldn't try to support everything in tree. Magnum would provide support<br>> > in-tree for 1 per COE and the COE driver interface would allow others to<br>> > add<br>> > support for their preferred distro out of tree. Hongbin Lu I agreed the<br>> > part that "we wouldn't try to support everything in tree". That doesn't<br>> > imply the decision to support single distro. Again, support single distro<br>> > is<br>> > a huge risk. Why make Magnum take this huge risk? [1]<br>> > </tt><tt><a href="https://review.openstack.org/#/c/277284/">https://review.openstack.org/#/c/277284/</a></tt><tt> Best regards, Hongbin<br>> > __________________________________________________________________________<br>> > OpenStack Development Mailing List (not for usage questions)<br>> > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> > </tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br>> > <br>> > <br>> > __________________________________________________________________________<br>> > OpenStack Development Mailing List (not for usage questions)<br>> > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> > </tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br>> > <br>> > <br>> > <br>> > __________________________________________________________________________<br>> > OpenStack Development Mailing List (not for usage questions)<br>> > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> > </tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br>> > <br>> <br>> --<br>> Steve Gordon,<br>> Principal Product Manager,<br>> Red Hat OpenStack Platform<br>> <br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> </tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br>> <br><br>-- <br>Steve Gordon,<br>Principal Product Manager,<br>Red Hat OpenStack Platform<br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br></tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br></tt><br><br><BR>
</body></html>