Re: [openstack-dev] [neutron] PTL candidacy for Rocky

[Morales, Victor]

+1, even if my vote doesn’t count.

From: Miguel Lavalle 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, February 5, 2018 at 11:21 AM
To: OpenStack Development Mailing List 
Subject: [openstack-dev] [neutron] PTL candidacy for Rocky

Hello OpenStack Community,
I write this to submit my candidacy for the Neutron PTL position during the 
Rocky cycle. I had the privilege of being the project's PTL for most of the 
Queens release series and want to have another opportunity helping the team and 
the community to deliver more and better networking  functionality.
I have worked for the technology industry 37+ years. After many years in 
management, I decided to return to the "Light Side of the Force", the technical 
path, and during the San Diego Summit in 2012 told the Neutron (Quantum at the 
time) PTL that one day I wanted to be a member of the core team. He and the 
team welcomed me and that started the best period of my career, not only for 
the never ending learning experiences, but more importantly, for the many 
talented women and men that I have met along the way. Over these past few years 
I worked for Rackspace, helping them to deploy and operate Neutron in their 
public cloud, IBM in their Linux Technology Center, and currently for Huawei, 
as their Neutron upstream development lead.
During the Queens release the team made significant progress in the following 
fronts:

  *   Continued with the adoption of Oslo Versioned Objects in the DB layer
  *   Implemented QoS rate limits for floating IPs
  *   Delivered the FWaaS V2.0 API
  *   Concluded the implementation of the logging API for security groups, 
which implements a way to capture and store events related to security groups.
  *   Continued moving externally referenced items to neutron-lib and adopting 
them in Neutron and the Stadium projects
  *   Welcomed VPNaaS back into the Stadium after the team put it back in shape
  *   Improved team processes such as having a pre-defined weekly schedule for 
team members to act as bug triagers, gave W+ to additional core members in 
neutron-lib and re-scheduled the Neutron drivers meeting on alternate days and 
hours to enable attendance of more people across different time zones

Some of the goals that I propose for the team to pursue during the Rocky cycle 
are:

  *   Finish the implementation of multiple port binding to solve the migration 
between VIF types in a generic way so operators can switch easily between 
backends. This is a joint effort with the Nova team
  *   Implement QoS minimum bandwidth allocation in the Placement API to 
support scheduling of instances based on the network bandwidth available in 
hosts. This is another joint effort with the Nova team
  *   Synchronize the adoption of the DB layer engine facade with the adoption 
of Oslo Versioned Objects to avoid situations where they don't cooperate nicely
  *   Implement port forwarding based on floating IPs
  *   Continue moving externally referenced items to neutron-lib and adopting 
them in Neutron and the Stadium projects. Finish documenting extensions in the 
API reference. Start the move of generic DB functionality to the library
  *   Expand the work done with the logging API in security groups to FWaaS v2.0
  *   Continue efforts in expanding our team and making its work easier. While 
we had some success during Queens, this is an area where we need to maintain 
our focus

Thank you for your consideration and for taking the time to read this

Miguel Lavalle (mlavalle)


__
OpenStack Development Mailing 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] mod_wsgi support (pike bug?)

[Morales, Victor]

Howdy,

Well, my point is that *neutron-server* can be called with several 
configuration files[1][2][3] as arguments like 

$ neutron-server --config-file /etc/neutron/neutron.conf --config-file 
/etc/neutron/ml2.ini --config-file /root/experimental.ini

Which depends on the needs of the user.  Usually these are stored in the same 
configuration directory but there is no guarantee on that.  The other thing 
that I was thinking is that given that neutron has a pluggable architecute 
maybe there are config values that define folders to load configuration info, 
something like *api_extensions_path* which defines the place of the extension 
classes.

Regards/Saludos
Victor Morales

[1] https://github.com/openstack-dev/devstack/blob/master/lib/neutron#L391-L397
[2] 
https://github.com/openstack/neutron/blob/master/neutron/server/__init__.py#L30
[3] 
https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L76-L78


On 9/15/17, 3:23 AM, "Thomas Bechtold" <tbecht...@suse.com> wrote:

Hi Victor,

On 13.09.2017 17:37,  Morales, Victor  wrote:
> As far as I remember the reason to have everything on a single file is 
because we’re trying to make Apache to load the configuration values during the 
startup.

Hm. I don't understand. With config-dirs, the service automatically 
reads also the extra files from the directories.
Am I missing something?

Best,

Tom

> 
> On 9/6/17, 9:19 PM, "Thomas Bechtold" <tbecht...@suse.com> wrote:
> 
>  Hi Kevin,
>  
>  On 04.09.2017 15:01, Kevin Benton wrote:
>  > Yes, unfortunately I didn't make it back to the patch in time to 
adjust
>  > devstack to dump all of the configuration into one file (instead of
>  > /etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc).
>  
>  You don't have to put everything into one file. oslo.config supports 
per
>  service config files and conf.d dirs[1].
>  So eg. dhcp_agent.ini could be put into
>  /etc/neutron/neutron-dhcp-agent.conf.d/foo.conf (it must end with 
.conf).
>  Maybe that's more readable than a single huge config file?
>  
>  Best,
>  
>  Tom
>  
>  [1] 
https://docs.openstack.org/releasenotes/oslo.config/ocata.html#id2
>  
>  
>  
__
>  OpenStack Development Mailing 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] mod_wsgi support (pike bug?)

[Morales, Victor]

As far as I remember the reason to have everything on a single file is because 
we’re trying to make Apache to load the configuration values during the startup.

On 9/6/17, 9:19 PM, "Thomas Bechtold"  wrote:

Hi Kevin,

On 04.09.2017 15:01, Kevin Benton wrote:
> Yes, unfortunately I didn't make it back to the patch in time to adjust 
> devstack to dump all of the configuration into one file (instead of 
> /etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc).

You don't have to put everything into one file. oslo.config supports per 
service config files and conf.d dirs[1].
So eg. dhcp_agent.ini could be put into 
/etc/neutron/neutron-dhcp-agent.conf.d/foo.conf (it must end with .conf).
Maybe that's more readable than a single huge config file?

Best,

Tom

[1] https://docs.openstack.org/releasenotes/oslo.config/ocata.html#id2


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

[Morales, Victor]

Hi Meher,

Can you include the paste for this? Can you also verify that your 
global-requirements file contains the tricircleclient module[1]?.  It seems 
like the pip_install_gr function [2][3] is not resolving [4] the 
tricircleclient module[5]

Regards,
Victor Morales

[1] 
https://github.com/openstack/requirements/blob/master/global-requirements.txt#L233
[2] https://github.com/openstack/tricircle/blob/master/devstack/plugin.sh#L323
[3] https://github.com/openstack-dev/devstack/blob/master/inc/python#L59-L70
[4] https://github.com/openstack-dev/devstack/blob/master/inc/python#L362-L372
[5] https://pypi.python.org/pypi/tricircleclient


From: "meher.h...@orange.com" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, July 24, 2017 at 8:57 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [tricircle]

Hello to the community of Openstack-Tricircle,

I hope you are all well! I postulated the problem that I encountered during the 
trial of "Single pod installation with DevStack", I managed to deploy the 
solution by trying the install on Ubuntu and not on RHEL.

Now I try "Multi-pod Installation with DevStack". On the first node, the script 
stops with an error of this form: "[ERROR] / opt / stack / devstack / inc / 
python: 256 Can not find package tricircleclient in requirements". I wanted to 
know if you have any idea how to fix this error.

I thank you in advance!

Meher

[ogo Orange]

Meher Hihi
Intern
ORANGE/IMT/OLN/WTC/CMA/MAX
Fixe : +33 2 96 07 03 
71
Mobile : +33 7 58 38 68 
87
meher.h...@orange.com



_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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] TR: [tricircle]

[Morales, Victor]

Hi Meher,

I don’t think that you need to create those folders or at least that it’s shown 
in the devstack functions[1].

Regards/Saludos
Victor Morales

[1] https://github.com/openstack-dev/devstack/blob/master/lib/apache#L178-L192

From: "meher.h...@orange.com" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, July 11, 2017 at 7:51 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] TR: [tricircle]



[ogo Orange]

Meher Hihi
Intern
ORANGE/IMT/OLN/WTC/CMA/MAX
Fixe : +33 2 96 07 03 
71
Mobile : +33 7 58 38 68 
87
meher.h...@orange.com


De : HIHI Meher IMT/OLN
Envoyé : mardi 11 juillet 2017 14:50
À : HIHI Meher IMT/OLN
Objet : RE: [openstack-dev][tricircle]

Hi Zhiyuan,

Thank you for the response! So, in this case, I just need to create two 
"sites-available" and "sites-enabled" folders under /etc/ httpd and put in the 
config files found in /etc/httpd/conf.d/?

Regards,

Meher

[ogo Orange]

Meher Hihi
Intern
ORANGE/IMT/OLN/WTC/CMA/MAX
Fixe : +33 2 96 07 03 
71
Mobile : +33 7 58 38 68 
87
meher.h...@orange.com


De : HIHI Meher IMT/OLN
Envoyé : lundi 10 juillet 2017 16:10
À : 'openstack-dev@lists.openstack.org'
Objet : RE: [openstack-dev][tricircle]

Hello everybody,

I posted before a problem related to installing the tricircle on a single node, 
the script stopped with a keystone startup. You advised me to see the / etc / 
apache2 / sites-enabled folder to see if the keystone config files are 
included. But, I have not found this folder, yet the httpd service is properly 
installed, the name of this file changes according to the distribution? I use 
RHEL 7, thank you in advance!

Meher

[ogo Orange]

Meher Hihi
Intern
ORANGE/IMT/OLN/WTC/CMA/MAX
Fixe : +33 2 96 07 03 
71
Mobile : +33 7 58 38 68 
87
meher.h...@orange.com


De : HIHI Meher IMT/OLN
Envoyé : mercredi 28 juin 2017 15:12
À : 'openstack-dev@lists.openstack.org'
Objet : [openstack-dev][tricircle]

Hello everyone,

I introduce myself; Meher Hihi; I am doing my internship at Orange Labs 
Networks Lannion-France for the diploma of computer network and 
telecommunications engineer.

I am working on innovative distribution solutions for the virtualization 
infrastructure of the network functions and more specifically on the Openstack 
Tricircle solution, which is why I join your community to participate in your 
discussions and learn from your advice.

Indeed, I try to install Tricircle on a single node by following this 
documentation 
“https://docs.openstack.org/developer/tricircle/installation-guide.html#single-pod-installation-with-devstack”.
I managed to install Devstack without any problems, but when I modify the 
local.conf file by adding the Tricircle plugin integration and the HOST_IP, the 
script does not want to work and stops on an error of Start of the Keystone 
service.

I wanted to know if the problem is with my config file that is attached or I 
lack other things to configure. You will also find in the file the IP address 
of the machine.

I thank you in advance for the help you will bring me. Sincerely,

Best regards,

Meher

[ogo Orange]

Meher Hihi
Intern
ORANGE/IMT/OLN/WNI/ODIS/NAVI
Fixe : +33 2 96 07 03 
71
Mobile : +33 7 58 38 68 

Re: [openstack-dev] [neutron] tempest failures when deploying neutron-server in wsgi with apache

[Morales, Victor]

Hi Emilien, 

I noticed that the configuration file was created using puppet.  I submitted a 
patch[1] that was targeting to include the changes in Devstack. My major 
concern is with the value of WSGIScriptAlias which should be pointing to WSGI 
script.

Regards/Saludos
Victor Morales

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

On 5/31/17, 4:40 AM, "Emilien Macchi"  wrote:

Hey folks,

I've been playing with deploying Neutron in WSGI with Apache and
Tempest tests fail on spawning Nova server when creating Neutron
ports:

http://logs.openstack.org/89/459489/4/check/gate-puppet-openstack-integration-4-scenario001-tempest-centos-7/f2ee8bf/console.html#_2017-05-30_13_09_22_715400

I haven't found anything useful in neutron-server logs:

http://logs.openstack.org/89/459489/4/check/gate-puppet-openstack-integration-4-scenario001-tempest-centos-7/f2ee8bf/logs/apache/neutron_wsgi_access_ssl.txt.gz

Before I file a bug in neutron, can anyone look at the logs with me
and see if I missed something in the config:

http://logs.openstack.org/89/459489/4/check/gate-puppet-openstack-integration-4-scenario001-tempest-centos-7/f2ee8bf/logs/apache_config/10-neutron_wsgi.conf.txt.gz

Thanks for the help,
-- 
Emilien Macchi

__
OpenStack Development Mailing 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] multi-site forum discussion

[Morales, Victor]

Armando,

I noticed that Tricircle is mentioned there.  Shouldn’t be better to extend its 
current functionality or what are the things that are missing there?

Regards,
Victor Morales

From: "Armando M." 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, May 12, 2017 at 1:06 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [neutron] multi-site forum discussion

Hi folks,

At the summit we had a discussion on how to deploy a single neutron system 
across multiple geographical sites [1]. You can find notes of the discussion on 
[2].

One key requirement that came from the discussion was to make Neutron more Nova 
cells friendly. I filed an RFE bug [3] so that we can move this forward on 
Lauchpad.

Please, do provide feedback in case I omitted some other key takeaway.

Thanks,
Armando

[1] 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18757/neutron-multi-site
[2] https://etherpad.openstack.org/p/pike-neutron-multi-site
[3] https://bugs.launchpad.net/neutron/+bug/1690425
__
OpenStack Development Mailing 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] [tricircle]mascot for the Tricircle project

[Morales, Victor]

+1

From: Zhipeng Huang 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, April 24, 2017 at 3:06 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [tricircle]mascot for the Tricircle project

perfect XD

On Mon, Apr 24, 2017 at 2:59 PM, joehuang 
> wrote:
Hello, team,

What about the mascot of Tricircle project?

Your comments are welcome.

Best Regards
Chaoyi Huang(joehuang)


From: Heidi Joy Tretheway 
[heidi...@openstack.org]
Sent: 22 April 2017 6:15
To: joehuang
Subject: Re: Question about the Tricircle mascot
Hi Joe,
Following up on your team’s mascot request, our illustrators came back with a 
beautiful piece. Would you please let me know what your team thinks?

[cid:image001.png@01D2BCCF.02FAD1D0]






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



--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing 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][gate][all] dsvm gate stability and scenario tests

[Morales, Victor]

Well my crazy idea was the addition[10] of an extra argument(—men-trace) on the 
pbr binary creation.  The idea is to be able to use it from any openstack 
binary and print those methods that are differences in the memory 
consumption[11].

Regards/Saludos
Victor Morales
irc: electrocucaracha

[10] https://review.openstack.org/#/c/433947/
[11] http://paste.openstack.org/show/599087/



From:  Jordan Pittier 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)" 

Date:  Friday, March 17, 2017 at 7:27 AM
To:  "OpenStack Development Mailing List (not for usage questions)" 

Subject:  Re: [openstack-dev] [QA][gate][all] dsvm gate stability and   
scenario tests


The patch that reduced the number of Tempest Scenarios we run in every job and 
also reduce the test run concurrency [0] was merged 13 days ago. Since, the 
situation (i.e the high number of false negative job results) has not improved 
significantly. We
 need to keep looking collectively at this.


There seems to be an agreement that we are hitting some memory limit. Several 
of our most frequent failures are memory related [1]. So we should either 
reduce our memory usage or ask for bigger VMs, with more than 8GB of RAM.


There was/is several attempts to reduce our memory usage, by reducing the Mysql 
memory consumption ([2] but quickly reverted [3]), reducing the number of 
Apache workers ([4], [5]), more apache2 tuning [6]. If you have any crazy idea 
to help in this regard,
 please help. This is high priority for the whole openstack project, because 
it's plaguing many projects.


We have some tools to investigate memory consumption, like some regular "dstat" 
output [7], a home-made memory tracker [8] and stackviz [9].


Best,

Jordan

[0]: https://review.openstack.org/#/c/439698/
[1]: http://status.openstack.org/elastic-recheck/gate.html
[2] : https://review.openstack.org/#/c/438668/
[3]: https://review.openstack.org/#/c/446196/
[4]: https://review.openstack.org/#/c/426264/
[5]: https://review.openstack.org/#/c/445910/
[6]: https://review.openstack.org/#/c/446741/
[7]: 
http://logs.openstack.org/96/446196/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/b5c362f/logs/dstat-csv_log.txt.gz
 

[8]: 
http://logs.openstack.org/96/446196/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/b5c362f/logs/screen-peakmem_tracker.txt.gz
 

[9] : 
http://logs.openstack.org/41/446741/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/fa4d2e6/logs/stackviz/#/stdin/timeline
 








On Sat, Mar 4, 2017 at 4:19 PM, Andrea Frittoli 
 wrote:

Quick update on this, the change is now merged, so we now have a smaller number 
of scenario tests running serially after the api test run.
We'll monitor gate stability for the next week or so and decide whether further 
actions are required.
Please keep categorizing failures via elastic recheck as usual.
thank you
andrea

On Fri, 3 Mar 2017, 8:02 a.m. Ghanshyam Mann,  wrote:


Thanks. +1. i added my list in ethercalc.

Left put scenario tests can be run on periodic and experimental job. IMO on 
both ( periodic and experimental) to monitor their status periodically as well 
as on particular patch if we need to. 

-gmann






On Fri, Mar 3, 2017 at 4:28 PM, Andrea Frittoli
 wrote:




Hello folks,

we discussed a lot since the PTG about issues with gate stability; we need a 
stable and reliable gate to ensure smooth progress in Pike.

One of the issues that stands out is that most of the times during test runs 
our test VMs are under heavy load.
This can be the common cause behind several failures we've seen in the gate, so 
we agreed during the QA meeting yesterday [0] that we're going to try reducing 
the load and see whether that improves stability.


Next steps are:

- select a subset of scenario tests to be executed in the gate, based on [1], 
and run them serially only 
- the patch for this is [2] and we will approve this by the end of the day
- we will monitor stability for a week - if needed we may reduce concurrency a 
bit on API tests as well, and identify "heavy" tests candidate for removal / 
refactor
- the QA team won't approve any new test (scenario or heavy resource consuming 
api) until gate stability is ensured 

Thanks for your patience and collaboration!

Andrea

---
irc: andreaf

[0] http://eavesdrop.openstack.org/meetings/qa/2017/qa.2017-03-02-17.00.txt
[1] https://ethercalc.openstack.org/nu56u2wrfb2b
[2] 

Re: [openstack-dev] [neutron] upgrades PTG recap

[Morales, Victor]

On 3/6/17, 8:28 AM, "Ihar Hrachyshka"  wrote:

>Hi all,
>
>This is a report on upgrades related topics discussed during PTG in
>Atlanta. A general PTG report from PTL can be found at:
>
>http://lists.openstack.org/pipermail/openstack-dev/2017-February/113032.html
>
>Topics discussed:
>1. OVO progress;
>2. running mixed server versions;
>3. online data migration framework;
>4. impact of new features (multiple port bindings) for mixed
>server execution, and how to deal with it;
>5. gate.
>
>=> OVO progress
>The effort is a bit stalled but slowly progressing. Progress is
>sometimes blocked by external ongoing initiatives: new oslo.db
>enginefacade; other code refactoring. Sometimes we need to back off
>and fix plugin database logic before switching to objects (think of
>lock_for_update removal in all places in current code). The initiative
>is critical only as long as there are other initiatives that would
>benefit from it. At this point, we are mainly looking at multiple port
>bindings feature and its potential impact on our ability to run mixed
>server versions at the same time. Other objects are worth an effort
>but are not critical. There may be other objects during the cycle that
>may be determined critical for rolling upgrades support.
>
>Specifically talking about lock_for_update support in objects layer:
>https://review.openstack.org/#/c/435598/ , Kevin is hesitant to add
>it. Instead we are going to clean up remaining code that uses the
>locking feature, like in https://review.openstack.org/#/c/438144/ . We
>need the same approach applied for quotas.
>
>=> Running mixed server versions
>Initial testing done by Artur showed that it's now possible to execute
>Newton and Ocata server versions in the same environment with some
>success. This is partly the result of OVO work, but also the fact that
>Ocata cycle was short and not rich on new features. We should build on
>top of that to deliver the same for Pike. We should give special
>attention to initiatives that may disrupt the work (multiple port
>bindings and others).

Regarding this testing, is there a place where it was documented, scripted or 
shared? Something that helps to someone else can take a look.  And in the other 
hand,  is there a way to simulate a “fake change” for similar releases where 
didn’t add significant features but we still need to guarantees its 
functionality. 

>
>=> Online data migration framework
>We discussed that in general there are 3 steps needed for online
>migration 1) Declaration of the intent and creating a general
>framework for online migration, 2) CLI for online migration (example
>patch https://review.openstack.org/#/c/432494/) and, 3) The changes
>made in the object layer for online data migration needs to be
>backward compatible. We sat down and looked at specific contract
>migrations from the past as a matter of case study excercise. During
>our discussion we found out that all the migrations might not be
>addressed by the general framework and will require case-by-case code
>to implement the needed transition. Actually, intent for most
>non-obvious contractions would be hard to express in a general way.

It seems like we can completely discard the point number one(the creation of a 
common framework), in other words, online data migration will be analyzed 
case-by-case.

>
>=> Impact of multiple port bindings
>Discussions suggest that the feature may be of high impact for our
>ability to deliver mixed server versions for Ocata->Pike upgrade. This
>is not because of database access not being properly aligned for the
>newly expected feature. Instead, we may hit issues because of the
>nature of the extension usage, that is usually consumed by compute
>component. Once nova switches to using the new extension to drive port
>bindings if the extension is present, and if neutron replies to nova
>that it indeed supports the new extension before all neutron-servers
>are upgraded to Pike, then it may turn out that some data stored in
>the database may not be easily implemented/acted on by older
>neutron-servers.
>
>Ideally, we would instead block any new API requests till the moment
>when all neutron-servers are running the new code, at which point they
>could start advertising the fact on /extensions/ endpoint. That would
>imply that neutron-servers become aware of each other, and extensions
>each of them support and expose. In that case, they could negotiate to
>use the common subset of extensions, and avoid exposing any extensions
>that are not implemented by any other neutron-server. In that case,
>newer servers would still behave as if they don't support new API
>features. Then once the upgrade to the new release is complete,
>neutron-servers could detect the end of upgrade phase (either through
>some external event, like admin initiated signals; or by periodic
>inspection of the server db table) and reload extensions to enable new
>API. I am going to report the 

Re: [openstack-dev] [cross-project][nova][cinder][designate][neutron] Common support-matrix.py

[Morales, Victor]

I got this link[11] from Ankur, apparently Nova and Neutron has already started 
a common effort

[11] https://review.openstack.org/#/c/330027/

Regards,
Victor Morales
irc: electrocucaracha





On 3/1/17, 5:53 PM, "Mike Perez"  wrote:

>Hey all,
>
>I kicked off a thread [1] to start talking about approaches with improving
>vendor discoveribility by improving our Market Place [2]. In order to improve
>our market place, having the projects be more part of the process would allow
>the information to be more accurate of what vendors have good support in the
>respected service.
>
>It was discovered that we have a common solution of using INI files and parsing
>that with a common support-matrix.py script that originated out of nova [3].
>I would like to propose we push this into some common sphinx extension project.
>Are there any suggestions of where that could live?
>
>I've look at how Nova [3][4], Neutron [5][6] and Designate [7][8] are doing
>this today. Nova and Neutron are pretty close, and Designate is a much more
>simplified version. Cinder [9][10] is not using INI files, but instead going
>off the driver classes themselves. Are there any other projects I'm missing?
>
>Cinder and Designate have drivers per row, as oppose to Nova and Neutron
>which have features per row. This makes sense given the difference in drivers
>versus features?
>
>I'm assuming the Designate matrix is saying every driver supports every feature
>in its API? If so, that's so awesome and makes me happy.
>
>I would like to start brainstorming on how we can converge on a common matrix
>table design so things are a bit more consistent and easier for a common
>parsing tool.
>
>
>[1] - 
>http://lists.openstack.org/pipermail/openstack-dev/2017-January/110151.html
>[2] - https://www.openstack.org/marketplace/drivers/
>[3] - 
>https://docs.openstack.org/developer/nova/support-matrix.html#operation_maintenance_mode
>[4] - 
>http://git.openstack.org/cgit/openstack/nova/tree/doc/ext/support_matrix.py
>[5] - https://review.openstack.org/#/c/318192/76
>[6] - 
>http://docs-draft.openstack.org/92/318192/76/check/gate-neutron-docs-ubuntu-xenial/48cdeb7//doc/build/html/feature_classification/general_feature_support_matrix.html
>[7] - 
>https://git.openstack.org/cgit/openstack/designate/tree/doc/ext/support_matrix.py
>[8] - https://docs.openstack.org/developer/designate/support-matrix.html
>[9] - https://review.openstack.org/#/c/371169/15
>[10] - 
>http://docs-draft.openstack.org/69/371169/15/check/gate-cinder-docs-ubuntu-xenial/aa1bdb1//doc/build/html/driver_support_matrix.html
>
>-- 
>Mike Perez
__
OpenStack Development Mailing 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] [tricircle]Nominating Victor Morales as Tricircle Core

[Morales, Victor]

Thanks everyone for voting, I started recently and I’m sure that I’ve many 
things to learn but something that I discover since the beginning was the 
enthusiasm and welcoming aptitudes of this community.  I’m going to do my best 
for keeping high standards of the code

Thanks
Victor Morales
irc: electrocucaracha

From: joehuang >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, March 2, 2017 at 1:25 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle 
Core

Thank you all for your voting.

Victor, you are now included in the core team.

Best Regards
Chaoyi Huang (joehuang)



From: Yipei Niu [newy...@gmail.com]
Sent: 01 March 2017 15:06
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle 
Core

+1.


From: joehuang
Sent: 01 March 2017 11:44
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle 
Core

+1 from my vote.

Best Regards
Chaoyi Huang (joehuang)

From: Vega Cai [luckyveg...@gmail.com]
Sent: 01 March 2017 11:42
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle 
Core

+1

Zhiyuan

On Wed, 1 Mar 2017 at 11:41 Devale, Sindhu 
> wrote:
+1

Sindhu

From: joehuang >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, February 28, 2017 at 8:38 PM
To: openstack-dev 
>
Subject: [openstack-dev] [tricircle]Nominating Victor Morales as Tricircle Core

Hi Team,

Victor Morales has made many review contributions[1] to Trircircle since the 
Ocata cycle, and he also created the python-tricircleclient sub-project[2]. I 
would like to nominate him to be Tricircle core reviewer. I really think his 
experience will help us substantially improve Trircircle.

 It's now time to vote :)

[1] http://stackalytics.com/report/contribution/tricircle/120
[2] https://git.openstack.org/cgit/openstack/python-tricircleclient/


Best Regards
Chaoyi Huang (joehuang)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
BR
Zhiyuan
__
OpenStack Development Mailing 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] [tricircle] python-tricircleclient repo officially created

[Morales, Victor]

Howdy,

I’m happy to announce that after OpenStack Governance has approved[1] and infra 
them processed the request[2],  the python-tricircleclient repository  has been 
created[3].  This client pretends to make things simpler for users who require 
multi region solutions which can be addressed by Tricircle.  Hopefully this 
project helps for the adoption and visibility of this solution.  Lastly,  this 
client is still under developing and requires all your expertise to improve it 
so feel free to add new capabilities and features that you consider necessary.

Regards,
Victor Morales
irc: electrocucaracha

[1] https://review.openstack.org/#/c/426419/
[2] https://review.openstack.org/#/c/426859/
[3] http://git.openstack.org/cgit/openstack/python-tricircleclient/
__
OpenStack Development Mailing 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] Alternative approaches for L3 HA

[Morales, Victor]

Hey Lubosz,

First of all, good job responding to the concerns of users and keeping a 
healthy OpenStack ecosystem.  I’ve one comment about this email,  maybe it was 
a cultural thing but I found it a little aggressive, specially the use of some 
pronouns and names.  I know you and I’m completely sure that your intention was 
to help others in the best way, hopefully this is not a blind spot.

Regards,
Victor Morales

From: "Kosnik, Lubosz" >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, February 13, 2017 at 10:23 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

So from my perspective I can tell that problem is completely in architecture 
and even without something outside of Neutron we cannot solve that.
Two releases ago I started to work on hardening that feature but all my ideas 
was killed by Armando and Assaf. The decided that adding outside dependency 
will open the doors for a new bugs from dependencies into Neutron [1].

You need to know that there are two outstanding bugs in this feature. There is 
a internal and outside connectivity split brain. [2] this patch made by me is 
“fixing” part of the problem. It allows you specify additional tests to verify 
connectivity from router to GW.
Also there is a problem with connectivity between network nodes. It’s more 
problematic and like you said it’s unsolvable in my opinion without using 
external mechanism.

If there will be any need to help with anything I would love to help with 
sharing my knowledge about this feature and what exactly is not working. If 
anyone needs any help with anything about this please ping me on email or IRC.

[1] https://bugs.launchpad.net/neutron/+bug/1375625/comments/31
[2] https://review.openstack.org/#/c/273546/

Lubosz

On Feb 13, 2017, at 4:10 AM, Anna Taraday 
> wrote:

To avoid dependency of data plane on control plane it is possible to deploy a 
separate key-value storage cluster on data plane side, using the same network 
nodes.
I'm proposing to make some changes to enable experimentation in this field, we 
are yet to come up with any other concrete solution.

On Mon, Feb 13, 2017 at 2:01 PM 
> wrote:

Hi,





We also operate using Juno with the VRRP HA implementation and at had to patch 
through several bugs before getting to the Mitaka release.

An pluggable, drop-in alternative would be highly appreciated. However our 
experience has been that the decoupling of VRRP from the control plane is 
actually a benefit as when the control plane is down the traffic is not 
affected.

In a solution where the L3 HA implementation becomes tied to the availability 
of the control plane (etcd cluster or any other KV store) then an operator 
would have to account for extra failure scenarios for the KV store which would 
affect multiple routers than the outage of a single L3 node which is the case 
we usually have to account now.





Just my $.02



Cristian



From: Anna Taraday 
[mailto:akamyshnik...@mirantis.com]
Sent: Monday, February 13, 2017 11:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA



In etcd for each HA router we can store key which will identify which agent is 
active. L3 agents will "watch" this key.
All these tools have leader election mechanism which can be used to get agent 
which is active for current HA router.



On Mon, Feb 13, 2017 at 7:02 AM zhi 
> wrote:

Hi, we are using L3 HA in our production environment now. Router instances 
communicate to each other by VRRP protocol. In my opinion, although VRRP is a 
control plane thing, but the real VRRP traffic is using data plane nic so that 
router namespaces can not talk to each other sometimes when the  data plan is 
busy. If we were used etcd (or other), does every router instance register one 
"id" in etcd ?





Thanks

Zhi Chang

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

--

Regards,
Ann Taraday

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou 

Re: [openstack-dev] [gate][neutron][infra] tempest jobs timing out due to general sluggishness of the node?

[Morales, Victor]

On 2/9/17, 10:59 PM, "Ihar Hrachyshka"  wrote:

>Hi all,
>
>I noticed lately a number of job failures in neutron gate that all
>result in job timeouts. I describe
>gate-tempest-dsvm-neutron-dvr-ubuntu-xenial job below, though I see
>timeouts happening in other jobs too.
>
>The failure mode is all operations, ./stack.sh and each tempest test
>take significantly more time (like 50% to 150% more, which results in
>job timeout triggered). An example of what I mean can be found in [1].
>
>A good run usually takes ~20 minutes to stack up devstack; then ~40
>minutes to pass full suite; a bad run usually takes ~30 minutes for
>./stack.sh; and then 1:20h+ until it is killed due to timeout.
>
>It affects different clouds (we see rax, internap, infracloud-vanilla,
>ovh jobs affected; we haven't seen osic though). It can't be e.g. slow
>pypi or apt mirrors because then we would see slowdown in ./stack.sh
>phase only.
>
>We can't be sure that CPUs are the same, and devstack does not seem to
>dump /proc/cpuinfo anywhere (in the end, it's all virtual, so not sure

I don’t think that logging this information could be useful mainly because this 
depends on enabling *host-passthrough*[3] in nova-compute configuration of 
Public cloud providers

>if it would help anyway). Neither we have a way to learn whether
>slowliness could be a result of adherence to RFC1149. ;)
>
>We discussed the matter in neutron channel [2] though couldn't figure
>out the culprit, or where to go next. At this point we assume it's not
>neutron's fault, and we hope others (infra?) may have suggestions on
>where to look.
>
>[1] 
>http://logs.openstack.org/95/429095/2/check/gate-tempest-dsvm-neutron-dvr-ubuntu-xenial/35aa22f/console.html#_2017-02-09_04_47_12_874550
>[2] 
>http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2017-02-10.log.html#t2017-02-10T04:06:01
[3] 
http://docs.openstack.org/newton/config-reference/compute/hypervisor-kvm.html 

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

[Morales, Victor]

One  of my favorites is the usage of #undo command during the meetings for 
fixing a quick copy & paste link.  Should be necessary to include more 
information in this wiki entry[1]

Victor Morales
irc: electrocucaracha

[1] https://wiki.openstack.org/wiki/UsingIRC

From: Rob C >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, February 9, 2017 at 6:57 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [All] IRC Mishaps

#startmeeting in the wrong channel

#startmeeting in the right channel but at the wrong time

#startmeeting in the right channel and at the right time but someone else 
already started it

I'm basically a pro at meetings.

On Thu, Feb 9, 2017 at 1:14 AM, Lana Brindley 
> wrote:
On 09/02/17 06:36, Kendall Nelson wrote:
> Hello All!
>
> So I am sure we've all seen it: people writing terminal commands into our 
> project channels, misusing '/' commands, etc. But have any of you actually 
> done it?
>
> If any of you cores, ptls or other upstanding members of our wonderful 
> community have had one of these embarrassing experiences please reply! I am 
> writing an article for the SuperUser trying to make us all seem a little more 
> human to people new to the community and new to using IRC. It can be scary 
> asking questions to such a large group of smart people and its even more off 
> putting when we make mistakes in front of them.
>
> So please share your stories!

What about the one where you're conducting a private conversation in one 
window, and watching a group chat in another one, and then drop some deeply 
personal (or embarrassing!) content in the group chat instead the PM ;)

L

--
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com


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


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

[Morales, Victor]

Howdy,

First of all, thanks for the creation of this space to discuss about shouldn’t 
be something common(in an utopia) but it’s part of our daily duties.  I’m not 
sure if this is the right venue but I discovered today that the current 
implementation of the job for coverage[1] only valides the creation of the 
report and it doesn’t guarantee that the code coverage percentage drops (we’re 
relying on code reviewers to avoid that).  I’m wondering if we could propose 
something to openstack-infra for enabling a threshold on the gates.

Regards, 
Victor Morales
irc: electrocucaracha

[1] 
https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/python-jobs.yaml#L17
 


PS: Congrats Ihar for your new role



From:  "Armando M." 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)" 

Date:  Tuesday, January 31, 2017 at 1:47 PM
To:  "OpenStack Development Mailing List (not for usage questions)" 

Subject:  [openstack-dev] [neutron] Neutron CI team meeting


Hi folks,

Recently [1], a new meeting has been setup to give the neutron team a dedicated 
time to discuss any upstream CI matter (gate issues, testing strategies, etc), 
as well as an overflow space to be used after the main team meeting section 
[3]. Kudos to Ihar
 for being our first chair.

Needless to say, attendance is welcome.

Cheers,
Armando

[1] https://review.openstack.org/#/c/426311/
[2] https://wiki.openstack.org/wiki/Meetings/NeutronCI
[3] https://wiki.openstack.org/wiki/Network/Meetings#Bugs_and_Gate_issues
__
OpenStack Development Mailing 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] PTL Candidacy

[Morales, Victor]

Definitely, both are great candidates and my best wishes to both during this 
process.

Given the latest issues related with the memory consumption[1] in CI jobs, I’m 
just wondering if you have a plan to deal and/or improve it in Neutron.

Regards,
Victor Morales
irc: electrocucaracha





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


On 1/24/17, 12:51 PM, "Ihar Hrachyshka"  wrote:

>On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
>> I'm on board with getting visibility into the drivers with improvements to
>> driverlog, etc. What I'm uncertain of is providing much in the lines of
>> 'validation'. Core reviewers don't frequently have access to the hardware or
>> software required to validate these drivers so we can't be sure if the
>> features really are working as expected.
>>
>> If validation is as flexible as you highlighted in the email, we can at
>> least get it to a point where all recent CI runs are linkable from driverlog
>> and people can see recent tempest runs. I don't foresee the Neutron team
>> getting to a point soon where we vouch for certain drivers though just
>> because it is so hard to keep up with their changes (even ignoring changes
>> in the vendor hardware itself).
>
>Good point. We may guide plugins and drivers on how to set up CI; we
>may help Foundation to set up Marketplace in such a way that would
>allow to automatically consume test artifacts from driver owners; we
>may provide guidance to Foundation about which features are more
>important to reflect that in Marketplace; but I would hope we don't
>put the Neutron team on the hook to validate each driver, or even
>police CI owners to produce consumable results. (The stick in the
>latter case would be driver not showing up in Marketplace, or showing
>up with no feature support information.)
>
>Ihar
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Improving Vendor Driver Discoverability

[Morales, Victor]

Just a FYI, Ankur have been working on have a Feature Classification Matrix in 
Neutron[1] which collects some of this information

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

Regards/Saludos
Victor Morales
Irc: electrocucaracha





On 1/13/17, 10:29 PM, "Mike Perez"  wrote:

>Hello all,
>
>In the spirit of recent Technical Committee discussions I would like to bring
>focus on how we're doing vendor driver discoverability. Today we're doing this
>with the OpenStack Foundation marketplace [1] which is powered by the driverlog
>project. In a nutshell, it is a big JSON file [2] that has information on which
>vendor solutions are supported by which projects in which releases. This
>information is then parsed to generate the marketplace so that users can
>discover them. As discussed in previous TC meetings [3] we need to recognize
>vendors that are trying to make great products work in OpenStack so that they
>can be successful, which allows our community to be successful and healthy.
>
>In the feedback I have received from various people in the community, some
>didn’t know how it worked, and were unhappy that the projects themselves
>weren’t owning this. I totally agree that project teams should own this and
>should be encouraged to be involved in the reviews. Today that’s not happening.
>I’d like to propose we come up with a way for the marketplace to be more
>community-driven by the projects that are validating these solutions.
>
>At the Barcelona Summit [4] we discussed ways to improve driverlog. Projects
>like Nova have a support matrix of hypervisors in their in-tree documentation.
>Various members of the Cinder project also expressed interest in using this
>solution. It was suggested in the session that the marketplace should just link
>to the projects' appropriate documentation. The problem with this solution is
>the information is not presented in a consistent way across projects, as
>driverlog does it today. We could accomplish this instead by using a parsable
>format that is stored in each appropriate project's git repository. I'm
>thinking of pretty much how driverlog works today, but broken up into
>individual projects.
>
>The marketplace can parse this information and present it in one place
>consistently. Projects may also continue to parse this information in their own
>documentation, and we can even write a common tool to do this. The way a vendor
>is listed here is based on being validated by the project team itself. Keeping
>things in the marketplace would also address the suggestions that came out of
>the recent feedback we received from various driver maintainers [4].
>
>The way validation works is completely up to the project team. In my research
>as shown in the Summit etherpad [5] there's a clear trend in projects doing
>continuous integration for validation. If we wanted to we could also have the
>marketplace give the current CI results, which was also requested in the
>feedback from driver maintainers.
>
>I would like to volunteer in creating the initial files for each project with
>what the marketplace says today.
>
>[1] - https://www.openstack.org/marketplace/drivers/
>[2] - 
>http://git.openstack.org/cgit/openstack/driverlog/tree/etc/default_data.json
>[3] - 
>http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-01-10-20.01.log.html#l-106
>[4] - 
>http://lists.openstack.org/pipermail/openstack-dev/2017-January/109855.html
>[5] - https://etherpad.openstack.org/p/driverlog-validation
>
>-- 
>Mike Perez
>
>__
>OpenStack Development Mailing 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] Confusion around the complexity

[Morales, Victor]

My two cents on this

Agree with Kevin, IaaS solutions(like CloudStack, OpenNebula, OpenStack, etc.) 
offer a deep level of customization for those apps which requires fine-grained 
control of Cloud resources with the disadvantage of increasing the time 
required for developing them. By other hand, PaaS solutions (e.g Cloud Foundry, 
OpenShift, etc) usually deployed on top of IaaS solutions, offer a quicker 
development process but lower level of customization associated with poor 
performance or scalability controlled by the PaaS solution.  Lastly, my 
understanding is that the term "legacy apps” refers to non-cloud aware 
applications usually with monolithic instead of using microservices 
architecture and/or publish/subscribe pattern.

Regards, 
Victor Morales

irc: electrocucaracha




On 1/13/17, 12:38 AM, "Joshua Harlow"  wrote:

>Kevin Benton wrote:
>> If you don't want users to specify network details, then use the get me
>> a network extension or just have them boot to a public (or other
>> pre-created) network.
>>
>> In your thought experiment, why is your iPhone app developer not just
>> using a PaaS that handles instance scaling, load balancing and HA? Why
>> would he/she want to spend time managing security updates and log
>> rotation for an operating system running inside another program
>> pretending to be hardware? Different levels of abstraction solve
>> different use cases.
>
>Fair point, probably mr/mrs iPhone app developer should be doing that.
>
>>
>> Amazon VPC exists (and is the default) for the same reason neutron
>> provides network virtualization primitives. People moving legacy apps
>> onto these systems end up needing specific addressing schemes and
>> isolation topologies.
>>
>
>What's a legacy app, sounds sorta dirty lol
>
>__
>OpenStack Development Mailing 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] PTL nominations deadline and non-candidacy

[Morales, Victor]

Those are sad news for starting this year.  First of all, grazie for being the 
PTL of Neutron during these last releases.  When I started contributing to 
neutron, I noticed that this community is so vibrant and passioned, that this 
energy needs to be properly addressed and you have demonstrated to posses those 
skills required for that.  Thanks for that effort and enthusiasm.

Victor Morales

From: "Armando M." >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, January 9, 2017 at 8:11 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [neutron] PTL nominations deadline and non-candidacy

Hi neutrinos,

The PTL nomination week is fast approaching [0], and as you might have guessed 
by the subject of this email, I am not planning to run for Pike. If I look back 
at [1], I would like to think that I was able to exercise the influence on the 
goals I set out with my first self-nomination [2].

That said, when it comes to a dynamic project like neutron one can't never 
claim to be *done done* and for this reason, I will continue to be part of the 
neutron core team, and help the future PTL drive the next stage of the 
project's journey.

I must admit, I don't write this email lightly, however I feel that it is now 
the right moment for me to step down, and give someone else the opportunity to 
grow in the amazing role of neutron PTL! I have certainly loved every minute of 
it!

Cheers,
Armando

[0] https://releases.openstack.org/ocata/schedule.html
[1] 
https://review.openstack.org/#/q/project:openstack/election+owner:armando-migliaccio
[2] https://review.openstack.org/#/c/223764/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] proposing Miguel Lavalle as neutron core and Brian Haley as L3 Lt

[Morales, Victor]

More likely, my vote doesn’t count but I’ve seen them very actively 
contributing, so +1

From: "Armando M." >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, December 15, 2016 at 5:14 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [neutron] proposing Miguel Lavalle as neutron core and 
Brian Haley as L3 Lt

Hi neutrinos,

Miguel Lavalle has been driving the project forward consistently and reliably. 
I would like to propose him to be entrusted with +2/+A rights in the areas he's 
been most prolific, which are L3 and DHCP.

At the same time, I'd like to propose Brian Haley as our next Chief L3 Officer. 
Both of them have worked with Carl Baldwin extensively and that can only be a 
guarantee of quality.

Cheers,
Armando

[1] https://review.openstack.org/#/c/411531/
__
OpenStack Development Mailing 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] [oslo] Propose to normalize namespaces

[Morales, Victor]

Hey there, 

There is a mismatch of namespaces in neutron which uses AGENT and agent which 
is addressed by Ihar in the patch[1].  That raised the question is 
olo-config-generator should be normalize this namespaces, maybe(with my limited 
knowledge of oslo.conf) this change can be placed in _clean_opts function[2].  
I personally like what Doug is suggesting[3], emitting a warning where is 
mixing case, which at least give us an idea of places where is having the same 
issue and eventually normalize them.  Any thoughts on this?

Regards, 

Victor Morales

[1] https://review.openstack.org/#/c/404362
[2] 
https://github.com/openstack/oslo.config/blob/master/oslo_config/generator.py#L331-L362
[3] https://bugs.launchpad.net/oslo.config/+bug/1646084/comments/2
__
OpenStack Development Mailing 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

[Morales, Victor]

Henry, it has been a pleasure to have been working with you and thanks for 
supporting this community and helping us to get involved quickly.  Best wishes 
for your new adventure.

Thanks
Victor Morales

PS:  Hopefully your Linkedin photo was not taken couple days before you started 
working in Neutron :P




On 12/1/16, 4:51 PM, "Henry Gessau"  wrote:

>I've already communicated this in the neutron meeting and in some neutron
>policy patches, but yesterday the PTL actually updated the gerrit ACLs so I
>thought I'd drop a note here too.
>
>My work situation has changed and leaves me little time to keep up with my
>duties as core reviewer, DB lieutenant, and drivers team member.
>
>Working with the diverse and very talented contributors to Neutron has been
>the best experience of my career (which started before many of you were born).
>Thank you all for making the team such a great community. Because of you the
>project is thriving and will continue to be successful!
>
>I will still be around on IRC, contribute some small patches here and there,
>and generally try to keep abreast of Neutron's progress. Don't hesitate to
>ping me.
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing 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 as testing lieutenant and from the core & drivers teams

[Morales, Victor]

It’s sad to read this, I’m still digesting some of your articles of your blog.  
Thanks for all of those years of making OpenStack Quantum/Neutron better.

Regards,
Victor Morales



On 11/28/16, 12:58 PM, "Assaf Muller"  wrote:

>Hi all,
>
>For the past few months I've been gaining more responsibilities within
>Red Hat. I have less time to dedicate to personal contribution and
>it's had a considerable tole on my ability to perform my duties
>upstream to the degree of effectiveness I am satisfied with. To that
>end, I've decided that the right thing to do is to hand over my
>testing lieutenant responsibilities to Jakub Libosvar, and to step
>down from the core and drivers team.
>
>This is a bitter sweet moment. I'm enormously proud to see the
>progress Neutron as a platform, community and as a reference
>implementation have made over the last 3 years and I'm thrilled to
>have taken part in that. It's grown from an experiment to a ubiquitous
>OpenStack project with a proven, robust and scalable
>batteries-included implementation used at the largest retail,
>insurance, banking, web and telco (And more!) companies in the world.
>My focus will remain on OpenStack networking but my contributions will
>be indirect through my amazing team members. The people leading
>Quantum when I joined are nearly all gone and luckily we've seen a
>continuous influx of fresh talent ready to take over leadership
>responsibilities. I'm confident the wheel will keep on spinning and
>the project will continue stepping down the right path.
>
>I'll still be on IRC and I'll be working over the upcoming couple of
>weeks to hand off any specific tasks I had going on. Have fun folks.
>
>__
>OpenStack Development Mailing 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][metadata] Is there HTTP attack issue in metadata proxy functionality offered by reference implementation?

[Morales, Victor]

Thant’s remind me when we tried to improve cloud-init.  Basically, the 
discovery process checks sequentially where the instance is being landed(EC2, 
GoogleCompute, OpenStack).  This process could be done in parallel and reduce 
the time to boot.

Regards, 
Victor Morales




On 11/16/16, 11:31 AM, "Mathieu Gagné"  wrote:

>On Wed, Nov 16, 2016 at 11:52 AM, Clint Byrum  wrote:
>>
>> IMO the HTTP metadata service and the way it works is one of the worst
>> ideas we borrowed from EC2. Config drive (which I didn't like when I
>> first saw it, but now that I've operated clouds, I love) is a simpler
>> system and does not present any real surface area to the users.
>>
>
>Cannot agree more with you on that one.
>
>--
>Mathieu
>
>__
>OpenStack Development Mailing 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

[Morales, Victor]

Hey Carl,

These are sad news, thanks for those years helping to make OpenStack better, 
best of the wishes for your future assignments.

Thanks,
Victor Morales

From: Carl Baldwin >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, November 17, 2016 at 12:42 PM
To: OpenStack Development Mailing List 
>
Subject: [openstack-dev] [Neutron] Stepping down from core

Neutron (and Openstack),

It is with regret that I report that my work situation has changed such that 
I'm not able to keep up with my duties as a Neutron core reviewer, L3 
lieutenant, and drivers team member. My participation has dropped off 
considerably since Newton was released and I think it is fair to step down and 
leave an opening for others to fill. There is no shortage of talent in Neutron 
and Openstack and I know I'm leaving it in good hands.

I will be more than happy to come back to full participation in Openstack and 
Neutron in the future if things change again in that direction. This is a great 
community and I've had a great time participating and learning with you all.

Well, I don't want to drag this out. I will still be around on IRC and will be 
happy to help out where I am able. Feel free to ping me.

Carl
__
OpenStack Development Mailing 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] OVO support

[Morales, Victor]

My two cents on this.   

OVO is going to be the new layer to access to DB model classes, therefore all 
the calls to the database(ensuring that there is an opened session) and the 
process to receive(validating fields) and/or return data(determining if a 
specific column exists) should be managed by OVO classes internally, so that’s 
also my understanding.

Regards,
Victor Morales

From:  Gary Kotton 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)" 

Date:  Tuesday, November 15, 2016 at 3:06 AM
To:  OpenStack List 
Subject:  [openstack-dev] [neutron] OVO support


Hi,
It seems like a lot of the object work is being done under database 
transactions. My understanding is that the objects should take care of this 
internally.
Any thoughts?
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

Re: [openstack-dev] [Neutron] Database field sizes and attribute "MAX_LEN" constants

[Morales, Victor]

I just want to add my two cents on this.  Several months ago I asked to nova 
community about a bug that they decided to don’t implement, this bug was 
suggesting to add a validation to String OVO field[1] to check if the length of 
the columns has been changed, the answer was that they considered hard to track 
those DB changes.  I mentioned this because maybe we can explore this other 
alternative, just in case that we don’t have the same type of restrictions that 
nova has. By other hand, if our goal is ensuring that integrity of the class 
maybe we can validate them as we do in OVO, using a hash code.

[1] 
https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/fields.py#L254-L265





On 10/15/16, 2:36 PM, "Henry Gessau"  wrote:

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

[Morales, Victor]

+1

From: Miguel Lavalle
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Friday, October 14, 2016 at 1:30 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron] Neutron team social event in Barcelona

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-dev] [neutron][upgrades] Bi-weekly upgrades work status. 9/19/2016

[Morales, Victor]

Hi neutrinos,

The idea of this email is to summarize the effort that we're making during the 
implemetation of Rolling upgrades in Neutron, as well as 
sharing the upcoming changes.

Announcements


Neutron Newton RC1 has been created and this contains the following changes 
related to OVO:
https://review.openstack.org/#/dashboard/?foreach=%28project%3Aopenstack%2Fneutron%29%0Astatus%3Amerged+after%3A2016%2D04%2D04+before%3A2016%2D09%2D19=Neutron+Upgrades+%2D+Newton%2DVersioned+Object+Creation+and+Integration=%28topic%3Abp%2Fadopt%2Doslo%2Dversioned%2Dobjects%2Dfor%2Ddb+OR+topic%3Aovo%29+DB+model+classes=topic%3Abug%2F1597913

Here, let's just outline general plan:
- Move DB model classes to avoid cyclic imports. 
https://review.openstack.org/#/q/status:open+topic:bug/1597913
- Land Oslo-Versioned Objects
- Adopt them in plugin code, this means the replacement of the exisiting 
calls for corresponding OVO functions. 

Ocata release will last 4.5 months only. Though the cycle is short, the plan is 
to make it the first release that supports partial upgrade
for neutron-servers. It means we will need to forbid contract alembic scripts 
during this cycle.

Model Relocation 
=

SubnetServiceType, FlatAllocation, GreAllocation and GreEndpoints models have 
been already moved into neutron/db/models folder.  The 
plan is to move the DB model classes that share file with mixin class ( 
https://review.openstack.org/#/q/status:open+topic:bug/1597913 )

OVO Neutron Framework
===

There are some cases where the API receives filters which are not defined in 
the model.( e. g. for the query to filter Subnet model class 
is using 'admin_state_up' as filter).  This behaviour is not allowed in the 
strict OVO implementation, so it was required to make optional
this restriction. https://review.openstack.org/#/c/365659/

Subnet OVO has been created but its integration is in progress, so any feedback 
is welcome
https://review.openstack.org/#/c/321001/ 
 https://review.openstack.org/#/c/351740/

Regarding the way to replace inner and outer joins on the current way that 
models have been implemented is something that has not 
been defined yet.  The initial approach to follow is trying to create a new 
classmethod in the most relevant OVO class and move that logic
into the OVO class.  Obviously, this varies case by case.

It has been identified some cases where methods passes DB session as an 
argument instead of a Application Context.  This has a direct impact on the way 
to
replace code with OVO classes because they use context for doing DB changes 
internally.  It was decided to consider changes on method signature whenever
it's possible with the only exception to don't modify the any method that 
afects the API.

OVO Implementation Dashboard  ->  
https://docs.google.com/spreadsheets/d/1FeeQlQITsZSj_wpOXiLbS36dirb_arX0XEWBdFVPMB8

http://eavesdrop.openstack.org/meetings/neutron_upgrades/2016/neutron_upgrades.2016-09-12-15.01.log.html
http://eavesdrop.openstack.org/meetings/neutron_upgrades/2016/neutron_upgrades.2016-09-19-15.00.log.html



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

Re: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers team

[Morales, Victor]

This achievement reflects the constant effort you makes in OpenStack, kudos Ihar

From: "Armando M."
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Saturday, September 17, 2016 at 11:40 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers team

Hi folks,

I would like to propose Ihar to become a member of the Neutron drivers team [1].

Ihar wide knowledge of the Neutron codebase, and his longstanding duties as 
stable core, downstream package whisperer, release and oslo liaison (I am sure 
I am forgetting some other capacity he is in) is going to put him at great 
comfort in the newly appointed role, and help him grow and become wise even 
further.

Even though we have not been meeting regularly lately we will resume our 
Thursday meetings soon [2], and having Ihar onboard by then will be highly 
beneficial.

Please, join me in welcome Ihar to the team.

Cheers,
Armando

[1] 
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
[2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] OVO Status Dashboard

[Morales, Victor]

Hey neutrinos,

First of all, the high priority for OVO implementation in newton release are 
the implementation and integration of port, subnet and network objects, but 
given that more people is joining to this initiative and also many patches are
related directly and indirectly to this, results in something hard to track. 
So, I decided to create this document[1] to visualize and coordinate efforts.
Feel free to include, modify or add missing things but even more try to review 
existing patches and help us to achieve our goal.

[1] 
https://docs.google.com/spreadsheets/d/1FeeQlQITsZSj_wpOXiLbS36dirb_arX0XEWBdFVPMB8/edit?usp=sharing

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

Re: [openstack-dev] [neutron][db][models]

[Morales, Victor]

Manjeet, 

Tony has some issues moving model classes to other location. Given that some 
class models are used by other neutron services, Ihar suggest to use 
debtcollector to make this transition smoothly.  Can we include that solution 
as part of this movement?

Thanks
Victor Morales



On 7/28/16, 12:19 PM, "Bhatia, Manjeet S"  wrote:

>
>Ihar Hrachyshka  wrote:
>> Manjeet S  wrote:
>> 
>>> Hello Team,
>>>
>>> I have a question regarding centralizing all db models in neutron. As 
>>> you all know Oslo versioned object work is under progress and I also 
>>> had a ticket opened for refactoring Db models. 
>>> (https://bugs.launchpad.net/neutron/+bug/1597913). There are three 
>>> way I can do this, 1, move all models to db/models_v2.py 2, create a 
>>> new dir db/models/ and move whatever models are giving issue Of 
>>> cyclic import to db_models.py under db/models/ tree but all in same 
>>> file, 3rd is move into different files under Same tree db/models. I 
>>> liked second way better, please let me know which one according to 
>>> experienced developers is better, I’ll do that way.
>> 
>> I don’t think 2. is the best way forward because it still keeps all 
>> models in a single file with no classification. I prefer we split 
>> models by topic, so option 3.
>> 
>> I took the approach for security groups here:  
>> https://review.openstack.org/#/c/284738/49/neutron/db/models/securityg
>> roup.py
>
>>I also prefer this organization (option 3).
>
>Ok thanks will follow 3.
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>__
>OpenStack Development Mailing 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][Infra] Post processing of gate hooks on job timeouts

[Morales, Victor]

On 4/11/16, 5:07 AM, "Jakub Libosvar"  wrote:

>Hi,
>
>recently we hit an issue in Neutron with tests getting stuck [1]. As a
>side effect we discovered logs are not collected properly which makes it
>hard to find the root cause. The reason of missing logs is that we send
>SIGKILL to whatever gate hook is running when we hit the global timeout
>per gate job [2]. This gives no time to running process to perform any
>post-processing. In post_gate_hook function in Neutron, we collect logs
>from /tmp directory, compress them and move them to /opt/stack/logs to
>make them exposed.
>
>I have in mind two solutions to which I'd like to get feedback before
>sending patches.
>
>1) In Neutron, we execute tests in post_gate_hook (dunno why). But even
>if we would have moved test execution into gate_hook and tests get stuck
>then the post_gate_hook won't be triggered [3]. So the solution I
>propose here is to terminate gate_hook N minutes before global timeout
>and still execute post_gate_hook (with timeout) as post-processing routine.
>
>2) Second proposal is to let timeout wrapped commands know they are
>about to be killed. We can send let's say SIGTERM instead of SIGKILL and
>after certain amount of time, send SIGKILL. Example: We send SIGTERM 3
>minutes before global timeout, letting these 3 minutes to 'command' to
>handle the SIGTERM signal.
>
> timeout -s 15 -k 3 $((REMAINING_TIME-3))m bash -c "command"
>
>With the 2nd approach we can trap the signal that kills running test
>suite and collects logs with same functions we currently have.
>
>
>I would personally go with second option but I want to hear if anybody
>has a better idea about post processing in gate jobs or if there is
>already a tool we can use to collect logs.

I also like the second option, it seems less aggressive and give opportunity to 
catch
more information before killing processes.  Ideally, timeouts are ultimatums 
for worst-case scenarios
and should be never reach it.

>
>Thanks,
>Kuba
>
>
>[1] https://bugs.launchpad.net/bugs/1567668
>[2]
>https://github.com/openstack-infra/devstack-gate/blob/master/functions.sh#L1151
>[3]
>https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate-wrap.sh#L581
>
>__
>OpenStack Development Mailing 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] [devstack][neutron] Eliminating the DevStack layer

[Morales, Victor]

Agree, sometimes is hard to figure out what is the Devstack variable that will 
modify the configuration value.

There is an effort to categorize the configuration options[1] of some of the 
projects.  I’m wondering if it could be possible to create category or field 
that specifies the Destack variable that changes this configuration value.

[1] 
https://review.openstack.org/#/c/295543/8/specs/categorized-configuration-options.rst

Victor Morales






On 4/8/16, 10:07 AM, "Sean M. Collins"  wrote:

>Prior to the introduction of local.conf, the only way to configure
>OpenStack components was to introduce code directly into DevStack, so
>that DevStack would pick it up then inject it into the configuration
>file.
>
>This was because DevStack writes out new configuration files on each
>run, so it wasn't possible for you to make changes to any configuration
>file (nova.conf, neutron.conf, ml2_plugin.ini, etc..).
>
>So, someone who wanted to set the Linux Bridge Agent's
>physical_interface_mappings setting for Neutron would have to use
>$LB_INTERFACE_MAPPINGS in DevStack, which would then be invoked by
>DevStack[1].
>
>The local.conf functionality was introduced quite a while back, and
>I think it's time to have a conversation about why we should start
>moving away from the previous practice of declaring variables in
>DevStack, and then having them injected into the configuration files.
>
>The biggest issue is: There is a disconnect between the developers
>using DevStack and someone who is an operator or who has been editing
>OpenStack conf files directly. So, for example I can tell you all about
>how DevStack has a bunch of variables for configuring Neutron (which is
>Not a Good Thing™), and how those go into DevStack and then end up coming
>out the other side in a Neutron configuration file.
>
>Really, I would like to get rid of the intermediate layer (DevStack)
>and get both Devs and Deployers to be able to just say: Here's my
>neutron.conf - let's diff mine and yours and see what we need to sync.
>
>Matt Kassawara and I have had this issue, since he's coming from the
>OSAD side, and I'm coming from the DevStack side. We both know what the
>Neutron configuration should end up as, but DevStack having its own set
>of variables and how those variables are handled and eventually rendered
>as a Neutron config file makes things more difficult than it needs to
>be, since Matt has to now go and learn about how DevStack handles all
>these Neutron specific variables.
>
>The Neutron refactor[2] that I am working on, I am trying to configure
>as little as possible in DevStack. Neutron should be able to, out of the
>box, Just Work™. If it can't, then that needs to be fixed in Neutron.
>
>Secondly, the Neutron refactor will be getting rid of all the things
>like $LB_INTERFACE_MAPPINGS - I would *much* prefer that someone using
>DevStack actually set the apropriate line in their local.conf
>
>Such as:
>
>[[post-config|/$Q_PLUGIN_CONF_FILE]]
>[linux_bridge]
>physical_interface_mappings = foo:bar
>
>
>The advantage of this is, when someone is working with DevStack, the
>things they are configuring are the same as all the other OpenStack 
>documentation.
>
>For example, someone could read the Networking Guide, read the example
>configuration[3] and the only thing they'd need to learn is our syntax
>for specifying what file the contents go in (the 
>"[[post-config|/$Q_PLUGIN_CONF_FILE]]" piece).
>
>Thoughts?
>
>[1]: 
>https://github.com/openstack-dev/devstack/blob/1195a5b7394fc5b7a1cb1415978e9997701f5af1/lib/neutron_plugins/linuxbridge_agent#L63
>
>[2]: https://review.openstack.org/168438
>
>[3]: 
>http://docs.openstack.org/liberty/networking-guide/scenario-classic-lb.html#example-configuration
>
>-- 
>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
__
OpenStack Development Mailing 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 naming legal issues

[Morales, Victor]

Jim, 

Did you verify with Marvel if it's possible to keep the name and use
his hero. In that way we could be the first OpenStack project to have
one.

Victor Morales

On Fri, 2016-04-01 at 08:46 +0300, Jimmy Akin wrote:
> Dear Neutrinos,
> 
> We've been following the project for quite some time.
> To our satisfaction the project seems to have done well; the base
> line of
> features that were available to the networking component of OpenStack
> (then nova-network) has grown quite a bit and seem to have gained a
> successful momentum with the communities, both development and
> operators.
> 
> However, Neutron appears to be a trademarked name [1], and 
> after thoroughly discussing the issue with our and Marvel' legal
> departments
> both sides have reached the conclusion that a naming scheme is an
> obligatory amendment and unfortunately is the only viable option.
> 
> An obvious resolution to this issue is reverting the old "Quantum"
> name back.
> However, this is subject to change and review from the PTL and as
> such, we'll shortly propose a relevant change to the review system.
> We anticipate the review process to be be swift, to avoid further
> legal implications.
> 
> Sincerely,
> Jimmy J. Akin,
> CIO,John F. Kennedy Space Center.
> 
> [1] https://en.wikipedia.org/wiki/Neutron_(Marvel_Comics)
> 
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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