11:55 a.m.
I've posted a WIP patch[1] based on what we've done in the downstream
OSP releases with tripleo-heat-templates to provide backwards
compatible heat templates for managing older versions.
The base requirements are:
* Package the latest tripleo-heat-templates from the previous release
(in this case mitaka)
* Must be installable side-by-side with the the current version heat-templates
* A single srpm if at all possible
The patch essentially mimics what has been done downstream previously
and has generally worked. Getting it to work with DLRN is more
difficult and sub-optimal due to having to track multiple upstream
branches.
I'm open to suggestions for how to deal with this challenge and am
certainly not stuck on the this being the solution.
Thanks
Mike
[1] http://review.rdoproject.org/r/2042
5:04 p.m.
* A single srpm if at all possible
Why is that a requirement? Usually in rpm world you create separate
parallel installable compat package by adding version to the package
name e.g. we had python-webob1.2 in the past.
THT mitaka is 2.x so what about creating a new package
openstack-tripleo-heat-templates2 ?
Alan
7:50 p.m.
On Fri, Sep 2, 2016 at 6:04 PM, Alan Pevec <apevec(a)redhat.com> wrote:
> * A single srpm if at all possible
Why is that a requirement? Usually in rpm world you create separate
parallel installable compat package by adding version to the package
name e.g. we had python-webob1.2 in the past.
THT mitaka is 2.x so what about creating a new package
openstack-tripleo-heat-templates2 ?
We could do that and it's ok, really. It just means a new package
process for every release of OpenStack. There is no real clean
mapping historically of THT version to OpenStack version. How does
someone know that tht2 is mitaka? When we reach ocata and have to
have a BC package, it's tht5 which is newton. (We could simply name
it openstack-tripleo-heat-templates-mitaka).
The proposal currently means that we have to change 1 spec file value
per release rather than go through a totally new package each release.
Mike
Alan
9:47 a.m.
New subject: [rdo-list] Adding backwards compatible tripleo-heat-templates packaging
----- Original Message -----
On Fri, Sep 2, 2016 at 6:04 PM, Alan Pevec <apevec(a)redhat.com>
wrote:
>> * A single srpm if at all possible
>
> Why is that a requirement? Usually in rpm world you create separate
> parallel installable compat package by adding version to the package
> name e.g. we had python-webob1.2 in the past.
> THT mitaka is 2.x so what about creating a new package
> openstack-tripleo-heat-templates2 ?
We could do that and it's ok, really. It just means a new package
process for every release of OpenStack. There is no real clean
mapping historically of THT version to OpenStack version. How does
someone know that tht2 is mitaka? When we reach ocata and have to
have a BC package, it's tht5 which is newton. (We could simply name
it openstack-tripleo-heat-templates-mitaka).
I think something like this (having an openstack-tripleo-heat-templates-compat-mitaka
package or similar) would work best.
This would also allow us to decide when to drop support for older releases. Newton will
have a mitaka-compat package, but we'll sure drop it in a later release, won't we?
We could then just control which packages are built for each release using rdoinfo.
Javier
The proposal currently means that we have to change 1 spec file value
per release rather than go through a totally new package each release.
Mike
>
> Alan
_______________________________________________
rdo-list mailing list
rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com
7:29 a.m.
On Mon, Sep 5, 2016 at 10:47 AM, Javier Pena <javier.pena(a)redhat.com> wrote:
----- Original Message -----
> On Fri, Sep 2, 2016 at 6:04 PM, Alan Pevec <apevec(a)redhat.com> wrote:
> >> * A single srpm if at all possible
> >
> > Why is that a requirement? Usually in rpm world you create separate
> > parallel installable compat package by adding version to the package
> > name e.g. we had python-webob1.2 in the past.
> > THT mitaka is 2.x so what about creating a new package
> > openstack-tripleo-heat-templates2 ?
>
> We could do that and it's ok, really. It just means a new package
> process for every release of OpenStack. There is no real clean
> mapping historically of THT version to OpenStack version. How does
> someone know that tht2 is mitaka? When we reach ocata and have to
> have a BC package, it's tht5 which is newton. (We could simply name
> it openstack-tripleo-heat-templates-mitaka).
I think something like this (having an openstack-tripleo-heat-templates-compat-mitaka
package or similar) would work best.
This would also allow us to decide when to drop support for older releases. Newton will
have a mitaka-compat package, but we'll sure drop it in a later release, won't we?
We could then just control which packages are built for each release using rdoinfo.
Javier
If we do this, *every* release will drop a package and add a package.
The tripleo team won't commit to supporting more than 1 version back
currently, so -mitaka would only be included with the newton release.
In Ocata, we'd drop mitaka and add -newton. This is part of the
reason that a single tarball made things easier. Just get the right
source tarball for old release and build it in a single package. An
update per release in a single spec file is generally easier than a
new package.
Mike
>
> The proposal currently means that we have to change 1 spec file value
> per release rather than go through a totally new package each release.
>
> Mike
>
>
> >
> > Alan
>
> _______________________________________________
> rdo-list mailing list
> rdo-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe(a)redhat.com
>
3:59 a.m.
> I think something like this (having an
openstack-tripleo-heat-templates-compat-mitaka package or similar) would work best.
>
> This would also allow us to decide when to drop support for older releases. Newton
will have a mitaka-compat package, but we'll sure drop it in a later release,
won't we? We could then just control which packages are built for each release using
rdoinfo.
If we do this, *every* release will drop a package and add a package.
The tripleo team won't commit to supporting more than 1 version back
currently, so -mitaka would only be included with the newton release.
If that's defined in a tripleo spec, please provide a link.
In Ocata, we'd drop mitaka and add -newton. This is part of the
reason that a single tarball made things easier. Just get the right
source tarball for old release and build it in a single package. An
update per release in a single spec file is generally easier than a
new package.
How is that done in upstream tripleoci jobs which is testing upgrade?
Is that just checking out stable branch? Link please :)
Problmem with the proposed change is how to supply Source1 to Trunk
builders, currently it handles only single Source0 by replacing it
with the tarball generated from the git checkout. We would have to
keep full Source1 tarball in the distgit and manually keep it in sync
with the stable source branch.
While this might look like a nail-hammer tool deficiency, tracking two
branches in the same package is really adding unnecessary complexity.
What about adding a new package
openstack-tripleo-heat-templates-compat which would be configured in
rdoinfo to take Source0 from the previous stable branch and only that
metadata would get updated for the new release e.g.
- project: tripleo-heat-templates-compat
tags:
newton-uc:
source-branch: stable/mitaka
newton:
source-branch: stable/mitaka
mitaka:
source-branch: stable/liberty
conf: rpmfactory-core
maintainers:
- mburns(a)redhat.com
It would install into {_datadir}/%{name}/%{old_name} and
openstack-tripleo-heat-templates could have Requires:
openstack-tripleo-heat-templates-compat so that no changes are
required in the installer.
Cheers,
Alan
4:43 p.m.
On Wed, Sep 14, 2016 at 4:59 AM, Alan Pevec <apevec(a)redhat.com> wrote:
>> I think something like this (having an
openstack-tripleo-heat-templates-compat-mitaka package or similar) would work best.
>>
>> This would also allow us to decide when to drop support for older releases.
Newton will have a mitaka-compat package, but we'll sure drop it in a later release,
won't we? We could then just control which packages are built for each release using
rdoinfo.
>
> If we do this, *every* release will drop a package and add a package.
> The tripleo team won't commit to supporting more than 1 version back
> currently, so -mitaka would only be included with the newton release.
If that's defined in a tripleo spec, please provide a link.
> In Ocata, we'd drop mitaka and add -newton. This is part of the
> reason that a single tarball made things easier. Just get the right
> source tarball for old release and build it in a single package. An
> update per release in a single spec file is generally easier than a
> new package.
How is that done in upstream tripleoci jobs which is testing upgrade?
This isn't upgrade, it's old version support. Managing a Mitaka
overcloud with a Newton undercloud. AFAIK, there is no support for
this in CI today due to the lack of this compat package existing in
RDO.
Is that just checking out stable branch? Link please :)
Problmem with the proposed change is how to supply Source1 to Trunk
builders, currently it handles only single Source0 by replacing it
with the tarball generated from the git checkout. We would have to
keep full Source1 tarball in the distgit and manually keep it in sync
with the stable source branch.
While this might look like a nail-hammer tool deficiency, tracking two
branches in the same package is really adding unnecessary complexity.
What about adding a new package
openstack-tripleo-heat-templates-compat which would be configured in
rdoinfo to take Source0 from the previous stable branch and only that
metadata would get updated for the new release e.g.
- project: tripleo-heat-templates-compat
tags:
newton-uc:
source-branch: stable/mitaka
newton:
source-branch: stable/mitaka
mitaka:
source-branch: stable/liberty
conf: rpmfactory-core
maintainers:
- mburns(a)redhat.com
I'm fine with this (except I shouldn't be the long term owner, but
we'll solve that later).
It would install into {_datadir}/%{name}/%{old_name} and
openstack-tripleo-heat-templates could have Requires:
openstack-tripleo-heat-templates-compat so that no changes are
required in the installer.
I've posted an initial spec here:
https://github.com/mburns72h/openstack-tripleo-heat-templates-compat-distgit
Mike
Cheers,
Alan
2790
days inactive
2802
days old
6 comments
3 participants
participants (3)
-
Alan Pevec -
Javier Pena -
Mike Burns