<html><body><p>Hi  Stdake,<br><br>There is a patch about Atomic 23 support in Magnum.  And atomic 23 uses kubernetes 1.0.6, and docker 1.9.1. <br>From Steve Gordon, I learnt they did have a two-weekly release. To me it seems each atomic 23 release not much difference, (minor change)<br>The major rebases/updates may still have to wait for e.g. Fedora Atomic 24.  <br><br>So maybe we not need to test every Atomic 23 two-weekly.<br>Pick one or update old, when we find it is integrated with new kubernetes or docker, etcd etc. If other small changes(not include security), seems not need to update so frequently, it can save some efforts.<br><br><br>What do you think ?<br><br>Thanks<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:2__=8FBBF5EBDF95CDA98f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for "Steven Dake (stdake)" ---16/03/2016 03:23:20 am---WFM as long as we stick to the spirit of the propo"><font color="#424282">"Steven Dake (stdake)" ---16/03/2016 03:23:20 am---WFM as long as we stick to the spirit of the proposal and don't end up in a situation where there is</font><br><br><font size="2" color="#5F5F5F">From:        </font><font size="2">"Steven Dake (stdake)" <stdake@cisco.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">Date:        </font><font size="2">16/03/2016 03:23 am</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><font face="Calibri">WFM as long as we stick to the spirit of the proposal and don't end up in a situation where there is only one distribution.  Others in the thread had indicated there would be only one distribution in tree, which I'd find disturbing for reasons already described on this thread.</font><br><br><font face="Calibri">While we are about it, we should move to the latest version of atomic and chase atomic every two weeks on their release.  Thoughts?</font><br><br><font face="Calibri">Regards</font><br><font face="Calibri">-steve</font><br><br><br><b><font face="Calibri">From: </font></b><font face="Calibri">Hongbin Lu <</font><a href="mailto:hongbin.lu@huawei.com"><u><font color="#0000FF" face="Calibri">hongbin.lu@huawei.com</font></u></a><font face="Calibri">></font><b><font face="Calibri"><br>Reply-To: </font></b><font face="Calibri">"OpenStack Development Mailing List (not for usage questions)" <</font><a href="mailto:openstack-dev@lists.openstack.org"><u><font color="#0000FF" face="Calibri">openstack-dev@lists.openstack.org</font></u></a><font face="Calibri">></font><b><font face="Calibri"><br>Date: </font></b><font face="Calibri">Monday, March 14, 2016 at 8:10 PM</font><b><font face="Calibri"><br>To: </font></b><font face="Calibri">"OpenStack Development Mailing List (not for usage questions)" <</font><a href="mailto:openstack-dev@lists.openstack.org"><u><font color="#0000FF" face="Calibri">openstack-dev@lists.openstack.org</font></u></a><font face="Calibri">></font><b><font face="Calibri"><br>Subject: </font></b><font face="Calibri">Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro</font><br>
<ul><ul><font color="#1F497D" face="Calibri"> </font><br><font color="#1F497D" face="Calibri"> </font><ul><ul><b><font face="Tahoma">From:</font></b><font face="Tahoma"> Adrian Otto [</font><a href="mailto:adrian.otto@rackspace.com"><u><font color="#0000FF" face="Tahoma">mailto:adrian.otto@rackspace.com</font></u></a><font face="Tahoma">] </font><b><font face="Tahoma"><br>Sent:</font></b><font face="Tahoma"> March-14-16 4:49 PM</font><b><font face="Tahoma"><br>To:</font></b><font face="Tahoma"> OpenStack Development Mailing List (not for usage questions)</font><b><font face="Tahoma"><br>Subject:</font></b><font face="Tahoma"> Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Steve, </font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">I think you may have misunderstood our intent here. We are not seeking to lock in to a single OS vendor. Each COE driver can have a different OS. We can have multiple drivers per COE. The point is that drivers should be simple, and therefore should support one Bay node OS each. That would mean taking what we have today in our Kubernetes Bay type implementation and breaking it down into two drivers: one for CoreOS and another for Fedora/Atomic. New drivers would start out in a contrib directory where complete functional testing would not be required. In order to graduate one out of contrib and into the realm of support of the Magnum dev team, it would need to have a full set of tests, and someone actively maintaining it.</font></ul></ul><font color="#1F497D" face="Calibri">OK. It sounds like the proposal allows more than one OS to be in-tree, as long as the second OS goes through an incubation process. If that is what you mean, it sounds reasonable to me.</font><ul><ul><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Multi-personality driers would be relatively complex. That approach would slow down COE specific feature development, and complicate maintenance that is needed as new versions of the dependency chain are bundled in (docker, k8s, etcd, etc.). We have all agreed that having integration points that allow for alternate OS selection is still our direction. This follows the pattern that we set previously when deciding what networking options to support. We will have one that¡¯s included as a default, and a way to plug in alternates.</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Here is what I expect to see when COE drivers are implemented:</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Docker Swarm: </font><br><font size="4" face="Times New Roman">Default driver Fedora/Atomic</font><br><font size="4" face="Times New Roman">Alternate driver: TBD</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Kubernetes: </font><br><font size="4" face="Times New Roman">Default driver Fedora/Atomic</font><br><font size="4" face="Times New Roman">Alternate driver: CoreOS</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Apache Mesos/Marathon: </font><br><font size="4" face="Times New Roman">Default driver: Ubuntu</font><br><font size="4" face="Times New Roman">Alternate driver: TBD</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">We can allow an arbitrary number of alternates. Those TBD items can be initially added to the contrib directory, and with the right level of community support can be advanced to defaults if shown to work better, be more straightforward to maintain, be more secure, or whatever criteria is important to us when presented with the choice. Such criteria will be subject to community consensus. This should allow for free experimentation with alternates to allow for innovation. See how this is not locking in a single OS vendor?</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Adrian</font><br><font size="4" face="Times New Roman"> </font><ul><ul><font size="4" face="Times New Roman">On Mar 14, 2016, at 12:41 PM, Steven Dake (stdake) <</font><a href="mailto:stdake@cisco.com"><u><font size="4" color="#0000FF" face="Times New Roman">stdake@cisco.com</font></u></a><font size="4" face="Times New Roman">> wrote:</font><br><font size="4" face="Times New Roman"> </font><br><font face="Calibri">Hongbin,</font><br><font face="Calibri"> </font><br><font face="Calibri">When we are at a disagreement in the Kolla core team, we have the Kolla core reviewers vote on the matter. This is typical standard OpenStack best practice.</font><br><font face="Calibri"> </font><br><font face="Calibri">I think the vote would be something like</font><br><font face="Calibri">"Implement one OS/COE/network/storage prototype, or implement many."</font><br><font face="Calibri"> </font><br><font face="Calibri">I don't have a horse in this race, but I think it would be seriously damaging to Magnum to lock in to a single vendor.</font><br><font face="Calibri"> </font><br><font face="Calibri">Regards</font><br><font face="Calibri">-steve</font><br><font face="Calibri"> </font><br><font face="Calibri"> </font><br><b><font face="Calibri">From: </font></b><font face="Calibri">Hongbin Lu <</font><a href="mailto:hongbin.lu@huawei.com"><u><font color="#800080" face="Calibri">hongbin.lu@huawei.com</font></u></a><font face="Calibri">></font><b><font face="Calibri"><br>Reply-To: </font></b><font face="Calibri">"OpenStack Development Mailing List (not for usage questions)" <</font><a href="mailto:openstack-dev@lists.openstack.org"><u><font color="#800080" face="Calibri">openstack-dev@lists.openstack.org</font></u></a><font face="Calibri">></font><b><font face="Calibri"><br>Date: </font></b><font face="Calibri">Monday, March 7, 2016 at 10:06 AM</font><b><font face="Calibri"><br>To: </font></b><font face="Calibri">"OpenStack Development Mailing List (not for usage questions)" <</font><a href="mailto:openstack-dev@lists.openstack.org"><u><font color="#800080" face="Calibri">openstack-dev@lists.openstack.org</font></u></a><font face="Calibri">></font><b><font face="Calibri"><br>Subject: </font></b><font face="Calibri">Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro</font><br><font face="Calibri"> </font><br><font color="#1F497D" face="Calibri"> </font><br><font color="#1F497D" face="Calibri"> </font><ul><ul><b><font face="Tahoma">From:</font></b><font face="Tahoma"> Corey O'Brien [</font><a href="mailto:coreypobrien@gmail.com"><u><font color="#800080" face="Tahoma">mailto:coreypobrien@gmail.com</font></u></a><font face="Tahoma">] </font><b><font face="Tahoma"><br>Sent:</font></b><font face="Tahoma"> March-07-16 8:11 AM</font><b><font face="Tahoma"><br>To:</font></b><font face="Tahoma"> OpenStack Development Mailing List (not for usage questions)</font><b><font face="Tahoma"><br>Subject:</font></b><font face="Tahoma"> Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Hongbin, I think the offer to support different OS options is a perfect example both of what we want and what we don't want. We definitely want to allow for someone like yourself to maintain templates for whatever OS they want and to have that option be easily integrated in to a Magnum deployment. However, when developing features or bug fixes, we can't wait for you to have time to add it for whatever OS you are promising to maintain.</font></ul></ul><font color="#1F497D" face="Calibri">It might be true that supporting additional OS could slow down the development speed, but the key question is how much the impact will be. Does it outweigh the benefits? IMO, the impact doesn¡¯t seem to be significant, given the fact that most features and bug fixes are OS agnostic. Also, keep in mind that every features we introduced (variety of COEs, variety of Nova virt-driver, variety of network driver, variety of volume driver, variety of ¡­) incurs a maintenance overhead. If you want an optimal development speed, we will be limited to support a single COE/virt driver/network driver/volume driver. I guess that is not the direction we like to be?</font><br><font color="#1F497D" face="Calibri"> </font><ul><ul><font size="4" face="Times New Roman">Instead, we would all be forced to develop the feature for that OS as well. If every member of the team had a special OS like that we'd all have to maintain all of them.</font></ul></ul><font color="#1F497D" face="Calibri">To be clear, I don¡¯t have a special OS, I guess neither do others who disagreed in this thread.</font><ul><ul><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Alternatively, what was agreed on by most at the midcycle was that if someone like yourself wanted to support a specific OS option, we would have an easy place for those contributions to go without impacting the rest of the team. The team as a whole would agree to develop all features for at least the reference OS.</font></ul></ul><font color="#1F497D" face="Calibri">Could we re-confirm that this is a team agreement? There is no harm to re-confirm it in the design summit/ML/team meeting. Frankly, it doesn¡¯t seem to be.</font><ul><ul><font color="#1F497D" face="Calibri"> </font><br><font size="4" face="Times New Roman">Then individuals or companies who are passionate about an alternative OS can develop the features for that OS.</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Corey</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">On Sat, Mar 5, 2016 at 12:30 AM Hongbin Lu <</font><a href="mailto:hongbin.lu@huawei.com"><u><font size="4" color="#800080" face="Times New Roman">hongbin.lu@huawei.com</font></u></a><font size="4" face="Times New Roman">> wrote:</font><br><font color="#1F497D" face="Calibri"> </font><br><font color="#1F497D" face="Calibri"> </font><ul><ul><b><font face="Tahoma">From:</font></b><font face="Tahoma"> Adrian Otto [mailto:</font><a href="mailto:adrian.otto@rackspace.com" target="_blank"><u><font color="#800080" face="Tahoma">adrian.otto@rackspace.com</font></u></a><font face="Tahoma">] </font><b><font face="Tahoma"><br>Sent:</font></b><font face="Tahoma"> March-04-16 6:31 PM</font><br><b><font face="Tahoma"><br>To:</font></b><font face="Tahoma"> OpenStack Development Mailing List (not for usage questions)</font><br><b><font face="Tahoma">Subject:</font></b><font face="Tahoma"> Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Steve, </font><br><font size="4" face="Times New Roman"> </font><ul><ul><font size="4" face="Times New Roman">On Mar 4, 2016, at 2:41 PM, Steven Dake (stdake) <</font><a href="mailto:stdake@cisco.com" target="_blank"><u><font size="4" color="#800080" face="Times New Roman">stdake@cisco.com</font></u></a><font size="4" face="Times New Roman">> wrote:</font><br><font face="Calibri"> </font><br><b><font face="Calibri">From: </font></b><font face="Calibri">Adrian Otto <</font><a href="mailto:adrian.otto@rackspace.com" target="_blank"><u><font color="#800080" face="Calibri">adrian.otto@rackspace.com</font></u></a><font face="Calibri">></font><b><font face="Calibri"><br>Reply-To: </font></b><font face="Calibri">"OpenStack Development Mailing List (not for usage questions)" <</font><a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><u><font color="#800080" face="Calibri">openstack-dev@lists.openstack.org</font></u></a><font face="Calibri">></font><b><font face="Calibri"><br>Date: </font></b><font face="Calibri">Friday, March 4, 2016 at 12:48 PM</font><b><font face="Calibri"><br>To: </font></b><font face="Calibri">"OpenStack Development Mailing List (not for usage questions)" <</font><a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><u><font color="#800080" face="Calibri">openstack-dev@lists.openstack.org</font></u></a><font face="Calibri">></font><b><font face="Calibri"><br>Subject: </font></b><font face="Calibri">Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro</font><br><font face="Calibri"> </font><ul><font face="Calibri">Hongbin, </font><br><font face="Calibri"> </font><br><font face="Calibri">To be clear, this pursuit is not about what OS options cloud operators can select. We will be offering a method of choice. It has to do with what we plan to build comprehensive testing for,</font></ul></ul></ul>
<ul><font color="#1F497D" face="Calibri">This is easy. Once we build comprehensive tests for the first OS, just re-run it for other OS(s).</font><br><font color="#1F497D" face="Calibri"> </font><ul><ul><font face="Calibri">and the implications that has on our pace of feature development. My guidance here is that we resist the temptation to create a system with more permutations than we can possibly support. The relation between bay node OS, Heat Template, Heat Template parameters, COE, and COE dependencies (could-init, docker, flannel, etcd, etc.) are multiplicative in nature. From the mid cycle, it was clear to me that:</font><br><font face="Calibri"> </font><br><font face="Calibri">1) We want to test at least one OS per COE from end-to-end with comprehensive functional tests.</font><br><font face="Calibri">2) We want to offer clear and precise integration points to allow cloud operators to substitute their own OS in place of whatever one is the default for the given COE.</font></ul><font face="Calibri"> </font><br><font face="Calibri">A COE shouldn¡¯t have a default necessarily that locks out other defaults.  Magnum devs are the experts in how these systems operate, and as such need to take on the responsibility of the implementation for multi-os support.</font><br><font face="Calibri"> </font><ul><font face="Calibri">3) We want to control the total number of configuration permutations to simplify our efforts as a project. We agreed that gate testing all possible permutations is intractable.</font></ul><font face="Calibri"> </font><br><font face="Calibri">I disagree with this point, but I don't have the bandwidth available to prove it ;)  </font></ul></ul><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">That¡¯s exactly my point. It takes a chunk of human bandwidth to carry that responsibility. If we had a system engineer assigned from each of the various upstream OS distros working with Magnum, this would not be a big deal. Expecting our current contributors to support a variety of OS variants is not realistic.</font></ul></ul><font color="#1F497D" face="Calibri">You have my promise to support an additional OS for 1 or 2 popular COEs.</font><br><font color="#1F497D" face="Calibri"> </font><ul><ul><font size="4" face="Times New Roman">Change velocity among all the components we rely on has been very high. We see some of our best contributors frequently sidetracked in the details of the distros releasing versions of code that won¡¯t work with ours. We want to upgrade a component to add a new feature, but struggle to because the new release of the distro that offers that component is otherwise incompatible. Multiply this by more distros, and we expect a real problem.</font></ul></ul><font color="#1F497D" face="Calibri">At Magnum upstream, the overhead doesn¡¯t seem to come from the OS. Perhaps, that is specific to your downstream?</font><ul><ul><font size="4" face="Times New Roman"> </font><br><font face="Calibri">There is no harm if you have 30 gates running the various combinations.  Infrastructure can handle the load.  Whether devs have the cycles to make a fully bulletproof gate is the question I think you answered with the word intractable.</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Actually, our existing gate tests are really stressing out our CI infra. At least one of the new infrastructure providers that replaced HP have equipment that runs considerably slower. For example, our swam functional gate now frequently fails because it can¡¯t finish before the allowed time limit of 2 hours where it could finish substantially faster before. If we expanded the workload considerably, we might quickly work to the detriment of other projects by perpetually clogging the CI pipelines. We want to be a good citizen of the openstack CI community. Testing configuration of third party software should be done with third party CI setups. That¡¯s one of the reasons those exist. Ideally, each would be maintained by those who have a strategic (commercial?) interest in support for that particular OS.</font><br><font size="4" face="Times New Roman"> </font><ul><ul><font face="Calibri">I can tell you in Kolla we spend a lot of cycles just getting basic gating  going of building containers and then deploying them.  We have even made inroads into testing the deployment.  We do CentOS, Ubuntu, and soon Oracle Linux, for both source and binary and build and deploy.  Lots of gates and if they aren't green we know the patch is wrong.</font></ul></ul><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Remember that COE¡¯s are tested on nova instances within heat stacks. Starting lots of nova instances within devstack in the gates is problematic. We are looking into using a libvirt-lxc instance type from nova instead of a libvirt-kvm instance to help alleviate this. Until then, limiting the scope of our gate tests is appropriate. We will continue our efforts to make them reasonably efficient.</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Thanks,</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Adrian</font><br><font size="4" face="Times New Roman"> </font><ul><ul><font face="Calibri"> </font><br><font face="Calibri">Regards</font><br><font face="Calibri">-steve</font><br><font face="Calibri"> </font><ul><font face="Calibri"> </font><br><font face="Calibri">Note that it will take a thoughtful approach (subject to discussion) to balance these interests. Please take a moment to review the interest above. Do you or others disagree with these? If so, why?</font><br><font face="Calibri"> </font><br><font face="Calibri">Adrian</font><br><font face="Calibri"> </font><ul><ul><font face="Calibri">On Mar 4, 2016, at 9:09 AM, Hongbin Lu <</font><a href="mailto:hongbin.lu@huawei.com" target="_blank"><u><font color="#800080" face="Calibri">hongbin.lu@huawei.com</font></u></a><font face="Calibri">> wrote:</font><br><font face="Calibri"> </font><br><font color="#1F497D" face="Calibri">I don¡¯t think there is any consensus on supporting single distro. There are multiple disagreements on this thread, including several senior team members and a project co-founder. This topic should be re-discussed (possibly at the design summit).</font><br><font color="#1F497D" face="Calibri"> </font><br><font color="#1F497D" face="Calibri">Best regards,</font><br><font color="#1F497D" face="Calibri">Hongbin</font><br><font color="#1F497D" face="Calibri"> </font><br><b><font face="Tahoma">From:</font></b><font face="Tahoma"> Corey O'Brien [</font><a href="mailto:coreypobrien@gmail.com" target="_blank"><u><font color="#800080" face="Tahoma">mailto:coreypobrien@gmail.com</font></u></a><font face="Tahoma">] </font><b><font face="Tahoma"><br>Sent:</font></b><font face="Tahoma"> March-04-16 11:37 AM</font><b><font face="Tahoma"><br>To:</font></b><font face="Tahoma"> OpenStack Development Mailing List (not for usage questions)</font><b><font face="Tahoma"><br>Subject:</font></b><font face="Tahoma"> Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">I don't think anyone is saying that code should somehow block support for multiple distros. The discussion at midcycle was about what the we should gate on and ensure feature parity for as a team. Ideally, we'd like to get support for every distro, I think, but no one wants to have that many gates. Instead, the consensus at the midcycle was to have 1 reference distro for each COE, gate on those and develop features there, and then have any other distros be maintained by those in the community that are passionate about them.</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">The issue also isn't about how difficult or not it is. The problem we want to avoid is spending precious time guaranteeing that new features and bug fixes make it through multiple distros. </font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">Corey</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">On Fri, Mar 4, 2016 at 11:18 AM Steven Dake (stdake) <</font><a href="mailto:stdake@cisco.com" target="_blank"><u><font size="4" color="#800080" face="Times New Roman">stdake@cisco.com</font></u></a><font size="4" face="Times New Roman">> wrote:</font><br><font face="Calibri">My position on this is simple.</font><br><font face="Calibri"> </font><br><font face="Calibri">Operators are used to using specific distros because that is what they used in the 90s,and the 00s, and the 10s.  Yes, 25 years of using a distro, and you learn it inside and out.  This means you don't want to relearn a new distro, especially if your an RPM user going to DEB or a DEB user going to RPM.  These are non-starter options for operators, and as a result, mean that distro choice is a must.  Since CoreOS is a new OS in the marketplace, it may make sense to consider placing it in "third" position in terms of support.</font><br><font face="Calibri"> </font><br><font face="Calibri">Besides that problem, various distribution companies will only support distros running in Vms if it matches the host kernel, which makes total sense to me.  This means on an Ubuntu host if I want support I need to run Ubuntu vms, on a RHEL host I want to run RHEL vms, because, hey, I want my issues supported.</font><br><font face="Calibri"> </font><br><font face="Calibri">For these reasons and these reasons alone, there is no good rationale to remove multi-distro support  from Magnum.  All I've heard in this thread so far is "its too hard".  Its not too hard, especially with Heat conditionals making their way into Mitaka.</font><br><font face="Calibri"> </font><br><font face="Calibri">Regards</font><br><font face="Calibri">-steve</font><br><font face="Calibri"> </font><br><b><font face="Calibri">From: </font></b><font face="Calibri">Hongbin Lu <</font><a href="mailto:hongbin.lu@huawei.com" target="_blank"><u><font color="#800080" face="Calibri">hongbin.lu@huawei.com</font></u></a><font face="Calibri">></font><b><font face="Calibri"><br>Reply-To: </font></b><font face="Calibri">"</font><a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><u><font color="#800080" face="Calibri">openstack-dev@lists.openstack.org</font></u></a><font face="Calibri">" <</font><a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><u><font color="#800080" face="Calibri">openstack-dev@lists.openstack.org</font></u></a><font face="Calibri">></font><b><font face="Calibri"><br>Date: </font></b><font face="Calibri">Monday, February 29, 2016 at 9:40 AM</font><b><font face="Calibri"><br>To: </font></b><font face="Calibri">"</font><a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><u><font color="#800080" face="Calibri">openstack-dev@lists.openstack.org</font></u></a><font face="Calibri">" <</font><a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><u><font color="#800080" face="Calibri">openstack-dev@lists.openstack.org</font></u></a><font face="Calibri">></font><b><font face="Calibri"><br>Subject: </font></b><font face="Calibri">[openstack-dev] [magnum] Discussion of supporting single/multiple OS distro</font><br><font face="Calibri"> </font><br><font size="4" color="#1F497D" face="Times New Roman">Hi team,</font><br><font size="4" color="#1F497D" face="Times New Roman"> </font><br><font size="4" color="#1F497D" face="Times New Roman">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. </font><br><font size="4" color="#1F497D" face="Times New Roman"> </font><br><i><font size="4" face="Times New Roman">Corey O'Brien</font></i><br><i><font size="4" face="Times New Roman">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.</font></i><br><i><font size="4" face="Times New Roman">In addition, I don't think we should break the coreos template by adding the trust token as a heat parameter.</font></i><br><i><font size="4" face="Times New Roman"> </font></i><br><i><font size="4" face="Times New Roman">Hongbin Lu</font></i><br><i><font size="4" face="Times New Roman">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.</font></i><br><i><font size="4" face="Times New Roman"> </font></i><br><i><font size="4" face="Times New Roman">Corey O'Brien</font></i><br><i><font size="4" face="Times New Roman">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.</font></i><br><i><font size="4" face="Times New Roman"> </font></i><br><i><font size="4" face="Times New Roman">Hongbin Lu</font></i><br><i><font size="4" face="Times New Roman">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).</font></i><br><i><font size="4" face="Times New Roman"> </font></i><br><i><font size="4" face="Times New Roman">Corey O'Brien</font></i><br><i><font size="4" face="Times New Roman">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.</font></i><br><i><font size="4" face="Times New Roman"> </font></i><br><i><font size="4" face="Times New Roman">Hongbin Lu</font></i><br><i><font size="4" face="Times New Roman">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?</font></i><br><font size="4" color="#1F497D" face="Times New Roman"> </font><br><font size="4" color="#1F497D" face="Times New Roman">[1] </font><a href="https://review.openstack.org/#/c/277284/" target="_blank"><u><font size="4" color="#800080" face="Times New Roman">https://review.openstack.org/#/c/277284/</font></u></a><br><font size="4" color="#1F497D" face="Times New Roman"> </font><br><font size="4" color="#1F497D" face="Times New Roman">Best regards,</font><br><font size="4" color="#1F497D" face="Times New Roman">Hongbin</font><br><font size="4" face="Times New Roman">__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: </font><a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank"><u><font size="4" color="#800080" face="Times New Roman">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</font></u></a><u><font size="4" color="#0000FF" face="Times New Roman"><br></font></u><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><u><font size="4" color="#800080" face="Times New Roman">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></u></a><br><font size="2" face="Helvetica">__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: </font><a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank"><u><font size="2" color="#800080" face="Helvetica">OpenStack-dev-request@lists.openstack.org</font></u></a><font size="2" face="Helvetica">?subject:unsubscribe</font><u><font size="2" color="#0000FF" face="Helvetica"><br></font></u><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><u><font size="2" color="#800080" face="Helvetica">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></u></a></ul></ul><font face="Calibri"> </font></ul><font size="4" face="Times New Roman">__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: </font><a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank"><u><font size="4" color="#800080" face="Times New Roman">OpenStack-dev-request@lists.openstack.org</font></u></a><font size="4" face="Times New Roman">?subject:unsubscribe</font><u><font size="4" color="#0000FF" face="Times New Roman"><br></font></u><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><u><font size="4" color="#800080" face="Times New Roman">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></u></a></ul></ul><font size="4" face="Times New Roman"> </font></ul></ul><font size="4" face="Times New Roman">__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: </font><a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank"><u><font size="4" color="#800080" face="Times New Roman">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</font></u></a><u><font size="4" color="#0000FF" face="Times New Roman"><br></font></u><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><u><font size="4" color="#800080" face="Times New Roman">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></u></a></ul></ul><font face="Calibri">__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: </font><a href="mailto:OpenStack-dev-request@lists.openstack.org"><u><font color="#0000FF" face="Calibri">OpenStack-dev-request@lists.openstack.org</font></u></a><font face="Calibri">?subject:unsubscribe</font><u><font color="#0000FF" face="Calibri"><br></font></u><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><u><font color="#0000FF" face="Calibri">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></u></a></ul></ul><font size="4" face="Times New Roman"> </font><tt>__________________________________________________________________________<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></ul></ul></ul></ul><BR>
</body></html>