Re: [foreman-dev] [infra] Packaging reorganization

2017-09-04 Thread Ewoud Kohl van Wijngaarden 

On Mon, Sep 04, 2017 at 02:13:27PM -0400, Justin Sherrill wrote:


On 09/02/2017 03:00 PM, Eric D Helms wrote:


On Sep 2, 2017 10:22 AM, "Timo Goebel" > wrote:


   I am wondering if we should name the katello-client repository
   either foreman-client or just client. I can think of more plugins
   that need a client package.
   Timo


I was not going to suggest this yet, but since you brought it up and 
know of other client tools I think this would be a great addition 
and coming together for Foreman and Katello.  For the yum 
repositories (maybe this also translates for Debian? sorry I am not 
as familiar with them) I'd then suggest changing our structure to 
the following:
It might be even more out of scope, but i could see value in having 
hammer and all the hammer plugins in a client repo as well.


From an issue in puppet-foreman we know users deploy Hammer using 
puppet-foreman without installing foreman itself so that might make 
sense. Makes me wonder if we should split off foreman::cli into a 
separate hammer module.



-Justin



http://yum.theforeman.org
 -- nightly/
-- foreman/
  -- el7/
-- plugins/
-- el7/
-- client/
-- el7/
  -- el6/
  -- el5/
  -- f25/
  -- f26/
-- katello/
  -- el7/
-- pulp/
-- el7/
-- candlepin/
-- el7/
 -- 1.15
 -- 1.14

Another question, though possibly overkill would be if its worth 
separating out the smart proxy (and plugins) to their own repository 
to differentiate them more clearly (and potentially support more 
distros?).



   On 2. Sep 2017, at 01:48, Eric D Helms > wrote:


   Howdy,

   As a lead-in to being working towards migrating Katello's
   packages to the foreman-packaging repository, I'd like to propose
   a slight re-organization of the repository. As well, to seek any
   other ideas or problems any might see with the proposal.

   Currently, the packaging repository is a flat structure with all
   packages being represented by a directory containing sources and
   a spec file. When looking at it, I find it hard to think about
   them in an organized manner given we separate by repository into
   foreman and foreman-plugins (and eventually katello
   repositories). Thus, my proposal is to let the packaging
   repository reflect the repository organization by moving things
   into the following directories:

   foreman-packaging
  - foreman
  - plugins
  - katello
  - katello-client


   Thoughts?


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] [infra] Packaging reorganization

2017-09-04 Thread Justin Sherrill 



On 09/02/2017 03:00 PM, Eric D Helms wrote:



On Sep 2, 2017 10:22 AM, "Timo Goebel" > wrote:


I am wondering if we should name the katello-client repository
either foreman-client or just client. I can think of more plugins
that need a client package.
Timo


I was not going to suggest this yet, but since you brought it up and 
know of other client tools I think this would be a great addition and 
coming together for Foreman and Katello.  For the yum repositories 
(maybe this also translates for Debian? sorry I am not as familiar 
with them) I'd then suggest changing our structure to the following:
It might be even more out of scope, but i could see value in having 
hammer and all the hammer plugins in a client repo as well.


-Justin



http://yum.theforeman.org
  -- nightly/
 -- foreman/
   -- el7/
 -- plugins/
-- el7/
 -- client/
-- el7/
   -- el6/
   -- el5/
   -- f25/
   -- f26/
 -- katello/
   -- el7/
 -- pulp/
-- el7/
 -- candlepin/
-- el7/
  -- 1.15
  -- 1.14

Another question, though possibly overkill would be if its worth 
separating out the smart proxy (and plugins) to their own repository 
to differentiate them more clearly (and potentially support more 
distros?).



On 2. Sep 2017, at 01:48, Eric D Helms > wrote:


Howdy,

As a lead-in to being working towards migrating Katello's
packages to the foreman-packaging repository, I'd like to propose
a slight re-organization of the repository. As well, to seek any
other ideas or problems any might see with the proposal.

Currently, the packaging repository is a flat structure with all
packages being represented by a directory containing sources and
a spec file. When looking at it, I find it hard to think about
them in an organized manner given we separate by repository into
foreman and foreman-plugins (and eventually katello
repositories). Thus, my proposal is to let the packaging
repository reflect the repository organization by moving things
into the following directories:

foreman-packaging
   - foreman
   - plugins
   - katello
   - katello-client


Thoughts?

-- 
Eric D. Helms

Red Hat Engineering
-- 
You received this message because you are subscribed to the

Google Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-dev+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout
.
-- 
You received this message because you are subscribed to the Google

Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-dev+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout
.


--
You received this message because you are subscribed to the Google 
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to foreman-dev+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] [infra] Packaging reorganization

2017-09-04 Thread Marek Hulán 
Perhaps the foreman_scap_client could be one. There's the gem itself [1] and 
configuring puppet module that we also package [2]

[1] 
https://github.com/theforeman/foreman-packaging/tree/rpm/1.16/rubygem-foreman_scap_client
[2] 
https://github.com/theforeman/foreman-packaging/tree/rpm/1.16/puppet-foreman_scap_client

--
Marek

On sobota 2. září 2017 16:22:36 CEST Timo Goebel wrote:
> I am wondering if we should name the katello-client repository either
> foreman-client or just client. I can think of more plugins that need a
> client package. Timo
> 
> > On 2. Sep 2017, at 01:48, Eric D Helms  wrote:
> > 
> > Howdy,
> > 
> > As a lead-in to being working towards migrating Katello's packages to the
> > foreman-packaging repository, I'd like to propose a slight
> > re-organization of the repository. As well, to seek any other ideas or
> > problems any might see with the proposal.
> > 
> > Currently, the packaging repository is a flat structure with all packages
> > being represented by a directory containing sources and a spec file. When
> > looking at it, I find it hard to think about them in an organized manner
> > given we separate by repository into foreman and foreman-plugins (and
> > eventually katello repositories). Thus, my proposal is to let the
> > packaging repository reflect the repository organization by moving things
> > into the following directories:
> > 
> > foreman-packaging
> > 
> >- foreman
> >- plugins
> >- katello
> >- katello-client
> > 
> > Thoughts?

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] [infra] Packaging reorganization

2017-09-02 Thread Eric D Helms 
On Sep 2, 2017 10:22 AM, "Timo Goebel"  wrote:

I am wondering if we should name the katello-client repository either
foreman-client or just client. I can think of more plugins that need a
client package.
Timo


I was not going to suggest this yet, but since you brought it up and know
of other client tools I think this would be a great addition and coming
together for Foreman and Katello.  For the yum repositories (maybe this
also translates for Debian? sorry I am not as familiar with them) I'd then
suggest changing our structure to the following:

http://yum.theforeman.org
  -- nightly/
 -- foreman/
   -- el7/
 -- plugins/
   -- el7/
 -- client/
   -- el7/
   -- el6/
   -- el5/
   -- f25/
   -- f26/
 -- katello/
   -- el7/
 -- pulp/
   -- el7/
 -- candlepin/
   -- el7/
  -- 1.15
  -- 1.14

Another question, though possibly overkill would be if its worth separating
out the smart proxy (and plugins) to their own repository to differentiate
them more clearly (and potentially support more distros?).


On 2. Sep 2017, at 01:48, Eric D Helms  wrote:

Howdy,

As a lead-in to being working towards migrating Katello's packages to the
foreman-packaging repository, I'd like to propose a slight re-organization
of the repository. As well, to seek any other ideas or problems any might
see with the proposal.

Currently, the packaging repository is a flat structure with all packages
being represented by a directory containing sources and a spec file. When
looking at it, I find it hard to think about them in an organized manner
given we separate by repository into foreman and foreman-plugins (and
eventually katello repositories). Thus, my proposal is to let the packaging
repository reflect the repository organization by moving things into the
following directories:

foreman-packaging
   - foreman
   - plugins
   - katello
   - katello-client


Thoughts?

-- 
Eric D. Helms
Red Hat Engineering

-- 
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] [infra] Packaging reorganization

2017-09-02 Thread Timo Goebel 
I am wondering if we should name the katello-client repository either 
foreman-client or just client. I can think of more plugins that need a client 
package.
Timo

> On 2. Sep 2017, at 01:48, Eric D Helms  wrote:
> 
> Howdy,
> 
> As a lead-in to being working towards migrating Katello's packages to the 
> foreman-packaging repository, I'd like to propose a slight re-organization of 
> the repository. As well, to seek any other ideas or problems any might see 
> with the proposal.
> 
> Currently, the packaging repository is a flat structure with all packages 
> being represented by a directory containing sources and a spec file. When 
> looking at it, I find it hard to think about them in an organized manner 
> given we separate by repository into foreman and foreman-plugins (and 
> eventually katello repositories). Thus, my proposal is to let the packaging 
> repository reflect the repository organization by moving things into the 
> following directories:
> 
> foreman-packaging
>- foreman
>- plugins
>- katello
>- katello-client
> 
> 
> Thoughts?
> 
> -- 
> Eric D. Helms
> Red Hat Engineering
> -- 
> You received this message because you are subscribed to the Google Groups 
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] [infra] Packaging reorganization

2017-09-02 Thread Eric D Helms 
On Sep 2, 2017 6:17 AM, "Ewoud Kohl van Wijngaarden" <
ew...@kohlvanwijngaarden.nl> wrote:

On Fri, Sep 01, 2017 at 07:48:19PM -0400, Eric D Helms wrote:

> As a lead-in to being working towards migrating Katello's packages to the
> foreman-packaging repository, I'd like to propose a slight re-organization
> of the repository. As well, to seek any other ideas or problems any might
> see with the proposal.
>
> Currently, the packaging repository is a flat structure with all packages
> being represented by a directory containing sources and a spec file. When
> looking at it, I find it hard to think about them in an organized manner
> given we separate by repository into foreman and foreman-plugins (and
> eventually katello repositories). Thus, my proposal is to let the packaging
> repository reflect the repository organization by moving things into the
> following directories:
>
> foreman-packaging
>   - foreman
>   - plugins
>   - katello
>   - katello-client
>
>
> Thoughts?
>

It makes sense to me and I have the same problem but it does make me wonder
how we deal repo boundries/repoclosure.

Plugins probably needs foreman where katello probably requires foreman and
maybe plugins. If a package from plugins is now required in foreman, is it
moved?


Yes. The breakdown in the packaging repository would essentially be by
repository. So if something lives in the foreman repository it lives in the
foreman folder. Repository requires and repoclosure should not be affected
by this change.


I assume katello-client is supposed not to require any other repos, just
base OS and possibly EPEL. If a package is needed in both foreman and
katello-client, should it be copied?


That's a good question. I would say it should go in the most base of
repositories in a heirarchy given that koji only lets you have a single
build in it but can be tagged across. I think this situation should be rare.


Long term/big picture: I know we have pulp and candlepin. Where do they fit
in? Should katello eventually be merged into plugins?


We don't manage Pulp and Candlepin packaging from that perspective. We make
use of their builds but the process is separate. I think most would
probably argue for putting Katello into the plugins repository once we
figure out a few constraints within our CI.

Eric



-- 
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] [infra] Packaging reorganization

2017-09-02 Thread Ewoud Kohl van Wijngaarden 

On Fri, Sep 01, 2017 at 07:48:19PM -0400, Eric D Helms wrote:

As a lead-in to being working towards migrating Katello's packages to the
foreman-packaging repository, I'd like to propose a slight re-organization
of the repository. As well, to seek any other ideas or problems any might
see with the proposal.

Currently, the packaging repository is a flat structure with all packages
being represented by a directory containing sources and a spec file. When
looking at it, I find it hard to think about them in an organized manner
given we separate by repository into foreman and foreman-plugins (and
eventually katello repositories). Thus, my proposal is to let the packaging
repository reflect the repository organization by moving things into the
following directories:

foreman-packaging
  - foreman
  - plugins
  - katello
  - katello-client


Thoughts?


It makes sense to me and I have the same problem but it does make me 
wonder how we deal repo boundries/repoclosure.


Plugins probably needs foreman where katello probably requires foreman 
and maybe plugins. If a package from plugins is now required in foreman, 
is it moved?


I assume katello-client is supposed not to require any other repos, just 
base OS and possibly EPEL. If a package is needed in both foreman and 
katello-client, should it be copied?


Long term/big picture: I know we have pulp and candlepin. Where do they 
fit in? Should katello eventually be merged into plugins?


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.