Re: [openstack-dev] [kolla][release] Version numbers for kolla-ansible repository.

[Steven Dake (stdake)]

Thanks,

I have done exactly as you recommended.

Regards
-steve





On 11/12/16, 10:49 AM, "Andreas Jaeger"  wrote:

>On 11/12/2016 11:15 AM, Steven Dake (stdake) wrote:
>> The proposal I think you made is what I was thinking we would do, so just to 
>> clarify:
>>  Kolla keeps all branches/tags
>>  When kolla-ansible is created with an upstream tag in PC, the 
>> project-config will include no post jobs so no artifacts will be created
>
>we import the complete repo - so create a copy of the repo for import, 
>delete the branches and tags on that copy - and then it gets imported as 
>is. Then you don't need post jobs removal.
>
>> Kolla-ansible will have all branches deleted from it (so we maintain the 
>> back ports in the kolla repo where the code originated
>
>Do this as before.
>
>> New (ocata) versions of kolla-ansible will have a 4.0.0 tag but no branches, 
>> and possibly no tags.
>>
>> The delta between kolla and kolla-ansible is in the diagram in this thread, 
>> but in a nutshell:
>>
>> Today Kolla contains build.py docker dir, sensible dir, and kolla-ansible.py
>>
>> In the future:
>> Kolla - contains build.py, docker dir
>> Kolla-ansible contains sensible dir, kolla-ansible.py
>>
>> Both repos contain whatever is needed to make those repos work with the 
>> various OpenStack processes.
>>
>> I agree back ports will be more challenging in general with a repo split.  
>> The core reviewers committed to maintaining back ports properly when they 
>> voted on the repo split.
>
>Andreas
>-- 
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][release] Version numbers for kolla-ansible repository.

[Andreas Jaeger]

On 11/12/2016 11:15 AM, Steven Dake (stdake) wrote:

The proposal I think you made is what I was thinking we would do, so just to 
clarify:
 Kolla keeps all branches/tags
 When kolla-ansible is created with an upstream tag in PC, the project-config 
will include no post jobs so no artifacts will be created


we import the complete repo - so create a copy of the repo for import, 
delete the branches and tags on that copy - and then it gets imported as 
is. Then you don't need post jobs removal.



Kolla-ansible will have all branches deleted from it (so we maintain the back 
ports in the kolla repo where the code originated


Do this as before.


New (ocata) versions of kolla-ansible will have a 4.0.0 tag but no branches, 
and possibly no tags.

The delta between kolla and kolla-ansible is in the diagram in this thread, but 
in a nutshell:

Today Kolla contains build.py docker dir, sensible dir, and kolla-ansible.py

In the future:
Kolla - contains build.py, docker dir
Kolla-ansible contains sensible dir, kolla-ansible.py

Both repos contain whatever is needed to make those repos work with the various 
OpenStack processes.

I agree back ports will be more challenging in general with a repo split.  The 
core reviewers committed to maintaining back ports properly when they voted on 
the repo split.


Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][release] Version numbers for kolla-ansible repository.

[Steven Dake (stdake)]

The proposal I think you made is what I was thinking we would do, so just to 
clarify:
 Kolla keeps all branches/tags
 When kolla-ansible is created with an upstream tag in PC, the project-config 
will include no post jobs so no artifacts will be created
Kolla-ansible will have all branches deleted from it (so we maintain the back 
ports in the kolla repo where the code originated
New (ocata) versions of kolla-ansible will have a 4.0.0 tag but no branches, 
and possibly no tags.

The delta between kolla and kolla-ansible is in the diagram in this thread, but 
in a nutshell:

Today Kolla contains build.py docker dir, sensible dir, and kolla-ansible.py

In the future:
Kolla - contains build.py, docker dir
Kolla-ansible contains sensible dir, kolla-ansible.py

Both repos contain whatever is needed to make those repos work with the various 
OpenStack processes.

I agree back ports will be more challenging in general with a repo split.  The 
core reviewers committed to maintaining back ports properly when they voted on 
the repo split.

Regards
-steve





On 11/11/16, 7:43 AM, "Doug Hellmann"  wrote:

>Excerpts from Steven Dake (stdake)'s message of 2016-11-08 21:41:26 +:
>> 
>> On 11/8/16, 9:08 AM, "Doug Hellmann"  wrote:
>> 
>> >Excerpts from Steven Dake (stdake)'s message of 2016-11-08 13:08:11 +:
>> >> Hey folks,
>> >> 
>> >> As we split out the repository per our unanimous vote several months ago, 
>> >> we have a choice to make (I think, assuming we are given latitude of  the 
>> >> release team who is in the cc list) as to which version to call 
>> >> kolla-ansible.
>> >> 
>> >> My personal preference is to completely retag our newly split repo with 
>> >> all old tags from kolla git revisions up to version 3.0.z.  The main 
>> >> rationale I can think of is kolla-ansible 1 = liberty, 2 = mitaka, 3 = 
>> >> newton.  I think calling kolla-ansible 1.0 = newton would be somewhat 
>> >> confusing, but we could do that as well.
>> >> 
>> >> The reason the repository needs to be retagged in either case is to 
>> >> generate release artifacts (tarballs, pypi, etc).
>> >> 
>> >> Would also like feedback from the release team on what they think is a 
>> >> best practice here (we may be breaking new ground for the OpenStack 
>> >> release team, maybe not – is there prior art here?)
>> >> 
>> >> For a diagram (mostly for the release team) of the repository split check 
>> >> out:
>> >> https://www.gliffy.com/go/share/sg9fc5eg9ktg9binvc89
>> >> 
>> >> Thanks!
>> >> -steve
>> >
>> >When you say "split," I'm going to assume that you mean the
>> >openstack/kolla repo has the full history but that openstack/kolla-ansible
>> >only contains part of the files and their history.
>> 
>> Doug,
>> 
>> I’d like to maintain history for both the repos, and then selectively remove 
>> the stuff not neeeded for each repo (so they will then diverge).
>
>Sure, that's one way to do it. I recommend picking just one of the
>repos to have the old tags. I'm not sure if it would be simpler to
>keep them in the repo that is current (openstack/kolla, I think?)
>because artifact names for the old versions won't change that way,
>or to keep all of that history and the stable branches in the repo
>where you'll be doing new work to make backporting simpler.
>
>What's the difference between kolla and kolla-ansible?
>
>> >Assuming the history is preserved in openstack/kolla, then I don't
>> >think you want new tags. The way to reproduce the 1, 2, or 3 versions
>> >is to check out the existing tag in openstack/kolla. Having similar
>> >tags in openstack/kolla-ansible will be confusing about which is
>> >the actual tag that produced the build artifacts that were shipped
>> >with those version numbers.  New versions tagged on master in
>> >openstack/kolla-ansible can still start from 4 (or 3.x, I suppose).
>> 
>> Ok that works.  I think the lesson there is we can’t change the past :)  I 
>> think we would want kolla-ansible 
>> 
>> >
>> >Do you maintain stable branches? Are those being kept in openstack/kolla
>> >or openstack/kolla-ansible?
>> Great question and something I hadn’t thought of.
>> 
>> Yes we maintain stable branches for liberty, mitaka, and newton.  I’m not 
>> sure if a stable branch for liberty is in policy for OpenStack.  Could you 
>> advice here?
>
>Liberty is scheduled to be EOL-ed around 17 Nov, so if you have the
>branch I would keep it for now and go through the EOL process normally.
>
>> 
>> I believe the result we want is to maintain the stable branches for 
>> liberty/mitaka/newton in kolla and then tag kolla-ansible Ocata as 4.0.0.  I 
>> don’t know if we need the 1/2/3 tags deleted in this case.  Could you advise?
>> 
>> Thanks for your help and contributions Doug :)
>> 
>> Regards
>> -steve
>> 
>> >
>> >Doug
>> >
>> >__
>> >OpenStack Development Mailing List (not for usage questions)
>> 

Re: [openstack-dev] [kolla][release] Version numbers for kolla-ansible repository.

[Doug Hellmann]

Excerpts from Steven Dake (stdake)'s message of 2016-11-08 21:41:26 +:
> 
> On 11/8/16, 9:08 AM, "Doug Hellmann"  wrote:
> 
> >Excerpts from Steven Dake (stdake)'s message of 2016-11-08 13:08:11 +:
> >> Hey folks,
> >> 
> >> As we split out the repository per our unanimous vote several months ago, 
> >> we have a choice to make (I think, assuming we are given latitude of  the 
> >> release team who is in the cc list) as to which version to call 
> >> kolla-ansible.
> >> 
> >> My personal preference is to completely retag our newly split repo with 
> >> all old tags from kolla git revisions up to version 3.0.z.  The main 
> >> rationale I can think of is kolla-ansible 1 = liberty, 2 = mitaka, 3 = 
> >> newton.  I think calling kolla-ansible 1.0 = newton would be somewhat 
> >> confusing, but we could do that as well.
> >> 
> >> The reason the repository needs to be retagged in either case is to 
> >> generate release artifacts (tarballs, pypi, etc).
> >> 
> >> Would also like feedback from the release team on what they think is a 
> >> best practice here (we may be breaking new ground for the OpenStack 
> >> release team, maybe not – is there prior art here?)
> >> 
> >> For a diagram (mostly for the release team) of the repository split check 
> >> out:
> >> https://www.gliffy.com/go/share/sg9fc5eg9ktg9binvc89
> >> 
> >> Thanks!
> >> -steve
> >
> >When you say "split," I'm going to assume that you mean the
> >openstack/kolla repo has the full history but that openstack/kolla-ansible
> >only contains part of the files and their history.
> 
> Doug,
> 
> I’d like to maintain history for both the repos, and then selectively remove 
> the stuff not neeeded for each repo (so they will then diverge).

Sure, that's one way to do it. I recommend picking just one of the
repos to have the old tags. I'm not sure if it would be simpler to
keep them in the repo that is current (openstack/kolla, I think?)
because artifact names for the old versions won't change that way,
or to keep all of that history and the stable branches in the repo
where you'll be doing new work to make backporting simpler.

What's the difference between kolla and kolla-ansible?

> >Assuming the history is preserved in openstack/kolla, then I don't
> >think you want new tags. The way to reproduce the 1, 2, or 3 versions
> >is to check out the existing tag in openstack/kolla. Having similar
> >tags in openstack/kolla-ansible will be confusing about which is
> >the actual tag that produced the build artifacts that were shipped
> >with those version numbers.  New versions tagged on master in
> >openstack/kolla-ansible can still start from 4 (or 3.x, I suppose).
> 
> Ok that works.  I think the lesson there is we can’t change the past :)  I 
> think we would want kolla-ansible 
> 
> >
> >Do you maintain stable branches? Are those being kept in openstack/kolla
> >or openstack/kolla-ansible?
> Great question and something I hadn’t thought of.
> 
> Yes we maintain stable branches for liberty, mitaka, and newton.  I’m not 
> sure if a stable branch for liberty is in policy for OpenStack.  Could you 
> advice here?

Liberty is scheduled to be EOL-ed around 17 Nov, so if you have the
branch I would keep it for now and go through the EOL process normally.

> 
> I believe the result we want is to maintain the stable branches for 
> liberty/mitaka/newton in kolla and then tag kolla-ansible Ocata as 4.0.0.  I 
> don’t know if we need the 1/2/3 tags deleted in this case.  Could you advise?
> 
> Thanks for your help and contributions Doug :)
> 
> Regards
> -steve
> 
> >
> >Doug
> >
> >__
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][release] Version numbers for kolla-ansible repository.

[Steven Dake (stdake)]

Thanks Jeremy.

That is a hugely helpful piece of advice.  I will include  a link to your email 
to make sure I’m doing it correctly when I split the repo.

Regards,
-steve






On 11/8/16, 8:24 AM, "Jeremy Stanley"  wrote:

>On 2016-11-08 19:07:07 +0530 (+0530), Swapnil Kulkarni wrote:
>[...]
>> I would love to get inputs from release team, though one of the recent
>> repo split I remember is neutron and if I look at the history, old
>> tags from git revisions are preserved. I think we can follow the same
>> process for kolla and kolla-ansible split.
>
>Yes, one lesson recently learned is that when the repo is imported,
>any tags present will trigger release jobs. Odds are you want to
>start with just noop jobs for the repo, or at least no jobs for the
>pre-release, release or tag pipelines (and then add them after the
>import is successful and you've looked it over).
>-- 
>Jeremy Stanley
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][release] Version numbers for kolla-ansible repository.

[Steven Dake (stdake)]

On 11/8/16, 9:08 AM, "Doug Hellmann"  wrote:

>Excerpts from Steven Dake (stdake)'s message of 2016-11-08 13:08:11 +:
>> Hey folks,
>> 
>> As we split out the repository per our unanimous vote several months ago, we 
>> have a choice to make (I think, assuming we are given latitude of  the 
>> release team who is in the cc list) as to which version to call 
>> kolla-ansible.
>> 
>> My personal preference is to completely retag our newly split repo with all 
>> old tags from kolla git revisions up to version 3.0.z.  The main rationale I 
>> can think of is kolla-ansible 1 = liberty, 2 = mitaka, 3 = newton.  I think 
>> calling kolla-ansible 1.0 = newton would be somewhat confusing, but we could 
>> do that as well.
>> 
>> The reason the repository needs to be retagged in either case is to generate 
>> release artifacts (tarballs, pypi, etc).
>> 
>> Would also like feedback from the release team on what they think is a best 
>> practice here (we may be breaking new ground for the OpenStack release team, 
>> maybe not – is there prior art here?)
>> 
>> For a diagram (mostly for the release team) of the repository split check 
>> out:
>> https://www.gliffy.com/go/share/sg9fc5eg9ktg9binvc89
>> 
>> Thanks!
>> -steve
>
>When you say "split," I'm going to assume that you mean the
>openstack/kolla repo has the full history but that openstack/kolla-ansible
>only contains part of the files and their history.

Doug,

I’d like to maintain history for both the repos, and then selectively remove 
the stuff not neeeded for each repo (so they will then diverge).

>
>Assuming the history is preserved in openstack/kolla, then I don't
>think you want new tags. The way to reproduce the 1, 2, or 3 versions
>is to check out the existing tag in openstack/kolla. Having similar
>tags in openstack/kolla-ansible will be confusing about which is
>the actual tag that produced the build artifacts that were shipped
>with those version numbers.  New versions tagged on master in
>openstack/kolla-ansible can still start from 4 (or 3.x, I suppose).

Ok that works.  I think the lesson there is we can’t change the past :)  I 
think we would want kolla-ansible 

>
>Do you maintain stable branches? Are those being kept in openstack/kolla
>or openstack/kolla-ansible?
Great question and something I hadn’t thought of.

Yes we maintain stable branches for liberty, mitaka, and newton.  I’m not sure 
if a stable branch for liberty is in policy for OpenStack.  Could you advice 
here?

I believe the result we want is to maintain the stable branches for 
liberty/mitaka/newton in kolla and then tag kolla-ansible Ocata as 4.0.0.  I 
don’t know if we need the 1/2/3 tags deleted in this case.  Could you advise?

Thanks for your help and contributions Doug :)

Regards
-steve

>
>Doug
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][release] Version numbers for kolla-ansible repository.

[Doug Hellmann]

Excerpts from Steven Dake (stdake)'s message of 2016-11-08 13:08:11 +:
> Hey folks,
> 
> As we split out the repository per our unanimous vote several months ago, we 
> have a choice to make (I think, assuming we are given latitude of  the 
> release team who is in the cc list) as to which version to call kolla-ansible.
> 
> My personal preference is to completely retag our newly split repo with all 
> old tags from kolla git revisions up to version 3.0.z.  The main rationale I 
> can think of is kolla-ansible 1 = liberty, 2 = mitaka, 3 = newton.  I think 
> calling kolla-ansible 1.0 = newton would be somewhat confusing, but we could 
> do that as well.
> 
> The reason the repository needs to be retagged in either case is to generate 
> release artifacts (tarballs, pypi, etc).
> 
> Would also like feedback from the release team on what they think is a best 
> practice here (we may be breaking new ground for the OpenStack release team, 
> maybe not – is there prior art here?)
> 
> For a diagram (mostly for the release team) of the repository split check out:
> https://www.gliffy.com/go/share/sg9fc5eg9ktg9binvc89
> 
> Thanks!
> -steve

When you say "split," I'm going to assume that you mean the
openstack/kolla repo has the full history but that openstack/kolla-ansible
only contains part of the files and their history.

Assuming the history is preserved in openstack/kolla, then I don't
think you want new tags. The way to reproduce the 1, 2, or 3 versions
is to check out the existing tag in openstack/kolla. Having similar
tags in openstack/kolla-ansible will be confusing about which is
the actual tag that produced the build artifacts that were shipped
with those version numbers.  New versions tagged on master in
openstack/kolla-ansible can still start from 4 (or 3.x, I suppose).

Do you maintain stable branches? Are those being kept in openstack/kolla
or openstack/kolla-ansible?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][release] Version numbers for kolla-ansible repository.

[Jeremy Stanley]

On 2016-11-08 19:07:07 +0530 (+0530), Swapnil Kulkarni wrote:
[...]
> I would love to get inputs from release team, though one of the recent
> repo split I remember is neutron and if I look at the history, old
> tags from git revisions are preserved. I think we can follow the same
> process for kolla and kolla-ansible split.

Yes, one lesson recently learned is that when the repo is imported,
any tags present will trigger release jobs. Odds are you want to
start with just noop jobs for the repo, or at least no jobs for the
pre-release, release or tag pipelines (and then add them after the
import is successful and you've looked it over).
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][release] Version numbers for kolla-ansible repository.

[Swapnil Kulkarni]

On Tue, Nov 8, 2016 at 6:38 PM, Steven Dake (stdake)  wrote:
> Hey folks,
>
> As we split out the repository per our unanimous vote several months ago, we
> have a choice to make (I think, assuming we are given latitude of  the
> release team who is in the cc list) as to which version to call
> kolla-ansible.
>
> My personal preference is to completely retag our newly split repo with all
> old tags from kolla git revisions up to version 3.0.z.  The main rationale I
> can think of is kolla-ansible 1 = liberty, 2 = mitaka, 3 = newton.  I think
> calling kolla-ansible 1.0 = newton would be somewhat confusing, but we could
> do that as well.
>
> The reason the repository needs to be retagged in either case is to generate
> release artifacts (tarballs, pypi, etc).
>
> Would also like feedback from the release team on what they think is a best
> practice here (we may be breaking new ground for the OpenStack release team,
> maybe not – is there prior art here?)
>
> For a diagram (mostly for the release team) of the repository split check
> out:
> https://www.gliffy.com/go/share/sg9fc5eg9ktg9binvc89
>
> Thanks!
> -steve
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


I would love to get inputs from release team, though one of the recent
repo split I remember is neutron and if I look at the history, old
tags from git revisions are preserved. I think we can follow the same
process for kolla and kolla-ansible split.



-coolsvap

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla][release] Version numbers for kolla-ansible repository.

[Steven Dake (stdake)]

Hey folks,

As we split out the repository per our unanimous vote several months ago, we 
have a choice to make (I think, assuming we are given latitude of  the release 
team who is in the cc list) as to which version to call kolla-ansible.

My personal preference is to completely retag our newly split repo with all old 
tags from kolla git revisions up to version 3.0.z.  The main rationale I can 
think of is kolla-ansible 1 = liberty, 2 = mitaka, 3 = newton.  I think calling 
kolla-ansible 1.0 = newton would be somewhat confusing, but we could do that as 
well.

The reason the repository needs to be retagged in either case is to generate 
release artifacts (tarballs, pypi, etc).

Would also like feedback from the release team on what they think is a best 
practice here (we may be breaking new ground for the OpenStack release team, 
maybe not – is there prior art here?)

For a diagram (mostly for the release team) of the repository split check out:
https://www.gliffy.com/go/share/sg9fc5eg9ktg9binvc89

Thanks!
-steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev