Re: [OpenStack-Infra] grafana does not work for new job of neutron-dynamic-routing

[Armando M.]

On 13 August 2017 at 19:26, fumihiko kakuma  wrote:

> Hi infra team,
>
> I added the new periodic job for neutron-dynamic-routing[1] and
> it also can display results to grafana.
>

If the job runs on the periodic queue for the neutron-dynamic-routing
project, then the dashboard entry should really be under [1].

[1]
https://github.com/openstack-infra/project-config/blob/master/grafana/neutron-dynamic-routing.yaml


> Currently openstack-health[2] works good but grafana[3] seems not to
> work.
> Can you tell me the reason?
>

I can see it now, though usually what happens is that if there's no
failures it's difficult to detect the plot.


>
> Thank you,
> fumihiko kakuma
>
>
> [1] https://review.openstack.org/#/c/482340/
> [2] http://status.openstack.org/openstack-health/#/job/periodic-neutron-d
> ynamic-routing-dsvm-tempest-with-ryu-master-scenario-ipv4
> [3] http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelI
> d=4
>
> --
> fumihiko kakuma 
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] [infra] please help to add initial member to octavia-stable-maint group

[Armando M.]

Hi folks,

Recent change [0] created an octavia-stable-maint group. Can we seed it
with johnso...@gmail.com?

Thanks,
Armando

[0] https://review.openstack.org/#/c/405598/
[1] https://review.openstack.org/#/admin/groups/1662,members
[2] https://review.openstack.org/#/admin/groups/371,members
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

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

[Armando M.]

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.


>
> >
> > 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-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] periodic-networking-sfc-py35-with-neutron-lib-master failure

[Armando M.]

You're missing:

ostestr_compat_shim.sh

Please follow instructions as detailed on [1] and you'll find your answer.

[1]
http://docs.openstack.org/developer/neutron/stadium/governance.html#checklist
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Armando M.]

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.

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-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] adding CI job for ovs native interface

[Armando M.]

On 8 October 2015 at 16:06, fumihiko kakuma  wrote:

> Hi,
>
> Thank you for reply and adding CC.
>

Hi,

Please bring this to the attention of the Neutron IRC meeting on the 'On
Demand' section [1]. I am primarily suggesting this because it's getting
clear that we cannot keep adding new CI jobs to test all the possible
config knobs that Neutron has. Functional testing might be a better fit.

Feel free to come and find us on #openstack-neutron to discuss this further.

Cheers,
Armando

[1] https://wiki.openstack.org/wiki/Network/Meetings#On_Demand_Agenda


>
> On Thu, 8 Oct 2015 11:25:22 -0400
> Anita Kuno  wrote:
>
> > On 10/08/2015 08:06 AM, fumihiko kakuma wrote:
> > > Hello Anita,
> > >
> > > I work in ryu team in neutron.
> > >
> > > We added a interface using ryu library to the ovs mechanism
> > > driver in liberty(it is called native interface).
> > > We want to run CI for it to verify behavior of the native interface.
> > > And I pushed the change to project-config to add a job for
> > > the ovs native interface.
> > > But it is not checked for several days.
> > >
> > > Could you infra team check the following change ?
> > >
> > > https://review.openstack.org/#/c/221143/
> > >
> > >
> > > Regards,
> > >
> >
> > Hello fumihiko:
> >
> > I future it is best to email to a mailing list rather than me personally.
> >
>
> I understood it.
> I'm sorry for having sent an email personally.
>
> > Our reviewers work hard to review as many patches as they can in a day,
> > I am confident someone will review your patch as soon as they are able.
> >
>
> I understand circumstances well.
>
> > Thank you,
> > Anita.
>
> Thank you,
>
> --
> fumihiko kakuma 
>
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Help with tagging releases for networking sub-projects

[Armando M.]

On 30 September 2015 at 09:02, Jeremy Stanley  wrote:

> On 2015-09-30 10:32:45 -0500 (-0500), Kyle Mestery wrote:
> > I'm sending this email because I'm having trouble tagging and releasing
> > some networking sub-projects to PyPi.
> [...]
>
> A basic release checklist summarizing the relevant configuration
> discussed in http://docs.openstack.org/infra/manual/ is:
>
> 1. Your Gerrit ACL must allow your release manager(s) to push signed
> git tags. Without this, Gerrit will refuse the push.
>
> 2. When pushing tags you must sign them (git tag -s). Without this,
> Gerrit will refuse the push (unless the ACL is misconfigured to
> allow it, in which case it will fail to trigger the appropriate jobs
> in Zuul).
>
> 3. If your project uses PBR, you must tag with a conforming
> 3-component version string (e.g. "1.23.4" or "0.3.0").
>
> 4. You must add the publish-to-pypi project template in Zuul's
> layout (or at least individual whatever-tarball and
> whatever-pypi-wheel-upload or whatever-pypi-both-upload to the
> release pipeline). Without these, no release jobs will be run.
>
> 5. You must be able to `tox -e venv python setup.py sdist` and `tox
> -e venv python setup.py bdist_wheel` and get an sdist tarball and a
> wheel in the dist subdirectory of your checkout. This is what the
> jobs will be running to generate your release artifacts for upload.
>
> 6. You must register the matching project name at pypi.python.org
> and set the "openstackci" account with a maintainer role on it.
>
> > For another, Octavia, I've never been able to get a PyPi release
> > to happen. If you look [2], it's not there, just a stub version
> > the Octavia folks put up. For Octavia, they had some issues with
> > their PyPi project when I pushed 0.5.0 [3], so I pushed a 0.5.1
> > [4] after they addressed that but it still never showed up on
> > PyPi.
>
> Yep, this looks like at least #4 above is a problem.
>
> > I've run into a similar problem with networking-ale-omniswitch. I
> > wanted to release 1.0.0, but again, the push of the tag to gerrit
> > shows up fine in git [5] but not on PyPi [6].
> [...]
>
> Also missing #4 here. Revisiting
>
> http://docs.openstack.org/infra/manual/creators.html#configure-zuul-to-run-jobs
> may help.
> --
> Jeremy Stanley
>

Thanks for (re)sharing this knowledge with us.

I always read fungi's emails in awe, and always end up learning something
new :)

Cheers,
Armando
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra