> I have at least one feature planned for smart-proxy that requires
> dependencies not available on 1.8.7 (at all). At this point converting
> the smart-proxy to use SCL isn’t worth it, and it would be great not
> to have an additional 3-months wait.
That would be exactly my point also, as I said in my mail for the
original discussion back then: If the support for EL6 is prolonged, the
proxy (and maybe even the installer) should really get into SCL, which
is definitely too much work for just 3 or 6 months. If EL6 support is
really needed, somebody[tm] needs to do that work, but then we could
also extend the lifespan not only some months, but probably some years.
As I don't use RH based distro at the moment, I can't really say how
widespread the use of EL6 for Foreman really is…
Regards
···
On Fri, Jul 29, 2016 at 08:35:36AM +0100, Dmitri Dolguikh wrote:
--
Michael Moll
The migration would be complicated for users who run TFTP/DHCP/DNS
(etc…) on the same host. Then again they can just keep the proxy
running there and hook the new Foreman (1.13 in el7) to the old el6 box.
Same thing applies to Katello I think. I'm not sure about any traces
that katello leaves on the Foreman box but if users can keep their el6
proxy with Pulp, that's not a major issue. They can upgrade Foreman but
keep the old el6 proxy with Pulp, and not upgrade the proxy. I am not
aware of any way of migrating candlepin information to another box (or
connecting to a capsule just for candlepin) so pointers to that would be
very helpful.
I don't know much about migrating tasks (Dynflow), so any guides on that
would help too.
tl;dr: Migrating Foreman itself should be a piece of cake. For services
that are not that easy to migrate such as Pulp, TFTP, DHCP, DNS, users
can keep their el6 proxies and those ought to be compatible with Foreman
1.13.
···
On 07/29, Lukas Zapletal wrote:
> > > That said, I believe security updates are the most important to them so
> > > you could consider supporting the last release on EL6 a bit longer. I
> > > don't know how much of a time/effort difference that makes compared to
> > > supporting it longer on the newest release.
> >
> > Yeah, I can certainly try for a bit longer if it's useful to people,
> > though help doing the backports may be appreciated when we get there.
>
> I think we are discussing two things which are different.
>
> Maintaining EL6 releases is one thing and we are not dropping that at
> all - we are sticking with our commitment. For those who need even
> longer support cycle there are 3rd party vendors like Red Hat.
>
> On the other hand, what Dominic suggest is dropping EL6 from the next
> release. That's a different story. And that's not that hot topic from
> user perspective, but plugins should be taken into consideration for
> sure.
>
> For discovery, I can say I am fine with dropping EL6 from the next
> release, but I can understand this is huge move and if there is a chance
> to postpone this one another release let's just do it. But I would like
> to see immediate planning and actions in order to achieve smooth exit
> phase.
>
> Can we identify first what needs to be done in order to drop EL6? Also
> can we do something for users to smoother the experience? Some web
> banners, blog posts? Perhaps a RFC can help here so it's recorded and
> visible for others.
Branching is in roughly a month yea? Could we do a hybrid approach where
1.13 is released supporting EL6 but with only a 3 month support instead of
the usual 6? While providing migration articles and scripts and emphasizing
to the community to start moving as soon as possible.
Development could begin roughly after branching on ripping out 1.8.7
support as well as any features that will require newer Ruby.
That would mean roughly 1 dev month and 4 support months on EL6. We can
also work on a OS deprecation policy for the future to be clear for users
and help their planning.
Eric
···
On Jul 29, 2016 5:35 AM, "Dominic Cleal" wrote:
On 29/07/16 10:29, Michael Moll wrote:
Hi,
On Fri, Jul 29, 2016 at 08:35:36AM +0100, Dmitri Dolguikh wrote:
I have at least one feature planned for smart-proxy that requires
dependencies not available on 1.8.7 (at all). At this point converting
the smart-proxy to use SCL isn’t worth it, and it would be great not
to have an additional 3-months wait.
That would be exactly my point also, as I said in my mail for the
original discussion back then: If the support for EL6 is prolonged, the
proxy (and maybe even the installer) should really get into SCL, which
is definitely too much work for just 3 or 6 months. If EL6 support is
really needed, somebody[tm] needs to do that work, but then we could
also extend the lifespan not only some months, but probably some years.
The latest software collection updates aren’t available on EL6 either,
so more reliance on packaging into SCLs doesn’t help in the medium to
long term.
Katello provides full backup and restore scripts for users. We've not
tested it for this specific case and or migrating a large infrastructure.
Nor have we given guidance which are my bigger concerns.
That said, I believe security updates are the most important to them
so
you could consider supporting the last release on EL6 a bit longer. I
don’t know how much of a time/effort difference that makes compared
to
supporting it longer on the newest release.
Yeah, I can certainly try for a bit longer if it’s useful to people,
though help doing the backports may be appreciated when we get there.
I think we are discussing two things which are different.
Maintaining EL6 releases is one thing and we are not dropping that at
all - we are sticking with our commitment. For those who need even
longer support cycle there are 3rd party vendors like Red Hat.
On the other hand, what Dominic suggest is dropping EL6 from the next
release. That’s a different story. And that’s not that hot topic from
user perspective, but plugins should be taken into consideration for
sure.
For discovery, I can say I am fine with dropping EL6 from the next
release, but I can understand this is huge move and if there is a chance
to postpone this one another release let’s just do it. But I would like
to see immediate planning and actions in order to achieve smooth exit
phase.
Can we identify first what needs to be done in order to drop EL6? Also
can we do something for users to smoother the experience? Some web
banners, blog posts? Perhaps a RFC can help here so it’s recorded and
visible for others.
The migration would be complicated for users who run TFTP/DHCP/DNS
(etc…) on the same host. Then again they can just keep the proxy
running there and hook the new Foreman (1.13 in el7) to the old el6 box.
Same thing applies to Katello I think. I’m not sure about any traces
that katello leaves on the Foreman box but if users can keep their el6
proxy with Pulp, that’s not a major issue. They can upgrade Foreman but
keep the old el6 proxy with Pulp, and not upgrade the proxy. I am not
aware of any way of migrating candlepin information to another box (or
connecting to a capsule just for candlepin) so pointers to that would be
very helpful.
I don’t know much about migrating tasks (Dynflow), so any guides on that
would help too.
tl;dr: Migrating Foreman itself should be a piece of cake. For services
that are not that easy to migrate such as Pulp, TFTP, DHCP, DNS, users
can keep their el6 proxies and those ought to be compatible with Foreman
1.13.
The latest software collection updates aren't available on EL6 either,
so more reliance on packaging into SCLs doesn't help in the medium to
long term.
···
On 29/07/16 10:29, Michael Moll wrote:
> Hi,
>
> On Fri, Jul 29, 2016 at 08:35:36AM +0100, Dmitri Dolguikh wrote:
>> I have at least one feature planned for smart-proxy that requires
>> dependencies not available on 1.8.7 (at all). At this point converting
>> the smart-proxy to use SCL isn’t worth it, and it would be great not
>> to have an additional 3-months wait.
>
> That would be exactly my point also, as I said in my mail for the
> original discussion back then: If the support for EL6 is prolonged, the
> proxy (and maybe even the installer) should really get into SCL, which
> is definitely too much work for just 3 or 6 months. If EL6 support is
> really needed, somebody[tm] needs to do that work, but then we could
> also extend the lifespan not only some months, but probably some years.
> > The migration would be complicated for users who run TFTP/DHCP/DNS
> > (etc…) on the same host.
>
> Why would it be complicated? Backup config files, restore them on the
> new machine and run migrations.
Have you tried it yourself? There are newer ISC services which might
not load. I am just curious…
How about to push a banner into all our supported Foreman versions (plus
maybe few older as users are still on quite old releases) that will show
up in Foreman is running on EL6 asking users to consider a migration
with this link.
If users start this doing sooner, we will have more time to tune things
up for the last EL6 release (perhaps some changes might be necessary for
plugins).
> > The migration would be complicated for users who run TFTP/DHCP/DNS
> > (etc…) on the same host.
>
> Why would it be complicated? Backup config files, restore them on the
> new machine and run migrations.
Sorry, I meant 'more complicated'. It's more complicated to
migrate all the config files when we don't provide a simple script like we
do for the Foreman database.
> Hi,
>
>> I have at least one feature planned for smart-proxy that requires
>> dependencies not available on 1.8.7 (at all). At this point converting
>> the smart-proxy to use SCL isn’t worth it, and it would be great not
>> to have an additional 3-months wait.
>
> That would be exactly my point also, as I said in my mail for the
> original discussion back then: If the support for EL6 is prolonged, the
> proxy (and maybe even the installer) should really get into SCL, which
> is definitely too much work for just 3 or 6 months. If EL6 support is
> really needed, somebody[tm] needs to do that work, but then we could
> also extend the lifespan not only some months, but probably some years.
>
> As I don't use RH based distro at the moment, I can't really say how
> widespread the use of EL6 for Foreman really is…
It seems surprisingly prevalent in katello users (maybe 30% from my
instances helping users).
Since there wasn't a clear statement of when the deprecation was going
to occur (the original email thread was left without a conclusion), and
the release notes for 1.11 did not say which future release would remove
el6 support (until it was recently updated) I would vote to keep it for
1.13 and make it very clear to both users and devs. It would allow us
(and users on el6) to more thoroughly test our backup and restore
procedures across all plugins.
···
On 07/29/2016 05:29 AM, Michael Moll wrote:
> On Fri, Jul 29, 2016 at 08:35:36AM +0100, Dmitri Dolguikh wrote:
···
On Mon, Aug 1, 2016 at 11:56 AM, Daniel Lobato Garcia wrote:
> Sorry, I meant 'more complicated'. It's more complicated to
> migrate all the config files when we don't provide a simple script like we
> do for the Foreman database.
>
> > Sorry, I meant 'more complicated'. It's more complicated to
> > migrate all the config files when we don't provide a simple script like we
> > do for the Foreman database.
> >
>
> But we do, "rake migrate_settings" will migrate smart-proxy’s config files [1].
> -d
>
I didn't make myself clear again, I mean the config files for the services itselves
think /etc/xinetd, puppet.conf, dhpcd.conf …
···
On 08/01, Dmitri Dolguikh wrote:
> On Mon, Aug 1, 2016 at 11:56 AM, Daniel Lobato Garcia > wrote:
This thread has seen a revival with many points being made on both sides.
However, things have gone cold for nearly a week now and there are
processes and decisions that hinge on the outcome with respect to users and
developers alike. Are we to assume that what has been done is done and this
discussion is moot? Some finality in this matter would be greatly
appreciated to either continue forward with EL6 builds and preparing all of
our ecosystem users for the 1.14 release to migrate or beginning now to
tell users they are SOL and to start testing transition and migration while
we work out and test the best way for them to do so.
Eric
···
On Tue, Aug 2, 2016 at 1:15 PM, Justin Sherrill wrote:
On 07/29/2016 05:29 AM, Michael Moll wrote:
Hi,
On Fri, Jul 29, 2016 at 08:35:36AM +0100, Dmitri Dolguikh wrote:
I have at least one feature planned for smart-proxy that requires
dependencies not available on 1.8.7 (at all). At this point converting
the smart-proxy to use SCL isn’t worth it, and it would be great not
to have an additional 3-months wait.
That would be exactly my point also, as I said in my mail for the
original discussion back then: If the support for EL6 is prolonged, the
proxy (and maybe even the installer) should really get into SCL, which
is definitely too much work for just 3 or 6 months. If EL6 support is
really needed, somebody[tm] needs to do that work, but then we could
also extend the lifespan not only some months, but probably some years.
As I don’t use RH based distro at the moment, I can’t really say how
widespread the use of EL6 for Foreman really is…
It seems surprisingly prevalent in katello users (maybe 30% from my
instances helping users).
Since there wasn’t a clear statement of when the deprecation was going
to occur (the original email thread was left without a conclusion), and
the release notes for 1.11 did not say which future release would remove
el6 support (until it was recently updated) I would vote to keep it for
1.13 and make it very clear to both users and devs. It would allow us
(and users on el6) to more thoroughly test our backup and restore
procedures across all plugins.
> This thread has seen a revival with many points being made on both sides.
> However, things have gone cold for nearly a week now and there are
> processes and decisions that hinge on the outcome with respect to users and
> developers alike. Are we to assume that what has been done is done and this
> discussion is moot? Some finality in this matter would be greatly
> appreciated to either continue forward with EL6 builds and preparing all of
> our ecosystem users for the 1.14 release to migrate or beginning now to
> tell users they are SOL and to start testing transition and migration while
> we work out and test the best way for them to do so.
>
I strongly prefer deprecating EL6 with Foreman 1.14, and would ask to
revert the el6 changes in nighties.
Ohad
···
On Mon, Aug 8, 2016 at 5:33 PM, Eric D Helms wrote:
Eric
On Tue, Aug 2, 2016 at 1:15 PM, Justin Sherrill jsherril@redhat.com > wrote:
On 07/29/2016 05:29 AM, Michael Moll wrote:
Hi,
On Fri, Jul 29, 2016 at 08:35:36AM +0100, Dmitri Dolguikh wrote:
I have at least one feature planned for smart-proxy that requires
dependencies not available on 1.8.7 (at all). At this point converting
the smart-proxy to use SCL isn’t worth it, and it would be great not
to have an additional 3-months wait.
That would be exactly my point also, as I said in my mail for the
original discussion back then: If the support for EL6 is prolonged, the
proxy (and maybe even the installer) should really get into SCL, which
is definitely too much work for just 3 or 6 months. If EL6 support is
really needed, somebody[tm] needs to do that work, but then we could
also extend the lifespan not only some months, but probably some years.
As I don’t use RH based distro at the moment, I can’t really say how
widespread the use of EL6 for Foreman really is…
It seems surprisingly prevalent in katello users (maybe 30% from my
instances helping users).
Since there wasn’t a clear statement of when the deprecation was going
to occur (the original email thread was left without a conclusion), and
the release notes for 1.11 did not say which future release would remove
el6 support (until it was recently updated) I would vote to keep it for
1.13 and make it very clear to both users and devs. It would allow us
(and users on el6) to more thoroughly test our backup and restore
procedures across all plugins.
I did ask previously to confirm if the cons to keeping EL6 were still as
simple as suggested on May 10th. I've heard no contradiction of that, so my
preference also goes to reverting the change in the nightlies.
···
On 8 August 2016 at 15:41, Ohad Levy wrote:
>
> On Mon, Aug 8, 2016 at 5:33 PM, Eric D Helms wrote:
>
>> This thread has seen a revival with many points being made on both sides.
>> However, things have gone cold for nearly a week now and there are
>> processes and decisions that hinge on the outcome with respect to users and
>> developers alike. Are we to assume that what has been done is done and this
>> discussion is moot? Some finality in this matter would be greatly
>> appreciated to either continue forward with EL6 builds and preparing all of
>> our ecosystem users for the 1.14 release to migrate or beginning now to
>> tell users they are SOL and to start testing transition and migration while
>> we work out and test the best way for them to do so.
>>
>
> I strongly prefer deprecating EL6 with Foreman 1.14, and would ask to
> revert the el6 changes in nighties.
>
Supporting EL6 is little effort for the projects I'm involved so I have
no objections to formally deprecating EL6 on 1.13 and dropping support
in 1.14.
···
On Mon, Aug 08, 2016 at 06:34:01PM +0100, Greg Sutcliffe wrote:
> On 8 August 2016 at 15:41, Ohad Levy wrote:
> >
> > On Mon, Aug 8, 2016 at 5:33 PM, Eric D Helms wrote:
> >
> >> This thread has seen a revival with many points being made on both sides.
> >> However, things have gone cold for nearly a week now and there are
> >> processes and decisions that hinge on the outcome with respect to users and
> >> developers alike. Are we to assume that what has been done is done and this
> >> discussion is moot? Some finality in this matter would be greatly
> >> appreciated to either continue forward with EL6 builds and preparing all of
> >> our ecosystem users for the 1.14 release to migrate or beginning now to
> >> tell users they are SOL and to start testing transition and migration while
> >> we work out and test the best way for them to do so.
> >>
> >
> > I strongly prefer deprecating EL6 with Foreman 1.14, and would ask to
> > revert the el6 changes in nighties.
> >
>
> I did ask previously to confirm if the cons to keeping EL6 were still as
> simple as suggested on May 10th. I've heard no contradiction of that, so my
> preference also goes to reverting the change in the nightlies.
