[openstack-dev] [kuryr-kubernetes] Kuryr vPTG

[Daniel Mellado]

Hi Kuryrs!

As I promised in my earlier email, I'd like to organize a virtual team
gathering to gather around and sync for the upcoming and next release.

I've put up an etherpad [1] for gathering topics for the sessions, which
will be open until October 22nd, where I'll put up a tentative schedule
for this.

Thanks and looking forward to see you!

[1] https://etherpad.openstack.org/p/kuryr-vtg-stein


0x13DDF774E05F5B85.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing 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] [kuryr-kubernetes] PTL out for two weeks

[Daniel Mellado]

Hi all!

I'll be out for two weeks, coming back on Oct 30th. I won't cancel the
upstream meeting, which will be led by apuimedo in the meanwhile.

I also do plan to organize a vPTG, around my return date, so stay tuned
for an email with a document for topics.

See you in some days!

Best!

Daniel



0x13DDF774E05F5B85.asc
Description: application/pgp-keys


0x13DDF774E05F5B85.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing 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] Nominating Luis Tomás Bolívar for kuryr-kubernetes core

[Daniel Mellado]

Hi All,

Id like to nominate Luis Tomás for Kuryr-Kubernetes core.

He has been contributing to the project development with both features
and quality reviews at core reviewer level, as well as being the stable
branch liaison keeping on eye on every needed backport and bug and
fighting and debugging lbaas issues.

Please follow up with a +1/-1 to express your support, even if he makes
the worst jokes ever!

Thanks!

Daniel


0x13DDF774E05F5B85.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing 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] [kuryr][fuxi] Retiring fuxi* projects

[Daniel Mellado]

Hi all,

After having discussed with the project maintainers, we'll be no longer
supporting fuxi, fuxi-golang nor fuxi-kubernetes, and I'll start the
process of retiring this.

We're driving this as a part of the py3 goal and as contributors have no
longer time available to work on these projects.

Thanks for your help so far!

Best!

Daniel


0x13DDF774E05F5B85.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing 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] [Kuryr] Meeting cancelled

[Daniel Mellado Area]

Due to folks being at the Denver PTG (including myself virtually at  odd
hours x) we'll be cancelling today's weekly meeting.

Best!

Daniel
__
OpenStack Development Mailing 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] [kuryr] No meeting today

[Daniel Mellado Area]

Hi folks,

since a couple of our core reviewers are on PTO today we have decided not
to host a meeting today.

If you have any questions just ping us at #openstack-kuryr

Best!

Daniel
__
OpenStack Development Mailing 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] [kuryr] SRIOV and Multi-Vif meeting

[Daniel Mellado]

Hi everyone,

As discussed in last meeting, we'll get to use next week's one to go
over the multi-vif blueprint [1] and some discussions about its
implementation and remaining patches.

Feel free to join us at [2]

Best!

Daniel

[1] https://blueprints.launchpad.net/kuryr-kubernetes/+spec/multi-vif-pods
[2] https://bluejeans.com/4944951842


0xC905561547B09777.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing 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] [kuryr] PTL on vacation

[Daniel Mellado Area]

Hi all,

I'll be on vacation until July 31st, without easy access to email and
computer. During that time Antoni Segura Puimedon (apuimedo) will be acting
as my deputy (thanks in advance!)

Best!

Daniel
__
OpenStack Development Mailing 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] [opentack-dev][kuryr][ptl] PTL Candidacy for Kuryr - Stein

[Daniel Mellado Area]

Dear all,

I'd like to announce my candidacy for Kuryr's PTL for the Stein cycle.

In case you don't know me, I was fortunate to work as PTL on Kuryr and its
related projects for the Rocky cycle where I'm happy to say that we've
achieved most of the milestones we set. I would be honoured to continue
doing
this for the next six months.

During Stein, I would like to focus on some of these topics. We've also
started
efforts on Rocky which I'd like to lead to completion.

* Network Policy Support: This feature maps K8s network policies into
Neutron
  segurity groups and it's something I'd personally like to lead to
completion.

* Neutron pooling resource speedups: Tied closesly with the previous
feature,
  it'll be needed as a way to further improve the speed Neutron handles its
  resources.

* Operator Support

* Octavia providers:

  Native OVN Layer 4 load balancing for services
  Amphora provider for Routes

* Native router supports via Octavia

* Multi device/net support

Also, I'd like to coordinate finishing some features that might not be
making it
for the Rocky cycle, such as SRIOV and DPDK support, and adopt the usage of
CRDs
within the project.

Outside of this key areas, my priority is also helping the community by
acting
as an interface for the cross-project sessions and further improve our
presence
in initiatives such as Openlab, OPNFV and so.

Thanks a lot!

Daniel Mellado (dmellado)
__
OpenStack Development Mailing 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] [kuryr] Kuryr PTG survey

[Daniel Mellado]

Hi Kuryrs,

As you might've already been informed, next PTG [1] will be held again
in Denver, Colorado[1]. Where the pretty Rocky Mountains are and the
trains like to blow. We'd like you to have a minute and consider whether
we should be participating in this one. I personally consider that we
made great progress on last one at Dublin but would like you to fill
this form [2] before May 2nd so we can provide feedback to the
foundation. As usual, another options would be a VTG or a mid-cycle
somewhere else, depending on the planned participation.

Also take note if you haven't already that prices have changed quite a
lot, so the sooner we decide, the better.

Thanks!

Daniel

[1] https://www.openstack.org/ptg
[2]https://goo.gl/forms/HfiNnEF2CwuMva6n1



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing 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] [kuryr] Cancelling this week's kuryr meeting

[Daniel Mellado]

Hi everyone!

As a lot of people are out of office due to Easter today's meeting is
cancelled.
If anything urgent comes up, feel free to use #openstack-kuryr.

Happy Easter!




signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing 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] [Kuryr] Rocky Kuryr PTL candidacy

[Daniel Mellado]

Dear all,

I'd like to announce my candidacy for PTL of the Kuryr project for the
Rocky cycle.

After being part of the Kuryr community for a while and running the
Upstream meetings for a while I'd be delighted to continue the Toni's
great work as PTL for the next six months as he won't be running for it
this cycle.

I do intend to keep acting as an interface for the cross-project
sessions and try to use this cycle to grow on requirements and stability.

Within the Rocky cycle there's a few topics I'd like to care about:

- Further enhance our testing coverage and SDN matrix.

- Kubernetess network policies.

- SRIOV support in Kuryr-Kubernetes.

- Multi pool driver.

- Further improve debugging and instrospection tools using Kubernetes
plugins.

Also, I'll try to support the visibility within the community and be a
mediator
for growing the project scope.

Thanks a lot!

Daniel Mellado (dmellado)

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



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing 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] [devstack] Broken repo on devstack-plugin-container for Fedora

[Daniel Mellado]

Hi everyone,

Since today, when I try to install devstack-plugin-container plugin over
fedora. It complains in here [1] about not being able to sync the cache
for the repo with the following error [2].

This is affecting me on Fedora26+ from different network locations, so I
was wondering if someone from suse could have a look (it did work for
Andreas in opensuse... thanks in advance!)

[1]
https://github.com/openstack/devstack-plugin-container/blob/master/devstack/lib/docker#L164-L170

[2] http://paste.openstack.org/show/652041/

__
OpenStack Development Mailing 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] [kuryr][libnetwork] Release kuryr-libnetwork 1.x for Queens

[Daniel Mellado]

+1


El 21/1/18 a las 8:13, Irena Berezovsky escribió:
> +1
>
> On Fri, Jan 19, 2018 at 9:42 PM, Hongbin Lu  > wrote:
>
> Hi Kuryr team,
>
> I think Kuryr-libnetwork is ready to move out of beta status. I
> propose to make the first 1.x release of Kuryr-libnetwork for
> Queens and cut a stable branch on it. What do you think about this
> proposal?
>
> Best regards,
> Hongbin
>
> __
> OpenStack Development Mailing 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] [kuryr] Rocky PTG planning

[Daniel Mellado]

On 01/18/2018 05:49 PM, Daniel Mellado wrote:
> Hi everyone!
> 
> Unlike winter, PTG is coming! I've created an etherpad to track the
> topics and attendees, so please add your attendance information in the
> there.
> 
> Besides work items, maybe we can also use it to try to organize some
> kind of social event in Dublin.
> 
> Looking forward to see you all there!
> 
Forgot to put the link xD!

https://etherpad.openstack.org/p/kuryr-ptg-rocky

Best!



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing 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] [kuryr] Rocky PTG planning

[Daniel Mellado]

Hi everyone!

Unlike winter, PTG is coming! I've created an etherpad to track the
topics and attendees, so please add your attendance information in the
there.

Besides work items, maybe we can also use it to try to organize some
kind of social event in Dublin.

Looking forward to see you all there!



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing 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] [octavia] Proposing Nir Magnezi as Octavia core reviewer

[Daniel Mellado]

+1

Go, Nir, Go!

congrats!

On 10/05/2017 03:51 AM, German Eichberger wrote:
> +1
> 
> Welcome Nir, well earned.
> 
> German
> 
> On 10/4/17, 4:28 PM, "Michael Johnson"  wrote:
> 
> Hello OpenStack folks,
> 
> I would like to propose Nir Magnezi as a core reviewer on the Octavia 
> project.
> 
> He has been an active contributor to the Octavia projects for a few
> releases and has been providing solid patch review comments. His
> review stats are also in line with other core reviewers.
> 
> Octavia cores, please reply to this e-mail with your
> agreement/disagreement to this proposal.
> 
> Michael
> 
> __
> OpenStack Development Mailing 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] [kuryr] vPTG schedule

[Daniel Mellado]

Hi Hongbin,

It seems we messed up with the etherpad times, please do follow the
invite schedule for that.

Today's session will be held at 12:00 CET and 13:00 UTC (we have kist
corrected the etherpad).

Sorry for the noise!

Daniel

On 10/02/2017 03:30 AM, Hongbin Lu wrote:
> Hi Toni,
> 
> The time of a few proposed sessions look inconsistent with the etherpad.
> Could you double check?
> 
> On Thu, Sep 28, 2017 at 5:48 AM, Antoni Segura Puimedon
> > wrote:
> 
> Hi fellow Kuryrs!
> 
> It's that time of the cycle again where we hold our virtual project team
> gathering[0]. The dates this time are:
> 
> October 2nd, 3rd and 4th
> 
> The proposed sessions are:
> 
> October 2nd 13:00utc: Scale discussion
>     In this session we'll talk about the recent scale testing we
> have performed
>     in a 112 node cluster. From this starting point. We'll work on
> identifying
>     and prioritizing several initiatives to improve the performance
> of the
>     pod-in-VM and the baremetal scenarios.
> 
> October 2nd 14:00utc: Scenario testing
>     The September 27th's release of zuulv3 opens the gates for
> better scenario
>     testing, specially regarding multinode scenarios. We'll discuss
> the tasks
>     and outstanding challenges to achieve good scenario testing
> coverage and
>     document well how to write these tests in our tempest plugin.
> 
> October 3rd 13:00utc: Multi networks
>     As the Kubernetes community Network SIG draws near to having a
> consensus on
>     multi network implementations, we must elaborate a plan on a PoC
> that takes
>     the upstream Kubernetes consensus and implements it with
> Kuryr-Kubernetes
>     in a way that we can serve normal overlay and accelerated
> networking.
> 
> October 4th 14:00utc: Network Policy
>     Each cycle we aim to narrow the gap between Kubernetes
> networking entities
>     and our translations. In this cycle, apart from the Loadbalancer
> service
>     type support, we'll be tackling how we map Network Policy to Neutron
>     networking. This session will first lay out Network Policy and
> its use and
>     then discuss about one or more mappings.
> 
> October 5th 13:00utc: Kuryr-libnetwork
> 
> This session is Oct 4th in the etherpad. 
> 
>     We'll do the cycle planing for Kuryr-libnetwork. Blueprints and
> bugs and
>     general discussion.
> 
> October 6th 14:00utc: Fuxi
> 
> This session is Oct 4th in the etherpad. 
> 
>     In this session we'll discuss everything related to storage,
> both in the
>     Docker and in the Kubernetes worlds.
> 
> 
> I'll put the links to the bluejeans sessions in the etherpad[0].
> 
> 
> [0] https://etherpad.openstack.org/p/kuryr-queens-vPTG
> 
> 
> __
> OpenStack Development Mailing 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] Tacker

[Daniel Mellado]

On 08/17/2017 12:43 PM, CRISTIAN ARRIBAS GONZALEZ wrote:
> Hello,
> 
> my name is Cristian Arribas, i´m getting stated to use Tacker. I
> installed tacker
> with devstack. When I want to deploy the ns service with Tosca Template,
> a one error ocurre:
> 
> *Error: *Failed to create NS: Request Failed: internal server error
> while processing your request.
> 
> ¿What could be the problem?
> 
> Best regards.
> 
> -- 
> Cristian Arribas González
> Ingeniería de Telemática
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
Hi Christian, welcome aboard! Did you get to check any logs? I'd
recommend you to first take a look at that in order to narrow the scope.

Best!

Daniel

__
OpenStack Development Mailing 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] [kuryr] Nominate Kirill Zaitsev as kuryr-tempest-core reviewer

[Daniel Mellado]

Hi Team,

I wanted to nominate Kirill for kuryr-tempest-core reviewer. He's been a
great help from start both contributing and reviewing.

Please voice your support or concerns if any

Best!

Daniel

__
OpenStack Development Mailing 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] [l2gw] DSVM gates for networking-l2gw

[Daniel Mellado]

Hi Ricardo,

That sounds like a totally valid approach to me, but I was wondering if
there'd be a way to mock that API call. If just using the dummy driver
would achieve that then I'd be more than happy to see that modification.

Cheers!

Daniel

El 15/06/17 a las 06:38, Ricardo Noriega De Soto escribió:
> Hello L2GWers
> 
> Currently networking-l2gw CI only covers unit tests. However, there is
> an experimental check that starts a devstack VM to be able to run more
> complex tests. That experimental check is not working, and we are trying
> to fix it, however we encountered some difficulties that we wanted to
> share with you.
> 
> https://review.openstack.org/#/c/471692/
> 
> The configuration of the experimental check uses the L2GW agent which is
> very good, however, the API tests try to create a l2gw connection and
> fail since there is not an ovsdb instance with the vtep schema to execute.
> 
> If we use the dummy driver, these three failing testcases will be
> skipped and we have a way to test the API (without backend).
> 
> So for now, our proposal is to modify this experimental check using the
> dummy driver, and convert it to a possible non-voting -> voting gate
> executing pure API tests.
> 
> Furthermore, we will start working on a new gate with the l2gw agent and
> create a new OVS entity in a namespace or something similar to be able
> to test api and agent together.
> 
> Any comment is more than welcome!
> 
> Thanks guys
> 
> -- 
> Ricardo Noriega
> 
> Senior Software Engineer - NFV Partner Engineer | Office of Technology
>  | Red Hat
> irc: rnoriega @freenode
> 
> 
> 
> __
> OpenStack Development Mailing 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

[Daniel Mellado]

El 04/05/17 a las 15:52, Rossella Sblendido escribió:
> Hi all,
> 
> I've moved to a new position recently and despite my best intentions I
> was not able to devote to Neutron as much time and energy as I wanted.
> It's time for me to move on and to leave room for new core reviewers.
> 
> It's been a great experience working with you all, I learned a lot both
> on the technical and on the human side.
> I won't disappear, you will see me around in IRC, etc, don't hesitate to
> contact me if you have any question or would like my feedback on something.
> 
> ciao,
> 
> Rossella
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
Thanks Rossella! Best of luck! ;)

__
OpenStack Development Mailing 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

[Daniel Mellado]

+1

El 22/02/17 a las 11:52, Ian Wells escribió:
> +1
> 
> On 21 February 2017 at 16:18, Ichihara Hirofumi
> > wrote:
> 
> +1
> 
> 2017-02-17 14:18 GMT-05:00 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
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing 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] PTL non-candidacy

[Daniel Mellado]

El 19/01/17 a las 20:16, Ken'ichi Ohmichi escribió:
> Hi,
> 
> I will step down as PTL after this Ocata cycle.
> I was happy to see new ideas and folks who try making ideas true in
> this 2 cycles.
> Now QA project has a lot of components with many people's effort and
> we help each other as a community.
> This experience is very exciting for me, I am proud to being a member
> in this community.
> 
> Today, I'd like to concentrate on coding and reviewing again as a developer.
> I think we have good candidates for a next PTL, and I will keep active
> under the next PTL's leadership.
> 
> Thanks for choosing me anyways, let's make OpenStack quality better together 
> :-)
> 
> 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
> 
Thanks for all your hard work!!!

__
OpenStack Development Mailing 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][all] Propose to remove negative tests from Tempest

[Daniel Mellado]

El 17/03/16 a las 04:27, Assaf Muller escribió:
> On Wed, Mar 16, 2016 at 10:41 PM, Jim Rollenhagen
>  wrote:
>> On Wed, Mar 16, 2016 at 06:20:11PM -0700, Ken'ichi Ohmichi wrote:
>>> Hi
>>>
>>> I have one proposal[1] related to negative tests in Tempest, and
>>> hoping opinions before doing that.
>>>
>>> Now Tempest contains negative tests and sometimes patches are being
>>> posted for adding more negative tests, but I'd like to propose
>>> removing them from Tempest instead.
>>>
>>> Negative tests verify surfaces of REST APIs for each component without
>>> any integrations between components. That doesn't seem integration
>>> tests which are scope of Tempest.
>>> In addition, we need to spend the test operating time on different
>>> component's gate if adding negative tests into Tempest. For example,
>>> we are operating negative tests of Keystone and more
>>> components on the gate of Nova. That is meaningless, so we need to
>>> avoid more negative tests into Tempest now.
>>>
>>> If wanting to add negative tests, it is a nice option to implement
>>> these tests on each component repo with Tempest plugin interface. We
>>> can avoid operating negative tests on different component gates and
>>> each component team can decide what negative tests are valuable on the
>>> gate.
>>>
>>> In long term, all negative tests will be migrated into each component
>>> repo with Tempest plugin interface. We will be able to operate
>>> valuable negative tests only on each gate.
>> So, positive tests in tempest, negative tests as a plugin.
>>
>> Is there any longer term goal to have all tests for all projects in a
>> plugin for that project? Seems odd to separate them.
> I'd love to see this idea explored further. What happens if Tempest
> ends up without tests, as a library for shared code as well as a
> centralized place to run tests from via plugins?
I think this should be further discussed as some tests, such as the
scenario ones, make use of several projects. So for scenario tests at
least I think that we should keep them inside the core tempest repo.
Besides that such change would also affect different projects, such as
Defcore/Refstack, where the plugin usage would make complex to keep a
list of non-tree tests.
>
>> // jim
>>
>>> Any thoughts?
>>>
>>> Thanks
>>> Ken Ohmichi
>>>
>>> ---
>>> [1]: https://review.openstack.org/#/c/293197/
>>>
>>> __
>>> OpenStack Development Mailing 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] [QA] Not running for PTL

[Daniel Mellado]

Thanks Matt for all your help and support, and glad that you'll be still
around!

El 11/03/16 a las 20:34, Matthew Treinish escribió:
> Hi everyone,
>
> I'm writing this to announce that I am not running for QA PTL this cycle. I've
> been the QA PTL for the past 4 cycles and I think it's time for another person
> to take over the role. I think during the past 4 cycles the QA community has
> grown greatly and become a much larger and stronger community compared to 
> when 
> I first took on the position in the Juno cycle.
>
> I strongly believe in the diversity of leadership and ideas, and I don't want
> the community to grow stagnant because it becomes synonymous with just my 
> voice.
> Being a PTL is not the same as being an autocrat and I think it's time for
> another person to step up and take over the QA PTL spot.
>
> That being said, I'm not planning on going anywhere or leaving the project. I
> fully intend to continue working and being heavily involved with the QA 
> program,
> as I have for been the past 2 years. (although maybe with a bit more free time
> now)
>
> -Matt Treinish
>
>
> __
> OpenStack Development Mailing 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] deprecating Tempest stress framework

[Daniel Mellado]

+1 to that, it was my 2nd to-be-deprecated after javelin ;)

El 11/02/16 a las 12:47, Sean Dague escribió:
> In order to keep Tempest healthy I feel like it's time to prune things
> that are outside of the core mission, especially when there are other
> options out there.
>
> The stress test framework in tempest is one of those. It builds on other
> things in Tempest, but isn't core to it.
>
> I'd propose that becomes deprecated now, and removed in Newton. If there
> are folks that would like to carry it on from there, I think we should
> spin it into a dedicated repository and just have it require tempest.
>
>   -Sean
>


__
OpenStack Development Mailing 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][Tempest] Drop javelin off tempest

[Daniel Mellado]

Do you think that then we should mark it as 'deprecate'? so it throws a
warning when called until we finally decide to drop it off in a future
cycle?

El 11/12/15 a las 03:52, GHANSHYAM MANN escribió:
> Hi,
>
> Yes, That's very valid point about there might be some real users or in 
> future.
>
> So Instead of deleting it, how about maintaining it. Only issue here
> was gate did not
> capture the issues when introduced in his tool.
> But we can cover that using Unit tests and if really necessary we can
> add experimental job for that.
>
> 2 thing we need
> - Modify current unit tests to mock clients methods at deeper level
> instead of complete service clients class.
> - If really needed add experimental job for testing on gate.
>
> Same issue we have for cleanup tool also, I need to check where we can
> cover their testing(UT or gate job etc)
>
> I vote it to keep that (which can be useful for some users (may be
> future) who want to quickly tests their Cloud's resource
> creation/deletion etc )
>
> On Fri, Dec 11, 2015 at 1:17 AM, Matthew Treinish <mtrein...@kortar.org> 
> wrote:
>> On Thu, Dec 10, 2015 at 11:15:06AM +0100, Daniel Mellado wrote:
>>> Hi All,
>>>
>>> In today's QA meeting we were discussing about dropping Javelin off
>>> tempest if it's not being used anymore in grenade, as sdague pointed
>>> out. We were thinking about this as a part of the work for [1], where we
>>> hit issue on Javelin script testing where gate did not detect the
>>> service clients changes in this script.
>> So the reason we didn't remove this from tempest when we stopped using it as
>> part of grenade is at the time there were external users. They still wanted 
>> to
>> keep the tooling around. This is why the unit tests were grown in an effort 
>> to
>> maintain some semblance of testing after the grenade removal. (for a long 
>> time
>> it was mostly self testing through the grenade job)
>>
>>> Our intention it's to drop the following files off tempest:
>>>
>>>   * tempest/cmd/javelin.py
>>> <https://review.openstack.org/#/c/254274/3/tempest/cmd/javelin.py>
>>>   * tempest/cmd/resources.yaml
>>> <https://review.openstack.org/#/c/254274/3/tempest/cmd/resources.yaml>
>>>   * tempest/tests/cmd/test_javelin.py
>>> 
>>> <https://review.openstack.org/#/c/254274/3/tempest/tests/cmd/test_javelin.py>
>>>
>>> Before doing so, we'd like to get some feedback about out planned move,
>>> so if you have any questions, comments or feedback, please reply to this
>>> thread.
>> You should not just delete these files, there were real users of it in the 
>> past
>> and there might still be. If you're saying that javelin isn't something we 
>> can
>> realistically maintain anymore (which I'm not sure I buy, but whatever) we
>> should first mark it for deprecation and have a warning print saying it will 
>> be
>> removed in the future. This gives people a chance to stop using it and 
>> migrate
>> to something else. (using ansible would be a good alternative)
>>
>>
>> -Matt Treinish
>>
>>> ---
>>> [1]
>>> https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/consistent-service-method-names,n,z
>>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>


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

[openstack-dev] [QA][Tempest] Drop javelin off tempest

[Daniel Mellado]

Hi All,

In today's QA meeting we were discussing about dropping Javelin off
tempest if it's not being used anymore in grenade, as sdague pointed
out. We were thinking about this as a part of the work for [1], where we
hit issue on Javelin script testing where gate did not detect the
service clients changes in this script.

Our intention it's to drop the following files off tempest:

  * tempest/cmd/javelin.py
<https://review.openstack.org/#/c/254274/3/tempest/cmd/javelin.py>
  * tempest/cmd/resources.yaml
<https://review.openstack.org/#/c/254274/3/tempest/cmd/resources.yaml>
  * tempest/tests/cmd/test_javelin.py

<https://review.openstack.org/#/c/254274/3/tempest/tests/cmd/test_javelin.py>

Before doing so, we'd like to get some feedback about out planned move,
so if you have any questions, comments or feedback, please reply to this
thread.

Thanks!

Daniel Mellado

---
[1]
https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/consistent-service-method-names,n,z



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

Re: [openstack-dev] [QA][Tempest] Drop javelin off tempest

[Daniel Mellado]

Hi All,

comments inline

El 10/12/15 a las 17:17, Matthew Treinish escribió:
> On Thu, Dec 10, 2015 at 11:15:06AM +0100, Daniel Mellado wrote:
>> Hi All,
>>
>> In today's QA meeting we were discussing about dropping Javelin off
>> tempest if it's not being used anymore in grenade, as sdague pointed
>> out. We were thinking about this as a part of the work for [1], where we
>> hit issue on Javelin script testing where gate did not detect the
>> service clients changes in this script.
> So the reason we didn't remove this from tempest when we stopped using it as
> part of grenade is at the time there were external users. They still wanted to
> keep the tooling around. This is why the unit tests were grown in an effort to
> maintain some semblance of testing after the grenade removal. (for a long time
> it was mostly self testing through the grenade job)
About the unit tests, then the option would be for them to use real
clients instead of the Mock ones. Would that work for you?
>
>> Our intention it's to drop the following files off tempest:
>>
>>   * tempest/cmd/javelin.py
>> <https://review.openstack.org/#/c/254274/3/tempest/cmd/javelin.py>
>>   * tempest/cmd/resources.yaml
>> <https://review.openstack.org/#/c/254274/3/tempest/cmd/resources.yaml>
>>   * tempest/tests/cmd/test_javelin.py
>> 
>> <https://review.openstack.org/#/c/254274/3/tempest/tests/cmd/test_javelin.py>
>>
>> Before doing so, we'd like to get some feedback about out planned move,
>> so if you have any questions, comments or feedback, please reply to this
>> thread.
> You should not just delete these files, there were real users of it in the 
> past
> and there might still be. If you're saying that javelin isn't something we can
> realistically maintain anymore (which I'm not sure I buy, but whatever) we 
> should first mark it for deprecation and have a warning print saying it will 
> be
> removed in the future. This gives people a chance to stop using it and migrate
> to something else. (using ansible would be a good alternative)
Then should we just mark it as deprecate, and if so, how? I'll put a new
commit marking it as deprecate with a different commit message

Thanks
>
>
> -Matt Treinish
>
>> ---
>> [1]
>> https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/consistent-service-method-names,n,z
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [QA][Tempest] Use tempest-config for tempest-cli-improvements

[Daniel Mellado]

I still do think that even if there are some issues addressed to the
feature, such as skipping tests in the gate, the feature itself it's
still good -we just won't use it for the gates-
Instead it'd be used as a wrapper for a user who would be interested on
trying it against a real/reals clouds.

Ken, do you really think a tempest user should know all tempest options?
As you pointed out there are quite a few of them and even if they should
at least know their environment, this script would set a minimum
acceptable default. Do you think PTL and Pre-PTL concerns that we spoke
of would still apply to that scenario?

Andrey, Yaroslav. Would you like to revisit the blueprint to adapt it to
tempest-cli improvements? What do you think about this, Masayuki?

Thanks for all your feedback! ;)

El 27/11/15 a las 00:15, Andrey Kurilin escribió:
> Sorry for wrong numbers. The bug-fix for issue with counters is merged.
> Correct numbers(latest result from rally's gate[1]):
>  - total number of executed tests: 1689
>  - success: 1155
>  - skipped: 534 (neutron,heat,sahara,ceilometer are disabled. [2]
> should enable them)
>  - failed: 0
>
> [1] -
> http://logs.openstack.org/27/246627/11/gate/gate-rally-dsvm-verify-full/800bad0/rally-verify/7_verify_results_--html.html.gz
> [2] - https://review.openstack.org/#/c/250540/
>
> On Thu, Nov 26, 2015 at 3:23 PM, Yaroslav Lobankov
> <yloban...@mirantis.com <mailto:yloban...@mirantis.com>> wrote:
>
> Hello everyone,
>
> Yes, I am working on this now. We have some success already, but
> there is a lot of work to do. Of course, some things don't work
> ideally. For example, in [2] from the previous letter we have not
> 24 skipped tests, actually much more. So we have a bug somewhere :)
>
> Regards,
> Yaroslav Lobankov.  
>
> On Thu, Nov 26, 2015 at 3:59 PM, Andrey Kurilin
> <akuri...@mirantis.com <mailto:akuri...@mirantis.com>> wrote:
>
> Hi!
> Boris P. and I tried to push a spec[1] for automation tempest
> config generator, but we did not succeed to merge it. Imo,
> qa-team doesn't want to have such tool:(
>
> >However, there is a big concern:
> >If the script contain a bug and creates the configuration
> which makes
> >most tests skipped, we cannot do enough tests on the gate.
> >Tempest contains 1432 tests and difficult to detect which
> tests are
> >skipped as unexpected.
>
> Yaroslav Lobankov is working on improvement for tempest config
> generator in Rally. Last time when we launch full tempest
> run[2], we got 1154 success tests and only 24 skipped. Also,
> there is a patch, which adds x-fail mechanism(it based on
> subunit-filter): you can transmit a file with test names +
> reasons and rally will modify results.
>
> [1] - https://review.openstack.org/#/c/94473/
>
> [2] -
> 
> http://logs.openstack.org/49/242849/8/check/gate-rally-dsvm-verify/e91992e/rally-verify/7_verify_results_--html.html.gz
>
> On Thu, Nov 26, 2015 at 1:52 PM, Ken'ichi Ohmichi
> <ken1ohmi...@gmail.com <mailto:ken1ohmi...@gmail.com>> wrote:
>
> Hi Daniel,
>
> Thanks for pointing this up.
>
> 2015-11-25 1:40 GMT+09:00 Daniel Mellado
> <daniel.mellado...@ieee.org
> <mailto:daniel.mellado...@ieee.org>>:
> > Hi All,
> >
> > As you might already know, within Red Hat's tempest
> fork, we do have one
> > tempest configuration script which was built in the past
> by David Kranz [1]
> > and that's been actively used in our CI system.
> Regarding this topic, I'm
> > aware that quite some effort has been done in the past
> [2] and I would like
> > to complete the implementation of this blueprint/spec.
> >
> > My plan would be to have this script under the
> /tempest/cmd or
> > /tempest/tools folder from tempest so it can be used to
> configure not the
> > tempest gate but any cloud we'd like to run tempest against.
> >
> > Adding the configuration script was discussed briefly at
> the Mitaka summit
> > in the QA Priorities meting [3]. I propose we use the
> existing etherpad to
> > continue the discussion around and tracking of
> implementing "tempest
> > config-create&q

[openstack-dev] [QA][Tempest] Use tempest-config for tempest-cli-improvements

[Daniel Mellado]

Hi All,

As you might already know, within Red Hat's tempest fork, we do have one
tempest configuration script which was built in the past by David Kranz
[1] and that's been actively used in our CI system. Regarding this
topic, I'm aware that quite some effort has been done in the past [2]
and I would like to complete the implementation of this blueprint/spec.

My plan would be to have this script under the /tempest/cmd or
/tempest/tools folder from tempest so it can be used to configure not
the tempest gate but any cloud we'd like to run tempest against.

Adding the configuration script was discussed briefly at the Mitaka
summit in the QA Priorities meting [3]. I propose we use the existing
etherpad to continue the discussion around and tracking of implementing
"tempest config-create" using the downstream config script as a starting
point. [4]

If you have any questions, comments or opinion, please let me know.

Best Regards

Daniel Mellado

---
[1]
https://github.com/redhat-openstack/tempest/blob/master/tools/config_tempest.py
[2] https://blueprints.launchpad.net/tempest/+spec/tempest-config-generator
[3] https://etherpad.openstack.org/p/mitaka-qa-priorities
[4] https://etherpad.openstack.org/p/tempest-cli-improvements

https://github.com/openstack/qa-specs/blob/master/specs/tempest/tempest-cli-improvements.rst
__
OpenStack Development Mailing 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] Logging - filling up my tiny SSDs

[Daniel Mellado]

Also you could set up this var

LOGDAYS=1

to limit the amount of log, althougt setting the LOGDIR to /dev/null
should work too.

Cheers

Daniel

El 02/11/15 a las 04:12, Davanum Srinivas escribió:
> Sean,
>
> I typically switch off screen and am able to redirect logs to a
> specified directory. Does this help?
>
> USE_SCREEN=False
> LOGDIR=/opt/stack/logs/
>
> thanks,
> dims
>
> On Mon, Nov 2, 2015 at 4:43 AM, Sean M. Collins  > wrote:
>
> Hi,
>
> The docs right now are a little unclear about if it is possible to
> stop
> logging the output of all the screen sessions to the local filesystem.
> It has a tendency to fill up my filesystem on my little NUCs :(
> --
> Sean M. Collins
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> -- 
> Davanum Srinivas :: https://twitter.com/dims
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

[Daniel Mellado]

I could try to allocate some time for this, I think it's deff worth the
effort!

El 08/10/15 a las 02:11, Edgar Magana escribió:
> Hello,
>
> I would like to invite everybody to become an active contributor for
> the OpenStack Networking
> Guide: http://docs.openstack.org/networking-guide/
>
> During the Liberty cycle we made a lot of progress and we feel that
> the guide is ready to have even more contributions and formalize a bit
> more the team around it. 
> The first thing that I want to propose is to have a regular meeting
> over IRC to discuss the progress and to welcome new contributors. This
> is the same process that other guides like the operators one are
> following currently.
>
> The networking guide is based on this
> ToC: https://wiki.openstack.org/wiki/NetworkingGuide/TOC
> Contribution process is the same that the rest of the OpenStack docs
> under the openstack-manuals git
> repo: 
> https://github.com/openstack/openstack-manuals/tree/master/doc/networking-guide/source
>
> Please, response to this thread and let me know if you could allocate
> some time to help us to make this guide a rock star as the other ones.
> Based on the responses, I will propose a couple of times for the IRC
> meeting that could allocate to everybody if possible, this is why is
> very important to let me know your time zone.
>
> I am really looking forward to increase the contributors in this guide. 
>
> Thanks in advance!
>
> Edgar Magana
>
>
> __
> OpenStack Development Mailing 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] [infra][third-party][CI] Third-party oses in devstack-gate

[Daniel Mellado]

El 04/09/15 a las 08:11, Evgeny Antyshev escribió:
> On 01.09.2015 12:28, Evgeny Antyshev wrote:
>> Hello!
>>
>> This letter I address to those third-party CI maintainers who needs
>> to amend
>> the upstream devstack-gate to satisfy their environment.
>>
>> Some folks that I know use inline patching at job level,
>> some make private forks of devstack-gate (I even saw one on github).
>> There have been a few improvements to devstack-gate, which made it
>> easier to use it
>> downstream, f.e. introducing DEVSTACK_LOCAL_CONFIG
>> (https://review.openstack.org/145321)
>>
>> We particularly need it to recognize our rhel-based distribution as a
>> Fedora OS.
>> We cannot define it explicitly in is_fedora() as it is not officially
>> supported upstream,
>> but we can introduce the variable DEVSTACK_GATE_IS_FEDORA which makes
>> is_fedora() agnostic to distributions and to succeed if run on an
>> undefined OS.
>>
>> Here is the change: https://review.openstack.org/215029
>> I welcome everyone interested in the matter
>> to tell us if we do it right or not, and to review the change.
>>
> Prepending with [infra] tag to draw more attention
>
Personally I think that would be great, as it would greatly help finding
Fedora-ish issues with devstack, which are now only being raised by
developers due to the lack of a gate.

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