[openstack-dev] [I18n] PTL Candidacy

[Kato, Tomoyuki]

Hello everyone,

I'd like to announce my candidacy for I18n PTL.

I'm one of the most active translators since July 2013
when I18n team is a just working group, not an official project.
Also, I'm one of Japanese coordinators.
Japanese translation team is the most active team in I18n team.
We sometimes share a few tips from our experience to I18n team.

I18n team have spent a very great time for a long time.
Especially, after we became an official project,
we have became more collaborative in cross-language activity,
such as building dashboard translation check site.
I appreciate the current I18n PTL Daisy.
She made our team become an official project.

In the Newton cycle, I'd like to

* support dashboard and its plug-ins tranlation into more languages,

* facilitate documentation tranlation into more languages,

* design and improve translation process, glossary management,
  translation bug triage process, and so on.

Also, I'd like to feedback our experience to the translation
system Zanata and cooperate with Zanata and Infra team to improve
our translation efficiency.

I think user facing contents translation is essential to improve
user experience to the people having various language background.
I believe I18n activity is necessary for OpenStack to become
more and more universal.

Best regards,
KATO Tomoyuki (katomo)

__
OpenStack Development Mailing 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] Error connecting to gerrit - issue with gerrit and launchpad username mismatch?

[Jeremy Stanley]

On 2016-03-13 19:51:14 -0500 (-0500), Lee Calcote wrote:
> Does anyone know if the fact that my usernames are different
> across these systems will cause an error when authenticating to
> gerrit?

It will not. Gerrit does not care (or even know) your Launchpad
username. The Gerrit WebUI identifies you with a unique OpenId URL
from your Launchpad account.

> I receive this error when running a git review from within an
> openstack repository I just cloned:
> 
> $ git review Could not connect to gerrit. Enter your gerrit
> username:
[...]

Unfortunately git-review's current mechanism for determining whether
your account is valid is by trying a test push for the repository
you're working in. Any condition which causes Gerrit to refuse the
push makes git-review think your username is incorrect.

> My gerrit username is "lecalcot". My launchpad username is "lcalcote”.
[...]

A quick look in the Gerrit backend database tells me you've not
filed contact information at
https://review.openstack.org/#/settings/contact which means you
probably also haven't agreed to the Individual Contributor License
Agreement (and the openstack-manuals repository to which you're
trying to contribute requires those). Please follow the
http://docs.openstack.org/infra/manual/developers.html#account-setup
instructions (including creating a Foundation Member account, making
sure you use the same primary E-mail address for that as your
preferred address in Gerrit, agreeing to the ICLA and filing contact
information), and then try your git-review again once that's done.
-- 
Jeremy Stanley

__
OpenStack Development Mailing 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] [Nova][Glance_store][VMware] Different glance store for Nova snapshot in VMware

[dongcan ye]

Hi all,

In our production environment, we enables glance_store for VMware datastore.
Configuration in glance-api.conf:

[DEFAULT]
show_image_direct_url = True
[glance_store]
stores= glance.store.vmware_datastore.Store
default_store = vsphere
vmware_server_host= 172.18.6.22
vmware_server_username = administrator@vsphere.local
vmware_server_password = 1qaz!QAZ
vmware_datastores = ICT Test:F7-HPP9500-SAS-ICTHPCLUSTER03-LUN06


Firstly we boot an instance, make online snapshot for the VM, we see the
image stores on local file system:
direct_url
file:///var/lib/glance/images/8cf7ba51-31d8-4282-89db-06957d609691

Then we poweroff the VM, make offline snapshot, the image stores on VMware
datastore:
direct_urlvsphere://
172.20.2.38/folder/openstack_glance/52825a70-f645-46b5-80ec-7a430dcd13cf?dcPath=IDC_Test=LUN03-00

In Nova VCDriver, make snapshot will upload VM disk file to Glance image
server. But why different behaviour for the VM poweron and poweroff?

Hopes for your reply.
__
OpenStack Development Mailing 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] Ironing out outstanding issues in time for RC1

[Armando M.]

On 13 March 2016 at 15:14, Ihar Hrachyshka  wrote:

> Armando M.  wrote:
>
> Neutrinos,
>>
>> We have about ~20 outstanding bugs marked Medium/High/Critical, and we
>> have only one or two days left to have a chance to get them in the gate
>> queue [1]. Can I trouble you to go and make sure patches are up to date and
>> well reviewed?
>>
>> Many thanks,
>> Armando
>>
>> [1] https://launchpad.net/neutron/+milestone/mitaka-rc1
>>
>
> Hi Armando and all,
>
> [Full disclosure: I am really interested in getting stable/mitaka cut off
> asap due to the code sprint starting on Mon where we would like to land a
> number of N bits to master.]
>
>
Do you have a list of patches that are currently blocked by the feature
freeze? I have this:


https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:ovo+label:Code-Review%253C%253D-2

I appreciate your concern, and we should do everything we can to enable you
guys to have a productive sprint. That said, it's unfortunate that the
sprint ended up being scheduled for this week, where attention should
really be devoted to Mitaka rather than Newton...but I guess you couldn't
predict the state of the codebase too far in advance.



> Currently I see 25 unreleased bugs targeted for RC1. I believe the list is
> too broad and does not represent actual team priorities as of right now; I
> suggest we go thru the list and postpone those bugs that either won’t land
> on Mon, or aren't really critical for the release; then cut-off
> stable/mitaka to unblock master.
>

Yes it is (you should have seen the list before I already had my first pass
;)). Bear in mind that most of these bugs ended up being automatically
rolled over to RC1 being targeted for earlier milestones (some of them are
as old as Liberty).


>
> If you think the list is fine, remember that at this point we should land
> only safe fixes, or those that make release impossible [aka ‘something base
> to the cloud operation is totally broken in Mitaka comparing to Liberty’].
> If you like, you can compare Neutron with its 25 targeted bugs to other
> projects (hint: nova - 2 bugs; glance - 2 bugs; cinder - 5 bugs; horizon -
> 12 bugs).


You should not trust the Launchpad view of other projects, because,
especially if you looked at Nova, this would mean that they fixed virtually
nothing in Mitaka, which is clearly not true. In other words, some projects
moved away from tracking issues using Launchpad. So rest assured that we're
not as lousy as we look.


> If we would start landing all cool stuff that we happen to produce in the
> last week, we would be undermining freeze and release process, also raising
> chances of releasing a pile of broken code.
>

Can you start telling me something I don't know? :)


>
> With that in mind, I went through the target to see what is really
> critical for the release.
>
> ===
>

Great, let's dig in!

Bear in mind that we can really consider RC1 bugs those for which we, as a
team, can clearly identify fixes that can safely land in the next day or
so. Any other, sadly, must be dropped no matter how bad it looks, due to
the time constraint we have.


>
> We have 18 bugs that are High+. Below is each of those bugs, with [*] mark
> where I think RC target is justified at this point.
>
> https://bugs.launchpad.net/neutron/+bug/1523031: linuxbridge + l2pop +
> l3ha broken.
> ^ while it’s unfortunate, I don’t see how it stands for a release critical
> bug since it affects setup that is not really that common. Also, looking at
> the bug state, I don’t see any work started on it. I would prefer we drop
> it out of RC1 target.
>

Agreed


>
> https://bugs.launchpad.net/bugs/1551288
> ^ fullstack (non-voting) job sometimes fails for native ovsdb interface.
> No idea why it’s critical for the release. Suggesting to postpone to N.


Agreed. The only comment I have to make here is: the sooner we make
fullstack voting the better. I wish we could have made that a Mitaka
priority so that we'd have an extra tool in our stability arsenal.


>
> https://bugs.launchpad.net/bugs/1513765 [*]
> ^ conntrack calls block ovs agent; patch in review optimizes for some use
> cases, but does not tackle the general issue of the agent being blocked;
> patch opens some rolling upgrade scenario concerns too since it touches RPC
> version and method signatures; that said, we indeed want to try to tackle
> it in RC;


> https://bugs.launchpad.net/neutron/+bug/1556139 [*]
> ^ create/delete race when returning new resource body in ml2; the patch is
> up for review and ready for merge; good to go;
>
> https://bugs.launchpad.net/neutron/+bug/1453350
> ^ port ready event sent to nova before dhcp is ready; not a regression:
> was always the case; the proper fix would require a lot of work; definitely
> won’t happen in Mitaka; I believe should be dropped from RC target;
>
> https://bugs.launchpad.net/neutron/+bug/1456073 [*]
> ^ dvr not ready yet when live 

Re: [openstack-dev] [telemetry] stepping down as PTL

[liusheng]

Thanks for your awsome work in last cycle Gordon!  I know you have pay a 
lot of efforts to make telemetry better, and I have learnt much from you.

--
Liu sheng

在 2016/3/12 1:33, Emilien Macchi 写道:



On Fri, Mar 11, 2016 at 11:32 AM, gordon chung > wrote:


hi folks,

as the PTL nominations are open, i just want to note that i won't be
running again as the Telemetry PTL for Newton cycle.

i've thoroughly enjoyed my time as PTL which afforded me the
opportunity
to work with and learn from some great individuals who share the same
passion to collaborate openly. i have the utmost confidence that the
projects will continue to grow and become more refined under the next
leadership.

personal thanks to everyone in Aodh, Ceilometer and Gnocchi
communities
as well as the projects that provided valuable feedback by
collaborating
with us. i thank you for sharing in the decision making so i could
spread the blame around. i also thank you for reading through terribly
written messages that make you question whether the shift keys on
all my
keyboards are broken.

cheers,


Thanks for all your work and great leadership, but also your help on 
helping other communities, like Puppet OpenStack to get puppet-aodh, 
puppet-gnocchi and puppet-ceilometer better.

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

[openstack-dev] [Docs] PTL Candidacy

[Lana Brindley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi everyone,

I am seeking re-election as Documentation PTL for Newton. I have now been the
docs PTL for two releases (Liberty and Mitaka), and would love another term in
the middle of the alphabet! We've achieved a lot this time around, including
an almost complete conversion to RST, quite a few structural overhauls of
popular books, and some fundamental toolchain improvements. There is still
lots to be done, though, and I would love your support to achieve this in
Newton.

During Liberty we got the bulk of our books migrated away from Docbook XML and
into RST. In Mitaka, we completed that work (with only the Ops Guide remaining
to be converted in Newton). For the last couple of releases, we've also had a
focus on improving the information architecture of our books, and have now
successfully completed overhauls of our most popular books, with the
Architecture Guide also well underway. All of these tasks will be carried over
to Newton, with many of them finally coming to completion. In Newton, I would
also like to address some of the larger issues around the organisation of our
documentation suite, making it easier for developers to contribute quality
code to our docs, and better welcoming and introducing new big tent projects
to the documentation team.

At the Mitaka summit in Tokyo, we decided to make a concerted effort to pay
down a lot of our tech debt, and one of the main ways we chose to do that was
to change the way we handled the DocImpact flag in our bugs. We merged those
changes to DocImpact about a month ago now, and it is already having a
significant impact on the amount of untriaged bugs outstanding. We're now much
more able to keep on top of our bug queue, which is giving us a much greater
ability to pay down tech debt. In this vein, we also have put a lot of effort
into ensuring new contributors have a better onboarding experience to docs,
with the creation of our new Contributor Guide which replaces a lot of old
wiki-based content, a great 'get started with docs' campaign at the last
Summit (which resulted in a hard copy article in the Summit edition of
SuperUser, and Anne and I on SuperUser TV), and a general willingness to
respond to questions on the mailing lists and help out new users wherever we
find them.

In the Liberty release cycle, we closed just over 600 bugs, and we're very
close to matching that number for Mitaka, with 505 bugs closed as I write
this. Again, we've managed to keep on top of the aging bugs as well, with all
bugs older than a year now closed. In the Mitaka release, we managed to close
16 blueprints, which is a massive increase over Liberty's 7.

I'm very excited about making the trek to Austin soon for the Newton summit,
to catch up with old friends, and hopefully meet some of our newest
contributors. Please be sure to stop for a chat if you see me around :)

I'd love to have your support for the PTL role for Newton, and I'm looking
forward to continuing to grow the documentation team.

Thanks,
Lana (@loquacities)

- -- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJW5g++AAoJELppzVb4+KUy9LAH/RC5y/gM22qywGZaE2y4hWEc
b+xdCxFUuh41l3WJhQ2iRJrnZUjm84doG2eCIcCpJW/OC5udo+2GiQYGmLUH278A
uz8Rfglsu/SmDhWZbaIWtiKXo3WedmWzXUbBCV7/+aftphKLMdckD1KAharZZOWq
Jqzg56SjWRqzbO++XiciCVwQ+zgoGuzJzYEQ1SsYsAdp/+wdtO2qPORZO1UuoOfz
wFFS/OG8O4PsJa3e9KW/kHzDY3Emkz7bhqDcbE6w3HyszC6bEq8lDgmcXtg2SoNn
FzjEpoiiAyalncUfo3p+v+7CV/3M/N4nCB2K+VhYO0hIAxPgUMxhrP3jzzq/gSI=
=sboQ
-END PGP 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] Error connecting to gerrit - issue with gerrit and launchpad username mismatch?

[Lee Calcote]

Does anyone know if the fact that my usernames are different across these 
systems will cause an error when authenticating to gerrit?

I receive this error when running a git review from within an openstack 
repository I just cloned:

$ git review Could not connect to gerrit. Enter your gerrit username: lecalcot 
Trying again with 
ssh://lecal...@review.openstack.org:29418/openstack/openstack-manuals.git 
 We don't know where your gerrit is. Please 
manually create a remote named "gerrit" and try again. Could not connect to 
gerrit at 
ssh://lecal...@review.openstack.org:29418/openstack/openstack-manuals.git 
Traceback (most recent call last): File "/usr/local/bin/git-review", line 11, 
in  sys.exit(main()) File 
"/Library/Python/2.7/site-packages/git_review/cmd.py", line 1534, in main 
sys.exit(e.EXIT_CODE) AttributeError: 'GitReviewException' object has no 
attribute 'EXIT_CODE'

I'm able to ssh -p 29418 lecal...@review.openstack.org gerrit version and 
receive the current version of gerrit back, so I have both network connectivity 
and a valid SSH key.

My gerrit username is "lecalcot". My launchpad username is "lcalcote”.

Thanks,
Lee

1] 
https://ask.openstack.org/en/question/89483/error-connecting-to-gerrit-issue-with-gerrit-and-launchpad-username-mismatch/__
OpenStack Development Mailing 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] [Horizon] How do we move forward with xstatic releases?

[Thomas Goirand]

On 03/12/2016 09:11 PM, Matthias Runge wrote:
> - how often have we been blocked by releases of software not managed by
> OpenStack? Seriously, that happens quite a few times over a release
> cycle, not to mention breakages by releases of our own tools turning out
> to block one or the other sub-project.

Let's remember the bad releases of setuptools :)

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing 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] [Horizon] How do we move forward with xstatic releases?

[Thomas Goirand]

On 03/10/2016 12:14 PM, Richard Jones wrote:
> On 10 March 2016 at 21:48, Beth Elwell  > wrote:
> 
>> On 10 Mar 2016, at 07:46, Richard Jones > > wrote:
>>
>> It has been mentioned, xstatic packages can block the gate. We
>> currently
>> control xstatic package releases, thus we can roll back, if
>> something
>> goes wrong.
>>
>> If we're pulling directly with npm/bower, someone from the
>> outside can
>> break us. We already have the situation with pypi packages.
>> With proper packages, we could even use the gate to release those
>> packages and thus verify, we're not breaking anyone.
>>
>>
>> We're going to have potential breakage (gate breakage, in the
>> integrated tests) any time we release a package (regardless of
>> release mechanism) and have to update two separate repositories
>> resulting in out-of-sync version specification
>> and expectation (ie. upper-constraints specification and Horizon's
>> code expectation) as described in my OP. The only solution that
>> we're aware of is to synchronise updating those two things,
>> through one of the mechanisms proposed so far (or possibly through
>> a mechanism not yet proposed.)
> If we will anyway have potential breakage I don’t understand why the
> better solution here would not be to just use the bower and npm
> tools which are standardised for JavaScript and would move Horizon
> more towards using widely recognised tooling from within not just
> Openstack but the wider development community. Back versions always
> need to be supported for a time, however I would add that long term
> this could end up saving time and create a stable longer term solution.
> 
> 
> I (and others) have argued several times for this, for a number of
> reasons, and it remains my preferred solution, but it has been shot down
> many times :-(

And I will attempt to do it once more unless someone brings the right
argumentation to the table.

> There are three major hurdles that I recall (sorry if I forgot any, it's
> getting late here):
> 
> 1. system packaging; installers using Debian or Red Hat (completely
> offline) installation will not be able to install Horizon. We don't have
> a solution for this though various caching mechanisms have been proposed.
> 2. security; the bower installation mechanism is seen as being very
> insecure - not that I would call the current xstatic mechanism secure.
> It's all down to degrees, I suppose.
> 3. installation in the gate; I believe that currently installation from
> bower would not be possible in the gate. This is pretty closely related
> to #1.
> 
> I think I recall licensing came up at one point too, but I might be
> mis-remembering.
> 
>   Richard

>From a distribution package maintainer perspective, the most annoying
part is that there's no easy way to get the web app use the JS libs from
the OS, and there's no system wide registry of installed components.
XStatic does that. Get $your-favoring-js-package-manager to do it, just
like php pear, perl CPAN, or Python pip does, then we will adopt it.
This, of course, requires work on upstream tooling.

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing 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] [Horizon] How do we move forward with xstatic releases?

[Thomas Goirand]

On 03/10/2016 11:48 AM, Beth Elwell wrote:
> 
>> On 10 Mar 2016, at 07:46, Richard Jones > > wrote:
>>  
>>
>> It has been mentioned, xstatic packages can block the gate. We
>> currently
>> control xstatic package releases, thus we can roll back, if something
>> goes wrong.
>>
>> If we're pulling directly with npm/bower, someone from the outside can
>> break us. We already have the situation with pypi packages.
>> With proper packages, we could even use the gate to release those
>> packages and thus verify, we're not breaking anyone.
>>
>>
>> We're going to have potential breakage (gate breakage, in the
>> integrated tests) any time we release a package (regardless of release
>> mechanism) and have to update two separate repositories resulting in
>> out-of-sync version specification and expectation (ie.
>> upper-constraints specification and Horizon's code expectation) as
>> described in my OP. The only solution that we're aware of is to
>> synchronise updating those two things, through one of the mechanisms
>> proposed so far (or possibly through a mechanism not yet proposed.)
> 
> If we will anyway have potential breakage I don’t understand why the
> better solution here would not be to just use the bower and npm tools

We control the breakages, and we're trying to find a solution (if you
didn't notice, many where proposed in this thread).

> which are standardised for JavaScript

They are a *very bad* standard which doesn't work at all with downstream
distributions. Unless someone adds a system wide registry for javascript
(the say way that if you apt-get a Python package, pip wont download
it), then we can't use it.

> and would move Horizon more
> towards using widely recognised tooling

Recognized by who? Certainly not downstream distributions. This is a
nightmare.

> from within not just Openstack
> but the wider development community.

What community are you talking about? That JavaScript community which
breaks APIs every 2 weeks? Please re-read this:

https://github.com/openstack/horizon/blob/master/doc/source/topics/packaging.rst

and especially the part:
"Why we use XStatic"

We have every few months some Horizon contributors advocating for
pushing toward this direction, however, none have yet shown a way to
solve what Xstatic does. Until this is done, please refrain from writing:

"hey, everyone uses X, so let's do the same"

without valid technical argumentation.

Yes, using npm / bower / gulp / you-name-it, may make your Horizon
contributor life easier. But that's *not* the only thing to consider.

> Back versions always need to be
> supported for a time, however I would add that long term this could end
> up saving time and create a stable longer term solution.

Long term, I would like to see more contributions to the upstream
JavaScript tooling to make it behave reasonably. Until this is done, we
can't use it.

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing 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] [Horizon] How do we move forward with xstatic releases?

[Thomas Goirand]

On 03/09/2016 04:53 PM, Monty Taylor wrote:
> On 03/07/2016 10:52 PM, Richard Jones wrote:
>> We've solved *most* of the issues around releasing new xstatic packages,
>> documented here[1] (and related documentation).
>>
>> We have one final issue that's blocking us, which is that during the
>> xstatic release there will be a point at which Horizon may be broken
>> from an integrated point of view - some of the interfaces may not work
>> and fail tests. The process goes something like this:
>>
>> ​Note: this assumes that depends-on can reliably bring in patches from
>> all over the place into a gate environment, which is technically
>> possible, but not necessarily correct today.
>>
>> The problem is that because we can't atomically update both
>> upper-constraints *and* Horizon at the same time (or upper-constraints
>> *and* xstatic-angular, or Horizon *and* xstatic-angular) we run into a
>> situation where Horizon will be running against the wrong version of
>> xstatic-angular.
>>
>> So we break one of the basic assumptions of the OpenStack world: that
>> every single commit in every repository for the integrated environment
>> will pass tests.
>>
>> In the Python world, we code around this by making Horizon compatible
>> with both the X and X1 versions of xstatic-angular (if it was a Python
>> library). In Javascript land this is much more difficult - Javascript
>> libraries tend to break compatibility in far more interesting ways.
> 
> Yah. Honestly, this is one of the main places where I think we get into
> trouble in linux-distro land in trying to apply the tools/techniques
> developed for one set of problems with another.
> 
>> Maintaining compatibility across CSS and font releases is also a
>> difficult problem, though changes here are unlikely to break Horizon
>> enough that gate tests would fail. So, solution 1 to the problem is:
>>
>> SOLUTION 1: always maintain Horizon compatibility across xstatic library
>> releases.
>>
>> This is potentially very difficult to guarantee. So, a second solution
>> has been proposed:
>>
>> SOLUTION 2: move the upper-constraints information for *the xstatic
>> libraries only* from the global upper-constraints file into Horizon's
>> repository.
>>
>> This allows us to atomically update both Horizon and the xstatic library
>> version, removing the potential to break because of the version
>> mismatch. Unfortunately it means that we have version compatibility
>> issues with anything else that wants to install alongside Horizon that
>> also uses xstatic packages. For example, Horizon plugins. We could move
>> Horizon plugins into the Horizon repository to solve this. /ducks
> 
> I actually like this one a lot. I know that there is a plugin problem
> ... but ... plugin installers could also consume the horizon xstatic
> constraints when installing xstatic packages?
> 
> xstatic packages are specifically workarounds for doing javascript in a
> python-centric world. Putting then in upper-constraints and actually
> treating them like actual python packages rather than what they are
> which is a clever utilization of the python ecosystem to deliver
> javascript libraries is vexing at best.
> 
> 
>> A variation on this solution is:
>>
>> SOLUTION 3: allow Horizon to locally override upper-constraints for the
>> time needed to merge a patch in devstack.
>>
>> This solution allows Horizon to atomically update itself and the xstatic
>> library, but it also means installing Horizon in a CI/CD environment
>> becomes more difficult due to the need to always pull down the
>> upper-constraints file and edit it. We could code this in to tox, but
>> that doesn't help eg. devstack which needs to also do this thing.
> 
> Or people who are deploying horizon CD from master from source and
> applying upper-constraints to get the tested version. Those people would
> have to duplicate the tox logic.
> 
>> SOLUTION 4: vendor the javascript
>>
>> Heh.
> 
> Heh indeed.
> 
> SOLUTION 4.alt: use npm/bower instead of xstatic to pull the javascript.

Veto. See "Why we use XStatic" at:
https://github.com/openstack/horizon/blob/master/doc/source/topics/packaging.rst

Thomas


__
OpenStack Development Mailing 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] [Horizon] How do we move forward with xstatic releases?

[Thomas Goirand]

On 03/08/2016 05:52 AM, Richard Jones wrote:
> In the Python world, we code around this by making Horizon compatible
> with both the X and X1 versions of xstatic-angular (if it was a Python
> library). In Javascript land this is much more difficult - Javascript
> libraries tend to break compatibility in far more interesting ways.
> Maintaining compatibility across CSS and font releases is also a
> difficult problem, though changes here are unlikely to break Horizon
> enough that gate tests would fail. So, solution 1 to the problem is:
> 
> SOLUTION 1: always maintain Horizon compatibility across xstatic library
> releases.
> 
> This is potentially very difficult to guarantee. So, a second solution
> has been proposed:
> 
> SOLUTION 2: move the upper-constraints information for *the xstatic
> libraries only* from the global upper-constraints file into Horizon's
> repository.
> 
> This allows us to atomically update both Horizon and the xstatic library
> version, removing the potential to break because of the version
> mismatch. Unfortunately it means that we have version compatibility
> issues with anything else that wants to install alongside Horizon that
> also uses xstatic packages. For example, Horizon plugins. We could move
> Horizon plugins into the Horizon repository to solve this. /ducks
> 
> A variation on this solution is:
> 
> SOLUTION 3: allow Horizon to locally override upper-constraints for the
> time needed to merge a patch in devstack.
> 
> This solution allows Horizon to atomically update itself and the xstatic
> library, but it also means installing Horizon in a CI/CD environment
> becomes more difficult due to the need to always pull down the
> upper-constraints file and edit it. We could code this in to tox, but
> that doesn't help eg. devstack which needs to also do this thing.
> 
> SOLUTION 4: vendor the javascript
> 
> Heh.
> 
> SOLUTION 5: have dependencies on xstatic move from global requirements
> to Horizon
> 
> This is similar to 2 & 3 with some of the same drawbacks (multiple users
> of xstatic) but also we'd need a change to global-requirements handling
> to ignore some entries in Horizon's requirements.
> 
> Your thoughts on any and all of the above are requested.

SOLUTION 6: educate upstream and make them stop breaking the world.

SOLUTION 7: Stop having dependencies on libraries that constantly break
the world.

SOLUTION 8: Stop using JavaScript.

SOLUTION 9: Rewrite Horizon as QT client! :)

Cheers,

Thomas Goirand (zigo)

P.S: While all of this is just for fun, I seriously believe that
upstream JavaScript people should be educated to not break things every
2 weeks... though I don't think it will happen anytime soon.


__
OpenStack Development Mailing 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] Is keystone support combined authentication in release L?

[Lance Bragstad]

Keystone introduced TOTP authentication this release [0]. Like Adam said,
in Newton we will build multi-factor authentication on top of TOTP and
existing plugins.


[0]
http://specs.openstack.org/openstack/keystone-specs/specs/mitaka/totp-auth.html

On Sun, Mar 13, 2016 at 4:05 PM, Adam Young  wrote:

> On 03/12/2016 11:37 PM, 赵智龙 wrote:
>
> hi guys.
> i just want to ask a small question.
> Is keystone support combined authentication in release L?
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> I think you are asking for Multifactor Auth.  That got bumped to Newton.
>
> __
> OpenStack Development Mailing 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] Ironing out outstanding issues in time for RC1

[Ihar Hrachyshka]

Armando M.  wrote:


Neutrinos,

We have about ~20 outstanding bugs marked Medium/High/Critical, and we  
have only one or two days left to have a chance to get them in the gate  
queue [1]. Can I trouble you to go and make sure patches are up to date  
and well reviewed?


Many thanks,
Armando

[1] https://launchpad.net/neutron/+milestone/mitaka-rc1


Hi Armando and all,

[Full disclosure: I am really interested in getting stable/mitaka cut off  
asap due to the code sprint starting on Mon where we would like to land a  
number of N bits to master.]


Currently I see 25 unreleased bugs targeted for RC1. I believe the list is  
too broad and does not represent actual team priorities as of right now; I  
suggest we go thru the list and postpone those bugs that either won’t land  
on Mon, or aren't really critical for the release; then cut-off  
stable/mitaka to unblock master.


If you think the list is fine, remember that at this point we should land  
only safe fixes, or those that make release impossible [aka ‘something base  
to the cloud operation is totally broken in Mitaka comparing to Liberty’].  
If you like, you can compare Neutron with its 25 targeted bugs to other  
projects (hint: nova - 2 bugs; glance - 2 bugs; cinder - 5 bugs; horizon -  
12 bugs). If we would start landing all cool stuff that we happen to  
produce in the last week, we would be undermining freeze and release  
process, also raising chances of releasing a pile of broken code.


With that in mind, I went through the target to see what is really critical  
for the release.


===

We have 18 bugs that are High+. Below is each of those bugs, with [*] mark  
where I think RC target is justified at this point.


https://bugs.launchpad.net/neutron/+bug/1523031: linuxbridge + l2pop + l3ha  
broken.
^ while it’s unfortunate, I don’t see how it stands for a release critical  
bug since it affects setup that is not really that common. Also, looking at  
the bug state, I don’t see any work started on it. I would prefer we drop  
it out of RC1 target.


https://bugs.launchpad.net/bugs/1551288
^ fullstack (non-voting) job sometimes fails for native ovsdb interface. No  
idea why it’s critical for the release. Suggesting to postpone to N.


https://bugs.launchpad.net/bugs/1513765 [*]
^ conntrack calls block ovs agent; patch in review optimizes for some use  
cases, but does not tackle the general issue of the agent being blocked;  
patch opens some rolling upgrade scenario concerns too since it touches RPC  
version and method signatures; that said, we indeed want to try to tackle  
it in RC;


https://bugs.launchpad.net/neutron/+bug/1556139 [*]
^ create/delete race when returning new resource body in ml2; the patch is  
up for review and ready for merge; good to go;


https://bugs.launchpad.net/neutron/+bug/1453350
^ port ready event sent to nova before dhcp is ready; not a regression: was  
always the case; the proper fix would require a lot of work; definitely  
won’t happen in Mitaka; I believe should be dropped from RC target;


https://bugs.launchpad.net/neutron/+bug/1456073 [*]
^ dvr not ready yet when live migration triggered; targeted for RC on both  
nova and neutron sides; neutron patch in review, has needed +2s; good to go;


https://bugs.launchpad.net/neutron/+bug/1462154
^ dvr returns fip targeted pings with fixed ips; patch up for review [WIP];  
not sure whether it will make it; I suggest we don’t wait for that one;


https://bugs.launchpad.net/bugs/1478100
^ physical network aware dhcp scheduler; honestly, that one is rather  
feature-ish; I would untarget it from Mitaka on that ground;


https://bugs.launchpad.net/bugs/1491131
^ ipset race; this one seems abandoned right now; no patches for review;  
long standing issue; I would move it to N;


https://bugs.launchpad.net/neutron/+bug/1498790
^ allow to delete other’s ports from your network; while obviously a bug,  
the fix could be also considered rather feature-ish, since it change API  
behaviour; there seems to be no active patches in gerrit for that; I would  
postpone it till N when we’ll have more time to look into the proper fix;


https://bugs.launchpad.net/bugs/1501206 [*]
^ dhcp ports reply to requests from other subnets; potential security hole;  
patch up for review; could indeed be worth looking at for RC;


https://bugs.launchpad.net/bugs/1514056 [*]
^ vlan external connectivity disrupted on ovs agent restart; patch up for  
review [tiny one, need respin]; not a regression; would be fine to see it  
fixed in RC but not a tragedy if it’s skipped;


https://bugs.launchpad.net/neutron/+bug/1528895
^ bulk rpc calls time out for l2 agent with default rpc timeout; honestly,  
I don’t believe it’s valid to have it High (there is a tunable for the  
timeout provided by oslo.messaging library); no proper fix up for review; I  
would say, we should postpone to N;


https://bugs.launchpad.net/bugs/1533034
^ exception error fix; breaks i18n freeze; 

Re: [openstack-dev] [puppet] PTL candidacy

[Adam Young]

On 03/13/2016 05:44 PM, Emilien Macchi wrote:

This is my candidacy for PTL role in the Puppet OpenStack team
for the Newton release cycle.

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

Puppet OpenStack is a great example of project where collaboration works
between developers and operators. Expect me to continue being a liaison
between different groups so our community can successfully build
production-ready OpenStack Clouds deployed with our modules.
I'll continue to facilitate our team work, to coordinate cross-project 
tasks,

to mentor our contributors who want to learn more and also
the most important for me: keep being open.

I had the tremendous pleasure [1] to lead our team during the last 
cycle and

I would like to continue my role of PTL during Newton.
Thank you for your consideration,

[1] http://my1.fr/blog/puppet-openstack-mitaka-success
--
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

Make sure you also submit to the git repo:

https://github.com/openstack/election
__
OpenStack Development Mailing 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] [glance] Glance Mitaka: Passing the torch

[Fei Long Wang]

You've been fantastic.  Thanks for all you have done, Fla.


On 10/03/16 03:15, Flavio Percoco wrote:


Greetings,

I'm not going to run for Glance's PTL position for the Newton timeframe.

There are many motivations behind this choice. Some of them I'm 
willing to
discuss in private if people are interested but I'll go as far as 
saying there

are personal and professional reasons for me to not run again.

As I've always done in my past cycles as PTL, I'd like to take some 
time to
summarize what's happened in the past cycle not only for the new PTL 
to know

what's coming up but for the community to know how things went.

Before I even start, I'd like to thank everyone in the Glance 
community. I truly
believe this was a great cycle for the project and the community has 
gotten
stronger. None of this would have been possible without the help of 
all of you
and for that, I'm deeply in debt with you all. It does not just take 
an employer
to get someone to contribute to a project. Being paid, for those who 
are, to do
Open Source is not enough. It takes passion, motivation and a lot of 
patience to
analyze a technology, think out of the box and look for ways it can be 
improved
either by fixing bugs or by implementing new features. The amount of 
time and
dedication this process requires is probably worth way more than what 
we get

back from it.

Now, with all that being said, here's Glance Mitaka for all of you:

Completed Features
==

I think I've mentioned this already but I'm proud of it so I'll say it 
again.
The prioritization and scheduling of Glance Mitaka went so well that 
we managed
to release M-3 without any feature freeze exception (FFE) request. 
This doesn't
mean all the features were implemented. In fact, at least 4 were 
pushed back to
Newton. However, the team communicated, reviewed, sprinted and coded 
in such a
way that we were able to re-organize the schedule to avoid wasting 
time on
things we new weren't going to make it. This required transparency and 
hard

decisions but that's part of the job, right?

* [0] CIM Namespace Metadata
* [1] Support download from and upload to Cinder volumes
* [2] Glance db purge utility
* [3] Deprecate Glance v3 API
* [4] Implement trusts for Glance
* [5] Migrate the HTTP Store to Use Requests
* [6] Glance Image Signing and Verification
* [7] Supporting OVF Single Disk Image Upload
* [8] Prevention of Unauthorized errors during upload/download in 
Swift driver

* [9] Add filters using an ‘in’ operator

[0] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cim-namespace-metadata-definitions.html
[1] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cinder-store-upload-download.html
[2] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/database-purge.html
[3] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/deprecate-v3-api.html
[4] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/glance-trusts.html
[5] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/http-store-on-requests.html
[6] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/image-signing-and-verification-support.html
[7] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/ovf-lite.html
[8] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/prevention-of-401-in-swift-driver.html
[9] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/v2-add-filters-with-in-operator.html


If the above doesn't sound impressive to you, let me fill you in with 
some extra

info about Glance's community.

Community
=

Glance's community currently has 12 core members, 3 of which joined 
during
Mitaka and 2 of those 3 members joined at the end of the cycle. That 
means the
team ran on 9 reviewers for most of the cycle except that out of those 
9, 1 left
the team and joined later in the cycle and 3 folks weren't super 
active this

cycle. That left the team with 5 constant reviewers throughout the cycle.

Now, the above is *NOT* to say that the success of the cycle is thanks 
to those
5 constant reviewers. On the contrary, it's to say that we've managed 
to build a
community capable of working together with other non-core reviewers. 
This was a

key thing for this cycle.

I don't think it's a secret to anyone that, at the beginning of the 
cycle, the
community was fragile and somewhat split. There were different 
opinions on what
Glance should (or shouldn't) look like, what new features Glance 
should (or
shouldn't) have and where the project should be headed in the next 6 
months.


The team sat down, the team talked and the team agreed on what the 
project
should be and that's what the team did in the Mitaka cycle. Sharing 
one message

with the rest of the OpenStack community (and especially new Glance
contributors) was a key for the 

[openstack-dev] [puppet] PTL candidacy

[Emilien Macchi]

This is my candidacy for PTL role in the Puppet OpenStack team
for the Newton release cycle.

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

Puppet OpenStack is a great example of project where collaboration works
between developers and operators. Expect me to continue being a liaison
between different groups so our community can successfully build
production-ready OpenStack Clouds deployed with our modules.
I'll continue to facilitate our team work, to coordinate cross-project
tasks,
to mentor our contributors who want to learn more and also
the most important for me: keep being open.

I had the tremendous pleasure [1] to lead our team during the last cycle and
I would like to continue my role of PTL during Newton.
Thank you for your consideration,

[1] http://my1.fr/blog/puppet-openstack-mitaka-success
-- 
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

Re: [openstack-dev] Is keystone support combined authentication in release L?

[Adam Young]

On 03/12/2016 11:37 PM, 赵智龙 wrote:

hi guys.
i just want to ask a small question.
Is keystone support combined authentication in release L?


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

I think you are asking for Multifactor Auth.  That got bumped to Newton.
__
OpenStack Development Mailing 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

[Yaroslav Lobankov]

Thanks, Matt, for your great work for 2 years! These years have been very
productive for the QA program. It has been a pleasure working under your
leadership! :)

Regards,
Yaroslav Lobankov.

On Sun, Mar 13, 2016 at 8:51 AM, Masayuki Igawa 
wrote:

> From: Matthew Treinish 
> Subject: [openstack-dev] [QA] Not running for PTL
> Date: Fri, 11 Mar 2016 14:34:10 -0500
>
> > 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)
>
> Thank you very very very much for your really great work! And I hope you
> still
> continue to deeply involved with the QA program for the better OpenStack
> quality,
> too :)
>
> Best Regards,
> -- Masayuki Igawa(IRC: masayukig)
>
> __
> OpenStack Development Mailing 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] [Kuryr] PTL Candidacy for Gal Sagie

[Gal Sagie]

I would like to propose my candidacy for Kuryr PTL position.

Kuryr has only recently joined OpenStack big-tent and i would like to
receive the official trust of the community and continue serving as the
PTL for a full release cycle.

I think that Kuryr serve an important role in current OpenStack eco-system
and solve new problems that many users are facing starting to deploy
containers environments mixed with OpenStack.

Kuryr is a relatively new project but i am proud to say that we already have
a very diverse community and feel that we operate openly and advancing in
the
right direction.
I would like us to keep doing that and advance even faster in the next
cycle, I
have and will continue to devote time to bring more new contributors and
users
into Kuryr.

Kuryr is at first a team effort, me and Toni (apuimedo) from Midokura are
doing
this together all the way from the start and hopefully continue so in the
future.
I would also like to thank all the great people and contributors helping and
working together with us on Kuryr, you guys are doing great job!

My goals for Kuryr to the next release are:

* Stability, Test coverage and benchmarking - This is important for every
  project but especially for Kuryr that is facing and working with models
and
  frameworks that are experimental and changing quite often.
  As more users considering deploying Kuryr, our quality assurance become
more
  and more critical but also our advantage over existing solutions.

* Kubernetes Integration - This effort has already started and we already
have
  what seems to be a good design and a POC implementation of this, i would
like
  us to keep that great work from Antoni Segura Puimedon, Irena Berezovsky,
  Taku Fukushima and Jaume Devesa.
  We also need to start looking at providing extra enhancement and policy
to the
  deployments, working together with the Kubernetes and Neutron communities
to
  accomplish this.

* Magnum and Nested containers - We have a great spec and proposal for this
  done by Fawad Khaliq and i hope to soon be able to bring more interested
resources
  to work on this with him and hopefully myself as well.
  To me, the goal is for Kuryr to be the default Magnum networking driver
and
  this is one big step in this direction which we do openly with the Magnum
team.

* Operators / users - I would like for us to be more involved and
responsive for
  users needs and requirements, Mike Spreitzer from IBM is helping us drive
this effort.
  I am working on providing more reference architecture of such mixed
environments
  which will help us prioritize and find the best use cases to focus on.
  I am also working internally in Huawei trying to bring these operational
requirements.

  I think packaging and Kolla integration are major part of this effort and
makes the
  process of deploying Kuryr simple and easy, we need to continue all the
good work that
  was done on this front and add support for more and more existing Neutron
plugins

* Containers storage - My plan is to expand Kuryr mission statement to also
bridge between
  containers orchestration engines and models and the various storage and
backup projects
  in OpenStack to provide simplified management and extra added value
features for
  containers deployment.
  I hope that we will start these discussions, designs and work during the
next
  release and do it hand in hand with all of these projects.

* Added value features - Like being able to attach to existing
networks/ports,
  a very use full feature for production use cases that i hear is needed
quite a lot and is being
  implemented by Mohammad Banikazemi.
  We need to identify any other feature that simplify and improve
containers networking
  and work to provide it.

* Increase visibility - Put focus on providing more documentation, blog
posts and arrange
  meetups and talks for all of us to spread the word about Kuryr.
  I feel that operational documentation is very important for our first
users.

* New contributors - I personally hope that more companies (like RedHat and
Mirantis) will
  join our effort and share their vision with us in order to provide a
better solution
  to the community.
  I am also working on more active involvement from Huawei and hopefully
from other
  companies just as well.

Thanks and feel free to email me with any question,

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

[Masayuki Igawa]

From: Matthew Treinish 
Subject: [openstack-dev] [QA] Not running for PTL
Date: Fri, 11 Mar 2016 14:34:10 -0500

> 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)

Thank you very very very much for your really great work! And I hope you still
continue to deeply involved with the QA program for the better OpenStack 
quality,
too :)

Best Regards,
-- Masayuki Igawa(IRC: masayukig)

__
OpenStack Development Mailing 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][Dragonflow] IRC Meeting tomorrow (3/14) - 0900 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting tomorrow (Monday, 3/14) at 0900 UTC
in #openstack-meeting-4

I personally will not be able to attend, Eran Gampel will chair it instead.

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/dragonflow/2016/dragonflow.2016-03-07-09.00.html

Please update the agenda if you have any subject you would like to discuss
about.
__
OpenStack Development Mailing 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] IRC Meeting tomorrow (3/14) - 1500 UTC

[Gal Sagie]

Hello All

We will have an IRC meeting tomorrow (3/14) at 1500UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Kuryr

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-03-08-03.01.html

Please update the agenda if you have any subject you would like to discuss
about.
__
OpenStack Development Mailing 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] [Openstack-stable-maint][stable/liberty][trove] stable/liberty changes in Trove that are ready for merge

[Amrith Kumar]

Hi,

Sorry for the blast mail, this is targeted at the stable-maint team. The 
following five changes are now ready to merge. Two of them are changes proposed 
by the bot and three of them are clearly identified as cherry-picks from 
changes that went into master.

236209

Updated from global requirements

262287

Add instance create int-tests

262289

Add MySQL int-test helper client

262291

Catch all errors in Mock detector

228965

Updated from global requirements


Thanks,

-amrith


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