fuel-dev team mailing list archive

[Andrew Woodward <xarses@xxxxxxxxx>]

>
> Right now master node has 2.6 kernel, bootstrap has 3.10 and target node
> has an option in settings with 2.6 kernel as default.


WHAT? Why is the bootstrap 3.10 already? I already spoke to the issues that
some users have had about this. This should have been discussed on the ML
before making a change like this.

First off, I'm sorry but making the 3.10 the default kernel for our "CentOS
6.x" installs inherently makes it NOT CentOS, it becomes Fedora 18. If we
are going to do this, then we might as well switch from CentOS base to a
proper Fedora base. At the same time, making 3.10 the default kernel
impacts vendor support. Vendors that might have supported CentOS 6.x now
wont. I've already been in on a conversation with with a user, and
separately two vendors that are having a hard time using our "CentOS"
because we don't have a stock kernel. This removes support-ability from the
list of reasons to use CentOS, which is one of the core reasons I've seen
organizations select it.

Second, what is the goal here?

* if we are trying reduce issues from master -> bootstrap -> target node?
switching kernel around? If this is the case then we really should just
change master and bootstrap to Ubuntu (which I've been considering raising
anyways).

* If we are trying to reduce the OVS issues (or other old kernel issues),
then the current workup is correct, the user should have to explicitly
choose a kernel that wasn't part of the base distribution, this is
important as is must be their choice and not default to enter into a mode
that reduces their support.

* If we are trying to get CentOS to a more modern kernel, then we really
just have to wait for CentOS 7 otherwise we are really better off tracking
Fedora instead of CentOS

Third, this is changing our user story of "No vendor lock-in" to "You're
stuck with Mirantis". We really need to take a step back an evaluate where
we are going. If we want to maintain our on proprietary distro then we need
to stop beating around and do it, and do it well. If we are going to fight
vendor lock-in, then we need to be more cautions about what distro packages
we are modifying and why. We also need to not replace distro packages but
instead maintain a clean distro repos and a MOS repo, this will grant us a
clear line of what we are doing and better allow others to participate
(like bringing in other distros, vendor compatibility, and others)


On Fri, Mar 28, 2014 at 5:08 AM, Matthew Mosesohn <mmosesohn@xxxxxxxxxxxx>wrote:

> I propose that since we do kernel-lt 3.10.30 as a default for installs
> and bootstrap, we should default to it for Fuel master node as well.
> I believe we should keep the 2.6.32 kernel around just in case there
> is a regression in using the newer kernel, but maybe we can drop it
> after a release cycle or two if there are no major issues.
>
> The build tiem option I mentioned to you would be to optionally
> generate a bootstrap image with the 2.6.32 kernel during ISO build. It
> isn't likely we will need to build it, but it should be easy to swap
> back if the need arises.
>
> On Fri, Mar 28, 2014 at 4:03 PM, Dmitry Pyzhov <dpyzhov@xxxxxxxxxxxx>
> wrote:
> > Guys,
> >
> > we have two kernels: default 2.6.32 and kernel-lt 3.10.30. And we have
> three
> > types of CentOS nodes: master node, bootstrap, target node.
> >
> > Right now master node has 2.6 kernel, bootstrap has 3.10 and target node
> has
> > an option in settings with 2.6 kernel as default.
> >
> > There is a suggestion from our team members to use 3.10 kernel everywhere
> > and add build-time option for 2.6.
> >
> > Any concerns?
> >
> > --
> > Mailing list: https://launchpad.net/~fuel-dev
> > Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~fuel-dev
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Andrew
Mirantis
Ceph community