[openstack-dev] [Neutron] Stepping down from core

[Henry Gessau]

I've already communicated this in the neutron meeting and in some neutron
policy patches, but yesterday the PTL actually updated the gerrit ACLs so I
thought I'd drop a note here too.

My work situation has changed and leaves me little time to keep up with my
duties as core reviewer, DB lieutenant, and drivers team member.

Working with the diverse and very talented contributors to Neutron has been
the best experience of my career (which started before many of you were born).
Thank you all for making the team such a great community. Because of you the
project is thriving and will continue to be successful!

I will still be around on IRC, contribute some small patches here and there,
and generally try to keep abreast of Neutron's progress. Don't hesitate to
ping me.

__
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] NeutronLibImpact: Adoption of db *_FIELD_SIZE constants from neutron-lib

[Henry Gessau]

Gary Kotton  wrote:
> Would it be worth considering have the three patches:
> https://review.openstack.org/399891, https://review.openstack.org/398113
> and  https://review.openstack.org/398489 based one on top of the other.
> Then all sub projects could take the top of the commit and base on top of
> that. That may make the process a little more efficient.

The problem is that the ExtensionDescriptor change has its own specific order
in which the patches must be done, as explained in
http://lists.openstack.org/pipermail/openstack-dev/2016-November/108005.html

My recommendation is that ExtensionDescriptor be done first. Then we could
stage the PLURALS and _FIELD_SIZES as you suggest, but the PLURALS change is
quite independent, so it could be done in parallel with ExtensionDescriptor.

Once ExtensionDescriptor, PLURALS and _FIELD_SIZES are done, then we will be
in a position to remove attributes.py from core neutron. That is the aim of
this little dance.

> Thanks
> Gary
>  
>
> 
> 
> On 11/26/16, 9:03 AM, "Henry Gessau"  wrote:
> 
> The following _MAX_LEN constants are being removed from
> neutron/api/v2/attributes.py in [1]. The corresponding DB field size
> constants from neutron_lib.db.constants should be used instead.
> 
> All subproject maintainers should update their code to use the
> the db *_FIELD_SIZE constants from neutron-lib.
> 
> I have submitted patches [2] for most subprojects.
> 
>  NAME_MAX_LEN  -->  NAME_FIELD_SIZE
>  TENANT_ID_MAX_LEN -->  PROJECT_ID_FIELD_SIZE
>  DESCRIPTION_MAX_LEN   -->  DESCRIPTION_FIELD_SIZE
>  LONG_DESCRIPTION_MAX_LEN  -->  LONG_DESCRIPTION_FIELD_SIZE
>  DEVICE_ID_MAX_LEN -->  DEVICE_ID_FIELD_SIZE
>  DEVICE_OWNER_MAX_LEN  -->  DEVICE_NAME_FIELD_SIZE
> 
> In alembic migration scripts, the raw numerical value shall be used.
> 
> For more information, see [3].
> 
> [1] https://review.openstack.org/399891
> [2] https://review.openstack.org/#/q/status:open+topic:use-db-field-sizes
> [3] 
> http://lists.openstack.org/pipermail/openstack-dev/2016-October/105789.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
> 


__
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] NeutronLibImpact: Removing deprecated model_base mixins from core

[Henry Gessau]

The deprecated model_base mixins are be being removed from
neutron/db/model_base.py and neutron/db/models_v2.py in [1].
The mixins from neutron_lib.db.model_base should be used instead.

All subproject maintainers should update their code to use the model_base
mixins from neutron-lib.

I have submitted patches [2] for the stragglers that I found.

[1] https://review.openstack.org/403329
[2] https://review.openstack.org/#/q/status:open+topic:use-lib-model_base

__
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] NeutronLibImpact: Adoption of db *_FIELD_SIZE constants from neutron-lib

[Henry Gessau]

The following _MAX_LEN constants are being removed from
neutron/api/v2/attributes.py in [1]. The corresponding DB field size
constants from neutron_lib.db.constants should be used instead.

All subproject maintainers should update their code to use the
the db *_FIELD_SIZE constants from neutron-lib.

I have submitted patches [2] for most subprojects.

 NAME_MAX_LEN  -->  NAME_FIELD_SIZE
 TENANT_ID_MAX_LEN -->  PROJECT_ID_FIELD_SIZE
 DESCRIPTION_MAX_LEN   -->  DESCRIPTION_FIELD_SIZE
 LONG_DESCRIPTION_MAX_LEN  -->  LONG_DESCRIPTION_FIELD_SIZE
 DEVICE_ID_MAX_LEN -->  DEVICE_ID_FIELD_SIZE
 DEVICE_OWNER_MAX_LEN  -->  DEVICE_NAME_FIELD_SIZE

In alembic migration scripts, the raw numerical value shall be used.

For more information, see [3].

[1] https://review.openstack.org/399891
[2] https://review.openstack.org/#/q/status:open+topic:use-db-field-sizes
[3] http://lists.openstack.org/pipermail/openstack-dev/2016-October/105789.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-dev] [neutron] NeutronLibImpact: Adoption of ExtensionDescriptor from neutron-lib

[Henry Gessau]

The ExtensionDescriptor class has been rehomed to neutron-lib and is being
removed from neutron core, see [1].

All subproject maintainers should update their code to use the
ExtensionDescriptor class from neutron-lib.

I have submitted patches [2] for most subprojects.

This will be highlighted in the next Neutron team meeting [3].


[1] https://review.openstack.org/398113
[2] https://review.openstack.org/#/q/status:open+topic:ExtensionDescriptor
[3] https://wiki.openstack.org/wiki/Network/Meetings

__
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] NeutronLibImpact: Removal of PLURALS

[Henry Gessau]

The PLURALS dict in neutron.api.v2.attributes is written to but never used.
Before rehoming neutron.api.v2.attributes to neutron-lib I am removing all
references to PLURALS [1].

All subproject maintainers should remove the use of PLURALS from their code.
I have submitted patches [2] for most subprojects.

This will be highlighted in the next Neutron team meeting [3].


[1] https://review.openstack.org/398489
[2] https://review.openstack.org/#/q/status:open+topic:remove-PLURALS
[3] https://wiki.openstack.org/wiki/Network/Meetings

__
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] Reviews needed in neutron-lib

[Henry Gessau]

During the meeting today I promised to provide a list of reviews in
neutron-lib that need review attention.

The following are patches that "rehome" code from neutron core into
neutron-lib and are therefore important to keep up the velocity of neutron-lib
adoption:

https://review.openstack.org/385045
https://review.openstack.org/391354
https://review.openstack.org/387612
https://review.openstack.org/396972
https://review.openstack.org/394244
https://review.openstack.org/397035
https://review.openstack.org/346554

(Also look for patches in neutron core that remove deprecations, or that adopt
code from neutron-lib.)


Finally, do not neglect the api-ref fixes/updates in neutron-lib, most of
these are very easy to review...

https://review.openstack.org/#/q/project:openstack/neutron-lib+status:open+file:%22%255Eapi-ref/.*%22


__
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] Weekly neutron-lib meeting canceled

[Henry Gessau]

See https://review.openstack.org/395034

We now have a slot in the main neutron project meeting.

If we do need extra meeting time for neutron-lib we can set up something based
on who wants to attend and when.

__
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] Barcelona summit neutron-lib session recap

[Henry Gessau]

Ocata neutron-lib session recap
---

tl;dr:
 - Speed up moving common code into neutron-lib
 - Sub-project maintainers must keep up and should contribute

The session consisted of announcing the goals around speeding up the
neutron-lib work so that consuming projects can remove their dependency on
core neutron. No objections to the speed-up were raised during the session.

Updates to policies:
1) No more debtcollector deprecations on neutron core changes when adopting
neutron-lib code (unless it affects projects beyond those that integrate with
neutron). See below for details.
2) Provide unit test base classes and utils in neutron-lib (reverses previous
decision).
3) Spend more effort on rehoming code from neutron, less on tweaking what
is already in lib.
4) All stadium REST APIs must go in the api-ref.

The above will be detailed in the devref[1], but here is a summary:


1. No more deprecations

When a new version of neutron-lib is released the new features should be
adopted immediately by all consuming projects. One month after the release,
code will be removed from neutron core if it is available in neutron-lib.
**NOTE** This will break sub-projects that are not keeping up.
(No one at the session objected to this.)
As part of this effort we are requiring release notes in neutron-lib patches
that impact consuming projects.

2. Unit test framework

Base classes and utility functions will be provided. Some minor refactoring
for cleaner code-reuse will be needed. Base test classes for ml2 will also be
provided.

3. Rehome first, tweak later

Let's de-prioritize the tweaking of code already in neutron-lib until after
all the stadium projects have stopped importing neutron core.

3b. Shed technical debt

Rehoming ugly code will give us a ugly library. Some existing neutron code
needs to be refactored before being made available in neutron-lib.

4. Complete api-ref

All REST API extensions from stadium sub-projects must be documented in the
api-ref. The api definitions must also be added.
The existing api-ref update work will continue. We encourage developers to
look for discrepancies and propose fixes.



The following items were not addressed:
 - Not enough core reviewer attention in neutron-lib.
 - Config options in neutron-lib. There is an email thread[2] about this.


[1] https://review.openstack.org/331338
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-October/106369.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] neutron-lib

[Henry Gessau]

Gary Kotton  wrote:
> Would it be possible to cut a new version of neutron-lib. This will enable us
> to proceed with the integration into the various projects?

https://review.openstack.org/392009


__
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] Next neutron-lib meeting is November 9

[Henry Gessau]

Due to the summit.

__
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] Database field sizes and attribute "MAX_LEN" constants

[Henry Gessau]

Anna Taraday  wrote:
> Henry, thanks for taking care of this!
> 
> In my opinion, it is just safe to use raw values in migration, because
> migration is a strict point in time.
> 
> I remember how many patches I send in havana in Neutron for fixing
> synchronization issues. Usage constants everywhere can be good in this case,
> but ModelMigrationSyc did such check of this for us already.
> 
> If we want to have constants everywhere, we should guarantee that they are
> unchanged - have test in neutron-lib which verifies their values. 

Yes, we could have some tests, although a patch changing a constant would
probably also have a change to the test. :) We might need to also have a
prominent "Warning! Do not change this test!" comment for each test.

> 
> 
> On Sat, Oct 15, 2016 at 10:41 PM Henry Gessau  <mailto:hen...@gessau.net>> wrote:
> 
> Hi neutrinos,
> 
> In Neutron many attributes are stored in database fields. The size of 
> these
> fields therefore determines the maximum length of the attribute values.
> 
> I would like to get some consistency in place around how we define the
> constants and where they are used. Here are my thoughts...
> 
> 
> 1. Raw sizes in alembic migrations
> 
> In the alembic migrations which build the DB schema, we should use the raw
> number value of the field size.
> 
> 2. FOO_FIELD_SIZE in the sqlalchemy models
> 
> In the sqlalchemy models, we should use the _FIELD_SIZE constants
> defined in neutron_lib/db/constants.py
> 
> 3. Everywhere else, use FOO_FIELD_SIZE, or another constant (like 
> FOO_MAX_LEN)
> based on FOO_FIELD_SIZE.
> 
> 
> "Why raw numbers in alembic migrations?", you may ask. Well, we have tests
> that verify that the models match the schema generated by migrations. If 
> both
> the models and the migrations use the constants then the tests would not
> detect if a patch changes the constant value.
> 
> By using raw numbers in migrations, together with our rule of not allowing
> changes to existing migrations, we allow the tests to detect and fail on 
> any
> attempt to alter a FIELD_SIZE constant.
> 
> Let me know if this makes sense or if you think it's a terrible idea.
> 
> If there are no objections, I intend to submit a patch or patches to:
>  - replace constants with numbers in existing migrations
>  - ensure all models use the appropriate constants
> 
> Existing code uses FOO_MAX_LEN in a lot of places. In most of these 
> places it
> would make sense to simply switch to using FOO_FIELD_SIZE. However, some 
> code
> may be quite far removed from the DB and would look better by sticking to
> FOO_MAX_LEN. I added item 3. above to allow for that.


__
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] Database field sizes and attribute "MAX_LEN" constants

[Henry Gessau]

Ihar Hrachyshka  wrote:
> Henry Gessau  wrote:
> 
>> Hi neutrinos,
>>
>> In Neutron many attributes are stored in database fields. The size of these
>> fields therefore determines the maximum length of the attribute values.
>>
>> I would like to get some consistency in place around how we define the
>> constants and where they are used. Here are my thoughts...
>>
>>
>> 1. Raw sizes in alembic migrations
>>
>> In the alembic migrations which build the DB schema, we should use the raw
>> number value of the field size.
>>
>> 2. FOO_FIELD_SIZE in the sqlalchemy models
>>
>> In the sqlalchemy models, we should use the _FIELD_SIZE constants
>> defined in neutron_lib/db/constants.py
>>
>> 3. Everywhere else, use FOO_FIELD_SIZE, or another constant (like  
>> FOO_MAX_LEN)
>> based on FOO_FIELD_SIZE.
>>
>>
>> "Why raw numbers in alembic migrations?", you may ask. Well, we have tests
>> that verify that the models match the schema generated by migrations. If  
>> both
>> the models and the migrations use the constants then the tests would not
>> detect if a patch changes the constant value.
>>
>> By using raw numbers in migrations, together with our rule of not allowing
>> changes to existing migrations, we allow the tests to detect and fail on  
>> any
>> attempt to alter a FIELD_SIZE constant.
>>
>> Let me know if this makes sense or if you think it's a terrible idea.
> 
> Not sure. I mean, if you envision that a ‘constant’ value maintained in  
> neutron-lib may be changed in the future, then it’s not safe to use it  
> anywhere, both in models and alembic scripts.
> 
> But I believe those lib constants are supposed to be unchanged, and  
> reviewers of the library should understand that; in which case we should be  
> safe to use them in alembic scripts too.
> 
> Is it that we don’t trust neutron-lib core reviewers to follow the rule?

OK, I suppose using *_FIELD_SIZE constants from neutron-lib in the alembic
scripts is safe enough.

I began thinking about this problem before I added field sizes to neutron-lib,
and it was not a matter of trust. It was more about having a mechanism to
detect a problem if someone tries to change, say, FILE_NAME_MAX_LEN from 16 to
80 without realizing it is related to a DB field. That's a hypothetical
example, but we have many constants and I did not want to count on humans to
detect every impacting case.


__
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] Database field sizes and attribute "MAX_LEN" constants

[Henry Gessau]

Hi neutrinos,

In Neutron many attributes are stored in database fields. The size of these
fields therefore determines the maximum length of the attribute values.

I would like to get some consistency in place around how we define the
constants and where they are used. Here are my thoughts...


1. Raw sizes in alembic migrations

In the alembic migrations which build the DB schema, we should use the raw
number value of the field size.

2. FOO_FIELD_SIZE in the sqlalchemy models

In the sqlalchemy models, we should use the _FIELD_SIZE constants
defined in neutron_lib/db/constants.py

3. Everywhere else, use FOO_FIELD_SIZE, or another constant (like FOO_MAX_LEN)
based on FOO_FIELD_SIZE.


"Why raw numbers in alembic migrations?", you may ask. Well, we have tests
that verify that the models match the schema generated by migrations. If both
the models and the migrations use the constants then the tests would not
detect if a patch changes the constant value.

By using raw numbers in migrations, together with our rule of not allowing
changes to existing migrations, we allow the tests to detect and fail on any
attempt to alter a FIELD_SIZE constant.

Let me know if this makes sense or if you think it's a terrible idea.

If there are no objections, I intend to submit a patch or patches to:
 - replace constants with numbers in existing migrations
 - ensure all models use the appropriate constants

Existing code uses FOO_MAX_LEN in a lot of places. In most of these places it
would make sense to simply switch to using FOO_FIELD_SIZE. However, some code
may be quite far removed from the DB and would look better by sticking to
FOO_MAX_LEN. I added item 3. above to allow for that.


__
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] Neutron team social event in Barcelona

[Henry Gessau]

Thanks for organizing this Miguel!
I plan to attend.

Miguel Lavalle  wrote:
> Dear Neutrinos,
> 
> I am organizing a social event for the team on Thursday 27th at 19:30. After
> doing some Google research, I am proposing Raco de la Vila, which is located
> in Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here:
> http://www.racodelavila.com/en/carta-racodelavila.htm
> 
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under
> 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get a
> final count.
> 
> Here's some reviews:
> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
> 
> Cheers
> 
> 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

Re: [openstack-dev] [oslo.db] [release] opportunistic tests breaking randomly

[Henry Gessau]

Sean Dague  wrote:
> On 09/15/2016 09:20 AM, Roman Podoliaka wrote:
>> Sean,
>>
>> So currently we have a default timeout of 160s in Nova. And
>> specifically for migration tests we set a scaling factor of 2. Let's
>> maybe give 2.5 or 3 a try ( https://review.openstack.org/#/c/370805/ )
>> and make a couple of "rechecks" to see if it helps or not.
> 
> Given the fail rate, lets just go safe and double it to 4. If it's
> really a timeout issue that should move the bell curve to mostly cover
> it. Timeouts are really just supposed to be a backstop to ensure the
> tests don't deadlock forever.
> 
> The incidence rate is at that odd race rate that we'll probably have to
> merge and just see if it goes away.

Neutron also started seeing timeouts in DB migration tests today.
We're going to try a similar timeout scaling factor for these tests.


__
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] Adding ihrachys to the neutron-drivers team

[Henry Gessau]

+1000!

Armando M.  wrote:
> Hi folks,
> 
> I would like to propose Ihar to become a member of the Neutron drivers team 
> [1].
> 
> Ihar wide knowledge of the Neutron codebase, and his longstanding duties as
> stable core, downstream package whisperer, release and oslo liaison (I am sure
> I am forgetting some other capacity he is in) is going to put him at great
> comfort in the newly appointed role, and help him grow and become wise even
> further.
> 
> Even though we have not been meeting regularly lately we will resume our
> Thursday meetings soon [2], and having Ihar onboard by then will be highly
> beneficial. 
> 
> Please, join me in welcome Ihar to the team.
> 
> Cheers,
> Armando 
> 
> [1] 
> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
> 
> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
> 


__
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] neutronclient check queue is broken

[Henry Gessau]

Akihiro Motoki  wrote:
> In the neutronclient check queue,
> gate-neutronclient-test-dsvm-functional is broken now [1].
> Please avoid issuing 'recheck'.
> 
> [1] https://bugs.launchpad.net/python-neutronclient/+bug/1616749

The fix [2] has merged. Carry on.

[2] https://review.openstack.org/360291


__
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] [OpenStack-docs] [neutron] [api] [doc] API reference for neutron stadium projects (re: API status report)

[Henry Gessau]

Akihiro Motoki  wrote:
> this mail focuses on neutron-specific topics. I dropped cinder and ironic 
> tags.
> 
> 2016-08-11 23:52 GMT+09:00 Anne Gentle :
>>
>>
>> On Wed, Aug 10, 2016 at 2:49 PM, Anne Gentle 
>> wrote:
>>>
>>> Hi all,
>>> I wanted to report on status and answer any questions you all have about
>>> the API reference and guide publishing process.
>>>
>>> The expectation is that we provide all OpenStack API information on
>>> developer.openstack.org. In order to meet that goal, it's simplest for now
>>> to have all projects use the RST+YAML+openstackdocstheme+os-api-ref
>>> extension tooling so that users see available OpenStack APIs in a sidebar
>>> navigation drop-down list.
>>>
>>> --Migration--
>>> The current status for migration is that all WADL content is migrated
>>> except for trove. There is a patch in progress and I'm in contact with the
>>> team to assist in any way. https://review.openstack.org/#/c/316381/
>>>
>>> --Theme, extension, release requirements--
>>> The current status for the theme, navigation, and Sphinx extension tooling
>>> is contained in the latest post from Graham proposing a solution for the
>>> release number switchover and offers to help teams as needed:
>>> http://lists.openstack.org/pipermail/openstack-dev/2016-August/101112.html I
>>> hope to meet the requirements deadline to get those changes landed.
>>> Requirements freeze is Aug 29.
>>>
>>> --Project coverage--
>>> The current status for project coverage is that these projects are now
>>> using the RST+YAML in-tree workflow and tools and publishing to
>>> http://developer.openstack.org/api-ref/ so they will be
>>> included in the upcoming API navigation sidebar intended to span all
>>> OpenStack APIs:
>>>
>>> designate http://developer.openstack.org/api-ref/dns/
>>> glance http://developer.openstack.org/api-ref/image/
>>> heat http://developer.openstack.org/api-ref/orchestration/
>>> ironic http://developer.openstack.org/api-ref/baremetal/
>>> keystone http://developer.openstack.org/api-ref/identity/
>>> manila http://developer.openstack.org/api-ref/shared-file-systems/
>>> neutron-lib http://developer.openstack.org/api-ref/networking/
>>> nova http://developer.openstack.org/api-ref/compute/
>>> sahara http://developer.openstack.org/api-ref/data-processing/
>>> senlin http://developer.openstack.org/api-ref/clustering/
>>> swift http://developer.openstack.org/api-ref/object-storage/
>>> zaqar http://developer.openstack.org/api-ref/messaging/
>>>
>>> These projects are using the in-tree workflow and common tools, but do not
>>> have a publish job in project-config in the jenkins/jobs/projects.yaml file.
>>>
>>> ceilometer
>>
>>
>> Sorry, in reviewing further today I found another project that does not have
>> a publish job but has in-tree source files:
>>
>> cinder
>>
>> Team cinder: can you let me know where you are in your publishing comfort
>> level? Please add an api-ref-jobs: line with a target of block-storage to
>> jenkins/jobs/projects.yaml in the project-config repo to ensure publishing
>> is correct.
>>
>> Another issue is the name of the target directory for the final URL. Team
>> ironic can I change your api-ref-jobs: line to bare-metal instead of
>> baremetal? It'll be better for search engines and for alignment with the
>> other projects URLs: https://review.openstack.org/354135
>>
>> I've also uncovered a problem where a neutron project's API does not have an
>> official service name, and am working on a solution but need help from the
>> neutron team: https://review.openstack.org/#/c/351407
> 
> I followed the discussion in https://review.openstack.org/#/c/351407
> and my understanding of the conclusion is to add API reference source
> of neutron stadium projects
> to neutron-lib and publish them under
> http://developer.openstack.org/api-ref/networking/ .
> I sounds reasonable to me.
> 
> We can have a dedicated pages for each stadium project like networking-sfc
> like api-ref/networking/service-function-chaining.
> At now all APIs are placed under v2/ directory, but it is not good
> both from user and
> maintenance perspectives.
> 
> 
> So, the next thing we need to clarify is what names and directory
> structure are appropropriate
> from the documentation perspective.
> My proposal is to prepare a dedicated directory per networking project
> repository.
> The directory name should be a function name rather than a project
> name. For example,
> - neutron => ???
> - neutron-lbaas => load-balancer
> - neutron-vpnaas => vpn
> - neutron-fwaas => firewall
> - neutron-dynamic-routing => dynamic-routing
> - networking-sfc => service-function-chaining
> - networking-l2gw => layer2-gateway
> - (networking-bgpvpn) => bgp-vpn
> 
> My remaining open questions are:
> 
> - Is 'v2' directory needed?
>   All networking API provided by stadium projects are extensions to
> Networking v2 API and "v2" is the only API we have now.
>   Do we place all APIs from stadium projects under 'v2' directory, or
> is 'v

Re: [openstack-dev] [Neutron] Team and Driver meetings for the week of Aug 15th

[Henry Gessau]

Armando M.  wrote:
> Hi Neutrinos,
> 
> The meetings will be cancelled due to the mid-cycle.

The neutron-lib meeting will also skip next week.


__
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] Be prepared for bumps in the road -- tenant_id columns have been renamed to project_id

[Henry Gessau]

Hello neutrinos and especially maintainers of consuming projects.

The patch [1] to rename all tenant_id columns to project_id in the Neutron DB
has merged. Although we have tried our best to check for dependencies and side
effects, this is a very fundamental change and there may be consequences we
did not predict.

Most consuming subprojects have been pre-emptively updated to absorb the
change, while others will need to adjust reactively. See [2].

Note that sqlalchemy models can still access the tenant_id property as a
synonym for project_id, but in the database schema the column name is
project_id in all tables that have it.

If you encounter a problem due to this change, please reach out to us. Reply
here or use the #openstack-neutron IRC channel.

[1] https://review.openstack.org/335786
[2] https://etherpad.openstack.org/p/neutron-stadium-tenant2project

__
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][db][models]

[Henry Gessau]

Ihar Hrachyshka  wrote:
> Manjeet S  wrote:
> 
>> Hello Team,
>>
>> I have a question regarding centralizing all db models in neutron. As you  
>> all know
>> Oslo versioned object work is under progress and I also had a ticket  
>> opened for refactoring
>> Db models. (https://bugs.launchpad.net/neutron/+bug/1597913). There are  
>> three way I can do this,
>> 1, move all models to db/models_v2.py 2, create a new dir db/models/ and  
>> move whatever models are giving issue
>> Of cyclic import to db_models.py under db/models/ tree but all in same  
>> file, 3rd is move into different files under
>> Same tree db/models. I liked second way better, please let me know which  
>> one according to experienced developers
>> is better, I’ll do that way.
> 
> I don’t think 2. is the best way forward because it still keeps all models  
> in a single file with no classification. I prefer we split models by topic,  
> so option 3.
> 
> I took the approach for security groups here:  
> https://review.openstack.org/#/c/284738/49/neutron/db/models/securitygroup.py

I also prefer this organization (option 3).


__
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] no neutron-lib meeting today

[Henry Gessau]

Myself and dougwig will be unable to attend today.
We'll resume as usual next week.

__
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] how to create initial db migration script to sub-project

[Henry Gessau]

Moshe Levi  wrote:
> Hi Henry,
> 
> Thank for the reply. 
> 
> I tried to do the following with your commit [2]:

Note I just updated my patch for a minor problem.

> 1. I create models.py in networking_mlnx/db.

Nit: I would recommend creating all model under networking_mlnx/db/models/.

> 2. mysql -e "drop database neutron; create database neutron;"
> 3. neutron-db-manage --subproject=neutron  upgrade heads

You should upgrade all heads here (leave out the --subproject option).

> 4. neutron-db-manage --subproject=networking-mlnx  revision -m "test" --expend

Hopefully you spelled it correctly: --expand. :)

> 
> Now I don't see the errors as before, but the migration script that was 
> generated 
> Looks like [3] and doesn't contain the new table.

Yes, I can reproduce this problem. We need to set up a head.py file that
includes all mlnx models. I need to remember how to correctly set up this
inclusion and I will get back to you.

> 
> Am I doing it wrong?  
> 
> [3] - 
> from alembic import op
> import sqlalchemy as sa
> 
> 
> # revision identifiers, used by Alembic.
> revision = 'cbb661581082'
> down_revision = '65b6db113427b9_initial_contract'
> 
> 
> def upgrade():
> pass
> 
> -Original Message-
> From: Henry Gessau [mailto:hen...@gessau.net] 
> Sent: Sunday, July 24, 2016 9:21 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: Re: [openstack-dev] [neutron] how to create initial db migration 
> script to sub-project
> 
> Hi Moshe,
> 
> It has been a while since a neutron sub-project initialized new alembic 
> migrations, so the devref is out of date, sorry. Let me help you get this 
> sorted out and then I can update the devref with the latest info.
> 
> First you need to create the initial migration for each branch (expand and 
> contract). This is done by submitting a patch -- the contents of which used 
> to be crafted by copying a similar patch from another sub-project. The 
> patches to copy from are now out of date, so I have created a patch [2] for 
> you and we can use this as the new "template patch for initial alembic 
> migrations."
> 
> Some more comments inline ...
> 
> Moshe Levi  wrote:
>> Hi,
>>
>> I am trying to create initial db for the networking-mlnx project. 
>> I am following this neutron alembic documentation [1].
>> I added a entrypoint to networking-mlnx setup.cfg 
>> neutron.db.alembic_migrations =
>> networking-mlnx = networking_mlnx.db.migration:alembic_migrations
>> I added model.py file to networking-mlnx/networking_mlnx/db
>> And I run python setup.py develop to regenerate the entrypoint
>>
>> I am running the following commands:
>> 1. mysql -e "drop database neutron; create database neutron;"
>> 2. neutron-db-manage --subproject=neutron  upgrade heads
> 
> So far so good.
> 
>> 3. neutron-db-manage --subproject=networking-mlnx  revision -m "test" 
>> --autogenerate
> 
> Because we now require split (expand and contract) branches, you must now 
> specify --expand or --contract *instead of* --autogenerate. I will update the 
> devref about this.
> 
>> I am getting the following errors:
>> INFO  [alembic.runtime.migration] Context impl MySQLImpl.
>>
>> INFO  [alembic.runtime.migration] Will assume non-transactional DDL. 
>>
>> INFO  [alembic.autogenerate.compare] Detected removed table 
>> u'alembic_version'  
>> INFO  [alembic.autogenerate.compare] Detected removed index 
>> 'idx_autoinc_vr_id' on 'ha_router_vrid_allocations' 
>>   Generating 
>> /.autodirect/mtrswgwork/moshele/openstack/networking-mlnx/networking_mlnx/db/migration/alembic_migrations/versions/120e7e350bb1_test.py
>>  ... done
>>   OK 
>>  
>>
>> Traceback (most recent call last):   
>>  
>>
>>   File "/usr/bin/neutron-db-manage", line 10, in 
>>  
>>
>> sys.exit(main()) 
>>  
>>

Re: [openstack-dev] [neutron] how to create initial db migration script to sub-project

[Henry Gessau]

Hi Moshe,

It has been a while since a neutron sub-project initialized new alembic
migrations, so the devref is out of date, sorry. Let me help you get this
sorted out and then I can update the devref with the latest info.

First you need to create the initial migration for each branch (expand and
contract). This is done by submitting a patch -- the contents of which used to
be crafted by copying a similar patch from another sub-project. The patches to
copy from are now out of date, so I have created a patch [2] for you and we
can use this as the new "template patch for initial alembic migrations."

Some more comments inline ...

Moshe Levi  wrote:
> Hi,
> 
> I am trying to create initial db for the networking-mlnx project. 
> I am following this neutron alembic documentation [1].
> I added a entrypoint to networking-mlnx setup.cfg
> neutron.db.alembic_migrations =
> networking-mlnx = networking_mlnx.db.migration:alembic_migrations
> I added model.py file to networking-mlnx/networking_mlnx/db
> And I run python setup.py develop to regenerate the entrypoint 
> 
> I am running the following commands:
> 1. mysql -e "drop database neutron; create database neutron;"
> 2. neutron-db-manage --subproject=neutron  upgrade heads

So far so good.

> 3. neutron-db-manage --subproject=networking-mlnx  revision -m "test" 
> --autogenerate

Because we now require split (expand and contract) branches, you must now
specify --expand or --contract *instead of* --autogenerate. I will update the
devref about this.

> I am getting the following errors:
> INFO  [alembic.runtime.migration] Context impl MySQLImpl. 
>   
> INFO  [alembic.runtime.migration] Will assume non-transactional DDL.  
>   
> INFO  [alembic.autogenerate.compare] Detected removed table 
> u'alembic_version'  
> INFO  [alembic.autogenerate.compare] Detected removed index 
> 'idx_autoinc_vr_id' on 'ha_router_vrid_allocations' 
>   Generating 
> /.autodirect/mtrswgwork/moshele/openstack/networking-mlnx/networking_mlnx/db/migration/alembic_migrations/versions/120e7e350bb1_test.py
>  ... done
>   OK  
>   
>  
> Traceback (most recent call last):
>   
>  
>   File "/usr/bin/neutron-db-manage", line 10, in  
>   
>  
> sys.exit(main())  
>   
>  
>   File 
> "/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
>  line 689, in main
> return_val |= bool(CONF.command.func(config, CONF.command.name))  
>   
>  
>   File 
> "/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
>  line 275, in do_revision 
> update_head_files(config) 
>   
>  
>   File 
> "/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
>  line 398, in update_head_files   
> f.write(head_map[CONTRACT_BRANCH] + '\n') 
>   
>  
> KeyError: 'contract'
> 
> 
> And the migration script just dropping unrelated tables 

This should be fixed by env.py in [2].

> [moshele@r-dcs84 networking-mlnx]$ cat 
> /.autodirect/mtrswgwork/moshele/openstack/networking-mlnx/networking_mlnx/db/migration/alembic_migrations/versions/120e7e350bb1_test.py
> # revision identifiers, used by Alembic.
> revision = '120e7e350bb1'
> down_revision = None
> 
> from alembic import op
> import sqlalchemy as sa
> from sqlalchemy.dialects import mysql
> 
> def upgrade():
> ### commands auto generated by Alembic - please adjust! ###
> op.drop_table('alembic_version')
> op.drop_index('idx_autoinc_vr_id', 
> table_name='ha_router_vrid_allocations')
> ### end Alembic commands ###
> 
> 
> 
> It seem that the neutron alembic migration documentation [1] is out of date
> ( I don't see the --core_plugin flag in the neutron-db-manage man, but I do
> see the --subproject flag)
> 
> Does anyone know how to make it works? 

Yes, --core_plugin is defunct and I will remove it from the devref.

If you rebase on top of my patch [2] and run the revision command with
--expand y

Re: [openstack-dev] [Neutron] Proposing Jakub Libosvar for testing core

[Henry Gessau]

Big +1 from me.

Assaf Muller  wrote:
> As Neutron's so called testing lieutenant I would like to propose
> Jakub Libosvar to be a core in the testing area.
> 
> Jakub has demonstrated his inherent interest in the testing area over
> the last few years, his reviews are consistently insightful and his
> numbers [1] are in line with others and I know will improve if given
> the responsibilities of a core reviewer. Jakub is deeply involved with
> the project's testing infrastructures and CI systems.
> 
> As a reminder the expectation from cores is found here [2], and
> specifically for cores interesting in helping out shaping Neutron's
> testing story:
> 
> * Guide community members to craft a testing strategy for features [3]
> * Ensure Neutron's testing infrastructures are sufficiently
> sophisticated to achieve the above.
> * Provide leadership when determining testing Do's & Don'ts [4]. What
> makes for an effective test?
> * Ensure the gate stays consistently green
> 
> And more tactically we're looking at finishing the Tempest/Neutron
> tests dedup [5] and to provide visual graphing for historical control
> and data plane performance results similar to [6].
> 
> [1] http://stackalytics.com/report/contribution/neutron/90
> [2] http://docs.openstack.org/developer/neutron/policies/neutron-teams.html
> [3] 
> http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron
> [4] https://assafmuller.com/2015/05/17/testing-lightning-talk/
> [5] https://etherpad.openstack.org/p/neutron-tempest-defork
> [6] https://www.youtube.com/watch?v=a0qlsH1hoKs&feature=youtu.be&t=24m22s



__
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] Keystone V3 alignment: renaming tenant_id columns to project_id

[Henry Gessau]

Henry Gessau  wrote:
> In accordance with the Blueprint [1] and the spec [2], we are in the process
> of deprecating the use of the term 'tenant' in favor of 'project'.
> 
> The code change [3] with the biggest impact on Neutron developers is currently
> out for review and will merge quite soon (shortly after N-2). This change
> renames all 'tenant_id' columns in the database to 'project_id'.
> 
> If you have any changes in flight that touch a tenant_id field, you will be
> affected. Please familiarize yourself with [3], rebase on it, and comply with
> the changes.
> 
> One patch known to be affected is [4].
> 
> The column rename change has been designed to have minimal impact on the usage
> of 'tenant_id' fields. For now 'tenant_id' is still available as a
> key/property in resource dicts and objects, and as an attribute in request
> contexts.
> 
> In the long run (Ocata or beyond) we want to end up with no usages of the term
> 'tenant', except in the API for backwards compatibility. Existing usages of
> 'tenant' in the codebase will be converted to 'project' on a case-by-case
> basis. Although the conversion has not yet commenced, any *new* fields,
> arguments, variables, etc. with 'tenant' in the name will no longer be 
> accepted.
> 
> [1] https://blueprints.launchpad.net/neutron/+spec/keystone-v3
> [2]
> http://specs.openstack.org/openstack/neutron-specs/specs/newton/moving-to-keystone-v3.html
> [3] https://review.openstack.org/335786
> [4] https://review.openstack.org/244680

This work also affects repos that integrate with neutron and have tables in
the Neutron database. We have started to submit patches for the neutron-fwaas,
-lbaas, and -vpnaas repos, and we are keeping track of the progress with an
etherpad [5].

I have listed all the Neutron Stadium projects there, as well as all the
projects that I could find hosted on git.openstack.org that integrate with the
Neutron DB. Please help by signing up for a project.

If you encounter any problem or issues, please ask us for help. Either reply
to this email thread, or find me (HenryG) or Darek (dasm) in the Neutron IRC
channel.

[5] https://etherpad.openstack.org/p/neutron-stadium-tenant2project


__
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] Keystone V3 alignment: renaming tenant_id columns to project_id

[Henry Gessau]

In accordance with the Blueprint [1] and the spec [2], we are in the process
of deprecating the use of the term 'tenant' in favor of 'project'.

The code change [3] with the biggest impact on Neutron developers is currently
out for review and will merge quite soon (shortly after N-2). This change
renames all 'tenant_id' columns in the database to 'project_id'.

If you have any changes in flight that touch a tenant_id field, you will be
affected. Please familiarize yourself with [3], rebase on it, and comply with
the changes.

One patch known to be affected is [4].

The column rename change has been designed to have minimal impact on the usage
of 'tenant_id' fields. For now 'tenant_id' is still available as a
key/property in resource dicts and objects, and as an attribute in request
contexts.

In the long run (Ocata or beyond) we want to end up with no usages of the term
'tenant', except in the API for backwards compatibility. Existing usages of
'tenant' in the codebase will be converted to 'project' on a case-by-case
basis. Although the conversion has not yet commenced, any *new* fields,
arguments, variables, etc. with 'tenant' in the name will no longer be accepted.

[1] https://blueprints.launchpad.net/neutron/+spec/keystone-v3
[2]
http://specs.openstack.org/openstack/neutron-specs/specs/newton/moving-to-keystone-v3.html
[3] https://review.openstack.org/335786
[4] https://review.openstack.org/244680


__
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] New Python35 Jobs coming

[Henry Gessau]

Clark Boylan  wrote:
> The infra team is working on taking advantage of the new Ubuntu Xenial
> release including running unittests on python35. The current plan is to
> get https://review.openstack.org/#/c/336272/ merged next Tuesday (July
> 5, 2016). This will add non voting python35 tests restricted to >=
> master/Newton on all projects that had python34 testing.
> 
> The expectation is that in many cases python35 tests will just work if
> python34 testing was also working. If this is the case for your project
> you can propose a change to openstack-infra/project-config to make these
> jobs voting against your project. You should only need to edit
> jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the '-nv'
> portion of the python35 jobs to do this.
> 
> We do however expect that there will be a large group of failed tests
> too. If your project has a specific tox.ini py34 target to restrict
> python3 testing to a specific list of tests you will need to add a tox
> target for py35 that does the same thing as the py34 target. We have
> also seen bug reports against some projects whose tests rely on stable
> error messages from Python itself which isn't always the case across
> version changes so these tests will need to be updated as well.
> 
> Note this change will not add python35 jobs for cases where projects
> have special tox targets. This is restricted just to the default py35
> unittesting.
> 
> As always let us know if you questions,
> Clark

How soon can projects replace py34 with py35?

I tried py35 for neutron locally, and it ran without errors.


__
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] neutron-lib and dependencies in neutron reference implementation

[Henry Gessau]

One of the goals of neutron-lib is to reduce the chances of a code change in
neutron core breaking other repos. We want to get to a point where no repo
imports anything from neutron core.

So if there is some value shared between neutron core and one or more other
repos, then the value should go in neutron-lib.

Your question seems to be around "neutron reference implementation", but I
don't think that is relevant to what goes into neutron-lib.

You could argue that the values in neutron_lib/constants.py are big mix of
unrelated items, and that we may want to divide them up into separate
_constants.py modules. But then I could argue that would proliferate the
number of imports required for many repos.

Gal Sagie  wrote:
> For example references to the various different agents which are an
> implementation details to me
> 
> On Wed, Jun 8, 2016 at 8:51 PM, Henry Gessau  <mailto:hen...@gessau.net>> wrote:
> 
> Gal Sagie mailto:gal.sa...@gmail.com>> wrote:
> > Hello all,
> >
> > I have recently came across some missing constants in neutron-lib and 
> sent
> > a patch but i wanted to try and understand the scope of the lib.
> >
> > I see that the Neutron lib consist of many definitions which are 
> actually
> > part of the reference implementation and are not really "generic" 
> Neutron
> > parts.
> 
> Can you give specific examples of 'not really generic' constants?
> 
> > I am wondering if this is the right approach, especially since i think 
> an
> > end goal is to split between the two (some day..)
> >
> > My suggestion would be to at least split these two in the neutron-lib, 
> but maybe
> > i miss understood the scope of the lib


__
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] neutron-lib and dependencies in neutron reference implementation

[Henry Gessau]

Gal Sagie  wrote:
> Hello all,
> 
> I have recently came across some missing constants in neutron-lib and sent
> a patch but i wanted to try and understand the scope of the lib.
> 
> I see that the Neutron lib consist of many definitions which are actually
> part of the reference implementation and are not really "generic" Neutron
> parts.

Can you give specific examples of 'not really generic' constants?

> I am wondering if this is the right approach, especially since i think an
> end goal is to split between the two (some day..)
> 
> My suggestion would be to at least split these two in the neutron-lib, but 
> maybe
> i miss understood the scope of the lib


__
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] Elevating context to remove subnets created by admin

[Henry Gessau]

Carl Baldwin  wrote:
> On Fri, Jun 3, 2016 at 2:26 PM, Henry Gessau  wrote:
>> Darek Smigiel  wrote:
>>> strange, that owner is not able to just get rid of *his* network and 
>>> subnets.
>>
>> But not all the subnets are his, and consequently the network is partially 
>> not
>> his.
> 
> To me, this is a nonsensical outcome and tells me that subnets
> probably shouldn't really have owners distinct from the network's.

Right. So are you saying we should prevent that?



__
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] Elevating context to remove subnets created by admin

[Henry Gessau]

Darek Smigiel  wrote:
> strange, that owner is not able to just get rid of *his* network and subnets.

But not all the subnets are his, and consequently the network is partially not
his.

Why did the admin create a subnet on the user's network in [1]?

IMO the admin messed things up for the user.

[1] https://bugs.launchpad.net/neutron/+bug/1588228

__
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] Mid-cycle development sprint (NOTE: DATE CHANGE!)

[Henry Gessau]

Thierry Carrez  wrote:
> Rossella Sblendido wrote:
>> On 05/26/2016 10:47 PM, Henry Gessau wrote:
>>> I am happy to announce that the location logistics for the Neutron mid-cycle
>>> have been finalized. The mid-cycle will take place in Cork, Ireland on 
>>> August
>>> 15-17. I have updated the wiki [1] where you will find a link to an etherpad
>>> with all the details. There you can add yourself if you plan to attend, and
>>> make updates to topics that you would like to work on.
>>
>> Thanks for organizing this! I am happy to see a sprint in Europe :)
>> Unfortunately the 15th is bank holidays in some European countries and
>> at least in Italy most people organize their holidays around those days.
>> I will try to change my plans and do my best to attend.
> 
> For reference, Assumption (Aug 15) is a nationwide public holiday in the 
> following countries in Europe:
> 
> Andorra, Austria, Belgium, Croatia, Cyprus, France, Greece, Italy, 
> Lithuania, Luxembourg, Republic of Macedonia, Malta, Republic of 
> Moldova, Monaco, Poland (Polish Army Day), Portugal, Romania, Slovenia, 
> and Spain.
> 
> Beyond people generally organizing summer vacation around that date, 
> it's also peak-season for European travel, which can make flight prices 
> go up :)
> 
> But then, no date is perfect.
> 

After some discussions I have decided to keep this week but change it slightly
to the end of the week, Wednesday to Friday.

I other words, August 17-19. Same location.
I have updated the wiki and the etherpad.

-- 
Henry

__
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] Mid-cycle development sprint

[Henry Gessau]

I am happy to announce that the location logistics for the Neutron mid-cycle
have been finalized. The mid-cycle will take place in Cork, Ireland on August
15-17. I have updated the wiki [1] where you will find a link to an etherpad
with all the details. There you can add yourself if you plan to attend, and
make updates to topics that you would like to work on.


[1] https://wiki.openstack.org/wiki/Sprints#Newton_sprints



__
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][stable] proposing Brian Haley for neutron-stable-maint

[Henry Gessau]

+1 for Brian. (And retroactive +1 for Cedric.)

Ihar Hrachyshka  wrote:
> Hi stable-maint-core and all,
> 
> I would like to propose Brian for neutron specific stable team.
> 
> His stats for neutron stable branches are (last 120 days):
> 
> mitaka: 19 reviews; liberty: 68 reviews (3rd place in the top); kilo: 16
> reviews.
> 
> Brian helped the project with stabilizing liberty neutron/DVR jobs, and
> with other L3 related stable matters. In his stable reviews, he shows
> attention to details.
> 
> If Brian is added to the team, I will make sure he is aware of all stable
> policy intricacies.
> 
> Side note: recently I added another person to the team (Cedric Brandilly),
> and now I realize that I haven’t followed the usual approval process. That
> said, the person also has decent stable review stats, and is aware of the
> policy. If someone has doubts about that addition to the team, please ping
> me and we will discuss how to proceed.
> 
> 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] [all] summit session recap - getting API Docs off WADL and into RST

[Henry Gessau]

Sean Dague  wrote:
> Part of the cross project session track -
> https://etherpad.openstack.org/p/newton-api-docs-rst
> 
> The first half of the session was spent going over the background issues
> and the work so far. The TL;DR
> 
> * We need to get off WADL, it's a dead spec, and it's use is inhibiting
> contributions
> * We *need* to get up to date docs to our users, ASAP. The API
> References are way out of data and inaccurate in most places (and
> missing entirely for 50% of our projects with REST APIs)
> * Swagger (OpenAPI) was looked at, but there are hard problems in our
> legacy APIs that aren't possible to solve within the spec at hand
> * Nova team started building some semistructured tooling based on RST /
> Sphinx to move forward.
> 
> We then looked at the sphinx extension work in the Nova api-ref tree.
> 
> Question: why not https://pythonhosted.org/sphinxcontrib-httpdomain/?
> Answer: we have some specific needs on formating, headers where it
> doesn't fit (see etherpad for full answer).
> 
> Next Steps:
> 
> * Nova team is doing a doc sprint to try to get through verification of
> the content we've got
> * Once that is done (under control) sdague to work on splitting out
> sphinx extension into a dedicated project to make it easy for others to
> consume / contribute
> * Cinder, Ironic, and Keystone ready to get started on similar conversion

Neutron too. Akihiro Motoki and I are the contacts.

Thanks for this initiative. With the focus on RST we will have many more
developers contributing to docs, I am sure.


__
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] Easing contributions to central documentation

[Henry Gessau]

Matt Kassawara  wrote:
> At each summit, I speak with a variety of developers from different projects
> about the apparent lack of contributions to the central documentation. At
> previous summits, the most common complaint involved using DocBook. After
> converting most of the documentation to RST, the most common complaint at the
> recent summit involves the review process, particularly the lengthy amount of
> time patches sit in the review queue with -1s for various "conventions"
> problems such as structure, formatting, grammar, spelling, etc. Unlike most
> OpenStack developers that focus on a particular project, the documentation
> team covers all projects and lacks the capacity to understand each one enough
> to contribute and maintain technically accurate documentation in a timely
> manner. However, covering all projects enables the documentation team to
> organize and present the documentation to various audiences, primarily
> operators and users, that consume OpenStack as a coherent product. In other
> words, the entire process relies on developers contributing to the central
> documentation. So, before developer frustrations drive some or all projects to
> move their documentation in-tree which which negatively impacts the goal of
> presenting a coherent product, I suggest establishing an agreement between
> developers and the documentation team regarding the review process. 
> 
> As much as the documentation team wants to present OpenStack as a coherent
> product, it contains many projects with different contribution processes. In
> some cases, individual developers prefer to contribute in unique ways. Thus,
> the conventional "one-size-fits-all" approach that the documentation team
> historically takes with reviewing contributions from developers yields various
> levels of frustration among projects and developers. I ran a potential
> solution by various developers during the recent summit and received enough
> positive feedback to discuss it with a larger audience. So, here goes...
> 
> A project or individual developer decides the level of documentation team
> involvement with reviewing patches. The developer adds a WIP to the
> documentation patch while adding content to prevent premature reviews by the
> documentation team. Once the content achieves a sufficient level of technical
> accuracy, the developer removes the WIP and adds a comment in the review
> indicating of the following preferences:
> 
> 1) The documentation team should review the patch for compliance with
> conventions (proper structure, format, grammar, spelling, etc.) and provide
> feedback to the developer who updates the patch.
> 2) The documentation team should modify the patch to make it compliant and ask
> the developer for a final review to prior to merging it.
> 3) The documentation team should only modify the patch to make it build (if
> necessary) and quickly merge it with a documentation bug to resolve any
> compliance problems in a future patch by the documentation team.
> 
> What do you think?

I think this is fantastic and I particularly like option (2).

Thanks for this initiative.



__
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] neutron-lib report from the summit

[Henry Gessau]

At the Newton summit in Austin we held a session on the next steps for
neutron-lib. Here is a report on what was discussed at the session.

Etherpad:
https://etherpad.openstack.org/p/newton-neutron-lib-next-steps

Progress so far
---
The package is on PyPI and sub-projects should be using it now.

Only the very obvious and easy items have been added to neutron-lib:
  - Common constants
  - Common exceptions
  - Attribute converters and validators
  - Common hacking checks, including one to aid decoupling (N530)

Adding database and DB model support

We are leaning towards a common pattern for interacting with neutron resources
using oslo versioned objects (OVOs). The OVO work in neutron core needs to
mature a bit before we start moving it to neutron-lib.

Some basic DB utility methods will be added to allow sub-projects to add and
update their own tables.

Architecture decisions
--
  - Should there be more than one library, with smaller pieces?
  - Decide what is useful before just trying to do  everything.
  - Decide on Callbacks: OVO integration, or something else?
  - OVOs are new in neutron core, which means they are inherently unstable
(undergoing changes) and buggy. The goal is for neutron-lib to contain
stable and proven code, yet OVOs are permeating many of the things we
want in neutron-lib. How do we reconcile this?

Documentation
-
We need to write API documentation. Contributions are welcome.
We need to expand the devref with details on how to use the lib, how to add
things, how to work on dependent code without being blocked, etc.

Work planned for Newton (and beyond)
---
  - DB common utils (for operations not requiring OVO)
  - DB common framework with OVO integration
  - DB alembic migration interface
  - RPC common framework and utilities
  - Finalize Callbacks
  - Context support
  - Policy support
  - Config support, on top of oslo.config?
  - Agent common utils/framework?
  - Extensions common utils/framework?

We should try to determine the priority of these planned items.

We should have a Release Cadence strategy. We can decide on publishing a
release at each weekly meeting, or have a regular cadence, or have a process
similar to oslo libraries.


__
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] OSC transition

[Henry Gessau]

Adding the [neutron] tag.

I believe that the OSC extension for neutron-dynamic-routing should live in
the python-neutronclient repo. Keep in touch with Richard Theis as he is the
one leading the transition to OSC. He is rtheis on IRC.

See:
http://lists.openstack.org/pipermail/openstack-dev/2016-April/093139.html
https://review.openstack.org/309587


Na Zhu  wrote:
> Dear All,
> 
> 
> I have a question about OSC transition, recently, the community approves
> moving bgp out of neutron, as a service like other *aas. The BGP CLIs need be
> removed from neutronclient. Because of OSC transition, I can not just move the
> BGP CLIs code from python-neutronclient repo to neutron-dynamic-routing repo.
> I have to refactor the code and do transition to OSC plugin system.
>  
> From the
> link 
> _http://docs.openstack.org/developer/python-openstackclient/plugins.html_, the
> client has a separate repo, take designate as example, the CLI repo is
> python-designateclient, the project repo is designate. So for BGP, should I
> create a repo for CLI, or leverage project repo neutron-dynamic-routing?
> 
> 
> 
> 
> Regards,
> Juno Zhu
> IBM China Development Labs (CDL) Cloud IaaS Lab
> Email: na...@cn.ibm.com
> 5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New
> District, Shanghai, China (201203)
> 
> 
> __
> 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] Neutron lib hack has broken all decomposed projects

[Henry Gessau]

This was a learning experience and we found out the hard way about an extra
dependency we had not anticipated. Thanks Gary for spotting it early and
hopefully the revert will merge soon.

Doug Wiegley  wrote:
> That revert is https://review.openstack.org/#/c/309776 , and is working its
> way through CI now.  About to lose connectivity for my flight to the summit…
>
> doug
>
>
>> On Apr 24, 2016, at 9:24 AM, Doug Wiegley > > wrote:
>>
>> Reverted the neutron change that started using this, which is the quickest
>> path to unbreaking the children. We’ll have to unwind those child projects
>> first.
>>
>> doug
>>
>>
>>> On Apr 24, 2016, at 8:09 AM, Gary Kotton >> > wrote:
>>>
>>> Another example is Lbaas - https://review.openstack.org/#/c/309766/
>>>
>>> I have posted https://review.openstack.org/309770
>>>
>>> Its either that or we skip the current neutron-lib in the requirements file.
>>>
>>> Neutron lib cores please look ASAP as the whole community is kind of stuck
>>> at the moment…
>>>
>>> From: Gary Kotton mailto:gkot...@vmware.com>>
>>> Reply-To: OpenStack List >> >
>>> Date: Sunday, April 24, 2016 at 4:48 PM
>>> To: OpenStack List >> >
>>> Subject: [openstack-dev] [Neutron] Neutron lib hack has broken all
>>> decomposed projects
>>>
>>> Hi,
>>> Commit 4b17f1da1a5f65f0c4db395034ed732174a19315 has broken the pep8 of all
>>> of the decomposed projects.
>>> Do we need this hacking check? Can we have it reverted
>>> An example of this is - 
>>> OVN
>>> - 
>>> http://logs.openstack.org/35/299835/3/check/gate-networking-ovn-pep8/3ad066e/console.html
>>> Thanks
>>> Gary
>>> __
>>> 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] Proposing Hirofumi Ichihara to Neutron Core Reviewer Team

[Henry Gessau]

+1, Hirofumi will make a great addition.

Akihiro Motoki  wrote:
> Hi Neutrinos,
> 
> As the API Lieutenant of Neutron team,
> I would like to propose Hirofumi Ichihara (irc: hichihara) as a member of
> Neutron core reviewer team mainly focuing on the API/DB area.
> 
> Hirofumi has been contributing neutron actively in the recent two
> releases constantly.
> He was involved in key features in API/DB areas in Mitaka such as
> tagging support and network availability zones.
> I believe his knowledge and involvement will be great addition to our team.
> He have been reviewing constantly [1] and I expect he continue to work
> for Newton or later.
> 
> Existing API/DB core reviews (and other Neutron core reviewers),
> please vote +1/-1 for the addition of Hirofumi to the team.
> 
> Thanks!
> Akihiro
> 
> 
> [1] http://stackalytics.com/report/contribution/neutron/90


__
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] unit test failures due to new release of Routes package (v2.3)

[Henry Gessau]

https://launchpad.net/bugs/1563028
https://review.openstack.org/298855

Aditya Vaja  wrote:
> Hi,
> 
> I'm seeing unit test failures when I test locally after a fresh git clone of
> neutron master.
> 
> $ ./run_tests.sh -V -f
> 
> log excerpt: http://paste.openstack.org/show/492384/
> 
> I update the requirements.txt to use 'Routes<2.0,>=1.12.3' and all the tests
> work fine.
> I see there was a new release (v2.3 ) of Routes on 28th March 2016 [1], which
> seems to have caused the issue, specifically:
>  - Concatenation fix when using submappers with path prefixes. Multiple
> submappers combined the path prefix inside the controller argument in
> non-obvious ways. The controller argument will now be properly carried through
> when using submappers. PR #28[2].
> 
> Is anyone else noticing the test failures?
> Should I submit this requirements.txt change as a patch or should we pass the
> required two args as the patch? I can do the requirement.txt change. For the
> latter, somebody who knows what goes on in the extensions.py __init__() should
> take a look.
> 
> I assume this will also affect the stable branches, since the Routes package
> versin in requirements.txt in previous versions was same as in master.
> 
> --
> Aditya
> [1] 
> https://routes.readthedocs.org/en/latest/changes.html#release-2-3-march-28-2016
> [2] 
> https://github.com/bbangert/routes/pull/28/files?diff=unified#diff-b54de741c3f86d76eb4bce4a223054aaL154



__
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] Plan for changes affecting DB schema

[Henry Gessau]

na...@vn.fujitsu.com  wrote:
> Two weeks ago, I received an information about changing affecting DB schema
> [1] from Henry Gessau just a day before the deadline. I was so surprised about
> this and could not change my plan for my patch sets. Do you know any plan for
> this ?

There should be no surprises. Neutron follows the OpenStack release schedule
[1]. For Mitaka, it looked like [2].

> In the future, do you have plan for this in Netwon cycle?

The Newton release schedule is at [3], although the details are still being
planned. The detailed dates should be available soo.

[1] http://releases.openstack.org
[2] http://releases.openstack.org/mitaka/schedule.html
[3] http://releases.openstack.org/newton/schedule.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] Last chance to finish changes affecting DB schema for Mitaka

[Henry Gessau]

Takashi Yamamoto  wrote:
> hi,
> 
> On Wed, Mar 9, 2016 at 9:01 PM, Henry Gessau  wrote:
>> Takashi Yamamoto  wrote:
>>> Henry,
>>>
>>> i think it's better to fix model vs migration mismatch issues [1]
>>> before tagging.
>>> how do you think?
>>
>> I agree that [1] should be included in Mitaka, but it just adds the
>> model-migration test to lbaas. The test passes so I don't see any issues, and
>> the patch is independent of the milestone tagging.
>>
>> Please let me know if I am missing the issue(s).
> 
> [1] is depending on patches which actually fixes mismatches. [2] [3]

Thanks. Gerrit's UI strikes again.

> [2] https://review.openstack.org/#/c/287014/
> [3] https://review.openstack.org/#/c/287015/
> 
>>
>>>
>>> [1] https://review.openstack.org/#/c/287016/
>>>
>>> On Tue, Mar 8, 2016 at 11:52 PM, Henry Gessau  wrote:
>>>> By tomorrow we intend to tag the heads of all the neutron alembic branches
>>>> with the MITAKA label [1][2][3][4].
>>>>
>>>> If you have a patch that adds an alembic migration and you want to get it 
>>>> in
>>>> Mitaka you must be associated with a targeted BP/RFE/bug [5] and get your 
>>>> code
>>>> merged by tomorrow (Wednesday, March 9).
>>>>
>>>> Here is a list of open reviews with DB migration changes [6]. Check if your
>>>> Mitaka-targeted patch is on the list and if so, reach out to me (HenryG) or
>>>> our PTL (armax) on IRC and let us know of your plans.
>>>>
>>>> -- HenryG
>>>>
>>>> [1] https://review.openstack.org/288212
>>>> [2] https://review.openstack.org/288213
>>>> [3] https://review.openstack.org/288214
>>>> [4] https://review.openstack.org/288215
>>>> [5] https://launchpad.net/neutron/+milestone/mitaka-rc1
>>>> [6]
>>>> https://review.openstack.org/#/q/(project:openstack/neutron+OR+project:openstack/neutron-fwaas+OR+project:openstack/neutron-lbaas+OR+project:openstack/neutron-vpnaas)+status:open+file:%22%255E.*/versions/mitaka/.*%22+-label:workflow-1
>>>>
>>>> __
>>>> 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
> 
> __
> 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] Last chance to finish changes affecting DB schema for Mitaka

[Henry Gessau]

Takashi Yamamoto  wrote:
> Henry,
> 
> i think it's better to fix model vs migration mismatch issues [1]
> before tagging.
> how do you think?

I agree that [1] should be included in Mitaka, but it just adds the
model-migration test to lbaas. The test passes so I don't see any issues, and
the patch is independent of the milestone tagging.

Please let me know if I am missing the issue(s).

> 
> [1] https://review.openstack.org/#/c/287016/
> 
> On Tue, Mar 8, 2016 at 11:52 PM, Henry Gessau  wrote:
>> By tomorrow we intend to tag the heads of all the neutron alembic branches
>> with the MITAKA label [1][2][3][4].
>>
>> If you have a patch that adds an alembic migration and you want to get it in
>> Mitaka you must be associated with a targeted BP/RFE/bug [5] and get your 
>> code
>> merged by tomorrow (Wednesday, March 9).
>>
>> Here is a list of open reviews with DB migration changes [6]. Check if your
>> Mitaka-targeted patch is on the list and if so, reach out to me (HenryG) or
>> our PTL (armax) on IRC and let us know of your plans.
>>
>> -- HenryG
>>
>> [1] https://review.openstack.org/288212
>> [2] https://review.openstack.org/288213
>> [3] https://review.openstack.org/288214
>> [4] https://review.openstack.org/288215
>> [5] https://launchpad.net/neutron/+milestone/mitaka-rc1
>> [6]
>> https://review.openstack.org/#/q/(project:openstack/neutron+OR+project:openstack/neutron-fwaas+OR+project:openstack/neutron-lbaas+OR+project:openstack/neutron-vpnaas)+status:open+file:%22%255E.*/versions/mitaka/.*%22+-label:workflow-1
>>
>> __
>> 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

[openstack-dev] [neutron] Last chance to finish changes affecting DB schema for Mitaka

[Henry Gessau]

By tomorrow we intend to tag the heads of all the neutron alembic branches
with the MITAKA label [1][2][3][4].

If you have a patch that adds an alembic migration and you want to get it in
Mitaka you must be associated with a targeted BP/RFE/bug [5] and get your code
merged by tomorrow (Wednesday, March 9).

Here is a list of open reviews with DB migration changes [6]. Check if your
Mitaka-targeted patch is on the list and if so, reach out to me (HenryG) or
our PTL (armax) on IRC and let us know of your plans.

-- HenryG

[1] https://review.openstack.org/288212
[2] https://review.openstack.org/288213
[3] https://review.openstack.org/288214
[4] https://review.openstack.org/288215
[5] https://launchpad.net/neutron/+milestone/mitaka-rc1
[6]
https://review.openstack.org/#/q/(project:openstack/neutron+OR+project:openstack/neutron-fwaas+OR+project:openstack/neutron-lbaas+OR+project:openstack/neutron-vpnaas)+status:open+file:%22%255E.*/versions/mitaka/.*%22+-label:workflow-1

__
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] [all][infra] eventlet 0.18.1 not on PyPi anymore

[Henry Gessau]

Doug Hellmann  wrote:
> Excerpts from Henry Gessau's message of 2016-02-17 11:00:53 -0500:
>> Doug Hellmann  wrote:
>>> Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800:
>>>> On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague  wrote:
>>>>
>>>>> On 02/17/2016 08:42 AM, Doug Hellmann wrote:
>>>>>> Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100:
>>>>>>> Le 17/02/2016 13:43, Henry Gessau a écrit :
>>>>>>>> And it looks like eventlet 0.18.3 breaks neutron:
>>>>>>>> https://bugs.launchpad.net/neutron/+bug/1546506
>>>>>>>
>>>>>>> 2 releases, 2 regressions in OpenStack. Should we cap eventlet version?
>>>>>>> The requirement bot can produce patches to update eventlet, patches
>>>>>>> which would run integration tests using Nova, Keystone, Neutron on the
>>>>>>> new eventlet version.
>>>>>>>
>>>>>>> eventlet 0.18.2 broke OpenStack Keystone and OpenStack Nova
>>>>>>> https://github.com/eventlet/eventlet/issues/296
>>>>>>> https://github.com/eventlet/eventlet/issues/299
>>>>>>> https://review.openstack.org/#/c/278147/
>>>>>>> https://bugs.launchpad.net/nova/+bug/1544801
>>>>>>>
>>>>>>> eventlet 0.18.3 broke OpenStack Neutron
>>>>>>> https://github.com/eventlet/eventlet/issues/301
>>>>>>> https://bugs.launchpad.net/neutron/+bug/1546506
>>>>>>>
>>>>>>> FYI eventlet 0.18.0 broke WSGI servers:
>>>>>>> https://github.com/eventlet/eventlet/issues/295
>>>>>>>
>>>>>>> It was followed quickly by eventlet 0.18.2 to fix this issue.
>>>>>>>
>>>>>>> Sadly, it looks like bugfix releases of eventlet don't include a single
>>>>>>> bugfix, but include also other changes. For example, 0.18.3 fixed the
>>>>>>> bug #296 but introduced "wsgi: TCP_NODELAY enabled by default"
>>>>> optimization.
>>>>>>>
>>>>>>> IMHO the problem is not the release manager of eventlet, but more the
>>>>>>> lack of tests on eventlet, especially on OpenStack services.
>>>>>>>
>>>>>>> Current "Continious Delivery"-like with gates do detect bugs, yeah, but
>>>>>>> also block a lot of developers when the gates are broken. It doesn't
>>>>>>> seem trivial to investigate and fix eventlet issues.
>>>>>>>
>>>>>>> Victor
>>>>>>>
>>>>>>
>>>>>> Whether we cap or not, we should exclude the known broken versions.
>>>>>> It looks like getting back to a good version will also require
>>>>>> lowering the minimum version we support, since we have >=0.18.2
>>>>>> now.
>>>>>>
>>>>>> What was the last version of eventlet known to work?
>>>>>
>>>>> 0.18.2 works. On the Nova side we had a failure around unit tests which
>>>>> was quite synthetic that we fixed. I don' know what the keystone issue
>>>>> turned out to be.
>>>>>
>>>>
>>>> I believe the keystone issue was a test specific issue, not a runtime
>>>> issue. We disabled the test.
>>>> --Morgan
>>>
>>> OK. Can someone from the neutron team verify that 0.18.2 works? If so,
>>> we can just exclude 0.18.3 and reset the constraint.
>>
>> I can confirm that neutron works with 0.18.2 as far as we know.
>>
> 
> Great. If you (or someone else) wants to submit a requirements update, I
> can approve it. Ping me in #openstack-release.

If it's only neutron that is affected by 0.18.3 then we already have our
workaround in place [1]. Additionally, eventlet 0.18.4 will replace the
breaking change with a different approach [2].

[1] https://review.openstack.org/281278
[2] https://github.com/eventlet/eventlet/issues/301


__
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] [all][infra] eventlet 0.18.1 not on PyPi anymore

[Henry Gessau]

Doug Hellmann  wrote:
> Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800:
>> On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague  wrote:
>>
>>> On 02/17/2016 08:42 AM, Doug Hellmann wrote:
>>>> Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100:
>>>>> Le 17/02/2016 13:43, Henry Gessau a écrit :
>>>>>> And it looks like eventlet 0.18.3 breaks neutron:
>>>>>> https://bugs.launchpad.net/neutron/+bug/1546506
>>>>>
>>>>> 2 releases, 2 regressions in OpenStack. Should we cap eventlet version?
>>>>> The requirement bot can produce patches to update eventlet, patches
>>>>> which would run integration tests using Nova, Keystone, Neutron on the
>>>>> new eventlet version.
>>>>>
>>>>> eventlet 0.18.2 broke OpenStack Keystone and OpenStack Nova
>>>>> https://github.com/eventlet/eventlet/issues/296
>>>>> https://github.com/eventlet/eventlet/issues/299
>>>>> https://review.openstack.org/#/c/278147/
>>>>> https://bugs.launchpad.net/nova/+bug/1544801
>>>>>
>>>>> eventlet 0.18.3 broke OpenStack Neutron
>>>>> https://github.com/eventlet/eventlet/issues/301
>>>>> https://bugs.launchpad.net/neutron/+bug/1546506
>>>>>
>>>>> FYI eventlet 0.18.0 broke WSGI servers:
>>>>> https://github.com/eventlet/eventlet/issues/295
>>>>>
>>>>> It was followed quickly by eventlet 0.18.2 to fix this issue.
>>>>>
>>>>> Sadly, it looks like bugfix releases of eventlet don't include a single
>>>>> bugfix, but include also other changes. For example, 0.18.3 fixed the
>>>>> bug #296 but introduced "wsgi: TCP_NODELAY enabled by default"
>>> optimization.
>>>>>
>>>>> IMHO the problem is not the release manager of eventlet, but more the
>>>>> lack of tests on eventlet, especially on OpenStack services.
>>>>>
>>>>> Current "Continious Delivery"-like with gates do detect bugs, yeah, but
>>>>> also block a lot of developers when the gates are broken. It doesn't
>>>>> seem trivial to investigate and fix eventlet issues.
>>>>>
>>>>> Victor
>>>>>
>>>>
>>>> Whether we cap or not, we should exclude the known broken versions.
>>>> It looks like getting back to a good version will also require
>>>> lowering the minimum version we support, since we have >=0.18.2
>>>> now.
>>>>
>>>> What was the last version of eventlet known to work?
>>>
>>> 0.18.2 works. On the Nova side we had a failure around unit tests which
>>> was quite synthetic that we fixed. I don' know what the keystone issue
>>> turned out to be.
>>>
>>
>> I believe the keystone issue was a test specific issue, not a runtime
>> issue. We disabled the test.
>> --Morgan
> 
> OK. Can someone from the neutron team verify that 0.18.2 works? If so,
> we can just exclude 0.18.3 and reset the constraint.

I can confirm that neutron works with 0.18.2 as far as we know.


__
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] [all][infra] eventlet 0.18.1 not on PyPi anymore

[Henry Gessau]

And it looks like eventlet 0.18.3 breaks neutron:
https://bugs.launchpad.net/neutron/+bug/1546506

Victor Stinner  wrote:
> Hi,
> 
> I asked eventlet dev to *not* remove a release from PyPI before they did 
> it, but they ignored me and removed 0.18.0 and 0.18.1 releases from PyPI :-(
> 
> 0.18.0 fixed a bug in Python 3:
> https://github.com/eventlet/eventlet/issues/274
> 
> But 0.18.0 introduced a regression on Python 3 in WSGI:
> https://github.com/eventlet/eventlet/issues/295
> 
> 0.18.2 was supposed to fix the WSGI bug, but introduced a different bug 
> in Keystone:
> https://github.com/eventlet/eventlet/issues/296
> 
> Yeah, it's funny to work on eventlet :-) A new bug everyday :-D
> 
> At least, the eventlet test suite is completed at each bugfix.
> 
> Victor
> 
> Le 09/02/2016 17:44, Markus Zoeller a écrit :
>> For the sake of completeness: The eventlet package version 0.18.1
>> seems to be disappeared from the PyPi servers, which is a bad thing,
>> as we use that version in the "upper-constraints.txt" of the
>> requirements project. There is patch [1] in the queue which solves that.
>> Until this is merged, there is a change that our CI (and your third-party
>> CI) will break after the locally cached version in the CI vanishes.
>>
>> References:
>> [1] https://review.openstack.org/#/c/277912/
>>
>> Regards, Markus Zoeller (markus_z)
>>
>>
>> __
>> 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] questions about uni test

[Henry Gessau]

Gareth  wrote:
> It creates and cleans the tables in memory?

Creates and deletes actually.

Line 69 creates all the tables when a test starts.

Line 78 uses the unittest framework to add the function clear_tables() to the
post-test operations that are run after every test. So after a test finishes,
all the tables will be deleted by line 76.


Neutron's unit test framework uses a sqlite in-memory database, yes. This is
configured by [1].

[1]
https://github.com/openstack/neutron/blob/master/neutron/tests/etc/neutron.conf#L26


> 
> On Tue, Jan 26, 2016 at 12:56 AM, Assaf Muller  wrote:
>> On Mon, Jan 25, 2016 at 10:05 AM, Gareth  wrote:
>>> Hey neutron guys
>>>
>>> What will happen if I remove this line[0]?
>>>
>>> When running unit test, do we create tables in real database?
>>>
>>> [0] 
>>> https://github.com/openstack/neutron/blob/master/neutron/tests/unit/testlib_api.py#L78
>>
>> That line has nothing to do with what database backend you use (SQLite
>> or mysql or whatever), it's used to clear the contents of the tables
>> so the next test starts with a clean DB.
>>
>>>
>>> --
>>> Gareth (Kun Huang)
>>>
>>> Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball
>>> OpenStack contributor, kun_huang@freenode
>>> My promise: if you find any spelling or grammar mistakes in my email
>>> from Mar 1 2013, notify me
>>> and I'll donate $1 or ￥1 to an open organization you specify.
>>>
>>> __
>>> 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] Need you help.THANKS!!

[Henry Gessau]

hao li  wrote:
> Hi,everybody.
> I am a new hand.At first,I don't know whether the neutron's contributors can
> receive this letter.
> If not,could you tell me how to contact with them?
> We are a neutron team.we add a ''AC-L2 Mech Driver'' to the ML2 Plug-in to
> support our company controllers.We also add a  ''AC-VPN Service Driver'' to
> the Vpnaas Plug-in to support our company controllers.
> Based on the spirit of the "four open",we want to get these code open by the
> way of sub-project .
> Of course our team try to make our Plugins to conform to the specs. 
> Are you interested to have a look at our codes documents and ppt?
>  
> Apologies for the confusion.
>  
> Hao Li

I think most of what you are asking is answered here:
http://docs.openstack.org/developer/neutron/devref/contribute.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] Heads up for decomposed plugin break

[Henry Gessau]

Doug Wiegley  wrote:
> 
> 
>> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka  wrote:
>>
>> Sean M. Collins  wrote:
>>
 On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote:
> On Fri, 8 Jan 2016, Gary Kotton wrote:
>
> The commit https://github.com/openstack/neutron/commit/5d53dfb8d64186-
> b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins that make
> use of the method _get_tenant_id_for_create

 Just out of curiosity, is it not standard practice that a plugin
 shouldn't use a private method?
>>>
>>> +1 - hopefully decomposed plugins will audit their code and look for
>>> other calls to private methods.
>>
>> The fact that it broke *aas repos too suggests that we were not showing a
>> proper example to those decomposed. I think it can be reasonable to
>> restore the method until N, with a deprecation message, as Garry
>> suggested in his patch. Especially since there is no actual burden to
>> keep the method for another cycle.
> 
> The neutron community has been really lax about enforcing private methods.
> And while we should absolutely reverse that trend, likely we should give
> some warning. I agree with not going whole hog on that until N.
> 
> I'd suggest putting in a debtcollector reference when putting the method 
> back. 

Done. https://review.openstack.org/265315


__
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] Heads up for decomposed plugin break

[Henry Gessau]

Gary Kotton  wrote:
> commit 
> https://github.com/openstack/neutron/commit/5d53dfb8d64186b5b1d2f356fbff8f222e15d1b2
>  may
> break the decomposed plugins that make use of the method 
> _get_tenant_id_for_create

Note that this is a private method. Plugins should avoid using private
methods. Unfortunately during the decomposition efforts not enough effort was
expended on scrubbing private methods from the plugins. This should be
something that plugin maintainers continue to work on and keep an eye out for.

> It would have been nice if there was a deprecation warning.

I don't think we should have deprecation warnings for private properties.

> Options:
> 
>  1. Decomposed plugins fix this
>  2. Revert the patch and find a solution that does not break the plugins
> 
> If we do go for #1 then we can start to stop enforcing the usage of the
> deprecation warnings…

We will continue to use deprecation warnings for changes to non-private
methods affecting plugins.


__
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] Gate failure

[Henry Gessau]

Armando M.  wrote:
> Hi folks,
> 
> Due to [1], Neutron related jobs (api, and lbaas) are failing. Please hold
> your +A button until the issue is resolved.
> 
> Thanks,
> Armando 
> 
> [1] https://review.openstack.org/#/c/256164/

That fix has merged, but now we have a new issue [2] in the api job. :(

[2] https://bugs.launchpad.net/neutron/+bug/1531706



__
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] Rename tenant to project: discussion

[Henry Gessau]

Kevin Benton  wrote:
> So obviously the stuff in the client can be updated since most of that is
> user-facing. However, on the server side maybe we can start out by keeping all
> of the internal code and DB tables the same. Then all we need to worry about
> is the API translation code to start.
> 
> Once our public-facing stuff is done, we can just start the transition to
> project_id internally at our own pace and in much less invasive chunks.

I agree with Kevin's suggestion.

> On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz  > wrote:
> 
> Hey Neutrinos (thanks armax for this word :),
> Keystone is planning to deprecate V2 API (again :). This time in Mitaka
> [6], and probably forever. It will stay at least four releases, but we
> need to decide, how to conquer problem of renaming...
> And more important: consider if it's a problem for Neutron?
> 
> I'm looking at blueprint [1] about renaming all occurrences of 'tenant' to
> 'project', and trying to find out all the details.
> First attempt to solve this problem was raised in November 2013 [4][5] but
> unfortunately, no one finished it. Although Keystone V3 API is already
> supported in Neutron client [2], there are still some unknowns about
> Neutron server side. Monty Taylor is trying to address necessary (if any)
> changes [3].
> 
> Findings:
> I've focused on two projects: python-neutronclient and neutron.
> grep found 429 occurrences of 'tenant' in Client while Server has 3021 of
> it. Some of them are just documentation and docstrings, but there are a
> lot of places, where variables are tangled: defined in DB, used in server,
> accessed by client. Most of places are just internal usages. The only
> thing where I've found 'public' information about tenants is 'help'
> command in neutron client.
> 
> Suggested plan for conquer:
> 1. First step would be to deal with neutronclient. It's much smaller
> amount of code to look through, update all places and be successful :)
> 2. Bigger challenge will be to change server side code. I'd suggest to
> start with renaming db columns. It affects a lot of places, so when
> finished should significantly lower number of remained "tenants".
> 3. Deal with all other places.
> 
> Pros:
> - variable names unification in OpenStack code base. Someone needs to
> start this job.
> - one way to describe the same thing, instead of: tenant/account/project.
> Helpful, especially for newcomers.
> - alignment with Keystone V3 API
> 
> Cons:
> - A. Lot. Of. Work.
> - dealing with DB migrations
> - about 2-4 weeks of work for every part of code. Additional, a lot of
> patchsets to be reviewed.
> 
> What do you think about this? About proposed way of dealing with all 
> changes?
> Is this change necessary?
> Did I forget about something?
> 
> I'll be grateful for any kind of feedback.
> 
> Thanks,
>  Dariusz Smigiel (dasm)
>  Intel Technology Poland
> 
> [1] 
> https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project
> [2]
> 
> https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support
> [3] https://bugs.launchpad.net/neutron/+bug/1503428
> [4]
> 
> http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html
> [5]
> 
> http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html
> [6]
> 
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm
> 


__
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] Multiple locations for documentation of features

[Henry Gessau]

Sean M. Collins  wrote:
> I've noticed that a lot of features are now being documented as RSTs
> inside of devref. Like the following:
> 
> https://review.openstack.org/#/c/251859/
> 
> But there are lots already present. Can someone point out to me what the
> criteria is for these documents? I am a little confused about the
> relationship between neutron-specs, RFE bugs, and some features being
> documented in devref. Especially when a review includes the actual code,
> then a new RST file in devref - wasn't that what specs were for?

Here is how I would like to see things ending up:

1. RFE: "I want X"
2. Spec: "I plan to implement X like this"
3. devref: "How X is implemented and how to extend it"
4. OS docs: "API and guide for using X"

Once X is implemented I don't want to have to go to 1 or 2 to find information
on it. The devref may have a lot of content from the spec, but the spec is not
maintained and the implementation may differ in some ways. The devref should
be kept current with refactorings, etc. of the implementation.

-- 
Henry

__
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][db][migration] Neutron db migrationby python scripts

[Henry Gessau]

Your installed neutron is not current. When developing new db migrations you
should be working with the master branch. Fast forward your repo and re-run
devstack to get the latest neutron-db-manage.

On Tue, Nov 03, 2015, Zhi Chang  wrote:
> Thanks for your reply.
>  There is an error when I run migration cmd:
>
> stack@devstack:~/neutron/neutron/db/migration$ neutron-db-manage revision -m
> 'desc' --contract
> usage: neutron-db-manage [-h] [--config-dir DIR] [--config-file PATH]
>  [--core_plugin CORE_PLUGIN] [--nosplit_branches]
>  [--service SERVICE] [--split_branches]
>  [--subproject SUBPROJECT] [--version]
>  [--database-connection DATABASE_CONNECTION]
>  [--database-engine DATABASE_ENGINE]
>
>  {current,history,branches,check_migration,upgrade,downgrade,stamp,revision}
>  ...
> neutron-db-manage: error: unrecognized arguments: --contract
>  
>  
> -- Original --
> *From: * "Anna Kamyshnikova";
> *Date: * Tue, Nov 3, 2015 07:03 PM
> *To: * "OpenStack Development Mailing List (not for usage
> questions)";
> *Subject: * Re: [openstack-dev] [Neutron][db][migration] Neutron db
> migrationby python scripts
>  
> You can create new migration using "neutron-db-manage revision -m 'desc'
> --expand/--contract" depends in what changes do you want to do in migration
> expand - add something, contract - delete or modify.
>  More information
> - http://docs.openstack.org/developer/neutron/devref/alembic_migrations.html
>
> On Tue, Nov 3, 2015 at 1:52 PM, Zhi Chang  > wrote:
>
> Hi, all
> Now, I should make some database model definitions if I want to
> upgrade db. And a database migration script will generated when I run
> "neutron-db-manage revision -m "description of revision" --autogenerate".
> The database will upgraded when run "neutron-db-manage upgrade head". 
> I want to upgrade db and I plan to write db migration scripts manually
> instead of change database model definitions. Is there some ways to
> realize it?
> Does anyone have some good ideas?
>
> Thanks
> Zhi Chang
>
> __
> 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
>
>
>
>
> -- 
> Regards,
> Ann Kamyshnikova
> Mirantis, Inc
>
>
> __
> 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] New cycle started. What are you up to, folks?

[Henry Gessau]

Thanks Ihar. Here is what I plan to work on, or hope to help out with:

Continue working on alembic to support online migrations.

The alembic migrations seem to be a mysterious thing to many developers. I plan
to improve the devref documentation around this. The --autogenerate of
revisions, in particular, should work smoothly for developers and across the
various neutron stadium projects.

In Liberty each Neutron sub-project has a separate alembic environment and that
prevents sub-projects from having migration dependencies on other sub-projects.
So I will fix that.

Neutron's DB transaction issues at scale are a problem. I am not an expert in
this area, but would like to co-ordinate an effort with Mike Bayer and experts
from Neutron and other OpenStack projects to characterize the issues and plan
some solutions and/or best practices.

Neutron's IPv6 support is now quite extensive, but there are still some loose
ends like router HA support, and being able to use IPv6 for API/management. I
will help to co-ordinate the IPv6 updates in Mitaka. I will also sync up with
the state of IPv6 support in the *aaS and stadium repos and help out with IPv6
efforts there.

I think Salvatore's proposal [1] for API evolution is extremely important to
Neutron's future and I would like to see it happen this cycle. I will help out
where I can.

I want to help (mostly by reviewing and testing) the effort to make Neutron
support Python 3.

Always willing to help with, review, and improve Neutron's tests and testing
strategies.

[1] https://review.openstack.org/136760

-- 
Henry


On Thu, Oct 01, 2015, Ihar Hrachyshka  wrote:
> Hi all,
> 
> I talked recently with several contributors about what each of us plans for
> the next cycle, and found it’s quite useful to share thoughts with others,
> because you have immediate yay/nay feedback, and maybe find companions for
> next adventures, and what not. So I’ve decided to ask everyone what you see
> the team and you personally doing the next cycle, for fun or profit.
> 
> That’s like a PTL nomination letter, but open to everyone! :) No commitments,
> no deadlines, just list random ideas you have in mind or in your todo lists,
> and we’ll all appreciate the huge pile of awesomeness no one will ever have
> time to implement even if scheduled for Xixao release.
> 
> To start the fun, I will share my silly ideas in the next email.
> 
> 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][horizon] Nice new Network Topology panel in Horizon

[Henry Gessau]

On Fri, Sep 25, 2015, Daniel Comnea  wrote:
> Great job Henry !

I had nothing to do with it! (See below.)

> On Fri, Sep 25, 2015 at 6:47 PM, Henry Gessau  <mailto:ges...@cisco.com>> wrote:
> 
> It has been about three years in the making but now it is finally here.
> A screenshot doesn't do it justice, so here is a short video overview:
> https://youtu.be/PxFd-lJV0e4
> 
> Isn't that neat? I am sure you can see that it is a great improvement,
> especially for larger topologies.
> 
> This new view will be part of the Liberty release of Horizon. I encourage 
> you to
> take a look at it with your own network topologies, play around with it, 
> and
> provide feedback. Please stop by the #openstack-horizon IRC channel if 
> there are
> issues you would like addressed.
> 
> Thanks to the folks who made this happen.

I forgot to include the list of folks:

Curvature was started by Sam Betts, John Davidge, Jack Fletcher and Bradley
Jones as an intern project under Debo Dutta. It was first implemented for
"quantum" on the Grizzly release of OpenStack [1]. Sam, John and Brad are now
regular upstream contributors to OpenStack. In the Horizon project Rob Cresswell
has been instrumental in getting the panel view integrated.

[1] https://youtu.be/pmpRhcwyJIo


__
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][horizon] Nice new Network Topology panel in Horizon

[Henry Gessau]

It has been about three years in the making but now it is finally here.
A screenshot doesn't do it justice, so here is a short video overview:
https://youtu.be/PxFd-lJV0e4

Isn't that neat? I am sure you can see that it is a great improvement,
especially for larger topologies.

This new view will be part of the Liberty release of Horizon. I encourage you to
take a look at it with your own network topologies, play around with it, and
provide feedback. Please stop by the #openstack-horizon IRC channel if there are
issues you would like addressed.

Thanks to the folks who made this happen.

__
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] cloud-init IPv6 support

[Henry Gessau]

Some thought has been given to this. See
https://bugs.launchpad.net/neutron/+bug/1460177

I like the third option, a well-known name using DNS.

On Thu, Sep 03, 2015, Kevin Benton  wrote:
> I think that's different than what is being asked here. That patch appears to
> just add IPv6 interface information if it's available in the metadata. This
> thread is about getting cloud-init to connect to an IPv6 address instead of
> 169.254.169.254 for pure IPv6 environments.
>
> On Thu, Sep 3, 2015 at 11:41 AM, Joshua Harlow  > wrote:
>
> I'm pretty sure this got implemented :)
>
> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/1042
> 
> 
> and https://bugs.launchpad.net/cloud-init/+bug/1391695
>
> That's the RHEL support, since cloud-init translates a ubuntu style
> networking style the ubuntu/debian style format should also work.
>
>
> Steve Gordon wrote:
>
> - Original Message -
>
> From: "Kevin Benton"mailto:blak...@gmail.com>>
>
> When we discussed this before on the neutron channel, I thought 
> it was
> because cloud-init doesn't support IPv6. We had wasted quite a bit
> of time
> talking about adding support to our metadata service because I was
> under
> the impression that cloud-init already did support IPv6.
>
> IIRC, the argument against adding IPv6 support to cloud-init was
> that it
> might be incompatible with how AWS chooses to implement IPv6
> metadata, so
> AWS would require a fork or other incompatible alternative to
> cloud-init in
> all of their images.
>
> Is that right?
>
>
> That's certainly my understanding of the status quo, I was enquiring
> primarily to check it was still accurate.
>
> -Steve
>
> On Thu, Sep 3, 2015 at 7:30 AM, Sean M. Collins >  wrote:
>
> It's not a case of cloud-init supporting IPv6 - The Amazon EC2
> metadata
> API defines transport level details about the API - and
> currently only
> defines a well known IPv4 link local address to connect to. No
> well known
> link local IPv6 address has been defined.
>
> I usually recommend config-drive for IPv6 enabled clouds due
> to this.
> --
> Sent from my Android device with K-9 Mail. Please excuse my
> brevity.
> 
> __
> 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
>
>
>
>
> -- 
> Kevin Benton
>
>
> __
> 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] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

[Henry Gessau]

+1 to both!

On Wed, Aug 12, 2015, Kyle Mestery  wrote:
> It gives me great pleasure to propose Russell Bryant and Brandon Logan as core
> reviewers in the API/DB/RPC area of Neutron. Russell and Brandon have both 
> been
> incredible contributors to Neutron for a while now. Their expertise has been
> particularly helpful in the area they are being proposed in. Their review 
> stats
> [1] place them both comfortably in the range of existing Neutron core 
> reviewers.
> I expect them to continue working with all community members to drive Neutron
> forward for the rest of Liberty and into Mitaka.
> 
> Existing DB/API/RPC core reviewers (and other Neutron core reviewers), please
> vote +1/-1 for the addition of Russell and Brandon.
> 
> Thanks!
> Kyle
> 
> [1] http://stackalytics.com/report/contribution/neutron-group/90



__
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] Proposing Cedric Brandily to Neutron Core Reviewer Team

[Henry Gessau]

+1!

On Wed, Jul 15, 2015, Carl Baldwin  wrote:
> As the Neutron L3 Lieutenant along with Kevin Benton for control
> plane, and Assaf Muller for testing, I would like to propose Cedric
> Brandily as a member of the Neutron core reviewer team under these
> areas of focus.
> 
> Cedric has been a long time contributor to Neutron showing expertise
> particularly in these areas.  His knowledge and involvement will be
> very important to the project.  He is a trusted member of our
> community.  He has been reviewing consistently [1][2] and community
> feedback that I've received indicates that he is a solid reviewer.
> 
> Existing Neutron core reviewers from these areas of focus, please vote
> +1/-1 for the addition of Cedric to the team.
> 
> Thanks!
> Carl Baldwin
> 
> [1] https://review.openstack.org/#/q/reviewer:zzelle%2540gmail.com,n,z
> [2] http://stackalytics.com/report/contribution/neutron-group/90



__
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] Plethora of dbase migration questions...

[Henry Gessau]

On Tue, Jul 07, 2015, Salvatore Orlando  wrote:
>
>
> On 7 July 2015 at 14:00, Paul Michali  > wrote:
>
> Thanks Salvatore for the responses. See @PCM in-line...
>
>
>
> On Tue, Jul 7, 2015 at 6:14 AM Salvatore Orlando  > wrote:
>
> Some comments inline.
>
> Salvatore
>
> On 6 July 2015 at 20:00, Paul Michali  > wrote:
>
> Hi,
>
> I have some urgent requests about migration that I'm hoping to
> get some info on. I'm working on a bug where I need to add two
> (related) fields to a table for VPNaaS. Here's the objectives
> related to migration...
>
> 1) create local_v4_ip and lcoal_v6_ip fields in the vpnservice 
> table
> 2) for each entry in the vpnservice table:
> 2.1) Get the router.gw_port.fixed_ips list
> 2.2) Determine the version of each fixed IP and store the
> first of each version (if any) into the appropriate new field.
>
> I have created a migration file, and I changed the down_revision
> to be the number of the revision that is the first in the
> migration chain in the VPN repo.
>
> Here are the many questions I have...
>
> When I look in the VPN repo, the HEAD file has the version
> 'kilo', which is not the current head. 
>
>
> Shouldn't it the version number of the first file in the
> migration chain?
>
>
> It should indeed. How are you generating the revision script? Using
> neutron-db-manage it should be updated automatically [1]
>
>
> @PCM I ran neutron-db-manage, when in the neutron repo, and it assigned
> some version, but it was not the latest in the neutron-vpnaas repo.
>
>
> when you create a revision Alembic automatically assigns it a unique id.
> However, the neutron migration CLI (neutron-db-manage) then should take care
> of updating the HEAD file automatically. If this is not happening, that's
> where the problem should be.
>
>
> I checked the VPN repo and there were a chain of versions, which I used
> to determine what the head should be and have set the version
> accordingly. However, in the current repo, head is set to "kilo", which
> appears to be incorrect.  The versions are:
>
> 5689aa52
> kilo   <<< HEAD
> 3ea02b2a773e
> start_neutron_vpnaas
> None
>
> Should I do a separate commit that fixes the HEAD file, or just fix it as
> part of the bug fix I'm working on.
>
>
> In order to pass functional tests the HEAD file must point to the topmost
> revision (5689aa52)
>
>
> BTW, at one point, after having correctly set the HEAD and versions in my
> new migration file, I think I ran neutron-db-manage check_migration, and
> I think it set the HEAD to my version, but it did that in the neutron
> repo, and not the VPN repo.  I might have been running from the wrong 
> repo?
>
>
> Yes, probably.
> neutron-db-manage by default works on the neutron repo. In order to work with
> a service repo you should specify it on the command line
> (http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/migration/cli.py#n41).
> This might also explain why the HEAD is not getting updated in your repo.
I have been playing around with this. Unfortunately, --service only works for
the "upgrade" command. It does not work for the "revision" command, and even
less for --autogenerate.

I am working on a fix.

>  
>
>
>
>
> For my commit, I'm assuming I change the HEAD file to use my
> migration file's version?
>
>
> You can do that manually too, yes.
>  
>
>
> I set HEAD to my migration file, and my file has a down revision
> of the previous head's revision. If I run 'neutron-db-manage
> --config-file ../neutron/etc/neutron.conf --config-file
> ../neutron/etc/neutron/plugins/ml2/ml2_conf.ini check_migration'
> there is no output so I guess that is OK.
>
> As I develop my new migration file, is there a way that I can
> test it (running neutron-db-migration, maybe)?
>
>
> When I test migrations I usually dump the database, run the migration
> with neutron-db-manage upgrade HEAD (I think it's not necessary to
> specify HEAD), and restore the db from the dump if the migration 
> fails.
>  
>
> Is there a way to run the migration file under the debugger, as
> well (importing pdb, for example)?
>
>
> The migration process is just like any python application, so I guess
> you can debug it with pdb. 
>
>
> @PCM Ah, so use "neutron-db-manage upgrade HEAD". That was the piece that
> was missing. I take it there are no specific unit tests of the migration
> files?
>
>
> ... 

Re: [openstack-dev] [neutron] Plethora of dbase migration questions...

[Henry Gessau]

On Tue, Jul 07, 2015, Paul Michali  wrote:
> Thanks Salvatore for the responses. See @PCM in-line...
>
>
>
> On Tue, Jul 7, 2015 at 6:14 AM Salvatore Orlando  > wrote:
>
> Some comments inline.
>
> Salvatore
>
> On 6 July 2015 at 20:00, Paul Michali  > wrote:
>
> Hi,
>
> I have some urgent requests about migration that I'm hoping to get
> some info on. I'm working on a bug where I need to add two (related)
> fields to a table for VPNaaS. Here's the objectives related to
> migration...
>
> 1) create local_v4_ip and lcoal_v6_ip fields in the vpnservice table
> 2) for each entry in the vpnservice table:
> 2.1) Get the router.gw_port.fixed_ips list
> 2.2) Determine the version of each fixed IP and store the first
> of each version (if any) into the appropriate new field.
>
> I have created a migration file, and I changed the down_revision to
> be the number of the revision that is the first in the migration
> chain in the VPN repo.
>
> Here are the many questions I have...
>
> When I look in the VPN repo, the HEAD file has the version 'kilo',
> which is not the current head. 
>
>
> Shouldn't it the version number of the first file in the migration 
> chain?
>
>
> It should indeed. How are you generating the revision script? Using
> neutron-db-manage it should be updated automatically [1]
>
>
> @PCM I ran neutron-db-manage, when in the neutron repo, and it assigned some
> version, but it was not the latest in the neutron-vpnaas repo.
neutron-db-manage does not handle alembic branches in separate repos very well
at all yet. I am working on updating it with
https://review.openstack.org/198524 but I have quite a lot left to do.

>
> I checked the VPN repo and there were a chain of versions, which I used to
> determine what the head should be and have set the version accordingly.
> However, in the current repo, head is set to "kilo", which appears to be
> incorrect.  The versions are:
>
> 5689aa52
> kilo   <<< HEAD
> 3ea02b2a773e
> start_neutron_vpnaas
> None
Ouch. That is an error, because https://review.openstack.org/190569 should have
updated HEAD but didn't.

The version sequence (you can see it in any devstack run) is:

INFO  [alembic.migration] Running upgrade  -> start_neutron_vpnaas, start
neutron-vpnaas chain
INFO  [alembic.migration] Running upgrade start_neutron_vpnaas -> 3ea02b2a773e,
add_index_tenant_id
INFO  [alembic.migration] Running upgrade 3ea02b2a773e -> kilo, kilo
INFO  [alembic.migration] Running upgrade kilo -> 5689aa52, fix identifier
map fk

>
> Should I do a separate commit that fixes the HEAD file, or just fix it as
> part of the bug fix I'm working on.
Yes, you should immediately submit a patch to change HEAD to 5689aa52.

>
> BTW, at one point, after having correctly set the HEAD and versions in my new
> migration file, I think I ran neutron-db-manage check_migration, and I think
> it set the HEAD to my version, but it did that in the neutron repo, and not
> the VPN repo.  I might have been running from the wrong repo?
I working on updating the devref docs for this process. Things have changed
quite a bit with the alembic branches in separate repos.

>
>
>
> For my commit, I'm assuming I change the HEAD file to use my
> migration file's version?
>
>
> You can do that manually too, yes.
>  
>
>
> I set HEAD to my migration file, and my file has a down revision of
> the previous head's revision. If I run 'neutron-db-manage
> --config-file ../neutron/etc/neutron.conf --config-file
> ../neutron/etc/neutron/plugins/ml2/ml2_conf.ini check_migration'
> there is no output so I guess that is OK.
>
> As I develop my new migration file, is there a way that I can test it
> (running neutron-db-migration, maybe)?
>
>
> When I test migrations I usually dump the database, run the migration
> with neutron-db-manage upgrade HEAD (I think it's not necessary to
> specify HEAD), and restore the db from the dump if the migration fails.
>  
>
> Is there a way to run the migration file under the debugger, as well
> (importing pdb, for example)?
>
>
> The migration process is just like any python application, so I guess you
> can debug it with pdb. 
>
>
> @PCM Ah, so use "neutron-db-manage upgrade HEAD". That was the piece that was
> missing. I take it there are no specific unit tests of the migration files?
>
>
>  
>
>
> In the migration, I can add the columns needed. What's the best way
> to fill out those fields - using raw SQL queries or create a Session
> object and access the VpnService object's router object?
>
>
> If the default value for the column is not enough, and you need to
> specify a value which depends on other va

Re: [openstack-dev] [neutron] How to handle security issues in external repos?

[Henry Gessau]

Jeremy, a huge thanks for this fantastic reply! I have taken the liberty of
copying your responses directly into Neutron's "contributing" guide:
https://review.openstack.org/187267

I hope you don't mind.

On Fri, Jul 03, 2015, Jeremy Stanley  wrote:
> On 2015-07-03 22:01:38 +0200 (+0200), Henry Gessau wrote:
> [...]
>> The question now arises about what to do when a security issue is
>> found in such an external repository that integrates with Neutron.
>>
>>  - How should such security issues be managed?
> 
> The OpenStack Vulnerability Management Team (VMT) follows a
> documented process[1] which can basically be reused by any
> project-team when needed.
> 
>>  - Should the OpenStack security team be involved?
> 
> The OpenStack VMT directly oversees vulnerability reporting and
> disclosure for a subset[2] of OpenStack source code repositories.
> However we're still quite happy to answer any questions you might
> have about vulnerability management for your own projects even if
> they're not part of that set. Feel free to reach out to us in public
> or in private.
> 
> Also, the VMT is an autonomous subgroup of the much larger OpenStack
> Security project-team[3]. They're a knowledgeable bunch and quite
> responsive if you want to get their opinions or help with
> security-related issues (vulnerabilities or otherwise).
> 
>>  - Does a CVE need to be filed?
> 
> It can vary widely. If a commercial distribution such as Red Hat is
> redistributing a vulnerable version of your software then they may
> assign one anyway even if you don't request one yourself. Or the
> reporter may request one; the reporter may even be affiliated with
> an organization who has already assigned/obtained a CVE before they
> initiate contact with you.
> 
>>  - Do the maintainers need to publish OSSN or equivalent documents?
> 
> OpenStack Security Advisories (OSSA) are official publications of
> the OpenStack VMT and only cover VMT-supported software. OpenStack
> Security Notes (OSSN) are published by editors within the OpenStack
> Security project-team on more general security topics and may even
> cover issues in non-OpenStack software commonly used in conjunction
> with OpenStack, so it's at their discretion as to whether they would
> be able to accommodate a particular issue with an OSSN.
> 
> However, these are all fairly arbitrary labels, and what really
> matters in the grand scheme of things is that vulnerabilities are
> handled seriously, fixed with due urgency and care, and announced
> widely--not just on relevant OpenStack mailing lists but also
> preferably somewhere with broader distribution like the Open Source
> Security mailing list[4]. The goal is to get information on your
> vulnerabilities, mitigating measures and fixes into the hands of the
> people using your software in a timely manner.
> 
>>  - Anything else to consider here?
> [...]
> 
> The OpenStack VMT is in the process of trying to reinvent itself so
> that it can better scale within the context of the "Big Tent." This
> includes making sure our policy/process documentation is more
> consumable and reusable even by project-teams working on software
> outside the scope of our charter. It's a work in progress, and any
> input is welcome on how we can make this function well for everyone.
> 
> [1] https://security.openstack.org/vmt-process.html
> [2] https://wiki.openstack.org/wiki/Security_supported_projects
> [3] http://governance.openstack.org/reference/projects/security.html
> [4] http://oss-security.openwall.org/wiki/mailing-lists/oss-security


__
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] - Proposing Miguel Angel Ajo for the Control Plane core team

[Henry Gessau]

+1!

On Mon, Jul 06, 2015, Kevin Benton  wrote:
> Hello!
> 
> As the Lieutenant of the built-in control plane[1], I am proposing to add
> Miguel Angel Ajo to the control plane core reviewer team.
> 
> His review stats are inline with the other core reviewers[2], and his work on
> improving the stability/performance of the agents over the last year has been
> important in making the reference implementation reliable.
> 
> Existing cores, please vote +1/-1 for his addition to the team. 
> 
> Cheers!
> 
> 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html
> 2. http://stackalytics.com/report/contribution/neutron/30 
> http://stackalytics.com/report/contribution/neutron/60 
> http://stackalytics.com/report/contribution/neutron/90
> 
> -- 
> Kevin Benton


__
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] How to handle security issues in external repos?

[Henry Gessau]

In the Liberty cycle Neutron is mandating the splitting out of "third-party"
plugins and drivers into separate repositories, see [1]. These external
repositories will be managed by the maintainers of the code, who are
independent from the neutron core maintainers.

The question now arises about what to do when a security issue is found in such
an external repository that integrates with Neutron.

 - How should such security issues be managed?
 - Should the OpenStack security team be involved?
 - Does a CVE need to be filed?
 - Do the maintainers need to publish OSSN or equivalent documents?
 - Anything else to consider here?

[1] https://review.openstack.org/187267

__
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] db migration for vendor extensions

[Henry Gessau]

On Thu, Jul 02, 2015, Fawad Khaliq  wrote:
> After Neutron core and vendor code decomposition [1], it was decided to
> keep db migration scripts in Neutron repo. I was wondering if any of the
> networking-* project owners figured out an alternative to this approach
> where DB migration can reside in networking-* repositories instead. As
> far as DB models are concerned, keeping them in networking-* is simple.
> I plan to introduce some extensions and it would ideal if DB migration and
> DB models live out of Neutron repository. 
> 
> Any suggestions for addressing this? Anyone has a working mechanism?

Neutron's "contributing" devref is being updated to include information about
this. Please participate in the review [2] and let us know if there is anything
you feel is missing or if it can be explained better.

[2] https://review.openstack.org/187267


__
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] Proposing Ann Kamyshnikova for the API & DB core reviewer team

[Henry Gessau]

It has been a week and feedback has been positive and supportive of
Ann's nomination.  Welcome to the Neutron DB core reviewer team, Ann.

-- 
Henry

On Thu, Jun 11, 2015, Henry Gessau  wrote:
> As one of the Lieutenants [1] for the API and DB areas under the PTL, I would
> like to propose Ann Kamyshnikova as a member of the Neutron API and DB core
> reviewer team.
> 
> Ann has been a long time contributor in Neutron showing expertise particularly
> in database matters. She has also worked with and contributed code to the
> oslo.db and sqlalchemy/alembic projects. Ann was a critical contributor to the
> Neutron "database healing" effort that was completed in the Juno cycle.
> 
> Her deep knowledge of databases and backends, and her expertise with oslo.db,
> sqlalchemy and alembic will be very important in this area. Ann is a trusted
> member of our community and her review stats [2][3][4] place her comfortably
> with other Neutron core reviewers. She consistently catches database issues
> early when patches are submitted for review, and shows dedication to helping
> developers understand and perfect their database-related changes.
> 
> Existing Neutron core reviewers from the API and DB area of focus, please vote
> +1/-1 for the addition of Ann to the core reviewer team. Specifically, I'm
> looking for votes from Akihiro (co-Lieutenant), Mark, Maru, Armando and Carl.
> 
> 
> [1]
> http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers
> [2]
> https://review.openstack.org/#/q/reviewer:%22Ann+Kamyshnikova+%253Cakamyshnikova%2540mirantis.com%253E%22,n,z
> [3] http://stackalytics.com/report/contribution/neutron-group/90
> [4] http://stackalytics.com/?user_id=akamyshnikova&metric=marks



__
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] Proposing Rossella Sblendido for the Control Plane core team

[Henry Gessau]

A big +1 from me. Rossella is also a great community influence with her "Land
your first patch" for Neutron talk at the Paris summit.

On Fri, Jun 12, 2015, Kevin Benton  wrote:
> Hello!
> 
> As the Lieutenant of the built-in control plane[1], I would like Rossella
> Sblendido to be a member of the control plane core reviewer team.
> 
> Her review stats are in line with other cores[2] and her feedback on patches
> related to the agents has been great. Additionally, she has been working quite
> a bit on the blueprint to restructure the L2 agent code so she is very
> familiar with the agent code and the APIs it leverages.
> 
> Existing cores that have spent time working on the reference implementation
> (agents and AMQP code), please vote +1/-1 for her addition to the team. Aaron,
> Gary, Assaf, Maru, Kyle, Armando, Carl and Oleg; you have all been reviewing
> things in these areas recently so I would like to hear from you specifically.
> 
> 1. 
> http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
> 2. http://stackalytics.com/report/contribution/neutron-group/30
> 
> Cheers
> -- 
> Kevin Benton



__
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] Proposing YAMAMOTO Takashi for the Control Plane core team

[Henry Gessau]

Although I am not on your list I would like to add my +1! Yamamoto shows great
attention to detail in code reviews and frequently finds real issues that were
not spotted by others.

On Thu, Jun 11, 2015, Kevin Benton  wrote:
> Hello all!
> 
> As the Lieutenant of the built-in control plane[1], I would like YAMAMOTO
> Takashi to be a member of the control plane core reviewer team.
> 
> He has been extensively reviewing the entire codebase[2] and his feedback on
> patches related to the reference implementation has been very useful. This
> includes everything ranging from the AMPQ API to OVS flows.
> 
> Existing cores that have spent time working on the reference implementation
> (agents and AMQP code), please vote +1/-1 for his addition to the team. Aaron,
> Gary, Assaf, Maru, Kyle, Armando, Carl and Oleg; you have all been reviewing
> things in these areas recently so I would like to hear from you specifically.
> 
> 1. 
> http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
> 2. http://stackalytics.com/report/contribution/neutron-group/90
> 
> 
> Cheers
> -- 
> Kevin Benton


__
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] Microversioning work questions and kick-start

[Henry Gessau]

On Thu, Jun 11, 2015, Salvatore Orlando  wrote:
> Finally, I received queries from several community members that would be keen
> on helping supporting this microversioning effort. I wonder if the PTL and the
> API lieutenants would ok with agreeing to have a team of developers meeting
> regularly, working towards implementing this feature, and report progress
> and/or issues to the general Neutron meeting.

Yes, I am ok with agreeing to form such a team. ;) With an effort this complex
it makes sense to have tl;dr type summaries in the general meeting. This has
worked well for large-effort features before, and when the work winds down the
topic can fold back into the main meeting.


__
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] Proposing Ann Kamyshnikova for the API & DB core reviewer team

[Henry Gessau]

As one of the Lieutenants [1] for the API and DB areas under the PTL, I would
like to propose Ann Kamyshnikova as a member of the Neutron API and DB core
reviewer team.

Ann has been a long time contributor in Neutron showing expertise particularly
in database matters. She has also worked with and contributed code to the
oslo.db and sqlalchemy/alembic projects. Ann was a critical contributor to the
Neutron "database healing" effort that was completed in the Juno cycle.

Her deep knowledge of databases and backends, and her expertise with oslo.db,
sqlalchemy and alembic will be very important in this area. Ann is a trusted
member of our community and her review stats [2][3][4] place her comfortably
with other Neutron core reviewers. She consistently catches database issues
early when patches are submitted for review, and shows dedication to helping
developers understand and perfect their database-related changes.

Existing Neutron core reviewers from the API and DB area of focus, please vote
+1/-1 for the addition of Ann to the core reviewer team. Specifically, I'm
looking for votes from Akihiro (co-Lieutenant), Mark, Maru, Armando and Carl.


[1]
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers
[2]
https://review.openstack.org/#/q/reviewer:%22Ann+Kamyshnikova+%253Cakamyshnikova%2540mirantis.com%253E%22,n,z
[3] http://stackalytics.com/report/contribution/neutron-group/90
[4] http://stackalytics.com/?user_id=akamyshnikova&metric=marks




__
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] Proposing Brian Haley to Neutron L3 Core Reviewer Team

[Henry Gessau]

+1 Brian will be a great addition for L3

On Wed, Jun 10, 2015, Carl Baldwin  wrote:
> Folks,
> 
> As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to
> propose Brian Haley as a member of the Neutron L3 core reviewer team.
> Brian has been a long time contributor in Neutron showing expertise
> particularly in IPv6, iptables, and Linux kernel matters.  His
> knowledge and involvement will be very important especially in this
> area.  Brian has become a trusted member of our community.  His review
> stats [2][3][4] place him comfortably with other Neutron core
> reviewers.  He regularly runs proposed patches himself and gives
> insightful feedback.  He has shown a lot of interest in the success of
> Neutron.
> 
> Existing Neutron core reviewers from the L3 area of focus, please vote
> +1/-1 for the addition of Brian to the core reviewer team.
> Specifically, I'm looking for votes from Henry, Assaf, and Mark.
> 
> Thanks!
> Carl
> 
> [1] 
> http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers
> [2] 
> https://review.openstack.org/#/q/reviewer:%22Brian+Haley+%253Cbrian.haley%2540hp.com%253E%22,n,z
> [3] http://stackalytics.com/report/contribution/neutron-group/90
> [4] http://stackalytics.com/?user_id=brian-haley&metric=marks
> 
> __
> 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] Proposing Assaf Muller for the Neutron Core Reviewer Team

[Henry Gessau]

+1

On Thu, May 28, 2015, Kyle Mestery  wrote:
> Folks, I'd like to propose Assaf Muller to be a member of the Neutron core
> reviewer team. Assaf has been a long time contributor in Neutron, and he's
> also recently become my testing Lieutenant. His influence and knowledge in
> testing will be critical to the team in Liberty and beyond. In addition to
> that, he's done some fabulous work for Neutron around L3 HA and DVR. Assaf has
> become a trusted member of our community. His review stats place him in the
> pack with the rest of the Neutron core reviewers.
> 
> I'd also like to take this time to remind everyone that reviewing code is a
> responsibility, in Neutron the same as other projects. And core reviewers are
> especially beholden to this responsibility. I'd also like to point out that
> +1/-1 reviews are very useful, and I encourage everyone to continue reviewing
> code even if you are not a core reviewer.
> 
> Existing Neutron cores, please vote +1/-1 for the addition of Assaf to the
> core reviewer team.
> 
> Thanks!
> Kyle
> 
> [1] http://stackalytics.com/report/contribution/neutron-group/180


__
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][DB] neutron DB migration scripts

[Henry Gessau]

On Mon, May 25, 2015, Mike Bayer  wrote:
> On 5/25/15 10:24 AM, Henry Gessau wrote:
>> Yes, unfortunately the autogenerate currently generates commands to 
>> drop all the FWaaS, LBaaS and VPNaaS tables since their models are not 
>> in the neutron tree. You can and should delete all these commands that 
>> are not related to your new models. We have been meaning to fix the 
>> autogeneration so that it handles the *aaS tables correctly, but it is 
>> a little tricky. 
> I'm sure you know this already, but when you do this you should be using 
> the Alembic include_object hook:
> 
> http://alembic.readthedocs.org/en/latest/api.html?highlight=include_object#alembic.environment.EnvironmentContext.configure.params.include_object

I kind of knew about it, but I did not realize that I could hook it into the
env like that. Thanks!

> implementing this function will give you complete control over every 
> object considered by autogenerate.I'm assuming the "tricky" part 
> here has to do with some unpredictability on the part of the Neutron 
> schema.  On the Alembic side it should be straightforward (e.g. there's 
> no need to manipulate the MetaData or anything like that).
> 
> Feel free to point me to a review dealing with this.

https://review.openstack.org/185465


__
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][DB] neutron DB migration scripts

[Henry Gessau]

On Mon, May 25, 2015, Zang, Rui  wrote:
> Greetings,
> 
> Forgive my alembic ignorance. I am writing some vender specific code that 
> wants to create new DB tables for neutron. I have read the 
> neutron/db/migration/README file, but still have something unclear.
> My current understanding is that for DB tables creation, I have to do 
> "something" with neutron/db/migration/ .
> 
> What I have done were:
> - Copied neutron/db/migration/alembic.ini to $my_plugin_directory

Are you sure you needed to do this step? I have never needed to.

> - Ran `neutron-db-manage --config-file /etc/neutron/neutron.conf 
> --config-file $my_plugin_directory/alembic.ini revision -m "my plugin init 
> ops" --autogenerate`. This autogenerate command generated a 
> neutron/db/migrations/alembic_migrations/versions/ 
> ee78798e4af_my_plugin_init_ops.py file. But this file is completely 
> irrelevant with my targeted changes.

Yes, unfortunately the autogenerate currently generates commands to drop all
the FWaaS, LBaaS and VPNaaS tables since their models are not in the neutron
tree. You can and should delete all these commands that are not related to
your new models.

We have been meaning to fix the autogeneration so that it handles the *aaS
tables correctly, but it is a little tricky.

> So I replaced the upgrade() method with the DB table creation code.

If you import your models file in neutron/db/migration/models/head.py then
autogenerate should generate the commands for your schemas (in addition to the
drops for *aaS).

> - Then ran `neutron-db-manager upgrade` to upgrade to  revision ee78798e4af 
> manually, I saw the tables were created.
> 
> So the questions are:
> * there are scripts in neutron/db/migration/alembic_migrations/ that without 
> a revision prefix, like l3_init_ops.py, they are not in the "versions" 
> directory. What are they for?

They are used by the start migration (havana_initial) and some corner cases.
You shouldn't need them.

> * Should I just keep the "ee78798e4af_my_plugin_init_ops.py" file?

Yes, after modifying it so that it contains only commands for your tables.

> Seems the metadata files are no longer usable.

What metadata files?

> * I assume if the revision file ("ee78798e4af_my_plugin_init_ops.py" in my 
> case) is already there before devstack is started, the new tables will be 
> created by devstack as other tables, right?

Yes.

> * Anything what I did wrong or missing?

You were not too far off. I hope my answers helped.

> Thanks,
> Rui Zang 


__
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] [nova][heat] sqlalchemy-migrate tool to alembic

[Henry Gessau]

On Fri, May 15, 2015, Mike Bayer  wrote:
> 
> 
> On 5/15/15 9:31 AM, Doug Hellmann wrote:
>> This seems more complicated than needed. If we just stop writing the
>> sqlalchemy-migrate scripts and don't change them, then for 1 cycle we
>> have to run both sets of migrations and after that we can just run
>> alembic.
> Then we have a forever-in-perpetuity dependency on SQLAlchemy-Migrate 
> which must be maintained forever for to maintain compatibility with all 
> new SQLAlchemy, oslo.db, etc. releases, despite it never being used for 
> anythine new, because it will be impossible to install an Openstack 
> application without running through the first set of migrate scripts first.
> 
> The SQLAlchemy-Migrate dependency must be dropped and the project has to 
> be EOL'ed at some point.   Leaving it in is definitely the more 
> complicated alternative.

Neutron has used alembic since its birth (Folsom release), but during the Juno
cycle we consolidated all the Folsom to Havana migrations into one
"havana_initial" migration. That is now the start migration for Neutron.

Nova should be able to do something similar in a cycle or two: setting
liberty_initial as the start migration with no legacy before it.


__
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] Extending database schema from 3rd-party plugin

[Henry Gessau]

Note: I missed this email because Neutron was misspelled in the subject. I
have corrected it for this message.

On Tue, May 12, 2015, Alexey I. Froloff  wrote:
> I am developing ML2 type/mech plugin for some very special
> environment.  Because this environment is very special (using
> addressing based on physical hypervisor location), it will be
> separate package, I don't plan to alter Neutron code.  And this
> plugin needs to store some information in Neutron database.  Not
> altering existing tables, but adding couple.
> 
> I'm not very good with alembic (better say not good at all),
> maybe someone can enlight me, if this possible at all and how to
> make it with minimal damage.  I am writing this plugin for Kilo
> release, and this installation is supposed to be further updated
> to next OpenStack releases.

Alembic supports migration branches. The advanced services (FW/LB/VPNaaS) have
separate migration branches for their own tables. Unfortunately neutron's
alembic script is hard-coded to only support these three external services for
now. I hope to work on a more pluggable framework in the future.

For Kilo you could try to monkeypatch neutron's script to support your
plugin's migration. Or you can try to do something like the group-based-policy
project does, by consuming the neutron migration script[1]. (GBP also has its
own migration branch.)

Find me on IRC as HenryG and I will try to help you get more familiar with
alembic and neutron's migrations.

[1]
https://github.com/stackforge/group-based-policy/blob/master/gbpservice/neutron/db/migration/cli.py


__
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] [doc] what's happened to api documents?

[Henry Gessau]

On Mon, Apr 13, 2015, henry hly  wrote:
> http://developer.openstack.org/api-ref-networking-v2.html
> 
> The above api document seems lost most of the content, leaving only
> port, network, subnet?

In the navigation bar on the left there is a link to the rest of the Neutron
API, which is implemented as extensions:
http://developer.openstack.org/api-ref-networking-v2-ext.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] Proposal to add Ihar Hrachyshka as a Neutron Core Reviewer

[Henry Gessau]

+1 !!!

On Wed, Mar 04, 2015, Kyle Mestery  wrote:
> I'd like to propose that we add Ihar Hrachyshka to the Neutron core reviewer
> team. Ihar has been doing a great job reviewing in Neutron as evidence by his
> stats [1]. Ihar is the Oslo liaison for Neutron, he's been doing a great job
> keeping Neutron current there. He's already a critical reviewer for all the
> Neutron repositories. In addition, he's a stable maintainer. Ihar makes
> himself available in IRC, and has done a great job working with the entire
> Neutron team. His reviews are thoughtful and he really takes time to work with
> code submitters to ensure his feedback is addressed.
> 
> I'd also like to again remind everyone that reviewing code is a
> responsibility, in Neutron the same as other projects. And core reviewers are
> especially beholden to this responsibility. I'd also like to point out and
> reinforce that +1/-1 reviews are super useful, and I encourage everyone to
> continue reviewing code across Neutron as well as the other OpenStack
> projects, regardless of your status as a core reviewer on these projects.
> 
> Existing Neutron cores, please vote +1/-1 on this proposal to add Ihar to the
> core reviewer team.
> 
> Thanks!
> Kyle
> 
> [1] http://stackalytics.com/report/contribution/neutron-group/90



__
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] New version of python-neutronclient release: 2.3.11

[Henry Gessau]

The fix: https://review.openstack.org/157606

On Thu, Feb 19, 2015, Joe Gordon  wrote:
> neutronclient is requiring a keystone client that is way too new for icehouse.
> 2.3.11 was released (And breaks with semver), but icehouse has a limit
> of <2.4. So global-requirements for icehouse needs to be fixed.
> 
> 2015-02-19 22:21:21.419 
> 
>  | ERROR: openstackclient.shell Exception raised: (python-keystoneclient 
> 0.11.2 (/usr/local/lib/python2.7/dist-packages), 
> Requirement.parse('python-keystoneclient>=1.1.0'), 
> set(['python-neutronclient']))
> 
> 
> Note: I am not pushing the patch to fix this myself, we need more people who
> are able to monitor and fix these types of issues.
> 
> 
> On Thu, Feb 19, 2015 at 3:35 PM, Joe Gordon  > wrote:
> 
> And this just broke icehouse jobs. Which means devstack-gate is broken.
> 
> 
> http://logs.openstack.org/53/157553/1/check/check-tempest-dsvm-full-icehouse/6c63b71//logs/devstacklog.txt.gz#_2015-02-19_22_21_21_419
> 
> http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt?h=stable/icehouse#n89
> 
> On Thu, Feb 19, 2015 at 1:35 PM, Kyle Mestery  > wrote:
> 
> The Neutron team is proud to announce the release of the latest
> version of python-neutronclient. This release includes the following
> bug fixes and improvements:
> 
> 3e5c6ba Updated from global requirements
> a774e84 Add unit tests for agentscheduler related commands
> 069b14c Fix for incorrect parameter in user-id error message in 
> shell.py
> 57adb7f Fix CSV formatting of fixed_ips field in port-list command
> 0be3b62 Implement LBaaS object model v2
> 3d6769c Fix typo in test_cli20_agentschedulers filename
> e1633ed Add ip_version to extra dhcp opts
> 59d7564 Skip None id when getting security_group_ids
> 6f7cd14 Reverse order of tests to avoid incompatibility
> b0923a3 Utility method for boolean argument
> 68fc402 Split base function of v2_0.Client into a separate class
> 2dce00b Updated from global requirements
> 51d2a23 Add parser options for port-update and port-create
> 5b1c45a Add floating-ip-address to floatingip-create
> 845f461 Fix KeyError when filtering SG rule listing
> 30bd81c Updated from global requirements
> 86fede6 Remove unreachable code from test_cli20 class
> cb5d462 Parse provider network attributes in net_create
> 78b6310 Parameter support both id and name
> 096fd1b Add '--router:external' option to 'net-create'
> aed3faf Fix TypeError for six.text_type
> d6e40b5 Add Python 3 classifiers
> 4fa57fe Namespace of arguments is incorrectly used
> 4beadef Fix True/False to accept Camel and Lower case
> 799e288 Use adapter from keystoneclient
> 5822d61 Use requests_mock instead of mox
> 4b181cd Updated from global requirements
> 04a0ec8 firewall policy update for a rule is not working
> 0560f85 Fix columns setup base on csv formatter
> 187c36c Correct the bash completion of CLI
> 2f23623 Workflow documentation is now in infra-manual
> 62063c1 Fix issues with Unicode compatibility for Py3
> 
> For more details on the release, please see the git log history in the
> release notes in the LP page here:
> 
> https://launchpad.net/python-neutronclient/+milestone/2.3.11
> 
> Please report any bugs in LP.
> 
> Thanks!
> Kyle
> 
> 
> __
> 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] Changes to the core team

[Henry Gessau]

On Thu, Jan 15, 2015, Kyle Mestery  wrote:
> As part of the change, I'd like to propose Doug Wiegley as a new Neutron core
> reviewer. Doug has been actively reviewing code across not only all the
> Neutron projects, but also other projects such as infra. His help and work in
> the services split in December were the reason we were so successful in making
> that happen. Doug has also been instrumental in the Neutron LBaaS V2 rollout,
> as well as helping to merge code in the other neutron service repositories.

+1 for 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] UniqueConstraint for name and tenant_id in security group

[Henry Gessau]

On Thu, Dec 11, 2014, Mark McClain  wrote:
> 
>> On Dec 11, 2014, at 8:43 AM, Jay Pipes > > wrote:
>>
>> I'm generally in favor of making name attributes opaque, utf-8 strings that
>> are entirely user-defined and have no constraints on them. I consider the
>> name to be just a tag that the user places on some resource. It is the
>> resource's ID that is unique.
>>
>> I do realize that Nova takes a different approach to *some* resources,
>> including the security group name.
>>
>> End of the day, it's probably just a personal preference whether names
>> should be unique to a tenant/user or not.
>>
>> Maru had asked me my opinion on whether names should be unique and I
>> answered my personal opinion that no, they should not be, and if Neutron
>> needed to ensure that there was one and only one default security group for
>> a tenant, that a way to accomplish such a thing in a race-free way, without
>> use of SELECT FOR UPDATE, was to use the approach I put into the pastebin on
>> the review above.
>>
> 
> I agree with Jay.  We should not care about how a user names the resource.
>  There other ways to prevent this race and Jay’s suggestion is a good one.

However we should open a bug against Horizon because the user experience there
is terrible with duplicate security group names.


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

Re: [openstack-dev] [Neutron] IPv6 team summit meetup

[Henry Gessau]

Count me in.

On 11/6/2014 4:18 PM, Xuhan Peng wrote:
> Hey, 
>
> Since we don't have any slot for ipv6 in summit to meet up, can we have a
> lunch meetup together tomorrow (11/7 Friday)?
>
> We can meet at 12:30 at the meet up place Neuilly lobby of Le Meridien and
> go to lunch together after that.
>
> Xu Han 
>

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

[openstack-dev] [Neutron] Proposing to disallow updates of IPv6 attributes on subnets

[Henry Gessau]

A number of bugs[1][2][3] have been filed which are related to updating the
IPv6 attributes after a subnet has been created.

In the reviews[4][5] for the fixes for [1] and [2] some shortcomings and
questions have been raised, which were discussed in today's IPv6 IRC meeting[6].

Summary:
In Juno we are not ready for allowing the IPv6 attributes on a subnet to be
updated after the subnet is created, because:
- The implementation for supporting updates is incomplete.
- Perceived lack of usefulness, no good use cases known yet.
- Allowing updates causes more complexity in the code.
- Have not tested that radvd, dhcp, etc. behave OK after update.

Therefore we are proposing to change 'allow_put' to False for the two IPv6
attributes, ipv6_ra_mode and ipv6_address_mode. This will prevent the modes
from being updated via the PUT:subnets API.

We would be interested to hear of any disagreements or questions.


[1] https://launchpad.net/bugs/1362966
[2] https://launchpad.net/bugs/1363064
[3] https://launchpad.net/bugs/1373417
[4] https://review.openstack.org/125328
[5] https://review.openstack.org/117799
[6]
http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-10-07-15.01.log.html

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

Re: [openstack-dev] [Group-based Policy] Database migration chain

[Henry Gessau]

Clint Byrum  wrote:
> 
> Excerpts from Mike Bayer's message of 2014-10-04 08:10:38 -0700:
>>
>> On Oct 4, 2014, at 1:10 AM, Kevin Benton  wrote:
>>
>>> Does sqlalchemy have good support for cross-database foreign keys? I was 
>>> under the impression that they cannot be implemented with the normal syntax 
>>> and semantics of an intra-database foreign-key constraint. 
>>
>> cross “database” is not typically portable, but cross “schema” is.   
>>
>> different database vendors have different notions of “databases” or 
>> “schemas”.
>>
>> if you can get the “other database” to be accessible from the target 
>> database via “otherdatabase.sometable”, then you’re in.
>>
>> from SQLAlchemy’s perspective, it’s just a name with a dot.   It’s the 
>> database itself that has to support the foreign key at the scope you are 
>> shooting for.
>>
> 
> All true, however, there are zero guarantees that databases will be
> hosted on the same server, and typically permissions are setup to prevent
> cross-schema joins.

I believe Group-based Policy (which this thread is about) will use the Neutron
database configuration for its dependent database.

If Neutron is configured for:
  connection = mysql://user:pass@locationX:3306/neutron
then GBP would use:
  connection = mysql://user:pass@locationX:3306/neutron_gbp

> Typically we use the public API's when we want to access data in a
> different application. The database is a private implementation detail
> of each application.

Currently GPB is very tightly coupled to Neutron.


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

[openstack-dev] [Neutron] IPv6 bug fixes that would be nice to have in Juno

[Henry Gessau]

There are some fixes for IPv6 bugs that unfortunately missed the RC1 cut.
These bugs are quite important for IPv6 users and therefore I would like to
lobby for getting them into a possible RC2 of Neutron Juno.

These are low-risk fixes that would not jeopardize the stability of Neutron.

1. Network:dhcp port is not assigned EUI64 IPv6 address for SLAAC subnet
Bug: https://bugs.launchpad.net/neutron/+bug/1330826
Fix: https://review.openstack.org/101433

2. Cannot set only one of IPv6 attributes while second is None
Bug: https://bugs.launchpad.net/neutron/+bug/1363064
Fix: https://review.openstack.org/117799

The third one will probably not be allowed since it requires a string freeze
exception, but I will mention it anyway ...

3. IPv6 slaac is broken when subnet is less than /64
Bug: https://bugs.launchpad.net/neutron/+bug/1357084
Fix: https://review.openstack.org/116525

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

Re: [openstack-dev] [Neutron][LBaaS] Migrations in feature branch

[Henry Gessau]

Eugene Nikanorov  wrote:
> Hi neutron and lbaas folks.
> 
> Recently I briefly looked at one of lbaas proposed into feature branch.
> I see migration IDs there are lined into a general migration sequence.
> 
> I think something is definitely wrong with this approach as feature-branch
> components are optional, and also master branch can't depend on revision IDs 
> in
> feature-branch (as we moved to unconditional migrations)
> 
> So far the solution to this problem that I see is to have separate migration
> script, or in fact, separate revision sequence. The problem is that DB models
> in feature branch may depend on models of master branch, which means that each
> revision of feature-branch should have a kind of "minimum required" revision
> of the master branch.
> The problem that revision IDs don't form linear order, so we can't have
> 'minimum' unless that separate migration script may analyze master branch
> migration sequence and find minimum required migration ID.
> 
> Thoughts?

Here is my thought. Others may have better ideas.

In the feature branch maintain just one migration. Call it lbaasv2.
This migration is all the schema differences from master's head.

The lbaasv2 migration must be moved to after master's head every time the head
gets updated by a sync from master.

Every time some DB changes occur in the feature branch, update the lbaasv2
migration with the changes. (Do not create a new migration.)

When it's time to promote the feature to neutron master, the lbaasv2 migration
will integrate with the master timeline.


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

[openstack-dev] [Neutron][db] End of meetings for neutron-db

[Henry Gessau]

https://wiki.openstack.org/wiki/Meetings/NeutronDB

The work on healing and reorganizing Neutron DB migrations is complete, and so
we will no longer hold meetings.

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

Re: [openstack-dev] [all] Design Summit reloaded

[Henry Gessau]

On 8/27/2014 8:51 AM, Thierry Carrez wrote:
> better use of our 4 days

Will the design space be available on the fifth day too?

No need to schedule anything on that day ("Day 0"), but having the space
available would be nice for ad hoc gatherings.


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

Re: [openstack-dev] [neutron][cisco] Cisco Nexus requires patched ncclient

[Henry Gessau]

Ihar Hrachyshka  wrote:
> Now, maybe putting the module into requirements.txt is an overkill
> (though I doubt it). In that case, we could be interested in getting
> the info in some other centralized way.

Maru is of the opinion that it is overkill. I feel the same way, but I am not
involved much with deployment issues so my feelings should not sway anyone.

Note that ncclient is not the only package used by vendor solutions that is
not listed in requirements.txt. The ones I am aware of are:

  ncclient (cisco and brocade)
  heleosapi (embrane)
  a10_neutron_lbaas (a10networks)

Maybe we should start exploring "some other centralized way" to list these
type of dependencies?


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

Re: [openstack-dev] [neutron] [third-party] Cisco NXOS is not tested anymore

[Henry Gessau]

On 8/12/2014 2:04 PM, Jeremy Stanley wrote:
> On 2014-08-12 16:35:18 + (+), Edgar Magana wrote:
>> If this plugin will be deprecated in Juno it means that the code
>> will be there for this release, I will expect to have the CI still
>> running for until the code is completely removed from the Neutron
>> tree.
>>
>> Anyway, Infra guys will have the last word here!
> 
> It's really not up to the Project Infrastructure Team to decide
> this (we merely provide guidance, assistance and, sometimes,
> arbitration for such matters). It's ultimately the Neutron developer
> community who needs to determine whether they're willing to support
> an untested feature through deprecation or insist on continued
> testing until its full removal can be realized.

The Cisco Nexus sub-plugin is broken because the OVS plugin that is depends on
is broken. The Neutron Project switched from the OVS plugin to ML2 for testing
a long time ago, and the OVS plugin will be removed from the tree in Juno.
There are no plans to fix the OVS plugin, so the Cisco Nexus sub-plugin will
not be fixed either.

There are bugs[1,2] open to remove the deprecated plugins from the tree.

[1] https://bugs.launchpad.net/neutron/+bug/1323729
[2] https://bugs.launchpad.net/neutron/+bug/1350387


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

Re: [openstack-dev] [neutron][cisco] Cisco Nexus requires patched ncclient

[Henry Gessau]

On 8/12/2014 1:53 PM, Ihar Hrachyshka wrote:
> On 12/08/14 17:12, Henry Gessau wrote:
>> On 8/12/2014 10:27 AM, Ihar Hrachyshka wrote:
>>> as per [1], Cisco Nexus ML2 plugin requires a patched version of 
>>> ncclient from github. I wonder:
>>>
>>> - - whether this information is still current;
>>
>> Please see: https://review.openstack.org/112175
>>
>> But we need to do backports before updating the wiki.
> 
> Thanks for the link!
> 
>>
>>> - - why don't we depend on ncclient thru our requirements.txt
>>> file.
>>
>> Do we want to have requirements on things that are only used by a
>> specific vendor plugin? So far it has worked by vendor-specific
>> documentation instructing to manually install the requirement, or
>> vendor-tailored deployment tools/scripts.
>>
> 
> In downstream, it's hard to maintain all plugin dependencies if they
> are not explicitly mentioned in e.g. requirements.txt. Red Hat ships
> those plugins (with no commercial support or testing done on our
> side), and we didn't know that to make the plugin actually useable, we
> need to install that ncclient module until a person from Cisco
> reported the issue to us. We don't usually monitor random wiki pages
> to get an idea what we need to package and depend on. :)
> 
> I think we should have every third party module that we directly use
> in requirements.txt. We have code in the tree that imports ncclient
> (btw is it unit tested?), so I think it's enough to make that

The unit tests mock the import of ncclient.

> dependency explicit.
> 
> Now, maybe putting the module into requirements.txt is an overkill
> (though I doubt it). In that case, we could be interested in getting
> the info in some other centralized way.

I am not familiar with "other ways", but let me know if I can be of any help.

Note: it seems that the Brocade plugin also imports ncclient.


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

Re: [openstack-dev] [neutron][cisco] Cisco Nexus requires patched ncclient

[Henry Gessau]

On 8/12/2014 10:27 AM, Ihar Hrachyshka wrote:
> as per [1], Cisco Nexus ML2 plugin requires a patched version of
> ncclient from github. I wonder:
> 
> - - whether this information is still current;

Please see:
https://review.openstack.org/112175

But we need to do backports before updating the wiki.

> - - why don't we depend on ncclient thru our requirements.txt file.

Do we want to have requirements on things that are only used by a specific
vendor plugin? So far it has worked by vendor-specific documentation
instructing to manually install the requirement, or vendor-tailored deployment
tools/scripts.

> 
> [1]: https://wiki.openstack.org/wiki/Neutron/ML2/MechCiscoNexus


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

Re: [openstack-dev] [neutron] [third-party] Cisco NXOS is not tested anymore

[Henry Gessau]

On 8/11/2014 7:56 PM, Anita Kuno wrote:
> On 08/11/2014 05:46 PM, Henry Gessau wrote:
>> Anita Kuno  wrote:
>>> On 08/11/2014 05:05 PM, Edgar Magana wrote:
>>>> Cisco Folks,
>>>>
>>>> I don't see the CI for Cisco NX-OS anymore. Is this being deprecated?
>>>>
>>> I don't ever recall seeing that as a name of a third party gerrit
>>> account in my list[0], Edgar.
>>>
>>> Do you happen to have a link to a patchset that has that name attached
>>> to a comment?
>>
>> The "Cisco Neutron CI" tests at least five different configurations. By
>> "NX-OS" Edgar is referring to the Cisco Nexus switch configurations. The CI
>> used to run both the "monolithic_nexus" and "ml2_nexus" configurations, but
>> the monolithic cisco plugin for nexus is being deprecated for juno and its
>> configuration has already been removed from testing.
>>
> Thanks Henry:
> 
> Do we have a url for patch in gerrit for this or was this an internal
> code change?

This was a change only in the internal 3rd party Jenkins/Zuul settings.


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

Re: [openstack-dev] [neutron] [third-party] Cisco NXOS is not tested anymore

[Henry Gessau]

Anita Kuno  wrote:
> On 08/11/2014 05:05 PM, Edgar Magana wrote:
>> Cisco Folks,
>>
>> I don't see the CI for Cisco NX-OS anymore. Is this being deprecated?
>>
> I don't ever recall seeing that as a name of a third party gerrit
> account in my list[0], Edgar.
> 
> Do you happen to have a link to a patchset that has that name attached
> to a comment?

The "Cisco Neutron CI" tests at least five different configurations. By
"NX-OS" Edgar is referring to the Cisco Nexus switch configurations. The CI
used to run both the "monolithic_nexus" and "ml2_nexus" configurations, but
the monolithic cisco plugin for nexus is being deprecated for juno and its
configuration has already been removed from testing.


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

Re: [openstack-dev] [Neutron] Addressing unit tests broken by random PYTHONHASHSEED

[Henry Gessau]

Salvatore Orlando  wrote:
> Hi Henry,
> 
> Are the fixes pushed with patches [1], and [2], which amend tox.ini, 
> insufficient?
> 
> Salvatore
> 
> [1] https://review.openstack.org/#/c/109888/

This is for functional tests, not unit tests. Subtle difference. :)

> [2] https://review.openstack.org/#/c/109729/

This masks the errors by brute-forcing the hash to zero, which preserves
current behaviour. If we want to (and we do, eventually) remove this
work-around, then we need to fix all the broken test cases. The etherpad has
all the details.

> 
> 
> On 4 August 2014 20:42, Henry Gessau  <mailto:ges...@cisco.com>> wrote:
> 
> Please see this bug:  https://launchpad.net/bugs/1348818
> 
> I innocently assigned myself to this bug for Neutron. However, there are a
> very large number of Neutron unit tests that are broken by random hash 
> seeds.
> I think multiple people should work on fixing the tests.
> 
> We don't want to have multiple people doing the same fixes 
> simultaneously, so
> I have created an etherpad[1] to list the broken tests and allow people to
> sign up for fixing them. Please read the instructions carefully.
> 
> This is not urgent work for Neutron for Juno. Please prioritize other work
> first. However, there are several "low-hanging-fruit" fixes in the list, 
> which
> may be good for new developers. Some of them are not so trivial though, 
> so be
> careful.
> 
> [1] https://etherpad.openstack.org/p/neutron-random-hashseed
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org 
> <mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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