Re: [openstack-dev] [Fuel][Plugins][Ironic] Deploy Ironic with fuel ?

[Aleksey Kasatkin]

+ Pavlo, Andrey.


Aleksey Kasatkin


On Mon, Oct 19, 2015 at 6:45 AM,  wrote:

> Hello,
>
>
>
> I’m currently searching for information about Ironic Fuel plugin :
> https://github.com/openstack/fuel-plugin-ironic I don’t find any
> documentation on it.
>
>
>
> I’ve tried to install and deploy an Openstack environment with Fuel 7.0
> and Ironic plugin but it failed. After adding ironic role to a node Fuel UI
> crashed, due to a missing network “baremetal” . When creating a network
> group
>
>
>
> fuel network-group --create --node-group 1 --name \
>
> "baremetal" --cidr 192.168.3.0/24
>
> UI works again, but I got some errors in the deployment, during network
> configuration. So I think I have to configure a network template, did
> someone already do this for this plugin ?
>
>
>
> Regards,
>
>
>
> Loic
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
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][client] collecting opinions on neutronclient options

[Akihiro Motoki]

Hi team,

Recently there are many patches to add help messages to neutron
*-update sub-commands
(or others). I made similar comments and discussions repeatedly in
various reviews.

I created a etherpad page [1]  to dicsuss neutronclient options

Once we collect opinions and have a consensus,
I will propose a document patch on the guideline to neutronclient.

Feel free to join.

I would like to gather opinions this week.
I try to coordinate opinions.

[1] https://etherpad.openstack.org/p/neutronclient-adding-update-option

Thanks,
Akihiro

__
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] [mistral] How to call 3rd-party tools(such as Ansible) in Mistral

[WANG, Ming Hao (Tony T)]

Renat,

Another question is:
If I use custom action to run Ansible, the Ansible playbook should be stored on 
the same server of Mistral. Is it right?

Thanks,
Tony

From: Renat Akhmerov [mailto:rakhme...@mirantis.com]
Sent: Monday, October 19, 2015 2:58 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as 
Ansible) in Mistral


On 19 Oct 2015, at 07:53, WANG, Ming Hao (Tony T) 
> wrote:

The “custom action” needs to re-install Mistral.
If the Mistral service is part of 3rd party OpenStack, it may be unacceptable 
to let every user create his own customer action. What do you think?

Yes, correct. It requires reinstall. If your goal is to give users possibility 
to create custom actions "on the fly” then it’s now impossible in Mistral for 
fundamental reasons. We can’t let users upload arbitrary Python code via API 
for security reasons. However, we have a couple of ideas that we’re going to 
explore in order to partially close this gap:

  *   Keep action code on a client-side, sort of what StackStorm does. But IMO 
we could think about automating it in a more elegant and transparent way. For 
example, we could use decorators in python code that would associate a function 
or a class with a certain workflow task. Then a workflow could call this code 
back while its running using some mechanism (i.e. some special action). In this 
case, however, we’d have to have a process handling callback requests from 
Mistral on a client side. The alternative: using HTTP Long Poll mechanism so 
that a client could claim available tasks itself.
  *   We have BP [1] that describes the idea of using so-called action 
providers. It assumes that we can register trustworthy action providers that 
could dynamically provide new actions to Mistral. I personally like this idea 
and to some extent it would solve this issue but it requires some additional 
setup which works for cases like StackStorm but doesn’t work if we want to use 
Mistral as is, as a hosted workflow service.

Anyway, whatever solution we accept it will be a trade-off and depend on a 
particular use case.

Ad-hoc actions may also work for you if, for example, we create enough base 
actions that they could be built upon. Say if most of your actions are HTTP 
based then you can just create your own library (e.g. a workbook) of ad-hoc 
actions that will be wrappers around std.http.

Also look at what StackStorm does, it may also be helpful.

Thanks

[1] https://blueprints.launchpad.net/mistral/+spec/action-providers
__
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][QA][Plugins] Move functional tests from fuel-qa to the plugins

[Simon Pasquier]

Thanks for the reply, Andrew! I must admit that I haven't read thoroughly
the specification on the new team structure [1]. IIUC plugin developers
should be added to the MAINTAINERS file of fuel-qa for the directories that
concern their plugins. If I take LMA as an example, this would be:
fuelweb_test/tests/plugins/plugin_elasticsearch
fuelweb_test/tests/plugins/plugin_lma_collector
fuelweb_test/tests/plugins/plugin_lma_infra_alerting

Is that right?

I can submit a change to fuel-qa for adding the LMA team to the MAINTAINERS
file but I can't figure out the structure of the YAML data:
fuel-web/MAINTAINERS [2] is organized as "{directory1: [maintainer1,
maintainer2, ...], directory2: [...], ...}" while for fuel-qa [3] (and
other Fuel projects), it's "[maintainer1, maintainer2, ...]".

BR,
Simon

[1] http://specs.fuel-infra.org/fuel-specs-master/policy/team-structure.html
[2] https://github.com/openstack/fuel-web/blob/master/MAINTAINERS
[3] https://github.com/openstack/fuel-qa/blob/master/MAINTAINERS

On Sat, Oct 17, 2015 at 2:21 AM, Andrew Woodward  wrote:

> We have already discussed this to be a result of describing data driven
> testing, untill this spec is completed there is little sense to remove all
> of these since fuel-qa is 100% required to operate this way. In the interim
> we should just specify the appropriate SME with the MAINTAINERS file.
>
> On Fri, Oct 16, 2015 at 11:34 AM Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
>> Tests should be in plugin
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Fri, Oct 16, 2015 at 5:58 PM, Simon Pasquier 
>> wrote:
>>
>>> Hello Alexey,
>>>
>>> On Fri, Oct 16, 2015 at 5:35 PM, Alexey Elagin 
>>> wrote:
>>>
 Hello Simon!

 We are going to remove plugins' functional tests from fuel-qa because
 this tests don't use for our plugins CI process.

>>>
>>> And where are the existing tests going to be stored then?
>>>
>>> Thanks,
>>> Simon
>>>
>>>


 __
 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
>>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
> __
> 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][Plugins] Plugin deployment questions

[Matthew Mosesohn]

Hi Patrick,

During the 7.0 development cycle we made a lot of enhancements to what
environment characteristics can be modified through a plugin. One item that
plugins cannot directly modify is the default Fuel roles and their
metadata. That having been said, there is an open-ended post_install.sh
script you can use for your plugin to "hack" this value. I know of one
project that currently disables the requirement for controller role in a
deployment. This may be helpful in testing a given standalone role that
doesn't depend on a controller.

Here's a link to the script: http://paste.openstack.org/show/476821/
Note that this doesn't reflect "enabled" status of a plugin. It will make
controller min count 0 for all environments. That won't break them, but it
just removes the restriction.

Best Regards,
Matthew Mosesohn

On Mon, Oct 19, 2015 at 3:29 PM, Dmitry Mescheryakov <
dmescherya...@mirantis.com> wrote:

> Hello folks,
>
> I second Patrick's idea. In our case we would like to install standalone
> RabbitMQ cluster with Fuel reference architecture to perform destructive
> tests on it. Requirement to install controller is an excessive burden in
> that case.
>
> Thanks,
>
> Dmitry
>
> 2015-10-19 13:44 GMT+03:00 Patrick Petit :
>
>> Hi There,
>>
>> There are situations where we’d like to deploy only Fuel plugins in an
>> environment.
>> That’s typically the case with Elasticsearch and InfluxDB plugins of LMA
>> tools.
>> Currently it’s not possible because you need to at least have one
>> controller.
>> What exactly is making that limitation? How hard would it be to have it
>> removed?
>>
>> Thanks
>> Patrick
>>
>> __
>> 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] Modularization activity POC

[Evgeniy L]

Hi Mike,

1. our plan is to have working partitioning/provisioning in a couple of
weeks,
networking is more complicated and it's better to ask Vladimir/Ryan.
2, 3. here we have just some general ideas, we should have independent
releases on pypi,
each component should have responsible person (team), the same way we
do it for fuel-plugin-builder
and fuelclient. The same applies to independent docker containers.
Another thing is how
we are going to combine it in ready to use tool, there are several
ways, if we drop containers,
those will be just rpm/deb packages and dependencies between them, if
we continue using
docker containers, the simplest and the most robust way is to build a
single container which
has everything user needs.

Regarding the spec our plan is to start writing spec after we have working
POC.

Thanks,


On Tue, Oct 20, 2015 at 4:43 AM, Mike Scherbakov 
wrote:

> This is great start, Evgeny.
> I have a few questions:
>
>1. When do you expect to have POC to show?
>2. Do you plan to put new services into separate repos?
>3. How do you plan to package those - will you create RPM package for
>each, as well as Docker container (as we have everything in containers on
>Fuel master node)
>
> These questions, of course, should be covered in spec - so may be I should
> just wait for you guys to create specs. I just think that it's very
> important to think about integration from the very beginning.
>
> Thanks,
>
> On Mon, Oct 19, 2015 at 8:54 AM Igor Kalnitsky 
> wrote:
>
>> Hey Evgeniy.
>>
>> This is awesome news1 I believe that microservices is way to go.
>> Despite the fact that them bring a set of classical problems (e.g.
>> duplication of domain entities) we will win more than loose. :)
>>
>> If there will be any specs or design meetings, please send me invite -
>> I'd gladly join discussions.
>>
>> Thanks,
>> Igor
>>
>>
>>
>>
>> On Wed, Oct 14, 2015 at 5:30 PM, Evgeniy L  wrote:
>> > Hi,
>> >
>> > We are starting Fuel modularization POC activity which is basically in
>> one
>> > sentence
>> > can be explained as "Use Fuel without Fuel", it means that we want to
>> > provide
>> > for a user a way to use some good things from Fuel, without entire
>> master
>> > node and
>> > other parts which user doesn't need.
>> >
>> > Currently we have monolithic system which includes every aspect of
>> > deployment
>> > logic, those components tightly coupled together, and there are few
>> persons
>> > who understand all the interactions between components.
>> >
>> > As a result of modularization we will get the next benefits:
>> > 1. reusability of components
>> > 1.1. it will lead to more components consumers (users)
>> > 1.2. better integration with the community (some community projects
>> might
>> >be interested in using some parts of Fuel)
>> > 2. components decoupling will lead to clear interfaces between
>> components
>> > 2.1. so it will be easier to replace some component
>> > 2.2. it will be easier to split the work between teams and it will help
>> > scale teams in
>> >a much more efficient way
>> >
>> > Here are some thing which naturally can be used separately:
>> > * network configuration (is a part of POC)
>> > * advanced partitioning/provisioning (is a part of POC)
>> > * discovery mechanism (ironic-inspector?)
>> > * power management (ironic?)
>> > * network verification
>> > * diagnostic snapshot
>> > * etc
>> >
>> > The main purpose of POC is to try to make partly working system to
>> figure
>> > out the
>> > scope of work which we will have to do upstream in order to make it
>> > production ready.
>> >
>> > Here are few basic component-specific ideas:
>> >
>> > Advanced partitioning/provisioning
>> > * split provisioning into two independent actions partitioning and
>> > provisioning
>> >   (currently we have a single call which does partitioning,
>> provisioning,
>> >post provisioning configuration)
>> > * figure out the data format (currently it's too Fuel and Cobbler
>> specific)
>> >
>> > Network configuration
>> > * CRUD api on any entity in the system (in Fuel not all of the data are
>> > exposed via api,
>> >   so user has to go and edit entries in db manually)
>> > * no constraints regarding to network topology (in Fuel there are a lot
>> of
>> > hardcoded
>> >   assumptions)
>> >
>> > Node hardware discovery
>> > * should be able to support different source drivers at the same time
>> >(csv file, fuel-nailgun-agent, CMDB, dhcp, cobbler etc)
>> > * versioning of HW information (required for life cycle management)
>> > * notification about changes in hardware or about node statuses
>> >   (required for life cycle management)
>> >
>> > Common requirements for components:
>> > * every component must follow OpenStack coding standards when
>> >   we start working upstream after POC (so there shouldn't be a question
>> >   what to use pecan of 

Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as Ansible) in Mistral

[Lingxian Kong]

Hi, Minghao,

The answer is yes, if you want to use Ansible playbook in you
customized 'ansible actions', you need put the playbooks under a place
that your code has access to.

BTW, you can send personal email to me in Chinese, in case you want to
solve your problems quickly :-)

On Tue, Oct 20, 2015 at 4:58 PM, WANG, Ming Hao (Tony T)
 wrote:
> Renat,
>
>
>
> Another question is:
>
> If I use custom action to run Ansible, the Ansible playbook should be stored
> on the same server of Mistral. Is it right?
>
>
>
> Thanks,
>
> Tony
>
>
>
> From: Renat Akhmerov [mailto:rakhme...@mirantis.com]
> Sent: Monday, October 19, 2015 2:58 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as
> Ansible) in Mistral
>
>
>
>
>
> On 19 Oct 2015, at 07:53, WANG, Ming Hao (Tony T)
>  wrote:
>
>
>
> The “custom action” needs to re-install Mistral.
>
> If the Mistral service is part of 3rd party OpenStack, it may be
> unacceptable to let every user create his own customer action. What do you
> think?
>
>
>
> Yes, correct. It requires reinstall. If your goal is to give users
> possibility to create custom actions "on the fly” then it’s now impossible
> in Mistral for fundamental reasons. We can’t let users upload arbitrary
> Python code via API for security reasons. However, we have a couple of ideas
> that we’re going to explore in order to partially close this gap:
>
> Keep action code on a client-side, sort of what StackStorm does. But IMO we
> could think about automating it in a more elegant and transparent way. For
> example, we could use decorators in python code that would associate a
> function or a class with a certain workflow task. Then a workflow could call
> this code back while its running using some mechanism (i.e. some special
> action). In this case, however, we’d have to have a process handling
> callback requests from Mistral on a client side. The alternative: using HTTP
> Long Poll mechanism so that a client could claim available tasks itself.
> We have BP [1] that describes the idea of using so-called action providers.
> It assumes that we can register trustworthy action providers that could
> dynamically provide new actions to Mistral. I personally like this idea and
> to some extent it would solve this issue but it requires some additional
> setup which works for cases like StackStorm but doesn’t work if we want to
> use Mistral as is, as a hosted workflow service.
>
>
>
> Anyway, whatever solution we accept it will be a trade-off and depend on a
> particular use case.
>
>
>
> Ad-hoc actions may also work for you if, for example, we create enough base
> actions that they could be built upon. Say if most of your actions are HTTP
> based then you can just create your own library (e.g. a workbook) of ad-hoc
> actions that will be wrappers around std.http.
>
>
>
> Also look at what StackStorm does, it may also be helpful.
>
>
>
> Thanks
>
>
>
> [1] https://blueprints.launchpad.net/mistral/+spec/action-providers
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

__
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][heat] Which repo to use in docs -- git.openstack.org or github.com?

[Qiming Teng]

Hi,

Just encountered this again in code review [1]. The question is about
the repository to point to when documenting things up. Between the
following links, which one should we use?

- https://git.openstack.org/cgit/openstack/sqlalchemy-migrate
- https://github.com/openstack/sqlalchemy-migrate

I had an impression that I saw something like 'use git.openstack.org
instead of github.com because the later is just a mirror ...' but cannot
find the link now. Maybe it is an illusion. :)

So, seriously, any recommendations or guidelines?

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

Regards,
  Qiming



__
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] jobs that will fail when extras.d support in Devstack is removed in 8 weeks

[Sean Dague]

Logstash has been upgraded, so the old urls won't work any more. However
here are the top 9 jobs from yesterday that will fail after this change:

gate-murano-congress-devstack-dsvm
gate-murano-devstack-dsvm
gate-rally-dsvm-murano-task
gate-designate-dsvm-powerdns
gate-solum-devstack-dsvm
gate-rally-dsvm-designate-designate
gate-designate-dsvm-bind9
gate-cue-integration-dsvm-rabbitmq
gate-congress-dsvm-api
gate-solum-devstack-dsvm-centos7

You can search for jobs with the following logstash query:

message:"extras.d support is being removed in Mitaka-1"

-Sean

-- 
Sean Dague
http://dague.net

__
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] Assigning VIPs on network config serialization

[Roman Prykhodchenko]

My concern here is that there is also a Network check feature that according to 
its name should check things like whether or not there’s enough IP addresses in 
all ranges in a network. The problem is that it may be run at any time, even 
when VIPs are not yet allocated. From a user-side the workflow may look a 
little wrong:

 1. Check network => get "Everything is fine"
 2. Right after that press Apply Changes => get "Network configuration is bad"

This behavior is actually described in [1]. Should we allocate VIPs on network 
check as well?


1. https://bugs.launchpad.net/fuel/+bug/1487996


- romcheg


> 19 жовт. 2015 р. о 18:28 Igor Kalnitsky  написав(ла):
> 
> Hi Roman,
> 
>> Not assign addresses to VIPs is a network configuration is being
>> serialized for API output.
> 
> AFAIK, that's not truth. Fuel UI and OSTF relies only on *public* VIP.
> So we can keep only *public* VIP, and do not assign / show others.
> 
>> Check number of IP addresses wherever it is possible to "spoil" network
>> configuration: when a role get’s assigned to a node, when network
>> changes or network templates are applied.
> 
> It won't work that way. What if you enable plugin when all roles are
> assigned? What if you change networks, and now it's not enough IPs? Or
> what if enable plugin that requires 5 VIPs in public network by
> default, and it's not enough. But by using network templates you
> assign this netrole to management network?
> 
> From what I can say the proposed approach requires to put checks
> here-and-there around the code. Let's do not overcomplicate things
> without real need.
> 
> So let me share my thoughts regarding this issue.
> 
> * We shouldn't *allocate* VIPs when we make GET request on network
> configuration handler. It should return only *already allocated* VIPs
> and no more.
> * VIP allocation should be performed when we run deployment.
> * Before deployment checks should fail, if there's not enough VIPs or
> other resources. So users fix them, and try again.
> * Both Fuel UI and OSTF needs VIPs only when cluster is deployed, and
> it's safe to return allocated VIPs on that stage.
> 
> So what do you think guys?
> 
> Thanks,
> Igor
> 
> On Fri, Oct 16, 2015 at 5:25 PM, Roman Prykhodchenko  wrote:
>> Hi folks!
>> 
>> I’ve been discussing several bugs [1-3] with some folks and noticed that 
>> they share the same root cause which is that network serialization fails, if 
>> there’s not enough IP addresses in all available ranges of one of the 
>> available networks to assign them to all VIPs. There are several possible 
>> solutions for this issue:
>> 
>> a. Not assign addresses to VIPs is a network configuration is being 
>> serialized for API output.
>> A lot of external tools and modules, i. e., OSTF, rely on that information 
>> so this relatively small change in Nailgun will require big cross-components 
>> changes. Therefore this change can only be done as a feature but it seems to 
>> be the way this issue must be fixed.
>> 
>> b. Leave some VIPs without IP addresses
>> If network configuration is generated for API output it is possible to leave 
>> some VIPs without IP addresses assigned. This will only create more mess 
>> around Nailgun and bring more issues that it will resolve.
>> 
>> c. Check number of IP addresses wherever it is possible to "spoil" network 
>> configuration: when a role get’s assigned to a node, when network changes or 
>> network templates are applied.
>> 
>> 
>> The proposal is to follow [c] as a fast solution and file a blueprint for 
>> [a]. Opinions?
>> 
>> 
>> 1 https://bugs.launchpad.net/fuel/+bug/1487996
>> 2 https://bugs.launchpad.net/fuel/+bug/1500394
>> 3 https://bugs.launchpad.net/fuel/+bug/1504572
>> 
>> 
>> - romcheg
>> 
>> __
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [mistral] How to call 3rd-party tools(such as Ansible) in Mistral

[Lingxian Kong]

Or, feel free to join our IRC channel for quick response, #openstack-mistral

On Tue, Oct 20, 2015 at 4:58 PM, WANG, Ming Hao (Tony T)
 wrote:
> Renat,
>
>
>
> Another question is:
>
> If I use custom action to run Ansible, the Ansible playbook should be stored
> on the same server of Mistral. Is it right?
>
>
>
> Thanks,
>
> Tony
>
>
>
> From: Renat Akhmerov [mailto:rakhme...@mirantis.com]
> Sent: Monday, October 19, 2015 2:58 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as
> Ansible) in Mistral
>
>
>
>
>
> On 19 Oct 2015, at 07:53, WANG, Ming Hao (Tony T)
>  wrote:
>
>
>
> The “custom action” needs to re-install Mistral.
>
> If the Mistral service is part of 3rd party OpenStack, it may be
> unacceptable to let every user create his own customer action. What do you
> think?
>
>
>
> Yes, correct. It requires reinstall. If your goal is to give users
> possibility to create custom actions "on the fly” then it’s now impossible
> in Mistral for fundamental reasons. We can’t let users upload arbitrary
> Python code via API for security reasons. However, we have a couple of ideas
> that we’re going to explore in order to partially close this gap:
>
> Keep action code on a client-side, sort of what StackStorm does. But IMO we
> could think about automating it in a more elegant and transparent way. For
> example, we could use decorators in python code that would associate a
> function or a class with a certain workflow task. Then a workflow could call
> this code back while its running using some mechanism (i.e. some special
> action). In this case, however, we’d have to have a process handling
> callback requests from Mistral on a client side. The alternative: using HTTP
> Long Poll mechanism so that a client could claim available tasks itself.
> We have BP [1] that describes the idea of using so-called action providers.
> It assumes that we can register trustworthy action providers that could
> dynamically provide new actions to Mistral. I personally like this idea and
> to some extent it would solve this issue but it requires some additional
> setup which works for cases like StackStorm but doesn’t work if we want to
> use Mistral as is, as a hosted workflow service.
>
>
>
> Anyway, whatever solution we accept it will be a trade-off and depend on a
> particular use case.
>
>
>
> Ad-hoc actions may also work for you if, for example, we create enough base
> actions that they could be built upon. Say if most of your actions are HTTP
> based then you can just create your own library (e.g. a workbook) of ad-hoc
> actions that will be wrappers around std.http.
>
>
>
> Also look at what StackStorm does, it may also be helpful.
>
>
>
> Thanks
>
>
>
> [1] https://blueprints.launchpad.net/mistral/+spec/action-providers
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

__
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] [Magnum] Coe components status

[Vikas Choudhary]

Hi Team,

I would appreciate any opinion/concern regarding "coe-component-status"
feature implementation [1].

For example in k8s, using API api/v1/namespaces/{namespace}/componentstatuses,
status of each k8s component can be queried. My approach would be to
provide a command in magnum like "magnum
coe-component-status" leveraging coe provided rest api and result will be
shown to user.

[1] https://blueprints.launchpad.net/magnum/+spec/coe-component-status



-Vikas Choudhary
__
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][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

[Evgeniy L]

Hi,

I have a comment regarding to when/where run translators.
I think data processing (fetching + validation + translation) should be done
as a separate stage, this way when we start deployment, we are sure
that we have everything we need to perform deployment, but I understand
that there might be exceptions and sometimes we will have to get the data
on the fly.
If we are going to put translated data into some distributed store I'm not
sure
if distributed approach for fetching and updating the data won't cause the
problems
with race conditions, in centralised approach probability to get such
problems can
be reduced.

Thanks,


On Tue, Oct 20, 2015 at 5:14 AM, Mike Scherbakov 
wrote:

> Thanks Vladimir.
> This is very important work, I'd say. I'd split it into two parts:
>
>1. Have some store where you'd dump data from serializers. Hiera
>should be able to read easily directly from this store.
>2. Refactor serializers so to get rid of single python method which
>creates data for multiple OpenStack components, and allow deployment
>engineers to easily modify code of particular piece
>
> For #1, it is important to think broadly. We want this store to be used by
> other tools which users may have (Puppet Master, Ansible, etc.) as a source
> data, and so that Fuel & other tools can coexist on the same env if really
> needed (even though I'd ideally try to avoid it).
> We need to have an abstraction layer there, so that we can have drivers
> for key-value store and for such things as Zookeeper, for instance, in the
> future. I think we need to address #1 in the first order, before going to
> #2 (if we can't do it in parallel).
>
> For #2, I think we need to consider flexibility. What if we use Ansible,
> or container for some of our services? So we need to think where we can put
> these per-component / per-task serializers, so those can be used for both
> Puppet module & something different.
>
> Also, it's interesting problem from the execution point of view. Do we run
> serialization on Fuel Master side or on slave nodes, where we install
> OpenStack? I see some issues with running it on OpenStack nodes, even
> though I like an idea of load distribution, etc. For instance, if you run
> almost all graph, and then the last task in the graph runs corresponding
> serializer - and there is a Python exception for whatever reason (user
> input leads to bug in calculation). You could get it right a way, if you
> tried to calculate it before overall deployment - but now you've been
> waiting deployment to be almost done to catch it.
>
> Thank you,
>
> On Fri, Oct 16, 2015 at 9:22 AM Vladimir Kuklin 
> wrote:
>
>> Hey, Fuelers
>>
>> TL;DR This email is about how to make
>>
>> * Intro
>> I want to bring up one of the important topics on how to make Fuel more
>> flexible. Some of you know that we have been discussing means of doing this
>> internally and now it is time to share these thoughts with all of you.
>>
>> As you could know per Evgeniy Li's message [0] we are looking forward
>> splitting Fuel (specifically it's Fuel-Web) part into set of microservices
>> each one serving their own purpose like networking configuration,
>> partitioning, etc.
>>
>>
>> And while we are working on this it seems that we need to get rid of
>> so-called Nailgun serializers that are put too close to business logic
>> engine, that have a lot of duplicating attributes; you are not able to
>> easily modify or extend them; you are not able to change their behaviour
>> even when Fuel Library is capable of doing so - everything is hardcoded in
>> Nailgun code without clear separation between business logic and actual
>> deployment workflow data generation and orchestration.
>>
>> Let me give you an example:
>>
>> * Case A. Replace Linux bridges with OVS bridges by default
>>
>> We all know that we removed OVS as much as possible from our reference
>> architecture due to its buginess. Imagine a situation when someone
>> magically fixed OVS and wants to use it as a provider for generic bonds and
>> bridge. It actually means that he needs to set default provider in
>> network_scheme for l23network puppet module to 'ovs' instead of 'lnx'.
>> Imagine, he has put this magical OVS into a package and created a plugin.
>> The problem here will be that he needs to override what network serializer
>> is sending to the nodes.
>>
>> But the problem here is that he cannot do it without editing Nailgun code
>> or override this serializer in any way.
>>
>> * Case B. Make Swift Partitions Known to Fuel Library
>>
>> Imagine, you altered the way you partition your disk in Nailgun. You
>> created a special role for swift disks which should occupy the whole disk.
>> In this case you should be able to get this info from api and feed it to
>> swift deployment task. But it is not so easy - this stuff is still
>> hardcoded in deployment serializers like {mp} field of nodes array of
>> hashes.
>>
>> 

Re: [openstack-dev] [Fuel] Testing before switching to upstream librarian

[Vladimir Kuklin]

Folks

This is what we should discuss. Let's think of better testing coverage when
we decide to switch to new tag. We MUST NOT skip a single bug which we
fixed in downstream. So this means that for each bug fixed in downstream
there should be a set of tests merged into our testing framework along with
the fix. This should be an obligatory requirement for each change. This
testing framework MUST test each change to review.fuel-infra.org or to
fuel-library so that we can catch such issues immediately.

I would start with covering each bug with particular unit and/or
puppet-noop test and then, when we have working data-driven testing, there
should be a template of test for each environment.

Again, Sergey and Ivan, their MUST be 0 (zero) commits skipped by
downstream if they are not in upstream, unless it is 100% proven that this
commit is not needed anymore. And this can be proven only either by this
bugfix test passing against upstream or by SME's consensus on it.

I strongly urge you not to skip such fixes silently and discuss them with
Fuel Library core reviewers.

On Tue, Oct 20, 2015 at 1:26 PM, Sergii Golovatiuk  wrote:

> Hi,
>
> On Mon, Oct 19, 2015 at 10:46 PM, Sergey Kolekonov <
> skoleko...@mirantis.com> wrote:
>
>> Hi,
>>
>> I agree with Ivan. Getting rid of forks and moving to puppet-librarian is
>> complicated work and such problems are nearly unavoidable. It's hard to
>> cover all possible corner cases with regular tests.
>>
>
> This case shows the lack of integration tests. We do not validate if
> config files for all services are exactly the same before and after
> switching to librarian. We rely on deployment only. This way is not
> accurate.
>
>
>
>> openstacklib module provides basic functionality for many OpenStack
>> modules, so reverting it to Kilo code means breaking the whole Liberty
>> deployment.
>> Let's don't block development process and merge all lost fixes.
>>
>
> The main problem is not breaking deployment but recurring regressions and
> how to address them.
>
>
>
>>
>> Thanks Matthew for reporting this issue.
>>
>> On Mon, Oct 19, 2015 at 10:10 PM, Ivan Berezovskiy <
>> iberezovs...@mirantis.com> wrote:
>>
>>> Hi,
>>>
>>> First of all, I want to mention (I don't blame anyone), that two
>>> patchsets in bug description
>>> ([0], [1]) were not merged into upstream puppet-openstacklib module (and
>>> commit
>>> messages don't contain links to upstream review). I see only one
>>> proposed patch [2]
>>> from Dmitry Ilyin, which was abandoned at Sep 18. Now it's restored and
>>> those issues should be fixed using it.
>>>
>>> Second, our patches (moving to librarian) were tested several times
>>> under Fuel CI jobs,
>>> on BVTs, smoke_neutron tests with Kilo and Liberty code. Unfortunately,
>>> we didn't find
>>> problems with deployment.
>>>
>>> Third, two weeks passed after merging of our patches for librarian, and
>>> only now
>>> we are speaking about regressions.
>>>
>>> Patch [2] covers missing two commits [0], [1], that's why I suggest to
>>> get it merged
>>> and then recheck issues, because it's very late for reverting.
>>>
>>>
>>> [0] - https://review.openstack.org/#/c/219668/
>>> [1] - https://review.openstack.org/#/c/223676/
>>> [2] - https://review.openstack.org/#/c/220224/
>>>
>>> 2015-10-19 20:59 GMT+03:00 Sergii Golovatiuk :
>>>
 Hi,

 The policy should be revert, IMHO. cherry-pick doesn't guarantee the
 consistency, so it will take more time... Also this way gives time to write
 tests to exclude the regression in future.


 --
 Best regards,
 Sergii Golovatiuk,
 Skype #golserge
 IRC #holser

 On Mon, Oct 19, 2015 at 6:52 PM, Matthew Mosesohn <
 mmoses...@mirantis.com> wrote:

> Hi Fuelers,
>
> It seems we have a regression on two critical bugs because of
> switching Fuel to puppet-openstacklib:
> https://bugs.launchpad.net/fuel/+bug/1507685
>
> This regressed to patches that were in Fuel Library that addressed two
> bugs marked as Critical.
>
> We should improve the acceptance criteria for moving to upstream
> modules to ensure no bugs are regressed that relate to the particular
> Puppet module being migrated.
>
> Secondly, what should our policy be? Revert the switch to upstream
> module? Or just work on cherry-picking the appropriate fixes?
>
> Best Regards,
> Matthew Mosesohn
>
>
> __
> 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:
 

Re: [openstack-dev] [all][heat] Which repo to use in docs -- git.openstack.org or github.com?

[Andreas Jaeger]

On 2015-10-20 12:17, Qiming Teng wrote:

Hi,

Just encountered this again in code review [1]. The question is about
the repository to point to when documenting things up. Between the
following links, which one should we use?

- https://git.openstack.org/cgit/openstack/sqlalchemy-migrate
- https://github.com/openstack/sqlalchemy-migrate

I had an impression that I saw something like 'use git.openstack.org
instead of github.com because the later is just a mirror ...' but cannot
find the link now. Maybe it is an illusion. :)

So, seriously, any recommendations or guidelines?


Yes, git.openstack.org is our official server, github is just a 
read-only mirror.


Linking to github might also raise the expectation that we use the usual 
github workflow which is not the case,


Andreas


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


--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


__
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] [puppet] Match type checking from oslo.config.

[Sofer Athlan-Guyot]

Hi,

The idea would be to have some of the types defined oslo config
http://git.openstack.org/cgit/openstack/oslo.config/tree/oslo_config/types.py
ported to puppet type.  Those that looks like good candidates are:
 - Boolean;
 - IPAddress;
and in a lesser extend:
 - Integer;
 - Float;

For instance in puppet type requiring a Boolean, we may test
"/[tT]rue|[fF]alse/", but the real thing is :

TRUE_VALUES = ['true', '1', 'on', 'yes']
FALSE_VALUES = ['false', '0', 'off', 'no']

all this being case insensitive.

This can lead to discrepancies when checking if the resource is in_sync
for instance, as it could be saved as "1" and we would check for "true".

IPAddress could/should be use in puppet-neutron for instance to catch
problems earlier.

Eventually, this would be a library of types that could be included,
using a mixin in any type/provider and that would define the:
 - is_sync;
 - validate;
 - newparam;

Something like:

  newproperty(:gateway_ip) do
include Puppet_X::Openstack::Types::IPAdrress
  end

Float and Integer are very easy to make and I put them for completeness.

Any other types could be included there as well.

This point was raised during the last meeting[1] 

[1] 
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-10-13-15.00.html
-- 
Sofer Athlan-Guyot

__
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] Testing before switching to upstream librarian

[Sergii Golovatiuk]

Hi,

On Mon, Oct 19, 2015 at 10:46 PM, Sergey Kolekonov 
wrote:

> Hi,
>
> I agree with Ivan. Getting rid of forks and moving to puppet-librarian is
> complicated work and such problems are nearly unavoidable. It's hard to
> cover all possible corner cases with regular tests.
>

This case shows the lack of integration tests. We do not validate if config
files for all services are exactly the same before and after switching to
librarian. We rely on deployment only. This way is not accurate.



> openstacklib module provides basic functionality for many OpenStack
> modules, so reverting it to Kilo code means breaking the whole Liberty
> deployment.
> Let's don't block development process and merge all lost fixes.
>

The main problem is not breaking deployment but recurring regressions and
how to address them.



>
> Thanks Matthew for reporting this issue.
>
> On Mon, Oct 19, 2015 at 10:10 PM, Ivan Berezovskiy <
> iberezovs...@mirantis.com> wrote:
>
>> Hi,
>>
>> First of all, I want to mention (I don't blame anyone), that two
>> patchsets in bug description
>> ([0], [1]) were not merged into upstream puppet-openstacklib module (and
>> commit
>> messages don't contain links to upstream review). I see only one proposed
>> patch [2]
>> from Dmitry Ilyin, which was abandoned at Sep 18. Now it's restored and
>> those issues should be fixed using it.
>>
>> Second, our patches (moving to librarian) were tested several times under
>> Fuel CI jobs,
>> on BVTs, smoke_neutron tests with Kilo and Liberty code. Unfortunately,
>> we didn't find
>> problems with deployment.
>>
>> Third, two weeks passed after merging of our patches for librarian, and
>> only now
>> we are speaking about regressions.
>>
>> Patch [2] covers missing two commits [0], [1], that's why I suggest to
>> get it merged
>> and then recheck issues, because it's very late for reverting.
>>
>>
>> [0] - https://review.openstack.org/#/c/219668/
>> [1] - https://review.openstack.org/#/c/223676/
>> [2] - https://review.openstack.org/#/c/220224/
>>
>> 2015-10-19 20:59 GMT+03:00 Sergii Golovatiuk :
>>
>>> Hi,
>>>
>>> The policy should be revert, IMHO. cherry-pick doesn't guarantee the
>>> consistency, so it will take more time... Also this way gives time to write
>>> tests to exclude the regression in future.
>>>
>>>
>>> --
>>> Best regards,
>>> Sergii Golovatiuk,
>>> Skype #golserge
>>> IRC #holser
>>>
>>> On Mon, Oct 19, 2015 at 6:52 PM, Matthew Mosesohn <
>>> mmoses...@mirantis.com> wrote:
>>>
 Hi Fuelers,

 It seems we have a regression on two critical bugs because of switching
 Fuel to puppet-openstacklib:
 https://bugs.launchpad.net/fuel/+bug/1507685

 This regressed to patches that were in Fuel Library that addressed two
 bugs marked as Critical.

 We should improve the acceptance criteria for moving to upstream
 modules to ensure no bugs are regressed that relate to the particular
 Puppet module being migrated.

 Secondly, what should our policy be? Revert the switch to upstream
 module? Or just work on cherry-picking the appropriate fixes?

 Best Regards,
 Matthew Mosesohn


 __
 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
>>>
>>>
>>
>>
>> --
>> Thanks, Ivan Berezovskiy
>> MOS Puppet Team Lead
>> at Mirantis 
>>
>> slack: iberezovskiy
>> skype: bouhforever
>> phone: + 7-960-343-42-46
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Regards,
> Sergey Kolekonov
>
> __
> 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][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

[Vladimir Kuklin]

Folks

Can we please stop using etherpad and move to some more usable thing as
Google Docs? Etherpad seems too unusable for such discussion especially
with this coloured formatting.

Mike

I currently see no need in following marketing trend for noSQL here - we
need to store a set of structured data. This store should be the one that
can be easily consumed directly or with some API wrapper. That is all. We
will need to carefully evaluate each storage engine and decide which to
pick. I personally insist on the engine that provides 100% consistency
which is in fact opposite to what most of noSQL and distributed
architectures provide. Nobody cares if you lose 1 billion of messages in a
social network (even these messages authors) - this is almost all the time
garbage with porn and cat pictures. Things will get worse if you destroy
something in production serving accounting in your cloud due to the fact
that nodes are

I agree with option #2 - we actually should have task abstraction layer
with drivers for execution, but I would go with baby steps for supporting
other deployment tools - currently I do not see any benefit in using
Ansible for tasks that Fuel is solving. The same is almost true for
containers, but this is a different story.

Eugene, Mike

I agree with you that we need to think about where to execute these
serializers. I think that we could do it the following way - serializer can
be executed wherever it can actually work and it should possibly put data
into centralized storage for the means of logging, control and accounting.
I am not sure that this is the limitation case all the users will agree
with, but we need to think of it.

Regarding this 'last task throwing an exception issue' - we can handle this
properly by simply rerunning the task that failed only due to serialization
problem. Or even better - reorder its execution for later steps and try it
again in a while if there are other tasks to be executed.

But Mike's approach of data preparation prior to deployment/workflow
transaction execution seems more viable. I think, we should follow the
following one: "If you do not know the data before the transaction run,
this data should be calculated after this transaction ends and this data
should be used for another workflow in a different transaction".


On Tue, Oct 20, 2015 at 1:20 PM, Evgeniy L  wrote:

> Hi,
>
> I have a comment regarding to when/where run translators.
> I think data processing (fetching + validation + translation) should be
> done
> as a separate stage, this way when we start deployment, we are sure
> that we have everything we need to perform deployment, but I understand
> that there might be exceptions and sometimes we will have to get the data
> on the fly.
> If we are going to put translated data into some distributed store I'm not
> sure
> if distributed approach for fetching and updating the data won't cause the
> problems
> with race conditions, in centralised approach probability to get such
> problems can
> be reduced.
>
> Thanks,
>
>
> On Tue, Oct 20, 2015 at 5:14 AM, Mike Scherbakov  > wrote:
>
>> Thanks Vladimir.
>> This is very important work, I'd say. I'd split it into two parts:
>>
>>1. Have some store where you'd dump data from serializers. Hiera
>>should be able to read easily directly from this store.
>>2. Refactor serializers so to get rid of single python method which
>>creates data for multiple OpenStack components, and allow deployment
>>engineers to easily modify code of particular piece
>>
>> For #1, it is important to think broadly. We want this store to be used
>> by other tools which users may have (Puppet Master, Ansible, etc.) as a
>> source data, and so that Fuel & other tools can coexist on the same env if
>> really needed (even though I'd ideally try to avoid it).
>> We need to have an abstraction layer there, so that we can have drivers
>> for key-value store and for such things as Zookeeper, for instance, in the
>> future. I think we need to address #1 in the first order, before going to
>> #2 (if we can't do it in parallel).
>>
>> For #2, I think we need to consider flexibility. What if we use Ansible,
>> or container for some of our services? So we need to think where we can put
>> these per-component / per-task serializers, so those can be used for both
>> Puppet module & something different.
>>
>> Also, it's interesting problem from the execution point of view. Do we
>> run serialization on Fuel Master side or on slave nodes, where we install
>> OpenStack? I see some issues with running it on OpenStack nodes, even
>> though I like an idea of load distribution, etc. For instance, if you run
>> almost all graph, and then the last task in the graph runs corresponding
>> serializer - and there is a Python exception for whatever reason (user
>> input leads to bug in calculation). You could get it right a way, if you
>> tried to calculate it before overall deployment - but 

Re: [openstack-dev] [Fuel] Testing before switching to upstream librarian

[Sergii Golovatiuk]

Ivan,

BVT is not source of truth. BVT handles couple of scenarios from hundreds.
You should rely on swarm test and get parity in % of failed tests.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Mon, Oct 19, 2015 at 9:10 PM, Ivan Berezovskiy  wrote:

> Hi,
>
> First of all, I want to mention (I don't blame anyone), that two patchsets
> in bug description
> ([0], [1]) were not merged into upstream puppet-openstacklib module (and
> commit
> messages don't contain links to upstream review). I see only one proposed
> patch [2]
> from Dmitry Ilyin, which was abandoned at Sep 18. Now it's restored and
> those issues should be fixed using it.
>
> Second, our patches (moving to librarian) were tested several times under
> Fuel CI jobs,
> on BVTs, smoke_neutron tests with Kilo and Liberty code. Unfortunately, we
> didn't find
> problems with deployment.
>
> Third, two weeks passed after merging of our patches for librarian, and
> only now
> we are speaking about regressions.
>
> Patch [2] covers missing two commits [0], [1], that's why I suggest to get
> it merged
> and then recheck issues, because it's very late for reverting.
>
>
> [0] - https://review.openstack.org/#/c/219668/
> [1] - https://review.openstack.org/#/c/223676/
> [2] - https://review.openstack.org/#/c/220224/
>
> 2015-10-19 20:59 GMT+03:00 Sergii Golovatiuk :
>
>> Hi,
>>
>> The policy should be revert, IMHO. cherry-pick doesn't guarantee the
>> consistency, so it will take more time... Also this way gives time to write
>> tests to exclude the regression in future.
>>
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Mon, Oct 19, 2015 at 6:52 PM, Matthew Mosesohn > > wrote:
>>
>>> Hi Fuelers,
>>>
>>> It seems we have a regression on two critical bugs because of switching
>>> Fuel to puppet-openstacklib:
>>> https://bugs.launchpad.net/fuel/+bug/1507685
>>>
>>> This regressed to patches that were in Fuel Library that addressed two
>>> bugs marked as Critical.
>>>
>>> We should improve the acceptance criteria for moving to upstream modules
>>> to ensure no bugs are regressed that relate to the particular Puppet module
>>> being migrated.
>>>
>>> Secondly, what should our policy be? Revert the switch to upstream
>>> module? Or just work on cherry-picking the appropriate fixes?
>>>
>>> Best Regards,
>>> Matthew Mosesohn
>>>
>>>
>>> __
>>> 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
>>
>>
>
>
> --
> Thanks, Ivan Berezovskiy
> MOS Puppet Team Lead
> at Mirantis 
>
> slack: iberezovskiy
> skype: bouhforever
> phone: + 7-960-343-42-46
>
>
> __
> 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] [Tempest] where fwaas tempest tests should be?

[Sean M. Collins]

My only concern is how tightly coupled the FwaaS code is with the L3 agent. We 
have a bug already filed because the L3 agent inheriting the FwaaS code causes 
circular dependencies, but it also be the reason why FwaaS co-gates with the 
main Neutron repo.

Let's try and fix the tight coupling of the L3 agent with the FwaaS code so we 
can get FwaaS to just gate by itself.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.__
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] [rally] Rally boot tests fails with Error Forbidden: It is not allowed to create an interface on external networks

[Behzad Dastur]

I have a contrail/OpenStack cloud deployed on which I am trying to run some
rally benchmarks. But I am having trouble getting the rally boot tests to
run. It throws the "Error Forbidden: It is not allowed to create an
interface on external network"

It seems it is trying to create an interface on the external network,
however in this case that operation is not required as the contrail plugin
handles that.

 Is there a way to tell the rally scenario to avoid doing that. SImply put
the operations that need to happen are:

1. nova boot (create private network/ or use private network provided)

2. neutron floating ip create, and assign it to the port eg (neutron
floatingip-create --port-id  )

Here is the error log:

2015-10-20 00:24:12.759 19075 INFO
rally.plugins.openstack.context.keystone.users [-] Task
3000fcbd-2762-400d-920f-dfbfb667e7ec | Starting:  Enter context:
`users`2015-10-20 00:24:14.711 19075 INFO
rally.plugins.openstack.context.keystone.users [-] Task
3000fcbd-2762-400d-920f-dfbfb667e7ec | Completed: Enter context:
`users`2015-10-20 00:24:16.222 19264 INFO rally.task.runner [-] Task
3000fcbd-2762-400d-920f-dfbfb667e7ec | ITER: 0 START2015-10-20
00:24:16.227 19264 INFO rally.task.runner [-] Task
3000fcbd-2762-400d-920f-dfbfb667e7ec | ITER: 1 START2015-10-20
00:24:18.420 19264 INFO rally.task.runner [-] Task
3000fcbd-2762-400d-920f-dfbfb667e7ec | ITER: 0 END: Error Forbidden:
It is not allowed to create an interface on external network
2de28d39-34f9-48c5-bbac-609e258b7aad (HTTP 403) (Request-ID:
req-fe32bcf8-f624-4a2d-a083-7b6c5d1f24ab)


regards,
Behzad
__
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] Assigning VIPs on network config serialization

[Igor Kalnitsky]

Andrew,

> but the problem lies that VIP's need to already be allocated.

Why? Fuel doesn't use them on this stage.


> They need to be allocated on network update, or when a node role requiring
> one is added to the environment.

It looks like either you or me misunderstood something. AFAIK, node
role itself has nothing in common with VIPs. It doesn't require any of
them.

Currently VIPs are requested by network roles, and network roles are
the same for all nodes (except Network Templating case). Network roles
are assigned on network, and if VIP is required for network role it
will be allocated in the assigned network.

So basically, it requires a huge effort to redesign our allocation
system to achieve what you want, because:

* Each time you reassign network role, the corresponding VIP should be
re-allocated in the database either.
* Each time you enable/disable plugins, the VIPs should be
re-allocated, because plugins may export network roles.
* Each time you add new node to cluster, the VIPs should be
re-allocated, because with new node you simply may run out of free
IPs. And, btw, should we assign IP on added nodes here? Or maybe
postpone to serialization step?

Well, Andrew, I believe we don't have enough resources to implement
your proposal. Moreover, the proposed approach requires a lot of
discussions and design meetings. And it definitely should be
implemented in scope of some blueprint, not a bugfix.


> Not knowing the address until serialization for deployment is too late.

Once again - why? I agree, perhaps it would be useful, but there's no
strict requirement on this and we should resolve our issues
step-by-step. See my response above.


> No, Again, this is too late.

Too late for what?


- Igor

On Tue, Oct 20, 2015 at 12:38 PM, Roman Prykhodchenko  wrote:
> My concern here is that there is also a Network check feature that according 
> to its name should check things like whether or not there’s enough IP 
> addresses in all ranges in a network. The problem is that it may be run at 
> any time, even when VIPs are not yet allocated. From a user-side the workflow 
> may look a little wrong:
>
>  1. Check network => get "Everything is fine"
>  2. Right after that press Apply Changes => get "Network configuration is bad"
>
> This behavior is actually described in [1]. Should we allocate VIPs on 
> network check as well?
>
>
> 1. https://bugs.launchpad.net/fuel/+bug/1487996
>
>
> - romcheg
>
>
>> 19 жовт. 2015 р. о 18:28 Igor Kalnitsky  
>> написав(ла):
>>
>> Hi Roman,
>>
>>> Not assign addresses to VIPs is a network configuration is being
>>> serialized for API output.
>>
>> AFAIK, that's not truth. Fuel UI and OSTF relies only on *public* VIP.
>> So we can keep only *public* VIP, and do not assign / show others.
>>
>>> Check number of IP addresses wherever it is possible to "spoil" network
>>> configuration: when a role get’s assigned to a node, when network
>>> changes or network templates are applied.
>>
>> It won't work that way. What if you enable plugin when all roles are
>> assigned? What if you change networks, and now it's not enough IPs? Or
>> what if enable plugin that requires 5 VIPs in public network by
>> default, and it's not enough. But by using network templates you
>> assign this netrole to management network?
>>
>> From what I can say the proposed approach requires to put checks
>> here-and-there around the code. Let's do not overcomplicate things
>> without real need.
>>
>> So let me share my thoughts regarding this issue.
>>
>> * We shouldn't *allocate* VIPs when we make GET request on network
>> configuration handler. It should return only *already allocated* VIPs
>> and no more.
>> * VIP allocation should be performed when we run deployment.
>> * Before deployment checks should fail, if there's not enough VIPs or
>> other resources. So users fix them, and try again.
>> * Both Fuel UI and OSTF needs VIPs only when cluster is deployed, and
>> it's safe to return allocated VIPs on that stage.
>>
>> So what do you think guys?
>>
>> Thanks,
>> Igor
>>
>> On Fri, Oct 16, 2015 at 5:25 PM, Roman Prykhodchenko  wrote:
>>> Hi folks!
>>>
>>> I’ve been discussing several bugs [1-3] with some folks and noticed that 
>>> they share the same root cause which is that network serialization fails, 
>>> if there’s not enough IP addresses in all available ranges of one of the 
>>> available networks to assign them to all VIPs. There are several possible 
>>> solutions for this issue:
>>>
>>> a. Not assign addresses to VIPs is a network configuration is being 
>>> serialized for API output.
>>> A lot of external tools and modules, i. e., OSTF, rely on that information 
>>> so this relatively small change in Nailgun will require big 
>>> cross-components changes. Therefore this change can only be done as a 
>>> feature but it seems to be the way this issue must be fixed.
>>>
>>> b. Leave some VIPs without IP addresses
>>> If network 

Re: [openstack-dev] [Fuel] Assigning VIPs on network config serialization

[Igor Kalnitsky]

Roman,

> This behavior is actually described in [1]. Should we allocate
> VIPs on network check as well?

No, we shouldn't. We should check whether it's enough IPs for nodes /
VIPs with current network configuration, but no more.

- igor

On Tue, Oct 20, 2015 at 4:54 PM, Igor Kalnitsky  wrote:
> Andrew,
>
>> but the problem lies that VIP's need to already be allocated.
>
> Why? Fuel doesn't use them on this stage.
>
>
>> They need to be allocated on network update, or when a node role requiring
>> one is added to the environment.
>
> It looks like either you or me misunderstood something. AFAIK, node
> role itself has nothing in common with VIPs. It doesn't require any of
> them.
>
> Currently VIPs are requested by network roles, and network roles are
> the same for all nodes (except Network Templating case). Network roles
> are assigned on network, and if VIP is required for network role it
> will be allocated in the assigned network.
>
> So basically, it requires a huge effort to redesign our allocation
> system to achieve what you want, because:
>
> * Each time you reassign network role, the corresponding VIP should be
> re-allocated in the database either.
> * Each time you enable/disable plugins, the VIPs should be
> re-allocated, because plugins may export network roles.
> * Each time you add new node to cluster, the VIPs should be
> re-allocated, because with new node you simply may run out of free
> IPs. And, btw, should we assign IP on added nodes here? Or maybe
> postpone to serialization step?
>
> Well, Andrew, I believe we don't have enough resources to implement
> your proposal. Moreover, the proposed approach requires a lot of
> discussions and design meetings. And it definitely should be
> implemented in scope of some blueprint, not a bugfix.
>
>
>> Not knowing the address until serialization for deployment is too late.
>
> Once again - why? I agree, perhaps it would be useful, but there's no
> strict requirement on this and we should resolve our issues
> step-by-step. See my response above.
>
>
>> No, Again, this is too late.
>
> Too late for what?
>
>
> - Igor
>
> On Tue, Oct 20, 2015 at 12:38 PM, Roman Prykhodchenko  wrote:
>> My concern here is that there is also a Network check feature that according 
>> to its name should check things like whether or not there’s enough IP 
>> addresses in all ranges in a network. The problem is that it may be run at 
>> any time, even when VIPs are not yet allocated. From a user-side the 
>> workflow may look a little wrong:
>>
>>  1. Check network => get "Everything is fine"
>>  2. Right after that press Apply Changes => get "Network configuration is 
>> bad"
>>
>> This behavior is actually described in [1]. Should we allocate VIPs on 
>> network check as well?
>>
>>
>> 1. https://bugs.launchpad.net/fuel/+bug/1487996
>>
>>
>> - romcheg
>>
>>
>>> 19 жовт. 2015 р. о 18:28 Igor Kalnitsky  
>>> написав(ла):
>>>
>>> Hi Roman,
>>>
 Not assign addresses to VIPs is a network configuration is being
 serialized for API output.
>>>
>>> AFAIK, that's not truth. Fuel UI and OSTF relies only on *public* VIP.
>>> So we can keep only *public* VIP, and do not assign / show others.
>>>
 Check number of IP addresses wherever it is possible to "spoil" network
 configuration: when a role get’s assigned to a node, when network
 changes or network templates are applied.
>>>
>>> It won't work that way. What if you enable plugin when all roles are
>>> assigned? What if you change networks, and now it's not enough IPs? Or
>>> what if enable plugin that requires 5 VIPs in public network by
>>> default, and it's not enough. But by using network templates you
>>> assign this netrole to management network?
>>>
>>> From what I can say the proposed approach requires to put checks
>>> here-and-there around the code. Let's do not overcomplicate things
>>> without real need.
>>>
>>> So let me share my thoughts regarding this issue.
>>>
>>> * We shouldn't *allocate* VIPs when we make GET request on network
>>> configuration handler. It should return only *already allocated* VIPs
>>> and no more.
>>> * VIP allocation should be performed when we run deployment.
>>> * Before deployment checks should fail, if there's not enough VIPs or
>>> other resources. So users fix them, and try again.
>>> * Both Fuel UI and OSTF needs VIPs only when cluster is deployed, and
>>> it's safe to return allocated VIPs on that stage.
>>>
>>> So what do you think guys?
>>>
>>> Thanks,
>>> Igor
>>>
>>> On Fri, Oct 16, 2015 at 5:25 PM, Roman Prykhodchenko  
>>> wrote:
 Hi folks!

 I’ve been discussing several bugs [1-3] with some folks and noticed that 
 they share the same root cause which is that network serialization fails, 
 if there’s not enough IP addresses in all available ranges of one of the 
 available networks to assign them to all VIPs. There are several possible 
 

Re: [openstack-dev] [Heat] core team nomination

[Randall Burt]

+1

 Original message 
From: Sergey Kraynev
Date:10/20/2015 8:42 AM (GMT-06:00)
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: [openstack-dev] [Heat] core team nomination

I'd like to propose new candidates for heat core-team:
Rabi Mishra
Peter Razumovsky

According statistic both candidate made a big effort in Heat as
reviewers and as contributors [1][2].
They were involved in Heat community work  during last several releases and
showed good understanding of Heat code.
I think, that they are ready to became core-reviewers.

Heat-cores, please vote with +/- 1.

[1] http://stackalytics.com/report/contribution/heat-group/180
[2] http://stackalytics.com/?module=heat-group=person-day
--
Regards,
Sergey.

__
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] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

[Sofer Athlan-Guyot]

Gilles Dubreuil  writes:

> On 14/10/15 17:15, Gilles Dubreuil wrote:
>> 
>> 
>> On 14/10/15 10:36, Colleen Murphy wrote:
>>>
>>>
>>> On Tue, Oct 13, 2015 at 6:13 AM, Vladimir Kuklin >> > wrote:
>>>
>>> Puppetmaster and Fuelers,
>>>
>>> Last week I mentioned that I would like to bring the theme of using
>>> native ruby OpenStack client and use it within the providers.
>>>
>>> Emilien told me that I had already been late and the decision was
>>> made that puppet-openstack decided to not work with Aviator based on
>>> [0]. I went through this thread and did not find any unresolvable
>>> issues with using Aviator in comparison with potential benefits it
>>> could have brought up.
>>>
>>> What I saw actually was like that:
>>>
>>> * Pros
>>>
>>> 1) It is a native ruby client
>>> 2) We can import it in puppet and use all the power of Ruby
>>> 3) We will not need to have a lot of forks/execs for puppet 
>>> 4) You are relying on negotiated and structured output provided by
>>> API (JSON) instead of introducing workarounds for client output like [1]
>>>
>>> * Cons
>>>
>>> 1) Aviator is not actively supported 
>>> 2) Aviator does not track all the upstream OpenStack features while
>>> native OpenStack client does support them
>>> 3) Ruby community is not really interested in OpenStack (this one is
>>> arguable, I think)
>>>
>>> * Proposed solution
>>>
>>> While I completely understand all the cons against using Aviator
>>> right now, I see that Pros above are essential enough to change our
>>> mind and invest our own resources into creating really good
>>> OpenStack binding in Ruby.
>>> Some are saying that there is not so big involvement of Ruby into
>>> OpenStack. But we are actually working with Puppet/Ruby and are
>>> invloved into community. So why should not we own this by ourselves
>>> and lead by example here?
>>>
>>> I understand that many of you do already have a lot of things on
>>> their plate and cannot or would not want to support things like
>>> additional library when native OpenStack client is working
>>> reasonably well for you. But if I propose the following scheme to
>>> get support of native Ruby client for OpenStack:
>>>
>>> 1) we (community) have these resources (speaking of the company I am
>>> working for, we at Mirantis have a set of guys who could be very
>>> interested in working on Ruby client for OpenStack)
>>> 2) we gradually improve Aviator code base up to the level that it
>>> eliminates issues that are mentioned in  'Cons' section
>>> 3) we introduce additional set of providers and allow users and
>>> operators to pick whichever they want
>>> 4) we leave OpenStackClient default one
>>>
>>> Would you support it and allow such code to be merged into upstream
>>> puppet-openstack modules?
>>>
>>>
>>> [0] 
>>> https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J
>>> [1] 
>>> https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86
>>> -- 
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04 
>>> +7 (926) 702-39-68 
>>> Skype kuklinvv
>>> 35bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com 
>>> www.mirantis.ru 
>>> vkuk...@mirantis.com 
>>>
>>>
>>> The scale-tipping reason we went with python-openstackclient over the
>>> Aviator library was that at the same time we were trying to switch, we
>>> were also developing keystone v3 features and we could only get those
>>> features from python-openstackclient.
>>>
>>> For the first two pros you listed, I'm not convinced they're really
>>> pros. Puppet types and providers are actually extremely well-suited to
>>> shelling out to command-line clients. There are existing, documented
>>> puppet APIs to do it and we get automatic debug output with it. Nearly
>>> every existing type and provider does this. It is not well-suited to
>>> call out to other non-standard ruby libraries because they need to be
>>> added as a dependency somehow, and doing this is not well-established in
>>> puppet. There are basically two options to do this:
>>>
>>>  1) Add a gem as a package resource and make sure the package resource
>>> is called before any of the openstack resources. I could see this
>>> working as an opt-in thing, but not as a default, for the same reason we
>>> don't require our users to install pip libraries - there is less
>>> security guarantees from pypi and rubygems than from distro 

Re: [openstack-dev] [puppet] Running Debian packages on top of Trusty

[Sofer Athlan-Guyot]

Thomas Goirand  writes:

> On 10/07/2015 12:22 PM, Sofer Athlan-Guyot wrote:
>> Hi,
>> 
>> On 2 Oct 2015, iberezovs...@mirantis.com wrote:
>> 
>>> Hello,
>>>
>>> thanks for bringing up this topic, that's what I wanted to discuss on
>>> next puppet-openstack irc meeting.
>>>
>>> So, user case is following: users may want to install Debian packages
>>> on Ubuntu host or vice versa,
>>> the same problem can probably happen with CentOS, RHEL, Fedora; or
>>> users may use non-official
>>> package repositories with their own package (service) naming strategy
>>> and so on.
>>> Current situation in puppet modules is following that package and
>>> service names are (let's say)
>>> hardcoded in 'params' class (e.g. [0]). But in situation that I've
>>> described it won't work.
>>> Puppet will try to use Ubuntu names on Ubuntu host and it won't allow
>>> to install and work with
>>> Debian packages.
>>>
>>> I've researched puppet modules and found an interesting example which
>>> can help to solve
>>> this issue. It's implemented in puppetlabs mongodb module:
>>> they have 'globals' class [1] that allows to override most part of
>>> parameters from 'params' class [2].
>>>
>>> So, I've decided to rework this soltuion and use it in OpenStack
>>> modules. As result I got draft patch
>>> for ceilometer module [3]. By default we use parameters from 'params'
>>> class, but every parameter
>>> can be now overridden using 'globals' class.
>>>
>>> OpenStack Puppet team, what do you think about this solution?
>> 
>> Here is another track that you may follow.  For instance, to have access
>> to the code variables there
>> https://github.com/openstack/puppet-nova/blob/master/manifests/params.pp#L100-L107
>> on an Ubuntu system you could just do this :
>> 
>> env FACTER_operatingsystem=Debian puppet agent -t 
>> 
>> You can override any facts on a system using the environment variable
>> "FACTER_"
>> 
>> For instance on my system:
>> 
>>   $ facter -p 2>/dev/null | grep osfamily
>>   osfamily => RedHat
>> 
>>   $ env FACTER_osfamily=Ubuntu facter -p 2>/dev/null | grep osfamily 
>>
>>   osfamily => Ubuntu
>> 
>> Is this method wouldn't be enough for your purpose ?
>>
>> Check https://puppetlabs.com/blog/facter-part-1-facter-101 for more
>> information.
>
> I'm not sure, as I'm not a puppet specialist...
>
> We don't want to overwrite the parameter about the distribution, because
> some are really dependent of the distro. For example, the libvirt unix
> group is libvirt in Debian, but libvirtd in Ubuntu. This difference has
> to stay depending on the OS type, which we absolutely do not want to
> overwrite. So we do want variables for the *OpenStack package type*
> which is running on top of the operating system.
>
> Will what you wrote above help in this regard?

Well, it seems it would do.  I check the package provider and it doesn't
really care if it's debian or ubuntu, as it checks osfamily.
Furthermore, In your example the user should be set by the package and
not by puppet.  Actually all parameters regarding puppet activity should
be encapsulated in the params file.

So my bet is that running the above would give you what you need.  Let
me know if it worked or if there are limitations in this solution that
makes the case for more code. 

[sorry for the very late reply]

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

-- 
Sofer Athlan-Guyot

__
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][Plugins] Plugin deployment questions

[Patrick Petit]

Hi Matthew,

That’s useful.
Thanks

On 20 Oct 2015 at 11:22:07, Matthew Mosesohn (mmoses...@mirantis.com) wrote:
Hi Patrick,

During the 7.0 development cycle we made a lot of enhancements to what 
environment characteristics can be modified through a plugin. One item that 
plugins cannot directly modify is the default Fuel roles and their metadata. 
That having been said, there is an open-ended post_install.sh script you can 
use for your plugin to "hack" this value. I know of one project that currently 
disables the requirement for controller role in a deployment. This may be 
helpful in testing a given standalone role that doesn't depend on a controller.

Here's a link to the script: http://paste.openstack.org/show/476821/
Note that this doesn't reflect "enabled" status of a plugin. It will make 
controller min count 0 for all environments. That won't break them, but it just 
removes the restriction.

Best Regards,
Matthew Mosesohn

On Mon, Oct 19, 2015 at 3:29 PM, Dmitry Mescheryakov 
 wrote:
Hello folks,

I second Patrick's idea. In our case we would like to install standalone 
RabbitMQ cluster with Fuel reference architecture to perform destructive tests 
on it. Requirement to install controller is an excessive burden in that case.

Thanks,

Dmitry

2015-10-19 13:44 GMT+03:00 Patrick Petit :
Hi There,

There are situations where we’d like to deploy only Fuel plugins in an 
environment.
That’s typically the case with Elasticsearch and InfluxDB plugins of LMA tools.
Currently it’s not possible because you need to at least have one controller.
What exactly is making that limitation? How hard would it be to have it removed?

Thanks
Patrick

__
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] [rally] Rally boot tests fails with Error Forbidden: It is not allowed to create an interface on external networks

[Yair Fried]

On Tue, Oct 20, 2015 at 2:06 PM, Behzad Dastur 
wrote:

> I have a contrail/OpenStack cloud deployed on which I am trying to run
> some rally benchmarks. But I am having trouble getting the rally boot tests
> to run. It throws the "Error Forbidden: It is not allowed to create an
> interface on external network"
>
> It seems it is trying to create an interface on the external network,
> however in this case that operation is not required as the contrail plugin
> handles that.
>
What version of Rally are you using?
Could you please provide your task file? Looks like you are explicitly
telling rally to use your external network for the VMs.


>  Is there a way to tell the rally scenario to avoid doing that. SImply
> put the operations that need to happen are:
>
> 1. nova boot (create private network/ or use private network provided)
>
The "network" context should allow you to dynamically create the networks.
Also, all scenarios that boot an instance can propagate boot arguments even
if they aren't explicitly listed (for more details try "$ rally plugin info
"), so you should be able to pass "{networks: {uuid: }}"
to the scenario.

2. neutron floating ip create, and assign it to the port eg (neutron
> floatingip-create --port-id   id="">)
>
Only in VMTask AFAIK.


> Here is the error log:
>
> 2015-10-20 00:24:12.759 19075 INFO 
> rally.plugins.openstack.context.keystone.users [-] Task 3000fcbd-2762-400d
> -920f-dfbfb667e7ec | Starting:  Enter context: `users`2015-10-20 00:24:14.711 
> 19075 INFO rally.plugins.openstack.context.keystone.users [-] Task 
> 3000fcbd-2762-400d-920f-dfbfb667e7ec | Completed: Enter context: 
> `users`2015-10-20 00:24:16.222 19264 INFO rally.task.runner [-] Task 
> 3000fcbd-2762-400d-920f-dfbfb667e7ec | ITER: 0 START2015-10-20 00:24:16.227 
> 19264 INFO rally.task.runner [-] Task 3000fcbd-2762-400d-920f-dfbfb667e7ec | 
> ITER: 1 START2015-10-20 00:24:18.420 19264 INFO rally.task.runner [-] Task 
> 3000fcbd-2762-400d-920f-dfbfb667e7ec | ITER: 0 END: Error Forbidden: It is 
> not allowed to create an interface on external network 
> 2de28d39-34f9-48c5-bbac-609e258b7aad (HTTP 403) (Request-ID: 
> req-fe32bcf8-f624-4a2d-a083-7b6c5d1f24ab)
>
>
> regards,
> Behzad
>
> __
> 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] [Heat] core team nomination

[Manickam, Kanagaraj]

+1 to both Rabi Mishra  & Peter Razumovsky. 

-Kanagaraj M

-Original Message-
From: Sergey Kraynev [mailto:skray...@mirantis.com] 
Sent: Tuesday, October 20, 2015 7:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Heat] core team nomination

I'd like to propose new candidates for heat core-team:
Rabi Mishra
Peter Razumovsky

According statistic both candidate made a big effort in Heat as reviewers and 
as contributors [1][2].
They were involved in Heat community work  during last several releases and 
showed good understanding of Heat code.
I think, that they are ready to became core-reviewers.

Heat-cores, please vote with +/- 1.

[1] http://stackalytics.com/report/contribution/heat-group/180
[2] http://stackalytics.com/?module=heat-group=person-day
--
Regards,
Sergey.

__
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] [kolla][announce] Kolla Liberty Release Announcement

[Steven Dake (stdake)]

Hello OpenStackers!


The Kolla community is pleased to announce the release of the Kolla Liberty.  
This release fixes 432 bugs and implements 58 blueprints!


During Liberty, Kolla joined the big tent governance!  Our project can be found 
here:


http://governance.openstack.org/reference/projects/index.html


Kolla is an opinionated OpenStack deployment system unless the operator has 
opinions!  Kolla is completely customizable but comes with consumable out of 
the box defaults for use with Ansible deployment.  To understand the Kolla 
community's philosophy towards deployment, please read:


http://docs.openstack.org/developer/kolla/customize-deployment.html


Kolla includes the following features:

  *   AIO and multinode deployment using Ansible with n-way active high 
availability.
  *   Vastly improved documentation.
  *   Tools to build Docker images and deploy OpenStack via Ansible in Docker 
containers.
  *   Build containers for CentOS, Oracle Linux, RHEL, and Ubuntu distributions.
  *   Build containers from both binary packaging and directly from source.
  *   Development environments using Heat, Vagrant, or bare-metal.
  *   All "core" OpenStack services implemented as micro-services in Docker 
containers.
  *   Minimal host deployment dependencies requiring only docker-engine and 
docker-py.


The following services can be deployed via Ansible in 12 to 15 minutes with 3 
node high availability:

  *   ceph for glance, nova, cinder
  *   cinder (only ceph is implemented as a backend at this time)
  *   glance
  *   haproxy
  *   heat
  *   horizon
  *   ironic (tech preview)
  *   keystone
  *   mariadb with galera replication
  *   memcached
  *   murano
  *   neutron
  *   nova
  *   rabbitmq
  *   swift


Kolla's implementation is stable and the core reviewers feel Kolla is ready for 
evaluation by operators and third party projects.  We strongly encourage people 
to evaluate the included Ansible deployment tooling and are keen for additional 
feedback.




Regards,

Steven Dake (Kolla PTL) on behalf of the Kolla Community


__
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][heat] Which repo to use in docs -- git.openstack.org or github.com?

[Jeremy Stanley]

On 2015-10-20 13:20:34 -0500 (-0500), Dolph Mathews wrote:
[...]
> +1 I would never direct anyone new straight to git.openstack.org because it
> makes a poor first impression relative to github.com. I assume that's the
> reason why we keep github.com as a mirror at all (?).

Directing someone to a proprietary/non-open service seems like a far
worse impression to me.

We did look into a mechanism to auto-render README pages on the fly
in cgit, but any reasonably trivial implementation with its filter
mechanism made it hard to get to the non-rendered version of the
document. Ultimately we determined that putting work into making it
easier to render and publish documentation was a far better use of
our time than trying to turn a code browser into a documentation
viewer.

So if the question is whether to point people at git.openstack.org
or github.com as a homepage for a project, my recommendation is:
neither. Link them to your published documentation (and make sure it
includes information on where to browse and clone your source
code!).
-- 
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

Re: [openstack-dev] [infra][all] Reviews with a prio label?

[Sean Dague]

On 10/20/2015 12:43 PM, Dolph Mathews wrote:
> This is actually something I've thought a lot about (focusing the
> community's review efforts), and have experimented with various
> solutions in the keystone community. I've built external solutions that
> have worked fairly well, but my current preference is to take advantage
> of what's already built into gerrit: starred reviews and dashboards.
> 
> For example, here is a dashboard of reviews in the keystone ecosystem
> starred by any member of keystone-core that *you* have not reviewed
> yourself (so you'll need to be logged into gerrit for this link to work):
> 
>   http://bit.ly/1GnOuqw [1]
> 
> In other words, it's a personalized review queue of things keystone-core
> deems important.
> 
> The advantage I see to this approach over a new label is that the star
> feature is already in the gerrit UI and so people already use it. But
> broadly speaking, I'm not aware of anyone utilizing that data today as a
> crowd sourced data point.

The rally team uses it as part of their dashboard -
https://github.com/stackforge/gerrit-dash-creator/blob/4d597f3b9c62f4422e3f8cdcd3b9c96921faa155/dashboards/rally.dash#L6-L7

> If you'd like to create your own version of this dashboard, here's the
> gerrit-dash-creator config file for this dashboard:
> 
>   https://github.com/dolph/dotfiles/blob/master/gerrit-dashboard-keystone
> 
> To customize it for yourself, you'd pretty much only need to edit the
> [dashboard] section, and specifically the "foreach" value to reflect the
> right collection of projects and group of reviewers. After that it's a
> matter of using gerrit-dash-creator to produce the link:
> 
>   https://github.com/openstack/gerrit-dash-creator
> 
> I'd love to take this a couple steps further if people find the approach
> valuable. I'd like to regularly recreate these links for every project
> based on the latest *-core membership, and the latest set of projects in
> a given community, publish them to permalinks, and share those
> permalinks with code reviewers.

One of the challenges you run into is url length limits in browsers,
given that we're encoding the whole thing in the url.

I do think the overall approach has a lot of merrit, though it would
still be awesome if there was a more baked in tagging in gerrit.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [rally] Rally boot tests fails with Error Forbidden: It is not allowed to create an interface on external networks

[Behzad Dastur]

Hi Yair,
The rally version I am using is 0.1.2

> rally --version
0.1.2

Also the task file is as shown below. Do you have an example of the
"network" context to skip creation on the interface on the xternal network?

vagrant@rally:~/rally$ more /vagrant/boot.json

{% set flavor_name = flavor_name or "m1.tiny" %}

{

"NovaServers.boot_server": [

{

"args": {

"flavor": {

"name": "{{flavor_name}}"

},

"image": {

"name": "cirros-0.3.1-x86_64"

},

"use_floatingip": false

},

"runner": {

"type": "constant",

"times": 10,

"concurrency": 2

},

"context": {

"users": {

"tenants": 3,

"users_per_tenant": 2

}

}

}

]

}

regards,
Behzad

Date: Tue, 20 Oct 2015 15:04:46 +0300
From: Yair Fried 
To: "OpenStack Development Mailing List (not for usage questions)"

Subject: Re: [openstack-dev] [rally] Rally boot tests fails with Error
Forbidden: It is not allowed to create an interface on external
networks
Message-ID:

Re: [openstack-dev] [infra][all] Reviews with a prio label?

[Zaro]

Upstream Gerrit has been working on a tagging feature for a while now.
Take a look at the gerrit discussion thread[1] if you want more info
on how it came about.   They decided to call it 'hashtag' or '#' (the
name being very controversial).Looks like some of the feature is
in Gerrit 2.11 already[2] but it's definitely still work in progress
with sparse documentation thus far.  I believe it should be fully
available in the 2.12 release and you can track it with
topic:hashtag[3] on upstream.

[1] https://groups.google.com/d/msg/repo-discuss/-dHTaWt_LJA/JwUGeCPDpTUJ
 and  https://groups.google.com/d/msg/repo-discuss/jZ0raMyuiG0/YlntREKG0FgJ
[2] 
https://review-dev.openstack.org/Documentation/config-hooks.html#_hashtags_changed
[3] https://gerrit-review.googlesource.com/#/q/topic:hashtags


On Tue, Oct 20, 2015 at 9:40 AM, Markus Zoeller  wrote:
> "Daniel P. Berrange"  wrote on 10/20/2015 06:21:05
> PM:
>
>> From: "Daniel P. Berrange" 
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: 10/20/2015 06:21 PM
>> Subject: Re: [openstack-dev] [infra][all] Reviews with a prio label?
>> What you're describing is really just a special-case of allowing
>> arbitrary user tagging of changes. If gerrit had a free-format
>> keyword tag facility that users could use & query, it'd open up many
>> possible options for improving our general workflow, and letting
>> users customize their own workflow.
>>
>> Regards,
>> Daniel
>
> True. My proposal is indeed a poor man's way of tagging. My research,
> if Gerrit provides such a feature, didn't bring up any results.
>
> Regards, Markus Zoeller (markus_z)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [cinder] Specifications to support High Availability Active-Active configurations in Cinder

[Gorka Eguileor]

Hi,

We finally have ready for review all specifications required to support
High Availability Active/Active configurations in Cinder's Volume nodes.

There is a Blueprint to track this effort [1] and the specs are as follow:

- General description of the issues and solutions [2]
- Removal of Races on API nodes [3]
- Job distribution to clusters [4]
- Cleanup process of crashed nodes [5]
- Data corruption prevention [6]
- Removing local file locks from the manager [7]
- Removing local file locks from drivers [8]

The only effort that is in progress is the removal of code races on the
API nodes that has a series of patches but still needs reviewing and
more races need to be removed from the code.

I think it would be very beneficial for everyone if these patches were
reviewed before the Summit Sessions related to this topic, as it is a
complicated matter with many moving pieces and a good knowledge of the
topic will be essential to have productive sessions in Tokyo.

While I believe this is a viable path to implement HA A/A in Cinder,
these specifications can also be useful to anyone looking for other
solutions as it gives a detailed description of the problem as well as a
good number of cases that any proper solution needs to be able to
handle.

Alternatives to any of the issues are more than welcome, preferably
simpler ones, but they need to be well thought and must:

a) Take into account all cases of the issue that are trying to fix.

b) Play well with the other individual solutions as to give a reliable
global solution.

Cheers,
Gorka.


[1]: 
https://blueprints.launchpad.net/cinder/+spec/cinder-volume-active-active-support
[2]: https://review.openstack.org/232599
[3]: https://review.openstack.org/207101
[4]: https://review.openstack.org/232595
[5]: https://review.openstack.org/236977
[6]: https://review.openstack.org/237076
[7]: https://review.openstack.org/237602
[8]: https://review.openstack.org/237604

__
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] [NFV][Telco] Meeting canceled

[Steve Gordon]

Hi all,

No Telco Working Group meeting Wednesday October 20th due to proximity to the 
F2F in Tokyo and the lack of items to discuss. See you all next Tuesday!

Thanks,

Steve

__
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] [stable] Need group membership change for manila-stable-maint

[Ben Swartzlander]

On 10/20/2015 11:19 AM, Matthew Treinish wrote:

On Tue, Oct 20, 2015 at 11:16:38AM -0400, Doug Hellmann wrote:


Ah, right, I always forget those are a special case, thanks.

So, what *is* the process, for adding someone to the stable maintenance
team? :-)

https://wiki.openstack.org/wiki/StableBranch#Project-specific_teams

I feel like this topic comes up fairly regularly. Personally I'm not a fan of
the current policy and feel like we should not force project stable group
changes to go through stable-maint-core. But, that'll likely be a topic at
summit next week.

-Matt Treinish



After reading the wiki it sounds like we cannot simply add the core team 
as an included group. I would need to request each core team member be 
added individually. Should I make requests for the individuals? Or 
should I wait until after Tokyo when some newer better process may 
emerge for managing the group membership?


My stance is that I want all of the manila core team to be stable 
maintainers too. Having 2 groups is unnecessary bureaucracy. However I'm 
willing to follow the established process if it's working well for 
everyone else.


-Ben Swartzlander



__
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][heat] Which repo to use in docs -- git.openstack.org or github.com?

[Dolph Mathews]

On Tue, Oct 20, 2015 at 12:20 PM, Christopher Aedo  wrote:

> On Tue, Oct 20, 2015 at 3:43 AM, Andreas Jaeger  wrote:
> > On 2015-10-20 12:17, Qiming Teng wrote:
> >>
> >> Hi,
> >>
> >> Just encountered this again in code review [1]. The question is about
> >> the repository to point to when documenting things up. Between the
> >> following links, which one should we use?
> >>
> >> - https://git.openstack.org/cgit/openstack/sqlalchemy-migrate
> >> - https://github.com/openstack/sqlalchemy-migrate
> >>
> >> I had an impression that I saw something like 'use git.openstack.org
> >> instead of github.com because the later is just a mirror ...' but
> cannot
> >> find the link now. Maybe it is an illusion. :)
> >>
> >> So, seriously, any recommendations or guidelines?
> >
> >
> > Yes, git.openstack.org is our official server, github is just a
> read-only
> > mirror.
> >
> > Linking to github might also raise the expectation that we use the usual
> > github workflow which is not the case,
>
> I understand github is a read-only mirror and we don't want casual
> visitors to expect the github workflow - so in most cases I agree
> people should be pointed to our official server.
>
> On the other hand, the fact that github renders the README nicely
> (including images) leads to a much more inviting first impression.
> For example, for the uninitiated, this git.openstack.org URL[2]
> doesn't help at all if you are curious about the project, while the
> github.com URL[3] tells you what the project is about and even
> includes a few screenshots.  For purposes of learning about or
> understanding OpenStack I would say the github.com URL is vastly
> superior.
>

+1 I would never direct anyone new straight to git.openstack.org because it
makes a poor first impression relative to github.com. I assume that's the
reason why we keep github.com as a mirror at all (?).


>
> Is it crazy to suggest we do something similar with our github server?
>
> -Christopher
>
> [2]: http://git.openstack.org/cgit/openstack/app-catalog-ui/
> [3]: https://github.com/openstack/app-catalog-ui
>
> >
> > Andreas
> >
> >> [1] https://review.openstack.org/#/c/237404/
>
> __
> 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] [NFV][Telco] Meeting canceled

[Steve Gordon]

- Original Message -
> From: "Steve Gordon" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> ,
> 
> Hi all,
> 
> No Telco Working Group meeting Wednesday October 20th due to proximity to the

Obviously I meant 21st, apologies!

-Steve

> F2F in Tokyo and the lack of items to discuss. See you all next Tuesday!
> 
> Thanks,
> 
> Steve

__
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] [puppet] no meeting next week

[Emilien Macchi]

Most of our group will be in Tokyo for the OpenStack Summit:
https://etherpad.openstack.org/p/HND-puppet

We won't do our weekly meeting.
-- 
Emilien Macchi



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] [Congress] Congress and Monasca Joint Session at Tokyo Design Summit

[Fabio Giannetti (fgiannet)]

Tim,
  Yes, sorry I have been with my head down on finishing things for the summit.
It works. Thanks for setting it up.
Fabio
[http://www.cisco.com/c/dam/assets/email-signature-tool/logo_06.png?ct=1430182397611]

Fabio Giannetti
Cloud Innovation Architect
Cisco Services
fgian...@cisco.com
Phone: +1 408 527 1134
Mobile: +1 408 854 0020


Cisco Systems, Inc.
285 W. Tasman Drive
San Jose
California
95134
United States
Cisco.com





[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] Think before you 
print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.

Please click 
here for 
Company Registration Information.



From: Tim Hinrichs >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, October 19, 2015 at 8:11 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Congress] Congress and Monasca Joint Session at 
Tokyo Design Summit

Fabio,

I haven't heard back on this so I'm assuming Wed 3:40-4:20 works for you.

Tim


On Wed, Oct 14, 2015 at 10:51 AM Tim Hinrichs 
> wrote:
Hi Fabio,

We now have a schedule.  I've tentatively booked you for half of our slot Wed 
3:40-4:20.  Does that work for your team?  You can find the other options at...

https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Congress

Tim


On Thu, Oct 1, 2015 at 2:06 PM Fabio Giannetti (fgiannet) 
> wrote:
Thanks a lot Tim.
I really appreciate.
Fabio

From: Tim Hinrichs >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, October 1, 2015 at 7:40 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Congress] Congress and Monasca Joint Session at 
Tokyo Design Summit

Hi Fabio,

The Congress team talked this over during our IRC yesterday.  It looks like can 
meet with your team during one of our meeting slots.  As far as I know the 
schedule for those meetings hasn't been set.  But once it is I'll reach out (or 
you can) to discuss the day/time.

Tim

On Mon, Sep 28, 2015 at 2:51 PM Tim Hinrichs 
> wrote:

Hi Fabio: Thanks for reaching out.  We should definitely talk at the summit.  I 
don't know if we can devote 1 of the 3 allocated Congress sessions to Monasca, 
but we'll talk it over during IRC on Wed and let you know.  Or do you have a 
session we could use for the discussion?  In any case, I'm confident we can 
make good progress toward integrating Congress and Monasca in Tokyo.  Monasca 
sounds interesting--I'm looking forward to learning more!

Congress team: if we could all quickly browse the Monasca wiki before Wed's 
IRC, that would be great:
https://wiki.openstack.org/wiki/Monasca

Tim



On Mon, Sep 28, 2015 at 1:50 PM Fabio Giannetti (fgiannet) 
> wrote:
Tim and Congress folks,
  I am writing on behalf of the Monasca community and I would like to explore 
the possibility of holding a joint session during the Tokyo Design Summit.
We would like to explore:

  1.  how to integrate Monasca with Congress so then Monasca can provide 
metrics, logs and event data for policy evaluation/enforcement
  2.  How to leverage Monasca alarming to automatically notify about statuses 
that may imply policy breach
  3.  How to automatically (if possible) convert policies (or subparts) into 
Monasca alarms.

Please point me to a submission page if I have to create a formal proposal for 
the topic and/or let me know other forms we can interact at the Summit.
Thanks in advance,
Fabio

[http://www.cisco.com/c/dam/assets/email-signature-tool/logo_06.png?ct=1430182397611]

Fabio Giannetti
Cloud Innovation Architect
Cisco Services
fgian...@cisco.com
Phone: +1 408 527 1134
Mobile: +1 408 854 0020


Cisco Systems, Inc.
285 W. Tasman Drive
San Jose
California
95134
United States
Cisco.com





[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] Think before you 
print.

This email may contain confidential and privileged material for the sole use of 

Re: [openstack-dev] [Heat] core team nomination

[Pavlo Shchelokovskyy]

+1 for both!

On Tue, Oct 20, 2015 at 6:14 PM Thomas Herve  wrote:

> +1!
>
> --
> Thomas
>
> On Tue, Oct 20, 2015 at 3:38 PM, Sergey Kraynev 
> wrote:
>
>> I'd like to propose new candidates for heat core-team:
>> Rabi Mishra
>> Peter Razumovsky
>>
>> According statistic both candidate made a big effort in Heat as
>> reviewers and as contributors [1][2].
>> They were involved in Heat community work  during last several releases
>> and
>> showed good understanding of Heat code.
>> I think, that they are ready to became core-reviewers.
>>
>> Heat-cores, please vote with +/- 1.
>>
>> [1] http://stackalytics.com/report/contribution/heat-group/180
>> [2] http://stackalytics.com/?module=heat-group=person-day
>> --
>> Regards,
>> Sergey.
>>
>> __
>> 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
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.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] [Ceilometer] "Infinite" values for "sum" and "average" fields in statistics query

[Srikanth Vavilapalli]

Hi

I am using MongoDB backend.

Thanks
Srikanth

-Original Message-
From: gord chung [mailto:g...@live.ca] 
Sent: Tuesday, October 20, 2015 9:20 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ceilometer] "Infinite" values for "sum" and 
"average" fields in statistics query

which backend are you using? this potentially may be a bug where we're hitting 
some size limit restricted by datatype.

On 19/10/2015 4:02 PM, Srikanth Vavilapalli wrote:
> Hi
>
> I have observed "inf" values for "sum" and "average" fields in a ceilometer 
> statistics query on one of my custom meter as shown below. I have also 
> verified the samples query for this meter and there are 1544 samples (output 
> shown below) with all of them having value as "150.0". So ideally the "Avg" 
> filed should be "150.0" in this scenario. Could anyone tell me in what 
> scenario we will see these two fields as "inf" in the meter statistics query? 
> Plz let me know if you need more details or logs here. Appreciate your help.
>
> Thanks
> Srikanth
>
>
> svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer 
> statistics --meter=vcpe.dns.cache.size
> ++++---+---+-+-+---++++
> | Period | Period Start   | Period End | Max   | 
> Min   | Avg | Sum | Count | Duration   | Duration Start | 
> Duration End   |
> ++++---+---+-+-+---++++
> | 0  | 2015-10-17T01:30:24.999000 | 2015-10-19T17:47:20.587000 | 150.0 | 
> 150.0 | inf | inf | 1544  | 231415.588 | 2015-10-17T01:30:24.999000 | 
> 2015-10-19T17:47:20.587000 |
> ++++---+---+-+-+---++++
>
>
> svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer 
> sample-list --meter=vcpe.dns.cache.size
> +-+-+---++-++
> | Resource ID | Name| Type  | Volume | Unit| Timestamp
>   |
> +-+-+---++-++
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-19T17:47:20.587000 |
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-19T17:47:00.048000 |
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-19T17:42:20.47 |
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-19T17:41:59.921000 |
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-19T17:37:20.362000 |
> .
> .
> .
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-17T01:50:25.499000 |
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-17T01:45:46.255000 |
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-17T01:45:25.374000 |
> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
> 2015-10-17T01:40:46.131000 |
>
> __
>  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

--
gord


__
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] fuelmenu code freeze

[Igor Kalnitsky]

Hey Vladimir,

That's awesome news. I blocked all fuelmenu patches [1] with a link to
this thread. So don't worry, we won't merge them accidentally.

BTW, could you provide any ETA when moving will be done?

[1] 
https://review.openstack.org/#/q/project:openstack/fuel-web+file:%255Efuelmenu.*+status:open,n,z

Thanks,
Igor

On Tue, Oct 20, 2015 at 5:58 PM, Vladimir Kozhukalov
 wrote:
> Dear colleagues,
>
> As you might know I'm working on splitting multiproject fuel-web repository
> into several sub-projects. Fuelmenu is one of directories that are to be
> moved to a separate git project.
>
> Checklist for this to happen is as follows:
>
> Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1506885
> project-config patch https://review.openstack.org/#/c/235177 (ON REVIEW
> WORKFLOW -1)
> pypi project https://pypi.python.org/pypi?%3Aaction=pkg_edit=Fuel-menu
> (DONE)
> run_tests.sh https://review.openstack.org/#/c/235243/ (DONE)
> rpm/deb specs https://review.openstack.org/#/c/235273/ (DONE)
> fuel-ci verification jobs https://review.fuel-infra.org/12865 (ON REVIEW)
> label jenkins slaves for verification jobs (ci team)
> directory freeze (WE ARE HERE)
> prepare upstream (TODO)
> project-config (ON REVIEW)
> fuel-main patch (TODO)
> packaging-ci patch (TODO)
> deprecate fuel-web/fuelmenu directory (TODO)
>
> Now we are at the point where we need to freeze fuel-web/fuelmenu directory.
> So, I'd like to announce code freeze for this directory and all patches that
> make changes in the directory and are currently on review will need to be
> backported to the new git repository.
>
>
> 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
>

__
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][all] Reviews with a prio label?

[Dolph Mathews]

This is actually something I've thought a lot about (focusing the
community's review efforts), and have experimented with various solutions
in the keystone community. I've built external solutions that have worked
fairly well, but my current preference is to take advantage of what's
already built into gerrit: starred reviews and dashboards.

For example, here is a dashboard of reviews in the keystone ecosystem
starred by any member of keystone-core that *you* have not reviewed
yourself (so you'll need to be logged into gerrit for this link to work):

  http://bit.ly/1GnOuqw [1]

In other words, it's a personalized review queue of things keystone-core
deems important.

The advantage I see to this approach over a new label is that the star
feature is already in the gerrit UI and so people already use it. But
broadly speaking, I'm not aware of anyone utilizing that data today as a
crowd sourced data point.

If you'd like to create your own version of this dashboard, here's the
gerrit-dash-creator config file for this dashboard:

  https://github.com/dolph/dotfiles/blob/master/gerrit-dashboard-keystone

To customize it for yourself, you'd pretty much only need to edit the
[dashboard] section, and specifically the "foreach" value to reflect the
right collection of projects and group of reviewers. After that it's a
matter of using gerrit-dash-creator to produce the link:

  https://github.com/openstack/gerrit-dash-creator

I'd love to take this a couple steps further if people find the approach
valuable. I'd like to regularly recreate these links for every project
based on the latest *-core membership, and the latest set of projects in a
given community, publish them to permalinks, and share those permalinks
with code reviewers.

[1] unshortened
h*ttps://review.openstack.org/#/dashboard/?foreach=is%3Aopen+%252Downer%3Aself+%28project%3Aopenstack%252Dattic%2Fidentity%252Dapi+OR+project%3Aopenstack%2Fkeystone+OR+project%3Aopenstack%2Fkeystone%252Dspecs+OR+project%3Aopenstack%2Fkeystoneauth+OR+project%3Aopenstack%2Fkeystoneauth%252Dsaml2+OR+project%3Aopenstack%2Fkeystonemiddleware+OR+project%3Aopenstack%2Fpycadf+OR+project%3Aopenstack%2Fpython%252Dkeystoneclient%29+%28starredby%3Abknudson%40us.ibm.com+OR+starredby%3Adstanek%40dstanek.com+OR+starredby%3Adolph.mathews%40gmail.com+OR+starredby%3Ajamielennox%40redhat.com+OR+starredby%3Albragstad%40gmail.com+OR+starredby%3Aos.lcheng%40gmail.com+OR+starredby%3Amarek.denis%40cern.ch+OR+starredby%3Amorgan.fainberg%40gmail.com+OR+starredby%3Astevemar%40ca.ibm.com+OR+starredby%3Aayoung%40redhat.com+OR+starredby%3Aguang.yee%40hpe.com+OR+starredby%3Ahenryn%40linux.vnet.ibm.com%29=Priority+keystone+reviews+attention=%252Dlabel%3ACode%252DReview%3C%3D2%252cself+%252Dlabel%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0=%252Dlabel%3ACode%252DReview%3C%3D2+label%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0&%2B1=%252Dlabel%3ACode%252DReview%3C%3D%2B2%252cself+%252Dlabel%3ACode%252DReview%3C%3D%252D1+label%3ACode%252DReview%2B1+%252Dlabel%3ACode%252DReview%2B2+label%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0&%2B2=%252Dlabel%3ACode%252DReview%3C%3D%2B2%252cself+%252Dlabel%3ACode%252DReview%3C%3D%252D1+label%3ACode%252DReview%2B2+label%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0+gating=label%3AVerified%3D%2B1%252cjenkins+label%3AWorkflow%2B1=%252Dlabel%3AVerified%3C%3D%252D1%252cjenkins+%252Dlabel%3AVerified%3E%3D%2B1%252cjenkins+label%3AWorkflow%2B1+gating=label%3AVerified%3C%3D%252D1%252cjenkins+label%3AWorkflow%2B1

Re: [openstack-dev] [Heat] core team nomination

[Thomas Herve]

+1!

-- 
Thomas

On Tue, Oct 20, 2015 at 3:38 PM, Sergey Kraynev 
wrote:

> I'd like to propose new candidates for heat core-team:
> Rabi Mishra
> Peter Razumovsky
>
> According statistic both candidate made a big effort in Heat as
> reviewers and as contributors [1][2].
> They were involved in Heat community work  during last several releases and
> showed good understanding of Heat code.
> I think, that they are ready to became core-reviewers.
>
> Heat-cores, please vote with +/- 1.
>
> [1] http://stackalytics.com/report/contribution/heat-group/180
> [2] http://stackalytics.com/?module=heat-group=person-day
> --
> Regards,
> Sergey.
>
> __
> 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] fuelmenu code freeze

[Vladimir Kozhukalov]

Igor,

Thank you for your help. I'd say ETA is today/tomorrow and depends on how
quickly this project-config patch [1] will be reviewed and merged. I'll ask
openstack-infra guys to do this ASAP.

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

Vladimir Kozhukalov

On Tue, Oct 20, 2015 at 6:39 PM, Igor Kalnitsky 
wrote:

> Hey Vladimir,
>
> That's awesome news. I blocked all fuelmenu patches [1] with a link to
> this thread. So don't worry, we won't merge them accidentally.
>
> BTW, could you provide any ETA when moving will be done?
>
> [1]
> https://review.openstack.org/#/q/project:openstack/fuel-web+file:%255Efuelmenu.*+status:open,n,z
>
> Thanks,
> Igor
>
> On Tue, Oct 20, 2015 at 5:58 PM, Vladimir Kozhukalov
>  wrote:
> > Dear colleagues,
> >
> > As you might know I'm working on splitting multiproject fuel-web
> repository
> > into several sub-projects. Fuelmenu is one of directories that are to be
> > moved to a separate git project.
> >
> > Checklist for this to happen is as follows:
> >
> > Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1506885
> > project-config patch https://review.openstack.org/#/c/235177 (ON REVIEW
> > WORKFLOW -1)
> > pypi project
> https://pypi.python.org/pypi?%3Aaction=pkg_edit=Fuel-menu
> > (DONE)
> > run_tests.sh https://review.openstack.org/#/c/235243/ (DONE)
> > rpm/deb specs https://review.openstack.org/#/c/235273/ (DONE)
> > fuel-ci verification jobs https://review.fuel-infra.org/12865 (ON
> REVIEW)
> > label jenkins slaves for verification jobs (ci team)
> > directory freeze (WE ARE HERE)
> > prepare upstream (TODO)
> > project-config (ON REVIEW)
> > fuel-main patch (TODO)
> > packaging-ci patch (TODO)
> > deprecate fuel-web/fuelmenu directory (TODO)
> >
> > Now we are at the point where we need to freeze fuel-web/fuelmenu
> directory.
> > So, I'd like to announce code freeze for this directory and all patches
> that
> > make changes in the directory and are currently on review will need to be
> > backported to the new git repository.
> >
> >
> > 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
> >
>
> __
> 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] [kolla] Liberty release builds

[Paul Bourke]

Kolla core team,

Here's a link to an etherpad created just now for deciding the process 
on getting release builds to dockerhub:


https://etherpad.openstack.org/p/kolla-release-builds

Please review and revise. Steve, can you follow up to this mail when 
you'd like volunteers to kick off builds?


Cheers,
-Paul

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

Re: [openstack-dev] [Tacker] Proposing Bob Haddleton to core team

[Sridhar Ramaswamy]

Enough time has passed.

Bob - welcome to the tacker-core team!

- Sridhar

On Thu, Oct 15, 2015 at 10:31 AM, Vishwanath Jayaraman 
wrote:

> +1
>
> __
> 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][heat] Which repo to use in docs -- git.openstack.org or github.com?

[Christopher Aedo]

On Tue, Oct 20, 2015 at 3:43 AM, Andreas Jaeger  wrote:
> On 2015-10-20 12:17, Qiming Teng wrote:
>>
>> Hi,
>>
>> Just encountered this again in code review [1]. The question is about
>> the repository to point to when documenting things up. Between the
>> following links, which one should we use?
>>
>> - https://git.openstack.org/cgit/openstack/sqlalchemy-migrate
>> - https://github.com/openstack/sqlalchemy-migrate
>>
>> I had an impression that I saw something like 'use git.openstack.org
>> instead of github.com because the later is just a mirror ...' but cannot
>> find the link now. Maybe it is an illusion. :)
>>
>> So, seriously, any recommendations or guidelines?
>
>
> Yes, git.openstack.org is our official server, github is just a read-only
> mirror.
>
> Linking to github might also raise the expectation that we use the usual
> github workflow which is not the case,

I understand github is a read-only mirror and we don't want casual
visitors to expect the github workflow - so in most cases I agree
people should be pointed to our official server.

On the other hand, the fact that github renders the README nicely
(including images) leads to a much more inviting first impression.
For example, for the uninitiated, this git.openstack.org URL[2]
doesn't help at all if you are curious about the project, while the
github.com URL[3] tells you what the project is about and even
includes a few screenshots.  For purposes of learning about or
understanding OpenStack I would say the github.com URL is vastly
superior.

Is it crazy to suggest we do something similar with our github server?

-Christopher

[2]: http://git.openstack.org/cgit/openstack/app-catalog-ui/
[3]: https://github.com/openstack/app-catalog-ui

>
> Andreas
>
>> [1] https://review.openstack.org/#/c/237404/

__
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] [stable] Need group membership change for manila-stable-maint

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2015-10-20 13:41:05 +:
> On 2015-10-20 09:31:52 -0400 (-0400), Doug Hellmann wrote:
> > Excerpts from Ben Swartzlander's message of 2015-10-19 21:02:46 -0400:
> > > I would like the manila-core group added as an included group in 
> > > manila-stable-maint. I'm not sure what the right procedure is so I'm 
> > > asking here.
> [...]
> > Most gerrit groups are self-service by the members. Since you're a
> > member of manila-stable-maint, you should be able to visit the group
> > page in gerrit by clicking "People" in the top nav bar, selecting "List
> > Groups" then typing "manila-sstable-maint" in the filter box. Click the
> > "manilia-stable-maint" entry in the resulting list to get to [1].
> [...]
> 
> Infra recommended he request this here on the ML, since as with most
> of the per-project .*-stable-maint groups, manila-stable-maint is
> not self-owned but is rather under the care of the stable-maint-core
> group. https://review.openstack.org/#/admin/groups/1099,info

Ah, right, I always forget those are a special case, thanks.

So, what *is* the process, for adding someone to the stable maintenance
team? :-)

Doug

__
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] [stable] Need group membership change for manila-stable-maint

[Matthew Treinish]

On Tue, Oct 20, 2015 at 11:16:38AM -0400, Doug Hellmann wrote:
> Excerpts from Jeremy Stanley's message of 2015-10-20 13:41:05 +:
> > On 2015-10-20 09:31:52 -0400 (-0400), Doug Hellmann wrote:
> > > Excerpts from Ben Swartzlander's message of 2015-10-19 21:02:46 -0400:
> > > > I would like the manila-core group added as an included group in 
> > > > manila-stable-maint. I'm not sure what the right procedure is so I'm 
> > > > asking here.
> > [...]
> > > Most gerrit groups are self-service by the members. Since you're a
> > > member of manila-stable-maint, you should be able to visit the group
> > > page in gerrit by clicking "People" in the top nav bar, selecting "List
> > > Groups" then typing "manila-sstable-maint" in the filter box. Click the
> > > "manilia-stable-maint" entry in the resulting list to get to [1].
> > [...]
> > 
> > Infra recommended he request this here on the ML, since as with most
> > of the per-project .*-stable-maint groups, manila-stable-maint is
> > not self-owned but is rather under the care of the stable-maint-core
> > group. https://review.openstack.org/#/admin/groups/1099,info
> 
> Ah, right, I always forget those are a special case, thanks.
> 
> So, what *is* the process, for adding someone to the stable maintenance
> team? :-)

https://wiki.openstack.org/wiki/StableBranch#Project-specific_teams

I feel like this topic comes up fairly regularly. Personally I'm not a fan of
the current policy and feel like we should not force project stable group
changes to go through stable-maint-core. But, that'll likely be a topic at
summit next week.

-Matt Treinish


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] [Fuel][Plugins][Ironic] Deploy Ironic with fuel ?

[Pavlo Shchelokovskyy]

Hi Loic,

the story of this plugin is a bit complicated. We've done it as PoC of
integrating Ironic into Mirantis OpenStack/Fuel during 7.0 release.
Currently we are working on integrating Ironic into core of Fuel targeting
its 8.0 release. Given that, the plugin is not official in any sense, is
not certified according to Fuel plugins guidelines, is not supported at all
and has had only limited testing on a small in-house lab.

To successfully deploy Ironic with this plugin "as-is" you'd most probably
need access to Mirantis package repositories as it relies on some patches
to fuel-agent that we use for bootstrapping, and some of those are not
merged yet, so we use repos created by our CI from Gerrit changes. Probably
though you can hack on the code and disable such dependencies/building and
uploading the custom bootstrap image, activate clear upstream Ironic
drivers and then use upstream images with e.g. ironic-python-agent for
bootstrapping baremetal nodes.

As to your network setup question - the baremetal network is somewhat
similar to the public network in Fuel, which needs two ip ranges defined,
one for service nodes, and the other for actual VMs to assign as floating
ips. Thus networking setup for the plugin should be done as follows (naming
it "baremetal" is mandatory):

fuel network-group --name baremetal --cidr 192.168.3.0/24 -c --nodegroup 1
--meta='{ip_range: ["192.168.3.2", "192.168.3.50"], notation: "ip_ranges"}'

where the ip range (I've put some example values) is for those service
OpenStack nodes that host Ironic services and need to have access to this
provider network where BM nodes do live (this range is then auto-filled to
network.baremetal section of Networking settings tab in Fuel UI). The range
for the actual BM nodes is defined then on the "Settings->Ironic" tab in
Fuel UI once Ironic checkbox there is activated.

I admit we do need to make some effort and document the plugin a bit better
(actually at all :) ) to not confuse people wishing to try it out.

Best regards,


> On Mon, Oct 19, 2015 at 6:45 AM,  wrote:
>
>> Hello,
>>
>>
>>
>> I’m currently searching for information about Ironic Fuel plugin :
>> https://github.com/openstack/fuel-plugin-ironic I don’t find any
>> documentation on it.
>>
>>
>>
>> I’ve tried to install and deploy an Openstack environment with Fuel 7.0
>> and Ironic plugin but it failed. After adding ironic role to a node Fuel UI
>> crashed, due to a missing network “baremetal” . When creating a network
>> group
>>
>>
>>
>> fuel network-group --create --node-group 1 --name \
>>
>> "baremetal" --cidr 192.168.3.0/24
>>
>> UI works again, but I got some errors in the deployment, during network
>> configuration. So I think I have to configure a network template, did
>> someone already do this for this plugin ?
>>
>>
>>
>> Regards,
>>
>>
>>
>> Loic
>>
>> _
>>
>> Ce message et ses pieces jointes peuvent contenir des informations 
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>> ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
>> falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged 
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and 
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been 
>> modified, changed or falsified.
>> Thank you.
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> --
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.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][Glance] Feedback on the proposed refactor to the image import process required

[Brian Rosmaita]

Hello,

I've updated the image import spec [4] to incorporate the discussion thus
far.

The fishbowl session [5] is scheduled for Thursday, October 29,
2:40pm-3:20pm.

If you read through the spec and the current discussion on the review,
you'll be in a good position to help us get this worked out during the
summit.

--
cheers,
brian 

On 10/9/15, 3:39 AM, "Flavio Percoco"  wrote:

>Greetings,
>
>There was recently a discussion[0] on the mailing list, started by Doug
>Hellman, to discuss some issues related to Glance's API, the conflicts
>between v1 and v2 and how this is making some pandas sad.
>
>The above served as a starting point for a discussion around the
>current API, how it can be improved, etc. This discussions happened on
>IRC[1], on  a call (sorry, I forgot to record this call, this is entirely
>my fault) and on an etherpad[2]. Later on, Brian Rosmaita summarized
>all this in a document[3], which became a spec[4]. :D
>
>The spec is the central point of discussion now and it contains a more
>structured, more organized and more concrete proposal that needs to be
>discussed. Nevertheless, I believe there's still lot to do there and I
>also believe - I'm sure others do as well - this spec could use
>opinions from a broader audience. Therefore, I'd really appreciate
>your opinion on this thread.
>
>This will also be discussed at the summit[5] in a fishbowl session and
>I hope to see you all there as well.
>
>I'd like to thank everyone that has participated in this discussion so
>far and I hope to see others chime in as well.
>
>Flavio
>
>[0] 
>http://lists.openstack.org/pipermail/openstack-dev/2015-September/074360.h
>tml
>[1] 
>http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23openstack-gl
>ance.2015-09-22.log.html#t2015-09-22T14:31:00
>[2] https://etherpad.openstack.org/p/glance-upload-mechanism-reloaded
>[3] 
>https://docs.google.com/document/d/1_mQZlUN_AtqhH6qh3ANz-m1zCOYkp1GyxndLtY
>MFRb0
>[4] https://review.openstack.org/#/c/232371/
>[5] 
>http://mitakadesignsummit.sched.org/event/398b1f44af7a4ae3dde9cb47d4d52d9a
>
>-- 
>@flaper87
>Flavio Percoco


__
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] Upgrade to Gerrit 2.11

[Markus Zoeller]

Alexis Lee  wrote on 10/20/2015 03:13:20 PM:

> From: Alexis Lee 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 10/20/2015 03:19 PM
> Subject: Re: [openstack-dev] [infra] Upgrade to Gerrit 2.11
> 
> Markus Zoeller said on Fri, Oct 16, 2015 at 03:33:37PM +0200:
> > > >Would it be possible to create a "prio" label to help sorting out 
> > stuff?
> 
> +1 to this!
> [...]
> 
> Alexis (lxsli)

To avoid a hijacking of this thread, here the new one where we
can discuss this:
http://lists.openstack.org/pipermail/openstack-dev/2015-October/077517.html

Regards, Markus Zoeller (markus_z)


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

Re: [openstack-dev] [Ceilometer] "Infinite" values for "sum" and "average" fields in statistics query

[gord chung]

which backend are you using? this potentially may be a bug where we're 
hitting some size limit restricted by datatype.


On 19/10/2015 4:02 PM, Srikanth Vavilapalli wrote:

Hi

I have observed "inf" values for "sum" and "average" fields in a ceilometer statistics query on one of my custom meter 
as shown below. I have also verified the samples query for this meter and there are 1544 samples (output shown below) with all of them having value 
as "150.0". So ideally the "Avg" filed should be "150.0" in this scenario. Could anyone tell me in what scenario we 
will see these two fields as "inf" in the meter statistics query? Plz let me know if you need more details or logs here. Appreciate your 
help.

Thanks
Srikanth


svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer statistics 
--meter=vcpe.dns.cache.size
++++---+---+-+-+---++++
| Period | Period Start   | Period End | Max   | 
Min   | Avg | Sum | Count | Duration   | Duration Start | Duration 
End   |
++++---+---+-+-+---++++
| 0  | 2015-10-17T01:30:24.999000 | 2015-10-19T17:47:20.587000 | 150.0 | 
150.0 | inf | inf | 1544  | 231415.588 | 2015-10-17T01:30:24.999000 | 
2015-10-19T17:47:20.587000 |
++++---+---+-+-+---++++


svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer 
sample-list --meter=vcpe.dns.cache.size
+-+-+---++-++
| Resource ID | Name| Type  | Volume | Unit| Timestamp  
|
+-+-+---++-++
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:47:20.587000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:47:00.048000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:42:20.47 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:41:59.921000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:37:20.362000 |
.
.
.
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:50:25.499000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:45:46.255000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:45:25.374000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:40:46.131000 |

__
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


--
gord


__
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] [TripleO] weekly TripleO meetings starting Nov. 3rd

[Dan Prince]

In today's IRC meeting we agreed that weekly TripleO meetings would
again be useful. So starting Nov. 3rd (the week after the Tokyo Summit)
we tentatively plan on resuming weekly meetings at 14:00 UTC on
Tuesdays.

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

Dan

__
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] network_checker code freeze

[Vladimir Kozhukalov]

Dear colleagues,

As you might know I'm working on splitting multiproject fuel-web repository
into several sub-projects. network_checker is one of directories that are
to be moved to a separate git project.

Checklist for this to happen is as follows:


   - Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1506896
   - project-config patch https://review.openstack.org/235822 (ON REVIEW)
   - pypi
   https://pypi.python.org/pypi?%3Aaction=pkg_edit=Network-checker
   (DONE)
   - run_tests.sh https://review.openstack.org/#/c/235829/ (DONE)
   - rpm/deb specs https://review.openstack.org/#/c/235966/ (DONE)
   - fuel-ci verification jobs https://review.fuel-infra.org/12923 (ON
   REVIEW)
   - label jenkins slaves for verification jobs (ci team)
   - directory freeze (WE ARE HERE)
   - prepare upstream (TODO)
   - project-config (ON REVIEW)
   - fuel-main patch (TODO)
   - packaging-ci patch (TODO)
   - deprecate network_checker directory (TODO)


Now we are at the point where we need to freeze fuel-web/network_checker
directory. So, I'd like to announce code freeze for this directory and all
patches that make changes in the directory and are currently on review will
need to be backported to the new git repository.



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] [ironic] [horizon] ironic panels

[Beth Elwell]

Hi Jim,

I have replied inline to your comments below:

On 19/10/2015 19:38, Jim Rollenhagen wrote:

On Mon, Oct 19, 2015 at 07:05:04PM +0100, Beth Elwell wrote:

Hi all,

I am currently in the process of writing an Ironic panel in Horizon
upstream. It was originally intended for this panel to be written in
Angular JS, however, as I understand, no horizon angular work will
merge for several months, and 2-3 panels (of which ironic is not one)
are being moved to the feature branch to iterate on the design pattern
that they want to use to implement the angular.

With regard to the ironic panel, this means that in order to implement
it in angular, it will take weeks or perhaps months to merge and even
when it does, it may well need to be rewritten to follow design patterns
being set at the moment.

Therefore I propose that I continue to develop this as a Horizon python
panel as a short term solution to allow a UI to exist for our users of
Ironic ASAP and longer term make use of the ironic webclient and the
work that krotscheck is currently doing on that.

I would appreciate feedback with regard to whether the ironic community
are happy for me to continue on with developing a horizon panel or would
like me to work on an angular panel.

In general, I like the idea of "get a web interface to users quickly",
and in that spirit I think building a horizon panel is the right thing
to do.

I do love the webclient work; I think it's great. However, considering
that (as far as I know) there's only two people working on Ironic web
interfaces, is it valuable to be working on two different web interfaces
right now? In the worst case:
I have had contact from another party interested in helping get a 
horizon panel up and running quickly and so it is definitely doable to 
have that being worked on as well as the work on the webclient.

* horizon panel will be built
* webclient will also be built
* horizon will figure out angular stuff
* webclient will be re-written to work with horizon
* webclient will likely take significant time to merge into horizon
* old horizon panel will be deprecated
* (in time) old horizon panel will be removed

And in the best case, only the rewrite step is skipped, and maybe the
merge into horizon won't take long. There's also a question about how
much different the two are, and how large of a leap that is for users.

That seems like a lot of extra effort and maintenance for an entire
team; let alone two people. So I question if it's worth working on the
webclient, or punting on that until horizon is ready, and then
refactoring the horizon panel into angular.

Is there a clear benefit to having both worked on in parallel?


As I see it they ultimately fulfill different purposes and therefore 
developing both is not a waste of resources or time. The panel is a 
short term solution to fulfill a user requirement for a user interface 
within Horizon. The webclient is a long term mission to create 
independent API libraries in javascript in order to make openstack more 
composable.

// jim

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

Thanks,
Beth
__
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][all] Reviews with a prio label?

[Dolph Mathews]

On Tue, Oct 20, 2015 at 11:43 AM, Dolph Mathews 
wrote:

> This is actually something I've thought a lot about (focusing the
> community's review efforts), and have experimented with various solutions
> in the keystone community. I've built external solutions that have worked
> fairly well, but my current preference is to take advantage of what's
> already built into gerrit: starred reviews and dashboards.
>
> For example, here is a dashboard of reviews in the keystone ecosystem
> starred by any member of keystone-core that *you* have not reviewed
> yourself (so you'll need to be logged into gerrit for this link to work):
>
>   http://bit.ly/1GnOuqw [1]
>
> In other words, it's a personalized review queue of things keystone-core
> deems important.
>
> The advantage I see to this approach over a new label is that the star
> feature is already in the gerrit UI and so people already use it. But
> broadly speaking, I'm not aware of anyone utilizing that data today as a
> crowd sourced data point.
>
> If you'd like to create your own version of this dashboard, here's the
> gerrit-dash-creator config file for this dashboard:
>
>   https://github.com/dolph/dotfiles/blob/master/gerrit-dashboard-keystone
>

Permalink:
https://github.com/dolph/dotfiles/blob/2cf8cf21821a1014883c6669bd9886b38d0225ae/gerrit-dashboard-keystone


>
> To customize it for yourself, you'd pretty much only need to edit the
> [dashboard] section, and specifically the "foreach" value to reflect the
> right collection of projects and group of reviewers. After that it's a
> matter of using gerrit-dash-creator to produce the link:
>
>   https://github.com/openstack/gerrit-dash-creator
>
> I'd love to take this a couple steps further if people find the approach
> valuable. I'd like to regularly recreate these links for every project
> based on the latest *-core membership, and the latest set of projects in a
> given community, publish them to permalinks, and share those permalinks
> with code reviewers.
>
> [1] unshortened 
> h*ttps://review.openstack.org/#/dashboard/?foreach=is%3Aopen+%252Downer%3Aself+%28project%3Aopenstack%252Dattic%2Fidentity%252Dapi+OR+project%3Aopenstack%2Fkeystone+OR+project%3Aopenstack%2Fkeystone%252Dspecs+OR+project%3Aopenstack%2Fkeystoneauth+OR+project%3Aopenstack%2Fkeystoneauth%252Dsaml2+OR+project%3Aopenstack%2Fkeystonemiddleware+OR+project%3Aopenstack%2Fpycadf+OR+project%3Aopenstack%2Fpython%252Dkeystoneclient%29+%28starredby%3Abknudson%40us.ibm.com+OR+starredby%3Adstanek%40dstanek.com+OR+starredby%3Adolph.mathews%40gmail.com+OR+starredby%3Ajamielennox%40redhat.com+OR+starredby%3Albragstad%40gmail.com+OR+starredby%3Aos.lcheng%40gmail.com+OR+starredby%3Amarek.denis%40cern.ch+OR+starredby%3Amorgan.fainberg%40gmail.com+OR+starredby%3Astevemar%40ca.ibm.com+OR+starredby%3Aayoung%40redhat.com+OR+starredby%3Aguang.yee%40hpe.com+OR+starredby%3Ahenryn%40linux.vnet.ibm.com%29=Priority+keystone+reviews+attention=%252Dlabel%3ACode%252DReview%3C%3D2%252cself+%252Dlabel%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0=%252Dlabel%3ACode%252DReview%3C%3D2+label%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0&%2B1=%252Dlabel%3ACode%252DReview%3C%3D%2B2%252cself+%252Dlabel%3ACode%252DReview%3C%3D%252D1+label%3ACode%252DReview%2B1+%252Dlabel%3ACode%252DReview%2B2+label%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0&%2B2=%252Dlabel%3ACode%252DReview%3C%3D%2B2%252cself+%252Dlabel%3ACode%252DReview%3C%3D%252D1+label%3ACode%252DReview%2B2+label%3AVerified%2B1%252cjenkins+label%3AWorkflow%2B0+gating=label%3AVerified%3D%2B1%252cjenkins+label%3AWorkflow%2B1=%252Dlabel%3AVerified%3C%3D%252D1%252cjenkins+%252Dlabel%3AVerified%3E%3D%2B1%252cjenkins+label%3AWorkflow%2B1+gating=label%3AVerified%3C%3D%252D1%252cjenkins+label%3AWorkflow%2B1
> 

Re: [openstack-dev] [infra][all] Reviews with a prio label?

[Dolph Mathews]

On Tue, Oct 20, 2015 at 12:09 PM, Sean Dague  wrote:

> On 10/20/2015 12:43 PM, Dolph Mathews wrote:
> > This is actually something I've thought a lot about (focusing the
> > community's review efforts), and have experimented with various
> > solutions in the keystone community. I've built external solutions that
> > have worked fairly well, but my current preference is to take advantage
> > of what's already built into gerrit: starred reviews and dashboards.
> >
> > For example, here is a dashboard of reviews in the keystone ecosystem
> > starred by any member of keystone-core that *you* have not reviewed
> > yourself (so you'll need to be logged into gerrit for this link to work):
> >
> >   http://bit.ly/1GnOuqw [1]
> >
> > In other words, it's a personalized review queue of things keystone-core
> > deems important.
> >
> > The advantage I see to this approach over a new label is that the star
> > feature is already in the gerrit UI and so people already use it. But
> > broadly speaking, I'm not aware of anyone utilizing that data today as a
> > crowd sourced data point.
>
> The rally team uses it as part of their dashboard -
>
> https://github.com/stackforge/gerrit-dash-creator/blob/4d597f3b9c62f4422e3f8cdcd3b9c96921faa155/dashboards/rally.dash#L6-L7
>
> > If you'd like to create your own version of this dashboard, here's the
> > gerrit-dash-creator config file for this dashboard:
> >
> >
> https://github.com/dolph/dotfiles/blob/master/gerrit-dashboard-keystone
> >
> > To customize it for yourself, you'd pretty much only need to edit the
> > [dashboard] section, and specifically the "foreach" value to reflect the
> > right collection of projects and group of reviewers. After that it's a
> > matter of using gerrit-dash-creator to produce the link:
> >
> >   https://github.com/openstack/gerrit-dash-creator
> >
> > I'd love to take this a couple steps further if people find the approach
> > valuable. I'd like to regularly recreate these links for every project
> > based on the latest *-core membership, and the latest set of projects in
> > a given community, publish them to permalinks, and share those
> > permalinks with code reviewers.
>
> One of the challenges you run into is url length limits in browsers,
> given that we're encoding the whole thing in the url.
>

I haven't run into any issues yet myself, but yes, definitely. One of the
easiest changes I'd make to "compress" the URL is to use user IDs instead
of emails like I did here, e.g.:

  https://review.openstack.org/#/q/status:open+starredby:4,n,z


>
> I do think the overall approach has a lot of merrit, though it would
> still be awesome if there was a more baked in tagging in gerrit.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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][all] Reviews with a prio label?

[Daniel P. Berrange]

On Tue, Oct 20, 2015 at 06:09:51PM +0200, Markus Zoeller wrote:
> In ML post [1] I wondered if it would be possible to introduce a new
> "prio" label in Gerrit which could help in focusing review efforts to
> increase the throughput. With this new post I'd like to discuss if we
> think this could be useful. For example, this would allow to create this
> query in Gerrit:
> 
> "status:open label:Prio=3" 
> 
> I was curious how this could look like in Gerrit, which resulted in the
> screenshots available at [2]. This would minimize the gap between the 
> prio of the blueprints/bugs and their commit reviews.
> 
> I'm mostly active in Nova, so here a short example of how we currently
> try to speed up the merges of trivial fixes:
> 
> * contributor "A" spots a review which looks trivial
> * contributor "A" copies the review ID into an etherpad
> * core reviewer "B" reads the etherpad when possible
> * core reviewer "B" does a review too and eventually gives a +W
> * core reviewer "B" removes that review from the Etherpad when it merges
> 
> This workflow is only necessary because Gerrit does not allow to 
> categorize reviews, e.g. into a group of "trivial fixes". 
> 
> I noticed in my "mini poc" that it would be possible to set permissions
> to specific label values. Which allows us to have a "trivialfix" prio 
> which can be set by everyone, but also a "high" prio which can be set 
> by an automated entity which reuses the priority of the blueprint or 
> bug report.
> 
> Do you think this would speed things up? Or is this just nitpicking on
> an already good enough workflow?

What you're describing is really just a special-case of allowing
arbitrary user tagging of changes. If gerrit had a free-format
keyword tag facility that users could use & query, it'd open up many
possible options for improving our general workflow, and letting
users customize their own workflow.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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][all] Reviews with a prio label?

[Markus Zoeller]

"Daniel P. Berrange"  wrote on 10/20/2015 06:21:05 
PM:

> From: "Daniel P. Berrange" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 10/20/2015 06:21 PM
> Subject: Re: [openstack-dev] [infra][all] Reviews with a prio label?
> What you're describing is really just a special-case of allowing
> arbitrary user tagging of changes. If gerrit had a free-format
> keyword tag facility that users could use & query, it'd open up many
> possible options for improving our general workflow, and letting
> users customize their own workflow.
> 
> Regards,
> Daniel

True. My proposal is indeed a poor man's way of tagging. My research,
if Gerrit provides such a feature, didn't bring up any results.

Regards, Markus Zoeller (markus_z)


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

Re: [openstack-dev] [puppet] weekly meeting #56

[Emilien Macchi]

On 10/19/2015 08:49 AM, Emilien Macchi wrote:
> Hello!
> 
> Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC
> in #openstack-meeting-4:
> 
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151020
> 
> Note: some people have some actions, please have a look at the etherpad!
> 
> Feel free to add any items you'd like to discuss.
> If our schedule allows it, we'll make bug triage during the meeting.
> 
> Thanks,

We did our meeting:
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-10-20-15.00.html

Reminder: no meeting next week, we'll be in Tokyo for the OpenStack Summit.
-- 
Emilien Macchi



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

[openstack-dev] [infra][all] Reviews with a prio label?

[Markus Zoeller]

In ML post [1] I wondered if it would be possible to introduce a new
"prio" label in Gerrit which could help in focusing review efforts to
increase the throughput. With this new post I'd like to discuss if we
think this could be useful. For example, this would allow to create this
query in Gerrit:

"status:open label:Prio=3" 

I was curious how this could look like in Gerrit, which resulted in the
screenshots available at [2]. This would minimize the gap between the 
prio of the blueprints/bugs and their commit reviews.

I'm mostly active in Nova, so here a short example of how we currently
try to speed up the merges of trivial fixes:

* contributor "A" spots a review which looks trivial
* contributor "A" copies the review ID into an etherpad
* core reviewer "B" reads the etherpad when possible
* core reviewer "B" does a review too and eventually gives a +W
* core reviewer "B" removes that review from the Etherpad when it merges

This workflow is only necessary because Gerrit does not allow to 
categorize reviews, e.g. into a group of "trivial fixes". 

I noticed in my "mini poc" that it would be possible to set permissions
to specific label values. Which allows us to have a "trivialfix" prio 
which can be set by everyone, but also a "high" prio which can be set 
by an automated entity which reuses the priority of the blueprint or 
bug report.

Do you think this would speed things up? Or is this just nitpicking on
an already good enough workflow?

Regards,
Markus Zoeller (markus_z)

References:
[1] ML; October 2015; "[infra] Upgrade to Gerrit 2.11":

http://lists.openstack.org/pipermail/openstack-dev/2015-October/077130.html
[2] images of a "demo" of having a prio label in Gerrit:
http://postimg.org/gallery/strofne2/


__
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] [Heat] core team nomination

[Steve Baker]

+1

On 21/10/15 02:38, Sergey Kraynev wrote:

I'd like to propose new candidates for heat core-team:
Rabi Mishra
Peter Razumovsky

According statistic both candidate made a big effort in Heat as
reviewers and as contributors [1][2].
They were involved in Heat community work  during last several releases and
showed good understanding of Heat code.
I think, that they are ready to became core-reviewers.

Heat-cores, please vote with +/- 1.

[1] http://stackalytics.com/report/contribution/heat-group/180
[2] http://stackalytics.com/?module=heat-group=person-day



__
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] [Heat] core team nomination

[Angus Salkeld]

+1 to both

On Tue, 20 Oct 2015 11:42 pm Sergey Kraynev  wrote:

I'd like to propose new candidates for heat core-team:
Rabi

Mishra


Peter Razumovsky

According statistic both candidate made a big effort in Heat as
reviewers and as contributors [1][2].
They were involved in Heat community work  during last several releases and
showed good understanding of Heat code.
I think, that they are ready to became core-reviewers.

Heat-cores, please vote with +/- 1.

[1] http://stackalytics.com/report/contribution/heat-group/180
[2] http://stackalytics.com/?module=heat-group=person-day
--
Regards,
Sergey.

__
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] [Heat] core team nomination

[Jason Dunsmore]

+1!

From: Sergey Kraynev 
Sent: Tuesday, October 20, 2015 8:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev]  [Heat] core team nomination

I'd like to propose new candidates for heat core-team:
Rabi Mishra
Peter Razumovsky

According statistic both candidate made a big effort in Heat as
reviewers and as contributors [1][2].
They were involved in Heat community work  during last several releases and
showed good understanding of Heat code.
I think, that they are ready to became core-reviewers.

Heat-cores, please vote with +/- 1.

[1] http://stackalytics.com/report/contribution/heat-group/180
[2] http://stackalytics.com/?module=heat-group=person-day
--
Regards,
Sergey.

__
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] [rally] Rally boot tests fails with Error Forbidden: It is not allowed to create an interface on external networks

[Yair Fried]

On Tue, Oct 20, 2015 at 8:39 PM, Behzad Dastur 
wrote:

> Hi Yair,
> The rally version I am using is 0.1.2
>
> > rally --version
> 0.1.2
>
> Also the task file is as shown below. Do you have an example of the
> "network" context to skip creation on the interface on the xternal network?
>
have you seen the plugin reference?
https://rally.readthedocs.org/en/latest/plugin/plugin_reference.html
Looks like there's also existing_network [context] but I'm unfamiliar with
it.

> vagrant@rally:~/rally$ more /vagrant/boot.json
>
> {% set flavor_name = flavor_name or "m1.tiny" %}
>
> {
>
> "NovaServers.boot_server": [
>
> {
>
> "args": {
>
> "flavor": {
>
> "name": "{{flavor_name}}"
>
> },
>
"auto_assign_nic": true,

> "image": {
>
> "name": "cirros-0.3.1-x86_64"
>
> },
>
> "use_floatingip": false
>
I think this should be true (or maybe even removed)

> },
>
> "runner": {
>
> "type": "constant",
>
> "times": 10,
>
> "concurrency": 2
>
> },
>
> "context": {
>
"network": {"networks_per_tenant": 1},

> "users": {
>
> "tenants": 3,
>
> "users_per_tenant": 2
>
> }
>
> }
>
> }
>
> ]
>
> }
>
> regards,
> Behzad
>
> Date: Tue, 20 Oct 2015 15:04:46 +0300
> From: Yair Fried 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [rally] Rally boot tests fails with Error
> Forbidden: It is not allowed to create an interface on external
> networks
> Message-ID:
> 

Re: [openstack-dev] [all][heat] Which repo to use in docs -- git.openstack.org or github.com?

[Ian Wienand]

On 10/21/2015 04:20 AM, Christopher Aedo wrote:

On the other hand, the fact that github renders the README nicely
(including images) leads to a much more inviting first impression.


I think it's nice to just have a standard docs target, even if it just
includes the README; [1] is an example.  Then you've got the framework
to actually document something in the future, should you wish.

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

__
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] Gerrit permissions and Merge rights

[Armando M.]

Hi folks,

During revision of the Neutron teams [1], we made clear that the
neutron-specs repo is to be targeted by specs for all the Neutron projects
(core + *-aas).

For this reason I made sure that the neutron-specs-core team +2 right was
extended to all the core teams.

Be mindful, use your +2 rights with care: if you are core on a *-aas
project, you should exercise that vote only for specs that pertain the
project you're core of.

If I could use this email as a reminder also of the core hierarchy and
lieutenant system we switched to in Liberty ([3]): if you have been made
core by a lieutenant of a sub-system, please use your +2/+A only within
your area of comfort and reach out for help if in doubt.

Reviews are always welcome though!

Cheers,
Armando

[1] https://review.openstack.org/#/c/237180/
[2] https://review.openstack.org/#/admin/groups/314,members
[3]
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy
__
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] [Ceilometer] "Infinite" values for "sum" and "average" fields in statistics query

[gord chung]

could you open a bug on 
https://bugs.launchpad.net/ceilometer/+bugs?orderby=-id=0 and 
reference this thread


i would also check to see if ceilometer-api logs have any noticeable 
warning/errors. it's possible a datatype is being restricted there as well.


thanks

On 20/10/2015 12:22 PM, Srikanth Vavilapalli wrote:

Hi

I am using MongoDB backend.

Thanks
Srikanth

-Original Message-
From: gord chung [mailto:g...@live.ca]
Sent: Tuesday, October 20, 2015 9:20 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ceilometer] "Infinite" values for "sum" and 
"average" fields in statistics query

which backend are you using? this potentially may be a bug where we're hitting 
some size limit restricted by datatype.

On 19/10/2015 4:02 PM, Srikanth Vavilapalli wrote:

Hi

I have observed "inf" values for "sum" and "average" fields in a ceilometer statistics query on one of my custom meter 
as shown below. I have also verified the samples query for this meter and there are 1544 samples (output shown below) with all of them having value 
as "150.0". So ideally the "Avg" filed should be "150.0" in this scenario. Could anyone tell me in what scenario we 
will see these two fields as "inf" in the meter statistics query? Plz let me know if you need more details or logs here. Appreciate your 
help.

Thanks
Srikanth


svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer
statistics --meter=vcpe.dns.cache.size
++++---+---+-+-+---++++
| Period | Period Start   | Period End | Max   | 
Min   | Avg | Sum | Count | Duration   | Duration Start | Duration 
End   |
++++---+---+-+-+---++++
| 0  | 2015-10-17T01:30:24.999000 | 2015-10-19T17:47:20.587000 | 150.0 | 
150.0 | inf | inf | 1544  | 231415.588 | 2015-10-17T01:30:24.999000 | 
2015-10-19T17:47:20.587000 |
++++---+---+-+-+---++++


svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer
sample-list --meter=vcpe.dns.cache.size
+-+-+---++-++
| Resource ID | Name| Type  | Volume | Unit| Timestamp  
|
+-+-+---++-++
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:47:20.587000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:47:00.048000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:42:20.47 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:41:59.921000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:37:20.362000 |
.
.
.
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:50:25.499000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:45:46.255000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:45:25.374000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:40:46.131000 |

__
 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

--
gord


__
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


--
gord


__
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] Cross-project meeting, Tue Oct 20th, 21:00 UTC

[Emilien Macchi]

Agenda is empty, meeting is canceled.
Next week's meeting is also canceled because of OpenStack Summit.

I hope you'll have a safe trip to Tokyo, see you there,

On 10/19/2015 08:41 AM, Emilien Macchi wrote:
> Dear PTLs, cross-project liaisons, and interested team members,
> 
> We'll have a cross-project meeting tomorrow at 21:00 UTC, with the
> following agenda:
> 
> https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda
> 
> Review past action items
> Team announcements (horizontal, vertical, diagonal)
> Open discussion
> 
> For more details on this meeting, please see:
> https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
> 
> See you there,
> 
> 
> 
> __
> 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
> 

-- 
Emilien Macchi



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] Liberty release builds

[Steven Dake (stdake)]

On 10/20/15, 9:06 AM, "Paul Bourke"  wrote:

>Kolla core team,
>
>Here's a link to an etherpad created just now for deciding the process
>on getting release builds to dockerhub:
>
>https://etherpad.openstack.org/p/kolla-release-builds
>
>Please review and revise. Steve, can you follow up to this mail when
>you'd like volunteers to kick off builds?

Paul,

Thanks for the initiative here!  We actually had one last minute patch
that needs to go into the tree related to Ceph failing to build
occasionally because of timers, so I decided to not push the tag until it
was resolved.  This was compounded by a node pool restart which broke
about 4 hours of CI testing of the patch that needs to go in to fix the
problem.

Once the release is tagged, we can go ahead and build for direct
consumption from the docker hub.

Regards,
-steve



>
>Cheers,
>-Paul
>
>__
>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] [Ceilometer] "Infinite" values for "sum" and "average" fields in statistics query

[Srikanth Vavilapalli]

I have raised the bug for this 
(https://bugs.launchpad.net/ceilometer/+bug/1508220)

I have checked the ceilometer-api logs when I ran the query and have not found 
any errors or warnings. I could see only the below two logs:

2015-10-20 17:47:06.771 84151 DEBUG ceilometer.api.controllers.v2.meters [-] 
computed value coming from u'(,)' statistics 
/usr/lib/python2.7/dist-packages/ceilometer/api/controllers/v2/meters.py:407
2015-10-20 17:47:06.773 84151 INFO werkzeug [-] 192.168.0.3 - - [20/Oct/2015 
17:47:06] "GET /v2/meters/vcpe.dns.cache.size/statistics HTTP/1.1" 200 -

Thanks
Srikanth



-Original Message-
From: gord chung [mailto:g...@live.ca] 
Sent: Tuesday, October 20, 2015 1:39 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ceilometer] "Infinite" values for "sum" and 
"average" fields in statistics query

could you open a bug on
https://bugs.launchpad.net/ceilometer/+bugs?orderby=-id=0 and reference 
this thread

i would also check to see if ceilometer-api logs have any noticeable 
warning/errors. it's possible a datatype is being restricted there as well.

thanks

On 20/10/2015 12:22 PM, Srikanth Vavilapalli wrote:
> Hi
>
> I am using MongoDB backend.
>
> Thanks
> Srikanth
>
> -Original Message-
> From: gord chung [mailto:g...@live.ca]
> Sent: Tuesday, October 20, 2015 9:20 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Ceilometer] "Infinite" values for "sum" 
> and "average" fields in statistics query
>
> which backend are you using? this potentially may be a bug where we're 
> hitting some size limit restricted by datatype.
>
> On 19/10/2015 4:02 PM, Srikanth Vavilapalli wrote:
>> Hi
>>
>> I have observed "inf" values for "sum" and "average" fields in a ceilometer 
>> statistics query on one of my custom meter as shown below. I have also 
>> verified the samples query for this meter and there are 1544 samples (output 
>> shown below) with all of them having value as "150.0". So ideally the "Avg" 
>> filed should be "150.0" in this scenario. Could anyone tell me in what 
>> scenario we will see these two fields as "inf" in the meter statistics 
>> query? Plz let me know if you need more details or logs here. Appreciate 
>> your help.
>>
>> Thanks
>> Srikanth
>>
>>
>> svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer 
>> statistics --meter=vcpe.dns.cache.size
>> ++++---+---+-+-+---++++
>> | Period | Period Start   | Period End | Max   | 
>> Min   | Avg | Sum | Count | Duration   | Duration Start | 
>> Duration End   |
>> ++++---+---+-+-+---++++
>> | 0  | 2015-10-17T01:30:24.999000 | 2015-10-19T17:47:20.587000 | 150.0 | 
>> 150.0 | inf | inf | 1544  | 231415.588 | 2015-10-17T01:30:24.999000 | 
>> 2015-10-19T17:47:20.587000 |
>> ++++---+---+-+-+---++++
>>
>>
>> svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer 
>> sample-list --meter=vcpe.dns.cache.size
>> +-+-+---++-++
>> | Resource ID | Name| Type  | Volume | Unit| Timestamp   
>>|
>> +-+-+---++-++
>> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
>> 2015-10-19T17:47:20.587000 |
>> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
>> 2015-10-19T17:47:00.048000 |
>> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
>> 2015-10-19T17:42:20.47 |
>> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
>> 2015-10-19T17:41:59.921000 |
>> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
>> 2015-10-19T17:37:20.362000 |
>> .
>> .
>> .
>> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
>> 2015-10-17T01:50:25.499000 |
>> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
>> 2015-10-17T01:45:46.255000 |
>> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
>> 2015-10-17T01:45:25.374000 |
>> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
>> 2015-10-17T01:40:46.131000 |
>>
>> _
>> _  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
> --
> gord
>
>
> 

[openstack-dev] [Fuel] fuelmenu code freeze

[Vladimir Kozhukalov]

Dear colleagues,

As you might know I'm working on splitting multiproject fuel-web repository
into several sub-projects. Fuelmenu is one of directories that are to be
moved to a separate git project.

Checklist for this to happen is as follows:

   - Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1506885
   - project-config patch https://review.openstack.org/#/c/235177 (ON
   REVIEW WORKFLOW -1)
   - pypi project
   https://pypi.python.org/pypi?%3Aaction=pkg_edit=Fuel-menu (DONE)
   - run_tests.sh https://review.openstack.org/#/c/235243/ (DONE)
   - rpm/deb specs https://review.openstack.org/#/c/235273/ (DONE)
   - fuel-ci verification jobs https://review.fuel-infra.org/12865 (ON
   REVIEW)
   - label jenkins slaves for verification jobs (ci team)
   - directory freeze (WE ARE HERE)
   - prepare upstream (TODO)
   - project-config (ON REVIEW)
   - fuel-main patch (TODO)
   - packaging-ci patch (TODO)
   - deprecate fuel-web/fuelmenu directory (TODO)

Now we are at the point where we need to freeze fuel-web/fuelmenu
directory. So, I'd like to announce code freeze for this directory and all
patches that make changes in the directory and are currently on review will
need to be backported to the new git repository.


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] [Heat] core team nomination

[Steven Hardy]

On Tue, Oct 20, 2015 at 04:38:12PM +0300, Sergey Kraynev wrote:
> I'd like to propose new candidates for heat core-team:
> Rabi Mishra
> Peter Razumovsky
> 
> According statistic both candidate made a big effort in Heat as
> reviewers and as contributors [1][2].
> They were involved in Heat community work  during last several releases and
> showed good understanding of Heat code.
> I think, that they are ready to became core-reviewers.
> 
> Heat-cores, please vote with +/- 1.

+1

__
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] python-novaclient 2.32.0 not working with rackspace

[melanie witt]

Hi everyone,

We have an issue [1] in python-novaclient 2.32.0 where it's not working with 
rackspace cloud.

It's caused by a commit [2] that changed the default requested compute API 
version from "latest" to "client supported latest", a specific version. We have 
some logic in the discover_version method that does comparisons between a 
user-specified version and the server version. For rackspace, we get a "null" 
server version because the version list API isn't exposed. The discover_version 
falls back on compute API 2.0 when requested version is "latest" and server 
version is "null" but raises an error when requested version is 
"user-specified" and server version is "null". So more work is needed there to 
handle cases where version API isn't exposed.

Should we revert [2] for now? Any other thoughts?

Thanks,
-melanie (irc: melwitt)

[1] https://bugs.launchpad.net/python-novaclient/+bug/1508244
[2] https://review.openstack.org/#/c/230024/



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [release][ironic] Announcing Ironic 4.2.1

[Jim Rollenhagen]

Hi all,

We're excited to announce the release of Ironic 4.2.1. This is a patch
release in the OpenStack Liberty series.

This release imports Japanese translations as our first translated
language, and also fixes some bugs around running on systems with the
Japanese locale.

Release notes can be found at: 
http://docs.openstack.org/developer/ironic/releasenotes/#id1
Full details are at: https://launchpad.net/ironic/liberty/4.2.1

Source code: http://git.openstack.org/cgit/openstack/ironic
Documentation: http://docs.openstack.org/developer/ironic/
Bug tracker: https://bugs.launchpad.net/ironic

Thanks!

// jim

__
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] [Magnum] Coe components status

[Qiao,Liyong]

hi Vikas,
thanks for propose this changes, I wonder if you can show some examples 
for other coes we currently supported:

swarm, mesos ?

if we propose a public api like you proposed, we'd better to support all 
coes instead of coe specific.


thanks
Eli.

On 2015年10月20日 18:14, Vikas Choudhary wrote:

Hi Team,

I would appreciate any opinion/concern regarding 
"coe-component-status" feature implementation [1].


For example in k8s, using 
APIapi/v1/namespaces/{namespace}/componentstatuses, status of each k8s 
component can be queried. My approach would be to provide a command in 
magnum like "magnum coe-component-status" leveraging coe provided rest 
api and result will be shown to user.


[1] https://blueprints.launchpad.net/magnum/+spec/coe-component-status



-Vikas Choudhary


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


--
BR, Eli(Li Yong)Qiao

<>__
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] [Ironic] OpenStack Ironic dinner

[John Villalovos]

Did we come to a decision on what day for the Ironic dinner?

On Mon, Oct 12, 2015 at 11:07 AM, Lucas Alvares Gomes  wrote:

> Since many of us is going to be in Tokyo for the summit, who's interested
> in an OpenStack Ironic dinner?
>
> Let's first decide what day of the week suits most people, so please vote
> here: http://doodle.com/poll/2nqbemmrdd9a5ypd
>
> if you have any food requirements or restrictions please add it to the
> "comments" section in the doodle pool.
>
> Cheers,
> Lucas
>
> __
> 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] [Ironic] OpenStack Ironic dinner

[Jim Rollenhagen]

BadCub and I have been working to find a venue that can host that many
people, and haven't had any luck at all. :(

I think we'll need to skip a formal team dinner this time, sorry folks.
I'd still love to do something informal on Thursday night with some of
you - we can work it out next week.

// jim

On Tue, Oct 20, 2015 at 05:02:24PM -0700, John Villalovos wrote:
> Did we come to a decision on what day for the Ironic dinner?
> 
> On Mon, Oct 12, 2015 at 11:07 AM, Lucas Alvares Gomes  > wrote:
> 
> > Since many of us is going to be in Tokyo for the summit, who's interested
> > in an OpenStack Ironic dinner?
> >
> > Let's first decide what day of the week suits most people, so please vote
> > here: http://doodle.com/poll/2nqbemmrdd9a5ypd
> >
> > if you have any food requirements or restrictions please add it to the
> > "comments" section in the doodle pool.
> >
> > Cheers,
> > Lucas
> >
> > __
> > 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] 答复: [Heat] core team nomination

[Huangtianhua]

+1

-邮件原件-
发件人: Sergey Kraynev [mailto:skray...@mirantis.com] 
发送时间: 2015年10月20日 21:38
收件人: OpenStack Development Mailing List (not for usage questions)
主题: [openstack-dev] [Heat] core team nomination

I'd like to propose new candidates for heat core-team:
Rabi Mishra
Peter Razumovsky

According statistic both candidate made a big effort in Heat as reviewers and 
as contributors [1][2].
They were involved in Heat community work  during last several releases and 
showed good understanding of Heat code.
I think, that they are ready to became core-reviewers.

Heat-cores, please vote with +/- 1.

[1] http://stackalytics.com/report/contribution/heat-group/180
[2] http://stackalytics.com/?module=heat-group=person-day
--
Regards,
Sergey.

__
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][QA][Plugins] Move functional tests from fuel-qa to the plugins

[Mike Scherbakov]

Simon,
I believe that it's a mistake in fuel-qa. Valid structure is in fuel-web.
Please fix the one in fuel-qa.

I'm also looking forward for automated adding of people to review requests
based on this file. Here is the task to track it:
https://bugs.launchpad.net/fuel/+bug/1497655

On Tue, Oct 20, 2015 at 2:10 AM Simon Pasquier 
wrote:

> Thanks for the reply, Andrew! I must admit that I haven't read thoroughly
> the specification on the new team structure [1]. IIUC plugin developers
> should be added to the MAINTAINERS file of fuel-qa for the directories that
> concern their plugins. If I take LMA as an example, this would be:
> fuelweb_test/tests/plugins/plugin_elasticsearch
> fuelweb_test/tests/plugins/plugin_lma_collector
> fuelweb_test/tests/plugins/plugin_lma_infra_alerting
>
> Is that right?
>
> I can submit a change to fuel-qa for adding the LMA team to the
> MAINTAINERS file but I can't figure out the structure of the YAML data:
> fuel-web/MAINTAINERS [2] is organized as "{directory1: [maintainer1,
> maintainer2, ...], directory2: [...], ...}" while for fuel-qa [3] (and
> other Fuel projects), it's "[maintainer1, maintainer2, ...]".
>
> BR,
> Simon
>
> [1]
> http://specs.fuel-infra.org/fuel-specs-master/policy/team-structure.html
> [2] https://github.com/openstack/fuel-web/blob/master/MAINTAINERS
> [3] https://github.com/openstack/fuel-qa/blob/master/MAINTAINERS
>
>
> On Sat, Oct 17, 2015 at 2:21 AM, Andrew Woodward  wrote:
>
>> We have already discussed this to be a result of describing data driven
>> testing, untill this spec is completed there is little sense to remove all
>> of these since fuel-qa is 100% required to operate this way. In the interim
>> we should just specify the appropriate SME with the MAINTAINERS file.
>>
>> On Fri, Oct 16, 2015 at 11:34 AM Sergii Golovatiuk <
>> sgolovat...@mirantis.com> wrote:
>>
>>> Tests should be in plugin
>>>
>>> --
>>> Best regards,
>>> Sergii Golovatiuk,
>>> Skype #golserge
>>> IRC #holser
>>>
>>> On Fri, Oct 16, 2015 at 5:58 PM, Simon Pasquier 
>>> wrote:
>>>
 Hello Alexey,

 On Fri, Oct 16, 2015 at 5:35 PM, Alexey Elagin 
 wrote:

> Hello Simon!
>
> We are going to remove plugins' functional tests from fuel-qa because
> this tests don't use for our plugins CI process.
>

 And where are the existing tests going to be stored then?

 Thanks,
 Simon


>
>
> __
> 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
>>>
>> --
>>
>> --
>>
>> Andrew Woodward
>>
>> Mirantis
>>
>> Fuel Community Ambassador
>>
>> Ceph Community
>>
>> __
>> 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
>
-- 
Mike Scherbakov
#mihgen
__
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] [ironic] [horizon] ironic panels

[Jim Rollenhagen]

On Tue, Oct 20, 2015 at 04:50:04PM +0100, Beth Elwell wrote:
> Hi Jim,
> 
> I have replied inline to your comments below:
> 
> On 19/10/2015 19:38, Jim Rollenhagen wrote:
> >On Mon, Oct 19, 2015 at 07:05:04PM +0100, Beth Elwell wrote:
> >>Hi all,
> >>
> >>I am currently in the process of writing an Ironic panel in Horizon
> >>upstream. It was originally intended for this panel to be written in
> >>Angular JS, however, as I understand, no horizon angular work will
> >>merge for several months, and 2-3 panels (of which ironic is not one)
> >>are being moved to the feature branch to iterate on the design pattern
> >>that they want to use to implement the angular.
> >>
> >>With regard to the ironic panel, this means that in order to implement
> >>it in angular, it will take weeks or perhaps months to merge and even
> >>when it does, it may well need to be rewritten to follow design patterns
> >>being set at the moment.
> >>
> >>Therefore I propose that I continue to develop this as a Horizon python
> >>panel as a short term solution to allow a UI to exist for our users of
> >>Ironic ASAP and longer term make use of the ironic webclient and the
> >>work that krotscheck is currently doing on that.
> >>
> >>I would appreciate feedback with regard to whether the ironic community
> >>are happy for me to continue on with developing a horizon panel or would
> >>like me to work on an angular panel.
> >In general, I like the idea of "get a web interface to users quickly",
> >and in that spirit I think building a horizon panel is the right thing
> >to do.
> >
> >I do love the webclient work; I think it's great. However, considering
> >that (as far as I know) there's only two people working on Ironic web
> >interfaces, is it valuable to be working on two different web interfaces
> >right now? In the worst case:
> I have had contact from another party interested in helping get a horizon
> panel up and running quickly and so it is definitely doable to have that
> being worked on as well as the work on the webclient.
> >* horizon panel will be built
> >* webclient will also be built
> >* horizon will figure out angular stuff
> >* webclient will be re-written to work with horizon
> >* webclient will likely take significant time to merge into horizon
> >* old horizon panel will be deprecated
> >* (in time) old horizon panel will be removed
> >
> >And in the best case, only the rewrite step is skipped, and maybe the
> >merge into horizon won't take long. There's also a question about how
> >much different the two are, and how large of a leap that is for users.
> >
> >That seems like a lot of extra effort and maintenance for an entire
> >team; let alone two people. So I question if it's worth working on the
> >webclient, or punting on that until horizon is ready, and then
> >refactoring the horizon panel into angular.
> >
> >Is there a clear benefit to having both worked on in parallel?
> 
> As I see it they ultimately fulfill different purposes and therefore
> developing both is not a waste of resources or time. The panel is a short
> term solution to fulfill a user requirement for a user interface within
> Horizon. The webclient is a long term mission to create independent API
> libraries in javascript in order to make openstack more composable.

Okay, after reading this and talking with krotscheck in IRC:

* The horizon panel is clearly valuable, as many users use Horizon. We
  should support that.

* The ironic-webclient work is clearly valuable, as we support running
  Ironic standalone, and a standalone web UI would be great to have for
  that.

* I'm not opinionated whether "independent API libraries in Javascript
  in order to make OpenStack more composable" is valuable. It seems like
  it is, assuming there's a use case for that. The clear use case to me
  is to allow Horizon competitors to be built, which seems useful for
  folks that don't want to or care to use Horizon.

At any rate, I agree the horizon panel should be worked on - let's get
our users a UI.

// jim

__
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] Custom Nova scheduler based on CPU queue length

[Rahul Nair]

​Hi All,

I am fairly new to the OpenStack community and is trying to create a custom
scheduler for Nova. A scheduler based on CPU queue length. Kindly apologize
if there are any inaccuracies in my statements.

As I understand a weigher for the filter scheduler that weighs filtered
host machines based on the host weight option, 'cpu.percent' can be
configured to prioritize the hosts based on CPU percentage, but there are
only limited options when it comes to filtering of machines in the first
place, that too using the CPU queue length.

Also, I understand that IBM has its platform resource scheduler that can be
used to build custom plugins to get user defined metrics, is there a
similar way in pure Openstack which can be used to get the CPU queue length.

As of now, I am thinking of writing a custom script to be kept in all
compute nodes to retrieve the CPU queue length and send it to the Nova
controller, is this the way to go, or is there a defined approach that I
can follow to implement a scheduler that uses CPU queue length to filter
physical machines.

Any pointers on this would be really helpful.

Regards,
Rahul U Nair
__
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] HenryG addition to the Neutron Drivers team

[Armando M.]

Hi folks,

Henry has been instrumental in many areas of the projects and his crazy
working hours makes even Kevin and I bow in awe.

Jokes aside, I would like to announce HenryG as a new member of the Neutron
Drivers team.

Having a propension to attendance, and desire to review of RFEs puts you on
the right foot to join the group, whose members are rotated regularly so
that everyone is given the opportunity to grow, and no-one burns out.

The team [1] meets regularly on Tuesdays [2], and anyone is welcome to
attend.

Please, join me in welcome Henry to the team.

Cheers,
Armando

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

Re: [openstack-dev] [Magnum] Coe components status

[Vikas Choudhary]

@ Eli ,

I will look into how to support this feature for other COEs also(mesos and
swarm). But anyways Magnum's goal is to provide users *atleast* what other
coes are providing (if not something extra). All coes dont have common
features, so we cant be very strict on providing common interface apis for
all coes. For example "magnum container" commands work only with swarm not
k8s or mesos.
It will not be justified if k8s is providing a way to monitor at more
granular level but magnum will not allow user to use it just beacuse other
coes does not provide this feature.

Agree that it will be nice if could support this feature for all. I will
prefer to start with k8s first and if similar feature is supported by mesos
and swarm also, incrementally will implement that also.

Regards
Vikas Choudhary

On Wed, Oct 21, 2015 at 6:50 AM, Qiao,Liyong  wrote:

> hi Vikas,
> thanks for propose this changes, I wonder if you can show some examples
> for other coes we currently supported:
> swarm, mesos ?
>
> if we propose a public api like you proposed, we'd better to support all
> coes instead of coe specific.
>
> thanks
> Eli.
>
>
> On 2015年10月20日 18:14, Vikas Choudhary wrote:
>
> Hi Team,
>
> I would appreciate any opinion/concern regarding "coe-component-status"
> feature implementation [1].
>
> For example in k8s, using API api/v1/namespaces/{namespace}/componentstatuses,
> status of each k8s component can be queried. My approach would be to
> provide a command in magnum like "magnum
> coe-component-status" leveraging coe provided rest api and result will be
> shown to user.
>
> [1] https://blueprints.launchpad.net/magnum/+spec/coe-component-status
>
>
>
> -Vikas Choudhary
>
>
> __
> 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
>
>
> --
> BR, Eli(Li Yong)Qiao
>
>
> __
> 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] [nova] python-novaclient 2.32.0 not working with rackspace

[Alex Xu]

Looks like we use API_MAX_VERSION and DEFAULT_OS_COMPUTE_API_VERSION with
wrong way. This isn't broken with rackspace only, this broken novaclient
runing with nova legacy v2 api(legacy v2 api's behavior is no version
exposed).

API_MAX_VERSION is the max version of client supported, currently it should
be '2.5'

DEFAULT_OS_COMPUTE_API_VERSION is the default value of CLI option of
'--os-compute-api-version', ti should be '2.latest' which means let CLI to
negotiate with server side choice most recently version.

Not sure whether we need revert, but at least a new fix should come after
that.

Thanks
Alex

2015-10-21 7:52 GMT+08:00 melanie witt :

> Hi everyone,
>
> We have an issue [1] in python-novaclient 2.32.0 where it's not working
> with rackspace cloud.
>
> It's caused by a commit [2] that changed the default requested compute API
> version from "latest" to "client supported latest", a specific version. We
> have some logic in the discover_version method that does comparisons
> between a user-specified version and the server version. For rackspace, we
> get a "null" server version because the version list API isn't exposed. The
> discover_version falls back on compute API 2.0 when requested version is
> "latest" and server version is "null" but raises an error when requested
> version is "user-specified" and server version is "null". So more work is
> needed there to handle cases where version API isn't exposed.
>
> Should we revert [2] for now? Any other thoughts?
>
> Thanks,
> -melanie (irc: melwitt)
>
> [1] https://bugs.launchpad.net/python-novaclient/+bug/1508244
> [2] https://review.openstack.org/#/c/230024/
>
>
> __
> 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] Do not merge until further notice

[Takashi Yamamoto]

i missed the "further notice"?

On Wed, Oct 14, 2015 at 4:07 AM, Armando M.  wrote:
> Hi folks,
>
> We are in the last hours of Liberty, let's pause for a second and consider
> merging patches only if absolutely necessary. The gate is getting clogged
> and we need to give priority to potential RC3 fixes or gate stability fixes.
>
> Thanks,
> Armando
>
> __
> 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] [Openstack]Devstack error tgt process related to iscsi not getting started

[Sumanth Sathyanarayana]

Hi,

On running stack.sh, I am getting the below error related to tgt process,
which has
something to do with Cinder.

2015-10-20 23:28:24.030 | + echo_summary 'Starting Cinder'
2015-10-20 23:28:24.030 | + [[ -t 3 ]]
2015-10-20 23:28:24.030 | + [[ True != \T\r\u\e ]]
2015-10-20 23:28:24.030 | + echo -e Starting Cinder
2015-10-20 23:28:24.030 | + start_cinder
2015-10-20 23:28:24.031 | + local service_port=8776
2015-10-20 23:28:24.031 | + local service_protocol=http
2015-10-20 23:28:24.031 | + is_service_enabled tls-proxy
2015-10-20 23:28:24.033 | + return 1
2015-10-20 23:28:24.033 | + '[' tgtadm = tgtadm ']'
2015-10-20 23:28:24.033 | + is_service_enabled c-vol
2015-10-20 23:28:24.035 | + return 0
2015-10-20 23:28:24.035 | + sudo rm -f /etc/tgt/conf.d/stack.conf
2015-10-20 23:28:24.043 | + _configure_tgt_for_config_d
2015-10-20 23:28:24.043 | + [[ ! -d /etc/tgt/stack.d/ ]]
2015-10-20 23:28:24.044 | + is_ubuntu
2015-10-20 23:28:24.044 | + [[ -z deb ]]
2015-10-20 23:28:24.044 | + '[' deb = deb ']'
2015-10-20 23:28:24.044 | + sudo service tgt restart
2015-10-20 23:28:24.055 | stop: Unknown instance:
2015-10-20 23:28:24.589 | start: Job failed to start
2015-10-20 23:28:24.590 | + exit_trap
2015-10-20 23:28:24.590 | + local r=1
2015-10-20 23:28:24.591 | ++ jobs -p
2015-10-20 23:28:24.592 | + jobs=
2015-10-20 23:28:24.592 | + [[ -n '' ]]
2015-10-20 23:28:24.592 | + kill_spinner
2015-10-20 23:28:24.592 | + '[' '!' -z '' ']'
2015-10-20 23:28:24.592 | + [[ 1 -ne 0 ]]
2015-10-20 23:28:24.592 | + echo 'Error on exit'
2015-10-20 23:28:24.592 | Error on exit
2015-10-20 23:28:24.592 | + [[ -z /opt/stack/logs ]]
2015-10-20 23:28:24.592 | + /home/ubuntu/devstack/tools/worlddump.py -d
/opt/stack/logs
2015-10-20 23:28:25.341 | + exit 1

I see in the above log that the tgt process is somehow failing to restart.
So I tried to manually uninstall the process and re-install it
by
sudo apt-get install tgt
and I also tried sudo apt-get upgrade.
For both the scenarios,  I still got the below log:

After this operation, 670 kB of additional disk space will be used.
Selecting previously unselected package tgt.
(Reading database ... 68926 files and directories currently installed.)
Preparing to unpack .../tgt_1%3a1.0.43-0ubuntu4.1~14.04.2_amd64.deb ...
Unpacking tgt (1:1.0.43-0ubuntu4.1~14.04.2) ...
Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
Processing triggers for ureadahead (0.100.0-16) ...
Setting up tgt (1:1.0.43-0ubuntu4.1~14.04.2) ...
start: Job failed to start
invoke-rc.d: initscript tgt, action "start" failed.
dpkg: error processing package tgt (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 tgt
E: Sub-process /usr/bin/dpkg returned an error code (1)


I saw that there were similar issues raised earlier,
like
http://lists.openstack.org/pipermail/openstack-dev/2014-June/038157.html

But I did not find any clear solution. Has any body faced this issue
recently?

Thanks & Best Regards
Sumanth
__
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] [nova] python-novaclient 2.32.0 not working with rackspace

[Alex Xu]

I just work out a patch quickly for fixing this,
https://review.openstack.org/237850

2015-10-21 10:08 GMT+08:00 Alex Xu :

> Looks like we use API_MAX_VERSION and DEFAULT_OS_COMPUTE_API_VERSION with
> wrong way. This isn't broken with rackspace only, this broken novaclient
> runing with nova legacy v2 api(legacy v2 api's behavior is no version
> exposed).
>
> API_MAX_VERSION is the max version of client supported, currently it
> should be '2.5'
>
> DEFAULT_OS_COMPUTE_API_VERSION is the default value of CLI option of
> '--os-compute-api-version', ti should be '2.latest' which means let CLI to
> negotiate with server side choice most recently version.
>
> Not sure whether we need revert, but at least a new fix should come after
> that.
>
> Thanks
> Alex
>
> 2015-10-21 7:52 GMT+08:00 melanie witt :
>
>> Hi everyone,
>>
>> We have an issue [1] in python-novaclient 2.32.0 where it's not working
>> with rackspace cloud.
>>
>> It's caused by a commit [2] that changed the default requested compute
>> API version from "latest" to "client supported latest", a specific version.
>> We have some logic in the discover_version method that does comparisons
>> between a user-specified version and the server version. For rackspace, we
>> get a "null" server version because the version list API isn't exposed. The
>> discover_version falls back on compute API 2.0 when requested version is
>> "latest" and server version is "null" but raises an error when requested
>> version is "user-specified" and server version is "null". So more work is
>> needed there to handle cases where version API isn't exposed.
>>
>> Should we revert [2] for now? Any other thoughts?
>>
>> Thanks,
>> -melanie (irc: melwitt)
>>
>> [1] https://bugs.launchpad.net/python-novaclient/+bug/1508244
>> [2] https://review.openstack.org/#/c/230024/
>>
>>
>> __
>> 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] [Magnum] Coe components status

[Bharath Thiruveedula]

+ 1 to vikas.

As we have monitor framework only to docker swarm COE at present and we are
pushing other COE drivers in future. So it is better to have component
status for one COE at first and will push other COEs support later. Correct
me if I am wrong.

Regards
Bharath T

On Wed, Oct 21, 2015 at 9:26 AM, Vikas Choudhary  wrote:

> @ Eli ,
>
> I will look into how to support this feature for other COEs also(mesos and
> swarm). But anyways Magnum's goal is to provide users *atleast* what other
> coes are providing (if not something extra). All coes dont have common
> features, so we cant be very strict on providing common interface apis for
> all coes. For example "magnum container" commands work only with swarm not
> k8s or mesos.
> It will not be justified if k8s is providing a way to monitor at more
> granular level but magnum will not allow user to use it just beacuse other
> coes does not provide this feature.
>
> Agree that it will be nice if could support this feature for all. I will
> prefer to start with k8s first and if similar feature is supported by mesos
> and swarm also, incrementally will implement that also.
>
> Regards
> Vikas Choudhary
>
> On Wed, Oct 21, 2015 at 6:50 AM, Qiao,Liyong 
> wrote:
>
>> hi Vikas,
>> thanks for propose this changes, I wonder if you can show some examples
>> for other coes we currently supported:
>> swarm, mesos ?
>>
>> if we propose a public api like you proposed, we'd better to support all
>> coes instead of coe specific.
>>
>> thanks
>> Eli.
>>
>>
>> On 2015年10月20日 18:14, Vikas Choudhary wrote:
>>
>> Hi Team,
>>
>> I would appreciate any opinion/concern regarding "coe-component-status"
>> feature implementation [1].
>>
>> For example in k8s, using API api/v1/namespaces/{namespace}
>> /componentstatuses, status of each k8s component can be queried. My
>> approach would be to provide a command in magnum like "magnum
>> coe-component-status" leveraging coe provided rest api and result will be
>> shown to user.
>>
>> [1] https://blueprints.launchpad.net/magnum/+spec/coe-component-status
>>
>>
>>
>> -Vikas Choudhary
>>
>>
>> __
>> 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
>>
>>
>> --
>> BR, Eli(Li Yong)Qiao
>>
>>
>> __
>> 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] [neutron][fwaas] openstack summit meetup

[Oğuz Yarımtepe]

Hi,

Will there be a meetup or design session for FWaaS? I just saw the roadmap
presentation at the main conf.

-- 
Oğuz Yarımtepe
http://about.me/oguzy
__
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] [nova-compute][nova][libvirt] Extending Nova-Compute for image prefetching

[Lingxian Kong]

Hi, Alberto,

I'm really interested in your proposal, have you already submitted
your spec? or is there any topic for you to have a discussion with
Nova team in design summit?

I wonder what if the nova compute host use shared storage backend,
like NFS or Ceph?

I have another suggestion, we can consider adding this capability in
nova manage CLI, since it's just may be used by operator or
administrator(at least for create/update/delete command), right?

On Thu, Oct 8, 2015 at 7:50 PM, Alberto Geniola
 wrote:
> Hi all,
>
> I'm considering to extend the Nova-Compute API in order to provide
> image-prefetching capabilities to OS.
>
> In order to allow image prefetching, I ended up with the need to add three
> different APIs on the nova-compute nodes:
>
>   1. Trigger an image prefetching
>
>   2. List prefetched images
>
>   3. Delete a prefetched image
>
>
>
> About the point 1 I saw I can re-use the libvirt driver function
> _create_image() to trigger the image prefetching. However, this approach
> will not store any information about the stored image locally. This leads to
> an issue: how do I retrieve a list of already fetched images? A quick and
> simple possibility would be having a local file, storing information about
> the fetched images. Would it be acceptable? Is there any best practice in OS
> community?
>
>
>
> Any ideas?
>
>
> Ty,
>
> Al.
>
>
> --
> Dott. Alberto Geniola
>
>   albertogeni...@gmail.com
>   +39-346-6271105
>   https://www.linkedin.com/in/albertogeniola
>
> Web: http://www.hw4u.it
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

__
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] The OVS and Provider Networks section of the guide to Neutron in DevStack

[Mike Spreitzer]

First let me make sure I understand what this section (
http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch-and-provider-networks
) is trying to say.  The second paragraph is saying that some 
infrastructure provider has allocated a VLAN tag (and the later display of 
localrc contents uses 2010 as that tag) and an address range (later seen 
to be 203.0.113.0/24) to use on that VLAN on provider_net.  The exhibited 
localrc contents also say that tenant networks can be created, using VLAN 
tags drawn from the range 3001:4000.  Those localrc contents do not 
explicitly say which ethernet --- provider_net or control_plane --- will 
carry those tenant VLANs.  Which ethernet do you think those localrc 
contents imply will carry the tenant VLANs?

Second, I tested this using stable/liberty on Ubuntu 14.04.03, and got a 
few surprises.  I did exactly as described by that section, starting from 
a "physical network setup" as described there (but it was actually 
virtual, using VirtualBox), and using the localrc contents exhibited there 
except patched to fix bugs 
https://bugs.launchpad.net/devstack/+bug/1508195 and 
https://bugs.launchpad.net/devstack/+bug/1508202 (the latter by sadly 
stipulating IP_VERSION=4).  After creating the controller, compute1, and 
compute2 I looked at `ovs-vsctl show` on the controller, and found that 
br-tun had two VxLan ports (see display below).  This surprised me because 
I thought that VxLan can itself handle multiple hosts, it is not just 
point-to-point.

Bridge br-tun
fail_mode: secure
Port "vxlan-0a03"
Interface "vxlan-0a03"
type: vxlan
options: {df_default="true", in_key=flow, 
local_ip="10.0.0.2", out_key=flow, remote_ip="10.0.0.3"}
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port "vxlan-0a04"
Interface "vxlan-0a04"
type: vxlan
options: {df_default="true", in_key=flow, 
local_ip="10.0.0.2", out_key=flow, remote_ip="10.0.0.4"}
Port br-tun
Interface br-tun
type: internal

My second surprise is that the path from controller to the VM's host goes 
over the control_plane network --- somewhat contrary to its name!

My third surprise came after I made a VM on the provider network and tried 
to ping it from the router.  I got no response.  A little investigation 
shows that the router's ARP request for the VM gets lost somewhere between 
br-int and br-tun.  `tcpdump -nne -i br-int` on the controller shows the 
ARP requests appearing with VLAN tag 1 (which is right, the external VLAN 
tags are translated to internal host-local tags on br-int), and no ARP 
replies.  OTOH, `tcpdump -nne -i br-tun` does not even find the ARP 
requests.

Digging a little deeper, I looked at the OpenFlow tables on the 
controller.  It looks like the flow table for br-tun does indeed prescribe 
that all traffic coming from outside be dropped!  Here is the output from 
`ovs-appctl bridge/dump-flows br-tun`:

duration=23916s, priority=1, n_packets=0, n_bytes=0, 
priority=1,in_port=3,actions=resubmit(,4)
duration=39904s, priority=1, n_packets=82, n_bytes=7025, 
priority=1,in_port=1,actions=resubmit(,2)
duration=36711s, priority=1, n_packets=0, n_bytes=0, 
priority=1,in_port=2,actions=resubmit(,4)
duration=39904s, priority=0, n_packets=7, n_bytes=558, 
priority=0,actions=drop
table_id=2, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00,actions=resubmit(,20)
table_id=2, duration=39904s, priority=0, n_packets=82, n_bytes=7025, 
priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=resubmit(,22)
table_id=3, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,actions=drop
table_id=4, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,actions=drop
table_id=6, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,actions=drop
table_id=10, duration=39904s, priority=1, n_packets=0, n_bytes=0, 
priority=1,actions=learn(table=20,hard_timeout=300,priority=1,cookie=0xb64bc7164f7e1137,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),output:1
table_id=20, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,actions=resubmit(,22)
table_id=22, duration=39904s, priority=0, n_packets=82, n_bytes=7025, 
priority=0,actions=drop
table_id=254, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,reg0=0x3,actions=drop
table_id=254, duration=39904s, priority=0, n_packets=1, n_bytes=90, 
priority=0,reg0=0x1,actions=controller(reason=no_match)
table_id=254, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,reg0=0x2,actions=drop

By examining `ovs-vsctl list Interface` I can see that patch-int is 
OpenFlow 

Re: [openstack-dev] [neutron][fwaas] openstack summit meetup

[Sridar Kandaswamy (skandasw)]

There are two slots (combined with LBaaS) Thu, Oct 29, 11am and the follow on 
at 11:50am [1].

Thanks

Sridar

[1] http://mitakadesignsummit.sched.org/overview/type/neutron


From: Oğuz Yarımtepe >
Reply-To: OpenStack List 
>
Date: Tuesday, October 20, 2015 at 9:42 PM
To: OpenStack List 
>
Subject: [openstack-dev] [neutron][fwaas] openstack summit meetup

Hi,

Will there be a meetup or design session for FWaaS? I just saw the roadmap 
presentation at the main conf.

--
Oğuz Yarımtepe
http://about.me/oguzy
__
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] Do not merge until further notice

[Armando M.]

On 20 October 2015 at 19:46, Takashi Yamamoto  wrote:

> i missed the "further notice"?
>

No, you didn't. RC3 released, Liberty released, the world moved on and I
didn't think of sending an email. Sorry.


>
> On Wed, Oct 14, 2015 at 4:07 AM, Armando M.  wrote:
> > Hi folks,
> >
> > We are in the last hours of Liberty, let's pause for a second and
> consider
> > merging patches only if absolutely necessary. The gate is getting clogged
> > and we need to give priority to potential RC3 fixes or gate stability
> fixes.
> >
> > Thanks,
> > Armando
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] HenryG addition to the Neutron Drivers team

[Kevin Benton]

Excellent addition! Remember everyone, if the feature you want doesn't make
it into Neutron, it's now Henry's fault. :)

On Tue, Oct 20, 2015 at 8:14 PM, Armando M.  wrote:

> Hi folks,
>
> Henry has been instrumental in many areas of the projects and his crazy
> working hours makes even Kevin and I bow in awe.
>
> Jokes aside, I would like to announce HenryG as a new member of the
> Neutron Drivers team.
>
> Having a propension to attendance, and desire to review of RFEs puts you
> on the right foot to join the group, whose members are rotated regularly so
> that everyone is given the opportunity to grow, and no-one burns out.
>
> The team [1] meets regularly on Tuesdays [2], and anyone is welcome to
> attend.
>
> Please, join me in welcome Henry to the team.
>
> Cheers,
> Armando
>
> [1]
> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [all][heat] Which repo to use in docs -- git.openstack.org or github.com?

[Monty Taylor]

On 10/20/2015 06:43 AM, Andreas Jaeger wrote:

On 2015-10-20 12:17, Qiming Teng wrote:

Hi,

Just encountered this again in code review [1]. The question is about
the repository to point to when documenting things up. Between the
following links, which one should we use?

- https://git.openstack.org/cgit/openstack/sqlalchemy-migrate
- https://github.com/openstack/sqlalchemy-migrate

I had an impression that I saw something like 'use git.openstack.org
instead of github.com because the later is just a mirror ...' but cannot
find the link now. Maybe it is an illusion. :)

So, seriously, any recommendations or guidelines?


Yes, git.openstack.org is our official server, github is just a
read-only mirror.

Linking to github might also raise the expectation that we use the usual
github workflow which is not the case,


++

I try to update github urls when I find them - but it's better if they 
don't crop up in general. :)



__
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