Setup custom update server for coreos?

[Jovi Zhangwei]

Hi,

I just wondering how to setup custom update server for coreos? this case might be needed because:

- user may need to have custom kernel patches on top of stable kernel, so it can not get update from official coreos public update server.

- user may need to use old kernel version for a long time for stability.

I'm assuming there have a way to let user setup custom update server, but I cannot found any link in coreos doc,

any hint would be great helpful for me.

Thanks.

Jovi

[Greg KH]

On Thu, May 08, 2014 at 12:16:05AM -0700, Jovi Zhangwei wrote:
> Hi,
>
> I just wondering how to setup custom update server for coreos? this case might
> be needed because:
>
> - user may need to have custom kernel patches on top of stable kernel, so it
> can not get update from official coreos public update server.

What kind of kernel patches do you need/want?

> - user may need to use old kernel version for a long time for stability.

Why does an "old" kernel mean "stability"? The idea is that all kernels
should be "stable", and if there is a problem, the roll-back will happen
to the last "stable" one automatically.

Is the kernel the only thing you are worried about here? And if so,
what makes it unique?

thanks,

greg k-h

[Jovi Zhangwei]

On Thursday, May 8, 2014 3:56:15 PM UTC+8, Greg Kroah-Hartman wrote:

On Thu, May 08, 2014 at 12:16:05AM -0700, Jovi Zhangwei wrote:
> Hi,
>
> I just wondering how to setup custom update server for coreos? this case might
> be needed because:
>
> - user may need to have custom kernel patches on top of stable kernel, so it
> can not get update from official coreos public update server.

What kind of kernel patches do you need/want?

 

For example, Third-party open sourced kernel patches for some feature enhancement,

or self developed patches for own feature, and more...

> - user may need to use old kernel version for a long time for stability.

Why does an "old" kernel mean "stability"?  The idea is that all kernels
should be "stable", and if there is a problem, the roll-back will happen
to the last "stable" one automatically.

In many cases, kernel cannot upgrade frequently, and a lot of kernel modules

bind with unique kernel version, it just not easy to update upstream kernel like coreos doing currently.

(There also have a lot of 2.6.x kernel still running in the enterprise world.)

Besides of kernel issue, networking is also a problem in many cases, many running systems

cannot access coreos public update server, they have own net domain which isolated with public net domain.

Just want to know the solution about how to deploy coreos in those systems. :)

Thanks.

Jovi

[Greg KH]

On Thu, May 08, 2014 at 07:03:38PM -0700, Jovi Zhangwei wrote:
>
>
> On Thursday, May 8, 2014 3:56:15 PM UTC+8, Greg Kroah-Hartman wrote:
>
> On Thu, May 08, 2014 at 12:16:05AM -0700, Jovi Zhangwei wrote:
> > Hi,
> >
> > I just wondering how to setup custom update server for coreos? this case
> might
> > be needed because:
> >
> > - user may need to have custom kernel patches on top of stable kernel, so
> it
> > can not get update from official coreos public update server.
>
> What kind of kernel patches do you need/want?
>
>
>
> For example, Third-party open sourced kernel patches for some feature
> enhancement, or self developed patches for own feature, and more...

Any specifics?

> > - user may need to use old kernel version for a long time for stability.
>
> Why does an "old" kernel mean "stability"? The idea is that all kernels
> should be "stable", and if there is a problem, the roll-back will happen
> to the last "stable" one automatically.
>
>
> In many cases, kernel cannot upgrade frequently, and a lot of kernel modules
> bind with unique kernel version, it just not easy to update upstream kernel
> like coreos doing currently.

On the contrary, updating a kernel can be done just fine very rapidly,
as you really should not ever be relying on an external kernel module.

> (There also have a lot of 2.6.x kernel still running in the enterprise world.)

That is their problem :)

> Besides of kernel issue, networking is also a problem in many cases, many
> running systems cannot access coreos public update server, they have
> own net domain which isolated with public net domain.

That's a different issue, and is not a kernel issue. There are
solutions for this with other methods.

> Just want to know the solution about how to deploy coreos in those systems. :)

For "private" networks, talk to the coreos people, they have something
for you.

And don't get hung up on the "we can't update the kernel" mentality that
older distros like Red Hat have been pushing for years, that's really
not the way forward at all. Other "enterprise" distros have realized
this and have changed (Oracle, SuSE, etc.), and even Red Hat does major
things to their kernel between releases, they just keep the number the
same to make it look like they do not.

Remember, you want change, as the world changes. If you have a box that
just sits in the corner and isn't connect to the internet with no new
hardware, then don't update the kernel. Otherwise, in order to have it
work properly, you will have to update it.

Hope this helps,

greg k-h

[Jovi Zhangwei]

On Fri, May 9, 2014 at 12:10 PM, Greg KH <gr...@kroah.com> wrote:
> On Thu, May 08, 2014 at 07:03:38PM -0700, Jovi Zhangwei wrote:
>>
>>
>> On Thursday, May 8, 2014 3:56:15 PM UTC+8, Greg Kroah-Hartman wrote:
>>
>> On Thu, May 08, 2014 at 12:16:05AM -0700, Jovi Zhangwei wrote:
>> > Hi,
>> >
>> > I just wondering how to setup custom update server for coreos? this case
>> might
>> > be needed because:
>> >
>> > - user may need to have custom kernel patches on top of stable kernel, so
>> it
>> > can not get update from official coreos public update server.
>>
>> What kind of kernel patches do you need/want?
>>
>>
>>
>> For example, Third-party open sourced kernel patches for some feature
>> enhancement, or self developed patches for own feature, and more...
>
> Any specifics?
>

Some patches for debug enhancement, and feature backport, etc.
(LTSI also have many addition patches on top of LTS? not confirmed)

>> > - user may need to use old kernel version for a long time for stability.
>>
>> Why does an "old" kernel mean "stability"? The idea is that all kernels
>> should be "stable", and if there is a problem, the roll-back will happen
>> to the last "stable" one automatically.
>>
>>
>> In many cases, kernel cannot upgrade frequently, and a lot of kernel modules
>> bind with unique kernel version, it just not easy to update upstream kernel
>> like coreos doing currently.
>
> On the contrary, updating a kernel can be done just fine very rapidly,
> as you really should not ever be relying on an external kernel module.
>

In the product which I working now, there have many kernel modules in there,
for different purposes. Actually those kernel modules is a big
challenge for kernel
update when new stable patches and new kernel version come, because
kernel ABI often break. so they need time to adapt all kernel modules with
new kernel update.

I think Enterprise kernel always don't have much kernel modules, but that's
not the general case for other people.

>> (There also have a lot of 2.6.x kernel still running in the enterprise world.)
>
> That is their problem :)
>
>> Besides of kernel issue, networking is also a problem in many cases, many
>> running systems cannot access coreos public update server, they have
>> own net domain which isolated with public net domain.
>
> That's a different issue, and is not a kernel issue. There are
> solutions for this with other methods.
>
>> Just want to know the solution about how to deploy coreos in those systems. :)
>
> For "private" networks, talk to the coreos people, they have something
> for you.
>
> And don't get hung up on the "we can't update the kernel" mentality that
> older distros like Red Hat have been pushing for years, that's really
> not the way forward at all. Other "enterprise" distros have realized
> this and have changed (Oracle, SuSE, etc.), and even Red Hat does major
> things to their kernel between releases, they just keep the number the
> same to make it look like they do not.
>
> Remember, you want change, as the world changes. If you have a box that
> just sits in the corner and isn't connect to the internet with no new
> hardware, then don't update the kernel. Otherwise, in order to have it
> work properly, you will have to update it.
>

I agree, update is the way to forward, we want to update our kernel, my concern
is how to handle below three issues under current coreos update mode?

- kernel module update
- addition kernel patch
- private network

Maybe there have another way to address these issues without setup custom
update server, that's the reason why the original question raised. :)

Thanks.

Jovi

[Greg KH]

On Fri, May 09, 2014 at 01:56:27PM +0800, Jovi Zhangwei wrote:
> On Fri, May 9, 2014 at 12:10 PM, Greg KH <gr...@kroah.com> wrote:
> > On Thu, May 08, 2014 at 07:03:38PM -0700, Jovi Zhangwei wrote:
> >>
> >>
> >> On Thursday, May 8, 2014 3:56:15 PM UTC+8, Greg Kroah-Hartman wrote:
> >>
> >> On Thu, May 08, 2014 at 12:16:05AM -0700, Jovi Zhangwei wrote:
> >> > Hi,
> >> >
> >> > I just wondering how to setup custom update server for coreos? this case
> >> might
> >> > be needed because:
> >> >
> >> > - user may need to have custom kernel patches on top of stable kernel, so
> >> it
> >> > can not get update from official coreos public update server.
> >>
> >> What kind of kernel patches do you need/want?
> >>
> >>
> >>
> >> For example, Third-party open sourced kernel patches for some feature
> >> enhancement, or self developed patches for own feature, and more...
> >
> > Any specifics?
> >
> Some patches for debug enhancement, and feature backport, etc.
> (LTSI also have many addition patches on top of LTS? not confirmed)

LTSI is for "consumer" products, and yes, they backport a lot of things,
mostly all new hardware support that is already upstream in newer kernel
releases.

LTSI really isn't relevant for a distro that constantly takes the latest
upstream kernel release.

> >> > - user may need to use old kernel version for a long time for stability.
> >>
> >> Why does an "old" kernel mean "stability"? The idea is that all kernels
> >> should be "stable", and if there is a problem, the roll-back will happen
> >> to the last "stable" one automatically.
> >>
> >>
> >> In many cases, kernel cannot upgrade frequently, and a lot of kernel modules
> >> bind with unique kernel version, it just not easy to update upstream kernel
> >> like coreos doing currently.
> >
> > On the contrary, updating a kernel can be done just fine very rapidly,
> > as you really should not ever be relying on an external kernel module.
> >
>
> In the product which I working now, there have many kernel modules in there,
> for different purposes. Actually those kernel modules is a big
> challenge for kernel
> update when new stable patches and new kernel version come, because
> kernel ABI often break. so they need time to adapt all kernel modules with
> new kernel update.

Why are those modules not merged upstream? Is there anything I can do
to help with that? If they were merged upstream, then there would not
be any issues :)

Also, what do these modules do? Hardware support? Something else?

> I think Enterprise kernel always don't have much kernel modules, but that's
> not the general case for other people.

I don't understand what you mean here.

> > Remember, you want change, as the world changes. If you have a box that
> > just sits in the corner and isn't connect to the internet with no new
> > hardware, then don't update the kernel. Otherwise, in order to have it
> > work properly, you will have to update it.
> >
> I agree, update is the way to forward, we want to update our kernel, my concern
> is how to handle below three issues under current coreos update mode?
>
> - kernel module update
> - addition kernel patch
> - private network
>
> Maybe there have another way to address these issues without setup custom
> update server, that's the reason why the original question raised. :)

If you have custom kernel modules / patches, that's something that would
need to be coordinated with the coreos team, nothing I can do here as a
community member, sorry. But again, I'd strongly urge you not to do
that, and to get your code upstream, so that issue will go away
automatically.

thanks,

greg k-h

[Jovi Zhangwei]

If it's end up of commercial support from coreos team, then it's also
a solution. :)

> But again, I'd strongly urge you not to do
> that, and to get your code upstream, so that issue will go away
> automatically.
>

Fully understood, we are still on the road. :)

Thank you for these helpful reply.

Jovi

[sma...@gmail.com]

a local update server would be nice for security....  a local update server would allow backend servers to get their updates without being exposed to the internet.

[Camilo Aguilar]

I'm also in favor of being able to have a private update server. No matter the specific need. It's a straightforward request. If it is part of the CoreOS commercial offering, that's fine, but just state it from the beginning instead of asking unrelated questions.

[Rob Szumski]

Yes, this is offered as a part of Managed Linux, it’s called CoreUpdate. Although the protocol it uses is open source (our docs) and it’d be great if someone worked on an open source version.

 - Rob