[openstack-dev] [tricircle][trio2o] trio2o git repo ready and tricircle splitting

[joehuang]

hello, team,

Trio2o git repository is ready now: https://github.com/openstack/trio2o

The repository inherited all files and commit messages from Tricircle.

It's now the time start to do the tricircle splitting: a blue print is 
registere for Tricircle cleaning: 
https://blueprints.launchpad.net/tricircle/+spec/make-tricircle-dedicated-for-networking-automation-across-neutron.There
 are lots of documentation work to do. Please review these doc in the BP, 
thanks.

There are some proposal for patches during the splitting:

1. For patch which is already in review status, let's review it in Tricircle 
(no matter it's for Trio2o or Tricircle), after it's get merged, then port it 
to Trio2o. After all patches get merged, let's have a last tag for Tricircle to 
cover both gateway and networking automation function. Then the cleaning will 
be done in Tricircle to make Tricircle as a project for networking automation 
only
2. For new patch which is only applicable to Trio2o, I propose that we submit 
such patches in Trio2o only, no need to submit in Tricircle.

Would like to know your thoughts on the splitting.

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

Re: [openstack-dev] [tricircle][trio2o] trio2o git repo ready and tricircle splitting

[Vega Cai]

+1 for the proposal. What about the codes for Pod operation? It seems that
both Tricircle and Trio2o need these codes. We submit patches to these two
projects separately?

Zhiyuan

joehuang 于2016年9月18日周日 下午4:17写道：

> hello, team,
>
> Trio2o git repository is ready now: https://github.com/openstack/trio2o
>
> The repository inherited all files and commit messages from Tricircle.
>
> It's now the time start to do the tricircle splitting: a blue print is
> registere for Tricircle cleaning:
> https://blueprints.launchpad.net/tricircle/+spec/make-tricircle-dedicated-for-networking-automation-across-neutron
> .There are lots of documentation work to do. Please review these doc in
> the BP, thanks.
>
> There are some proposal for patches during the splitting:
>
> 1. For patch which is already in review status, let's review it in
> Tricircle (no matter it's for Trio2o or Tricircle), after it's get merged,
> then port it to Trio2o. After all patches get merged, let's have a last tag
> for Tricircle to cover both gateway and networking automation function.
> Then the cleaning will be done in Tricircle to make Tricircle as a project
> for networking automation only
> 2. For new patch which is only applicable to Trio2o, I propose that we
> submit such patches in Trio2o only, no need to submit in Tricircle.
>
> Would like to know your thoughts on the splitting.
>
> 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
>
__
OpenStack Development Mailing 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][trio2o] trio2o git repo ready and tricircle splitting

[joehuang]

Thank you for your comment, Zhiyuan.

For pod management, because these two projects need to run independently, I 
think submit patches separately as needed may be a better choice.

Best Regards
Chaoyi Huang(joehuang)

From: Vega Cai [luckyveg...@gmail.com]
Sent: 18 September 2016 16:27
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle][trio2o] trio2o git repo ready and 
tricircle splitting

+1 for the proposal. What about the codes for Pod operation? It seems that both 
Tricircle and Trio2o need these codes. We submit patches to these two projects 
separately?

Zhiyuan

joehuang mailto:joehu...@huawei.com>>于2016年9月18日周日 
下午4:17写道：
hello, team,

Trio2o git repository is ready now: https://github.com/openstack/trio2o

The repository inherited all files and commit messages from Tricircle.

It's now the time start to do the tricircle splitting: a blue print is 
registere for Tricircle cleaning: 
https://blueprints.launchpad.net/tricircle/+spec/make-tricircle-dedicated-for-networking-automation-across-neutron.There
 are lots of documentation work to do. Please review these doc in the BP, 
thanks.

There are some proposal for patches during the splitting:

1. For patch which is already in review status, let's review it in Tricircle 
(no matter it's for Trio2o or Tricircle), after it's get merged, then port it 
to Trio2o. After all patches get merged, let's have a last tag for Tricircle to 
cover both gateway and networking automation function. Then the cleaning will 
be done in Tricircle to make Tricircle as a project for networking automation 
only
2. For new patch which is only applicable to Trio2o, I propose that we submit 
such patches in Trio2o only, no need to submit in Tricircle.

Would like to know your thoughts on the splitting.

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
__
OpenStack Development Mailing 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] Should we discuss the use cases of force volume detach in the Tricircle

[cr_...@126.com]

Hello，
When the patch "force volume detach" has submited , some proposals have came 
back.
The important point is wheathe this function is needed or safe.
Should we disscuss some uses cases of this function. Such as the define of this 
function, when this function been triggered.



Best regards,
Ronghui Cao, Ph.D. Candidate
College of Information Science and Engineering
Hunan University, Changsha 410082, Hunan, China
__
OpenStack Development Mailing 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] [fuel][plugin] Is there a way to change plugin html dynamically?

[Wang, Peter (Xu)]

Hi Fuel dev,

I am studying the development of fuel plugin and usage of some existing plugins.

I wondered is there a way to change the Plugin layout in settings page 
dynamically:

Take netapp's plugin as the example:
https://github.com/openstack/fuel-plugin-cinder-netapp/blob/master/figures/cinder-netapp-7mode-iscsi-plugin.png
Looks like admin can only add one netapp backend for one OpenStack cluster from 
the GUI, but what if user own 2 netapp devices to be managed?


*From GUI side:
How can I do that as a plugin developer? Any reference guides on the layout 
yaml files are welcome  (environment_config.yaml)

*From puppet module side:
Any reference implementation for how to enable multiple cinder backends in 
multi-backend enabled environment in one time?

Thanks
Peter

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

[joehuang]

Hello,

This is Chaoyi Huang(nick: joehuang), I would like to nominate myself as 
Tricircle PTL in Ocata release.

Before look forward to what to do in Ocata release, I want to have a short look 
back what's Tricircle has done in Newton release. The objectives and our 
progress in Newton release are:
* Cross OpenStack L2 networking: "local network" and "shared vlan" supported in 
Tricircle for L2/L3 networking functionalities, this is a great fundamental for 
our Newton release.
* Dynamic pod binding: the framework is in review.
* Tempest and basic VM/Volume operation: tempest based check and gate test has 
been integrated into the process, support basic features tempest
* Keep Tricircle follow OpenStack open source development guideline to make 
Tricircle project as open as any other OpenStack project, so that more and
more talents would like to join and contribute in Tricircle, and target at 
being a big tent project of OpenStack, being member of OpenStack eco-system and 
help the eco-system to address the problem domain in multi-OpenStack cloud, no 
matter it's in one site or multi-site: now Tricircle is applying big-tent 
application, and the splitting is ongoing, and glad to see more and more 
contributors join Tricricle community.

This is great progress for Tricricle based on every contributor's great effort.

As the Tricircle will be splitted and dedicate for cross Neutron networking 
automation, my vision for Tricircle Ocata will based on our basis in Newton 
release and what we discussed in these weeks:

* Ensure the Tricircle splitting smoothly with quality.
* Continue cross OpenStack L2/L3 networking, and work with upstream projects 
like Neutron, L2GW
* Being better citizen in OpenStack, continue the big-tent application, and 
collaboration with other projects
* enhance the installation method and make it easier to play Tricircle, so that 
more contributors would like to join Tricircle.
* Start advance networking service support in Ocata for Tricircle if possible

Since the Tricircle project tries to address very fundamental cross Neutron 
networking automation chanllenges, it's exciting to work and contribute in such 
a project, let's enjoy the journey.

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

Re: [openstack-dev] [tricircle] Should we discuss the use cases of force volume detach in the Tricircle

[joehuang]

This is a good question. I also sent a mail in cinder thread that wants to know 
why the tempest test cases missing for the "force volume detach".
The spec for the "force volume detach" could be found here: 
https://github.com/openstack/cinder-specs/blob/master/specs/liberty/implement-force-detach-for-safe-cleanup.rst

From: cr_...@126.com [cr_...@126.com]
Sent: 18 September 2016 16:53
To: openstack-dev
Subject: [openstack-dev] [tricircle] Should we discuss the use cases of force 
volume detach in the Tricircle

Hello，
When the patch "force volume detach" has submited , some proposals have came 
back.
The important point is wheathe this function is needed or safe.
Should we disscuss some uses cases of this function. Such as the define of this 
function, when this function been triggered.



Best regards,
Ronghui Cao, Ph.D. Candidate
College of Information Science and Engineering
Hunan University, Changsha 410082, Hunan, China
__
OpenStack Development Mailing 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] PTL Candidacy

[Gary Kotton]

Hi,
I saw that Armando has put himself up for reelection. I would like to endorse 
him and vote a big +1 for him doing the job in the next cycle. One of the hard 
things about working in this environment is that it is very hard to get any 
feedback. I think that over the last cycle you have grown and have done a very 
good job.
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] [tricircle]PTL candidacy

[Shinobu Kinjo]

No objection.
I really appreciate your great leadership.

Cheers,
Shinobu

On Sun, Sep 18, 2016 at 6:26 PM, joehuang  wrote:
> Hello,
>
> This is Chaoyi Huang(nick: joehuang), I would like to nominate myself as
> Tricircle PTL in Ocata release.
>
> Before look forward to what to do in Ocata release, I want to have a short
> look back what's Tricircle has done in Newton release. The objectives and
> our progress in Newton release are:
>
> * Cross OpenStack L2 networking: "local network" and "shared vlan" supported
> in Tricircle for L2/L3 networking functionalities, this is a great
> fundamental for our Newton release.
> * Dynamic pod binding: the framework is in review.
> * Tempest and basic VM/Volume operation: tempest based check and gate test
> has been integrated into the process, support basic features tempest
> * Keep Tricircle follow OpenStack open source development guideline to make
> Tricircle project as open as any other OpenStack project, so that more and
> more talents would like to join and contribute in Tricircle, and target at
> being a big tent project of OpenStack, being member of OpenStack eco-system
> and help the eco-system to address the problem domain in multi-OpenStack
> cloud, no matter it's in one site or multi-site: now Tricircle is applying
> big-tent application, and the splitting is ongoing, and glad to see more and
> more contributors join Tricricle community.
>
>
> This is great progress for Tricricle based on every contributor's great
> effort.
>
> As the Tricircle will be splitted and dedicate for cross Neutron networking
> automation, my vision for Tricircle Ocata will based on our basis in Newton
> release and what we discussed in these weeks:
>
> * Ensure the Tricircle splitting smoothly with quality.
> * Continue cross OpenStack L2/L3 networking, and work with upstream projects
> like Neutron, L2GW
> * Being better citizen in OpenStack, continue the big-tent application, and
> collaboration with other projects
> * enhance the installation method and make it easier to play Tricircle, so
> that more contributors would like to join Tricircle.
> * Start advance networking service support in Ocata for Tricircle if
> possible
>
> Since the Tricircle project tries to address very fundamental cross Neutron
> networking automation chanllenges, it's exciting to work and contribute in
> such a project, let's enjoy the journey.
>
> 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
>



-- 
Email:
shin...@linux.com
shin...@redhat.com

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

Re: [openstack-dev] [all] Barcelona Design Summit track layout

[Thierry Carrez]

Emilien Macchi wrote:
> On Fri, Sep 16, 2016 at 10:22 AM, Thierry Carrez  
> wrote:
>> 1. If you have a *hard* conflict that I failed to take into account
>> (like the PTL is giving a talk during the one and only fishbowl room the
>> team has), let me know and I'll try to find someone you could swap with.
> 
> I'll give a talk on Thu 27  9:50am-10:30am but in same time there is a
> Puppet design session.
> Maybe could we move this Puppet session to another slot (my only
> constraint is to attend also all TripleO sessions).
> I hope we can arrange something :-)

Argh! I spotted your talk but somehow failed to spot the conflict.

I think the simpler would be to swap the Puppet workroom at 9:50am with
the Watcher workroom at 11:50am. Antoine: would that work for you ?

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing 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] Barcelona Design Summit track layout

[Thierry Carrez]

Richard Theis wrote:
>> 4. If you're an official or prospective team and you notice an empty
>> slot that you'd like to use, let me know which one. I'll collect the
>> requests and try to satisfy them. Note that the page will be refreshed
>> as teams liberate extra slots they don't plan to use -- come back often!
>> Priority will be given to teams which don't have representation at all.
> 
> I'd like to request a workroom for the networking-ovn project team on
> Wednesday from 3:05 to 3:45 and/or 3:55 to 4:35.

There aren't any slot available at those times currently. If one frees
up I'll make sure you can get it.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Kuryr] IPVLAN data path proposal

[Liping Mao (limao)]

Hi Ivan,

I tried your proposal with manually steps in Mitaka, I use netns(instead of 
docker container) and macvlan(instead of ipvlan) in my test:
https://lipingmao.github.io/2016/09/18/kuryr_macvlan_ipvlan_datapath_poc.html

Did I understand correct? Any comments will be very appricated.
Thanks.

Regards,
Liping Mao

From:  Liping Mao mailto:li...@cisco.com>>
Reply-To:  OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date:  2016年9月13日 星期二 下午7:56
To:  OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject:  Re: [openstack-dev] [Kuryr] IPVLAN data path proposal


Hi Ivan，

It sounds cool！

for security group and allowed address pair，
Maybe we can disable port-security，because all the docker in one vm will share 
one security group on the vm port. I'm not sure how to use sg for each 
docker，maybe just disable port-security can be one of the choice. then do not
need allowed address pairs in this case.


Regards，
Lipimg Mao

在 2016年9月12日，19:31，Coughlan, Ivan 
mailto:ivan.cough...@intel.com>> 写道：



Overview
Kuryr proposes to address the issues of double encapsulation and exposure of 
containers as neutron entities when containers are running within VMs.
As an alternative to the vlan-aware-vms and use of ovs within the VM, we 
propose to:
-
Use allowed-address-pairs configuration for the VM neutron port
-
Use IPVLAN for wiring the Containers within VM
In this way:
-
Achieve efficient data path to container within VM
-
Better leverage OpenStack EPA(Enhanced Platform Awareness) features to 
accelerate the data path (more details below)
-
Mitigate the risk of vlan-aware-vms not making neutron in time
-
Provide a solution that works on existing and previous openstack releases
This work should be done in a way permitting the user to optionally select this 
feature.
Required ChangesThe four main changes we have identified in the current kuryr 
codebase are as follows:
・
Introduce an option of enabling “IPVLAN in VM” use case. This can be achieved 
by using a config file option or possibly passing a command line argument. The 
IPVLAN master interface must also be identified.
・
If using “IPVLAN in VM” use case, Kuryr should no longer create a new port in 
Neutron or the associated VEth pairs. Instead, Kuryr will create a new IPVLAN 
slave interface on top of the VM’s master interface and pass this
slave interface to the Container netns.
・
If using “IPVLAN in VM” use case, the VM’s port ID needs to be identified so we 
can associate the additional IPVLAN addresses with the port. This can be 
achieved by querying Neutron’s show-port function and passing the VMs
IP address.
・
If using “IPVLAN in VM” use case, Kuryr should associate the additional IPVLAN 
addresses with the VMs port. This can be achieved using Neutron’s
allowed-address-pairs flag in the
port-update function. We intend to make use of Kuryr’s existing IPAM 
functionality to request these IPs from Neutron.
Asks
We wish to discuss the pros and cons.
For example, containers exposure as proper neutron entities and the utility of 
neutron’s allowed-address-pairs is not yet well understood.
We also wish to understand if this approach is acceptable for kuryr?
EPA
The Enhanced Platform Awareness initiative is a continuous program to enable 
fine-tuning of the platform for virtualized network functions.
This is done by exposing the processor and platform capabilities through the 
management and orchestration layers.
When a virtual network function is instantiated by an Enhanced Platform 
Awareness enabled orchestrator, the application requirements can be more 
efficiently matched with the platform capabilities.
http://itpeernetwork.intel.com/openstack-kilo-release-is-shaping-up-to-be-a-milestone-for-enhanced-platform-awareness/
https://networkbuilders.intel.com/docs/OpenStack_EPA.pdf
https://www.brighttalk.com/webcast/12229/181563/epa-features-in-openstack-kilo
Regards,
Ivan….

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all
copies.


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

Re: [openstack-dev] [kolla][release] Branching of stable/newton

[Thierry Carrez]

Steven Dake (stdake) wrote:
> Release team,
> 
> At one point Doug had indicated all projects would automatically branch
> on tagging of rc1.  I notice in git no Kolla stable/newton branch
> exists. Fwiw this is actually a good thing, because 33 patches have
> merged since rc1 relating to things that need to go into Newton,
> dramatically reducing the amount of backport work we need to do.  Part
> of this was error on my part – not validating all FFE blueprints that
> were marked Implemented were actually implemented.  One related to
> monitoring (and part of the 33 patches since rc1) was actually “Needs
> Review” rather than Implemented (as it was marked).
> 
> I don’t want Kolla to be a special snowflake wrt release processes, and
> we can live with a branch on rc1.  A branch on rc2 would be far better
> for us as we have roughly 250 bugs to triage or fix.  I leave it in the
> release team’s capable judgement to decide best on a course of action.

I'm probably the one to blame for that. Kolla follows milestones but is
trailing the release, which makes it a bit of a release snowflake. I
wasn't sure we should cut the stable branch at RC1 for such a case
(since you're still far away from final).

We should discuss what to do here (branch ASAP, branch at RC2...) on
Monday on the release channel when Doug is around.

> I would request that the expected time of branch be communicated clearly
> to us for the Newton cycle.  I have been communicating with our team
> that rc1 is where we branch.  Folks are now asking “where is the Newton
> branch of Kolla?”

FWIW Doug has been working on a spec so that projects communicate more
clearly when they want the release branch to be cut. For
milestone-driven projects it's usually clear (we branch at RC1), but for
other cases (intermediary-released, trailing) options are a bit more
open so having a way (through the openstack/releases repo) to clearly
communicate "when" will definitely help.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing 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] Barcelona Design Summit track layout

[Vitaly Gridnev]

Hi Thierry,

As we discussed during the last meeting, we agreed that 6wr + cm is
absolutely enough for sahara. So, we can release one working room for other
projects (for example Wed, 3:05 to 3:45)

On Fri, Sep 16, 2016 at 5:22 PM, Thierry Carrez 
wrote:

> Hi everyone,
>
> I mapped the slot allocation (which I sent on Tuesday) to the available
> rooms in Barcelona, trying to take into account all the constraints you
> submitted and to avoid conflicts with talks on the conference side. Here
> is the result:
>
> https://docs.google.com/spreadsheets/d/1TQ-RSlbiBBEclkonIbfUP7R1ExZSJylF1
> uiEKV2G_Cw/pubhtml?gid=1107826458&single=true
>
> This is a pretty brittle (and unfun to build) house of cards, so I'd
> rather minimize the number of changes we push to it at this stage. A few
> things:
>
> 1. If you have a *hard* conflict that I failed to take into account
> (like the PTL is giving a talk during the one and only fishbowl room the
> team has), let me know and I'll try to find someone you could swap with.
>
> 2. If you already know that you won't be using a given slot, let me know
> which one(s) ASAP and I'll remove your team from it to make it available
> for others. (NB: Freezer already gave up 2 wr slots)
>
> 3. If you would like to swap two slots, make sure both PTLs agree and
> let me know. I'll check that it doesn't create other conflicts and make
> it happen.
>
> 4. If you're an official or prospective team and you notice an empty
> slot that you'd like to use, let me know which one. I'll collect the
> requests and try to satisfy them. Note that the page will be refreshed
> as teams liberate extra slots they don't plan to use -- come back often!
> Priority will be given to teams which don't have representation at all.
>
> 5. We have to make the schedule "official" and push it to the main event
> schedule very soon. Please suggest all changes before end of next week
> (September 25) -- after that the layout will be frozen as we map it to
> real room numbers and publish it.
>
> Thanks!
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards,
Vitaly Gridnev,
Project Technical Lead of OpenStack DataProcessing Program (Sahara)
Mirantis, Inc
__
OpenStack Development Mailing 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] [horizon] ListField in Horizon

[Janki Chhatbar]

Hi

I am working on a dashboard's panel that needs an input as a "list". I
couldnot find any "ListField" (like CharFiled) in Horizon forms.

Is there any other field type that takes input as a list or this needs to
be developed?

Any pointer would be appreciated.

-- 
Thanking you

Janki Chhatbar
OpenStack | Docker | SDN
simplyexplainedblog.wordpress.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[HU, BIN]

+1

From: joehuang [mailto:joehu...@huawei.com]
Sent: Sunday, September 18, 2016 2:27 AM
To: openstack-dev 
Subject: [openstack-dev] [tricircle]PTL candidacy

Hello,

This is Chaoyi Huang(nick: joehuang), I would like to nominate myself as 
Tricircle PTL in Ocata release.

Before look forward to what to do in Ocata release, I want to have a short look 
back what's Tricircle has done in Newton release. The objectives and our 
progress in Newton release are:
* Cross OpenStack L2 networking: "local network" and "shared vlan" supported in 
Tricircle for L2/L3 networking functionalities, this is a great fundamental for 
our Newton release.
* Dynamic pod binding: the framework is in review.
* Tempest and basic VM/Volume operation: tempest based check and gate test has 
been integrated into the process, support basic features tempest
* Keep Tricircle follow OpenStack open source development guideline to make 
Tricircle project as open as any other OpenStack project, so that more and
more talents would like to join and contribute in Tricircle, and target at 
being a big tent project of OpenStack, being member of OpenStack eco-system and 
help the eco-system to address the problem domain in multi-OpenStack cloud, no 
matter it's in one site or multi-site: now Tricircle is applying big-tent 
application, and the splitting is ongoing, and glad to see more and more 
contributors join Tricricle community.

This is great progress for Tricricle based on every contributor's great effort.

As the Tricircle will be splitted and dedicate for cross Neutron networking 
automation, my vision for Tricircle Ocata will based on our basis in Newton 
release and what we discussed in these weeks:

* Ensure the Tricircle splitting smoothly with quality.
* Continue cross OpenStack L2/L3 networking, and work with upstream projects 
like Neutron, L2GW
* Being better citizen in OpenStack, continue the big-tent application, and 
collaboration with other projects
* enhance the installation method and make it easier to play Tricircle, so that 
more contributors would like to join Tricircle.
* Start advance networking service support in Ocata for Tricircle if possible

Since the Tricircle project tries to address very fundamental cross Neutron 
networking automation chanllenges, it's exciting to work and contribute in such 
a project, let's enjoy the journey.

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

Re: [openstack-dev] [infra]exception when uploading file to openstack wiki system

[Jeremy Stanley]

On 2016-09-18 02:55:19 + (+), joehuang wrote:
> I am editing the wikipage of Tricircle: 
> https://wiki.openstack.org/wiki/Tricircle#Cloud_Capacity_Expansion
> 
> and want to upload a picture in the wikipage, 
> https://wiki.openstack.org/w/index.php?title=Special:Upload&wpDestFile=Tricircle_usecase1.png
> 
> then exception encountered, and not able to upload any pictures
[...]

Sorry about that, the Cinder device where it stores images had a
communication issue and needed to be checked and remounted. It
should be working now if you want to try again.
-- 
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][neutron] summit cross-project session

[Matt Riedemann]

I want to confirm whether or not we're going to have a nova/neutron 
cross-project fishbowl session in Barcelona, I think we are. Since 
Thierry has the draft slots out I wanted to start looking at what time 
is going to work.


Looking at:

https://docs.google.com/spreadsheets/d/1TQ-RSlbiBBEclkonIbfUP7R1ExZSJylF1uiEKV2G_Cw/pubhtml?gid=1107826458&single=true

Anytime on Thursday afternoon would work - agreed? I'd like to pencil 
something in.


As far as topics, I think we'll pull from the neutron midcycle report:

http://lists.openstack.org/pipermail/openstack-dev/2016-August/102366.html

So mainly live migration and API interaction improvements.

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing 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] Candidacy for cloudkitty PTL

[Christophe Sauthier]

Hello everyone,

I would like to announce my candidacy to become cloudkitty's PTL for
the Ocata release.

Being present in the OpenStack community since almost its beginning,
I have been involved at different levels and community (development,
french community, business side...).
In the past I gave numerous talks about Cloudkitty and its integration
with other solutions to both dev and/or end-users.

Being of the 2 co-father of cloudkitty, I have followed all the
steps of that project (from the Proof of Concept we have shown to
some community members in Atlanta's Summit to the Newton Cycle).

Cloudkitty entered the big tent about a year ago, and we have seen
some new contributors but we failed so far to keep them so far.
That is one of the big challenge I want to tackle in the O cycle.

The other one would be to have a more user-centric approach, to both
ease their usage of the component but also try to have a stronger
coordination with their needs.

I also want to mention that I have been acting as a PTL for
cloudkitty for the last few weeks, due to the absence of the
current one.

I would also like to take this opportunity to thank all members of
the OpenStack community who helped our team during the lasts cycles.

Thank you,
Christophe



Christophe Sauthier   Mail : 
christophe.sauth...@objectif-libre.com

CEO   Mob : +33 (0) 6 16 98 63 96
Objectif LibreURL : www.objectif-libre.com
Au service de votre Cloud Twitter : @objectiflibre

Suivez les actualités OpenStack en français en vous abonnant à la Pause 
OpenStack

http://olib.re/pause-openstack

__
OpenStack Development Mailing 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] [diskimage-builder] Stepping down as diskimage-builder core

[Gregory Haynes]

On Sat, Sep 17, 2016, at 10:23 AM, Clint Byrum wrote:
> It's been my honor to be included with the core reviewer group on
> diskimage-builder, but my focus has changed quite a bit and I'm not
> able to keep up with the review load. As a result, I've lost most of
> the context and struggle to understand patches enough to +2 them.
> 
> Given that, I'm laying down my +2 in diskimage-builder.
> 

Thanks for all your help, Clint!

-Greg

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

Re: [openstack-dev] [OpenStack-I18n] [horizon] Question on a singular/plural string use in openstack_dashboard

[Akihiro Motoki]

Hi Ian,

gettext itself allows this pattern [1] but django compilemessage
expects variables with same names are used in all plural forms (See
Note in [2]).
IMHO it is better to use same variables in all plural forms in code as
possible as we can.
As translator, I try to use the second pattern (i.e., plural form) as
source string as a plural form contains sufficient and full pattern in
most cases.
What I am not sure is this happens only for languages with nplural==1
(like Korean, Japanese and so on).

Akihiro

[1] 
https://www.gnu.org/software/gettext/manual/html_node/Translating-plural-forms.html#Translating-plural-forms
[2] 
https://docs.djangoproject.com/en/1.10/topics/i18n/translation/#pluralization


2016-09-16 18:57 GMT+09:00 Ian Y. Choi :
> Hello,
>
> Recently, thanks to the help from Andreas, I am investigating on a broken
> job
> for the translation import of Horizon project [1].
> The actual error message is
> : openstack_dashboard/locale/ko_KR/LC_MESSAGES/django.po:8273: a format
> specification for argument 'req' doesn't exist in 'msgstr[0]'
>
> And then I have found that this error was from a string in horizon -
> openstack_dashboard [2]
>
> error_message = ungettext_lazy(
> 'The requested instance cannot be launched as you only '
> 'have %(avail)i of your quota available. ',
> 'The requested %(req)i instances cannot be launched as you '
> 'only have %(avail)i of your quota available.',
> count)
> params = {'req': count,
>   'avail': available_count}
>
> In i18n translation infrastructure, only one of two (for singular and
> plural) strings should be
> selected, translated, saved, and finally imported back to Horizon project as
> [1].
> However, the first string only used "%(avail)i" string variable,
> and the second string used both "%(req)i" and "%(avail)i" string variables.
>
> Since one Korean translator selected the first string, there will be no
> "%(req)i" in Korean po file, which generates such an error.
> So my suggestion is to use the same string variables for both two strings
> when we use ungettext_lazy function.
>
> Is it a bug from Horizon? Would it be other issues when we change like
> : from 'The requested instance cannot be launched as you only ' to 'The
> requested %(req)i instance cannot be launched as you only '?
>
>
> [1]
> http://logs.openstack.org/periodic/horizon-propose-translation-update/c038aab/console.html#_2016-09-16_07_37_22_312092
> [2]
> http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/dashboards/project/instances/workflows/create_instance.py#n214
>
>
> With many thanks,
>
> /Ian
>
> ___
> OpenStack-I18n mailing list
> openstack-i...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n

__
OpenStack Development Mailing 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] [kolla][elections][ptl] Kolla PTL Candidacy for Jeffrey Zhang

[Steven Dake (stdake)]

Hui,

Change is what you will see as I am not running for PTL for Ocata.

Reference: 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103499.html

Regards
-steve

On 9/14/16, 4:32 PM, "Hui Kang"  wrote:

+1 for Jeffrey Zhang
- Jeffrey is full time on Kolla
- Steven is doing excellent job, but I would like to see some change.

Thanks.

- Hui

On Mon, Sep 12, 2016 at 3:18 AM, Jeffrey Zhang  
wrote:
> Hi Everyone,
>
> I'm excited to announce my candidacy for PTL for Kolla team during the 
Ocata
> cycle.
>
> Kolla is a fantastic project. It brings fresh new blood to OpenStack 
Deployment
> Management. Simplifying the lives of Operators when managing OpenStack is
> essential to OpenStack’s success and I personally believe Kolla as of 
Liberty
> 1.1.0 delivers on that promise. I also deployed several Kolla production
> environment for customers without any problem. I've been a core 
contributor to
> Kolla since Mitaka. I am full time on Kolla project and have been heavily
> involved with all of my waking hours[0][1].
>
> Over the Newton development cycle, we have implemented numerous new 
features
> and improved stability and usability. The top features are:
>
> * Introduced the Bifrost and kolla-host to manage the bare metal 
provision and
>   initialize the node before deploying OpenStack.
> * The introduction of far more services including Aodh, Bifrost, 
Ceilometer,
>   Cloudkitty, Multipath, Rally, Sahara, Tempest, Watcher.
> * Implemented Dockerfile customization.
> * Launched the kolla-kubernetes project.
> * More robust CI jobs
>
> As a team, the Kolla Community tested 123 nodes for Kolla using osic[2]. 
The
> results validate Kolla works and scales to a majority of use cases today. 
The
> major code paths that enable this scalability have been in place since 
Liberty
> which gives a good indicator of Liberty and Mitaka scalability. As a Kolla
> core reviewer and PTL self-nominee, I find this result to be highly 
satisfying.
> One of Kolla’s many goals has been executed: Deploying OpenStack at 100+ 
node
> count fast and easily.
>
> The kolla community is diversely affiliated, a fantastic crew of 
contributors,
> and excellent leadership within the core reviewer team.
>
> For Ocata, I'd like the project focused on these objectives:
>
> * Focus on the needs of the Kolla team.
> * Optimize the speed of reconfiguration and upgrade.
> * Implement and integrate with more driver plugins for neutron and cinder.
> * Deliver 1.0.0 of kolla-kubernetes.
> * Implement different CI jobs to test diverse scenarios.I’d like to start 
out
>   with some really hard CI problems such as testing real upgrades and
>   validating ceph in the CI jobs per commit.
> * Support the implementation of a monitoring stack.
>
> Finally, I know it is important that PTL time is spent on the 
non-technical
> problem-solving such as mentoring potential core reviewers, scheduling the
> project progress, interacting with other OpenStack projects and many other
> activities a PTL undertakes.  I’d like to work this cycle on scaling those
> activities across the core reviewer team.  I will use my personal 
strengths and
> rely on the core reviewer team’s personal strengths to make Kolla Ocata 
the
> best release yet.
>
> Thank you for the considering me to serve as your Kolla PTL.
>
> Regards,
> Jeffrey Zhang
>
> [0] http://stackalytics.com/?release=all&module=kolla&metric=commits
> [1] http://stackalytics.com/?release=all&module=kolla&metric=marks
> [2] https://review.openstack.org/352101
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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



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

[openstack-dev] [all][elections] PTL nomination period is now over

[Tristan Cacqueray]

PTL Nomination is now over. The official candidate list is available on
the election website[0].

There are 4 projects without candidates, so according to this
resolution[1], the TC we'll have to appoint a new PTL for Astara,
OpenStackSalt, OpenStack UX, Security

There are 6 projects that will have an election: Freezer, Ironic,
Keystone, Kolla, Magnum and Quality_Assurance. The details for those
will be posted shortly after we setup the CIVS system.

Thank you,

[0]: http://governance.openstack.org/election/#ocata-ptl-candidates
[1]:
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html



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

Re: [openstack-dev] [kolla][release] Branching of stable/newton

[Steven Dake (stdake)]

Thierry,

Cool wfm.

Thanks
-steve


On 9/18/16, 7:08 AM, "Thierry Carrez"  wrote:

Steven Dake (stdake) wrote:
> Release team,
> 
> At one point Doug had indicated all projects would automatically branch
> on tagging of rc1.  I notice in git no Kolla stable/newton branch
> exists. Fwiw this is actually a good thing, because 33 patches have
> merged since rc1 relating to things that need to go into Newton,
> dramatically reducing the amount of backport work we need to do.  Part
> of this was error on my part – not validating all FFE blueprints that
> were marked Implemented were actually implemented.  One related to
> monitoring (and part of the 33 patches since rc1) was actually “Needs
> Review” rather than Implemented (as it was marked).
> 
> I don’t want Kolla to be a special snowflake wrt release processes, and
> we can live with a branch on rc1.  A branch on rc2 would be far better
> for us as we have roughly 250 bugs to triage or fix.  I leave it in the
> release team’s capable judgement to decide best on a course of action.

I'm probably the one to blame for that. Kolla follows milestones but is
trailing the release, which makes it a bit of a release snowflake. I
wasn't sure we should cut the stable branch at RC1 for such a case
(since you're still far away from final).

We should discuss what to do here (branch ASAP, branch at RC2...) on
Monday on the release channel when Doug is around.

> I would request that the expected time of branch be communicated clearly
> to us for the Newton cycle.  I have been communicating with our team
> that rc1 is where we branch.  Folks are now asking “where is the Newton
> branch of Kolla?”

FWIW Doug has been working on a spec so that projects communicate more
clearly when they want the release branch to be cut. For
milestone-driven projects it's usually clear (we branch at RC1), but for
other cases (intermediary-released, trailing) options are a bit more
open so having a way (through the openstack/releases repo) to clearly
communicate "when" will definitely help.

-- 
Thierry Carrez (ttx)

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



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

Re: [openstack-dev] [OpenStack-I18n] [horizon] Question on a singular/plural string use in openstack_dashboard

[Ian Y. Choi]

Thank you, Akihiro-san.

I agree that it is better to use same variables as much as possible.

Akihiro Motoki wrote on 9/19/2016 7:21 AM:

Hi Ian,

gettext itself allows this pattern [1] but django compilemessage
expects variables with same names are used in all plural forms (See
Note in [2]).
IMHO it is better to use same variables in all plural forms in code as
possible as we can.
As translator, I try to use the second pattern (i.e., plural form) as
source string as a plural form contains sufficient and full pattern in
most cases.
Yep it would be a Fuzzy form for translation in Zanata, but that's okay 
for me. I have fixed in Korean,

and checked that there is no error for 'msgfmt --check-format ' command.


With many thanks,

/Ian

What I am not sure is this happens only for languages with nplural==1
(like Korean, Japanese and so on).

Akihiro

[1] 
https://www.gnu.org/software/gettext/manual/html_node/Translating-plural-forms.html#Translating-plural-forms
[2] 
https://docs.djangoproject.com/en/1.10/topics/i18n/translation/#pluralization


2016-09-16 18:57 GMT+09:00 Ian Y. Choi :

Hello,

Recently, thanks to the help from Andreas, I am investigating on a broken
job
for the translation import of Horizon project [1].
The actual error message is
: openstack_dashboard/locale/ko_KR/LC_MESSAGES/django.po:8273: a format
specification for argument 'req' doesn't exist in 'msgstr[0]'

And then I have found that this error was from a string in horizon -
openstack_dashboard [2]

 error_message = ungettext_lazy(
 'The requested instance cannot be launched as you only '
 'have %(avail)i of your quota available. ',
 'The requested %(req)i instances cannot be launched as you '
 'only have %(avail)i of your quota available.',
 count)
 params = {'req': count,
   'avail': available_count}

In i18n translation infrastructure, only one of two (for singular and
plural) strings should be
selected, translated, saved, and finally imported back to Horizon project as
[1].
However, the first string only used "%(avail)i" string variable,
and the second string used both "%(req)i" and "%(avail)i" string variables.

Since one Korean translator selected the first string, there will be no
"%(req)i" in Korean po file, which generates such an error.
So my suggestion is to use the same string variables for both two strings
when we use ungettext_lazy function.

Is it a bug from Horizon? Would it be other issues when we change like
: from 'The requested instance cannot be launched as you only ' to 'The
requested %(req)i instance cannot be launched as you only '?


[1]
http://logs.openstack.org/periodic/horizon-propose-translation-update/c038aab/console.html#_2016-09-16_07_37_22_312092
[2]
http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/dashboards/project/instances/workflows/create_instance.py#n214


With many thanks,

/Ian

___
OpenStack-I18n mailing list
openstack-i...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n




__
OpenStack Development Mailing 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] [all][elections] PTL Voting is now open

[Tony Breeds]

Elections are underway and will remain open for you to cast your vote until
2016-09-25, 23:45 UTC.

We are having elections for Freezer, Ironic, Keystone, Kolla, Magnum and
Quality_Assurance.

If you are a Foundation individual member and had a commit in one of the
program's projects[0] over the Mitaka-Newton timeframe (September 5, 2015 00:00
UTC to September 4, 2016 23:59 UTC) then you are eligible to vote. You should
find your email with a link to the Condorcet page to cast your vote in the
inbox of your gerrit preferred email[1].

What to do if you don't see the email and have a commit in at least one of the
programs having an election:
  * check the trash or spam folders of your gerrit Preferred Email address, in
case it went into trash or spam
  * wait a bit and check again, in case your email server is a bit slow
  * find the sha of at least one commit from the program project repos[0] and
email Tristan, Nate and I at the below email addresses below[2]. If we can
confirm that you are entitled to vote, we will add you to the voters list
for the appropriate election.

Our democratic process is important to the health of OpenStack, please exercise
your right to vote.

Candidate statements/platforms can be found linked to Candidate names on this
page: http://governance.openstack.org/election/#ocata-ptl-candidates

Happy voting,

[0] The list of the program projects eligible for electoral status:

https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=sept-2016-elections

[1] Sign into review.openstack.org:
Go to Settings > Contact Information.
Look at the email listed as your Preferred Email.
That is where the ballot has been sent.

[2] Tony's email: tony at bakeyournoodle dot com
Tristan's email: tdecacqu at redhat dot com
Nate's email: openstacknate at gmail dot com

Yours Tony.


signature.asc
Description: 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

Re: [openstack-dev] [all][astara][cloudkitty][dragonflow][i18n][karbor][openstack_ux][openstacksalt][security][senlin][elections] Last hours for PTL candidate announcements

[Adam Lawson]

Tony, I tried to commit my candidacy for Astara but I am not seeing the
file present. Is there a delay between the commit and the display at
git.openstack.org?

//adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072

On Sat, Sep 17, 2016 at 4:53 PM, Tony Breeds 
wrote:

> A quick reminder that we are in the last hours for PTL candidate
> announcements.
>
> If you want to stand for PTL, don't delay, follow the instructions at [1]
> to make sure the community knows your intentions.
>
> Make sure your candidacy have been submitted to the openstack/election
> repository and approved by election officials.
>
> Election statistics[2]:
> ---
> Nominations started   @ 2016-09-12 00:00:00 UTC
> Nominations end   @ 2016-09-18 23:45:00 UTC
> Nominations duration  : 6 days, 23:45:00
> Nominations remaining : 23:54:55
> Nominations progress  :  85.74%
> ---
> Projects  :59
> Projects with candidates  :50 ( 84.75%)
> Projects with election: 3 (  5.08%)
> ===
> Stats gathered@ 2016-09-17 23:50:05 UTC
> Projects without candidates[2]
> Astara
> Cloudkitty
> Dragonflow
> I18n
> Karbor
> OpenStack_UX
> OpenStackSalt
> Security
> Senlin
>
>
> This means that with approximately 1 day left more than 15% of projects
> will be deemed
> leaderless.  In this case the TC will be bound by [3].
>
> Thank you,
> Tony.
>
> [1] http://governance.openstack.org/election/#how-to-submit-your-candidacy
> [2] Assuming the open reviews below are validated
>https://review.openstack.org/#/q/is:open+project:openstack/election
> [3] http://governance.openstack.org/resolutions/20141128-
> elections-process-for-leaderless-programs.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra]exception when uploading file to openstack wiki system

[joehuang]

Thank you very much. The wiki restored to work for uploading files now.

Best Regards
Chaoyi Huang(joehuang)

From: Jeremy Stanley [fu...@yuggoth.org]
Sent: 19 September 2016 0:38
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [infra]exception when uploading file to openstack 
wiki system

On 2016-09-18 02:55:19 + (+), joehuang wrote:
> I am editing the wikipage of Tricircle: 
> https://wiki.openstack.org/wiki/Tricircle#Cloud_Capacity_Expansion
>
> and want to upload a picture in the wikipage, 
> https://wiki.openstack.org/w/index.php?title=Special:Upload&wpDestFile=Tricircle_usecase1.png
>
> then exception encountered, and not able to upload any pictures
[...]

Sorry about that, the Cinder device where it stores images had a
communication issue and needed to be checked and remounted. It
should be working now if you want to try again.
--
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 Development Mailing 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][astara][cloudkitty][dragonflow][i18n][karbor][openstack_ux][openstacksalt][security][senlin][elections] Last hours for PTL candidate announcements

[Tony Breeds]

On Sun, Sep 18, 2016 at 06:12:53PM -0700, Adam Lawson wrote:
> Tony, I tried to commit my candidacy for Astara but I am not seeing the
> file present. Is there a delay between the commit and the display at
> git.openstack.org?

Hi Adam,
No it's just the standard gerrit review system.  Once git review tells you
the change is uploaded it should be visible in gerrit.

I see 2 nominations from you that both arrived after the cut off.  Which means
that the TC will be bound by [1].

During the next week the election officials will let the TC know about
leaderless projects and the TC will determine the correct course of action.

Yours Tony.

[1] 
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html


signature.asc
Description: 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

Re: [openstack-dev] [all] Barcelona Design Summit track layout

[joehuang]

Tricircle (now turn to be dedicated for cross Neutron networking automation) 
would like
to have one BoF session and design session (or combined?) in Barcelona summit, 
is it
possible to have a meeting room for that.

Tricircle splitting is ongoing, wiki/design doc update started, and draft is 
ready for
review, the source code cleaning starts soon, hopefully will be ready before 
Barcelona summit.

A blue print has been registered to track the splitting: 
https://blueprints.launchpad.net/tricircle/+spec/make-tricircle-dedicated-for-networking-automation-across-neutron

Best Regards
Chaoyi Huang(joehuang)

From: Vitaly Gridnev [vgrid...@mirantis.com]
Sent: 18 September 2016 22:48
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] Barcelona Design Summit track layout

Hi Thierry,

As we discussed during the last meeting, we agreed that 6wr + cm is absolutely 
enough for sahara. So, we can release one working room for other projects (for 
example Wed, 3:05 to 3:45)

On Fri, Sep 16, 2016 at 5:22 PM, Thierry Carrez 
mailto:thie...@openstack.org>> wrote:
Hi everyone,

I mapped the slot allocation (which I sent on Tuesday) to the available
rooms in Barcelona, trying to take into account all the constraints you
submitted and to avoid conflicts with talks on the conference side. Here
is the result:

https://docs.google.com/spreadsheets/d/1TQ-RSlbiBBEclkonIbfUP7R1ExZSJylF1uiEKV2G_Cw/pubhtml?gid=1107826458&single=true

This is a pretty brittle (and unfun to build) house of cards, so I'd
rather minimize the number of changes we push to it at this stage. A few
things:

1. If you have a *hard* conflict that I failed to take into account
(like the PTL is giving a talk during the one and only fishbowl room the
team has), let me know and I'll try to find someone you could swap with.

2. If you already know that you won't be using a given slot, let me know
which one(s) ASAP and I'll remove your team from it to make it available
for others. (NB: Freezer already gave up 2 wr slots)

3. If you would like to swap two slots, make sure both PTLs agree and
let me know. I'll check that it doesn't create other conflicts and make
it happen.

4. If you're an official or prospective team and you notice an empty
slot that you'd like to use, let me know which one. I'll collect the
requests and try to satisfy them. Note that the page will be refreshed
as teams liberate extra slots they don't plan to use -- come back often!
Priority will be given to teams which don't have representation at all.

5. We have to make the schedule "official" and push it to the main event
schedule very soon. Please suggest all changes before end of next week
(September 25) -- after that the layout will be frozen as we map it to
real room numbers and publish it.

Thanks!

--
Thierry Carrez (ttx)

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



--
Best Regards,
Vitaly Gridnev,
Project Technical Lead of OpenStack DataProcessing Program (Sahara)
Mirantis, Inc
__
OpenStack Development Mailing 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][astara][cloudkitty][dragonflow][i18n][karbor][openstack_ux][openstacksalt][security][senlin][elections] Last hours for PTL candidate announcements

[Adam Lawson]

Yep got it got it. Thanks.

//adam

On Sep 18, 2016 8:46 PM, "Tony Breeds"  wrote:

> On Sun, Sep 18, 2016 at 06:12:53PM -0700, Adam Lawson wrote:
> > Tony, I tried to commit my candidacy for Astara but I am not seeing the
> > file present. Is there a delay between the commit and the display at
> > git.openstack.org?
>
> Hi Adam,
> No it's just the standard gerrit review system.  Once git review tells
> you
> the change is uploaded it should be visible in gerrit.
>
> I see 2 nominations from you that both arrived after the cut off.  Which
> means
> that the TC will be bound by [1].
>
> During the next week the election officials will let the TC know about
> leaderless projects and the TC will determine the correct course of action.
>
> Yours Tony.
>
> [1] http://governance.openstack.org/resolutions/20141128-
> elections-process-for-leaderless-programs.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] venting -- OpenStack wiki reCAPTCHA

[Tom Fifield]

On 10/09/16 06:12, Tom Fifield wrote:



On 廿十六年九月九日 暮 02:01, Shamail wrote:

Hi Tom,

I'll help with that.  :)


Thanks Shamail - standby - I will write up instructions and send them
through.


I added a section "Helping Real Users avoid the CAPTCHA (admin rights 
needed)" on the wiki gardening page:


https://wiki.openstack.org/wiki/How_To_Use_The_Wiki#Helping_Real_Users_avoid_the_CAPTCHA_.28admin_rights_needed.29

Please try it out and edit as needed!




Thanks,
Shamail


On Sep 9, 2016, at 2:49 PM, Tom Fifield  wrote:


On 廿十六年九月九日 朝 11:45, Hayes, Graham wrote:

On 09/09/2016 08:44, Tom Fifield wrote:



On 廿十六年九月八日 暮 08:36, Jeremy Stanley wrote:

On 2016-09-09 01:10:15 + (+), Bhandaru, Malini K wrote:
Is it just me who likes to hit the save button often?
It gets tedious proving often that you are not a robot. Wiki
reCAPTCHA likes proof even if saves are spaced less than a minute
apart!
Wiki Gods, hear my plea!


I sympathize. That captcha addition is one of several tools we're
leveraging currently to combat the ongoing spam/scammer/vandalism
problems on wiki.openstack.org, as an alternative to shutting it
down completely. Unfortunately even now I still spend a chunk of
every day blocking new accounts created by abusers and cleaning up
all their modifications, but am hoping that with other improvements
we have pending the onslaught will lessen and we can revisit some of
the more intrusive mechanisms on which we've been forced to rely
(for example, I think we should be able to configure it so that
users whose previous edits have been confirmed by a wiki admin are
added to a group that bypasses the captcha, and then get a team of
wiki groomers in the habit of adding known good accounts to that
group).


Indeed - fungi has been doing amazing work :(

I have been adding "known good" accounts to such a group - there's
about
64 so far:

https://wiki.openstack.org/w/index.php?title=Special:ListUsers&group=autopatrol



How would someone get in said list?


$100 donation to the buy-fungi-beer fund.

... and/or email me a link to your wiki user page (Click in the top
right, click on your username)

I'm also going through the recent edits and adding people to get the
"bulk" of us in there, when time permits. Anyone else that wants to
help is welcome.






Is it possible to disable CAPTCHA for users in group "autopatrol"?

__

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



__

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


__

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


__

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



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



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

Re: [openstack-dev] [Fuel] Getting rid of ISO

[Guo, Ruijing]

Hi, Vladimir

Any guide to install from rpm?

Thanks,
-Ruijing
From: Vladimir Kozhukalov [mailto:vkozhuka...@mirantis.com]
Sent: Tuesday, August 16, 2016 4:58 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Fuel] Getting rid of ISO

Dear colleagues,
We finally have working custom deployment job that deploys Fuel admin node 
using online RPM repositories (not ISO) on vanilla Centos 7.0.

Currently all Fuel system and deployment tests use ISO and we are planning to 
re-implement all these jobs (including BVT, SWARM, and Fuel CI jobs) to exclude 
ISO from the pipeline. That will allow us to get rid of ISO as our deliverable 
and instead rely totally on package repositories. Linux distributions like 
Ubuntu, Debian, RHEL, etc. are already delivered via ISO/qcow2/etc. images and 
we'd better stop reinventing a wheel and support our own ISO build code. That 
will allow us to make Fuel admin node deployment more flexible.

I will infrom about our next steps here in the thread.

Vladimir Kozhukalov
__
OpenStack Development Mailing 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] [gnocchi] Support for other drivers - influxdb

[Sam Morrison]

Hi Julien,


> On 16 Sep 2016, at 7:46 PM, Julien Danjou  wrote:
> 
>> I could push it up to gerrit but I think something will need to change
>> for it to run the influxdb tests?
> 
> You can use pifpaf like we do for the indexer, InfluxDB is supported.
> That should make it possible to run the unit tests in the gate right
> away.

OK I’ve made some changes to support this, will push this to my branch shortly. 
Just fixing up a coupe more things.

> As for the functional tests, you can set up support via devstack and
> we wouldhad a job in infra.

Will look into this soon.

>> It should act more like the carbonara drivers now as opposed to the
>> old influx driver. It will do downsampling and retention based on the
>> archive policies.
> 
> That's great, and I imagine it'd be faster than doing it on the fly like
> previously.
> 
>> Currently it is failing one test [1] and that is to do with retention. 
>> This is because influxDB does retention based on the current time, e.g. a 1 
>> day retention policy will be from the current time. 
>> The tests assume that the retention period is based on the data stored and 
>> so it will keep 1 day of data no matter how old that data is.
> 
> lol, yeah the test assume it's a database that does not block you to
> insert things as you want. I feel like that being a bad and funny design
> decision (Whisper has the same defect).
> 
>> I also had to disable retention policies in influx while running the tests as
>> when I backfill data influx is too smart and won’t backfill data that 
>> wouldn’t
>> meet the retention policy.
> 
> I imagine that's because some of our tests are using date in year e.g.
> 2014? :)

Yeah exactly, I think it is ok with these disabled. We can just trust that 
influx retention policies work.

> Great. Do you have performance numbers, scalability, or things that are
> different/better/worse than using Carbonara based drivers?

No performance numbers. Do you have a test in mind so I can compare. Is there a 
standard way to test this?

Cheers,
Sam


> 
> Cheers,
> -- 
> Julien Danjou
> // Free Software hacker
> // https://julien.danjou.info


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