10:02 a.m.
hi guys,
The cloud-init is causing lots of issues and we need to workout how best
to handle this.
We have a cloud-init in the CentOS Instance SIG that is curated locally,
based off the last EL7 cloud-init ( 0.7.5 ); but there is now a
cloud-init in epel7 as well, which has a different patchset but higher
Release id.
I could now go and build a higher Release, but can we workout a better
longer term solution to stuff like this ?
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
10:50 a.m.
On 09/09/2014 10:02 AM, Karanbir Singh wrote:
hi guys,
The cloud-init is causing lots of issues and we need to workout how best
to handle this.
We have a cloud-init in the CentOS Instance SIG that is curated locally,
based off the last EL7 cloud-init ( 0.7.5 ); but there is now a
cloud-init in epel7 as well, which has a different patchset but higher
Release id.
I could now go and build a higher Release, but can we workout a better
longer term solution to stuff like this ?
As the patches used in the CentOS package have been accepted upstream,
perhaps they could be merged into the epel package so that there's only
one shipped.
Alternatively, is cloud-init an actual shipped RH package that should be
excluded/blacklisted from epel?
--
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
1:07 p.m.
On 09/09/2014 04:50 PM, Jim Perrin wrote:
Alternatively, is cloud-init an actual shipped RH package that should
be
excluded/blacklisted from epel?
its certainly used in the RHEL image
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
6:31 p.m.
On Tue, 09 Sep 2014 19:07:57 +0100
Karanbir Singh <mail-lists(a)karan.org> wrote:
On 09/09/2014 04:50 PM, Jim Perrin wrote:
> Alternatively, is cloud-init an actual shipped RH package that
> should be excluded/blacklisted from epel?
its certainly used in the RHEL image
Odd. I am not seeing it in any of the normal channels...
at least not by that name.
Anyhow, How about we try and get the same pool of people maintaining
both the EPEL one and the CentOS one? Then they might be more easily be
able to keep them in sync. Perhaps we can start an email dialog on
that...
kevin
3:27 a.m.
On 09/11/2014 12:31 AM, Kevin Fenzi wrote:
>> Alternatively, is cloud-init an actual shipped RH package
that
>> should be excluded/blacklisted from epel?
>
> its certainly used in the RHEL image
Odd. I am not seeing it in any of the normal channels...
at least not by that name.
its in the rhel guest agents, and therefore should be in there somewhere
- but I agree, its either hard to find or just not there. In previous
releases they did the RHCOMMON channel thing, not sure if thats the
intention here as well.
Anyhow, How about we try and get the same pool of people maintaining
both the EPEL one and the CentOS one? Then they might be more easily be
able to keep them in sync. Perhaps we can start an email dialog on
that...
that would work. There is the whole fundamental issue to then work
through as to how far the epel branch's can diverge from the fedora
codebase ? Secondly, could we find a mechanism that takes this model and
applies it across the board on both sides.
that would also make it easier for this use case : Some of the SIG's
might end up needing to carry the epel configs, not just the -release
rpm, but the yum config, enabled already, in their own release files to
satisfy deps.
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
12:01 p.m.
On Thu, 11 Sep 2014 09:27:32 +0100
Karanbir Singh <mail-lists(a)karan.org> wrote:
that would work. There is the whole fundamental issue to then work
through as to how far the epel branch's can diverge from the fedora
codebase ? Secondly, could we find a mechanism that takes this model
and applies it across the board on both sides.
Sure. I would hope that maintainers could come to some common agreement
on patches, etc. I am hard pressed to think of cases where something
wouldn't just be good for both EPEL and CentOS.
that would also make it easier for this use case : Some of the SIG's
might end up needing to carry the epel configs, not just the -release
rpm, but the yum config, enabled already, in their own release files
to satisfy deps.
So, we can get the maintainers of the epel package out of pkgdb. Is
there a way to get a list of the CentOS maintainers?
kevin
12:12 p.m.
On 09/12/2014 12:01 PM, Kevin Fenzi wrote:
On Thu, 11 Sep 2014 09:27:32 +0100
Karanbir Singh <mail-lists(a)karan.org> wrote:
> that would work. There is the whole fundamental issue to then work
> through as to how far the epel branch's can diverge from the fedora
> codebase ? Secondly, could we find a mechanism that takes this model
> and applies it across the board on both sides.
Sure. I would hope that maintainers could come to some common agreement
on patches, etc. I am hard pressed to think of cases where something
wouldn't just be good for both EPEL and CentOS.
>
> that would also make it easier for this use case : Some of the SIG's
> might end up needing to carry the epel configs, not just the -release
> rpm, but the yum config, enabled already, in their own release files
> to satisfy deps.
So, we can get the maintainers of the epel package out of pkgdb. Is
there a way to get a list of the CentOS maintainers?
Not currently, no. The SIG effort is one of the first where packages
aren't essentially controlled/dominated by upstream. Ownership wasn't a
large concern before.
--
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
4:13 p.m.
On Friday, September 12, 2014 at 1:01 PM, Kevin Fenzi wrote:
On Thu, 11 Sep 2014 09:27:32 +0100
Karanbir Singh <mail-lists(a)karan.org (mailto:mail-lists@karan.org)> wrote:
> that would work. There is the whole fundamental issue to then work
> through as to how far the epel branch's can diverge from the fedora
> codebase ? Secondly, could we find a mechanism that takes this model
> and applies it across the board on both sides.
>
Sure. I would hope that maintainers could come to some common agreement
on patches, etc. I am hard pressed to think of cases where something
wouldn't just be good for both EPEL and CentOS.
I’m the primary maintainer in EPEL + Fedora. Would certainly be able to help on the CentOS
side as well and apply patches as needed.
>
> that would also make it easier for this use case : Some of the SIG's
> might end up needing to carry the epel configs, not just the -release
> rpm, but the yum config, enabled already, in their own release files
> to satisfy deps.
>
So, we can get the maintainers of the epel package out of pkgdb. Is
there a way to get a list of the CentOS maintainers?
kevin
_______________________________________________
epel-devel mailing list
epel-devel(a)lists.fedoraproject.org (mailto:epel-devel@lists.fedoraproject.org)
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
7:46 a.m.
On 10/11/2014 04:13 PM, Sam Kottler wrote:
I’m the primary maintainer in EPEL + Fedora. Would certainly be able to help on the
CentOS side as well and apply patches as needed.
While some of the patches have different names, it looks like we
(CentOS) have 4 patches that are not included in the epel cloud-init.
Everything else is (other than the configured username).
These add support for cloudstack and opennebula as providers, as well as
fixing a hostname issue for centos 7 users.
Sam, would you review the linked patches and commit them into the epel7
cloud-init?
https://git.centos.org/blob/rpms!cloud-init.git/fdbbe746b0838a8957c8dbd19...
https://git.centos.org/blob/rpms!cloud-init.git/fdbbe746b0838a8957c8dbd19...
https://git.centos.org/blob/rpms!cloud-init.git/fdbbe746b0838a8957c8dbd19...
https://git.centos.org/blob/rpms!cloud-init.git/fdbbe746b0838a8957c8dbd19...
--
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
3467
days inactive
3510
days old
epel-devel@lists.fedoraproject.org
8 comments
4 participants
participants (4)
-
Jim Perrin -
Karanbir Singh -
Kevin Fenzi -
Sam Kottler