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] Proposal to Move Jenkins Job Configurations

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

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

> Howdy,
>
> Some quick background, for those that don't know a majority of our Jenkins
> job configuration are stored in git. I find our Jenkins job configuration
> to be important for developers to be able to understand and contribute
> changes. However, today, these configurations are stored deep inside the
> foreman-infra [1] repository. I am proposing one of two ideas to bring
> these to the forefront:
>
> 1) Move them to the top of foreman-infra under a "jenkins" or "jobs" folder
> 2) Move them to their own repository (e.g. foreman-ci)
>
>
> [1]
> https://github.com/theforeman/foreman-infra/tree/master/pupp
> et/modules/jenkins_job_builder/files/theforeman.org
>

+1 on bringing them to the forefront. The question where to put them is,
for better or worse, tightly coupled to the way we deploy them. Currently
it's puppet. If you move them to the top it can still be deployed easily
with a symlink or other scripting magic.

Splitting to their own repository makes it harder to re-use the puppet
deployment pipeline and we'd need to build a new one. Where would we put
this? Usually you think of Jenkins when building a pipeline but having
Jenkins manage itself might not be the best idea.


Could the puppet just clone the repository if using option #2 and work like
before?


Given that background right now I'm leaning to 1) but I can easily be
convinced of 2) if a more suitable deployment method is found.


-- 
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] Proposal to Move Jenkins Job Configurations

2017-09-02 Thread Ewoud Kohl van Wijngaarden 

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

Howdy,

Some quick background, for those that don't know a majority of our Jenkins
job configuration are stored in git. I find our Jenkins job configuration
to be important for developers to be able to understand and contribute
changes. However, today, these configurations are stored deep inside the
foreman-infra [1] repository. I am proposing one of two ideas to bring
these to the forefront:

1) Move them to the top of foreman-infra under a "jenkins" or "jobs" folder
2) Move them to their own repository (e.g. foreman-ci)


[1]
https://github.com/theforeman/foreman-infra/tree/master/puppet/modules/jenkins_job_builder/files/theforeman.org


+1 on bringing them to the forefront. The question where to put them is, 
for better or worse, tightly coupled to the way we deploy them. 
Currently it's puppet. If you move them to the top it can still be 
deployed easily with a symlink or other scripting magic.


Splitting to their own repository makes it harder to re-use the puppet 
deployment pipeline and we'd need to build a new one. Where would we put 
this? Usually you think of Jenkins when building a pipeline but having 
Jenkins manage itself might not be the best idea.


Given that background right now I'm leaning to 1) but I can easily be 
convinced of 2) if a more suitable deployment method is found.


--
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.