[openstack-dev] [neutron] [release]

[Miguel Lavalle]

Hi everybody,

This message is to announce that effective now Akihiro Amotoki has accepted
to be the new Neutron liaison with the Release team. As such, Akihiro will
be responsible for coordinating the releases of Neutron project and the
Neutron Stadium projects, starting with the upcoming Rocky-1 release

I also want to take this opportunity to thank Armando Migliaccio for the
support he has provided over the past few cycles releasing Neutron to the
community. This is only a tiny fraction of the many great contributions
that Armando has made to OpenStack over many years. Thank you and good luck!


Best regards

Miguel
__
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] [neutron] Release liaison needed

[Dariusz Śmigiel]

Hey folks,
Unfortunately, I'm not able to fulfill release liaison role anymore.
The same applies to being infra liaison. It means, that this very
important role needs YOU!


If you'll decide to join the army of release liaisons, you will be
responsible for:
* releases!
* communication with release team!
* glory!
* your name will be placed here [1]

If you're not convinced yet, you can read about liaison responsibilities [2].

Join now! Neutron needs YOU!


[1] https://wiki.openstack.org/wiki/CrossProjectLiaisons
[2] 
https://docs.openstack.org/project-team-guide/release-management.html#liaison-responsibilities

PS I should be around for some time. So, if any help is needed, I can
try to help.

Thanks,
Dariusz

__
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] [neutron] [release] misleading release notes

[Dean Troyer]

On Thu, Feb 2, 2017 at 7:42 AM, Doug Hellmann  wrote:
> As long as the edit happens on the branch where the note should appear,
> it should be fine.

Excellent!  Just tried it and it does, thanks.

I think https://review.openstack.org/427842 is doing what you intend,
I can see the entire set of notes by walking the stable release pages
now.

dt

-- 

Dean Troyer
dtro...@gmail.com

__
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] [neutron] [release] misleading release notes

[Doug Hellmann]

Excerpts from Dean Troyer's message of 2017-02-01 22:41:46 -0600:
> On Wed, Feb 1, 2017 at 8:13 PM, Armando M.  wrote:
> > I suspect what happens is that someone revises the content at a later date
> > and reno associated the last timestamp of the release note with release
> > where the change has been made?
> 
> I do believe this is the case, reno puts a note in the release that it
> find it in, thus editing notes after branching is going to give you
> the result you so not want.
> 
> I've made a point to do one last relnote cleanup pass before releases
> to catch the errors/typos that have slipped through, but OSC doesn't
> have near the volume of commits or notes that many projects have...
> 
> dt
> 

As long as the edit happens on the branch where the note should appear,
it should be fine.

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] [neutron] [release] misleading release notes

[Doug Hellmann]

Excerpts from Armando M.'s message of 2017-02-01 18:13:46 -0800:
> Hi,
> 
> There is something puzzling about release notes. I don't see 8.0.0 [1], and
> it looks like features released in Mitaka are being advertised as Newton
> features [2]. For instance, [3] 'Agent availability zones' shows as a
> Newton feature when I am pretty positive that it went in Mitaka [4].
> 
> I suspect what happens is that someone revises the content at a later date
> and reno associated the last timestamp of the release note with release
> where the change has been made?
> 
> I don't see other projects' release notes broken this way so we must be
> doing something wrong. It would be good to have guidance from the release
> team.
> 
> Thanks,
> Armando
> 
> [1] http://docs.openstack.org/releasenotes/neutron/mitaka.html
> [2] http://docs.openstack.org/releasenotes/neutron/newton.html#id5
> [3] http://docs.openstack.org/releasenotes/neutron/newton.html#id6
> [4] https://review.openstack.org/#/c/204436/

The Ironic team pointed out a similar issue yesterday, and I
discovered a bug in the logic in reno to determine when a release
series had started. That bug has led to early releases in a series
that happen before a branch is created not being visible, so that,
combined with the logic for collapsing notes from pre-release
versions into the final release, is why 8.0.0 is missing.

I have a patch up for review now to fix this bug
(https://review.openstack.org/427842).  Testing the patch locally
with neutron's release notes show 8.0.0 on the mitaka page, as
expected.

Editing release notes is an important requirement for reno, and I
think that part is working correctly.  Reno works by scanning the
history of a branch from tip to root. It uses the content of the
most recent version of a note file (closest to tip) but places the
note in the release where the file was originally added (closes to
root).

I could use some reviews on the patch above, but I'm reluctant to
ship a new version of reno while everyone is working on release
candidates this week. I'll plan for early next week, when breaking
the gate would be less disruptive.

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] [neutron] [release] misleading release notes

[Dean Troyer]

On Wed, Feb 1, 2017 at 8:13 PM, Armando M.  wrote:
> I suspect what happens is that someone revises the content at a later date
> and reno associated the last timestamp of the release note with release
> where the change has been made?

I do believe this is the case, reno puts a note in the release that it
find it in, thus editing notes after branching is going to give you
the result you so not want.

I've made a point to do one last relnote cleanup pass before releases
to catch the errors/typos that have slipped through, but OSC doesn't
have near the volume of commits or notes that many projects have...

dt

-- 

Dean Troyer
dtro...@gmail.com

__
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] [neutron] [release] misleading release notes

[Armando M.]

Hi,

There is something puzzling about release notes. I don't see 8.0.0 [1], and
it looks like features released in Mitaka are being advertised as Newton
features [2]. For instance, [3] 'Agent availability zones' shows as a
Newton feature when I am pretty positive that it went in Mitaka [4].

I suspect what happens is that someone revises the content at a later date
and reno associated the last timestamp of the release note with release
where the change has been made?

I don't see other projects' release notes broken this way so we must be
doing something wrong. It would be good to have guidance from the release
team.

Thanks,
Armando

[1] http://docs.openstack.org/releasenotes/neutron/mitaka.html
[2] http://docs.openstack.org/releasenotes/neutron/newton.html#id5
[3] http://docs.openstack.org/releasenotes/neutron/newton.html#id6
[4] https://review.openstack.org/#/c/204436/
__
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] [Neutron][Release] Changing release model for *-aas services

[Thierry Carrez]

Mark Voelker wrote:

On Jun 1, 2016, at 12:27 PM, Armando M.  wrote:
[...]
To the best of my knowledge none of the *-aas projects are part of defcore, and 
since [1] has no presence of vpn, fw, lb, nor planned, I thought I was on the 
safe side.


Thanks for checking.  You are correct: LBaaS, VPNaaS, and FWaaS capabilities 
are not present in existing Board-approved DefCore Guidelines, nor have they 
been proposed for the next one. [2]

[2] http://git.openstack.org/cgit/openstack/defcore/tree/next.json


Thanks for the quick check! So this is clear from a Defcore perspective. 
Let's continue discussing on the review, and sorry for the noise :)


--
Thierry Carrez (ttx)

__
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] [Neutron][Release] Changing release model for *-aas services

[Mark Voelker]

> On Jun 1, 2016, at 12:27 PM, Armando M.  wrote:
> 
> 
> 
> On 1 June 2016 at 02:28, Thierry Carrez  wrote:
> Armando M. wrote:
> Having looked at the recent commit volume that has been going into the
> *-aas repos, I am considering changing the release model for
> neutron-vpnaas, neutron-fwaas, neutron-lbaas
> from release:cycle-with-milestones [1] to
> release:cycle-with-intermediary [2]. This change will allow us to avoid
> publishing a release at fixed times when there's nothing worth releasing.
> 
> I commented on the review, but I think it's easier to discuss this here...
> 
> Beyond changing the release model, what you're proposing here is to remove 
> functionality from an existing deliverable ("neutron" which was a combination 
> of openstack/neutron and openstack/neutron-*aas, released together) and 
> making the *aas things separate deliverables.
> 
> All I wanted to do is change the release model of the *-aas projects, without 
> side effects. I appreciate that the governance structure doesn't seem to 
> allow this easily, and I am looking for guidance.
>   
> 
> From a Defcore perspective, the trademark programs include the "neutron" 
> deliverable. So the net effect for DefCore is that you remove functionality 
> -- and removing functionality from a Defcore-used project needs extra care 
> and heads-up time.
> 
> To the best of my knowledge none of the *-aas projects are part of defcore, 
> and since [1] has no presence of vpn, fw, lb, nor planned, I thought I was on 
> the safe side.
> 

Thanks for checking.  You are correct: LBaaS, VPNaaS, and FWaaS capabilities 
are not present in existing Board-approved DefCore Guidelines, nor have they 
been proposed for the next one. [2]

[2] http://git.openstack.org/cgit/openstack/defcore/tree/next.json

At Your Service,

Mark T. Voelker
DefCore Committee Co-Chair

> 
> It's probably fine to remove *-aas from the neutron deliverable if there is 
> no Defcore capability or designated section there (current or planned). 
> Otherwise we need to have a longer conversation that is likely to extend 
> beyond the release model deadline tomorrow.
> 
> I could not see one in [1]
>  
> [1] https://github.com/openstack/defcore/blob/master/2016.01.json 
> 
> 
> 
> -- 
> Thierry Carrez (ttx)
> 
> 
> __
> 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


__
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] [Neutron][Release] Changing release model for *-aas services

[Armando M.]

On 1 June 2016 at 02:28, Thierry Carrez  wrote:

> Armando M. wrote:
>
>> Having looked at the recent commit volume that has been going into the
>> *-aas repos, I am considering changing the release model for
>> neutron-vpnaas, neutron-fwaas, neutron-lbaas
>> from release:cycle-with-milestones [1] to
>> release:cycle-with-intermediary [2]. This change will allow us to avoid
>> publishing a release at fixed times when there's nothing worth releasing.
>>
>
> I commented on the review, but I think it's easier to discuss this here...
>
> Beyond changing the release model, what you're proposing here is to remove
> functionality from an existing deliverable ("neutron" which was a
> combination of openstack/neutron and openstack/neutron-*aas, released
> together) and making the *aas things separate deliverables.
>

All I wanted to do is change the release model of the *-aas projects,
without side effects. I appreciate that the governance structure doesn't
seem to allow this easily, and I am looking for guidance.


>
> From a Defcore perspective, the trademark programs include the "neutron"
> deliverable. So the net effect for DefCore is that you remove functionality
> -- and removing functionality from a Defcore-used project needs extra care
> and heads-up time.
>

To the best of my knowledge none of the *-aas projects are part of defcore,
and since [1] has no presence of vpn, fw, lb, nor planned, I thought I was
on the safe side.


> It's probably fine to remove *-aas from the neutron deliverable if there
> is no Defcore capability or designated section there (current or planned).
> Otherwise we need to have a longer conversation that is likely to extend
> beyond the release model deadline tomorrow.


I could not see one in [1]

[1] https://github.com/openstack/defcore/blob/master/2016.01.json


>
> --
> Thierry Carrez (ttx)
>
>
> __
> 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] [Neutron][Release] Changing release model for *-aas services

[Thierry Carrez]

Armando M. wrote:

Having looked at the recent commit volume that has been going into the
*-aas repos, I am considering changing the release model for
neutron-vpnaas, neutron-fwaas, neutron-lbaas
from release:cycle-with-milestones [1] to
release:cycle-with-intermediary [2]. This change will allow us to avoid
publishing a release at fixed times when there's nothing worth releasing.


I commented on the review, but I think it's easier to discuss this here...

Beyond changing the release model, what you're proposing here is to 
remove functionality from an existing deliverable ("neutron" which was a 
combination of openstack/neutron and openstack/neutron-*aas, released 
together) and making the *aas things separate deliverables.


From a Defcore perspective, the trademark programs include the 
"neutron" deliverable. So the net effect for DefCore is that you remove 
functionality -- and removing functionality from a Defcore-used project 
needs extra care and heads-up time.


It's probably fine to remove *-aas from the neutron deliverable if there 
is no Defcore capability or designated section there (current or 
planned). Otherwise we need to have a longer conversation that is likely 
to extend beyond the release model deadline tomorrow.


--
Thierry Carrez (ttx)

__
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] [Neutron][Release] Changing release model for *-aas services

[Doug Wiegley]

Agreed.

doug

> On May 31, 2016, at 12:12 PM, Armando M.  wrote:
> 
> Hi folks,
> 
> Having looked at the recent commit volume that has been going into the *-aas 
> repos, I am considering changing the release model for neutron-vpnaas, 
> neutron-fwaas, neutron-lbaas from release:cycle-with-milestones [1] to 
> release:cycle-with-intermediary [2]. This change will allow us to avoid 
> publishing a release at fixed times when there's nothing worth releasing.
> 
> I'll follow up with a governance change, as I know of the imminent deadline 
> [3].
> 
> Thoughts?
> Armando
> 
> [1] 
> https://governance.openstack.org/reference/tags/release_cycle-with-milestones.html
>  
> 
> [2] 
> https://governance.openstack.org/reference/tags/release_cycle-with-intermediary.html
>  
> 
> [3] http://lists.openstack.org/pipermail/openstack-dev/2016-May/095490.html 
> __
> 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] [Neutron][Release] Changing release model for *-aas services

[Ryan Moats]

"Armando M." <arma...@gmail.com> wrote on 05/31/2016 01:12:32 PM:

> From: "Armando M." <arma...@gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: 05/31/2016 01:13 PM
> Subject: [openstack-dev] [Neutron][Release] Changing release model
> for *-aas services
>
> Hi folks,
>
> Having looked at the recent commit volume that has been going into
> the *-aas repos, I am considering changing the release model for
> neutron-vpnaas, neutron-fwaas, neutron-lbaas from release:cycle-
> with-milestones [1] to release:cycle-with-intermediary [2]. This
> change will allow us to avoid publishing a release at fixed times
> when there's nothing worth releasing.
>
> I'll follow up with a governance change, as I know of the imminent
> deadline [3].
>
> Thoughts?
> Armando
>
> [1] https://governance.openstack.org/reference/tags/release_cycle-
> with-milestones.html
> [2] https://governance.openstack.org/reference/tags/release_cycle-
> with-intermediary.html
>
[3] http://lists.openstack.org/pipermail/openstack-dev/2016-May/095490.html

+1 to this as it makes a *LOT* of sense to me...

Ryan (regXboi)
__
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] [Neutron][Release] Changing release model for *-aas services

[Kyle Mestery]

On Tue, May 31, 2016 at 1:12 PM, Armando M.  wrote:
> Hi folks,
>
> Having looked at the recent commit volume that has been going into the *-aas
> repos, I am considering changing the release model for neutron-vpnaas,
> neutron-fwaas, neutron-lbaas from release:cycle-with-milestones [1] to
> release:cycle-with-intermediary [2]. This change will allow us to avoid
> publishing a release at fixed times when there's nothing worth releasing.
>
> I'll follow up with a governance change, as I know of the imminent deadline
> [3].
>
> Thoughts?
> Armando
>
+1, I've voted as such on the reivew as well [4].

[4] https://review.openstack.org/#/c/323522/

> [1]
> https://governance.openstack.org/reference/tags/release_cycle-with-milestones.html
> [2]
> https://governance.openstack.org/reference/tags/release_cycle-with-intermediary.html
> [3] http://lists.openstack.org/pipermail/openstack-dev/2016-May/095490.html
>
> __
> 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] [Neutron][Release] Changing release model for *-aas services

[Armando M.]

On 31 May 2016 at 11:17, Ihar Hrachyshka  wrote:

>
> > On 31 May 2016, at 20:12, Armando M.  wrote:
> >
> > Hi folks,
> >
> > Having looked at the recent commit volume that has been going into the
> *-aas repos, I am considering changing the release model for
> neutron-vpnaas, neutron-fwaas, neutron-lbaas from
> release:cycle-with-milestones [1] to release:cycle-with-intermediary [2].
> This change will allow us to avoid publishing a release at fixed times when
> there's nothing worth releasing.
>
> VPNaaS and FWaaS are the land of the dead these days. Even LBaaS is not
> that active.
>
> +1 for the change.
>

https://review.openstack.org/#/c/323522/


>
> Ihar
> __
> 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] [Neutron][Release] Changing release model for *-aas services

[Ihar Hrachyshka]

> On 31 May 2016, at 20:12, Armando M.  wrote:
> 
> Hi folks,
> 
> Having looked at the recent commit volume that has been going into the *-aas 
> repos, I am considering changing the release model for neutron-vpnaas, 
> neutron-fwaas, neutron-lbaas from release:cycle-with-milestones [1] to 
> release:cycle-with-intermediary [2]. This change will allow us to avoid 
> publishing a release at fixed times when there's nothing worth releasing.

VPNaaS and FWaaS are the land of the dead these days. Even LBaaS is not that 
active.

+1 for the change.

Ihar
__
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] [Neutron][Release] Changing release model for *-aas services

[Armando M.]

Hi folks,

Having looked at the recent commit volume that has been going into the
*-aas repos, I am considering changing the release model for
neutron-vpnaas, neutron-fwaas, neutron-lbaas
from release:cycle-with-milestones [1] to release:cycle-with-intermediary
[2]. This change will allow us to avoid publishing a release at fixed times
when there's nothing worth releasing.

I'll follow up with a governance change, as I know of the imminent deadline
[3].

Thoughts?
Armando

[1]
https://governance.openstack.org/reference/tags/release_cycle-with-milestones.html
[2]
https://governance.openstack.org/reference/tags/release_cycle-with-intermediary.html
[3] http://lists.openstack.org/pipermail/openstack-dev/2016-May/095490.html
__
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] [neutron][release] neutron *-aas release notes are not linked.

[Doug Hellmann]

Excerpts from Akihiro Motoki's message of 2016-04-20 13:20:40 +0900:
> Hi,
> 
> I noticed Mitaka release notes for neutron *-aas [1,2,3] are not
> referred to from anywhere.
> Neutron has four deliverables (neutron, lbaas, fwaas, vpnaas),
> but only the release note of the main neutron repo is linked.
> 
> Is the right solution to add links to the main neutron release notes?
> Another possible way is to allow multiple release note links in our
> deliverable YAML format,
> but the first one looks easier.
> 
> Thanks,
> Akihiro
> 
> [0] http://docs.openstack.org/releasenotes/neutron/
> [1] http://docs.openstack.org/releasenotes/neutron-lbaas/
> [2] http://docs.openstack.org/releasenotes/neutron-fwaas/
> [3] http://docs.openstack.org/releasenotes/neutron-vpnaas/
> 

This is an issue with the data model we have for the releases repo. I
only included support for one link, not thinking about projects like
Neutron with multi-part deliverables. We can fix this during Newton.

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] [neutron][release] neutron *-aas release notes are not linked.

[Armando M.]

On 20 April 2016 at 00:39, Andreas Jaeger  wrote:

> On 2016-04-20 06:20, Akihiro Motoki wrote:
> > Hi,
> >
> > I noticed Mitaka release notes for neutron *-aas [1,2,3] are not
> > referred to from anywhere.
> > Neutron has four deliverables (neutron, lbaas, fwaas, vpnaas),
> > but only the release note of the main neutron repo is linked.
> >
> > Is the right solution to add links to the main neutron release notes?
> > Another possible way is to allow multiple release note links in our
> > deliverable YAML format,
> > but the first one looks easier.
>
> They should be linked IMHO from
> http://releases.openstack.org/mitaka/index.html - but indeed they are not,
>

Not quite sure what's the best way to handle this, but this is an
inconsistency I found with [1], where entries must be explicitly added to
the networking section of [2].

[1] http://docs.openstack.org/developer/neutron/
[2] http://docs.openstack.org/developer/openstack-projects.html


> Andreas
>
> > Thanks,
> > Akihiro
> >
> > [0] http://docs.openstack.org/releasenotes/neutron/
> > [1] http://docs.openstack.org/releasenotes/neutron-lbaas/
> > [2] http://docs.openstack.org/releasenotes/neutron-fwaas/
> > [3] http://docs.openstack.org/releasenotes/neutron-vpnaas/
> >
> >
> __
> > 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
> >
>
>
> --
>  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] [neutron][release] neutron *-aas release notes are not linked.

[Andreas Jaeger]

On 2016-04-20 06:20, Akihiro Motoki wrote:
> Hi,
> 
> I noticed Mitaka release notes for neutron *-aas [1,2,3] are not
> referred to from anywhere.
> Neutron has four deliverables (neutron, lbaas, fwaas, vpnaas),
> but only the release note of the main neutron repo is linked.
> 
> Is the right solution to add links to the main neutron release notes?
> Another possible way is to allow multiple release note links in our
> deliverable YAML format,
> but the first one looks easier.

They should be linked IMHO from
http://releases.openstack.org/mitaka/index.html - but indeed they are not,

Andreas

> Thanks,
> Akihiro
> 
> [0] http://docs.openstack.org/releasenotes/neutron/
> [1] http://docs.openstack.org/releasenotes/neutron-lbaas/
> [2] http://docs.openstack.org/releasenotes/neutron-fwaas/
> [3] http://docs.openstack.org/releasenotes/neutron-vpnaas/
> 
> __
> 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
> 


-- 
 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-dev] [neutron][release] neutron *-aas release notes are not linked.

[Akihiro Motoki]

Hi,

I noticed Mitaka release notes for neutron *-aas [1,2,3] are not
referred to from anywhere.
Neutron has four deliverables (neutron, lbaas, fwaas, vpnaas),
but only the release note of the main neutron repo is linked.

Is the right solution to add links to the main neutron release notes?
Another possible way is to allow multiple release note links in our
deliverable YAML format,
but the first one looks easier.

Thanks,
Akihiro

[0] http://docs.openstack.org/releasenotes/neutron/
[1] http://docs.openstack.org/releasenotes/neutron-lbaas/
[2] http://docs.openstack.org/releasenotes/neutron-fwaas/
[3] http://docs.openstack.org/releasenotes/neutron-vpnaas/

__
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] [neutron][release] Releasing python-neutronclient 4.1.2?

[Miguel Angel Ajo Pelayo]

On Wed, Mar 9, 2016 at 4:16 PM, Doug Hellmann  wrote:

> Excerpts from Armando M.'s message of 2016-03-08 15:43:05 -0700:
> > On 8 March 2016 at 15:07, Doug Hellmann  wrote:
> >
> > > Excerpts from Armando M.'s message of 2016-03-08 12:49:16 -0700:
> > > > Hi folks,
> > > >
> > > > There's a feature or two that are pending to be delivered in Mitaka
> > > [1,2],
> > > > and those involve changes to both the server and client sides.
> Ideally
> > > we'd
> > > > merge both sides in time for Mitaka RC and that implies that we
> would be
> > > > able to release a new version of the client including changes [3,4].
> This
> > > > is especially important since a new client release would be
> beneficial to
> > > > improving test coverage as needed by [5].
> > > >
> > > > Considering what we released already, and what the tip of master is
> for
> > > the
> > > > client [6], I can't see any side effect that a new neutronclient
> release
> > > > may introduce.
> > > >
> > > > Having said that, I am leaning towards the all-or-none approach, but
> the
> > > > 'all' approach is predicated on the fact that we are indeed allowed
> to
> > > > release a new client and touch the global requirements.
> > > >
> > > > What's the release team's recommendation? Based on it, we may want to
> > > > decide to defer these to as soon as N master opens up.
> > >
> > > I'm a bit reluctant to start touching the requirements lists for
> > > feature work. We do have some bug fixes in the pipeline that will
> > > require library releases, but those are for bugs not new features.
> > > We also have one or two libs where feature work needed to be extended,
> > > but none of those have dependencies outside of the project producing
> > > them.
> > >
> > > The main reason to require a client release is for some *other* project
> > > to take advantage of the new feature work. Is that planned?
> > >
> >
> > Thanks for the prompt reply. Neutron would be the only consumer of these
> > additions, and no other project has pending work to leverage these
> > capabilities.
>
> In that case, I don't think we want to make an exception. Although
> Neutron is the only user of this feature, I counted more than 50 other
> projects that have python-neutronclient in a requirements file, and
> that's a lot of potential for impact with a new release.
>
> It seems like the options are to wait for Newton to land both parts of
> the feature, or to land the server side during Mitaka and release a
> feature update to the client as soon as Newton development opens.
>
> Doug
>

Yes, if anyone want's more detail, we discussed that in the
qos-meeting today [1], thank you Doug, for joining us.

I would like to ask for the inclusion of the server side, regardless
of the client bits. Fullstack would have to stay out, but I believe
the api-tests, unit tests, and functional tests included in the patch
will maintain the feature stability.

Users would have the chance to make use of the feature via direct
API calls without the client, or by bumping to neutronclient 4.2.x when
that's available. Distros would be able to backport the neutronclient
patch at their will.

I ask for it, not only for the sake of the feature, which I believe is not
critical, but because Comcast and other related contributors have been
patient enough (5-6 cycles?), learned and collaborated the U/S way to
get this finally in while helping with L2 agent extensibility and other
technical debt in the way. And because, the earlier the feature gets
used, the early we could iron out any possible bug features come with.


Best regards,
Miguel Ángel.

[1]
http://eavesdrop.openstack.org/meetings/neutron_qos/2016/neutron_qos.2016-03-09-14.03.log.html
 (around 15:37)


>
> >
> > >
> > > Doug
> > >
> > > >
> > > > Many thanks,
> > > > Armando
> > > >
> > > > [1] https://review.openstack.org/#/q/topic:bug/1468353
> > > > [2] https://review.openstack.org/#/q/topic:bug/1521783
> > > > [3] https://review.openstack.org/#/c/254280/
> > > > [4] https://review.openstack.org/#/c/288187/
> > > > [5] https://review.openstack.org/#/c/288392/
> > > > [6]
> > > >
> > >
> https://github.com/openstack/python-neutronclient/commit/8460b0dbb354a304a112be13c63cb933ebe1927a
> > >
> > >
> __
> > > 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
>
__
OpenStack Development Mailing List (not for usage 

Re: [openstack-dev] [neutron][release] Releasing python-neutronclient 4.1.2?

[Doug Hellmann]

Excerpts from Armando M.'s message of 2016-03-08 15:43:05 -0700:
> On 8 March 2016 at 15:07, Doug Hellmann  wrote:
> 
> > Excerpts from Armando M.'s message of 2016-03-08 12:49:16 -0700:
> > > Hi folks,
> > >
> > > There's a feature or two that are pending to be delivered in Mitaka
> > [1,2],
> > > and those involve changes to both the server and client sides. Ideally
> > we'd
> > > merge both sides in time for Mitaka RC and that implies that we would be
> > > able to release a new version of the client including changes [3,4]. This
> > > is especially important since a new client release would be beneficial to
> > > improving test coverage as needed by [5].
> > >
> > > Considering what we released already, and what the tip of master is for
> > the
> > > client [6], I can't see any side effect that a new neutronclient release
> > > may introduce.
> > >
> > > Having said that, I am leaning towards the all-or-none approach, but the
> > > 'all' approach is predicated on the fact that we are indeed allowed to
> > > release a new client and touch the global requirements.
> > >
> > > What's the release team's recommendation? Based on it, we may want to
> > > decide to defer these to as soon as N master opens up.
> >
> > I'm a bit reluctant to start touching the requirements lists for
> > feature work. We do have some bug fixes in the pipeline that will
> > require library releases, but those are for bugs not new features.
> > We also have one or two libs where feature work needed to be extended,
> > but none of those have dependencies outside of the project producing
> > them.
> >
> > The main reason to require a client release is for some *other* project
> > to take advantage of the new feature work. Is that planned?
> >
> 
> Thanks for the prompt reply. Neutron would be the only consumer of these
> additions, and no other project has pending work to leverage these
> capabilities.

In that case, I don't think we want to make an exception. Although
Neutron is the only user of this feature, I counted more than 50 other
projects that have python-neutronclient in a requirements file, and
that's a lot of potential for impact with a new release.

It seems like the options are to wait for Newton to land both parts of
the feature, or to land the server side during Mitaka and release a
feature update to the client as soon as Newton development opens.

Doug

> 
> >
> > Doug
> >
> > >
> > > Many thanks,
> > > Armando
> > >
> > > [1] https://review.openstack.org/#/q/topic:bug/1468353
> > > [2] https://review.openstack.org/#/q/topic:bug/1521783
> > > [3] https://review.openstack.org/#/c/254280/
> > > [4] https://review.openstack.org/#/c/288187/
> > > [5] https://review.openstack.org/#/c/288392/
> > > [6]
> > >
> > https://github.com/openstack/python-neutronclient/commit/8460b0dbb354a304a112be13c63cb933ebe1927a
> >
> > __
> > 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] [neutron][release] Releasing python-neutronclient 4.1.2?

[Akihiro Motoki]

2016-03-09 7:43 GMT+09:00 Armando M. :
>
>
> On 8 March 2016 at 15:07, Doug Hellmann  wrote:
>>
>> Excerpts from Armando M.'s message of 2016-03-08 12:49:16 -0700:
>> > Hi folks,
>> >
>> > There's a feature or two that are pending to be delivered in Mitaka
>> > [1,2],
>> > and those involve changes to both the server and client sides. Ideally
>> > we'd
>> > merge both sides in time for Mitaka RC and that implies that we would be
>> > able to release a new version of the client including changes [3,4].
>> > This
>> > is especially important since a new client release would be beneficial
>> > to
>> > improving test coverage as needed by [5].
>> >
>> > Considering what we released already, and what the tip of master is for
>> > the
>> > client [6], I can't see any side effect that a new neutronclient release
>> > may introduce.
>> >
>> > Having said that, I am leaning towards the all-or-none approach, but the
>> > 'all' approach is predicated on the fact that we are indeed allowed to
>> > release a new client and touch the global requirements.
>> >
>> > What's the release team's recommendation? Based on it, we may want to
>> > decide to defer these to as soon as N master opens up.
>>
>> I'm a bit reluctant to start touching the requirements lists for
>> feature work. We do have some bug fixes in the pipeline that will
>> require library releases, but those are for bugs not new features.
>> We also have one or two libs where feature work needed to be extended,
>> but none of those have dependencies outside of the project producing
>> them.
>>
>> The main reason to require a client release is for some *other* project
>> to take advantage of the new feature work. Is that planned?
>
>
> Thanks for the prompt reply. Neutron would be the only consumer of these
> additions, and no other project has pending work to leverage these
> capabilities.

The situations are:
* neutron itself works with the current version of neutronclient
  except that new features merged in RC1 phases are not used via neutronclient.
* neutron fullstack test requires a new release of neutron client.

There is no need to update global-requirements.txt. neutronclient >=
2.6.0 is enough
to make full features of neutron work.

What we need is to have a new release of neutronclient in
upper-constraints.txt for neutron testing.
Can we update upper-constraints.txt only?

If we have a new release of neutronclient, the version would be not
4.1.2 but 4.2.0.
It has new features added to Neutron in RC1 phase.

Akihiro

>
>>
>>
>> Doug
>>
>> >
>> > Many thanks,
>> > Armando
>> >
>> > [1] https://review.openstack.org/#/q/topic:bug/1468353
>> > [2] https://review.openstack.org/#/q/topic:bug/1521783
>> > [3] https://review.openstack.org/#/c/254280/
>> > [4] https://review.openstack.org/#/c/288187/
>> > [5] https://review.openstack.org/#/c/288392/
>> > [6]
>> >
>> > https://github.com/openstack/python-neutronclient/commit/8460b0dbb354a304a112be13c63cb933ebe1927a
>>
>> __
>> 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
>

__
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] [neutron][release] Releasing python-neutronclient 4.1.2?

[Armando M.]

On 8 March 2016 at 15:07, Doug Hellmann  wrote:

> Excerpts from Armando M.'s message of 2016-03-08 12:49:16 -0700:
> > Hi folks,
> >
> > There's a feature or two that are pending to be delivered in Mitaka
> [1,2],
> > and those involve changes to both the server and client sides. Ideally
> we'd
> > merge both sides in time for Mitaka RC and that implies that we would be
> > able to release a new version of the client including changes [3,4]. This
> > is especially important since a new client release would be beneficial to
> > improving test coverage as needed by [5].
> >
> > Considering what we released already, and what the tip of master is for
> the
> > client [6], I can't see any side effect that a new neutronclient release
> > may introduce.
> >
> > Having said that, I am leaning towards the all-or-none approach, but the
> > 'all' approach is predicated on the fact that we are indeed allowed to
> > release a new client and touch the global requirements.
> >
> > What's the release team's recommendation? Based on it, we may want to
> > decide to defer these to as soon as N master opens up.
>
> I'm a bit reluctant to start touching the requirements lists for
> feature work. We do have some bug fixes in the pipeline that will
> require library releases, but those are for bugs not new features.
> We also have one or two libs where feature work needed to be extended,
> but none of those have dependencies outside of the project producing
> them.
>
> The main reason to require a client release is for some *other* project
> to take advantage of the new feature work. Is that planned?
>

Thanks for the prompt reply. Neutron would be the only consumer of these
additions, and no other project has pending work to leverage these
capabilities.


>
> Doug
>
> >
> > Many thanks,
> > Armando
> >
> > [1] https://review.openstack.org/#/q/topic:bug/1468353
> > [2] https://review.openstack.org/#/q/topic:bug/1521783
> > [3] https://review.openstack.org/#/c/254280/
> > [4] https://review.openstack.org/#/c/288187/
> > [5] https://review.openstack.org/#/c/288392/
> > [6]
> >
> https://github.com/openstack/python-neutronclient/commit/8460b0dbb354a304a112be13c63cb933ebe1927a
>
> __
> 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] [neutron][release] Releasing python-neutronclient 4.1.2?

[Doug Hellmann]

Excerpts from Armando M.'s message of 2016-03-08 12:49:16 -0700:
> Hi folks,
> 
> There's a feature or two that are pending to be delivered in Mitaka [1,2],
> and those involve changes to both the server and client sides. Ideally we'd
> merge both sides in time for Mitaka RC and that implies that we would be
> able to release a new version of the client including changes [3,4]. This
> is especially important since a new client release would be beneficial to
> improving test coverage as needed by [5].
> 
> Considering what we released already, and what the tip of master is for the
> client [6], I can't see any side effect that a new neutronclient release
> may introduce.
> 
> Having said that, I am leaning towards the all-or-none approach, but the
> 'all' approach is predicated on the fact that we are indeed allowed to
> release a new client and touch the global requirements.
> 
> What's the release team's recommendation? Based on it, we may want to
> decide to defer these to as soon as N master opens up.

I'm a bit reluctant to start touching the requirements lists for
feature work. We do have some bug fixes in the pipeline that will
require library releases, but those are for bugs not new features.
We also have one or two libs where feature work needed to be extended,
but none of those have dependencies outside of the project producing
them.

The main reason to require a client release is for some *other* project
to take advantage of the new feature work. Is that planned?

Doug

> 
> Many thanks,
> Armando
> 
> [1] https://review.openstack.org/#/q/topic:bug/1468353
> [2] https://review.openstack.org/#/q/topic:bug/1521783
> [3] https://review.openstack.org/#/c/254280/
> [4] https://review.openstack.org/#/c/288187/
> [5] https://review.openstack.org/#/c/288392/
> [6]
> https://github.com/openstack/python-neutronclient/commit/8460b0dbb354a304a112be13c63cb933ebe1927a

__
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] [neutron][release] Releasing python-neutronclient 4.1.2?

[Armando M.]

Hi folks,

There's a feature or two that are pending to be delivered in Mitaka [1,2],
and those involve changes to both the server and client sides. Ideally we'd
merge both sides in time for Mitaka RC and that implies that we would be
able to release a new version of the client including changes [3,4]. This
is especially important since a new client release would be beneficial to
improving test coverage as needed by [5].

Considering what we released already, and what the tip of master is for the
client [6], I can't see any side effect that a new neutronclient release
may introduce.

Having said that, I am leaning towards the all-or-none approach, but the
'all' approach is predicated on the fact that we are indeed allowed to
release a new client and touch the global requirements.

What's the release team's recommendation? Based on it, we may want to
decide to defer these to as soon as N master opens up.

Many thanks,
Armando

[1] https://review.openstack.org/#/q/topic:bug/1468353
[2] https://review.openstack.org/#/q/topic:bug/1521783
[3] https://review.openstack.org/#/c/254280/
[4] https://review.openstack.org/#/c/288187/
[5] https://review.openstack.org/#/c/288392/
[6]
https://github.com/openstack/python-neutronclient/commit/8460b0dbb354a304a112be13c63cb933ebe1927a
__
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] [neutron] Release Notes for *aaS projects

[Ihar Hrachyshka]

Kyle Mestery  wrote:


We're hoping to cut Neutron M-1 this week [1]. We have implemented
release notes in the main Neutron repository [2] , but not in the *aaS
repositories. At the time, I thought this was a good approach and we
could collect all releasenotes there. But I think it makes sense to
have releasenotes in the *aaS repositories as well.

What I'm going to propose is we cut Neutron M-1 as-is now, with any
*aaS releasenotes done in the main repository. Once Neutron M-1 is
cut, I'll add the releasenotes stuff into the *aaS repositories, and
we can start using releasenotes independently in those repositories.

If anyone has issues with this approach please reply on this thread.


I believe that is the best way to do it. Otherwise we would need to push  
multiple patches for the same change: one into *aas, and another one into  
neutron tree just for release notes. It defeats the whole usefulness of  
being able to enforce release notes requirements as part of the patches  
making the actual changes. We all know ‘I will follow up’ often means ‘I  
won’t do it, ever’.


Ihar

__
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] [neutron] Release Notes for *aaS projects

[Martin Hickey]

+1

Regards,
Martin




From:   Kyle Mestery <mest...@mestery.com>
To: openstack-dev@lists.openstack.org
Date:   02/12/2015 16:40
Subject:    [openstack-dev] [neutron] Release Notes for *aaS projects



We're hoping to cut Neutron M-1 this week [1]. We have implemented
release notes in the main Neutron repository [2] , but not in the *aaS
repositories. At the time, I thought this was a good approach and we
could collect all releasenotes there. But I think it makes sense to
have releasenotes in the *aaS repositories as well.

What I'm going to propose is we cut Neutron M-1 as-is now, with any
*aaS releasenotes done in the main repository. Once Neutron M-1 is
cut, I'll add the releasenotes stuff into the *aaS repositories, and
we can start using releasenotes independently in those repositories.

If anyone has issues with this approach please reply on this thread.

Thanks!
Kyle

[1] https://review.openstack.org/#/c/251959/
[2] https://review.openstack.org/241758

__
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] [neutron] Release Notes for *aaS projects

[Doug Wiegley]

I’m in favor of things living in the repo where their code lives. The fewer 
dependencies the better. Especially if we stop adding them. So, I agree.

doug


> On Dec 2, 2015, at 9:38 AM, Kyle Mestery  wrote:
> 
> We're hoping to cut Neutron M-1 this week [1]. We have implemented
> release notes in the main Neutron repository [2] , but not in the *aaS
> repositories. At the time, I thought this was a good approach and we
> could collect all releasenotes there. But I think it makes sense to
> have releasenotes in the *aaS repositories as well.
> 
> What I'm going to propose is we cut Neutron M-1 as-is now, with any
> *aaS releasenotes done in the main repository. Once Neutron M-1 is
> cut, I'll add the releasenotes stuff into the *aaS repositories, and
> we can start using releasenotes independently in those repositories.
> 
> If anyone has issues with this approach please reply on this thread.
> 
> Thanks!
> Kyle
> 
> [1] https://review.openstack.org/#/c/251959/
> [2] https://review.openstack.org/241758
> 
> __
> 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] [neutron] Release Notes for *aaS projects

[Brandon Logan]

Makes complete sense.

On Wed, 2015-12-02 at 10:38 -0600, Kyle Mestery wrote:
> We're hoping to cut Neutron M-1 this week [1]. We have implemented
> release notes in the main Neutron repository [2] , but not in the *aaS
> repositories. At the time, I thought this was a good approach and we
> could collect all releasenotes there. But I think it makes sense to
> have releasenotes in the *aaS repositories as well.
> 
> What I'm going to propose is we cut Neutron M-1 as-is now, with any
> *aaS releasenotes done in the main repository. Once Neutron M-1 is
> cut, I'll add the releasenotes stuff into the *aaS repositories, and
> we can start using releasenotes independently in those repositories.
> 
> If anyone has issues with this approach please reply on this thread.
> 
> Thanks!
> Kyle
> 
> [1] https://review.openstack.org/#/c/251959/
> [2] https://review.openstack.org/241758
> 
> __
> 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] [neutron] Release Notes for *aaS projects

[Kyle Mestery]

OK, thanks for the input. I'll get the patches out to enable this by Friday
this week, once Mitaka-1 is cut for Neutron.

On Wed, Dec 2, 2015 at 11:34 AM, Brandon Logan 
wrote:

> Makes complete sense.
>
> On Wed, 2015-12-02 at 10:38 -0600, Kyle Mestery wrote:
> > We're hoping to cut Neutron M-1 this week [1]. We have implemented
> > release notes in the main Neutron repository [2] , but not in the *aaS
> > repositories. At the time, I thought this was a good approach and we
> > could collect all releasenotes there. But I think it makes sense to
> > have releasenotes in the *aaS repositories as well.
> >
> > What I'm going to propose is we cut Neutron M-1 as-is now, with any
> > *aaS releasenotes done in the main repository. Once Neutron M-1 is
> > cut, I'll add the releasenotes stuff into the *aaS repositories, and
> > we can start using releasenotes independently in those repositories.
> >
> > If anyone has issues with this approach please reply on this thread.
> >
> > Thanks!
> > Kyle
> >
> > [1] https://review.openstack.org/#/c/251959/
> > [2] https://review.openstack.org/241758
> >
> >
> __
> > 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
>
__
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] [Neutron] Release of a neutron sub-project

[Kyle Mestery]

On Tue, Sep 29, 2015 at 8:04 PM, Kyle Mestery  wrote:

> On Tue, Sep 29, 2015 at 2:36 PM, Vadivel Poonathan <
> vadivel.openst...@gmail.com> wrote:
>
>> Hi,
>>
>> As per the Sub-Project Release process - i would like to tag and release
>> the following sub-project as part of upcoming Liberty release.
>> The process says talk to one of the member of 'neutron-release' group. I
>> couldn’t find a group mail-id for this group. Hence I am sending this email
>> to the dev list.
>>
>> I just have removed the version from setup.cfg and got the patch merged,
>> as specified in the release process. Can someone from the neutron-release
>> group makes this sub-project release.
>>
>>
>
> Vlad, I'll do this tomorrow. Find me on IRC (mestery) and ping me there so
> I can get your IRC NIC in case I have questions.
>
>
It turns out that the networking-ale-omniswitch pypi setup isn't correct,
see [1] for more info and how to correct. This turned out to be ok, because
it's forced me to re-examine the other networking sub-projects and their
pypi setup to ensure consistency, which the thread found here [1] will
resolve.

Once you resolve this ping me on IRC and I'll release this for you.

Thanks!
Kyle

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/075880.html


> Thanks!
> Kyle
>
>
>>
>> ALE Omniswitch
>> Git: https://git.openstack.org/cgit/openstack/networking-ale-omniswitch
>> Launchpad: https://launchpad.net/networking-ale-omniswitch
>> Pypi: https://pypi.python.org/pypi/networking-ale-omniswitch
>>
>> Thanks,
>> Vad
>> --
>>
>> __
>> 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] [Neutron] Release of a neutron sub-project

[Vadivel Poonathan]

Kyle,

We referenced arista's setup/config files when we setup the pypi for
our plugin. So if it is ok for Arista, then it would be ok for
ale-omniswitch too, i believe. You said Arista was ok when you did in
google, instead of pypi search, in another email. So can you pls.
check again ale-omniswitch as well and confirm.

If still it has an issue, can you pls. throw me some pointers on where
to enable the openstackci owener permission?..

Thanks,Vad--

The following pypi registrations did not follow directions to enable
openstackci has "Owner" permissions, which allow for the publishing of

packages to pypi:

networking-ale-omniswitch
networking-arista


On Wed, Sep 30, 2015 at 11:56 AM, Kyle Mestery  wrote:

> On Tue, Sep 29, 2015 at 8:04 PM, Kyle Mestery  wrote:
>
>> On Tue, Sep 29, 2015 at 2:36 PM, Vadivel Poonathan <
>> vadivel.openst...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> As per the Sub-Project Release process - i would like to tag and release
>>> the following sub-project as part of upcoming Liberty release.
>>> The process says talk to one of the member of 'neutron-release' group. I
>>> couldn’t find a group mail-id for this group. Hence I am sending this email
>>> to the dev list.
>>>
>>> I just have removed the version from setup.cfg and got the patch merged,
>>> as specified in the release process. Can someone from the neutron-release
>>> group makes this sub-project release.
>>>
>>>
>>
>> Vlad, I'll do this tomorrow. Find me on IRC (mestery) and ping me there
>> so I can get your IRC NIC in case I have questions.
>>
>>
> It turns out that the networking-ale-omniswitch pypi setup isn't correct,
> see [1] for more info and how to correct. This turned out to be ok, because
> it's forced me to re-examine the other networking sub-projects and their
> pypi setup to ensure consistency, which the thread found here [1] will
> resolve.
>
> Once you resolve this ping me on IRC and I'll release this for you.
>
> Thanks!
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/075880.html
>
>
>> Thanks!
>> Kyle
>>
>>
>>>
>>> ALE Omniswitch
>>> Git: https://git.openstack.org/cgit/openstack/networking-ale-omniswitch
>>> Launchpad: https://launchpad.net/networking-ale-omniswitch
>>> Pypi: https://pypi.python.org/pypi/networking-ale-omniswitch
>>>
>>> Thanks,
>>> Vad
>>> --
>>>
>>>
>>> __
>>> 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
>
>
__
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] [Neutron] Release of a neutron sub-project

[Davanum Srinivas]

Vad,

You can look up the group in gerrit:
https://review.openstack.org/#/admin/groups/150,members

-- Dims

On Tue, Sep 29, 2015 at 3:36 PM, Vadivel Poonathan <
vadivel.openst...@gmail.com> wrote:

> Hi,
>
> As per the Sub-Project Release process - i would like to tag and release
> the following sub-project as part of upcoming Liberty release.
> The process says talk to one of the member of 'neutron-release' group. I
> couldn’t find a group mail-id for this group. Hence I am sending this email
> to the dev list.
>
> I just have removed the version from setup.cfg and got the patch merged,
> as specified in the release process. Can someone from the neutron-release
> group makes this sub-project release.
>
>
> ALE Omniswitch
> Git: https://git.openstack.org/cgit/openstack/networking-ale-omniswitch
> Launchpad: https://launchpad.net/networking-ale-omniswitch
> Pypi: https://pypi.python.org/pypi/networking-ale-omniswitch
>
> Thanks,
> Vad
> --
>
> __
> 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
>
>


-- 
Davanum Srinivas :: https://twitter.com/dims
__
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] [Neutron] Release of a neutron sub-project

[Kyle Mestery]

On Tue, Sep 29, 2015 at 2:36 PM, Vadivel Poonathan <
vadivel.openst...@gmail.com> wrote:

> Hi,
>
> As per the Sub-Project Release process - i would like to tag and release
> the following sub-project as part of upcoming Liberty release.
> The process says talk to one of the member of 'neutron-release' group. I
> couldn’t find a group mail-id for this group. Hence I am sending this email
> to the dev list.
>
> I just have removed the version from setup.cfg and got the patch merged,
> as specified in the release process. Can someone from the neutron-release
> group makes this sub-project release.
>
>

Vlad, I'll do this tomorrow. Find me on IRC (mestery) and ping me there so
I can get your IRC NIC in case I have questions.

Thanks!
Kyle


>
> ALE Omniswitch
> Git: https://git.openstack.org/cgit/openstack/networking-ale-omniswitch
> Launchpad: https://launchpad.net/networking-ale-omniswitch
> Pypi: https://pypi.python.org/pypi/networking-ale-omniswitch
>
> Thanks,
> Vad
> --
>
> __
> 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

[openstack-dev] [Neutron] Release of a neutron sub-project

[Vadivel Poonathan]

Hi,

As per the Sub-Project Release process - i would like to tag and release
the following sub-project as part of upcoming Liberty release.
The process says talk to one of the member of 'neutron-release' group. I
couldn’t find a group mail-id for this group. Hence I am sending this email
to the dev list.

I just have removed the version from setup.cfg and got the patch merged, as
specified in the release process. Can someone from the neutron-release
group makes this sub-project release.


ALE Omniswitch
Git: https://git.openstack.org/cgit/openstack/networking-ale-omniswitch
Launchpad: https://launchpad.net/networking-ale-omniswitch
Pypi: https://pypi.python.org/pypi/networking-ale-omniswitch

Thanks,
Vad
--
__
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] [Neutron] Release Notes for Icehouse

[Yaguang Tang]

Hi all,

I think it's important for our developers to publish an official Release
Note as other core openstack projects does at the end of Icehouse
development cycle, it contains the new features added and upgrade issue to
be noticed by the users. any one like to be volunteer to help accomplish it?
https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse

-- 
Tang Yaguang

Canonical Ltd. | www.ubuntu.com | www.canonical.com
Mobile:  +86 152 1094 6968
gpg key: 0x187F664F
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Release Notes for Icehouse

[Mark McClain]

On Apr 4, 2014, at 11:03 AM, Yaguang Tang 
yaguang.t...@canonical.commailto:yaguang.t...@canonical.com wrote:

I think it's important for our developers to publish an official Release Note 
as other core openstack projects does at the end of Icehouse development cycle, 
it contains the new features added and upgrade issue to be noticed by the 
users. any one like to be volunteer to help accomplish it?
https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse

I’ve typically waited until after we publish the second RC to add release notes 
to the Wiki. I’ll update the release notes for Neutron when we close out RC2.

mark

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev