One of the items on the Roadmap I've sent out is centralizing packaging
into a single repository. The last time I tried this I attempted to go
whole hog migrating all things all at once. In order to make this more
approachable, and to encourage reviews, I would like to follow the
following plan in this rough order for nightlies only:
Move comps to foreman-packaging and update mash scripts
copy releasers and tito.props to foreman-packaging for katello
repositories
Move packages 1 by 1 to foreman-packaging starting leaving nightly RPMs
(rubygem-katello, hammer_cli_katello, and katello-installer) for last. This
will involve a PR to foreman-packaging and PR to katello-packaging adding
to the former and removing from the latter.
Update katello-packaging README to indicate deperecation
I am sending this plan along to gather feedback, find holes in the plan and
to get approval/disapproval from the community in taking this step.
My plan would be to begin this migration towards the end of next week.
> All,
>
> One of the items on the Roadmap I've sent out is centralizing
> packaging into a single repository. The last time I tried this I
> attempted to go whole hog migrating all things all at once. In order
> to make this more approachable, and to encourage reviews, I would like
> to follow the following plan in this rough order for nightlies only:
>
> 1) Move comps to foreman-packaging and update mash scripts
> 2) copy releasers and tito.props to foreman-packaging for katello
> repositories
> 3) Move packages 1 by 1 to foreman-packaging starting leaving nightly
> RPMs (rubygem-katello, hammer_cli_katello, and katello-installer) for
> last. This will involve a PR to foreman-packaging and PR to
> katello-packaging adding to the former and removing from the latter.
> 4) Update katello-packaging README to indicate deperecation
Sounds good to me! What are the plans for the non-ruby packages, such
as 'katello' and 'pulp-katello' ? These have hard requirements on pulp
(you can likely argue 'katello' should not), and likely would break any
repoclosure without including our 'pulp' repo in the repoclosure.
-Justin
···
On 10/20/2017 08:30 PM, Eric D Helms wrote:
I am sending this plan along to gather feedback, find holes in the
plan and to get approval/disapproval from the community in taking this
step.
My plan would be to begin this migration towards the end of next week.
> All,
>
> One of the items on the Roadmap I've sent out is centralizing packaging
> into a single repository. The last time I tried this I attempted to go
> whole hog migrating all things all at once. In order to make this more
> approachable, and to encourage reviews, I would like to follow the
> following plan in this rough order for nightlies only:
>
> 1) Move comps to foreman-packaging and update mash scripts
> 2) copy releasers and tito.props to foreman-packaging for katello
> repositories
> 3) Move packages 1 by 1 to foreman-packaging starting leaving nightly RPMs
> (rubygem-katello, hammer_cli_katello, and katello-installer) for last. This
> will involve a PR to foreman-packaging and PR to katello-packaging adding
> to the former and removing from the latter.
> 4) Update katello-packaging README to indicate deperecation
>
> I am sending this plan along to gather feedback, find holes in the plan and
> to get approval/disapproval from the community in taking this step.
>
> My plan would be to begin this migration towards the end of next week.
I think it sounds great, ping me when you submit these PRs if you want someone
to take a look.
Would koji be affected by this? For example, new katello packages in the
foreman-packaging repository would need to be in foreman tags or still the
katello tags? If the latter, any reason why it would not make sense to change that
to treat it like any other plugin?
>
>
>
> All,
>
> One of the items on the Roadmap I've sent out is centralizing packaging
> into a single repository. The last time I tried this I attempted to go
> whole hog migrating all things all at once. In order to make this more
> approachable, and to encourage reviews, I would like to follow the
> following plan in this rough order for nightlies only:
>
> 1) Move comps to foreman-packaging and update mash scripts
> 2) copy releasers and tito.props to foreman-packaging for katello
> repositories
> 3) Move packages 1 by 1 to foreman-packaging starting leaving nightly
> RPMs (rubygem-katello, hammer_cli_katello, and katello-installer) for last.
> This will involve a PR to foreman-packaging and PR to katello-packaging
> adding to the former and removing from the latter.
> 4) Update katello-packaging README to indicate deperecation
>
>
> Sounds good to me! What are the plans for the non-ruby packages, such as
> 'katello' and 'pulp-katello' ? These have hard requirements on pulp (you
> can likely argue 'katello' should not), and likely would break any
> repoclosure without including our 'pulp' repo in the repoclosure.
>
Note that this plan says nothing about changing our actual yum repository
structure. That would come later. This is just about beginning with moving
all package management to be centralized in foreman-packaging git
repository.
Eric
···
On Sun, Oct 22, 2017 at 9:21 PM, Justin Sherrill wrote:
> On 10/20/2017 08:30 PM, Eric D Helms wrote:
-Justin
I am sending this plan along to gather feedback, find holes in the plan
and to get approval/disapproval from the community in taking this step.
My plan would be to begin this migration towards the end of next week.
> > All,
> >
> > One of the items on the Roadmap I've sent out is centralizing packaging
> > into a single repository. The last time I tried this I attempted to go
> > whole hog migrating all things all at once. In order to make this more
> > approachable, and to encourage reviews, I would like to follow the
> > following plan in this rough order for nightlies only:
> >
> > 1) Move comps to foreman-packaging and update mash scripts
> > 2) copy releasers and tito.props to foreman-packaging for katello
> > repositories
> > 3) Move packages 1 by 1 to foreman-packaging starting leaving nightly
> RPMs
> > (rubygem-katello, hammer_cli_katello, and katello-installer) for last.
> This
> > will involve a PR to foreman-packaging and PR to katello-packaging adding
> > to the former and removing from the latter.
> > 4) Update katello-packaging README to indicate deperecation
> >
> > I am sending this plan along to gather feedback, find holes in the plan
> and
> > to get approval/disapproval from the community in taking this step.
> >
> > My plan would be to begin this migration towards the end of next week.
>
> I think it sounds great, ping me when you submit these PRs if you want
> someone
> to take a look.
>
> Would koji be affected by this? For example, new katello packages in the
> foreman-packaging repository would need to be in foreman tags or still the
> katello tags? If the latter, any reason why it would not make sense to
> change that
> to treat it like any other plugin?
>
Koji has no binding to the git repository, as long as the releasers tag
target Katello's (for the releasers I plan to bring over) then it will
release the package to the standard Katello tags. There are a few forces at
play in order to get Katello to be treated like other plugins:
Move the git packaging to the same repository
Devise a plan that allows any plugin to be individually tested and
committed to Koji or pushed to the repositories.
Solve the bandwidth issue (Greg mentioned they are working on this)
There are rough plans in place for everything but #2. And given that today,
Katello runs a system level test before pushing this one is imperative for
assuring the same level of assurance in the code.
···
On Mon, Oct 23, 2017 at 5:57 AM, Daniel Lobato Garcia wrote:
> On 10/20, Eric D Helms wrote:
So if I understand right, then all the packages are still hosted on
the Katello side for now, and this is just a merging of the source
trees? I'm fine with that - I'm still waiting on sorting a CDN for
the web node, so until that's done I can't +1 something that adds
bandwidth costs, but this isn't it
Greg
···
On Sun, 2017-10-22 at 21:27 -0400, Eric D Helms wrote:
>
> Note that this plan says nothing about changing our actual yum
> repository structure. That would come later. This is just about
> beginning with moving all package management to be centralized in
> foreman-packaging git repository.
