Re: [openstack-dev] [taas] rocky

[Takashi Yamamoto]

i've just created 4.0.0 and rocky branch.


On Wed, Sep 26, 2018 at 6:55 PM Takashi Yamamoto  wrote:
>
> hi,
>
> it seems we forgot to create rocky branch.
> i'll make a release and the branch sooner or later, unless someone
> beat me to do so.

__
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][stadium][networking] Seeking proposals for non-voting Stadium projects in Neutron check queue

[Takashi Yamamoto]

hi,

what kind of jobs should it be?  eg. unit tests, tempest, etc...
On Sun, Sep 30, 2018 at 9:43 AM Miguel Lavalle  wrote:
>
> Dear networking Stackers,
>
> During the recent PTG in Denver, we discussed measures to prevent patches 
> merged in the Neutron repo breaking Stadium and related networking projects 
> in general. We decided to implement the following:
>
> 1) For Stadium projects, we want to add non-voting jobs to the Neutron check 
> queue
> 2) For non stadium projects, we are inviting them to add 3rd party CI jobs
>
> The next step is for each project to propose the jobs that they want to run 
> against Neutron patches.
>
> Best regards
>
> Miguel
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack 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] [taas] rocky

[Takashi Yamamoto]

hi,

it seems we forgot to create rocky branch.
i'll make a release and the branch sooner or later, unless someone
beat me to do so.

__
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] tox-siblings alternative for local testing

[Takashi Yamamoto]

hi,

after a recent change [1] ,
neutron-fwaas' unit tests need an unreleased version of neutron.
(the one including the corresponding change [2])
while it's handled by tox-siblings on the gate,
it requires extra steps if you want to run the tests locally.

is there any preferred solution for this?
i guess the simplest solution is to make an intermediate release of neutron
and publish it on pypi.  i wonder if it's acceptable or not.

[1] https://review.openstack.org/#/c/596971/
[2] https://review.openstack.org/#/c/586525/

__
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] [taas] cancel the weekly meeting officially

[Takashi Yamamoto]

hi,

please see https://review.openstack.org/#/c/578328/ and comment on it
if you have any opinions.  thank you.

__
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] Bug deputy report

[Takashi Yamamoto]

hi,

Here's a report of my week.
I will not attend the neutron meeting due to an overlapping schedule. (sorry!)

Issues I failed to triage.  Needs a help from someone familiar with DVR.
https://bugs.launchpad.net/neutron/+bug/1783470 get_subnet_for_dvr
returns SNAT mac instead of gateway in subnet_info
https://bugs.launchpad.net/neutron/+bug/1783654 DVR process flow not
installed on physical bridge for shared tenant network

Critical
none

High
https://bugs.launchpad.net/neutron/+bug/1783306 Invalid auth url

Medium
https://bugs.launchpad.net/neutron/+bug/1782421
https://bugs.launchpad.net/neutron/+bug/1782421
https://bugs.launchpad.net/neutron/+bug/1780453 openvswitch-agent
doesn't try to rebind "binding_failed" ports on startup anymore
https://bugs.launchpad.net/neutron/+bug/1783908 dnsmasq does not
remove leases for deleted VMs - leases and host files point to
different MACS
https://bugs.launchpad.net/neutron/+bug/1783965 Openvswtich agent
break the existing data plane as not stable server
https://bugs.launchpad.net/neutron/+bug/1783968 ovs agent failed to
continue to process devices if one of them are failed
https://bugs.launchpad.net/neutron/+bug/1783378 Following protocol 73
name change , neutron constants have to be updated too
https://bugs.launchpad.net/neutron/+bug/1780883 FWAAS V1： Add or
remove firewall rules, caused the status of associated firewall
becomes "PENDING_UPDATE"
https://bugs.launchpad.net/neutron/+bug/1784006 Instances miss neutron
QoS on their ports after unrescue and soft reboot

Incomplete
https://bugs.launchpad.net/neutron/+bug/1781372 Neutron security group
resource logging presents in ovs-agent.log
https://bugs.launchpad.net/neutron/+bug/1783261
Neutron-LBaaS v2: create loadbalance of 5 listeners, and add members
to each pool, cost about 1 hour
https://bugs.launchpad.net/neutron/+bug/1779334 neutron-vpnaas doesn't
support local tox targets
https://bugs.launchpad.net/neutron/+bug/1779194 neutron-lbaas haproxy
agent, when configured with allow_automatic_lbaas_agent_failover =
True, after failover, when the failed agent restarts or reconnects to
RabbitMQ, it tries to unplug the vif port without checking if it is
used by other agent
https://bugs.launchpad.net/neutron/+bug/1778735 floatingip not found
404 PecanNotFound
https://bugs.launchpad.net/neutron/+bug/1783330 Logging - Error
message is not correct in creating network log with incorrect
'resource_type'
https://bugs.launchpad.net/neutron/+bug/1780407 There are some errors
in neutron_l3_agent and neutron_dhcp_agent after restarting open
vswitch with dpdk
https://bugs.launchpad.net/neutron/+bug/1784342 AttributeError:
'Subnet' object has no attribute '_obj_network_id'

Duplicate
https://bugs.launchpad.net/neutron/+bug/1783534 Install and configure
OpenStack Neutron for Ubuntu

For those who read this boring mail up to here:
https://review.openstack.org/#/c/586488/ Bug deputy routines for dummies

__
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] [taas] LP project changes

[Takashi Yamamoto]

i went through existing bugs and prioritized them.
i'd recommend the others to do the same. there are not too many of them.

i also updated series and milestones.

On Mon, Jul 2, 2018 at 7:02 PM, Takashi Yamamoto  wrote:
> hi,
>
> I created a LP team "tap-as-a-service-drivers",
> whose initial members are same as the existing tap-as-a-service-core
> group on gerrit.
> I made the team the Maintainer and Driver of the tap-as-a-service project.
> This way, someone in the team can take it over even if I disappeared
> suddenly. :-)

__
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 review

[Takashi Yamamoto]

hi,

On Thu, Jul 12, 2018 at 6:13 PM, Tony Breeds  wrote:
> On Thu, Jul 12, 2018 at 03:53:22PM +0900, Takashi Yamamoto wrote:
>> hi,
>>
>> queens branch of networking-midonet has had no changes merged since
>> its creation.
>> the following commit would tell you how many gate blockers have been
>> accumulated.
>> https://review.openstack.org/#/c/572242/
>>
>> it seems the stable team doesn't have a bandwidth to review subprojects
>> in a timely manner.
>
> The project specific stable team is responsible for reviewing those
> changes.  The global stable team will review project specific changes
> if they're requested to.  I'll treat this email as such a request.
>
> Please ask a member of neutron-stable-maint[1] to take a look at your
> review.

i was talking about neutron stable team. nothing about the global stable team.
sorry if it was confusing.

>
>> i'm afraid that we need some policy changes.
>
> No we need more contributors to stable and extended maintenance periods.
> This is not a new problem, and one we're trying to correct.

actually it is a new problem. at least worse than before.

>
> Yours Tony.
>
> [1] https://review.openstack.org/#/admin/groups/539,members
>
> __
> 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] Stable review

[Takashi Yamamoto]

hi,

queens branch of networking-midonet has had no changes merged since
its creation.
the following commit would tell you how many gate blockers have been
accumulated.
https://review.openstack.org/#/c/572242/

it seems the stable team doesn't have a bandwidth to review subprojects
in a timely manner. i'm afraid that we need some policy changes.

__
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] autodoc and tox-siblings

[Takashi Yamamoto]

hi,

- networking-midonet uses autodoc in their doc.
build-openstack-sphinx-docs runs it.
- build-openstack-sphinx-docs doesn't use tox-siblings. thus the job
uses released versions of dependencies. eg. neutron, neutron-XXXaas,
os-vif, etc
- released versions of dependencies and networking-midonet master are
not necessarily compatible
- a consequence: https://bugs.launchpad.net/networking-midonet/+bug/1779801
  (in this case, neutron-lib and neutron are not compatible)

possible solutions i can think of:
- stop using autodoc (i suspect i have to do this for now)
- make intermediate releases of neutron and friends
- finish neutron-lib work and stop importing neutron etc (ideal but we
have not reached this stage yet)
- make doc job use tox-siblings (as it used to do in tox_install era)

any suggestions?

__
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] [taas] LP project changes

[Takashi Yamamoto]

hi,

I created a LP team "tap-as-a-service-drivers",
whose initial members are same as the existing tap-as-a-service-core
group on gerrit.
I made the team the Maintainer and Driver of the tap-as-a-service project.
This way, someone in the team can take it over even if I disappeared
suddenly. :-)

__
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][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Takashi Yamamoto]

On Tue, Jun 26, 2018 at 10:13 PM, Doug Hellmann  wrote:
> Excerpts from Lance Bragstad's message of 2018-06-25 22:51:37 -0500:
>> Thanks a bunch for digging into this, Tony. I'll follow up with the
>> oauthlib maintainers and see if they'd be interested in these changes
>> upstream. If so, I can chip away at it. For now we'll have to settle for
>> not treating warnings as errors to unblock our documentation gate [0].
>>
>> [0] https://review.openstack.org/#/c/577974/
>
> How are docstrings from a third-party library making their way into the
> keystone docs and breaking the build?

in the same way that docstrings from os-vif affect networking-midonet docs.
i.e. via class inheritance

>
> Doug
>
>>
>> On 06/25/2018 07:27 PM, Tony Breeds wrote:
>> > On Mon, Jun 25, 2018 at 05:42:00PM -0500, Lance Bragstad wrote:
>> >> Keystone is hitting this, too [0]. I attempted the same solution that
>> >> Tony posted, but no luck. I've even gone so far as removing every
>> >> comment from the module to see if that helps narrow down the problem
>> >> area, but sphinx still trips. The output from the error message isn't
>> >> very descriptive either. Has anyone else had issues fixing this for
>> >> python comments, not just docstrings?
>> >>
>> >> [0] https://bugs.launchpad.net/keystone/+bug/1778603
>> > I did a little digging for the keystone problem and it's due to a
>> > missing ':' in
>> > https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth1/rfc5849/request_validator.py#L819-L820
>> >
>> > So the correct way to fix this is to correct that in oauthlib, get it
>> > released and use that.
>> >
>> > I hit additional problems in that enabling -W in oauthlib, to pevent
>> > this happening in the future, lead me down a rabbit hole I don't really
>> > have cycles to dig out of.
>> >
>> > Here's a dump of where I got to[1].  Clearly it mixes "fixes" with
>> > debugging but it isn't too hard to reproduce and someone that knows more
>> > Sphinx will be able to understand the errors better than I can.
>> >
>> >
>> > [1] http://paste.openstack.org/show/724271/
>> >
>> > Yours Tony.
>> >
>> >
>> > __
>> > 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] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Takashi Yamamoto]

On Thu, Jun 21, 2018 at 12:13 PM, Tony Breeds  wrote:
> On Wed, Jun 20, 2018 at 08:54:56PM +0900, Takashi Yamamoto wrote:
>
>> do you have a plan to submit these changes on gerrit?
>
> I didn't but I have now:
>
>  * https://review.openstack.org/577028
>  * https://review.openstack.org/577029
>
> Feel free to edit/test as you like.

thank you!

>
> Yours Tony.
>
> __
> 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] Ports port_binding attribute is changing to an iterable

[Takashi Yamamoto]

hi,

On Thu, Jun 7, 2018 at 4:32 AM, Miguel Lavalle  wrote:
> Dear OpenStack Networking community of projects,
>
> As part of the implementation of multiple port bindings in the Neutron
> reference implementation
> (https://specs.openstack.org/openstack/neutron-specs/specs/backlog/pike/portbinding_information_for_nova.html),
> the port_binding relationship in the Port DB model is changing to be an
> iterable:
>
> https://review.openstack.org/#/c/414251/66/neutron/plugins/ml2/models.py@64
>
> and its name is being changed to port_bindings:
>
> https://review.openstack.org/#/c/571041/4/neutron/plugins/ml2/models.py@61
>
> Corresponding changes are being made to the Port Oslo Versioned Object:
>
> https://review.openstack.org/#/c/414251/66/neutron/objects/ports.py@285
> https://review.openstack.org/#/c/571041/4/neutron/objects/ports.py@285
>
> I did my best to find usages of these attributes in the Neutron Stadium
> projects and only found them in networking-odl:
> https://review.openstack.org/#/c/572212/2/networking_odl/ml2/mech_driver.py.
> These are the other projects that I checked:
>
> networking-midonet
> networking-ovn
> networking-bagpipe
> networking-bgpvpn
> neutron-dynamic-routing
> neutron-fwaas
> neutron-vpnaas
> networking-sfc
>
> I STRONGLY ENCOURAGE these projects teams to double check and see if you
> might be affected. I also encourage projects in the broader OpenStack
> Networking community of projects to check for possible impacts. We will be
> holding these two patches until June 14th before merging them.

i checked the following projects. they looked ok.

networking-midonet
networking-ovn
neutron-vpnaas
tap-as-a-service

>
> If you need help dealing with the change, please ping me in the Neutron
> channel
>
> Best regards
>
> Miguel
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack 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][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Takashi Yamamoto]

hi,

On Thu, May 17, 2018 at 12:51 PM, Tony Breeds  wrote:
> On Wed, May 16, 2018 at 04:14:36PM -0500, Matthew Thode wrote:
>> On 18-05-16 17:07:09, Doug Hellmann wrote:
>> > Excerpts from Matthew Thode's message of 2018-05-16 15:59:47 -0500:
>> > > Sphinx has breaking changes (yet again) and we need to figure out how to
>> > > deal with it.  I think the fix will be simple for affected projects, but
>> > > we should probably move forward on this.  The error people are getting
>> > > seems to be 'Field list ends without a blank line; unexpected unindent.'
>> > >
>> > > I'd like to keep on 1.7.4 and have the affected projects fix the error
>> > > so we can move on, but the revert has been proposed (and approved to get
>> > > gate unbroken for them).  https://review.openstack.org/568248  Any
>> > > advice from the community is welcome.
>> > >
>> >
>> > Is it sphinx, or docutils?
>> >
>> > Do you have an example of the error?
>> >
>>
>> From https://bugs.launchpad.net/networking-midonet/+bug/1771092
>>
>> 2018-05-13 14:22:06.176410 | ubuntu-xenial | Warning, treated as error:
>> 2018-05-13 14:22:06.176967 | ubuntu-xenial | 
>> /home/zuul/src/git.openstack.org/openstack/networking-midonet/midonet/neutron/db/l3_db_midonet.py:docstring
>>  of 
>> midonet.neutron.db.l3_db_midonet.MidonetL3DBMixin.get_router_for_floatingip:8:Field
>>  list ends without a blank line; unexpected unindent.
>>
>
> Adding something like:
>
> (.docs) [tony@thor networking-midonet]$ ( cd ../neutron && git diff )
> diff --git a/neutron/db/l3_db.py b/neutron/db/l3_db.py
> index 33b5d99b1..66794542a 100644
> --- a/neutron/db/l3_db.py
> +++ b/neutron/db/l3_db.py
> @@ -1091,8 +1091,8 @@ class L3_NAT_dbonly_mixin(l3.RouterPluginBase,
>  :param internal_subnet: The subnet for the fixed-ip.
>  :param external_network_id: The external network for floating-ip.
>
> -:raises: ExternalGatewayForFloatingIPNotFound if no suitable router
> -is found.
> +:raises: ExternalGatewayForFloatingIPNotFound if no suitable router \
> + is found.
>  """
>
>  # Find routers(with router_id and interface address) that
> (.docs) [tony@thor networking-midonet]$ ( cd ../os-vif && git diff )
> diff --git a/os_vif/plugin.py b/os_vif/plugin.py
> index 56566a6..2a437a6 100644
> --- a/os_vif/plugin.py
> +++ b/os_vif/plugin.py
> @@ -49,10 +49,11 @@ class PluginBase(object):
>  Given a model of a VIF, perform operations to plug the VIF properly.
>
>  :param vif: `os_vif.objects.vif.VIFBase` object.
> -:param instance_info: `os_vif.objects.instance_info.InstanceInfo`
> -object.
> -:raises `processutils.ProcessExecutionError`. Plugins implementing
> -this method should let `processutils.ProcessExecutionError`
> +:param instance_info: `os_vif.objects.instance_info.InstanceInfo` \
> +  object.
> +
> +:raises `processutils.ProcessExecutionError`. Plugins implementing \
> +this method should let `processutils.ProcessExecutionError` \
>  bubble up.
>  """
>
> @@ -63,9 +64,10 @@ class PluginBase(object):
>
>  :param vif: `os_vif.objects.vif.VIFBase` object.
>  :param instance_info: `os_vif.objects.instance_info.InstanceInfo`
> -object.
> -:raises `processutils.ProcessExecutionError`. Plugins implementing
> -this method should let `processutils.ProcessExecutionError`
> +  object.
> +
> +:raises `processutils.ProcessExecutionError`. Plugins implementing \
> +this method should let `processutils.ProcessExecutionError` \
>  bubble up.
>  """
>
> fixes the midonet docs build for me (locally) on sphinx 1.7.4.  I'm far from a
> sphinx expert but the chnages to neutron and os-vif seem correct to me.

do you have a plan to submit these changes on gerrit?

>
> Perhaps the sphinx parser just got more strict?
>
> Yours Tony.
>
> __
> 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] [tap-as-a-service] core reviewer update

[Takashi Yamamoto]

i just made the change as i haven't got any concerns.
welcome, kaz!

On Thu, May 31, 2018 at 2:36 PM, Takashi Yamamoto  wrote:
> hi,
>
> i plan to add Kazuhiro Suzuki to tap-as-a-service-core group. [1]
> he is one of active members of the project.
> he is also the original author of tap-as-a-service-dashboard.
> i'll make the change after a week unless i hear any objections/concerns.
>
> [1] https://review.openstack.org/#/admin/groups/957,members
> http://stackalytics.com/report/contribution/tap-as-a-service/120

__
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] [tap-as-a-service] core reviewer update

[Takashi Yamamoto]

hi,

i plan to add Kazuhiro Suzuki to tap-as-a-service-core group. [1]
he is one of active members of the project.
he is also the original author of tap-as-a-service-dashboard.
i'll make the change after a week unless i hear any objections/concerns.

[1] https://review.openstack.org/#/admin/groups/957,members
http://stackalytics.com/report/contribution/tap-as-a-service/120

__
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] [tap-as-a-service] publish on pypi

[Takashi Yamamoto]

thank you. done. https://pypi.org/project/tap-as-a-service/

On Fri, Mar 30, 2018 at 8:27 AM, Clark Boylan <cboy...@sapwetik.org> wrote:
> On Wed, Mar 28, 2018, at 7:59 AM, Takashi Yamamoto wrote:
>> hi,
>>
>> i'm thinking about publishing the latest release of tap-as-a-service on pypi.
>> background: https://review.openstack.org/#/c/555788/
>> iirc, the naming (tap-as-a-service vs neutron-taas) was one of concerns
>> when we talked about this topic last time. (long time ago. my memory is dim.)
>> do you have any ideas or suggestions?
>> probably i'll just use "tap-as-a-service" unless anyone has strong opinions.
>> because:
>> - it's the name we use the most frequently
>> - we are not neutron (yet?)
>
> http://git.openstack.org/cgit/openstack/tap-as-a-service/tree/setup.cfg#n2 
> shows that tap-as-a-service is the existing package name so probably a good 
> one to go with as anyone that already has it installed from source should 
> have pip do the right thing when talking to pypi.
>
> Clark
>
> __
> 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] Bug deputy report

[Takashi Yamamoto]

oops, i forgot to add the critical one.

Critical
https://bugs.launchpad.net/neutron/+bug/1765008 Tempest API tests
failing for stable/queens branch

On Tue, Apr 24, 2018 at 9:11 PM, Takashi Yamamoto <yamam...@midokura.com> wrote:
> hi,
>
> here's a summary of this week.
>
> RFEs for drivers team:
> https://bugs.launchpad.net/neutron/+bug/1766380 [RFE] Create
> host-routes for routed networks (segments)
> https://bugs.launchpad.net/neutron/+bug/1764738 routed provider
> networks limit to one host
>
> Medium:
> https://bugs.launchpad.net/neutron/+bug/1764330 Cannot set --no-share
> on shared network covered also by "access_as_shared" RBAC policy
> https://bugs.launchpad.net/neutron/+bug/1763627 neutron
> service-provider-list return duplicated entries
> https://bugs.launchpad.net/neutron/+bug/1763604 neutron-ovs-cleanup
> failing when there are too many ports in bridge
> https://bugs.launchpad.net/neutron/+bug/1765452 Unable to use
> project_id as sort_key
>
> Low:
> https://bugs.launchpad.net/neutron/+bug/1765208 IPtables firewall code
> sometimes tries to remove non-existent rules
>
> Wishlist:
> https://bugs.launchpad.net/neutron/+bug/1765519 Add fullstack tests
> for shared networks API
>
> Incomplete / waiting a feedback from the submitter:
> https://bugs.launchpad.net/neutron/+bug/1762708 Unable to ssh/ping IP
> assigned to VM deployed on flat network
> https://bugs.launchpad.net/neutron/+bug/1762733 l3agentscheduler
> doesn't return a response body with POST
> /v2.0/agents/{agent_id}/l3-routers
> https://bugs.launchpad.net/neutron/+bug/1765691 OVN vlan networks use
> geneve tunneling for SNAT traffic
> https://bugs.launchpad.net/neutron/+bug/1765530 VM failed to reboot
> after compute host reboot in Queens

__
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] Bug deputy report

[Takashi Yamamoto]

hi,

here's a summary of this week.

RFEs for drivers team:
https://bugs.launchpad.net/neutron/+bug/1766380 [RFE] Create
host-routes for routed networks (segments)
https://bugs.launchpad.net/neutron/+bug/1764738 routed provider
networks limit to one host

Medium:
https://bugs.launchpad.net/neutron/+bug/1764330 Cannot set --no-share
on shared network covered also by "access_as_shared" RBAC policy
https://bugs.launchpad.net/neutron/+bug/1763627 neutron
service-provider-list return duplicated entries
https://bugs.launchpad.net/neutron/+bug/1763604 neutron-ovs-cleanup
failing when there are too many ports in bridge
https://bugs.launchpad.net/neutron/+bug/1765452 Unable to use
project_id as sort_key

Low:
https://bugs.launchpad.net/neutron/+bug/1765208 IPtables firewall code
sometimes tries to remove non-existent rules

Wishlist:
https://bugs.launchpad.net/neutron/+bug/1765519 Add fullstack tests
for shared networks API

Incomplete / waiting a feedback from the submitter:
https://bugs.launchpad.net/neutron/+bug/1762708 Unable to ssh/ping IP
assigned to VM deployed on flat network
https://bugs.launchpad.net/neutron/+bug/1762733 l3agentscheduler
doesn't return a response body with POST
/v2.0/agents/{agent_id}/l3-routers
https://bugs.launchpad.net/neutron/+bug/1765691 OVN vlan networks use
geneve tunneling for SNAT traffic
https://bugs.launchpad.net/neutron/+bug/1765530 VM failed to reboot
after compute host reboot in Queens

__
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] [tap-as-a-service] publish on pypi

[Takashi Yamamoto]

hi,

i'm thinking about publishing the latest release of tap-as-a-service on pypi.
background: https://review.openstack.org/#/c/555788/
iirc, the naming (tap-as-a-service vs neutron-taas) was one of concerns
when we talked about this topic last time. (long time ago. my memory is dim.)
do you have any ideas or suggestions?
probably i'll just use "tap-as-a-service" unless anyone has strong opinions.
because:
- it's the name we use the most frequently
- we are not neutron (yet?)

__
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] [tap-as-a-service] queens

[Takashi Yamamoto]

hi,

1. i'm going to create a release and stable branch for tap-as-a-service/queens.

2. to clean up the queue before a release, i approved a bunch of
patches today without waiting for two +2s.
given the current review bandwidth, i guess we should relax the policy.
how do you think?

3. what to do for tap-as-a-service-dashboard?  kaz?

__
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] Automatically generated Zuul changes (topic: zuulv3-projects)

[Takashi Yamamoto]

On Thu, Feb 1, 2018 at 2:59 AM, James E. Blair  wrote:
> Hi,
>
> Occasionally we will make changes to the Zuul configuration language.
> Usually these changes will be backwards compatible, but whether they are
> or not, we still want to move things forward.
>
> Because Zuul's configuration is now spread across many repositories, it
> may take many changes to do this.  I'm in the process of making one such
> change now.
>
> Zuul no longer requires the project name in the "project:" stanza for
> in-repo configuration.  Removing it makes it easier to fork or rename a
> project.
>
> I am using a script to create and upload these changes.  Because changes
> to Zuul's configuration use more resources, I, and the rest of the infra
> team, are carefully monitoring this and pacing changes so as not to
> overwhelm the system.  This is a limitation we'd like to address in the
> future, but we have to live with now.
>
> So if you see such a change to your project (the topic will be
> "zuulv3-projects"), please observe the following:
>
> * Go ahead and approve it as soon as possible.
>
> * Don't be strict about backported change ids.  These changes are only
>   to Zuul config files, the stable backport policy was not intended to
>   apply to things like this.
>
> * Don't create your own versions of these changes.  My script will
>   eventually upload changes to all affected project-branches.  It's
>   intentionally a slow process, and attempting to speed it up won't
>   help.  But if there's something wrong with the change I propose, feel
>   free to push an update to correct it.

1. is it ok to create my version of the change when making other
changes to the file?  eg. https://review.openstack.org/#/c/538200/

2. as a reviewer, what should i do to the similar changes which is not yours?
https://review.openstack.org/#/q/topic:zuulv3-projects+NOT+owner:%22James+E.+Blair+%253Ccorvus%2540inaugust.com%253E%22

>
> Thanks,
>
> Jim
>
> __
> 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][l3][flavors][floatingip]

[Takashi Yamamoto]

a floating-ip is associated to a router only if it's associated to a fixed-ip.
consider the case where there are two routers sharing a public network.

On Tue, Jan 23, 2018 at 11:09 AM, Bhatia, Manjeet S
 wrote:
> Hi Neutrinos,
>
>
>
> I am working on L3 flavors driver implementation for ODL backend, In l3
> Flavor’s driver there is need to fetch flavors id on floatingip operations,
>
> So that if floatingip is not for association with router of that flavor,
> driver can ignore the operation and return, but I noticed there’s router_id
>
> None In floatingip payload sent to driver in networking-odl by neutron.
>
>
>
> What I did was
>
>
>
> 1.   Create an router of xyz flavor.
>
> 2.   Added public-subnet interface to that router.
>
> 3.   Created floatingip on that public network.
>
>
>
> I see None router_id being sent in payload [a]. for floatingip operation. I
> am not sure if this is intended, I think it is a bug otherwise I don’t see
>
> Other way of discarding floating ip operation by l3 flavors driver if it is
> not gonna be associated with router of that flavor.
>
>
>
>
>
> [a]. http://paste.openstack.org/show/646543/
>
>
>
>
>
> Thanks and Regards !
>
> Manjeet Singh Bhatia
>
>
>
>
>
>
> __
> 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] Stepping down from core

[Takashi Yamamoto]

On Sat, Dec 16, 2017 at 4:01 AM, Armando M.  wrote:
> Hi neutrinos,
>
> To some of you this email may not come as a surprise.

it was a surprise to me.

>
> During the past few months my upstream community engagements have been more
> and more sporadic. While I tried hard to stay committed and fulfill my core
> responsibilities I feel like I failed to retain the level of quality and
> consistency that I would have liked ever since I stepped down from being the
> Neutron PTL back at the end of Ocata.
>
> I stated many times when talking to other core developers that being core is
> a duty rather than a privilege, and I personally feel like it's way overdue
> for me to recognize on the mailing list that it's the time that I state
> officially my intention to step down due to other commitments.

it seems you have a very high standard.
i suspect many of us should resign if we all follow your standard. :-)

>
> This does not mean that I will disappear tomorrow. I'll continue to be on
> neutron IRC channels, support the neutron team, being the release liasion
> for Queens, participate at meetings, and be open to providing feedback to
> anyone who thinks my opinion is still valuable, especially when dealing with
> the neutron quirks for which I might be (git) blamed :)
>
> Cheers,
> Armando
>
>
> __
> 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] Bug deputy report

[Takashi Yamamoto]

hi,

thank you.
do you have anything to hand off to the next bug deputy (me) ?

On Mon, Dec 25, 2017 at 3:31 PM, Luo, Lujin  wrote:
> Hello everyone,
>
> I was on bug deputy between 2017.12.18 and 2017.12.25. I am sending a short 
> summary of the bugs reported during this period.
>
> https://bugs.launchpad.net/neutron/+bug/1739798 - Medium. networking-ovn 
> driver expects network postcommit methods to be called with no open sessions 
> to the database. Some changes of how we handle segments deletion inside 
> network deletion are required. It is not assigned yet, so if anyone is 
> interested, it is yours.
>
> https://bugs.launchpad.net/neutron/+bug/1739411 - Low. QoS DSCP mark 
> disappear stable/ocata. Two possible fixes have been proposed and one is used 
> in Pike and current master. It looks to me like a low-hanging fruit. Anyone 
> interested, please take it over.
>
> https://bugs.launchpad.net/neutron/+bug/1739227 - One test case does not obey 
> when the parent network is vlan. Jakub is handling it. Thanks :)
>
> https://bugs.launchpad.net/neutron/+bug/1739219 - Medium. stable/Pike. 
> Removal of DHCP agent does not cascade to the removal of the corresponding 
> port (with device_onwer as "network:dhcp"). It is not assigned yet, so if 
> anyone is interested, it is yours.
>
> https://bugs.launchpad.net/neutron/+bug/1739078 and 
> https://bugs.launchpad.net/neutron/+bug/1739075 - RFE of full stack test 
> proposed by Jakub.
>
> https://bugs.launchpad.net/neutron/+bug/1739071 and 
> https://bugs.launchpad.net/neutron/+bug/1738983 - garyk has started working 
> on them.
>
> https://bugs.launchpad.net/neutron/+bug/1738768 - Critial. Regression of 
> dataplane downtime when L3 agents running in containers are shutdown. It is 
> also marked as high in TripleO. Currently no one is assigned. I have asked 
> Miguel to take a look at it. But anyone else who is familiar with containers 
> and L3, please take a look too.
>
> https://bugs.launchpad.net/neutron/+bug/1738738 - RFE poposed by Reedip.
>
>
> Happy holidays!
>
> Best regards,
> Lujin
>
> ∽---
> Lujin Luo
> Email: luo.lu...@jp.fujitsu.com
> Tel: (81) 044-754-2027
> Linux Development Division
> Platform Software Business Unit
> Fujitsu Ltd.
> --∽
>
>
>
> __
> 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][networking-ovn] Stable branch maintainers for networking-ovn

[Takashi Yamamoto]

On Wed, Dec 20, 2017 at 7:18 PM, Lucas Alvares Gomes
 wrote:
> Hi,
>
>>> Hi all,
>>>
>>> Just sending this email to try to understand the model for stable branch 
>>> maintenance in networking-ovn (potentially other neutron drivers too).
>>>
>>> Right now, only members of the ``neutron-stable-maint`` gerrit group are 
>>> able to approve patches for the stable branches; this can cause some delays 
>>> when fixing things (e.g [0]) because we don't have any member in that group 
>>> that is also a ``networking-ovn-core`` member. So, sometimes we have to go 
>>> around and ping people to take a look at the patches and it kinda sucks.
>>
>>
>> We had a Gerrit dashboard that helped stable reviewers stay on top of things 
>> [1], but it looks like it doesn't seem to work anymore. My suggestion would 
>> be to look into that as the lack of visibility might be the source of the 
>> recent delay.
>>
>> [1] 
>> https://docs.openstack.org/neutron/latest/contributor/dashboards/index.html#gerrit-dashboards
>
> ++ indeed, lack of visibility is a problem as well.

and lack of visibility of the fix of the dashboard? :-)
https://review.openstack.org/#/c/479138/

>
>>> Is there any reason why things are set up in that way ?
>>>
>>> I was wondering if it would make sense to create a new group to help 
>>> maintaining the stable branches in networking-ovn. The new group could 
>>> include some of the core members willing to do the work + 
>>> ``neutron-stable-maint`` as a subgroup. Is that reasonable, what you think 
>>> about it?
>>
>>
>> Rather than create yet another group(s), it makes sense to have an 
>> individual from each neutron project participate in the neutron-stable-maint 
>> team (whose admin rights I think are held by Ihar as neutron member), for 
>> those of whom have actually an interest in reviewing stable patches :)
>>
>
> Having a member in the current group will help, if you are comfortable
> with adding a new member to the current group that would be great.
>
> The reason why I was leaning towards having another group is because
> of scope limitation. Members of the ``neutron-stable-maint`` group can
> approve patches for all neutron-related projects stable branches. By
> having a separated group, members would only be able to approve things
> for a specific project.
>
> The new group would also have the ``neutron-stable-maint`` as a
> sub-group to it , so the members of the original group would still
> able approve things everywhere.
>
> Anyway, either ideas would help with the original problem, I'm good
> with whatever approach people thinks is best.
>
> Cheers,
> Lucas
>
> __
> 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] [networking-ovn] Non voting jobs for networking-ovn on neutron.

[Takashi Yamamoto]

hi,

On Mon, Dec 4, 2017 at 10:20 PM, Miguel Angel Ajo Pelayo
 wrote:
>
> Hi Folks,
>  I wanted to rise this topic, I have been wanting to do it from long
> ago,
> but preferred to wait until the zuulv3 stuff was a little bit more stable,
> may
> be now it's a good time.
>
> We were thinking about the option of having a couple of non-voting jobs
> on
> the neutron check for networking-ovn. It'd be great for us, in terms of
> traceability,
> we re-use a lot of the neutron unit test base clases/etc, and sometimes
> we get hit by surprises.
>
> Sometimes some other changes hit us on the neutron scenario tests.
>
> So it'd be great to have them if you believe it's a reasonable thing.

i can understand why you want it.
but once we allow this kind of jobs, we will soon end up to have a lot
of jobs for
each neutron related projects. i guess it isn't acceptable.
you can still set up 3rd party CI.

>
> Best regards,
> Miguel Ángel.
>
> __
> 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][networking-odl]

[Takashi Yamamoto]

On Wed, Nov 8, 2017 at 3:15 PM, Bhatia, Manjeet S
<manjeet.s.bha...@intel.com> wrote:
>
>
>> -Original Message-
>> From: Takashi Yamamoto [mailto:yamam...@midokura.com]
>> Sent: Tuesday, November 7, 2017 10:13 PM
>> To: Bhatia, Manjeet S <manjeet.s.bha...@intel.com>
>> Cc: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [neutron][networking-odl]
>>
>> hi,
>>
>> On Thu, Nov 2, 2017 at 9:01 AM, Bhatia, Manjeet S
>> <manjeet.s.bha...@intel.com> wrote:
>> > Hello Neutrinos,
>> >
>> >
>> >
>> > I’ve been trying service profile flavors for L3 in neutron to register
>> > the driver,
>> >
>> > the method I’ve been using is below
>> >
>> >
>> >
>> > I have this added to neutron.conf
>> >
>> > [service_providers]
>> >
>> > service_provider =
>> > L3_ROUTER_NAT:ODL:networking_odl.l3.l3_flavor.ODLL3ServiceProvider:def
>> > ault
>>
>> where do you have this driver?
>
> In networking-odl local repo as WIP.

a similar procedure [1] worked for me with midonet POC code. [2]
so i suspect there's something wrong in your local code.

[1] 
https://review.openstack.org/#/c/483174/2/midonet/neutron/services/l3/service_providers/l3_midonet.py@38
[2] https://review.openstack.org/#/c/483174/

>
>>
>> >
>> >
>> >
>> > and then tried creating flavor profile
>> >
>> > [a]. openstack network flavor profile create --driver
>> > networking_odl.l3.l3_flavor.ODLL3ServiceProvider
>> >
>> >
>> >
>> > It returns NotFoundException: Not Found (HTTP 404) (Request-ID:
>> > req-6991a8ab-b785-4160-96d6-e496d7667f15), Service Profile driver
>> > networking_odl.l3.l3_flavor.ODLL3ServiceProvider could not be found.
>> >
>> >
>> >
>> > Here is trace from log http://paste.openstack.org/show/625178/ seems
>> > like resource not found,
>> >
>> >
>> >
>> > But I also noticed in [1]. self.config is {}
>> >
>> >
>> >
>> >
>> >
>> > [1].
>> > https://github.com/openstack/neutron/blob/master/neutron/db/servicetyp
>> > e_db.py#L55
>> >
>> >
>> >
>> >
>> >
>> > Any pointers what’s being done wrong is it the enabling of service
>> > profiles flavor or something else ?
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Thanks and regards !
>> >
>> > Manjeet
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >

__
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][networking-odl]

[Takashi Yamamoto]

hi,

On Thu, Nov 2, 2017 at 9:01 AM, Bhatia, Manjeet S
 wrote:
> Hello Neutrinos,
>
>
>
> I’ve been trying service profile flavors for L3 in neutron to register the
> driver,
>
> the method I’ve been using is below
>
>
>
> I have this added to neutron.conf
>
> [service_providers]
>
> service_provider =
> L3_ROUTER_NAT:ODL:networking_odl.l3.l3_flavor.ODLL3ServiceProvider:default

where do you have this driver?

>
>
>
> and then tried creating flavor profile
>
> [a]. openstack network flavor profile create --driver
> networking_odl.l3.l3_flavor.ODLL3ServiceProvider
>
>
>
> It returns NotFoundException: Not Found (HTTP 404) (Request-ID:
> req-6991a8ab-b785-4160-96d6-e496d7667f15), Service Profile driver
> networking_odl.l3.l3_flavor.ODLL3ServiceProvider could not be found.
>
>
>
> Here is trace from log http://paste.openstack.org/show/625178/ seems like
> resource not found,
>
>
>
> But I also noticed in [1]. self.config is {}
>
>
>
>
>
> [1].
> https://github.com/openstack/neutron/blob/master/neutron/db/servicetype_db.py#L55
>
>
>
>
>
> Any pointers what’s being done wrong is it the enabling of service profiles
> flavor or something else ?
>
>
>
>
>
>
>
> Thanks and regards !
>
> Manjeet
>
>
>
>
>
>
>
>

__
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][networking-midonet] Core reviewers change proposal

[Takashi Yamamoto]

Hi,

On Fri, Oct 20, 2017 at 10:10 PM, Takashi Yamamoto
<yamam...@midokura.com> wrote:
> Hi,
>
> Unless anyone objects, I'll remove the following people from the list
> of networking-midonet core reviewers.
>
> - Joe Mills
> - Michael Micucci
>
> They made great contributions in the past (thank you!) but have not
> reviewed any patches in the last 6 months. [2]
>
> [1] https://review.openstack.org/#/admin/groups/607,members
> [2] http://stackalytics.com/report/contribution/networking-midonet/180

As I haven't received any concerns, I updated the members accordingly.

__
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][vpnaas] core reviewer proposal

[Takashi Yamamoto]

Hi,

On Fri, Oct 20, 2017 at 10:10 PM, Takashi Yamamoto
<yamam...@midokura.com> wrote:
> Hi,
>
> Unless anyone objects, i'll add the following people to neutron-vpnaas
> core reviewers. [1]
>
> - Cao Xuan Hoang <hoan...@vn.fujitsu.com>
> - Akihiro Motoki <amot...@gmail.com>
> - Miguel Lavalle <mig...@mlavalle.com>
>
> Hoang is the most active contributor for the project these days.
>
> I don't bother to introduce Akihiro and Miguel as i guess everyone here
> knows them. :-)
>
> [1] https://review.openstack.org/#/admin/groups/502,members

As I haven't received any concerns, I updated the list accordingly.

__
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][networking-midonet] Core reviewers change proposal

[Takashi Yamamoto]

Hi,

Unless anyone objects, I'll remove the following people from the list
of networking-midonet core reviewers.

- Joe Mills
- Michael Micucci

They made great contributions in the past (thank you!) but have not
reviewed any patches in the last 6 months. [2]

[1] https://review.openstack.org/#/admin/groups/607,members
[2] http://stackalytics.com/report/contribution/networking-midonet/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

[openstack-dev] [neutron][vpnaas] core reviewer proposal

[Takashi Yamamoto]

Hi,

Unless anyone objects, i'll add the following people to neutron-vpnaas
core reviewers. [1]

- Cao Xuan Hoang 
- Akihiro Motoki 
- Miguel Lavalle 

Hoang is the most active contributor for the project these days.

I don't bother to introduce Akihiro and Miguel as i guess everyone here
knows them. :-)

[1] https://review.openstack.org/#/admin/groups/502,members

__
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] Update on Zuul v3 Migration - and what to do about issues

[Takashi Yamamoto]

On Thu, Oct 5, 2017 at 8:58 PM, Pierre Riteau  wrote:
> On 29 Sep 2017, at 15:58, Monty Taylor  wrote:
>
> tl;dr - If you're having issues with your jobs, check the FAQ, this email
> and followups on this thread for mentions of them. If it's an issue with
> your job and you can spot it (bad config) just submit a patch with topic
> 'zuulv3'. If it's bigger/weirder/you don't know - we'd like to ask that you
> send a follow up email to this thread so that we can ensure we've got them
> all and so that others can see it too.
>
>
> Hello,
>
> Automated requirements updates [1] are all failing with the same error in
> the run.yaml playbook of the legacy-requirements job, e.g. in
> python-blazarclient [2].
> The command `/usr/local/jenkins/slave_scripts/project-requirements-change.py
> $ZUUL_BRANCH` fails with:
>
> SystemError: error: pathspec 'remotes/origin/master' did not match any
> file(s) known to git.
>
> or, for patches using the Pike stable branch:
>
> SystemError: error: pathspec 'remotes/origin/stable/pike' did not match
> any file(s) known to git.

i was told this is a fix. https://review.openstack.org/#/c/508898/

>
> [1]
> https://review.openstack.org/#/q/topic:openstack/requirements+status:open
> [2]
> http://logs.openstack.org/50/509450/9/check/legacy-requirements/914355a/ara/
>
> Best regards,
> Pierre Riteau
>
>
> __
> 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] Denver Team Dinner

[Takashi Yamamoto]

+1

On Wed, Sep 13, 2017 at 2:56 AM, IWAMOTO Toshihiro
 wrote:
> +1
> thanks for organizing!
>
> On Wed, 13 Sep 2017 14:18:45 +0900,
> Brian Haley wrote:
>>
>> +1
>>
>> On 09/12/2017 10:44 PM, Ihar Hrachyshka wrote:
>> > +1
>> >
>> > On Tue, Sep 12, 2017 at 9:44 PM, Kevin Benton  wrote:
>> >> +1
>> >>
>> >> On Tue, Sep 12, 2017 at 8:50 PM, Sławek Kapłoński 
>> >> wrote:
>> >>>
>> >>> +1
>> >>>
>> >>> —
>> >>> Best regards
>> >>> Slawek Kaplonski
>> >>> sla...@kaplonski.pl
>> >>>
>> >>>
>> >>>
>> >>>
>>  Wiadomość napisana przez Miguel Lavalle  w dniu
>>  12.09.2017, o godz. 17:23:
>> 
>>  Dear Neutrinos,
>> 
>>  Our social event will take place on Thursday September 12th at 7:30pm.
>>  The venue is going to be https://www.famousdaves.com/Denver-Stapleton. 
>>  It is
>>  located 0.4 miles from the Renaissance Hotel, which translates to an 
>>  easy 9
>>  minutes walk.
>> 
>>  I have a reservation for a group of 30 people under my name. Please
>>  respond to this message with your attendance confirmation by Wednesday
>>  night, so I can get a more accurate head count.
>> 
>>  Looking forward to see y'all Thursday night
>> 
>>  Best regards
>> 
>>  Miguel
>> 
>>  __
>>  OpenStack Development Mailing List (not for usage questions)
>>  Unsubscribe:
>>  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>
>> >>>
>> >>> __
>> >>> OpenStack 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

__
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] out-of-tree l3 service providers

[Takashi Yamamoto]

hi,

On Fri, Sep 8, 2017 at 5:52 AM, Isaku Yamahata <isaku.yamah...@gmail.com> wrote:
> Hi.
>
> Any update on this? Now L3 service provider got the time slot at the PTG.
>
> Yamamoto, do you have any proposal for the interface?

no

> Although ODL surely is interested in L3 flavor, the networking-odl team hasn't
> spec or experimental patch yet unfortunately.

can you at least provide your requirements?

networking-midonet needs to send the following info to its backend on
AFTER_CREATE/AFTER_UPDATE for router, router_interface, and
floating_ip.
https://github.com/midonet/midonet/blob/fcc127f5c9216b7a563c89d2684461428feb9a67/nsdb/src/main/proto/neutron.proto#L129-L161
(some of fields are actually unused right now. eg. tenant_id)
on AFTER_DELETE, we only need "id" field of the resource.
in feature we want to use PRECOMMIT_xxx events as well. necessary
fields are same as AFTER_xxx.

> Dragon flow folks seems to have their own spec.
>
> thanks,
>
> On Mon, Jul 31, 2017 at 02:10:07PM +0900,
> Takashi Yamamoto <yamam...@midokura.com> wrote:
>
>> hi,
>>
>> On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton <ke...@benton.pub> wrote:
>> > If I understand the main issue with using regular callbacks, it's mainly
>> > just that the flavor assignment itself is in a callback, right?
>>
>> yes.
>>
>> >
>> > If so, couldn't we solve the problem by just moving flavor assignment to an
>> > explicit call before emitting the callbacks? Or would that still result in
>> > other ordering issues?
>>
>> it would solve the problem for CREATE.
>> for UPDATE and DELETE, i'm not sure.
>> UPDATE can change the flavor but it's supposed to be a special case
>> only for dvr/ha, right?
>> AFTER_DELETE might be tricky as we probably need to provide flavor
>> info to subscribers.
>>
>> >
>> > On Thu, Jul 13, 2017 at 3:01 AM, Takashi Yamamoto <yamam...@midokura.com>
>> > wrote:
>> >>
>> >> hi,
>> >>
>> >> today i managed to play with l3 flavors.
>> >> i wrote a crude patch to implement midonet flavor. [1]
>> >>
>> >> [1] https://review.openstack.org/#/c/483174/
>> >>
>> >> a good news is it's somehow working.
>> >>
>> >> a bad news is it has a lot of issues, as you can see in TODO comments
>> >> in the patch.
>> >> given these issues, now i tend to think it's cleaner to introduce
>> >> ml2-like precommit/postcommit driver api (or its equivalent via
>> >> callbacks) rather than using these existing notifications.
>> >>
>> >> how do you think?
>> >
>> >
>>
>> __
>> 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
>
> --
> Isaku Yamahata <isaku.yamah...@gmail.com>

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

Re: [openstack-dev] [neutron][vpnaas] pike rc

[Takashi Yamamoto]

done

http://git.openstack.org/cgit/openstack/neutron-vpnaas/tag/?h=11.0.0.0rc1
https://review.openstack.org/#/q/status:open+project:openstack/neutron-vpnaas+branch:stable/pike+topic:create-pike

On Tue, Aug 8, 2017 at 10:46 AM, Takashi Yamamoto <yamam...@midokura.com> wrote:
> hi,
>
> can anyone with an appropriate permission create a stable/pike
> and pike rc1 for neutron-vpnaas?
>
> stable/pike
> 11.0.0.0rc1
> openstack/neutron-vpnaas
> 8278615c1f35f98447a3f9692a78ab45e90ee8c6
>
> thank you.

__
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][tap-as-a-service] pike branch/release

[Takashi Yamamoto]

done.

http://git.openstack.org/cgit/openstack/tap-as-a-service/tag/?h=2.0.0
https://review.openstack.org/#/q/status:open+project:openstack/tap-as-a-service+branch:stable/pike+topic:create-pike

On Tue, Aug 8, 2017 at 10:07 PM, Takashi Yamamoto <yamam...@midokura.com> wrote:
> hi,
>
> On Tue, Aug 8, 2017 at 9:14 PM, Doug Hellmann <d...@doughellmann.com> wrote:
>> Excerpts from Takashi Yamamoto's message of 2017-08-08 10:49:09 +0900:
>>> hi
>>>
>>> i'll create stable/pike (and probably a release) for tap-as-a-service
>>> in this week.
>>>
>>
>> We have a bunch of tools that expect stable branches to only be created
>> from releases, so please do tag before branching.
>
> ok.  thank you!
>
>>
>> Doug
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron][vpnaas] pike rc

[Takashi Yamamoto]

On Wed, Aug 9, 2017 at 12:35 AM, Armando M. <arma...@gmail.com> wrote:
>
>
> On 8 August 2017 at 02:34, Akihiro Motoki <amot...@gmail.com> wrote:
>>
>> I proposed a project-config patch to allow us to release neutron-vpnaas.
>> https://review.openstack.org/#/c/491670/
>> There is a missing configuration when neutron-vpnaas was pushed out
>> from the neutron stadium.
>> Once the patch is merged and -release group are setup, we can release
>> neutron-vpnaas by ourselves.
>
>
> Is this strictly necessary? I don't see these in other gerrit ACLs
> (irrespective of whether they are part of neutron or not). My understanding
> is that the release can be fully managed by the openstack release team once
> a patch like [1] is posted to the openstack/releases project.
>
> [1] https://review.openstack.org/#/c/491429/

my understanding is it's necessary for hosted projects
because they are not managed by openstack/releases.
unlike neutron-vpnaas, networking-hyperv is an official project. [2]

[2] 
https://github.com/openstack/governance/commit/c84d0a702f536a43324212f803e0a43a640c9b56

>
>
>>
>>
>> Akihiro
>>
>> 2017-08-08 10:46 GMT+09:00 Takashi Yamamoto <yamam...@midokura.com>:
>> > hi,
>> >
>> > can anyone with an appropriate permission create a stable/pike
>> > and pike rc1 for neutron-vpnaas?
>> >
>> > stable/pike
>> > 11.0.0.0rc1
>> > openstack/neutron-vpnaas
>> > 8278615c1f35f98447a3f9692a78ab45e90ee8c6
>> >
>> > thank you.
>> >
>> >
>> > __
>> > 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][tap-as-a-service] pike branch/release

[Takashi Yamamoto]

hi,

On Tue, Aug 8, 2017 at 9:14 PM, Doug Hellmann  wrote:
> Excerpts from Takashi Yamamoto's message of 2017-08-08 10:49:09 +0900:
>> hi
>>
>> i'll create stable/pike (and probably a release) for tap-as-a-service
>> in this week.
>>
>
> We have a bunch of tools that expect stable branches to only be created
> from releases, so please do tag before branching.

ok.  thank you!

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

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

[openstack-dev] [neutron][tap-as-a-service] pike branch/release

[Takashi Yamamoto]

hi

i'll create stable/pike (and probably a release) for tap-as-a-service
in this 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][networking-l2gw] pike

[Takashi Yamamoto]

hi,

who is planning to make stable/pike for networking-l2gw?

__
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][vpnaas] pike rc

[Takashi Yamamoto]

hi,

can anyone with an appropriate permission create a stable/pike
and pike rc1 for neutron-vpnaas?

stable/pike
11.0.0.0rc1
openstack/neutron-vpnaas
8278615c1f35f98447a3f9692a78ab45e90ee8c6

thank you.

__
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] FFE for midonet v2 plugin removal

[Takashi Yamamoto]

On Tue, Aug 1, 2017 at 8:01 AM, Takashi Yamamoto <yamam...@midokura.com> wrote:
> hi,
>
> I'm not sure if changes like this requires an FFE, but just in case.
> I'd like to request an FFE for midonet v2 plugin removal.
>
> - patches are ready for review: https://review.openstack.org/#/c/486790/
> - https://bugs.launchpad.net/networking-midonet/

oops, bad copy and paste.
https://bugs.launchpad.net/networking-midonet/+bug/1680347

> - this is a removal of an already-deprecated plugin
> - the replacement code (midonet drivers for ml2) covers the most or
> probably all functionalities provided by the plugin being removed
> - the change is local to networking-midonet

__
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] FFE for midonet v2 plugin removal

[Takashi Yamamoto]

hi,

I'm not sure if changes like this requires an FFE, but just in case.
I'd like to request an FFE for midonet v2 plugin removal.

- patches are ready for review: https://review.openstack.org/#/c/486790/
- https://bugs.launchpad.net/networking-midonet/
- this is a removal of an already-deprecated plugin
- the replacement code (midonet drivers for ml2) covers the most or
probably all functionalities provided by the plugin being removed
- the change is local to networking-midonet

__
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] out-of-tree l3 service providers

[Takashi Yamamoto]

hi,

On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton <ke...@benton.pub> wrote:
> If I understand the main issue with using regular callbacks, it's mainly
> just that the flavor assignment itself is in a callback, right?

yes.

>
> If so, couldn't we solve the problem by just moving flavor assignment to an
> explicit call before emitting the callbacks? Or would that still result in
> other ordering issues?

it would solve the problem for CREATE.
for UPDATE and DELETE, i'm not sure.
UPDATE can change the flavor but it's supposed to be a special case
only for dvr/ha, right?
AFTER_DELETE might be tricky as we probably need to provide flavor
info to subscribers.

>
> On Thu, Jul 13, 2017 at 3:01 AM, Takashi Yamamoto <yamam...@midokura.com>
> wrote:
>>
>> hi,
>>
>> today i managed to play with l3 flavors.
>> i wrote a crude patch to implement midonet flavor. [1]
>>
>> [1] https://review.openstack.org/#/c/483174/
>>
>> a good news is it's somehow working.
>>
>> a bad news is it has a lot of issues, as you can see in TODO comments
>> in the patch.
>> given these issues, now i tend to think it's cleaner to introduce
>> ml2-like precommit/postcommit driver api (or its equivalent via
>> callbacks) rather than using these existing notifications.
>>
>> how do you think?
>
>

__
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][vpnaas] driver removal

[Takashi Yamamoto]

hi,

some of drivers in neutron-vpnaas don't have maintainers. [1]
unless someone steps up, we might end up with removing those drivers.

especially, VyattaIPsecDriver will likely be removed in near future,
as it requires a special agent [2] which is difficult to maintain for
those who are not familiar with it.

[1] 
https://github.com/openstack/neutron-vpnaas/blob/master/doc/source/devref/team.rst
[2] 
https://github.com/openstack/neutron-vpnaas/blob/797c0466693108dd63415a065750e7a62a5f5ce8/setup.cfg#L36

__
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] out-of-tree l3 service providers

[Takashi Yamamoto]

hi,

today i managed to play with l3 flavors.
i wrote a crude patch to implement midonet flavor. [1]

[1] https://review.openstack.org/#/c/483174/

a good news is it's somehow working.

a bad news is it has a lot of issues, as you can see in TODO comments
in the patch.
given these issues, now i tend to think it's cleaner to introduce
ml2-like precommit/postcommit driver api (or its equivalent via
callbacks) rather than using these existing notifications.

how do you think?

__
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] FWaaS/VPNaaS dashboard split out from horizon

[Takashi Yamamoto]

On Wed, May 31, 2017 at 10:12 PM, Akihiro Motoki  wrote:
> Hi all,
>
> As discussed last month [1], we agree that each neutron-related
> dashboard has its own repository.
> I would like to move this forward on FWaaS and VPNaaS
> as the horizon team plans to split them out as horizon plugins.
>
> A couple of questions hit me.
>
> (1) launchpad project
> Do we create a new launchpad project for each dashboard?
> At now, FWaaS and VPNaaS projects use 'neutron' for their bug tracking
> from the historical reason, it sometimes There are two choices: the
> one is to accept dashboard bugs in 'neutron' launchpad,
> and the other is to have a separate launchpad project.
>
> My vote is to create a separate launchpad project.
> It allows users to search and file bugs easily.

+1

>
> (2) repository name
>
> Are neutron-fwaas-dashboard / neutron-vpnaas-dashboard good repository
> names for you?
> Most horizon related projects use -dashboard or -ui as their repo 
> names.
> I personally prefers to -dashboard as it is consistent with the
> OpenStack dashboard
> (the official name of horizon). On the other hand, I know some folks
> prefer to -ui
> as the name is shorter enough.
> Any preference?

+1 for -dashboard.
-ui sounds too generic to me.

>
> (3) governance
> neutron-fwaas project is under the neutron project.
> Does it sound okay to have neutron-fwaas-dashboard under the neutron project?
> This is what the neutron team does for neutron-lbaas-dashboard before
> and this model is adopted in most horizon plugins (like trove, sahara
> or others).

+1

>
> (4) initial core team
>
> My thought is to have neutron-fwaas/vpnaas-core and horizon-core as
> the initial core team.
> The release team and the stable team follow what we have for
> neutron-fwaas/vpnaas projects.
> Sounds reasonable?

+1

>
>
> Finally, I already prepare the split out version of FWaaS and VPNaaS
> dashboards in my personal github repos.
> Once we agree in the questions above, I will create the repositories
> under git.openstack.org.

great, thank you.

>
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2017-April/thread.html#115200
>
> __
> 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][networking-midonet] networking-midonet core reviewer proposal

[Takashi Yamamoto]

as i haven't heard any objections, i went ahead and added them to the list. [1]

[1] https://review.openstack.org/#/admin/groups/607,members

On Wed, Apr 26, 2017 at 12:07 PM, Ryu Ishimoto <r...@midokura.com> wrote:
>
> +1 !
>
> On Wed, Apr 26, 2017 at 11:41 AM Takashi Yamamoto <yamam...@midokura.com>
> wrote:
>>
>> unless anyone objects, i'll add the following people to
>> networking-midonet project's core reviewers.
>>
>> - Antonio Ojea
>> - Brandon Berg
>> - Xavi León
>>
>> http://stackalytics.com/report/contribution/networking-midonet/30
>> http://stackalytics.com/report/contribution/networking-midonet/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
>
>
> __
> 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 in QoS service plugin

[Takashi Yamamoto]

On Fri, Apr 28, 2017 at 6:03 AM, Sławek Kapłoński  wrote:
> Hello,
>
> Some time ago my patch [1] was merged. It changes list of supported 
> qos_rule_types to dict with rule types as keys and list of supported 
> parameters and values for each rule type.
> Additionally now almost merged (I hope) is patch [2] which introduce new 
> attribute `direction` to bandwidth_limit_rule type. By default it will have 
> EGRESS value so it’s exactly like it was up to now.
>
> So similar changes should be done in 3rd party QoS drivers also. I made 
> patches [3], [4], [5] to networking-ovn, networking-odl and 
> networking-midonet repos because I found that in those repos there is QoS 
> driver already.
>
> If You have QoS driver in Your repo, please update it also.

dragonflow: https://review.openstack.org/#/c/460806/

codesearch suggested vmware-nsx and networking-hyperv have
RULE_TYPE_BANDWIDTH_LIMIT too.

>
> [1] https://review.openstack.org/#/c/426946/
> [2] https://review.openstack.org/#/c/457816/
> [3] https://review.openstack.org/#/c/460734/
> [4] https://review.openstack.org/#/c/460737/
> [5] https://review.openstack.org/#/c/460741/
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>
>
> __
> 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][networking-midonet] networking-midonet core reviewer proposal

[Takashi Yamamoto]

unless anyone objects, i'll add the following people to
networking-midonet project's core reviewers.

- Antonio Ojea
- Brandon Berg
- Xavi León

http://stackalytics.com/report/contribution/networking-midonet/30
http://stackalytics.com/report/contribution/networking-midonet/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] [devstack] uwsgi for API services

[Takashi Yamamoto]

On Thu, Apr 13, 2017 at 9:01 PM, Sean Dague  wrote:
> One of the many reasons for getting all our API services running wsgi
> under a real webserver is to get out of the custom ports for all
> services game. However, because of some of the limits of apache
> mod_wsgi, we really haven't been able to do that in our development
> enviroment. Plus, the moment we go to mod_wsgi for some services, the
> entire development workflow for "change this library, refresh the
> following services" changes dramatically.
>
> It would be better to have a consistent story here.
>
> So there is some early work up to use apache mod_proxy_uwsgi as the
> listener, and uwsgi processes running under systemd for all the
> services. These bind only to a unix local socket, not to a port.
> https://review.openstack.org/#/c/456344/
>
> Early testing locally has been showing progress. We still need to prove
> out a few things, but this should simplify a bunch of the setup. And
> coming with systemd will converge us back to a more consistent
> development workflow when updating common code in a project that has
> both API services and workers.
>
> For projects that did the mod_wsgi thing in a devstack plugin, this is
> going to require some adjustment. Exactly what is not yet clear, but
> it's going to be worth following that patch.

networking-midonet needed this change.
https://review.openstack.org/#/c/458305

i guess some other projects need similar changes.
http://codesearch.openstack.org/?q=KEYSTONE_AUTH_PORT=nope==

>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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] Engine facade

[Takashi Yamamoto]

hi,

On Tue, Apr 4, 2017 at 4:09 PM, Gary Kotton  wrote:
> Hi,
>
> The problem that we have is that any foreign key usage under transactions is
> now broken. An example of an exception that is raised is:
>
>
>
> DBReferenceError: (sqlite3.IntegrityError) FOREIGN KEY constraint failed
> [SQL: u'INSERT INTO neutron_nsx_firewall_section_mappings (created_at,
> updated_at, neutron_id, nsx_id) VALUES (?, ?, ?, ?)'] [parameters:
> ('2017-04-04 06:48:25.595118', None, '6a086bf1-b1c9-495f-bfca-810d6638e3fa',
> '2563cd05-edd9-4c7f-9708-857a129e2642')]
>
>
>
> This is a major refactor in the plugin (which I guess is part and parcel of
> rolling with the punches). I am just concerned if we are the only folks that
> have affected by this.

networking-midonet is affected as well.

>
> Thanks
>
> Gary
>
>
>
> From: Gary Kotton 
> Reply-To: OpenStack List 
> Date: Monday, April 3, 2017 at 3:14 PM
>
>
> To: OpenStack List 
> Subject: Re: [openstack-dev] [neutron] Engine facade
>
>
>
> Hi,
>
> We needed to make all of those changes to just get the plugin to pass unit
> tests and CI. We are still seeing lots of issues and need to look deeper.
> The façade changes have caused a lot of instability issues. I am not 100%
> sure why. Issues that we have seen:
>
> 1. object creation under a transaction broke
>
> 2. deleting DB entries under transaction also broke
>
> Thanks
>
> Gary
>
>
>
>
>
> From: Anna Taraday 
> Reply-To: OpenStack List 
> Date: Monday, April 3, 2017 at 11:53 AM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [neutron] Engine facade
>
>
>
> Hi!
>
> I'm a little confused change https://review.openstack.org/#/c/452539/ is
> about switching for new facade, does the master branch fails the same?
>
>
>
> On Mon, Apr 3, 2017 at 8:35 AM Gary Kotton  wrote:
>
> Yes, sorry my bad for not adding it -
> http://logs.openstack.org/39/452539/2/check/gate-vmware-nsx-python27-ubuntu-xenial/14c019c/testr_results.html.gz
>
> Please see the test test_create_port_dns_name
>
> Thanks
>
> Gary
>
>
>
> From: Kevin Benton 
> Reply-To: OpenStack List 
> Date: Monday, April 3, 2017 at 12:56 AM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [neutron] Engine facade
>
>
>
> Do you have a link to a traceback?
>
>
>
> On Apr 2, 2017 09:25, "Gary Kotton"  wrote:
>
> Hi,
>
> The change https://review.openstack.org/#/c/402750/ has broken the
> vmware-nsx plugin. I am not sure if this has had effect on any other
> decomposed plugins.
>
> One of the issues that we have is when we create a PortDNS object under a
> transaction we get an exception: DBReferenceError: (sqlite3.IntegrityError)
> FOREIGN KEY constraint failed [SQL: u'INSERT INTO portdnses (port_id,
> current_dns_name, current_dns_domain, previous_dns_name,
> previous_dns_domain, dns_name) VALUES (?, ?, ?, ?, ?, ?)'] [parameters:
> ('2f2039ac-e7e6-4cc3-a8a0-3298089d4afb', u'', u'', u'', u'',
> u'port-dns-name')]
>
> Any ideas?
>
> 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
>
> --
>
> Regards,
> Ann Taraday
>
>
> __
> 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] [qa][neutron-fwaas][networking-bgpvpn][nova-lxd] Removing old data_utils from Tempest

[Takashi Yamamoto]

thank you for heads up.

On Wed, Mar 15, 2017 at 2:18 AM, Ken'ichi Ohmichi  wrote:
> Hi,
>
> Many projects are using data_utils library which is provided by
> Tempest for creating test resources with random resource names.
> Now the library is provided as stable interface (tempest.lib) and old
> unstable interface (tempest.common) will be removed after most
> projects are switching to the new one.
> We can see remaining projects from
> https://review.openstack.org/#/q/status:open+branch:master+topic:tempest-data_utils

are you going to backport?

>
> I hope these patches also can be merged before the
> patch(https://review.openstack.org/#/c/72/) which removes the old
> one to keep all gates stable.
>
> Thanks
> Ken Ohmichi
>
> __
> 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] [QA][blazar][ceilometer][congress][intel-nfv-ci-tests][ironic][manila][networking-bgpvpn][networking-fortinet][networking-sfc][neutron][neutron-fwaas][neutron-lbaas][nova-lxd][octa

[Takashi Yamamoto]

hi,

On Mon, Feb 27, 2017 at 8:34 PM, Andrea Frittoli
 wrote:
> Hello folks,
>
> TL;DR: if today you import manager,py from tempest.scenario please maintain
> a copy of [0] in tree until further notice.
>
> Full message:
> --
>
> One of the priorities for the QA team in the Pike cycle is to refactor
> scenario tests to a sane code base [1].
>
> As they are now, changes to scenario tests are difficult to develop and
> review, and failures in those tests are hard to debug, which is in many
> directions far away from where we need to be.
>
> The issue we face is that, even though tempest.scenario.manager is not
> advertised as a stable interface in Tempest, many project use it today for
> convenience in writing their own tests. We don't know about dependencies
> outside of the OpenStack ecosystem, but we want to try to make this refactor
> a smooth experience for our uses in OpenStack, and avoid painful gate
> breakages as much as possible.
>
> The process we're proposing is as follows:
> - hold a copy of [0] in tree - in most cases you won't even have to change
> your imports as a lot of projects use tempest/scenario in their code base.
> You may decide to include the bare minimum you need from that module instead
> of all of it. It's a bit more work to make the patch, but less un-used code
> lying around afterwards.

i submitted patches for a few repos.
https://review.openstack.org/#/q/status:open++branch:master+topic:tempest-manager
i'd suggest to use the same gerrit topic for relevant patches.

> - the QA team will refactor scenario tests, and make more interfaces stable
> (test.py, credential providers). We won't advertise every single change in
> this process, only when we start and once we're done.
> - you may decide to discard your local copy of manager.py and consume
> Tempest stable interfaces directly. We will help with any question you may
> have on the process and on Tempest interfaces.
>
> Repositories affected by the refactor are (based on [2]):
>
> blazar,ceilometer,congress,intel-nfv-ci-tests,ironic,manila,networking-bgpvpn,networking-fortinet,networking-sfc,neutron-fwaas,neutron-lbaas,nova-lxd,octavia,sahara-tests,tap-as-a-service,tempest-horizon,vmware-nsx,watcher
>
> If we don't hear from a team at all in the next two weeks, we will assume
> that the corresponding Tempest plugin / bunch of tests is not in use
> anymore, and ignore it. If you use tempest.scenario.manager.py today and
> your repo is not on the list, please let us know!
>
> I'm happy to propose an initial patch for any team that may require it -
> just ping me on IRC (andreaf).
> I won't have the bandwidth myself to babysit each patch through review and
> gate though.
>
> Thank you for your cooperation and patience!
>
> Andrea
>
> [0]
> http://git.openstack.org/cgit/openstack/tempest/tree/tempest/scenario/manager.py
> [1] https://etherpad.openstack.org/p/pike-qa-priorities
> [2]
> https://github.com/andreafrittoli/tempest_stable_interfaces/blob/master/data/get_deps.sh
>
> __
> 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] Problem in visualizing port-mirroring information

[Takashi Yamamoto]

On Tue, Feb 28, 2017 at 4:05 PM, Manik Bindlish
 wrote:
> Hi All,
>
>
>
> I am facing an issue in visualizing port-mirroring information.
>
>
>
> 1.)Created 2 VMs:
>
> VM1:  ubuntu3(10.0.0.3,  floating IP: 192.168.200.252) – Tap service created
>
> VM2:  ubuntu2(10.0.0.12,  floating ip: 192.168.200.250) – Tap flow created
>
> 2.)Connected to bridge router: br-ex(192.168.200.11)
>
> 3.)Pinging google is possible and can be check from br-ex
>
>
>
> Problem: Not able to get the packet info on ubuntu3 where tap service is
> running.
>
>
>
> Ports info:
>
> ubuntu@openstack-nti-11:/opt/stack/devstack$ neutron port-show
> 19526048-98d9-4e6c-8205-dddfcaf8f2b2
>
> neutron CLI is deprecated and will be removed in the future. Use openstack
> CLI instead.
>
> +---+-+
>
> | Field | Value
> |
>
> +---+-+
>
> | admin_state_up| True
> |
>
> | allowed_address_pairs |
> |
>
> | binding:host_id   | openstack-nti-11
> |
>
> | binding:profile   | {}
> |
>
> | binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug": true}
> |
>
> | binding:vif_type  | ovs
> |
>
> | binding:vnic_type | normal
> |
>
> | created_at| 2017-02-22T09:59:51Z
> |
>
> | description   |
> |
>
> | device_id | 843fe80f-971a-43e3-986c-31d19bef3898
> |
>
> | device_owner  | compute:None
> |
>
> | extra_dhcp_opts   |
> |
>
> | fixed_ips | {"subnet_id":
> "398b77d2-49aa-4d29-ac4d-f0fd14943120", "ip_address": "10.0.0.3"}
> |
>
> |   | {"subnet_id":
> "401e3dde-1504-4620-8bbc-0ad6e54b0570", "ip_address":
> "fdaa:99df:2497:0:f816:3eff:feeb:52f2"} |
>
> | id| 19526048-98d9-4e6c-8205-dddfcaf8f2b2
> |
>
> | mac_address   | fa:16:3e:eb:52:f2
> |
>
> | name  |
> |
>
> | network_id| 7fae0053-aeeb-44ac-9336-41b9cae8a9ba
> |
>
> | port_security_enabled | True

have you tried to disable port security?

> |
>
> | project_id| 9c342a60b7cd4e8cacc8c5f6f92e80e6
> |
>
> | revision_number   | 10
> |
>
> | security_groups   | 13e4320a-bc74-4303-a55d-67a0f092a066
> |
>
> | status| ACTIVE
> |
>
> | tags  |
> |
>
> | tenant_id | 9c342a60b7cd4e8cacc8c5f6f92e80e6
> |
>
> | updated_at| 2017-02-22T10:00:10Z
> |
>
> +---+-+
>
>
>
>
>
> ubuntu@openstack-nti-11:/opt/stack/devstack$ neutron port-show
> dde6689e-4f0f-4fe2-9d28-1182ef03e113
>
> neutron CLI is deprecated and will be removed in the future. Use openstack
> CLI instead.
>
> +---+-+
>
> | Field | Value
> |
>
> +---+-+
>
> | admin_state_up| True
> |
>
> | allowed_address_pairs |
> |
>
> | binding:host_id   | openstack-nti-11
> |
>
> | binding:profile   | {}
> |
>
> | binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug": true}
> |
>
> | binding:vif_type  | ovs
> |
>
> | binding:vnic_type | normal
> |
>
> | created_at| 2017-02-27T10:13:51Z
> |
>
> | description   |
> |
>
> | device_id | 1582911f-ed59-43d6-9711-0e505db5413b
> |
>
> | device_owner  | compute:None
> |
>
> | extra_dhcp_opts   |
> |
>
> | fixed_ips | {"subnet_id":
> "398b77d2-49aa-4d29-ac4d-f0fd14943120", "ip_address": "10.0.0.12"}
> |
>
> |   | {"subnet_id":
> "401e3dde-1504-4620-8bbc-0ad6e54b0570", "ip_address":
> "fdaa:99df:2497:0:f816:3eff:fe58:4d36"} |
>
> | id| dde6689e-4f0f-4fe2-9d28-1182ef03e113
> |
>
> | mac_address   | fa:16:3e:58:4d:36
> |
>
> | name  |
> |
>
> | network_id| 7fae0053-aeeb-44ac-9336-41b9cae8a9ba
> |
>
> | port_security_enabled | True
> |
>
> | project_id| 9c342a60b7cd4e8cacc8c5f6f92e80e6
> |
>
> | revision_number   | 10
> |
>
> | security_groups   | 13e4320a-bc74-4303-a55d-67a0f092a066
> |
>
> | status| ACTIVE
> |
>
> | tags  |
> |
>
> | tenant_id | 9c342a60b7cd4e8cacc8c5f6f92e80e6
> |
>
> | updated_at| 2017-02-27T10:14:02Z
> |
>
> +---+-+
>
>
>
> Tap Service:
>
> ubuntu@openstack-nti-11:/opt/stack/devstack$ neutron tap-service-show
> 

[openstack-dev] [neutron] vpnaas driver maintainers

[Takashi Yamamoto]

hi,

i want to document who cares which drivers.
https://review.openstack.org/#/c/436081/
please comment on the review if you know an appropriate contact person
for each drivers.

btw, is the following a driver for neutron-vpnaas?  i couldn't find
documentation.
vmware_nsx/plugins/nsx_v/vshield/edge_ipsecvpn_driver.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] - Neutron team social in Atlanta on Thursday

[Takashi Yamamoto]

+1

2017/02/18 4:21 "Kevin Benton" :

Hi all,

I'm organizing a Neutron social event for Thursday evening in Atlanta
somewhere near the venue for dinner/drinks. If you're interested, please
reply to this email with a "+1" so I can get a general count for a
reservation.

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
__
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] [stadium] subprojects on independent release cycle

[Takashi Yamamoto]

On Thu, Feb 9, 2017 at 7:47 AM, Takashi Yamamoto <yamam...@midokura.com> wrote:
> i plan to cut a release for networking-midonet once relevant projects get 
> ready.
> ie. neutron-vpnaas, tap-as-a-service

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

>
> On Thu, Feb 9, 2017 at 1:16 AM, Armando M. <arma...@gmail.com> wrote:
>>
>>
>> On 2 February 2017 at 16:09, Armando M. <arma...@gmail.com> wrote:
>>>
>>> Hi neutrinos,
>>>
>>> I have put a number of patches in the merge queue for a few sub-projects.
>>> We currently have a number of these that are on an independent release
>>> schedule. In particular:
>>>
>>> networking-bagpipe
>>> networking-bgpvpn
>>> networking-midonet
>>> networking-odl
>>> networking-sfc
>>>
>>> Please make sure that between now and March 10th [1], you work to prepare
>>> at least one ocata release that works with neutron's [2] and cut a stable
>>> branch before than. That would incredibly help consumers who are interested
>>> in assembling these bits together and start testing ocata as soon as it's
>>> out.
>>>
>>> Your collaboration is much appreciated.
>>>
>>> Many thanks,
>>> Armando
>>
>>
>> Hi neutrinos,
>>
>> I did not hear anything back from the liaisons of the above mentioned
>> project over the past few days. Can you clarify your plans for cutting an
>> Ocata release?
>>
>> Thanks,
>> Armando
>>
>>>
>>> [1] https://releases.openstack.org/ocata/schedule.html
>>> [2] https://review.openstack.org/#/c/428474/
>>
>>
>>
>> __
>> 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] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

On Tue, Feb 14, 2017 at 8:15 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Takashi Yamamoto's message of 2017-02-14 07:31:34 +0900:
>> hi,
>>
>> On Tue, Feb 14, 2017 at 1:54 AM, Doug Hellmann <d...@doughellmann.com> wrote:
>> > Excerpts from Takashi Yamamoto's message of 2017-02-06 10:32:10 +0900:
>> >> On Wed, Feb 1, 2017 at 9:46 AM, Takashi Yamamoto <yamam...@midokura.com> 
>> >> wrote:
>> >> > hi,
>> >> >
>> >> > On Fri, Jan 27, 2017 at 7:46 AM, Doug Hellmann <d...@doughellmann.com> 
>> >> > wrote:
>> >> >> Excerpts from Takashi Yamamoto's message of 2017-01-26 11:42:48 +0900:
>> >> >>> hi,
>> >> >>>
>> >> >>> On Sat, Jan 14, 2017 at 2:17 AM, Doug Hellmann 
>> >> >>> <d...@doughellmann.com> wrote:
>> >> >>> > Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 
>> >> >>> > -0600:
>> >> >>> >> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto 
>> >> >>> >> <yamam...@midokura.com>:
>> >> >>> >> > hi,
>> >> >>> >> >
>> >> >>> >> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M. <arma...@gmail.com> 
>> >> >>> >> > wrote:
>> >> >>> >> >> Hi
>> >> >>> >> >>
>> >> >>> >> >> As of today, the project neutron-vpnaas is no longer part of 
>> >> >>> >> >> the neutron
>> >> >>> >> >> governance. This was a decision reached after the project saw a 
>> >> >>> >> >> dramatic
>> >> >>> >> >> drop in active development over a prolonged period of time.
>> >> >>> >> >>
>> >> >>> >> >> What does this mean in practice?
>> >> >>> >> >>
>> >> >>> >> >> From a visibility point of view, release notes and 
>> >> >>> >> >> documentation will no
>> >> >>> >> >> longer appear on openstack.org as of Ocata going forward.
>> >> >>> >> >> No more releases will be published by the neutron release team.
>> >> >>> >> >> The neutron team will stop proposing fixes for the upstream CI, 
>> >> >>> >> >> if not
>> >> >>> >> >> solely on a voluntary basis (e.g. I still felt like proposing 
>> >> >>> >> >> [2]).
>> >> >>> >> >>
>> >> >>> >> >> How does it affect you, the user or the deployer?
>> >> >>> >> >>
>> >> >>> >> >> You can continue to use vpnaas and its CLI via the 
>> >> >>> >> >> python-neutronclient and
>> >> >>> >> >> expect it to work with neutron up until the newton
>> >> >>> >> >> release/python-neutronclient 6.0.0. After this point, if you 
>> >> >>> >> >> want a release
>> >> >>> >> >> that works for Ocata or newer, you need to proactively request 
>> >> >>> >> >> a release
>> >> >>> >> >> [5], and reach out to a member of the neutron release team [3] 
>> >> >>> >> >> for approval.
>> >> >>> >> >
>> >> >>> >> > i want to make an ocata release. (and more importantly the 
>> >> >>> >> > stable branch,
>> >> >>> >> > for the benefit of consuming subprojects)
>> >> >>> >> > for the purpose, the next step would be ocata-3, right?
>> >> >>> >>
>> >> >>> >> Hey Takashi,
>> >> >>> >> If you want to release new version of neutron-vpnaas, please look 
>> >> >>> >> at [1].
>> >> >>> >> This is the place, which you need to update and based on provided
>> >> >>> >> details, tags and branches will be cut.
>> >> >>> >>
>> >> >>> >> [1] 
>> >> >>> >> https://github.com/openstack/releases/blob/

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

hi,

On Tue, Feb 14, 2017 at 1:54 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Takashi Yamamoto's message of 2017-02-06 10:32:10 +0900:
>> On Wed, Feb 1, 2017 at 9:46 AM, Takashi Yamamoto <yamam...@midokura.com> 
>> wrote:
>> > hi,
>> >
>> > On Fri, Jan 27, 2017 at 7:46 AM, Doug Hellmann <d...@doughellmann.com> 
>> > wrote:
>> >> Excerpts from Takashi Yamamoto's message of 2017-01-26 11:42:48 +0900:
>> >>> hi,
>> >>>
>> >>> On Sat, Jan 14, 2017 at 2:17 AM, Doug Hellmann <d...@doughellmann.com> 
>> >>> wrote:
>> >>> > Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 -0600:
>> >>> >> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto <yamam...@midokura.com>:
>> >>> >> > hi,
>> >>> >> >
>> >>> >> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M. <arma...@gmail.com> 
>> >>> >> > wrote:
>> >>> >> >> Hi
>> >>> >> >>
>> >>> >> >> As of today, the project neutron-vpnaas is no longer part of the 
>> >>> >> >> neutron
>> >>> >> >> governance. This was a decision reached after the project saw a 
>> >>> >> >> dramatic
>> >>> >> >> drop in active development over a prolonged period of time.
>> >>> >> >>
>> >>> >> >> What does this mean in practice?
>> >>> >> >>
>> >>> >> >> From a visibility point of view, release notes and documentation 
>> >>> >> >> will no
>> >>> >> >> longer appear on openstack.org as of Ocata going forward.
>> >>> >> >> No more releases will be published by the neutron release team.
>> >>> >> >> The neutron team will stop proposing fixes for the upstream CI, if 
>> >>> >> >> not
>> >>> >> >> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >>> >> >>
>> >>> >> >> How does it affect you, the user or the deployer?
>> >>> >> >>
>> >>> >> >> You can continue to use vpnaas and its CLI via the 
>> >>> >> >> python-neutronclient and
>> >>> >> >> expect it to work with neutron up until the newton
>> >>> >> >> release/python-neutronclient 6.0.0. After this point, if you want 
>> >>> >> >> a release
>> >>> >> >> that works for Ocata or newer, you need to proactively request a 
>> >>> >> >> release
>> >>> >> >> [5], and reach out to a member of the neutron release team [3] for 
>> >>> >> >> approval.
>> >>> >> >
>> >>> >> > i want to make an ocata release. (and more importantly the stable 
>> >>> >> > branch,
>> >>> >> > for the benefit of consuming subprojects)
>> >>> >> > for the purpose, the next step would be ocata-3, right?
>> >>> >>
>> >>> >> Hey Takashi,
>> >>> >> If you want to release new version of neutron-vpnaas, please look at 
>> >>> >> [1].
>> >>> >> This is the place, which you need to update and based on provided
>> >>> >> details, tags and branches will be cut.
>> >>> >>
>> >>> >> [1] 
>> >>> >> https://github.com/openstack/releases/blob/master/deliverables/ocata/neutron-vpnaas.yaml
>> >>> >
>> >>> > Unfortunately, since vpnaas is no longer part of an official project,
>> >>> > we won't be using the releases repository to manage and publish
>> >>> > information about the releases. It'll need to be done by hand.
>> >>>
>> >>> who can/should do it by hand?
>> >>
>> >> I can do it. Let me know the version number, and for each repository the
>> >> SHA of the commit on the master branch to be tagged.
>>
>> please make it with the following.  thank you!
>>
>> stable/ocata
>> 10.0.0
>> openstack/neutron-vpnaas
>> d6db1238a4950df03dfb28acabcf4df14ebfa3ac
>
> Sorry, I missed this email earlier.

no problem!

>
> Do you want 10.0.0 or 10.0.0.0rc1?

10.0.0.

>
> Doug
>
>>
>> >
>> > thank you. i'll ask you when necessary.
>> >
>> > i think it's fine to just make a branch from master when stable branch is 
>> > cut
>> > for neutron.  how others think?
>> >
>> >>
>> >> Doug
>> >>
>> >>>
>> >>> >
>> >>> > Doug
>> >>> >
>> >>> >>
>> >>> >> BR, Dariusz
>> >>> >>
>> >>> >
>> >>> > __
>> >>> > OpenStack Development Mailing List (not for usage questions)
>> >>> > Unsubscribe: 
>> >>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>
>> >>
>> >> __
>> >> 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][taas] ocata

[Takashi Yamamoto]

done.

vinay or anil, can you update launchpad?  i don't have permission.

On Wed, Feb 8, 2017 at 3:36 PM, Soichi Shigeta
 wrote:
>
>  Hi Yamamoto,
>
>We discussed this on today's IRC and agreed to make an ocata release.
>
>Best regards,
>Soichi
>
>
>
>> tap-as-a-service folks,
>>
>> unless anyone objects, i'll make a ocata release and thus stable
>> branch this week.
>> (otherwise the CI of consuming subprojects will break)
>>
>> __
>> 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] [stadium] subprojects on independent release cycle

[Takashi Yamamoto]

i plan to cut a release for networking-midonet once relevant projects get ready.
ie. neutron-vpnaas, tap-as-a-service

On Thu, Feb 9, 2017 at 1:16 AM, Armando M.  wrote:
>
>
> On 2 February 2017 at 16:09, Armando M.  wrote:
>>
>> Hi neutrinos,
>>
>> I have put a number of patches in the merge queue for a few sub-projects.
>> We currently have a number of these that are on an independent release
>> schedule. In particular:
>>
>> networking-bagpipe
>> networking-bgpvpn
>> networking-midonet
>> networking-odl
>> networking-sfc
>>
>> Please make sure that between now and March 10th [1], you work to prepare
>> at least one ocata release that works with neutron's [2] and cut a stable
>> branch before than. That would incredibly help consumers who are interested
>> in assembling these bits together and start testing ocata as soon as it's
>> out.
>>
>> Your collaboration is much appreciated.
>>
>> Many thanks,
>> Armando
>
>
> Hi neutrinos,
>
> I did not hear anything back from the liaisons of the above mentioned
> project over the past few days. Can you clarify your plans for cutting an
> Ocata release?
>
> Thanks,
> Armando
>
>>
>> [1] https://releases.openstack.org/ocata/schedule.html
>> [2] https://review.openstack.org/#/c/428474/
>
>
>
> __
> 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] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

On Wed, Feb 1, 2017 at 9:51 AM, Takashi Yamamoto <yamam...@midokura.com> wrote:
> hi,
>
>>> That's great to hear Yamamoto. Since you are already a neutron-core I assume
>>> you are already intimate with the work required to strengthen the VPNaaS
>>> project. I have added you to [4] and you can lean on me for any changes that
>>> needs reviewing.
>
> i wrote a scenario test.
> https://review.openstack.org/#/c/424459/
> while it's working well with midonet, it seems failing with strongswan driver.
> is there any possibly related known issues with strongswan?

https://bugs.launchpad.net/neutron/+bug/1660899

__
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][networking-l2gw] ocata release?

[Takashi Yamamoto]

thank you.

On Mon, Feb 6, 2017 at 3:51 PM, Gary Kotton <gkot...@vmware.com> wrote:
> Hi,
> Yes, I will go and do this.
> Thanks
> Gary
>
> On 2/6/17, 4:05 AM, "Takashi Yamamoto" <yamam...@midokura.com> wrote:
>
> hi,
>
> is anyone going to cut ocata release/branch for networking-l2gw?
>
> __
> 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][networking-l2gw] ocata release?

[Takashi Yamamoto]

hi,

is anyone going to cut ocata release/branch for networking-l2gw?

__
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] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

On Wed, Feb 1, 2017 at 9:46 AM, Takashi Yamamoto <yamam...@midokura.com> wrote:
> hi,
>
> On Fri, Jan 27, 2017 at 7:46 AM, Doug Hellmann <d...@doughellmann.com> wrote:
>> Excerpts from Takashi Yamamoto's message of 2017-01-26 11:42:48 +0900:
>>> hi,
>>>
>>> On Sat, Jan 14, 2017 at 2:17 AM, Doug Hellmann <d...@doughellmann.com> 
>>> wrote:
>>> > Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 -0600:
>>> >> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto <yamam...@midokura.com>:
>>> >> > hi,
>>> >> >
>>> >> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M. <arma...@gmail.com> wrote:
>>> >> >> Hi
>>> >> >>
>>> >> >> As of today, the project neutron-vpnaas is no longer part of the 
>>> >> >> neutron
>>> >> >> governance. This was a decision reached after the project saw a 
>>> >> >> dramatic
>>> >> >> drop in active development over a prolonged period of time.
>>> >> >>
>>> >> >> What does this mean in practice?
>>> >> >>
>>> >> >> From a visibility point of view, release notes and documentation will 
>>> >> >> no
>>> >> >> longer appear on openstack.org as of Ocata going forward.
>>> >> >> No more releases will be published by the neutron release team.
>>> >> >> The neutron team will stop proposing fixes for the upstream CI, if not
>>> >> >> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>>> >> >>
>>> >> >> How does it affect you, the user or the deployer?
>>> >> >>
>>> >> >> You can continue to use vpnaas and its CLI via the 
>>> >> >> python-neutronclient and
>>> >> >> expect it to work with neutron up until the newton
>>> >> >> release/python-neutronclient 6.0.0. After this point, if you want a 
>>> >> >> release
>>> >> >> that works for Ocata or newer, you need to proactively request a 
>>> >> >> release
>>> >> >> [5], and reach out to a member of the neutron release team [3] for 
>>> >> >> approval.
>>> >> >
>>> >> > i want to make an ocata release. (and more importantly the stable 
>>> >> > branch,
>>> >> > for the benefit of consuming subprojects)
>>> >> > for the purpose, the next step would be ocata-3, right?
>>> >>
>>> >> Hey Takashi,
>>> >> If you want to release new version of neutron-vpnaas, please look at [1].
>>> >> This is the place, which you need to update and based on provided
>>> >> details, tags and branches will be cut.
>>> >>
>>> >> [1] 
>>> >> https://github.com/openstack/releases/blob/master/deliverables/ocata/neutron-vpnaas.yaml
>>> >
>>> > Unfortunately, since vpnaas is no longer part of an official project,
>>> > we won't be using the releases repository to manage and publish
>>> > information about the releases. It'll need to be done by hand.
>>>
>>> who can/should do it by hand?
>>
>> I can do it. Let me know the version number, and for each repository the
>> SHA of the commit on the master branch to be tagged.

please make it with the following.  thank you!

stable/ocata
10.0.0
openstack/neutron-vpnaas
d6db1238a4950df03dfb28acabcf4df14ebfa3ac

>
> thank you. i'll ask you when necessary.
>
> i think it's fine to just make a branch from master when stable branch is cut
> for neutron.  how others think?
>
>>
>> Doug
>>
>>>
>>> >
>>> > Doug
>>> >
>>> >>
>>> >> BR, Dariusz
>>> >>
>>> >
>>> > __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> 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][taas] ocata

[Takashi Yamamoto]

tap-as-a-service folks,

unless anyone objects, i'll make a ocata release and thus stable
branch this week.
(otherwise the CI of consuming subprojects will break)

__
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] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

hi,

>> That's great to hear Yamamoto. Since you are already a neutron-core I assume
>> you are already intimate with the work required to strengthen the VPNaaS
>> project. I have added you to [4] and you can lean on me for any changes that
>> needs reviewing.

i wrote a scenario test.
https://review.openstack.org/#/c/424459/
while it's working well with midonet, it seems failing with strongswan driver.
is there any possibly related known issues with strongswan?

__
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] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

hi,

On Fri, Jan 27, 2017 at 7:46 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Takashi Yamamoto's message of 2017-01-26 11:42:48 +0900:
>> hi,
>>
>> On Sat, Jan 14, 2017 at 2:17 AM, Doug Hellmann <d...@doughellmann.com> wrote:
>> > Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 -0600:
>> >> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto <yamam...@midokura.com>:
>> >> > hi,
>> >> >
>> >> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M. <arma...@gmail.com> wrote:
>> >> >> Hi
>> >> >>
>> >> >> As of today, the project neutron-vpnaas is no longer part of the 
>> >> >> neutron
>> >> >> governance. This was a decision reached after the project saw a 
>> >> >> dramatic
>> >> >> drop in active development over a prolonged period of time.
>> >> >>
>> >> >> What does this mean in practice?
>> >> >>
>> >> >> From a visibility point of view, release notes and documentation will 
>> >> >> no
>> >> >> longer appear on openstack.org as of Ocata going forward.
>> >> >> No more releases will be published by the neutron release team.
>> >> >> The neutron team will stop proposing fixes for the upstream CI, if not
>> >> >> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >> >>
>> >> >> How does it affect you, the user or the deployer?
>> >> >>
>> >> >> You can continue to use vpnaas and its CLI via the 
>> >> >> python-neutronclient and
>> >> >> expect it to work with neutron up until the newton
>> >> >> release/python-neutronclient 6.0.0. After this point, if you want a 
>> >> >> release
>> >> >> that works for Ocata or newer, you need to proactively request a 
>> >> >> release
>> >> >> [5], and reach out to a member of the neutron release team [3] for 
>> >> >> approval.
>> >> >
>> >> > i want to make an ocata release. (and more importantly the stable 
>> >> > branch,
>> >> > for the benefit of consuming subprojects)
>> >> > for the purpose, the next step would be ocata-3, right?
>> >>
>> >> Hey Takashi,
>> >> If you want to release new version of neutron-vpnaas, please look at [1].
>> >> This is the place, which you need to update and based on provided
>> >> details, tags and branches will be cut.
>> >>
>> >> [1] 
>> >> https://github.com/openstack/releases/blob/master/deliverables/ocata/neutron-vpnaas.yaml
>> >
>> > Unfortunately, since vpnaas is no longer part of an official project,
>> > we won't be using the releases repository to manage and publish
>> > information about the releases. It'll need to be done by hand.
>>
>> who can/should do it by hand?
>
> I can do it. Let me know the version number, and for each repository the
> SHA of the commit on the master branch to be tagged.

thank you. i'll ask you when necessary.

i think it's fine to just make a branch from master when stable branch is cut
for neutron.  how others think?

>
> Doug
>
>>
>> >
>> > Doug
>> >
>> >>
>> >> BR, Dariusz
>> >>
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> 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] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

hi,

On Sat, Jan 14, 2017 at 2:17 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 -0600:
>> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto <yamam...@midokura.com>:
>> > hi,
>> >
>> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M. <arma...@gmail.com> wrote:
>> >> Hi
>> >>
>> >> As of today, the project neutron-vpnaas is no longer part of the neutron
>> >> governance. This was a decision reached after the project saw a dramatic
>> >> drop in active development over a prolonged period of time.
>> >>
>> >> What does this mean in practice?
>> >>
>> >> From a visibility point of view, release notes and documentation will no
>> >> longer appear on openstack.org as of Ocata going forward.
>> >> No more releases will be published by the neutron release team.
>> >> The neutron team will stop proposing fixes for the upstream CI, if not
>> >> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >>
>> >> How does it affect you, the user or the deployer?
>> >>
>> >> You can continue to use vpnaas and its CLI via the python-neutronclient 
>> >> and
>> >> expect it to work with neutron up until the newton
>> >> release/python-neutronclient 6.0.0. After this point, if you want a 
>> >> release
>> >> that works for Ocata or newer, you need to proactively request a release
>> >> [5], and reach out to a member of the neutron release team [3] for 
>> >> approval.
>> >
>> > i want to make an ocata release. (and more importantly the stable branch,
>> > for the benefit of consuming subprojects)
>> > for the purpose, the next step would be ocata-3, right?
>>
>> Hey Takashi,
>> If you want to release new version of neutron-vpnaas, please look at [1].
>> This is the place, which you need to update and based on provided
>> details, tags and branches will be cut.
>>
>> [1] 
>> https://github.com/openstack/releases/blob/master/deliverables/ocata/neutron-vpnaas.yaml
>
> Unfortunately, since vpnaas is no longer part of an official project,
> we won't be using the releases repository to manage and publish
> information about the releases. It'll need to be done by hand.

who can/should do it by hand?

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

__
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] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

hi,

On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
> Hi
>
> As of today, the project neutron-vpnaas is no longer part of the neutron
> governance. This was a decision reached after the project saw a dramatic
> drop in active development over a prolonged period of time.
>
> What does this mean in practice?
>
> From a visibility point of view, release notes and documentation will no
> longer appear on openstack.org as of Ocata going forward.
> No more releases will be published by the neutron release team.
> The neutron team will stop proposing fixes for the upstream CI, if not
> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>
> How does it affect you, the user or the deployer?
>
> You can continue to use vpnaas and its CLI via the python-neutronclient and
> expect it to work with neutron up until the newton
> release/python-neutronclient 6.0.0. After this point, if you want a release
> that works for Ocata or newer, you need to proactively request a release
> [5], and reach out to a member of the neutron release team [3] for approval.

i want to make an ocata release. (and more importantly the stable branch,
for the benefit of consuming subprojects)
for the purpose, the next step would be ocata-3, right?

> Assuming that the vpnaas CI is green, you can expect to have a working
> vpnaas system upon release of its package in the foreseeable future.
> Outstanding bugs and new bug reports will be rejected on the basis of lack
> of engineering resources interested in helping out in the typical OpenStack
> review workflow.
> Since we are freezing the development of the neutron CLI in favor of the
> openstack unified client (OSC), the lack of a plan to make the VPN commands
> available in the OSC CLI means that at some point in the future the neutron
> client CLI support for vpnaas may be dropped (though I don't expect this to
> happen any time soon).
>
> Can this be reversed?
>
> If you are interested in reversing this decision, now it is time to step up.
> That said, we won't be reversing the decision for Ocata. There is quite a
> curve to ramp up to make neutron-vpnaas worthy of being classified as a
> neutron stadium project, and that means addressing all the gaps identified
> in [6]. If you are interested, please reach out, and I will work with you to
> add your account to [4], so that you can drive the neutron-vpnaas agenda
> going forward.
>
> Please do not hesitate to reach out to ask questions and/or clarifications.
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/392010/
> [2] https://review.openstack.org/#/c/397924/
> [3] https://review.openstack.org/#/admin/groups/150,members
> [4] https://review.openstack.org/#/admin/groups/502,members
> [5] https://github.com/openstack/releases
> [6]
> http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

On Thu, Dec 1, 2016 at 1:02 AM, Armando M. <arma...@gmail.com> wrote:
>
>
> On 27 November 2016 at 20:50, Takashi Yamamoto <yamam...@midokura.com>
> wrote:
>>
>> On Wed, Nov 16, 2016 at 11:02 AM, Armando M. <arma...@gmail.com> wrote:
>> > Hi
>> >
>> > As of today, the project neutron-vpnaas is no longer part of the neutron
>> > governance. This was a decision reached after the project saw a dramatic
>> > drop in active development over a prolonged period of time.
>> >
>> > What does this mean in practice?
>> >
>> > From a visibility point of view, release notes and documentation will no
>> > longer appear on openstack.org as of Ocata going forward.
>> > No more releases will be published by the neutron release team.
>> > The neutron team will stop proposing fixes for the upstream CI, if not
>> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >
>> > How does it affect you, the user or the deployer?
>> >
>> > You can continue to use vpnaas and its CLI via the python-neutronclient
>> > and
>> > expect it to work with neutron up until the newton
>> > release/python-neutronclient 6.0.0. After this point, if you want a
>> > release
>> > that works for Ocata or newer, you need to proactively request a release
>> > [5], and reach out to a member of the neutron release team [3] for
>> > approval.
>> > Assuming that the vpnaas CI is green, you can expect to have a working
>> > vpnaas system upon release of its package in the foreseeable future.
>> > Outstanding bugs and new bug reports will be rejected on the basis of
>> > lack
>> > of engineering resources interested in helping out in the typical
>> > OpenStack
>> > review workflow.
>> > Since we are freezing the development of the neutron CLI in favor of the
>> > openstack unified client (OSC), the lack of a plan to make the VPN
>> > commands
>> > available in the OSC CLI means that at some point in the future the
>> > neutron
>> > client CLI support for vpnaas may be dropped (though I don't expect this
>> > to
>> > happen any time soon).
>> >
>> > Can this be reversed?
>> >
>> > If you are interested in reversing this decision, now it is time to step
>> > up.
>> > That said, we won't be reversing the decision for Ocata. There is quite
>> > a
>> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
>> > neutron stadium project, and that means addressing all the gaps
>> > identified
>> > in [6]. If you are interested, please reach out, and I will work with
>> > you to
>> > add your account to [4], so that you can drive the neutron-vpnaas agenda
>> > going forward.
>> >
>> > Please do not hesitate to reach out to ask questions and/or
>> > clarifications.
>>
>> hi,
>>
>> i'm interested in working on the project.
>> well, at least on the parts which is used by networking-midonet.
>
>
> That's great to hear Yamamoto. Since you are already a neutron-core I assume
> you are already intimate with the work required to strengthen the VPNaaS
> project. I have added you to [4] and you can lean on me for any changes that
> needs reviewing.

these fixes for gate jobs need review:
https://review.openstack.org/#/c/410511/
https://review.openstack.org/#/c/410530/
https://review.openstack.org/#/c/419396/

>
>>
>>
>> >
>> > Cheers,
>> > Armando
>> >
>> > [1] https://review.openstack.org/#/c/392010/
>> > [2] https://review.openstack.org/#/c/397924/
>> > [3] https://review.openstack.org/#/admin/groups/150,members
>> > [4] https://review.openstack.org/#/admin/groups/502,members
>> > [5] https://github.com/openstack/releases
>> > [6]
>> >
>> > http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.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 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] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

hi,

On Sat, Dec 3, 2016 at 4:07 PM, Lingxian Kong <anlin.k...@gmail.com> wrote:
> Hi, Takashi,
>
> Thanks for working on this project, we (Catalyst Cloud) also provide VPNaaS
> in our OpenStack based public cloud, so maybe we can also provide help from
> our side.

which driver are you using?

>
>
> Cheers,
> Lingxian Kong (Larry)
>
> On Mon, Nov 28, 2016 at 5:50 PM, Takashi Yamamoto <yamam...@midokura.com>
> wrote:
>>
>> On Wed, Nov 16, 2016 at 11:02 AM, Armando M. <arma...@gmail.com> wrote:
>> > Hi
>> >
>> > As of today, the project neutron-vpnaas is no longer part of the neutron
>> > governance. This was a decision reached after the project saw a dramatic
>> > drop in active development over a prolonged period of time.
>> >
>> > What does this mean in practice?
>> >
>> > From a visibility point of view, release notes and documentation will no
>> > longer appear on openstack.org as of Ocata going forward.
>> > No more releases will be published by the neutron release team.
>> > The neutron team will stop proposing fixes for the upstream CI, if not
>> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >
>> > How does it affect you, the user or the deployer?
>> >
>> > You can continue to use vpnaas and its CLI via the python-neutronclient
>> > and
>> > expect it to work with neutron up until the newton
>> > release/python-neutronclient 6.0.0. After this point, if you want a
>> > release
>> > that works for Ocata or newer, you need to proactively request a release
>> > [5], and reach out to a member of the neutron release team [3] for
>> > approval.
>> > Assuming that the vpnaas CI is green, you can expect to have a working
>> > vpnaas system upon release of its package in the foreseeable future.
>> > Outstanding bugs and new bug reports will be rejected on the basis of
>> > lack
>> > of engineering resources interested in helping out in the typical
>> > OpenStack
>> > review workflow.
>> > Since we are freezing the development of the neutron CLI in favor of the
>> > openstack unified client (OSC), the lack of a plan to make the VPN
>> > commands
>> > available in the OSC CLI means that at some point in the future the
>> > neutron
>> > client CLI support for vpnaas may be dropped (though I don't expect this
>> > to
>> > happen any time soon).
>> >
>> > Can this be reversed?
>> >
>> > If you are interested in reversing this decision, now it is time to step
>> > up.
>> > That said, we won't be reversing the decision for Ocata. There is quite
>> > a
>> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
>> > neutron stadium project, and that means addressing all the gaps
>> > identified
>> > in [6]. If you are interested, please reach out, and I will work with
>> > you to
>> > add your account to [4], so that you can drive the neutron-vpnaas agenda
>> > going forward.
>> >
>> > Please do not hesitate to reach out to ask questions and/or
>> > clarifications.
>>
>> hi,
>>
>> i'm interested in working on the project.
>> well, at least on the parts which is used by networking-midonet.
>>
>> >
>> > Cheers,
>> > Armando
>> >
>> > [1] https://review.openstack.org/#/c/392010/
>> > [2] https://review.openstack.org/#/c/397924/
>> > [3] https://review.openstack.org/#/admin/groups/150,members
>> > [4] https://review.openstack.org/#/admin/groups/502,members
>> > [5] https://github.com/openstack/releases
>> > [6]
>> >
>> > http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.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 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] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

hi,

On Sat, Dec 3, 2016 at 4:07 PM, Lingxian Kong <anlin.k...@gmail.com> wrote:
> Hi, Takashi,
>
> Thanks for working on this project, we (Catalyst Cloud) also provide VPNaaS
> in our OpenStack based public cloud, so maybe we can also provide help from
> our side.

thank you!
it's great to hear the project has more demands.

>
>
> Cheers,
> Lingxian Kong (Larry)
>
> On Mon, Nov 28, 2016 at 5:50 PM, Takashi Yamamoto <yamam...@midokura.com>
> wrote:
>>
>> On Wed, Nov 16, 2016 at 11:02 AM, Armando M. <arma...@gmail.com> wrote:
>> > Hi
>> >
>> > As of today, the project neutron-vpnaas is no longer part of the neutron
>> > governance. This was a decision reached after the project saw a dramatic
>> > drop in active development over a prolonged period of time.
>> >
>> > What does this mean in practice?
>> >
>> > From a visibility point of view, release notes and documentation will no
>> > longer appear on openstack.org as of Ocata going forward.
>> > No more releases will be published by the neutron release team.
>> > The neutron team will stop proposing fixes for the upstream CI, if not
>> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >
>> > How does it affect you, the user or the deployer?
>> >
>> > You can continue to use vpnaas and its CLI via the python-neutronclient
>> > and
>> > expect it to work with neutron up until the newton
>> > release/python-neutronclient 6.0.0. After this point, if you want a
>> > release
>> > that works for Ocata or newer, you need to proactively request a release
>> > [5], and reach out to a member of the neutron release team [3] for
>> > approval.
>> > Assuming that the vpnaas CI is green, you can expect to have a working
>> > vpnaas system upon release of its package in the foreseeable future.
>> > Outstanding bugs and new bug reports will be rejected on the basis of
>> > lack
>> > of engineering resources interested in helping out in the typical
>> > OpenStack
>> > review workflow.
>> > Since we are freezing the development of the neutron CLI in favor of the
>> > openstack unified client (OSC), the lack of a plan to make the VPN
>> > commands
>> > available in the OSC CLI means that at some point in the future the
>> > neutron
>> > client CLI support for vpnaas may be dropped (though I don't expect this
>> > to
>> > happen any time soon).
>> >
>> > Can this be reversed?
>> >
>> > If you are interested in reversing this decision, now it is time to step
>> > up.
>> > That said, we won't be reversing the decision for Ocata. There is quite
>> > a
>> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
>> > neutron stadium project, and that means addressing all the gaps
>> > identified
>> > in [6]. If you are interested, please reach out, and I will work with
>> > you to
>> > add your account to [4], so that you can drive the neutron-vpnaas agenda
>> > going forward.
>> >
>> > Please do not hesitate to reach out to ask questions and/or
>> > clarifications.
>>
>> hi,
>>
>> i'm interested in working on the project.
>> well, at least on the parts which is used by networking-midonet.
>>
>> >
>> > Cheers,
>> > Armando
>> >
>> > [1] https://review.openstack.org/#/c/392010/
>> > [2] https://review.openstack.org/#/c/397924/
>> > [3] https://review.openstack.org/#/admin/groups/150,members
>> > [4] https://review.openstack.org/#/admin/groups/502,members
>> > [5] https://github.com/openstack/releases
>> > [6]
>> >
>> > http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.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 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] [release] Re: [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Takashi Yamamoto]

On Tue, Nov 29, 2016 at 11:53 AM, Takashi Yamamoto
<yamam...@midokura.com> wrote:
> release team,
>
> can we (networking-midonet) branch stable/newton from a past commit
> with a RC tag, backport some changes [1], and then cut the first release
> on the branch?

to answer myself, RC or beta-looking tag doesn't seem to be allowed for
release:independent projects. [1]
so i went ahead with 3.0.0. [2]

[1] 
https://github.com/openstack/releases/blob/745554fdec87b18fe0a39fa25cdc481b23f28d24/openstack_releases/versionutils.py#L48-L49
[2] https://review.openstack.org/#/c/404078/

>
> [1] some addititonal features without db migrations (qos, lbaasv2, ...) and
> removal of some unsupported code (lbaasv1, ...)
>
> On Fri, Nov 25, 2016 at 11:32 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>>
>>> On 25 Nov 2016, at 15:23, Takashi Yamamoto <yamam...@midokura.com> wrote:
>>>
>>> On Fri, Nov 25, 2016 at 8:02 PM, Ihar Hrachyshka <ihrac...@redhat.com> 
>>> wrote:
>>>>
>>>>> On 25 Nov 2016, at 11:02, Takashi Yamamoto <yamam...@midokura.com> wrote:
>>>>>
>>>>> On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka <ihrac...@redhat.com> 
>>>>> wrote:
>>>>>>
>>>>>>> On 25 Nov 2016, at 09:25, Takashi Yamamoto <yamam...@midokura.com> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka <ihrac...@redhat.com> 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On 25 Nov 2016, at 05:26, Takashi Yamamoto <yamam...@midokura.com> 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> hi,
>>>>>>>>>
>>>>>>>>> networking-midonet doesn't have stable/newton branch yet.
>>>>>>>>> newton jobs failures are false alarms.
>>>>>>>>>
>>>>>>>>> branching has been delayed because development of some futures
>>>>>>>>> planned for newton has not been completed yet.
>>>>>>>>>
>>>>>>>>> the plan is to revert ocata-specific changes after branching newton.
>>>>>>>>
>>>>>>>> I don’t think it’s a good idea since you will need to tag a release on 
>>>>>>>> branch creation, that is supposed to be compatible with next releases 
>>>>>>>> in that same branch.
>>>>>>>
>>>>>>> can't we create the tag after the revert?
>>>>>>>
>>>>>>
>>>>>> No, that’s release team requirement that they branch on a release tag.
>>>>>
>>>>> ok, i didn't know the requirement. thank you.
>>>>>
>>>>>>
>>>>>>> anyway no one think this is a good idea.
>>>>>>> it's just an unfortunate compromise we ended up.
>>>>>>> we are trying to make the schedule better for next release.
>>>>>>
>>>>>> It would make more sense to tag on a compatible commit from the past and 
>>>>>> consider it a first stable release. (Of course it means that feature 
>>>>>> development would need to be aligned appropriately.)
>>>>>
>>>>> in that case, can we backport the features?
>>>>> (namely qos and lbaas drivers are in my mind)
>>>>
>>>> No, I don’t think so. Though maybe we can release an RC as the first tag 
>>>> in the branch and backport features before releasing a final version? I 
>>>> dunno, I guess you will need to talk to OpenStack release folks on how to 
>>>> proceed.
>>>
>>> is it a release team matter?
>>> i thought these were a policy inside neutron.
>>> after all networking-midonet is release:independent.
>>
>> Neutron does not override global policies. I explicitly asked during the 
>> last summit if we can branch before a tag; the answer was no, it’s not an 
>> option.
>>
>> Adding [release] tag since it becomes a matter beyond neutron.
>>
>> 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] [tap-as-a-service] stable/newton 'broken'

[Takashi Yamamoto]

On Mon, Nov 28, 2016 at 8:37 PM, Takashi Yamamoto <yamam...@midokura.com> wrote:
> Anil,
>
> do you have any opinion?
>
> i'm thinking to branch stable/newton at around
> 675af77205d4e404bc7c185c13ab6d86f300d185

after taas meeting, i went ahead and create the branch.

>
> On Thu, Nov 24, 2016 at 6:25 PM, Takashi Yamamoto <yamam...@midokura.com> 
> wrote:
>> hi,
>>
>> On Thu, Nov 24, 2016 at 6:00 PM, Gary Kotton <gkot...@vmware.com> wrote:
>>> Please see - 
>>> http://logs.openstack.org/82/401882/1/check/gate-vmware-nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-24_06_58_38_520273
>>> Here we are pulling trunk as there is no stable version to use
>>
>> thank you.
>> tap-as-a-service doesn't have any stable branches or releases yet.
>>
>> taas folks,
>> given increasing demands (networking-midonet also will depend on it)
>> i guess it makes sense to create newton branch.
>> if we don't think it's mature enough, we can call it experimental or
>> tech-preview or whatever.
>> how do you think?
>>
>>>
>>> On 11/24/16, 10:00 AM, "Takashi Yamamoto" <yamam...@midokura.com> wrote:
>>>
>>> can you give me an example of breakage?
>>>
>>> On Thu, Nov 24, 2016 at 4:19 PM, Gary Kotton <gkot...@vmware.com> wrote:
>>> > Hi,
>>> >
>>> > The change https://review.openstack.org/#/c/386845/ that landed 
>>> yesterday
>>> > has caused a breakage in stable/newton. This is due to the fact that 
>>> the
>>> > following projects do not have stable/newton tags:
>>> >
>>> > -  
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_tap-2Das-2Da-2Dservice=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=dXUw9DykF46Tk1oluf1fQMVmbhNKHbwG_scuNyTpXrM=
>>> >
>>> > -  
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_networking-2Dl2gw=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=DFa6PGUhmT9xowY1VGPsddAUZYVmZX2YsX9NIHQMpK0=
>>> >
>>> > Can the relevant release teams of the projects above please create the
>>> > relevant tags.
>>> >
>>> > 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

__
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] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

On Thu, Dec 1, 2016 at 1:02 AM, Armando M. <arma...@gmail.com> wrote:
>
>
> On 27 November 2016 at 20:50, Takashi Yamamoto <yamam...@midokura.com>
> wrote:
>>
>> On Wed, Nov 16, 2016 at 11:02 AM, Armando M. <arma...@gmail.com> wrote:
>> > Hi
>> >
>> > As of today, the project neutron-vpnaas is no longer part of the neutron
>> > governance. This was a decision reached after the project saw a dramatic
>> > drop in active development over a prolonged period of time.
>> >
>> > What does this mean in practice?
>> >
>> > From a visibility point of view, release notes and documentation will no
>> > longer appear on openstack.org as of Ocata going forward.
>> > No more releases will be published by the neutron release team.
>> > The neutron team will stop proposing fixes for the upstream CI, if not
>> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >
>> > How does it affect you, the user or the deployer?
>> >
>> > You can continue to use vpnaas and its CLI via the python-neutronclient
>> > and
>> > expect it to work with neutron up until the newton
>> > release/python-neutronclient 6.0.0. After this point, if you want a
>> > release
>> > that works for Ocata or newer, you need to proactively request a release
>> > [5], and reach out to a member of the neutron release team [3] for
>> > approval.
>> > Assuming that the vpnaas CI is green, you can expect to have a working
>> > vpnaas system upon release of its package in the foreseeable future.
>> > Outstanding bugs and new bug reports will be rejected on the basis of
>> > lack
>> > of engineering resources interested in helping out in the typical
>> > OpenStack
>> > review workflow.
>> > Since we are freezing the development of the neutron CLI in favor of the
>> > openstack unified client (OSC), the lack of a plan to make the VPN
>> > commands
>> > available in the OSC CLI means that at some point in the future the
>> > neutron
>> > client CLI support for vpnaas may be dropped (though I don't expect this
>> > to
>> > happen any time soon).
>> >
>> > Can this be reversed?
>> >
>> > If you are interested in reversing this decision, now it is time to step
>> > up.
>> > That said, we won't be reversing the decision for Ocata. There is quite
>> > a
>> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
>> > neutron stadium project, and that means addressing all the gaps
>> > identified
>> > in [6]. If you are interested, please reach out, and I will work with
>> > you to
>> > add your account to [4], so that you can drive the neutron-vpnaas agenda
>> > going forward.
>> >
>> > Please do not hesitate to reach out to ask questions and/or
>> > clarifications.
>>
>> hi,
>>
>> i'm interested in working on the project.
>> well, at least on the parts which is used by networking-midonet.
>
>
> That's great to hear Yamamoto. Since you are already a neutron-core I assume
> you are already intimate with the work required to strengthen the VPNaaS
> project. I have added you to [4] and you can lean on me for any changes that
> needs reviewing.

thank you.

>
>>
>>
>> >
>> > Cheers,
>> > Armando
>> >
>> > [1] https://review.openstack.org/#/c/392010/
>> > [2] https://review.openstack.org/#/c/397924/
>> > [3] https://review.openstack.org/#/admin/groups/150,members
>> > [4] https://review.openstack.org/#/admin/groups/502,members
>> > [5] https://github.com/openstack/releases
>> > [6]
>> >
>> > http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.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 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] [release] Re: [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Takashi Yamamoto]

release team,

can we (networking-midonet) branch stable/newton from a past commit
with a RC tag, backport some changes [1], and then cut the first release
on the branch?

[1] some addititonal features without db migrations (qos, lbaasv2, ...) and
removal of some unsupported code (lbaasv1, ...)

On Fri, Nov 25, 2016 at 11:32 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>
>> On 25 Nov 2016, at 15:23, Takashi Yamamoto <yamam...@midokura.com> wrote:
>>
>> On Fri, Nov 25, 2016 at 8:02 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>>>
>>>> On 25 Nov 2016, at 11:02, Takashi Yamamoto <yamam...@midokura.com> wrote:
>>>>
>>>> On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka <ihrac...@redhat.com> 
>>>> wrote:
>>>>>
>>>>>> On 25 Nov 2016, at 09:25, Takashi Yamamoto <yamam...@midokura.com> wrote:
>>>>>>
>>>>>> On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka <ihrac...@redhat.com> 
>>>>>> wrote:
>>>>>>>
>>>>>>>> On 25 Nov 2016, at 05:26, Takashi Yamamoto <yamam...@midokura.com> 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> hi,
>>>>>>>>
>>>>>>>> networking-midonet doesn't have stable/newton branch yet.
>>>>>>>> newton jobs failures are false alarms.
>>>>>>>>
>>>>>>>> branching has been delayed because development of some futures
>>>>>>>> planned for newton has not been completed yet.
>>>>>>>>
>>>>>>>> the plan is to revert ocata-specific changes after branching newton.
>>>>>>>
>>>>>>> I don’t think it’s a good idea since you will need to tag a release on 
>>>>>>> branch creation, that is supposed to be compatible with next releases 
>>>>>>> in that same branch.
>>>>>>
>>>>>> can't we create the tag after the revert?
>>>>>>
>>>>>
>>>>> No, that’s release team requirement that they branch on a release tag.
>>>>
>>>> ok, i didn't know the requirement. thank you.
>>>>
>>>>>
>>>>>> anyway no one think this is a good idea.
>>>>>> it's just an unfortunate compromise we ended up.
>>>>>> we are trying to make the schedule better for next release.
>>>>>
>>>>> It would make more sense to tag on a compatible commit from the past and 
>>>>> consider it a first stable release. (Of course it means that feature 
>>>>> development would need to be aligned appropriately.)
>>>>
>>>> in that case, can we backport the features?
>>>> (namely qos and lbaas drivers are in my mind)
>>>
>>> No, I don’t think so. Though maybe we can release an RC as the first tag in 
>>> the branch and backport features before releasing a final version? I dunno, 
>>> I guess you will need to talk to OpenStack release folks on how to proceed.
>>
>> is it a release team matter?
>> i thought these were a policy inside neutron.
>> after all networking-midonet is release:independent.
>
> Neutron does not override global policies. I explicitly asked during the last 
> summit if we can branch before a tag; the answer was no, it’s not an option.
>
> Adding [release] tag since it becomes a matter beyond neutron.
>
> 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] [tap-as-a-service] stable/newton 'broken'

[Takashi Yamamoto]

Anil,

do you have any opinion?

i'm thinking to branch stable/newton at around
675af77205d4e404bc7c185c13ab6d86f300d185

On Thu, Nov 24, 2016 at 6:25 PM, Takashi Yamamoto <yamam...@midokura.com> wrote:
> hi,
>
> On Thu, Nov 24, 2016 at 6:00 PM, Gary Kotton <gkot...@vmware.com> wrote:
>> Please see - 
>> http://logs.openstack.org/82/401882/1/check/gate-vmware-nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-24_06_58_38_520273
>> Here we are pulling trunk as there is no stable version to use
>
> thank you.
> tap-as-a-service doesn't have any stable branches or releases yet.
>
> taas folks,
> given increasing demands (networking-midonet also will depend on it)
> i guess it makes sense to create newton branch.
> if we don't think it's mature enough, we can call it experimental or
> tech-preview or whatever.
> how do you think?
>
>>
>> On 11/24/16, 10:00 AM, "Takashi Yamamoto" <yamam...@midokura.com> wrote:
>>
>> can you give me an example of breakage?
>>
>> On Thu, Nov 24, 2016 at 4:19 PM, Gary Kotton <gkot...@vmware.com> wrote:
>> > Hi,
>> >
>> > The change https://review.openstack.org/#/c/386845/ that landed 
>> yesterday
>> > has caused a breakage in stable/newton. This is due to the fact that 
>> the
>> > following projects do not have stable/newton tags:
>> >
>> > -  
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_tap-2Das-2Da-2Dservice=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=dXUw9DykF46Tk1oluf1fQMVmbhNKHbwG_scuNyTpXrM=
>> >
>> > -  
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_networking-2Dl2gw=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=DFa6PGUhmT9xowY1VGPsddAUZYVmZX2YsX9NIHQMpK0=
>> >
>> > Can the relevant release teams of the projects above please create the
>> > relevant tags.
>> >
>> > 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

__
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] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
> Hi
>
> As of today, the project neutron-vpnaas is no longer part of the neutron
> governance. This was a decision reached after the project saw a dramatic
> drop in active development over a prolonged period of time.
>
> What does this mean in practice?
>
> From a visibility point of view, release notes and documentation will no
> longer appear on openstack.org as of Ocata going forward.
> No more releases will be published by the neutron release team.
> The neutron team will stop proposing fixes for the upstream CI, if not
> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>
> How does it affect you, the user or the deployer?
>
> You can continue to use vpnaas and its CLI via the python-neutronclient and
> expect it to work with neutron up until the newton
> release/python-neutronclient 6.0.0. After this point, if you want a release
> that works for Ocata or newer, you need to proactively request a release
> [5], and reach out to a member of the neutron release team [3] for approval.
> Assuming that the vpnaas CI is green, you can expect to have a working
> vpnaas system upon release of its package in the foreseeable future.
> Outstanding bugs and new bug reports will be rejected on the basis of lack
> of engineering resources interested in helping out in the typical OpenStack
> review workflow.
> Since we are freezing the development of the neutron CLI in favor of the
> openstack unified client (OSC), the lack of a plan to make the VPN commands
> available in the OSC CLI means that at some point in the future the neutron
> client CLI support for vpnaas may be dropped (though I don't expect this to
> happen any time soon).
>
> Can this be reversed?
>
> If you are interested in reversing this decision, now it is time to step up.
> That said, we won't be reversing the decision for Ocata. There is quite a
> curve to ramp up to make neutron-vpnaas worthy of being classified as a
> neutron stadium project, and that means addressing all the gaps identified
> in [6]. If you are interested, please reach out, and I will work with you to
> add your account to [4], so that you can drive the neutron-vpnaas agenda
> going forward.
>
> Please do not hesitate to reach out to ask questions and/or clarifications.

hi,

i'm interested in working on the project.
well, at least on the parts which is used by networking-midonet.

>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/392010/
> [2] https://review.openstack.org/#/c/397924/
> [3] https://review.openstack.org/#/admin/groups/150,members
> [4] https://review.openstack.org/#/admin/groups/502,members
> [5] https://github.com/openstack/releases
> [6]
> http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Takashi Yamamoto]

On Fri, Nov 25, 2016 at 8:02 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>
>> On 25 Nov 2016, at 11:02, Takashi Yamamoto <yamam...@midokura.com> wrote:
>>
>> On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>>>
>>>> On 25 Nov 2016, at 09:25, Takashi Yamamoto <yamam...@midokura.com> wrote:
>>>>
>>>> On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka <ihrac...@redhat.com> 
>>>> wrote:
>>>>>
>>>>>> On 25 Nov 2016, at 05:26, Takashi Yamamoto <yamam...@midokura.com> wrote:
>>>>>>
>>>>>> hi,
>>>>>>
>>>>>> networking-midonet doesn't have stable/newton branch yet.
>>>>>> newton jobs failures are false alarms.
>>>>>>
>>>>>> branching has been delayed because development of some futures
>>>>>> planned for newton has not been completed yet.
>>>>>>
>>>>>> the plan is to revert ocata-specific changes after branching newton.
>>>>>
>>>>> I don’t think it’s a good idea since you will need to tag a release on 
>>>>> branch creation, that is supposed to be compatible with next releases in 
>>>>> that same branch.
>>>>
>>>> can't we create the tag after the revert?
>>>>
>>>
>>> No, that’s release team requirement that they branch on a release tag.
>>
>> ok, i didn't know the requirement. thank you.
>>
>>>
>>>> anyway no one think this is a good idea.
>>>> it's just an unfortunate compromise we ended up.
>>>> we are trying to make the schedule better for next release.
>>>
>>> It would make more sense to tag on a compatible commit from the past and 
>>> consider it a first stable release. (Of course it means that feature 
>>> development would need to be aligned appropriately.)
>>
>> in that case, can we backport the features?
>> (namely qos and lbaas drivers are in my mind)
>
> No, I don’t think so. Though maybe we can release an RC as the first tag in 
> the branch and backport features before releasing a final version? I dunno, I 
> guess you will need to talk to OpenStack release folks on how to proceed.

is it a release team matter?
i thought these were a policy inside neutron.
after all networking-midonet is release:independent.

>
> 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][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Takashi Yamamoto]

On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>
>> On 25 Nov 2016, at 09:25, Takashi Yamamoto <yamam...@midokura.com> wrote:
>>
>> On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>>>
>>>> On 25 Nov 2016, at 05:26, Takashi Yamamoto <yamam...@midokura.com> wrote:
>>>>
>>>> hi,
>>>>
>>>> networking-midonet doesn't have stable/newton branch yet.
>>>> newton jobs failures are false alarms.
>>>>
>>>> branching has been delayed because development of some futures
>>>> planned for newton has not been completed yet.
>>>>
>>>> the plan is to revert ocata-specific changes after branching newton.
>>>
>>> I don’t think it’s a good idea since you will need to tag a release on 
>>> branch creation, that is supposed to be compatible with next releases in 
>>> that same branch.
>>
>> can't we create the tag after the revert?
>>
>
> No, that’s release team requirement that they branch on a release tag.

ok, i didn't know the requirement. thank you.

>
>> anyway no one think this is a good idea.
>> it's just an unfortunate compromise we ended up.
>> we are trying to make the schedule better for next release.
>
> It would make more sense to tag on a compatible commit from the past and 
> consider it a first stable release. (Of course it means that feature 
> development would need to be aligned appropriately.)

in that case, can we backport the features?
(namely qos and lbaas drivers are in my mind)

>
> I see that subprojects do the same mistake over and over (the previous time 
> it was sfc, but I’ve heard similar concerns from bgpvpn). I believe that we 
> should set clear expectations for all stadium participants about when they 
> first stable releases happen and when branches are created. The current lack 
> of guidelines for participants just makes it harder for the core team to 
> maintain the setting, and for subprojects to become good citizens.
>
> 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][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Takashi Yamamoto]

On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>
>> On 25 Nov 2016, at 05:26, Takashi Yamamoto <yamam...@midokura.com> wrote:
>>
>> hi,
>>
>> networking-midonet doesn't have stable/newton branch yet.
>> newton jobs failures are false alarms.
>>
>> branching has been delayed because development of some futures
>> planned for newton has not been completed yet.
>>
>> the plan is to revert ocata-specific changes after branching newton.
>
> I don’t think it’s a good idea since you will need to tag a release on branch 
> creation, that is supposed to be compatible with next releases in that same 
> branch.

can't we create the tag after the revert?

anyway no one think this is a good idea.
it's just an unfortunate compromise we ended up.
we are trying to make the schedule better for next release.

>
>>
>> On Fri, Nov 25, 2016 at 9:14 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>>> Hi,
>>>
>>> could anyone from the midonet subproject take ownership of repo stable
>>> branches? Newton branch is broken for weeks with no apparent actions from
>>> the core team side.
>>>
>>> Begin forwarded message:
>>>
>>> From: "A mailing list for the OpenStack Stable Branch test reports."
>>> <openstack-stable-ma...@lists.openstack.org>
>>> Subject: [Openstack-stable-maint] Stable check of
>>> openstack/networking-midonet failed
>>> Date: 24 November 2016 at 07:11:42 GMT+1
>>> To: openstack-stable-ma...@lists.openstack.org
>>> Reply-To: openstack-dev@lists.openstack.org
>>>
>>> Build failed.
>>>
>>> - periodic-networking-midonet-docs-liberty
>>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-liberty/b912665/
>>> : SUCCESS in 4m 58s
>>> - periodic-networking-midonet-python27-liberty
>>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-liberty/978a77c/
>>> : SUCCESS in 9m 57s
>>> - periodic-networking-midonet-docs-mitaka
>>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-mitaka/e4e139e/
>>> : SUCCESS in 2m 19s
>>> - periodic-networking-midonet-python27-mitaka
>>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-mitaka/d61abf6/
>>> : SUCCESS in 7m 06s
>>> - periodic-networking-midonet-docs-newton
>>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-newton/55ae3d1/
>>> : SUCCESS in 2m 34s
>>> - periodic-networking-midonet-python27-newton
>>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-newton/db864e6/
>>> : FAILURE in 3m 57s
>>>
>>> ___
>>> Openstack-stable-maint mailing list
>>> openstack-stable-ma...@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
>>>
>>>
>

__
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][networking-midonet] Fwd: [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Takashi Yamamoto]

On Fri, Nov 25, 2016 at 4:36 PM, Takashi Yamamoto <yamam...@midokura.com> wrote:
> On Fri, Nov 25, 2016 at 4:28 PM, Andreas Jaeger <a...@suse.com> wrote:
>> On 11/25/2016 05:26 AM, Takashi Yamamoto wrote:
>>> networking-midonet doesn't have stable/newton branch yet.
>>> newton jobs failures are false alarms.
>>
>> Then let's remove these jobs,
>
> sure. i'll submit project-config change.

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

>
>>
>> Andreas
>> --
>>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>>HRB 21284 (AG Nürnberg)
>> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron][networking-midonet] Fwd: [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Takashi Yamamoto]

On Fri, Nov 25, 2016 at 4:28 PM, Andreas Jaeger <a...@suse.com> wrote:
> On 11/25/2016 05:26 AM, Takashi Yamamoto wrote:
>> networking-midonet doesn't have stable/newton branch yet.
>> newton jobs failures are false alarms.
>
> Then let's remove these jobs,

sure. i'll submit project-config change.

>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron][networking-midonet] Fwd: [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Takashi Yamamoto]

hi,

networking-midonet doesn't have stable/newton branch yet.
newton jobs failures are false alarms.

branching has been delayed because development of some futures
planned for newton has not been completed yet.

the plan is to revert ocata-specific changes after branching newton.

On Fri, Nov 25, 2016 at 9:14 AM, Ihar Hrachyshka  wrote:
> Hi,
>
> could anyone from the midonet subproject take ownership of repo stable
> branches? Newton branch is broken for weeks with no apparent actions from
> the core team side.
>
> Begin forwarded message:
>
> From: "A mailing list for the OpenStack Stable Branch test reports."
> 
> Subject: [Openstack-stable-maint] Stable check of
> openstack/networking-midonet failed
> Date: 24 November 2016 at 07:11:42 GMT+1
> To: openstack-stable-ma...@lists.openstack.org
> Reply-To: openstack-dev@lists.openstack.org
>
> Build failed.
>
> - periodic-networking-midonet-docs-liberty
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-liberty/b912665/
> : SUCCESS in 4m 58s
> - periodic-networking-midonet-python27-liberty
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-liberty/978a77c/
> : SUCCESS in 9m 57s
> - periodic-networking-midonet-docs-mitaka
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-mitaka/e4e139e/
> : SUCCESS in 2m 19s
> - periodic-networking-midonet-python27-mitaka
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-mitaka/d61abf6/
> : SUCCESS in 7m 06s
> - periodic-networking-midonet-docs-newton
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-newton/55ae3d1/
> : SUCCESS in 2m 34s
> - periodic-networking-midonet-python27-newton
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-newton/db864e6/
> : FAILURE in 3m 57s
>
> ___
> Openstack-stable-maint mailing list
> openstack-stable-ma...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
>
>

__
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] [tap-as-a-service] stable/newton 'broken'

[Takashi Yamamoto]

hi,

On Thu, Nov 24, 2016 at 6:00 PM, Gary Kotton <gkot...@vmware.com> wrote:
> Please see - 
> http://logs.openstack.org/82/401882/1/check/gate-vmware-nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-24_06_58_38_520273
> Here we are pulling trunk as there is no stable version to use

thank you.
tap-as-a-service doesn't have any stable branches or releases yet.

taas folks,
given increasing demands (networking-midonet also will depend on it)
i guess it makes sense to create newton branch.
if we don't think it's mature enough, we can call it experimental or
tech-preview or whatever.
how do you think?

>
> On 11/24/16, 10:00 AM, "Takashi Yamamoto" <yamam...@midokura.com> wrote:
>
> can you give me an example of breakage?
>
> On Thu, Nov 24, 2016 at 4:19 PM, Gary Kotton <gkot...@vmware.com> wrote:
> > Hi,
> >
> > The change https://review.openstack.org/#/c/386845/ that landed 
> yesterday
> > has caused a breakage in stable/newton. This is due to the fact that the
> > following projects do not have stable/newton tags:
> >
> > -  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_tap-2Das-2Da-2Dservice=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=dXUw9DykF46Tk1oluf1fQMVmbhNKHbwG_scuNyTpXrM=
> >
> > -  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_networking-2Dl2gw=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=DFa6PGUhmT9xowY1VGPsddAUZYVmZX2YsX9NIHQMpK0=
> >
> > Can the relevant release teams of the projects above please create the
> > relevant tags.
> >
> > 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

__
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/newton 'broken'

[Takashi Yamamoto]

can you give me an example of breakage?

On Thu, Nov 24, 2016 at 4:19 PM, Gary Kotton  wrote:
> Hi,
>
> The change https://review.openstack.org/#/c/386845/ that landed yesterday
> has caused a breakage in stable/newton. This is due to the fact that the
> following projects do not have stable/newton tags:
>
> -  https://github.com/openstack/tap-as-a-service
>
> -  https://github.com/openstack/networking-l2gw
>
> Can the relevant release teams of the projects above please create the
> relevant tags.
>
> 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

Re: [openstack-dev] [stable][neutron][midonet] midonet liberty gate failure

[Takashi Yamamoto]

hi,

On Thu, Nov 3, 2016 at 2:18 AM, Ihar Hrachyshka  wrote:
> Hi YAMAMOTO (and other midokura folks),
>
> I spotted unit tests in the branch are failing due to upper constraints not
> applied. So I backported the fix as:
> https://review.openstack.org/#/c/392698/ Sadly, it does not pass because
> tempest for midonet v2 fails:

thank you.

>
> http://logs.openstack.org/98/392698/1/check/gate-tempest-dsvm-networking-midonet-v2/9494c9c/logs/devstacklog.txt.gz#_2016-11-02_15_10_13_949
>
> It looks like midonet SDN controller misbehaving.
>
> Would you mind taking it from there and propose the needed patches to pass
> the gate for the patch?

sure, it looks like a backend issue. i'll take a look.

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

[Takashi Yamamoto]

+1

On Sat, Oct 15, 2016 at 3:30 AM, 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
>

__
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][stadium] Query regarding procedure for inclusion in Neutron Stadium

[Takashi Yamamoto]

hi,

On Sat, Sep 24, 2016 at 9:06 AM, Armando M. <arma...@gmail.com> wrote:
>
>
> On 22 September 2016 at 22:36, Takashi Yamamoto <yamam...@midokura.com>
> wrote:
>>
>> hi,
>>
>> On Fri, Sep 23, 2016 at 4:20 AM, Armando M. <arma...@gmail.com> wrote:
>> >
>> >
>> > On 22 September 2016 at 00:46, reedip banerjee <reedi...@gmail.com>
>> > wrote:
>> >>
>> >> Dear Neutron Core members,
>> >>
>> >> I have a query regarding the procedure for inclusion in the Neutron
>> >> Stadium.
>> >> I wanted to know if a project can apply for Big Tent and Neutron
>> >> Stadium
>> >> together ( means can a project be accepted in the Neutron Stadium and
>> >> as a
>> >> result into the Big Tent )
>> >>
>> >> I was checking out the checklist in  [1], and IMO , I think that we
>> >> need
>> >> to conform to the checklist to be added to the Neutron Stadium ( along
>> >> with
>> >> the other requirements  like keeping in sync with the core neutron
>> >> concepts)
>> >>
>> >> But IIUC, certain items in the checklist would be completed if a
>> >> project
>> >> is already included in the Big Tent.
>> >
>> >
>> > I would not worry about those, as these are rather trivial to implement
>> > in
>> > conjunction with Stadium inclusion. I'd worry about the fork that the
>> > project relies on, which is a big show stopper for Stadium inclusion.
>> >
>> > [1]
>> > https://github.com/openstack/tap-as-a-service/blob/master/setup.cfg#L50
>>
>> just a clarification; this is not a fork of ovs-agent. it's a separate
>> agent.
>
>
> It may not strictly be a fork, but I am not grasping the technical reason as
> to why one needs yet another agent on the node. Besides, this might end up
> interfering with the OVS agent as it is handling the same resources [1],
> without any level of coordination.

it was done that way just because there was no good ways at that point i guess.
(just a wild guess. i'm not a person who wrote it.)
making it an l2 agent extension is on our todo list.

>
> [1]
> https://github.com/openstack/tap-as-a-service/blob/master/neutron_taas/services/taas/drivers/linux/ovs_taas.py#L43:L44
>
>>
>> >
>> >>
>> >>
>> >> So my doubt is ,should a project apply for the Big Tent first, and
>> >> after
>> >> inclusion, apply for Neutron Stadium ? Or can a project be integrated
>> >> to
>> >> Neutron Stadium and Big Tent simultaneously ( I am a bit sceptical
>> >> about
>> >> this though)?
>> >
>> >
>> > You are confusing the two things. A project either belongs to list [1]
>> > or
>> > list [2], and you can't be in both at the same time. To be part of
>> > either
>> > list a project must comply with a set of criteria. As for the latter, a
>> > couple of steps may sound like a catch 22: for instance you can't make
>> > docs
>> > available on docs.o.o unless you are in [2] and you can't be in [2]
>> > unless...and here's the trick, unless you are a point where you can
>> > successfully demonstrate that the project has substantial documentation
>> > (of
>> > any sort, API included). The process of 'demonstrating'/application for
>> > inclusion in list [2] follows the RFE submission process that we have
>> > adopted for a while, and that means submitting a spec. Since the request
>> > does not require a conventional design process, I was going to prepare
>> > an
>> > ad-hoc template and make it available soon. So watch the neutron-specs
>> > repo
>> > for updates.
>> >
>> > In the meantime, I'd urge you to go over the checklist and make sure you
>> > can
>> > address the hard parts.
>> >
>> > If you ask me, if you go with [1], it makes no sense to go and apply to
>> > be
>> > in [2].
>> >
>> > HTH
>> > Armando
>> >
>> > [1] http://governance.openstack.org/reference/projects/
>> > [2] http://governance.openstack.org/reference/projects/neutron.html
>> >
>> >>
>> >>
>> >>
>> >> [1]
>> >>
>> >> http://docs.openstack.org/developer/neutron/stadium/governance.html#checklist
>> >> --
>> >> Th

Re: [openstack-dev] [neutron][stadium] Query regarding procedure for inclusion in Neutron Stadium

[Takashi Yamamoto]

hi,

On Fri, Sep 23, 2016 at 4:20 AM, Armando M.  wrote:
>
>
> On 22 September 2016 at 00:46, reedip banerjee  wrote:
>>
>> Dear Neutron Core members,
>>
>> I have a query regarding the procedure for inclusion in the Neutron
>> Stadium.
>> I wanted to know if a project can apply for Big Tent and Neutron Stadium
>> together ( means can a project be accepted in the Neutron Stadium and as a
>> result into the Big Tent )
>>
>> I was checking out the checklist in  [1], and IMO , I think that we need
>> to conform to the checklist to be added to the Neutron Stadium ( along with
>> the other requirements  like keeping in sync with the core neutron concepts)
>>
>> But IIUC, certain items in the checklist would be completed if a project
>> is already included in the Big Tent.
>
>
> I would not worry about those, as these are rather trivial to implement in
> conjunction with Stadium inclusion. I'd worry about the fork that the
> project relies on, which is a big show stopper for Stadium inclusion.
>
> [1] https://github.com/openstack/tap-as-a-service/blob/master/setup.cfg#L50

just a clarification; this is not a fork of ovs-agent. it's a separate agent.

>
>>
>>
>> So my doubt is ,should a project apply for the Big Tent first, and after
>> inclusion, apply for Neutron Stadium ? Or can a project be integrated to
>> Neutron Stadium and Big Tent simultaneously ( I am a bit sceptical about
>> this though)?
>
>
> You are confusing the two things. A project either belongs to list [1] or
> list [2], and you can't be in both at the same time. To be part of either
> list a project must comply with a set of criteria. As for the latter, a
> couple of steps may sound like a catch 22: for instance you can't make docs
> available on docs.o.o unless you are in [2] and you can't be in [2]
> unless...and here's the trick, unless you are a point where you can
> successfully demonstrate that the project has substantial documentation (of
> any sort, API included). The process of 'demonstrating'/application for
> inclusion in list [2] follows the RFE submission process that we have
> adopted for a while, and that means submitting a spec. Since the request
> does not require a conventional design process, I was going to prepare an
> ad-hoc template and make it available soon. So watch the neutron-specs repo
> for updates.
>
> In the meantime, I'd urge you to go over the checklist and make sure you can
> address the hard parts.
>
> If you ask me, if you go with [1], it makes no sense to go and apply to be
> in [2].
>
> HTH
> Armando
>
> [1] http://governance.openstack.org/reference/projects/
> [2] http://governance.openstack.org/reference/projects/neutron.html
>
>>
>>
>>
>> [1]
>> http://docs.openstack.org/developer/neutron/stadium/governance.html#checklist
>> --
>> Thanks and Regards,
>> Reedip Banerjee
>> IRC: reedip
>>
>>
>>
>>
>>
>> __
>> 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][taas] On TaaS not capturing some packets between two VMs on the same host

[Takashi Yamamoto]

hi,

On Sat, Sep 3, 2016 at 7:32 AM, Anil Rao  wrote:
> Hello,
>
> Here is an update on the issue of not being able to capture packets flowing
> between two VMs on the same host.

it it about bug 1529595 ?
https://bugs.launchpad.net/tap-as-a-service/+bug/1529595

>
> Isolating the problem:
>
> It has been confirmed that the TaaS OVS driver cannot capture packets
> ingressing (flowing into) a VM’s vNIC under the following conditions:
>
> - The sender port and the receiver port (which is being monitored) reside on
> the same host.
>
> - The sender port and the receiver port are attached to the same (virtual)
> network.
>
> We do not have a problem in the above situation for traffic egressing
> (flowing out) of the VM’s vNIC. We also do not have a problem if the sender
> port and receiver port are on different hosts, or if the sender and receiver
> ports belong to different (virtual) networks.
>
> Trafffic Capture Technique:
>
> The implementation uses the following methods to capture packets flowing
> into and out of a VM’s vNIC.
>
> Egress Side (flowing out of the vNIC):
>
> The ‘in_port=’ check is used to identify packets coming in from
> the port associated with the VM’s vNIC. This allows us to capture all
> packets flowing out of the vNIC under question. No problems here.
>
> Ingress Side (flowing into the vNIC):
>
> The ‘dl_vlan=, dl_dst=’ check is used to
> identify packets destined for the port associated with the VM’s vNIC.
>
> The VLAN tag check was put in place because Neutron port MAC addresses are
> required to be unique only within a (virtual) network. Now each instance
> port in br-int gets tagged with a VLAN id that is the same for all ports on
> that host, which are associated with a particular (virtual) network. Ports
> belonging to different (virtual) networks therefore get tagged with
> different VLAN ids.
>
> The combination of “VLAN tag + destination MAC address” was felt to be a
> sufficient check to ensure that we are truly dealing with traffic heading
> out of the port being monitored.
>
> Root Cause of the problem:
>
> The br-int bridge operates using the legacy (or normal) mode of operation.
> We have observed that under these circumstances, OVS does not add VLAN tags
> to packets, as long as they are flowing within the bridge. Packets escaping
> from br-int into br-tun (via the patch ports), however, get tagged as
> expected when they arrive in br-tun.
>
> Due to this behavior, our ingress side flow (described above) fails to
> capture packets flowing into a VM’s vNIC, when it is originating from
> another port on the same host and on the same virtual network.
>
> Possible Solutions:

i think the it can be fixed by having rules to "tag" packets explicitly.
ie. match on inport and record the logical network in openflow metadata.
(or ovs registers, which is basically the same thing)
as it's planned to be done for ovs-agent extensions:
https://review.openstack.org/#/c/320439/

>
> OVS documentation (refer: Open vSwitch FAQ) seems to recommend not using the
> normal operating mode, but handling VLANs explicitly, if flows related to
> VLAN ids are going to be used.  As mentioned above, to ensure that we
> correctly handle the Neutron requirement that port MAC addresses are unique
> only within a virtual network, we need to add VLAN related checks to the
> TaaS flows. However, br-int today relies on the normal operation mode for
> most of its work.
>
> This has left us now in a quandary situation. Here is a proposal to move us
> forward:
>
> 1.   As a temporary fix, we can convert the TaaS ingress side flow in
> br-int from
>
> dl_vlan=, dl_dst=
>
> to
>
> dl_dst=
>
> This will obviously mean that we no longer support the notion that Neutron
> port MAC addresses are unique only within a virtual network. However, given
> that the probability of two port MAC addresses on a host being the same is
> low, this should suffice for the short term.

i agree this is the easiest workaround.

>
> [We will also disable the flows used to capture broadcast/multicast traffic
> flowing into a VM’s vNIC]
>
> 2.   Implement VLAN handling explicitly in br-int and thereby move away
> from the normal operating mode. This will be a core Neutron change and not
> limited to just TaaS. However, I have the feeling that there will be other
> projects (outside of TaaS) that will sooner or later have a need to detect
> traffic flowing into a vNIC and they will also run into the same issue we
> are presently facing.

i'm all for moving away from port based "internal" vlans for longer term.

>
>
>
> 3.   Go back to the (current) TaaS ingress side flow
> (dl_vlan=, dl_dst=) when (2) is
> implemented. We will then be able to once again support the Neutron
> requirement that port MAC addresses need be unique only within a (virtual)
> network.
>
>
>
> [We will re-enable the flows used to capture broadcast/multicast traffic
> flowing into a VM’s vNIC]
>
>
>
> Thoughts 

[openstack-dev] [neutron][taas] making a taas release for mitaka or not

[Takashi Yamamoto]

hi,

we tap-as-a-service project had a plan to make a release compatible with mitaka.
however,
- it's a bit late for mitaka already
- the reference implementation needs to be adapted to l2 agent
extension but no much progress yet

so, a question is, if we still want to make a release for mitaka,
or it's better for the project to re-target to newton.
how do you think?

note: this topic was briefly discussed in the recent weekly meetings
but moved to ML due to the lack of quorum.

note: networking-midonet still wants to have the taas functionality for mitaka.
but it involves a non-trivial change in taas. [1]

[1] https://review.openstack.org/#/c/307708/

__
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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Takashi Yamamoto]

On Wed, May 18, 2016 at 4:57 PM, Miguel Angel Ajo Pelayo
<majop...@redhat.com> wrote:
> Hey,
>
>Finally we took over the channel for 1h. mostly because the time was
> already agreed between many people on opposed timezones and it was a bit
> late to cancel it.
>
>The first point was finding a suitable timeslot for a biweekly meeting
> -for some time- and alternatively following up on email. We should not take
> over the neutron channel for these meetings anymore, I'm sorry for the
> inconvenience.

Tony pointed out that there are bi-weekly slot available.
https://review.openstack.org/#/c/316830/
i guess the slot is fine for many of us.

>
>   Please find the summary here:
>
> http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-05-17-17.02.html
>
> On Tue, May 17, 2016 at 8:10 PM, Kevin Benton <ke...@benton.pub> wrote:
>>
>> Yeah, no meetings in #openstack-neutron please. It leaves us nowhere to
>> discuss development stuff during that hour.
>>
>> On Tue, May 17, 2016 at 2:54 AM, Miguel Angel Ajo Pelayo
>> <majop...@redhat.com> wrote:
>>>
>>> I agree, let's try to find a timeslot that works.
>>>
>>> using #openstack-neutron with the meetbot works, but it's going to
>>> generate a lot of noise.
>>>
>>> On Tue, May 17, 2016 at 11:47 AM, Ihar Hrachyshka <ihrac...@redhat.com>
>>> wrote:
>>>>
>>>>
>>>> > On 16 May 2016, at 15:47, Takashi Yamamoto <yamam...@midokura.com>
>>>> > wrote:
>>>> >
>>>> > On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto
>>>> > <yamam...@midokura.com> wrote:
>>>> >> hi,
>>>> >>
>>>> >> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka
>>>> >> <ihrac...@redhat.com> wrote:
>>>> >>> +1 for earlier time. But also, have we booked any channel for the
>>>> >>> meeting? Hijacking #openstack-neutron may not work fine during such a 
>>>> >>> busy
>>>> >>> (US) time. I suggest we propose a patch for
>>>> >>> https://github.com/openstack-infra/irc-meetings
>>>> >>
>>>> >> i agree and submitted a patch.
>>>> >> https://review.openstack.org/#/c/316830/
>>>> >
>>>> > oops, unfortunately there seems no meeting channel free at the time
>>>> > slot.
>>>>
>>>> This should be solved either by changing the slot, or by getting a new
>>>> channel registered for meetings. Using unregistered channels, especially
>>>> during busy hours, is not effective, and is prone to overlaps for relevant
>>>> meetings. The meetings will also not get a proper slot at
>>>> eavesdrop.openstack.org.
>>>>
>>>> Ihar
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __
>> 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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Takashi Yamamoto]

On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto
<yamam...@midokura.com> wrote:
> hi,
>
> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>> +1 for earlier time. But also, have we booked any channel for the meeting? 
>> Hijacking #openstack-neutron may not work fine during such a busy (US) time. 
>> I suggest we propose a patch for 
>> https://github.com/openstack-infra/irc-meetings
>
> i agree and submitted a patch.
> https://review.openstack.org/#/c/316830/

oops, unfortunately there seems no meeting channel free at the time slot.

>
>>
>> Ihar
>>
>>> On 10 May 2016, at 20:35, Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
>>>
>>> It is always hard to find a day and time that is good for everyone around 
>>> the globe:-)
>>> The first meeting will still be UTC 1700 ~ UTC 1800 May 17 on Neutron 
>>> channel.
>>> In the meeting, we can see if we can reach consensus on a new meeting time.
>>>
>>> Cathy
>>>
>>> -Original Message-
>>> From: Takashi Yamamoto [mailto:yamam...@midokura.com]
>>> Sent: Tuesday, May 10, 2016 12:40 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and 
>>> OVS Agent extension for Newton cycle
>>>
>>> On Tue, May 10, 2016 at 12:41 AM,  <thomas.mo...@orange.com> wrote:
>>>> Hi Cathy,
>>>>
>>>> Cathy Zhang:
>>>>>
>>>>> I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday.
>>>>> Hope this time is good for all people who have interest and like to
>>>>> contribute to this work. We plan to start the first meeting on May 17.
>>>>
>>>>
>>>> I would be happy to participate, but I'm unlikely to be able to attend
>>>> at that time.
>>>> Might 15:00 UTC work for others ?
>>>
>>> +1 for earlier
>>>
>>>> If not, well, I'll make do with log/emails/pads/gerrit interactions.
>>>>
>>>> -Thomas
>>>>
>>>>
>>>>
>>>>
>>>>> -Original Message-
>>>>> From: Cathy Zhang
>>>>> Sent: Thursday, April 21, 2016 11:43 AM
>>>>> To: Cathy Zhang; OpenStack Development Mailing List (not for usage
>>>>> questions); Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim
>>>>> Daniel; Mathieu Rohon; Shaughnessy, David; Eichberger, German; Henry
>>>>> Fourie; arma...@gmail.com; Miguel Angel Ajo; Reedip; Thierry Carrez
>>>>> Cc: Cathy Zhang
>>>>> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier
>>>>> and OVS Agent extension for Newton cycle
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> We have room 400 at 3:10pm on Thursday available for discussion of
>>>>> the two topics.
>>>>> Another option is to use the common room with roundtables in "Salon C"
>>>>> during Monday or Wednesday lunch time.
>>>>>
>>>>> Room 400 at 3:10pm is a closed room while the Salon C is a big open
>>>>> room which can host 500 people.
>>>>>
>>>>> I am Ok with either option. Let me know if anyone has a strong preference.
>>>>>
>>>>> Thanks,
>>>>> Cathy
>>>>>
>>>>>
>>>>> -Original Message-
>>>>> From: Cathy Zhang
>>>>> Sent: Thursday, April 14, 2016 1:23 PM
>>>>> To: OpenStack Development Mailing List (not for usage questions);
>>>>> 'Ihar Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim
>>>>> Daniel'; 'Mathieu Rohon'; 'Shaughnessy, David'; 'Eichberger, German';
>>>>> Cathy Zhang; Henry Fourie; 'arma...@gmail.com'
>>>>> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier
>>>>> and OVS Agent extension for Newton cycle
>>>>>
>>>>> Thanks for everyone's reply!
>>>>>
>>>>> Here is the summary based on the replies I received:
>>>>>
>>>>> 1.  We should have a meet-up for these two topics. The "to" list are
>>>>> the people who have interest in these topics.
>>>>> I am thinking about around lunch time on Tuesday or Wednesday
>>>>> since some of us will fl

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Takashi Yamamoto]

hi,

On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
> +1 for earlier time. But also, have we booked any channel for the meeting? 
> Hijacking #openstack-neutron may not work fine during such a busy (US) time. 
> I suggest we propose a patch for 
> https://github.com/openstack-infra/irc-meetings

i agree and submitted a patch.
https://review.openstack.org/#/c/316830/

>
> Ihar
>
>> On 10 May 2016, at 20:35, Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
>>
>> It is always hard to find a day and time that is good for everyone around 
>> the globe:-)
>> The first meeting will still be UTC 1700 ~ UTC 1800 May 17 on Neutron 
>> channel.
>> In the meeting, we can see if we can reach consensus on a new meeting time.
>>
>> Cathy
>>
>> -Original Message-
>> From: Takashi Yamamoto [mailto:yamam...@midokura.com]
>> Sent: Tuesday, May 10, 2016 12:40 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and 
>> OVS Agent extension for Newton cycle
>>
>> On Tue, May 10, 2016 at 12:41 AM,  <thomas.mo...@orange.com> wrote:
>>> Hi Cathy,
>>>
>>> Cathy Zhang:
>>>>
>>>> I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday.
>>>> Hope this time is good for all people who have interest and like to
>>>> contribute to this work. We plan to start the first meeting on May 17.
>>>
>>>
>>> I would be happy to participate, but I'm unlikely to be able to attend
>>> at that time.
>>> Might 15:00 UTC work for others ?
>>
>> +1 for earlier
>>
>>> If not, well, I'll make do with log/emails/pads/gerrit interactions.
>>>
>>> -Thomas
>>>
>>>
>>>
>>>
>>>> -Original Message-
>>>> From: Cathy Zhang
>>>> Sent: Thursday, April 21, 2016 11:43 AM
>>>> To: Cathy Zhang; OpenStack Development Mailing List (not for usage
>>>> questions); Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim
>>>> Daniel; Mathieu Rohon; Shaughnessy, David; Eichberger, German; Henry
>>>> Fourie; arma...@gmail.com; Miguel Angel Ajo; Reedip; Thierry Carrez
>>>> Cc: Cathy Zhang
>>>> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier
>>>> and OVS Agent extension for Newton cycle
>>>>
>>>> Hi everyone,
>>>>
>>>> We have room 400 at 3:10pm on Thursday available for discussion of
>>>> the two topics.
>>>> Another option is to use the common room with roundtables in "Salon C"
>>>> during Monday or Wednesday lunch time.
>>>>
>>>> Room 400 at 3:10pm is a closed room while the Salon C is a big open
>>>> room which can host 500 people.
>>>>
>>>> I am Ok with either option. Let me know if anyone has a strong preference.
>>>>
>>>> Thanks,
>>>> Cathy
>>>>
>>>>
>>>> -Original Message-
>>>> From: Cathy Zhang
>>>> Sent: Thursday, April 14, 2016 1:23 PM
>>>> To: OpenStack Development Mailing List (not for usage questions);
>>>> 'Ihar Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim
>>>> Daniel'; 'Mathieu Rohon'; 'Shaughnessy, David'; 'Eichberger, German';
>>>> Cathy Zhang; Henry Fourie; 'arma...@gmail.com'
>>>> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier
>>>> and OVS Agent extension for Newton cycle
>>>>
>>>> Thanks for everyone's reply!
>>>>
>>>> Here is the summary based on the replies I received:
>>>>
>>>> 1.  We should have a meet-up for these two topics. The "to" list are
>>>> the people who have interest in these topics.
>>>> I am thinking about around lunch time on Tuesday or Wednesday
>>>> since some of us will fly back on Friday morning/noon.
>>>> If this time is OK with everyone, I will find a place and let
>>>> you know where and what time to meet.
>>>>
>>>> 2.  There is a bug opened for the QoS Flow Classifier
>>>> https://bugs.launchpad.net/neutron/+bug/1527671
>>>> We can either change the bug title and modify the bug details or
>>>> start with a new one for the common FC which provides info on all
>>>> requirements needed by all relevant use cases. There is a bug opened