[openstack-dev] [openstack-infra] Vitrage is missing in the formal OpenStack launchpad

[GROSZ, Maty (Maty)]

Hello,

I have lately added the new Vitrage RCA project for OpenStack.
I have followed the instructions for adding a setting a new project, but for 
some reason, when I enters OpenStack launchpad - https://launchpad.net/openstack
I don’t see the Vitrage project in the lists (for example, I don’t see any of 
our blueprints when I enter the launchpad blueprints: 
https://blueprints.launchpad.net/openstack)
What do I miss? Where did I need to add Vitrage so that it would appear?

Thanks,

Maty


__
OpenStack Development Mailing 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] [murano]How to use Murano to transmit files to Mistral and execute scripts on Mistral

[Alexander Tivelkov]

Hi Tony,

Probably I am missing something, but why do you need Murano Agent to
interact with Mistral? You can call Mistral APIs right from MuranoPL code
being executed by Murano Engine. Murano's core library contains the
io.murano.system.MistralClient
class ([1]) which may be used to upload and run mistral workflows.

Please let me know if you need more details on this

[1]
https://github.com/openstack/murano/blob/master/murano/engine/system/mistralclient.py

On Tue, Nov 17, 2015 at 5:07 AM WANG, Ming Hao (Tony T) <
tony.a.w...@alcatel-lucent.com> wrote:

> Dear Murano developers and testers,
>
>
>
> I want to put some files that Mistral workflow needs into Murano package,
> and hope Murano can transmit them to Mistral before it calls Mistral
> workflow.
>
> The flow should be as following:
>
> 1.   User uploads one Murano package which includes both
> Murano artifacts and Mistral artifacts to Murano;
>
> 2.   Murano transmits the Mistral artifacts to Mistral,
> and Mistral does its work.
>
>
>
> After study, I thought muranoagent may be helpful and plan to install a
> muranoagent on the Mistral server since it can put files into nova server,
> and can run scripts on the nova server.
>
> After further study, I found muranoagent solution may be not feasible:
>
> 1.   muranoagent and murano-engine(dsl) uses rabbitMQ to
> communicate.
>
> 2.   When an Agent object is created in DSL,
> murano-engine creates a unique message queue to communicate with the
> muranoagent in nova instance:
>
> The queue name consists of current murano environment id, and the nova
> instance murano object id.
>
> 3.   During murano creates the nova instance, it passes
> this unique queue name via nova user_data to muranoagent on guest.
>
> In this way, muranoagents on different guests can communicate with
> murano-engine separately.
>
> This doesn’t suit the muranoagent + Mistral server solution.
>
> We only want to install one muranoagent in Mistral server, and it should
> only listen on one message queue.
>
> We can’t create  new muranoagent for each murano environment.
>
> To achieve this, one solution that I can think is to modify murano code to
> implement a new MistralAgent to listen on a pre-defined message queue.
>
>
>
> Could you please share your ideas about this?
>
> If you have other solution, please also help to share it.  J
>
>
>
> Thanks in advance,
>
> Tony
>
>
> __
> OpenStack Development Mailing 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,
Alexander Tivelkov
__
OpenStack Development Mailing 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] [ceilometer][aodh][vitrage] Vitrage project

[AFEK, Ifat (Ifat)]

Hi Ceilometer/AODH developers,

As you might have heard in Mitaka Summit, we have started a new project named 
Vitrage[1]. We would like it to be the Openstack RCA (Root Cause Analysis) 
Engine for organizing, analyzing and expanding OpenStack alarms & events, 
yielding insights regarding the root cause of problems and deducing the 
existence of problems before they are directly detected.

We are now in the process of reviewing the blueprints[2] that we wish to 
implement in mitaka. We would be happy to get your reviews as well, as Vitrage 
should work with AODH alarms - get AODH alarms as input, produce RCA insights, 
and optionally generate new deduced alarms. 

Your feedback would be highly appreciated.

[1] https://wiki.openstack.org/wiki/Vitrage
[2] https://blueprints.launchpad.net/vitrage 

Thanks,
Ifat Afek.



__
OpenStack Development Mailing 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] [vitrage] Next vitrage meeting

[AFEK, Ifat (Ifat)]

Hi,

Vitrage next weekly meeting will be tomorrow, Wednesday at 9:00 UTC, on 
#openstack-meeting-3 channel.

Agenda:
* Current status and progress from last week
* Review action items
* Next steps 
* Open Discussion

You are welcome to join.

Thanks, 
Ifat.

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

Re: [openstack-dev] [openstack-infra] Vitrage is missing in the formal OpenStack launchpad

[Foley, Emma L]

Hi Maty,

Have you set up the launchpad project? 
http://docs.openstack.org/infra/manual/creators.html#set-up-launchpad

Regards,
Emma

From: GROSZ, Maty (Maty) [mailto:maty.gr...@alcatel-lucent.com]
Sent: Tuesday, November 17, 2015 8:18 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [openstack-infra] Vitrage is missing in the formal 
OpenStack launchpad


Hello,

I have lately added the new Vitrage RCA project for OpenStack.
I have followed the instructions for adding a setting a new project, but for 
some reason, when I enters OpenStack launchpad - https://launchpad.net/openstack
I don’t see the Vitrage project in the lists (for example, I don’t see any of 
our blueprints when I enter the launchpad blueprints: 
https://blueprints.launchpad.net/openstack)
What do I miss? Where did I need to add Vitrage so that it would appear?

Thanks,

Maty


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

Re: [openstack-dev] [openstack-infra] Vitrage is missing in the formal OpenStack launchpad

[GROSZ, Maty (Maty)]

Thanks, found what was missing…

Yet another question:

How does the “Series and milestones” section and "Development focus:” in 
launchpad is updated? I only see “trunk” and “trunk series” instead of mitake/ 
and mitaka series.

Thanks

From: "Foley, Emma L"
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, November 17, 2015 at 11:16
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [openstack-infra] Vitrage is missing in the formal 
OpenStack launchpad

Hi Maty,

Have you set up the launchpad project? 
http://docs.openstack.org/infra/manual/creators.html#set-up-launchpad

Regards,
Emma

From: GROSZ, Maty (Maty) [mailto:maty.gr...@alcatel-lucent.com]
Sent: Tuesday, November 17, 2015 8:18 AM
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [openstack-infra] Vitrage is missing in the formal 
OpenStack launchpad


Hello,

I have lately added the new Vitrage RCA project for OpenStack.
I have followed the instructions for adding a setting a new project, but for 
some reason, when I enters OpenStack launchpad - https://launchpad.net/openstack
I don’t see the Vitrage project in the lists (for example, I don’t see any of 
our blueprints when I enter the launchpad blueprints: 
https://blueprints.launchpad.net/openstack)
What do I miss? Where did I need to add Vitrage so that it would appear?

Thanks,

Maty


__
OpenStack Development Mailing 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] [ec2api] stable/liberty release?

[Andrey Pavlov]

We are planning to cut liberty release and kilo update this or next week.
(Because we are waiting a response for one small issue.)

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

Re: [openstack-dev] [Openstack-operators] Mirantis Fuel Multi-Region

[Dina Belova]

+ openstack-dev mailing list to bring more Fuel audience.

On Tue, Nov 17, 2015 at 12:44 PM, Federico Michele Facca <
federico.fa...@create-net.org> wrote:

> Hi,
> as said, you need to do manual changes to your deployed nodes.
> then you will have to:
> - synch your galera cluster across the two dc
> - configure properly the load balancers
> - configure the memcached configuration
> - register the services of the second region on the new shared keystone
>
> Br,
> Federico
>
> PS: I think that you can change the region name in the YAML file using
> fuel cli (
> https://docs.mirantis.com/openstack/fuel/fuel-7.0/user-guide.html#cli-usage),
> but that won't help much honestly, being the trivial of the steps above.
>
> --
> Future Internet is closer than you think!
> http://www.fiware.org
>
> Official Mirantis partner for OpenStack Training
> https://www.create-net.org/community/openstack-training
>
> --
> Dr. Federico M. Facca
>
> CREATE-NET
> Via alla Cascata 56/D
> 38123 Povo Trento (Italy)
>
> P  +39 0461 312471
> M +39 334 6049758
> E  federico.fa...@create-net.org
> T @chicco785
> W  www.create-net.org
>
> On Tue, Nov 17, 2015 at 10:29 AM, Eren Türkay  wrote:
>
>> On 17-11-2015 10:40, Federico Michele Facca wrote:
>> > Hi Eren,
>>
>> Hello Federico
>>
>> > afaik, with the new plugin architecture, in fuel 7/8 it should be easy
>> to
>> > create a plugin for achieve your goal.
>> > in case of manual job, depending on your cloud architecture there are
>> different
>> > options, the main ones are:
>> > - you keep a single keystone in a datacenter and register the new region
>> > services in there.
>>
>> Yes, that's what I am aiming for. I need a single keystone and multiple
>> endpoints. However, as far as I understand, multi-dc isn't supported yet
>> on
>> Mirantis (nor the region name change). Do you know the actual/example
>> implementation for multi-dc with new plugin architecture? Here are my
>> findings
>> regarding to the issue. It seems deploying multi-site with fuel is really
>> hard
>> and not supported.
>>
>> https://answers.launchpad.net/fuel/+question/267127
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2015-October/076298.html
>>
>>
>> --
>> Eren Türkay, System Administrator
>> https://skyatlas.com/ | +90 850 885 0357
>>
>> Yildiz Teknik Universitesi Davutpasa Kampusu
>> Teknopark Bolgesi, D2 Blok No:107
>> Esenler, Istanbul Pk.34220
>>
>>
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

[openstack-dev] [Monasca][vitrage] Vitrage project

[AFEK, Ifat (Ifat)]

Hi Monasca developers,

As you might have heard in Mitaka Summit, we have started a new project named 
Vitrage[1]. We would like it to be the Openstack RCA (Root Cause Analysis) 
Engine for organizing, analyzing and expanding OpenStack alarms & events, 
yielding insights regarding the root cause of problems and deducing the 
existence of problems before they are directly detected.

We are now in the process of reviewing the blueprints[2] that we wish to 
implement in mitaka. At the first stage of the implementation we plan to 
integrate with AODH alarms. In the next phase, we would like to check how we 
can integrate with Monasca as well. We would be happy to get your reviews for 
our blueprints, to make sure our architecture matches this future integration. 

Your feedback would be highly appreciated.

[1] https://wiki.openstack.org/wiki/Vitrage
[2] https://blueprints.launchpad.net/vitrage 

Thanks,
Ifat Afek.



__
OpenStack Development Mailing 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] [aodh] HBase gate job

[Julien Danjou]

Hi,

So we recently decided to run the functional tests for the HBase driver
and enabled the gate job. It turned out the gate job didn't worked, so I
tried to fix it. Now it's almost fixed, and it run the functional tests
and Gabbi tests against Aodh with HBase as a back-end:

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

Obviously, as you know this is not a real HBase back-end, but a
in-memory backend that is provided inside Aodh. Now, it turns out that
this driver or this in-memory backend has a bug, as the Gabbi tests
fail.

I don't have time nor interest to fix that, so the way I see it it's
either:
1. Someone stands up, determines if the issue is in the driver or the
   in-memory implementation and fix it
2. Nobody cares and we drop HBase gate and deprecates the driver

If nobody stands up in the next week, I'll start working on 2.

-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info


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

[openstack-dev] [nova][libvirt] Native AIO mode - RFC

[Alexander Schmidt]

Hi all,

I started a blueprint [1] and spec [2] for enabling the usage
of native AIO mode for disk devices. The idea is to enable it
for storage backends/setups where IO performance benefits from
using native AIO mode and where no downsides are known wrt
stability or data integrity.

As there is a wide range of storage backends and setups, I'm
looking for input on specific backends that are known to
benefit from native AIO mode (or where known problems exist).
These are the comments so far (copied from the spec):

* native AIO mode is a bad idea if the storage is not fully
  pre-allocated, e.g. for qcow2 images that grow on
  demand or sparse LVM storage
* AIO mode has no effect if using the in-qemu
  network clients (any disks that use ).
  It is only relevant if using the in-kernel network drivers

Cases where AIO mode is beneficial

* Raw images and pre-allocated images in qcow2 format
* Cinder volumes that are located on iSCSI, NFS or FC devices.
* Quobyte (reported by Silvan Kaiser)

Also input on the minimum libvirt/qemu version where native
AIO mode should be used would be very helpful.

Thanks and regards,
Alex


__
OpenStack Development Mailing 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] [murano]How to use Murano to transmit files to Mistral and execute scripts on Mistral

[WANG, Ming Hao (Tony T)]

Alexander,

Thanks for your response.
During the workflow running stage, it may need to access some other artifacts.
In my case, I use Mistral workflow to call Ansible playbook, and I need Murano 
to put Ansible playbook into right place on Mistral server so that Mistral 
workflow can find it.

Thanks,
Tony

From: Alexander Tivelkov [mailto:ativel...@mirantis.com]
Sent: Tuesday, November 17, 2015 4:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [murano]How to use Murano to transmit files to 
Mistral and execute scripts on Mistral

Hi Tony,

Probably I am missing something, but why do you need Murano Agent to interact 
with Mistral? You can call Mistral APIs right from MuranoPL code being executed 
by Murano Engine. Murano's core library contains the 
io.murano.system.MistralClient class ([1]) which may be used to upload and run 
mistral workflows.

Please let me know if you need more details on this

[1]  
https://github.com/openstack/murano/blob/master/murano/engine/system/mistralclient.py

On Tue, Nov 17, 2015 at 5:07 AM WANG, Ming Hao (Tony T) 
mailto:tony.a.w...@alcatel-lucent.com>> wrote:
Dear Murano developers and testers,

I want to put some files that Mistral workflow needs into Murano package, and 
hope Murano can transmit them to Mistral before it calls Mistral workflow.
The flow should be as following:

1.   User uploads one Murano package which includes both Murano 
artifacts and Mistral artifacts to Murano;

2.   Murano transmits the Mistral artifacts to Mistral, and 
Mistral does its work.

After study, I thought muranoagent may be helpful and plan to install a 
muranoagent on the Mistral server since it can put files into nova server, and 
can run scripts on the nova server.
After further study, I found muranoagent solution may be not feasible:

1.   muranoagent and murano-engine(dsl) uses rabbitMQ to 
communicate.

2.   When an Agent object is created in DSL, murano-engine 
creates a unique message queue to communicate with the muranoagent in nova 
instance:
The queue name consists of current murano environment id, and the nova instance 
murano object id.

3.   During murano creates the nova instance, it passes this 
unique queue name via nova user_data to muranoagent on guest.
In this way, muranoagents on different guests can communicate with 
murano-engine separately.
This doesn’t suit the muranoagent + Mistral server solution.
We only want to install one muranoagent in Mistral server, and it should only 
listen on one message queue.
We can’t create  new muranoagent for each murano environment.
To achieve this, one solution that I can think is to modify murano code to 
implement a new MistralAgent to listen on a pre-defined message queue.

Could you please share your ideas about this?
If you have other solution, please also help to share it.  ☺•

Thanks in advance,
Tony

__
OpenStack Development Mailing 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,
Alexander Tivelkov
__
OpenStack Development Mailing 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] Use of self signed certs in endpoints

[Cory Benfield]

> On 16 Nov 2015, at 11:54, Sean Dague  wrote:
> That sounds pretty reasonable to me. I definitely support the idea that
> we should be using system CA by default, even if that means overriding
> requests in our tools.

Setting REQUESTS_CA_BUNDLE is absolutely the way to go about this. In requests 
2.9.0 we will also support the case that REQUESTS_CA_BUNDLE points to a 
directory of certificates, not a single certificate file, so this should cover 
all Linux distributions methods of distributing OpenSSL-compatible certificates.

If OpenStack wants to support using Windows and OS X built-in certificate 
stores, that's harder. This is because both systems do not use PEM-file based 
certificate distribution, which means OpenSSL can’t read them.

Cory


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] [keystone] Case for renewability of tokens, increasing expiration time

[Dolph Mathews]

On Tuesday, November 17, 2015, Lindsay Pallickal 
wrote:

> I was having an issue extending the expiration on unscoped and
> tenant/project scoped tokens retrieved with an existing token. I now
> realize this is a feature, not a bug, but I've got some points to argue
> that extending token expiration when getting a new token with an existing
> one (renewal), is worth considering. Maybe as on option with a cap on
> maximum renewal time.
>
> Problem (as state before I realized this was a feature):
>
> When I "renew" an unscoped token using an existing unscoped token, a new
> token (access.token.id is different) is issued, but the expiration is
> always the same as the first unscoped token that was returned on
> authentication with a username and password. I expected the expiration to
> extend with each new token, but this only seems to happen when an unscoped
> token is retrieved by authenticating with a username and password, not when
> an existing unscoped token is used to authenticate the request for a new
> token.
>
> Tenant/project scoped tokens, similarly, always return the expiration from
> the unscoped token used to retrieve them. Since any unscoped tokens can't
> get an updated expiration, the problem extends here.
>
> I have an application where the user enters their username and password
> once, and whenever a token is used, I mark it "dirty" so it is "renewed"
> within 30 seconds. This way they don't have to re-login until they haven't
> performed any actions for the ~1 hour expiration time Keystone grants. Now
> clearly the expiration time is not moving ahead with these "renewals", so
> it doesn't work as intended, and that leads me to seek some remedy. Storing
> a username and password in browser local storage/cookies, or multiple on a
> server that relays browser requests to api endpoints, would open a can of
> worms.
>
> Reasons to reconsider the expiration policy:
>
> It looks like expiration is done this way to limit the damage from stolen
> tokens, but if a token were stolen, it could be stolen from the same
> location a username and password will now have to sit, to get around having
> to re-supply them manually once an hour. Yes, forcing re-auth hourly with a
> username and password, at the Keystone level, can limit damage if any of
> the core Openstack services are compromised for the mass theft of tokens.
> But limited damage will depend just as much on how quickly the compromise
> is detected. The more time an attacker has in the system, the less his
> actions will be hampered by a lack of token renewals. VMs can be
> compromised, and data exported or destroyed given just a small window.
>

This first part of this is only a "maybe", not a completely true assertion.
There are *many* more opportunities for individual tokens to be exposed
than for the credentials used to create them. In the case if a mass token
compromise, which I consider to be a completely different scenario, token
expiration probably isn't going it be any help because there's probably
always a fresher token available to the attacker, anyway, until the exploit
is closed. Instead, keystone has several means of quickly revoking tokens
in bulk (revocation events, truncating the UUID token table, restarting the
memcache token backend, or rotating all your Fernet keys away... all
depending on your deployment).


>
> On the other hand, if a user facing application, or a long running service
> supporting one, needs the API and is to remain convenient, they have to
> store usernames and passwords. Sometimes that long running service is
> connected to the outside world and faces security threats, such as when
> relaying Openstack API requests to their respective internal network
> endpoints - similar to what Horizon does. I wonder if I use Horizon
> continuously, whether it will force me to manually re-authenticate hourly,
> and if not, how it is getting around this problem, with or without storing
> the username and password.
>

Bearer tokens are simply not the right solution to this use case. Unless
horizon were to store your credentials client-side, you will be logged out
after your keystone.conf [token] expiration passes.


>
> I suspect it is more probable to button up security closer to the core of
> Openstack, rather than relying on many third party API consuming
> apps/services to secure even more compromising credentials. Perhaps effort
> could be put into auditing for atypical mass token renewal events, like a
> sudden increase, or accumulating rate of renewal requests in proportion
> with the number of tokens streamed into compromised state.
>
> Allowing a maximum of 3 hours, in 1 hour renewal increments via Keystone,
> and making that configurable, would be a good compromise for user/outside
> facing apps/apis. Reducing temptation to adopt the security burden of
> storing usernames and passwords, especially on a server exposed to the
> outside or in storage that is outside (cookies & local storage), could
> itself b

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Stanislaw Bogatkin]

Dmitry, I believe it should be done via package spec as a part of
installation.

On Mon, Nov 16, 2015 at 8:04 PM, Dmitry Nikishov 
wrote:

> Hello folks,
>
> I have updated the spec, please review and share your thoughts on it:
> https://review.openstack.org/#/c/243340/
>
> Thanks.
>
> On Thu, Nov 12, 2015 at 10:42 AM, Dmitry Nikishov 
> wrote:
>
>> Matthew,
>>
>> sorry, didn't mean to butcher your name :(
>>
>> On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov > > wrote:
>>
>>> Matther,
>>>
>>> I totally agree that each daemon should have it's own user which should
>>> be created during installation of the relevant package. Probably I didn't
>>> state this clear enough in the spec.
>>>
>>> However, there are security requirements in place that root should not
>>> be used at all. This means that there should be a some kind of maintenance
>>> or system user ('fueladmin'), which would have enough privileges to
>>> configure and manage Fuel node (e.g. run "sudo puppet apply" without
>>> password, create mirrors etc). This also means that certain fuel- packages
>>> would be required to have their files accessible to that user. That's the
>>> idea behind having a package which would create 'fueladmin' user and
>>> including it into other fuel- packages requirements lists.
>>>
>>> So this part of the feature comes down to having a non-root user with
>>> sudo privileges and passwordless sudo for certain commands (like 'puppet
>>> apply ') for scripting.
>>>
>>> On Thu, Nov 12, 2015 at 9:52 AM, Matthew Mosesohn <
>>> mmoses...@mirantis.com> wrote:
>>>
 Dmitry,

 We really shouldn't put "user" creation into a single package and then
 depend on it for daemons. If we want nailgun service to run as nailgun
 user, it should be created in the fuel-nailgun package.
 I think it makes the most sense to create multiple users, one for each
 service.

 Lastly, it makes a lot of sense to tie a "fuel" CLI user to
 python-fuelclient package.

 On Thu, Nov 12, 2015 at 6:42 PM, Dmitry Nikishov <
 dnikis...@mirantis.com> wrote:

> Stanislaw,
>
> I agree that this approch would work well. However, does Puppet allow
> managing capabilities and/or file ACLs? Or can they be easily set up when
> installing RPM package? (is there a way to specify capabilities/ACLs in 
> the
> RPM spec file?) This doesn't seem to be supported out of the box.
>
> I'm going to research if it is possible to manage capabilities and
>  ACLs with what we have out of the box (RPM, Puppet).
>
> On Wed, Nov 11, 2015 at 4:29 AM, Stanislaw Bogatkin <
> sbogat...@mirantis.com> wrote:
>
>> Dmitry, I propose to give needed linux capabilities
>> (like CAP_NET_BIND_SERVICE) to processes (services) which needs them and
>> then start these processes from non-privileged user. It will give you
>> ability to run each process without 'sudo' at all with well fine-grained
>> permissions.
>>
>> On Tue, Nov 10, 2015 at 11:06 PM, Dmitry Nikishov <
>> dnikis...@mirantis.com> wrote:
>>
>>> Stanislaw,
>>>
>>> I've been experimenting with 'capsh' on the 6.1 master node and it
>>> doesn't seem to preserve any capabilities when setting SECURE_NOROOT 
>>> bit,
>>> even if explicitely told to do so (via either --keep=1 or
>>> "SECURE_KEEP_CAPS" bit).
>>>
>>> On Tue, Nov 10, 2015 at 11:20 AM, Dmitry Nikishov <
>>> dnikis...@mirantis.com> wrote:
>>>
 Bartolomiej, Adam,
 Stanislaw is correct. And this is going to be ported to master. The
 goal currently is to reach an agreement on the implementation so that
 there's going to be a some kinf of compatibility during upgrades.

 Stanislaw,
 Do I understand correctly that you propose using something like
 sucap to launch from root, switch to a different user and then drop
 capabilities which are not required?

 On Tue, Nov 10, 2015 at 3:11 AM, Stanislaw Bogatkin <
 sbogat...@mirantis.com> wrote:

> Bartolomiej, it's customer-related patches, they, I think, have to
> be done for 6.1 prior to 8+ release.
>
> Dmitry, it's nice to hear about it. Did you consider to use linux
> capabilities on fuel-related processes instead of just using 
> non-extended
> POSIX privileged/non-privileged permission checks?
>
> On Tue, Nov 10, 2015 at 10:11 AM, Bartlomiej Piotrowski <
> bpiotrow...@mirantis.com> wrote:
>
>> We don't develop features for already released versions… It
>> should be done for master instead.
>>
>> BP
>>
>> On Tue, Nov 10, 2015 at 7:02 AM, Adam Heczko <
>> ahec...@mirantis.com> wrote:
>>
>>> Dmitry,
>>> +1
>>>
>>> Do you plan to port your patchset to future Fuel releases?

Re: [openstack-dev] [OpenStack-Infra] Report from Gerrit User Summit

[David Pursehouse]

On Tue, Nov 10, 2015 at 9:53 PM Sean Dague  wrote:
<...>

>
> Is there any update on label:Code-Review<=-1,group:nova-core ? The group
> search support is documented, but as far as I can tell doesn't work
> except under very specific ldap configs.
> https://code.google.com/p/gerrit/issues/detail?id=3018
>
> That would be hugely helpful.
>
>
Khai backported his patch onto the stable-2.11 branch [1] but it wasn't
ready in time to be included in the 2.11.5 release.


[1] https://gerrit-review.googlesource.com/#/c/72470/
__
OpenStack Development Mailing 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] [networking-ovs-dpdk]

[Mooney, Sean K]

Can you provide the ovs-vswitchd log form ${OVS_LOG_DIR}/ovs-vswitchd.log
/tmp/ovs-vswitchd.log in your case.

If the vswitch fails to start we clean up by unmounting the hugepages.



From: Prathyusha Guduri [mailto:prathyushaconne...@gmail.com]
Sent: Tuesday, November 17, 2015 7:37 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-ovs-dpdk]

Hi Sean,
I realised on debugging ovs-dpdk-init script that the main issue is with the 
following command

$ screen -dms ovs-vswitchd sudo sg $qemu_group -c "umask 002; 
${OVS_INSTALL_DIR}/sbin/ovs-vswitchd --dpdk -vhost_sock_dir $OVS_DB_SOCKET_DIR 
-c $OVS_CORE_MASK -n $OVS_MEM_CHANNELS  --proc-type primary  --huge-dir 
$OVS_HUGEPAGE_MOUNT --socket-mem $OVS_SOCKET_MEM $pciAddressWhitelist -- 
unix:$OVS_DB_SOCKET 2>&1 | tee ${OVS_LOG_DIR}/ovs-vswitchd.log"

which I guess is starting the ovs-vswitchd application. Before this command, 
huge pages is mounted and port binding is also done but still the screen 
command fails.
I verified the db.sock and conf.db files.
Any help is highly appreciated.
Thanks,
Prathyusha


On Mon, Nov 16, 2015 at 5:12 PM, Prathyusha Guduri 
mailto:prathyushaconne...@gmail.com>> wrote:
Hi Sean,
Thanks for your response.
in your case though you are using 1GB hugepages so I don’t think this is 
related to memory fragmentation
or a lack of free hugepages.

to use preallocated 1GB page with ovs you should instead set the following in 
your local.conf

OVS_HUGEPAGE_MOUNT_PAGESIZE=1G
OVS_ALLOCATE_HUGEPAGES=False

Added the above two parameters to the local.conf. The same problem again.
Basically it throws this error -
2015-11-16 11:31:44.741 | starting vswitchd
2015-11-16 11:31:44.863 | sudo RTE_SDK=/opt/stack/DPDK-v2.0.0 RTE_TARGET=build 
/opt/stack/DPDK-v2.0.0/tools/dpdk_nic_bind.py -b igb_uio :07:00.0
2015-11-16 11:31:45.169 | sudo ovs-vsctl --no-wait --may-exist add-port br-eth1 
dpdk0 -- set Interface dpdk0 type=dpdk
2015-11-16 11:31:46.314 | Waiting for ovs-vswitchd to start...
2015-11-16 11:31:47.442 | libvirt-bin stop/waiting
2015-11-16 11:31:49.473 | libvirt-bin start/running, process 2255
2015-11-16 11:31:49.477 | [ERROR] /etc/init.d/ovs-dpdk:563 ovs-vswitchd 
application failed to start

manually mounting /mnt/huge and then commenting that part from the 
/etc/init.d/ovs-dpdk script also throws the same error.
Using 1G hugepagesize should not give any memory related problem. I dont 
understand why it is not mounting then.
Here is the /opt/stack/networking-ovs-dpdk/devstack/ovs-dpdk/ovs-dpdk.conf

RTE_SDK=${RTE_SDK:-/opt/stack/DPDK}
RTE_TARGET=${RTE_TARGET:-x86_64-ivshmem-linuxapp-gcc}

OVS_INSTALL_DIR=/usr
OVS_DB_CONF_DIR=/etc/openvswitch
OVS_DB_SOCKET_DIR=/var/run/openvswitch
OVS_DB_CONF=$OVS_DB_CONF_DIR/conf.db
OVS_DB_SOCKET=OVS_DB_SOCKET_DIR/db.sock

OVS_SOCKET_MEM=2048,2048
OVS_MEM_CHANNELS=4
OVS_CORE_MASK=${OVS_CORE_MASK:-2}
OVS_PMD_CORE_MASK=${OVS_PMD_CORE_MASK:-4}
OVS_LOG_DIR=/tmp
OVS_LOCK_DIR=''
OVS_SRC_DIR=/opt/stack/ovs
OVS_DIR=${OVS_DIR:-${OVS_SRC_DIR}}
OVS_UTILS=${OVS_DIR}/utilities/
OVS_DB_UTILS=${OVS_DIR}/ovsdb/
OVS_DPDK_DIR=$RTE_SDK
OVS_NUM_HUGEPAGES=${OVS_NUM_HUGEPAGES:-5}
OVS_HUGEPAGE_MOUNT=${OVS_HUGEPAGE_MOUNT:-/mnt/huge}
OVS_HUGEPAGE_MOUNT_PAGESIZE=''
OVS_BOND_MODE=$OVS_BOND_MODE
OVS_BOND_PORTS=$OVS_BOND_PORTS
OVS_BRIDGE_MAPPINGS=eth1
OVS_PCI_MAPPINGS=:07:00.0#eth1
OVS_DPDK_PORT_MAPPINGS=''
OVS_TUNNEL_CIDR_MAPPING=''
OVS_ALLOCATE_HUGEPAGES=True
OVS_INTERFACE_DRIVER='igb_uio'
Verified the OVS_DB_SOCKET_DIR and all others. conf.db and db.sock exist. So 
why ovs-vswitchd is failing to start??? Am I missing something???


Thanks,
Prathyusha


On Mon, Nov 16, 2015 at 4:39 PM, Mooney, Sean K 
mailto:sean.k.moo...@intel.com>> wrote:

Hi

Yes sorry for the delay in responding to you and samta.

In your case assuming you are using 2mb hugepages it is easy to hit dpdks 
default max memory segments

This can be changed by setting OVS_DPDK_MEM_SEGMENTS=
In the local.conf and recompiling. To do this simply remove the build complete 
file in /opt/stack/ovs
rm –f /opt/stack/BUILD_COMPLETE

in your case though you are using 1GB hugepages so I don’t think this is 
related to memory fragmentation
or a lack of free hugepages.

to use preallocated 1GB page with ovs you should instead set the following in 
your local.conf

OVS_HUGEPAGE_MOUNT_PAGESIZE=1G
OVS_ALLOCATE_HUGEPAGES=False

Regards
sean

From: Prathyusha Guduri 
[mailto:prathyushaconne...@gmail.com]
Sent: Monday, November 16, 2015 6:20 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-ovs-dpdk]

Hi all,

I have a similar problem as Samta. Am also stuck at the same place. The 
following command

$sudo ovs-vsctl br-set-external-id br-ex bridge-id br-ex

hangs forever. As Sean said, it might be because of ovs-vswitchd proces.

> The vswitchd process may exit if it  failed to allocate memory (due to memory 
> fragmentation or l

Re: [openstack-dev] [aodh] HBase gate job

[ZhiQiang Fan]

I prefer to deprecate all drivers except sql, but the upgrade issue
requires us providing some tools to migrate those existent data

On Tue, Nov 17, 2015 at 6:10 PM, Julien Danjou  wrote:

> Hi,
>
> So we recently decided to run the functional tests for the HBase driver
> and enabled the gate job. It turned out the gate job didn't worked, so I
> tried to fix it. Now it's almost fixed, and it run the functional tests
> and Gabbi tests against Aodh with HBase as a back-end:
>
>   https://review.openstack.org/#/c/245585/
>
> Obviously, as you know this is not a real HBase back-end, but a
> in-memory backend that is provided inside Aodh. Now, it turns out that
> this driver or this in-memory backend has a bug, as the Gabbi tests
> fail.
>
> I don't have time nor interest to fix that, so the way I see it it's
> either:
> 1. Someone stands up, determines if the issue is in the driver or the
>in-memory implementation and fix it
> 2. Nobody cares and we drop HBase gate and deprecates the driver
>
> If nobody stands up in the next week, I'll start working on 2.
>
> --
> Julien Danjou
> # Free Software hacker
> # https://julien.danjou.info
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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][Nova][Neutron] Multi-tenancy support

[Vasyl Saienko]

Hello Sean, Jim,

Thanks for your comments.
I've created separate repo:  https://github.com/jumpojoy/generic_switch

--
Sincerely
Vasyl Saienko

On Tue, Nov 17, 2015 at 1:38 AM, Jim Rollenhagen 
wrote:

> On Mon, Nov 16, 2015 at 06:38:28PM +, Sean M. Collins wrote:
> > On Mon, Nov 16, 2015 at 12:47:13PM EST, Vasyl Saienko wrote:
> > > [0] https://github.com/jumpojoy/neutron
> >
> > The way you created the repository in GitHub, it is impossible to diff
> > it against master to see what you did.
> >
> > https://github.com/jumpojoy/neutron/compare
>
> FWIW, it appears to just be a single commit on top of Neutron from about
> a week ago.
>
> https://github.com/jumpojoy/neutron/commits/generic_switch
>
> https://github.com/jumpojoy/neutron/commit/96de518c30459c91c06789fcc6d17a5d29ed3adc
>
> This should totally be a separate repo with just the plugin, though.
>
> // 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 Development Mailing 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] Nova live migration subteam meeting

[Murray, Paul (HP Cloud)]

A quick reminder: the first live migration subteam IRC meeting is today at 1400 
UTC on #openstack-meeting-3.

See: https://wiki.openstack.org/wiki/Meetings/NovaLiveMigration

Regards,
Paul

Paul Murray
Nova Technical Lead, HPE Cloud
Hewlett Packard Enterprise
+44 117 316 2527


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

Re: [openstack-dev] [Openstack-operators] Mirantis Fuel Multi-Region

[Vladimir Kuklin]

Hi Folks

Let me comment on a couple of things. Multiregion support is possible from
deployment side. You need to pass a region parameter to corresponding nodes
being deployed.
It is a part of detached services feature which is delivered through
plugins: "
http://specs.fuel-infra.org/fuel-specs-master/specs/7.0/separate-services.html
"
Please look into this change:
https://review.openstack.org/#/c/191244/

It should allow you to set Region name per-node. You will need just to
download nodes settings and add a corresponding parameter 'region' into
deployment yaml files. This will lead for controllers (or corresponding
nodes roles whether you choos to use separated controller services) to
create endpoints with corresponding region name.
Should you face any issues, please create a bug at Launchpad or contact us
within openstack-dev mailing list with [Fuel] tag in the message or
approach us at #fuel-dev IRC channel.

And another comment regarding multirack installation. In 8.0 we are
planning to enable multiple rack configuration MVP to allow users to be
able to deploy across multiple L2 segments for admin network. Please refer
to https://blueprints.launchpad.net/fuel/+spec/l3-multiple-racks .





On Tue, Nov 17, 2015 at 12:53 PM, Dina Belova  wrote:

> + openstack-dev mailing list to bring more Fuel audience.
>
> On Tue, Nov 17, 2015 at 12:44 PM, Federico Michele Facca <
> federico.fa...@create-net.org> wrote:
>
>> Hi,
>> as said, you need to do manual changes to your deployed nodes.
>> then you will have to:
>> - synch your galera cluster across the two dc
>> - configure properly the load balancers
>> - configure the memcached configuration
>> - register the services of the second region on the new shared keystone
>>
>> Br,
>> Federico
>>
>> PS: I think that you can change the region name in the YAML file using
>> fuel cli (
>> https://docs.mirantis.com/openstack/fuel/fuel-7.0/user-guide.html#cli-usage),
>> but that won't help much honestly, being the trivial of the steps above.
>>
>> --
>> Future Internet is closer than you think!
>> http://www.fiware.org
>>
>> Official Mirantis partner for OpenStack Training
>> https://www.create-net.org/community/openstack-training
>>
>> --
>> Dr. Federico M. Facca
>>
>> CREATE-NET
>> Via alla Cascata 56/D
>> 38123 Povo Trento (Italy)
>>
>> P  +39 0461 312471
>> M +39 334 6049758
>> E  federico.fa...@create-net.org
>> T @chicco785
>> W  www.create-net.org
>>
>> On Tue, Nov 17, 2015 at 10:29 AM, Eren Türkay  wrote:
>>
>>> On 17-11-2015 10:40, Federico Michele Facca wrote:
>>> > Hi Eren,
>>>
>>> Hello Federico
>>>
>>> > afaik, with the new plugin architecture, in fuel 7/8 it should be easy
>>> to
>>> > create a plugin for achieve your goal.
>>> > in case of manual job, depending on your cloud architecture there are
>>> different
>>> > options, the main ones are:
>>> > - you keep a single keystone in a datacenter and register the new
>>> region
>>> > services in there.
>>>
>>> Yes, that's what I am aiming for. I need a single keystone and multiple
>>> endpoints. However, as far as I understand, multi-dc isn't supported yet
>>> on
>>> Mirantis (nor the region name change). Do you know the actual/example
>>> implementation for multi-dc with new plugin architecture? Here are my
>>> findings
>>> regarding to the issue. It seems deploying multi-site with fuel is
>>> really hard
>>> and not supported.
>>>
>>> https://answers.launchpad.net/fuel/+question/267127
>>>
>>> http://lists.openstack.org/pipermail/openstack-dev/2015-October/076298.html
>>>
>>>
>>> --
>>> Eren Türkay, System Administrator
>>> https://skyatlas.com/ | +90 850 885 0357
>>>
>>> Yildiz Teknik Universitesi Davutpasa Kampusu
>>> Teknopark Bolgesi, D2 Blok No:107
>>> Esenler, Istanbul Pk.34220
>>>
>>>
>>
>> ___
>> OpenStack-operators mailing list
>> openstack-operat...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
>
> --
>
> Best regards,
>
> Dina Belova
>
> Software Engineer
>
> Mirantis Inc.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [oslo][All] Make CONF.set_override with paramter enforce_type=True by default

[ChangBo Guo]

Hi ALL,

1. Problems :
   oslo_config provides method CONF.set_override[1] , developers usually
use it to change config option's value in tests. That's convenient .
   By default  parameter enforce_type=False,  it doesn't check any type or
value of override. If set enforce_type=True , will check parameter
   override's type and value.  In production code(running time code),
oslo_config  always checks  config option's value.
   In short, we test and run code in different ways. so there's  gap:
config option with wrong type or invalid value can pass tests when
   parameter enforce_type = False in consuming projects.  that means some
invalid or wrong tests are in our code base.
   There is nova POC result when I enable "enforce_type=true" [2],  and I
must fix them in [3]

   [1]
https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py#L2173
   [2]
http://logs.openstack.org/16/242416/1/check/gate-nova-python27/97b5eff/testr_results.html.gz
   [3]  https://review.openstack.org/#/c/242416/
https://review.openstack.org/#/c/242717/
https://review.openstack.org/#/c/243061/

2. Proposal
   1) Make  method CONF.set_override with  enforce_type=True  in consuming
projects. and  fix violations when  enforce_type=True in each project.

  2) Make  method CONF.set_override with  enforce_type=True by default in
oslo_config

   Hope some one from consuming projects can help make  enforce_type=True
in consuming projects and fix violations,

   You can find more details and comments  in
https://etherpad.openstack.org/p/enforce_type_true_by_default

-- 
ChangBo Guo(gcb)
__
OpenStack Development Mailing 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] [aodh] HBase gate job

[Julien Danjou]

On Tue, Nov 17 2015, ZhiQiang Fan wrote:

> I prefer to deprecate all drivers except sql, but the upgrade issue
> requires us providing some tools to migrate those existent data

It does not require us anything if nobody steps us to do it. :)

-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


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] [OpenStack-Infra] Report from Gerrit User Summit

[Sean Dague]

On 11/17/2015 06:11 AM, David Pursehouse wrote:
> On Tue, Nov 10, 2015 at 9:53 PM Sean Dague  > wrote:
> <...>
> 
> 
> Is there any update on label:Code-Review<=-1,group:nova-core ? The group
> search support is documented, but as far as I can tell doesn't work
> except under very specific ldap configs.
> https://code.google.com/p/gerrit/issues/detail?id=3018
> 
> That would be hugely helpful.
> 
> 
> Khai backported his patch onto the stable-2.11 branch [1] but it wasn't
> ready in time to be included in the 2.11.5 release.
> 
> 
> [1] https://gerrit-review.googlesource.com/#/c/72470/

Very cool, thank you.

Given that it's on track for getting accepted upstream, it's probably
something we could cherry pick into our deploy, as it won't be a
divergence issue.

-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] [tripleo] Location of TripleO REST API

[Dougal Matthews]

On 10 November 2015 at 15:08, Tzu-Mainn Chen  wrote:

> Hi all,
>
> At the last IRC meeting it was agreed that the new TripleO REST API
> should forgo the Tuskar name, and simply be called... the TripleO
> API.  There's one more point of discussion: where should the API
> live?  There are two possibilities:
>
> a) Put it in tripleo-common, where the business logic lives.  If we
> do this, it would make sense to rename tripleo-common to simply
> tripleo.
>

+1 - I think this makes most sense if we are not going to support the
tripleo repo as a library.



> b) Put it in its own repo, tripleo-api
>
>
> The first option made a lot of sense to people on IRC, as the proposed
> API is a very thin layer that's bound closely to the code in tripleo-
> common.  The major objection is that renaming is not trivial; however
> it was mentioned that renaming might not be *too* bad... as long as
> it's done sooner rather than later.
>
> What do people think?
>
>
> Thanks,
> Tzu-Mainn Chen
>
> __
> OpenStack Development Mailing 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] [tripleo] Location of TripleO REST API

[Dougal Matthews]

On 10 November 2015 at 16:12, Giulio Fidente  wrote:

> On 11/10/2015 04:47 PM, Dmitry Tantsur wrote:
>
>> On 11/10/2015 04:37 PM, Giulio Fidente wrote:
>>
>>> On 11/10/2015 04:16 PM, Dmitry Tantsur wrote:
>>>
 On 11/10/2015 04:08 PM, Tzu-Mainn Chen wrote:

> Hi all,
>
> At the last IRC meeting it was agreed that the new TripleO REST API
> should forgo the Tuskar name, and simply be called... the TripleO
> API.  There's one more point of discussion: where should the API
> live?  There are two possibilities:
>
> a) Put it in tripleo-common, where the business logic lives.  If we
> do this, it would make sense to rename tripleo-common to simply
> tripleo.
>

 +1 for both


> b) Put it in its own repo, tripleo-api
>

>>> if both the api (coming) and the cli (currently python-tripleoclient)
>>> are meant to consume the shared code (business logic) from
>>> tripleo-common, then I think it makes sense to keep each in its own repo
>>> ... so that we avoid renaming tripleo-common as well
>>>
>>
>> tripleoclient should not consume tripleo-common
>>
>
> so FWIW I think my vote is different depending on the plans:
>
> a. if python-tripleoclient will be changed so that it uses tripleo-api,
> then I'd vote for option 1) (have tripleo-api in -common and rename)
>

I think this is what we want. Supporting both a Python API and REST API
adds a ton of extra work. It will take some time to transition the CLI
over, but I think it is worth it.



> b. if python-tripleoclient will be changed so that it uses the shared
> library in -common, then I'd vote for for option 2) (have tripleo-api in
> its own repo)
>
>
> on a side note, I think it should always be possible for the deployer to
> skip any business logic to give complete control over the template params
> for both the initial deployments and the updates
> --
> Giulio Fidente
> GPG KEY: 08D733BA | IRC: giulivo
>
> __
> OpenStack Development Mailing 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-infra] Adding new members to new vitrage-dashboard-core group in gerrit is disabled

[GROSZ, Maty (Maty)]

Hello,


Two questions regarding new project init:

1) A new change, https://review.openstack.org/#/c/245671/, was merged earlier.
In the change, I created a new gerrit group - vitrage-dashboard–core.
When I open gerrit UI – I don’t see myself in the list, and I cannot add anyone 
as the option to add is disabled.

2) Looking in launchpad for Vitrage and python-vitrageclient project:
How does the “Series and milestones” section and "Development focus:” in 
launchpad is updated? I only see “trunk” and “trunk series” instead of mitake/ 
and mitaka series

Thanks,

Maty

__
OpenStack Development Mailing 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] [networking-ovs-dpdk]

[Prathyusha Guduri]

Hi Sean,

Here is ovs-vswitchd.log

2015-11-13T12:48:01Z|1|dpdk|INFO|User-provided -vhost_sock_dir in use:
/var/run/openvswitch
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 4 on socket 0
EAL: Detected lcore 5 as core 5 on socket 0
EAL: Detected lcore 6 as core 0 on socket 0
EAL: Detected lcore 7 as core 1 on socket 0
EAL: Detected lcore 8 as core 2 on socket 0
EAL: Detected lcore 9 as core 3 on socket 0
EAL: Detected lcore 10 as core 4 on socket 0
EAL: Detected lcore 11 as core 5 on socket 0
EAL: Support maximum 128 logical core(s) by configuration.
EAL: Detected 12 lcore(s)
EAL: VFIO modules not all loaded, skip VFIO support...
EAL: Searching for IVSHMEM devices...
EAL: No IVSHMEM configuration found!
EAL: Setting up memory...
EAL: Ask a virtual area of 0x18000 bytes
EAL: Virtual area found at 0x7f1e (size = 0x18000)
EAL: remap_all_hugepages(): mmap failed: Cannot allocate memory
EAL: Failed to remap 1024 MB pages
PANIC in rte_eal_init():
Cannot init memory
7: [/usr/sbin/ovs-vswitchd() [0x40b803]]
6: [/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)
[0x7f1fb52d3ec5]]
5: [/usr/sbin/ovs-vswitchd() [0x40a822]]
4: [/usr/sbin/ovs-vswitchd() [0x675432]]
3: [/usr/sbin/ovs-vswitchd() [0x442155]]
2: [/usr/sbin/ovs-vswitchd() [0x407c9f]]
1: [/usr/sbin/ovs-vswitchd() [0x447828]]

Before this hugepages were free and port binding was also done. So I
suspected that this is a DPDK specific issue and found that in
remap_all_hugepages(
) of /opt/stack/DPDK-v2.0.0/lib/librte_eal/linuxapp/eal/eal_memory.c which
first unmaps and then mmaps, there is an issue here and so mmap here fails.
In DPDK mailing list I found that the unmap is taking longer time because
of which mmap fails, so putting a sleep(1) between unmap and map is
supposed to solve the issue. Please check the below link :
https://lists.01.org/pipermail/dpdk-ovs/2014-April/000864.html

After changing so, the ovs-vswitchd command hangs at this place

2015-11-17T10:52:38Z|1|dpdk|INFO|User-provided -vhost_sock_dir in use:
/var/run/openvswitch
2015-11-17 10:52:38.680 | EAL: Detected lcore 0 as core 0 on socket 0
2015-11-17 10:52:38.680 | EAL: Detected lcore 1 as core 1 on socket 0
2015-11-17 10:52:38.680 | EAL: Detected lcore 2 as core 2 on socket 0
2015-11-17 10:52:38.680 | EAL: Detected lcore 3 as core 3 on socket 0
2015-11-17 10:52:38.680 | EAL: Detected lcore 4 as core 4 on socket 0
2015-11-17 10:52:38.680 | EAL: Detected lcore 5 as core 5 on socket 0
2015-11-17 10:52:38.680 | EAL: Detected lcore 6 as core 0 on socket 0
2015-11-17 10:52:38.680 | EAL: Detected lcore 7 as core 1 on socket 0
2015-11-17 10:52:38.680 | EAL: Detected lcore 8 as core 2 on socket 0
2015-11-17 10:52:38.680 | EAL: Detected lcore 9 as core 3 on socket 0
2015-11-17 10:52:38.680 | EAL: Detected lcore 10 as core 4 on socket 0
2015-11-17 10:52:38.680 | EAL: Detected lcore 11 as core 5 on socket 0
2015-11-17 10:52:38.680 | EAL: Support maximum 128 logical core(s) by
configuration.
2015-11-17 10:52:38.680 | EAL: Detected 12 lcore(s)
2015-11-17 10:52:38.687 | EAL: VFIO modules not all loaded, skip VFIO
support...
2015-11-17 10:52:38.687 | EAL: Searching for IVSHMEM devices...
2015-11-17 10:52:38.687 | EAL: No IVSHMEM configuration found!
2015-11-17 10:52:38.687 | EAL: Setting up memory...
2015-11-17 10:52:39.252 | EAL: Ask a virtual area of 0x1c0 bytes
2015-11-17 10:52:39.252 | EAL: Virtual area found at 0x7fcab3a0 (size =
0x1c0)
2015-11-17 10:52:53.265 | EAL: Ask a virtual area of 0x20 bytes
2015-11-17 10:52:53.266 | EAL: Virtual area found at 0x7fcab360 (size =
0x20)
2015-11-17 10:52:54.266 | EAL: Ask a virtual area of 0x20 bytes
2015-11-17 10:52:54.266 | EAL: Virtual area found at 0x7fcab320 (size =
0x20)
2015-11-17 10:52:55.267 | EAL: Ask a virtual area of 0x22c0 bytes
2015-11-17 10:52:55.267 | EAL: Virtual area found at 0x7fca9040 (size =
0x22c0)
2015-11-17 10:57:33.574 | EAL: Ask a virtual area of 0x180 bytes
2015-11-17 10:57:33.574 | EAL: Virtual area found at 0x7fca8ea0 (size =
0x180)
2015-11-17 10:57:45.585 | EAL: Ask a virtual area of 0xd980 bytes
2015-11-17 10:57:45.585 | EAL: Virtual area found at 0x7fc9b500 (size =
0xd980)
2015-11-17 11:26:50.605 | EAL: Ask a virtual area of 0x20 bytes
2015-11-17 11:26:50.605 | EAL: Virtual area found at 0x7fc9b4c0 (size =
0x20)
2015-11-17 11:26:51.606 | EAL: Ask a virtual area of 0x20 bytes
2015-11-17 11:26:51.606 | EAL: Virtual area found at 0x7fc9b480 (size =
0x20)
2015-11-17 11:26:52.608 | EAL: Requesting 1024 pages of size 2MB from
socket 0
2015-11-17 11:26:53.111 | EAL: TSC frequency is ~3491914 KHz
2015-11-17 11:26:53.111 | EAL: Master lcore 1 is ready
(tid=b73cd700;cpuset=[1])
2015-11-17 11:26:53.111 | PMD: ENICPMD trace: rte_enic_pmd_init
2015-11-17 11:26:53.11

Re: [openstack-dev] [nova][libvirt] Native AIO mode - RFC

[Alexander Schmidt]

On Tue, 17 Nov 2015 11:14:29 +0100
Alexander Schmidt  wrote:

> Hi all,
> 
> I started a blueprint [1] and spec [2] for enabling the usage
> of native AIO mode for disk devices. The idea is to enable it
> for storage backends/setups where IO performance benefits from
> using native AIO mode and where no downsides are known wrt
> stability or data integrity.
> 
> As there is a wide range of storage backends and setups, I'm
> looking for input on specific backends that are known to
> benefit from native AIO mode (or where known problems exist).
> These are the comments so far (copied from the spec):
> 
> * native AIO mode is a bad idea if the storage is not fully
>   pre-allocated, e.g. for qcow2 images that grow on
>   demand or sparse LVM storage
> * AIO mode has no effect if using the in-qemu
>   network clients (any disks that use ).
>   It is only relevant if using the in-kernel network drivers
> 
> Cases where AIO mode is beneficial
> 
> * Raw images and pre-allocated images in qcow2 format
> * Cinder volumes that are located on iSCSI, NFS or FC devices.
> * Quobyte (reported by Silvan Kaiser)
> 
> Also input on the minimum libvirt/qemu version where native
> AIO mode should be used would be very helpful.
> 
> Thanks and regards,
> Alex
> 

Adding the links...

[1] https://blueprints.launchpad.net/nova/+spec/libvirt-aio-mode

[2] https://review.openstack.org/#/c/232514/


__
OpenStack Development Mailing 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] [networking-ovs-dpdk]

[Prathyusha Guduri]

Here is stack.sh log -

2015-11-17 13:38:50.010 | Loading uio module
2015-11-17 13:38:50.028 | Loading DPDK UIO module
2015-11-17 13:38:50.038 | starting ovs db
2015-11-17 13:38:50.038 | binding nics
2015-11-17 13:38:50.039 | starting vswitchd
2015-11-17 13:38:50.190 | sudo RTE_SDK=/opt/stack/DPDK-v2.0.0
RTE_TARGET=build /opt/stack/DPDK-v2.0.0/tools/dpdk_nic_bind.py -b igb_uio
:07:00.0
2015-11-17 13:38:50.527 | sudo ovs-vsctl --no-wait --may-exist add-port
br-eth1 dpdk0 -- set Interface dpdk0 type=dpdk
2015-11-17 13:38:51.671 | Waiting for ovs-vswitchd to start...
2015-11-17 13:38:52.685 | Waiting for ovs-vswitchd to start...
2015-11-17 13:38:53.702 | Waiting for ovs-vswitchd to start...
2015-11-17 13:38:54.720 | Waiting for ovs-vswitchd to start...
2015-11-17 13:38:55.733 | Waiting for ovs-vswitchd to start...
2015-11-17 13:38:56.749 | Waiting for ovs-vswitchd to start...
2015-11-17 13:38:57.768 | Waiting for ovs-vswitchd to start...
2015-11-17 13:38:58.787 | Waiting for ovs-vswitchd to start...
2015-11-17 13:38:59.802 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:00.818 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:01.836 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:02.849 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:03.866 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:04.884 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:05.905 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:06.923 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:07.937 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:08.956 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:09.973 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:10.988 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:12.004 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:13.022 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:14.040 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:15.060 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:16.073 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:17.089 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:18.108 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:19.121 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:20.138 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:21.156 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:22.169 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:23.185 | Waiting for ovs-vswitchd to start...



On Tue, Nov 17, 2015 at 6:50 PM, Prathyusha Guduri <
prathyushaconne...@gmail.com> wrote:

> Hi Sean,
>
> Here is ovs-vswitchd.log
>
> 2015-11-13T12:48:01Z|1|dpdk|INFO|User-provided -vhost_sock_dir in use:
> /var/run/openvswitch
> EAL: Detected lcore 0 as core 0 on socket 0
> EAL: Detected lcore 1 as core 1 on socket 0
> EAL: Detected lcore 2 as core 2 on socket 0
> EAL: Detected lcore 3 as core 3 on socket 0
> EAL: Detected lcore 4 as core 4 on socket 0
> EAL: Detected lcore 5 as core 5 on socket 0
> EAL: Detected lcore 6 as core 0 on socket 0
> EAL: Detected lcore 7 as core 1 on socket 0
> EAL: Detected lcore 8 as core 2 on socket 0
> EAL: Detected lcore 9 as core 3 on socket 0
> EAL: Detected lcore 10 as core 4 on socket 0
> EAL: Detected lcore 11 as core 5 on socket 0
> EAL: Support maximum 128 logical core(s) by configuration.
> EAL: Detected 12 lcore(s)
> EAL: VFIO modules not all loaded, skip VFIO support...
> EAL: Searching for IVSHMEM devices...
> EAL: No IVSHMEM configuration found!
> EAL: Setting up memory...
> EAL: Ask a virtual area of 0x18000 bytes
> EAL: Virtual area found at 0x7f1e (size = 0x18000)
> EAL: remap_all_hugepages(): mmap failed: Cannot allocate memory
> EAL: Failed to remap 1024 MB pages
> PANIC in rte_eal_init():
> Cannot init memory
> 7: [/usr/sbin/ovs-vswitchd() [0x40b803]]
> 6: [/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)
> [0x7f1fb52d3ec5]]
> 5: [/usr/sbin/ovs-vswitchd() [0x40a822]]
> 4: [/usr/sbin/ovs-vswitchd() [0x675432]]
> 3: [/usr/sbin/ovs-vswitchd() [0x442155]]
> 2: [/usr/sbin/ovs-vswitchd() [0x407c9f]]
> 1: [/usr/sbin/ovs-vswitchd() [0x447828]]
>
> Before this hugepages were free and port binding was also done. So I
> suspected that this is a DPDK specific issue and found that in 
> remap_all_hugepages(
> ) of /opt/stack/DPDK-v2.0.0/lib/librte_eal/linuxapp/eal/eal_memory.c
> which first unmaps and then mmaps, there is an issue here and so mmap here
> fails. In DPDK mailing list I found that the unmap is taking longer time
> because of which mmap fails, so putting a sleep(1) between unmap and map is
> supposed to solve the issue. Please check the below link :
> https://lists.01.org/pipermail/dpdk-ovs/2014-April/000864.html
>
> After changing so, the ovs-vswitchd command hangs at this place
>
> 2015-11-17T10:52:38Z|1|dpdk|INFO|User-provided -vhost_sock_dir in use:
> /var/run/openvswitch
> 2015-11-17 10:52:38.680 | EAL: Detected lcore 0 as core 0 on soc

Re: [openstack-dev] [aodh] HBase gate job

[gord chung]

let's change this gate to experimental for now.

On 17/11/15 05:10 AM, Julien Danjou wrote:

Hi,

So we recently decided to run the functional tests for the HBase driver
and enabled the gate job. It turned out the gate job didn't worked, so I
tried to fix it. Now it's almost fixed, and it run the functional tests
and Gabbi tests against Aodh with HBase as a back-end:

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

Obviously, as you know this is not a real HBase back-end, but a
in-memory backend that is provided inside Aodh. Now, it turns out that
this driver or this in-memory backend has a bug, as the Gabbi tests
fail.

I don't have time nor interest to fix that, so the way I see it it's
either:
1. Someone stands up, determines if the issue is in the driver or the
in-memory implementation and fix it
2. Nobody cares and we drop HBase gate and deprecates the driver

If nobody stands up in the next week, I'll start working on 2.



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


--
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] [aodh] HBase gate job

[Nadya Shakhat]

Hi folks,

Sorry I missed the letter. I'll take a look on this. As I understand, it's
enough just to run functional tests to see the issue, right?

Nadya

On Tue, Nov 17, 2015 at 4:48 PM, gord chung  wrote:

> let's change this gate to experimental for now.
>
> On 17/11/15 05:10 AM, Julien Danjou wrote:
>
> Hi,
>
> So we recently decided to run the functional tests for the HBase driver
> and enabled the gate job. It turned out the gate job didn't worked, so I
> tried to fix it. Now it's almost fixed, and it run the functional tests
> and Gabbi tests against Aodh with HBase as a back-end:
>
>   https://review.openstack.org/#/c/245585/
>
> Obviously, as you know this is not a real HBase back-end, but a
> in-memory backend that is provided inside Aodh. Now, it turns out that
> this driver or this in-memory backend has a bug, as the Gabbi tests
> fail.
>
> I don't have time nor interest to fix that, so the way I see it it's
> either:
> 1. Someone stands up, determines if the issue is in the driver or the
>in-memory implementation and fix it
> 2. Nobody cares and we drop HBase gate and deprecates the driver
>
> If nobody stands up in the next week, I'll start working on 2.
>
>
>
>
> __
> 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
>
>
> --
> 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

[openstack-dev] [Fuel] HA cluster disk monitoring, failover and recovery

[Kyrylo Galanov]

Hi Team,

I have been testing fail-over after free disk space is less than 512 mb. (
https://review.openstack.org/#/c/240951/)
Affected node is stopped correctly and services migrate to a healthy node.

However, after free disk space is more than 512 mb again the node does not
recover it's state to operating. Moreover, starting the resources manually
would rather fail. In a nutshell, the pacemaker service / node should be
restarted. Detailed information is available here:
https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_monitor_health.html

How do we address this issue?


Best regards,
Kyrylo
__
OpenStack Development Mailing 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] [mistral] Notifier about changes in the dsvm gates structure

[Anastasia Kuznetsova]

Hello Everyone,

This is a notifier about the fact that Mistral team is on the way of
refactoring of current Jenkins dsvm gates infrastructure.
The final goal is to have voting dsvm gates which will run on every commit
to mistral and mistralclient repositories.

What we have now:
- mistral repository:
gate-mistral-devstack-dsvm job that installs mistral from commit and
python-mistralclient from master,
it runs both suite of tests on every commit: API tests from mistral
repository and CLI tests from python-mistralclient repository;
- mistralclient repository:
gate-mistral-devstack-dsvm job that installs python-mistralclient from
commit and mistral from master,
it runs suite of CLI tests from python-mistralclient repository.

As you can see, there is only job template for both repositories.

What we will have (or what other projects have now):
- mistral repository:
gate-mistral-devstack-dsvm job that will install mistral from commit and
latest released python-mistralclient
(version will be taken according requirements), it will run only API tests
from mistral repository.
- mistralclient repository:
gate-mistralclient-devstack-dsvm job that will install python-mistralclient
from commit and mistral from master,
it will run suite of CLI tests from python-mistralclient repository.

As a result, we will have two separate job templates, in each of them we
will run its own suite of tests.

I've created appropriate blueprint for these changes
mistral-making-dsvm-gates-voting

 and
I am going to start work on its implementation.


-- 
Best regards,
Anastasia Kuznetsova
__
OpenStack Development Mailing 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] [networking-ovs-dpdk]

[Mooney, Sean K]

We mainly test with 2M hugepages not 1G however our ci does use 1G pages.
We recently noticed a different but unrelated related issue with using the 
ivshmem target when building dpdk.
(https://bugs.launchpad.net/networking-ovs-dpdk/+bug/1517032)

Instead of modifying dpdk can you try
Changing the default dpdk build target to x86_64-native-linuxapp-gcc.

This can be done by  adding

RTE_TARGET=x86_64-native-linuxapp-gcc to the local.conf
And removing the following file to force a rebuild 
“/opt/stack/ovs/BUILD_COMPLETE”

I agree with your assessment though this appears to be a timing issue in dpdk 
2.0



From: Prathyusha Guduri [mailto:prathyushaconne...@gmail.com]
Sent: Tuesday, November 17, 2015 1:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-ovs-dpdk]

Here is stack.sh log -

2015-11-17 13:38:50.010 | Loading uio module
2015-11-17 13:38:50.028 | Loading DPDK UIO module
2015-11-17 13:38:50.038 | starting ovs db
2015-11-17 13:38:50.038 | binding nics
2015-11-17 13:38:50.039 | starting vswitchd
2015-11-17 13:38:50.190 | sudo RTE_SDK=/opt/stack/DPDK-v2.0.0 RTE_TARGET=build 
/opt/stack/DPDK-v2.0.0/tools/dpdk_nic_bind.py -b igb_uio :07:00.0
2015-11-17 13:38:50.527 | sudo ovs-vsctl --no-wait --may-exist add-port br-eth1 
dpdk0 -- set Interface dpdk0 type=dpdk
2015-11-17 13:38:51.671 | Waiting for ovs-vswitchd to start...
2015-11-17 13:38:52.685 | Waiting for ovs-vswitchd to start...
2015-11-17 13:38:53.702 | Waiting for ovs-vswitchd to start...
2015-11-17 13:38:54.720 | Waiting for ovs-vswitchd to start...
2015-11-17 13:38:55.733 | Waiting for ovs-vswitchd to start...
2015-11-17 13:38:56.749 | Waiting for ovs-vswitchd to start...
2015-11-17 13:38:57.768 | Waiting for ovs-vswitchd to start...
2015-11-17 13:38:58.787 | Waiting for ovs-vswitchd to start...
2015-11-17 13:38:59.802 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:00.818 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:01.836 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:02.849 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:03.866 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:04.884 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:05.905 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:06.923 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:07.937 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:08.956 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:09.973 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:10.988 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:12.004 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:13.022 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:14.040 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:15.060 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:16.073 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:17.089 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:18.108 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:19.121 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:20.138 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:21.156 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:22.169 | Waiting for ovs-vswitchd to start...
2015-11-17 13:39:23.185 | Waiting for ovs-vswitchd to start...


On Tue, Nov 17, 2015 at 6:50 PM, Prathyusha Guduri 
mailto:prathyushaconne...@gmail.com>> wrote:
Hi Sean,
Here is ovs-vswitchd.log

2015-11-13T12:48:01Z|1|dpdk|INFO|User-provided -vhost_sock_dir in use: 
/var/run/openvswitch
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 4 on socket 0
EAL: Detected lcore 5 as core 5 on socket 0
EAL: Detected lcore 6 as core 0 on socket 0
EAL: Detected lcore 7 as core 1 on socket 0
EAL: Detected lcore 8 as core 2 on socket 0
EAL: Detected lcore 9 as core 3 on socket 0
EAL: Detected lcore 10 as core 4 on socket 0
EAL: Detected lcore 11 as core 5 on socket 0
EAL: Support maximum 128 logical core(s) by configuration.
EAL: Detected 12 lcore(s)
EAL: VFIO modules not all loaded, skip VFIO support...
EAL: Searching for IVSHMEM devices...
EAL: No IVSHMEM configuration found!
EAL: Setting up memory...
EAL: Ask a virtual area of 0x18000 bytes
EAL: Virtual area found at 0x7f1e (size = 0x18000)
EAL: remap_all_hugepages(): mmap failed: Cannot allocate memory
EAL: Failed to remap 1024 MB pages
PANIC in rte_eal_init():
Cannot init memory
7: [/usr/sbin/ovs-vswitchd() [0x40b803]]
6: [/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f1fb52d3ec5]]
5: [/usr/sbin/ovs-vswitchd() [0x40a822]]
4: [/usr/sbin/ovs-vswitchd() [0x675432]]
3: [/usr/sbin/ovs-vswitchd() [0x442155]]
2: [/usr/sbin/ovs-vswitchd() [0x407c9f]]
1: [/usr/sbin/ovs-vswitchd() [0x447828]]
Before this hugepages were free and port binding was also d

Re: [openstack-dev] [Fuel] HA cluster disk monitoring, failover and recovery

[Alex Schultz]

Hey Kyrylo,


On Tue, Nov 17, 2015 at 8:28 AM, Kyrylo Galanov  wrote:
> Hi Team,
>
> I have been testing fail-over after free disk space is less than 512 mb.
> (https://review.openstack.org/#/c/240951/)
> Affected node is stopped correctly and services migrate to a healthy node.
>
> However, after free disk space is more than 512 mb again the node does not
> recover it's state to operating. Moreover, starting the resources manually
> would rather fail. In a nutshell, the pacemaker service / node should be
> restarted. Detailed information is available here:
> https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_monitor_health.html
>
> How do we address this issue?
>

So the original change for this was
https://review.openstack.org/#/c/226062/. As indicated by the commit
message, the only way pacemaker will recover is that the operator must
run a pacemaker command to clear the disk alert.

crm node status-attr  delete "#health_disk"

Once the operator has cleared up the diskspace issue and run the above
command, pacemaker will rejoin the cluster and start services again.
The documentation bug for this is
https://bugs.launchpad.net/fuel/+bug/1500422.

Thanks,
-Alex

>
> Best regards,
> Kyrylo
>
> __
> OpenStack Development Mailing 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] [Manila] Attach/detach semantics

[John Spray]

Hi all,

As you may know, there is ongoing work on a spec for Nova to define an
"attach/detach" API for tighter integration with Manila.

The concept here is that this mechanism will be needed to implement
hypervisor mediated FS access using vsock, but that the mechanism
should also be applicable more generally to an "attach" concept for
filesystems accessed over IP networks (like existing NFS filers).

In the hypervisor-mediated case, attach would involve the hypervisor
host connecting as a filesystem client and then re-exporting to the
guest via a local address.  We think this would apply to
driver_handles_share_servers type drivers that support share networks,
by mapping the attach/detach share API to attaching/detaching the
share network from the guest VM.

Does that make sense to people maintaining this type of driver?  For
example, for the netapp and generic drivers, is it reasonable to
expose nova attach/detach APIs that attach and detach the associated
share network?

I've CC'd Luis who is working on the Nova spec.

Regards,
John

__
OpenStack Development Mailing 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] HA cluster disk monitoring, failover and recovery

[Vladimir Kuklin]

Folks

Is not it possible for an OCF script to clear this attribute after a
sufficient period of successful monitoring of node health? It could be a
better approach in this case then restarting the node.

On Tue, Nov 17, 2015 at 5:41 PM, Alex Schultz  wrote:

> Hey Kyrylo,
>
>
> On Tue, Nov 17, 2015 at 8:28 AM, Kyrylo Galanov 
> wrote:
> > Hi Team,
> >
> > I have been testing fail-over after free disk space is less than 512 mb.
> > (https://review.openstack.org/#/c/240951/)
> > Affected node is stopped correctly and services migrate to a healthy
> node.
> >
> > However, after free disk space is more than 512 mb again the node does
> not
> > recover it's state to operating. Moreover, starting the resources
> manually
> > would rather fail. In a nutshell, the pacemaker service / node should be
> > restarted. Detailed information is available here:
> >
> https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_monitor_health.html
> >
> > How do we address this issue?
> >
>
> So the original change for this was
> https://review.openstack.org/#/c/226062/. As indicated by the commit
> message, the only way pacemaker will recover is that the operator must
> run a pacemaker command to clear the disk alert.
>
> crm node status-attr  delete "#health_disk"
>
> Once the operator has cleared up the diskspace issue and run the above
> command, pacemaker will rejoin the cluster and start services again.
> The documentation bug for this is
> https://bugs.launchpad.net/fuel/+bug/1500422.
>
> Thanks,
> -Alex
>
> >
> > Best regards,
> > Kyrylo
> >
> >
> __
> > OpenStack Development Mailing 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
>



-- 
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
__
OpenStack Development Mailing 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] [aodh] HBase gate job

[Julien Danjou]

On Tue, Nov 17 2015, Nadya Shakhat wrote:

> Sorry I missed the letter. I'll take a look on this. As I understand, it's
> enough just to run functional tests to see the issue, right?

Yes, with my patch it should be pretty easy to reproduce.

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


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] Running Fuel node as non-superuser

[Dmitry Nikishov]

Stanislaw, do you mean the whole feature, or just a user? Since feature
would require actually changing puppet code.

On Tue, Nov 17, 2015 at 5:08 AM, Stanislaw Bogatkin 
wrote:

> Dmitry, I believe it should be done via package spec as a part of
> installation.
>
> On Mon, Nov 16, 2015 at 8:04 PM, Dmitry Nikishov 
> wrote:
>
>> Hello folks,
>>
>> I have updated the spec, please review and share your thoughts on it:
>> https://review.openstack.org/#/c/243340/
>>
>> Thanks.
>>
>> On Thu, Nov 12, 2015 at 10:42 AM, Dmitry Nikishov > > wrote:
>>
>>> Matthew,
>>>
>>> sorry, didn't mean to butcher your name :(
>>>
>>> On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov <
>>> dnikis...@mirantis.com> wrote:
>>>
 Matther,

 I totally agree that each daemon should have it's own user which should
 be created during installation of the relevant package. Probably I didn't
 state this clear enough in the spec.

 However, there are security requirements in place that root should not
 be used at all. This means that there should be a some kind of maintenance
 or system user ('fueladmin'), which would have enough privileges to
 configure and manage Fuel node (e.g. run "sudo puppet apply" without
 password, create mirrors etc). This also means that certain fuel- packages
 would be required to have their files accessible to that user. That's the
 idea behind having a package which would create 'fueladmin' user and
 including it into other fuel- packages requirements lists.

 So this part of the feature comes down to having a non-root user with
 sudo privileges and passwordless sudo for certain commands (like 'puppet
 apply ') for scripting.

 On Thu, Nov 12, 2015 at 9:52 AM, Matthew Mosesohn <
 mmoses...@mirantis.com> wrote:

> Dmitry,
>
> We really shouldn't put "user" creation into a single package and then
> depend on it for daemons. If we want nailgun service to run as nailgun
> user, it should be created in the fuel-nailgun package.
> I think it makes the most sense to create multiple users, one for each
> service.
>
> Lastly, it makes a lot of sense to tie a "fuel" CLI user to
> python-fuelclient package.
>
> On Thu, Nov 12, 2015 at 6:42 PM, Dmitry Nikishov <
> dnikis...@mirantis.com> wrote:
>
>> Stanislaw,
>>
>> I agree that this approch would work well. However, does Puppet allow
>> managing capabilities and/or file ACLs? Or can they be easily set up when
>> installing RPM package? (is there a way to specify capabilities/ACLs in 
>> the
>> RPM spec file?) This doesn't seem to be supported out of the box.
>>
>> I'm going to research if it is possible to manage capabilities and
>>  ACLs with what we have out of the box (RPM, Puppet).
>>
>> On Wed, Nov 11, 2015 at 4:29 AM, Stanislaw Bogatkin <
>> sbogat...@mirantis.com> wrote:
>>
>>> Dmitry, I propose to give needed linux capabilities
>>> (like CAP_NET_BIND_SERVICE) to processes (services) which needs them and
>>> then start these processes from non-privileged user. It will give you
>>> ability to run each process without 'sudo' at all with well fine-grained
>>> permissions.
>>>
>>> On Tue, Nov 10, 2015 at 11:06 PM, Dmitry Nikishov <
>>> dnikis...@mirantis.com> wrote:
>>>
 Stanislaw,

 I've been experimenting with 'capsh' on the 6.1 master node and it
 doesn't seem to preserve any capabilities when setting SECURE_NOROOT 
 bit,
 even if explicitely told to do so (via either --keep=1 or
 "SECURE_KEEP_CAPS" bit).

 On Tue, Nov 10, 2015 at 11:20 AM, Dmitry Nikishov <
 dnikis...@mirantis.com> wrote:

> Bartolomiej, Adam,
> Stanislaw is correct. And this is going to be ported to master.
> The goal currently is to reach an agreement on the implementation so 
> that
> there's going to be a some kinf of compatibility during upgrades.
>
> Stanislaw,
> Do I understand correctly that you propose using something like
> sucap to launch from root, switch to a different user and then drop
> capabilities which are not required?
>
> On Tue, Nov 10, 2015 at 3:11 AM, Stanislaw Bogatkin <
> sbogat...@mirantis.com> wrote:
>
>> Bartolomiej, it's customer-related patches, they, I think, have
>> to be done for 6.1 prior to 8+ release.
>>
>> Dmitry, it's nice to hear about it. Did you consider to use linux
>> capabilities on fuel-related processes instead of just using 
>> non-extended
>> POSIX privileged/non-privileged permission checks?
>>
>> On Tue, Nov 10, 2015 at 10:11 AM, Bartlomiej Piotrowski <
>> bpiotrow...@mirantis.com> wrote:
>>
>>> We don't develop features for al

[openstack-dev] [all] Skipping cross-project meeting today

[Thierry Carrez]

Hi everyone,

Since Everett can't really make the cross-project meeting today, we
don't have anything on the agenda to discuss. We'll therefore skip the
meeting later today, although a bunch of us will be around on
#openstack-meeting at that time and we can have an informal discussion
if anyone wants to.

NB: Mike and Anne are still coming up with a final proposal on how to
reform cross-project meetings and cross-project spec workflow. I suspect
they will post when both are back from vacation (probably next week).

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Fuel] HA cluster disk monitoring, failover and recovery

[Alex Schultz]

On Tue, Nov 17, 2015 at 9:01 AM, Vladimir Kuklin  wrote:
> Folks
>
> Is not it possible for an OCF script to clear this attribute after a
> sufficient period of successful monitoring of node health? It could be a
> better approach in this case then restarting the node.
>

So this leverages the pacemaker provided sysinfo and leverages core
pacemaker/corosync functionality.  We'd have to look into the core of
that to see if it would be possible to have it automatically mark the
node cleared if the space gets cleared up. (essentially clearing the
health_disk status attribute)  You do not have to reboot/restart the
node. You simply clear the alarm and the services automatically start
back up.  As I have previously mentioned about this change, it is not
a replacement for proper system monitoring and ensuring node health.
This is simply a minor improvement to ensure that the cluster doesn't
crash itself when it runs out of space. The goal of change was to
ensure that rabbitmq/mysql/etc are cleanly shutdown prior to a
critical lack of disk space which can lead to the systems melting
down.

Thanks,
-Alex

> On Tue, Nov 17, 2015 at 5:41 PM, Alex Schultz  wrote:
>>
>> Hey Kyrylo,
>>
>>
>> On Tue, Nov 17, 2015 at 8:28 AM, Kyrylo Galanov 
>> wrote:
>> > Hi Team,
>> >
>> > I have been testing fail-over after free disk space is less than 512 mb.
>> > (https://review.openstack.org/#/c/240951/)
>> > Affected node is stopped correctly and services migrate to a healthy
>> > node.
>> >
>> > However, after free disk space is more than 512 mb again the node does
>> > not
>> > recover it's state to operating. Moreover, starting the resources
>> > manually
>> > would rather fail. In a nutshell, the pacemaker service / node should be
>> > restarted. Detailed information is available here:
>> >
>> > https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_monitor_health.html
>> >
>> > How do we address this issue?
>> >
>>
>> So the original change for this was
>> https://review.openstack.org/#/c/226062/. As indicated by the commit
>> message, the only way pacemaker will recover is that the operator must
>> run a pacemaker command to clear the disk alert.
>>
>> crm node status-attr  delete "#health_disk"
>>
>> Once the operator has cleared up the diskspace issue and run the above
>> command, pacemaker will rejoin the cluster and start services again.
>> The documentation bug for this is
>> https://bugs.launchpad.net/fuel/+bug/1500422.
>>
>> Thanks,
>> -Alex
>>
>> >
>> > Best regards,
>> > Kyrylo
>> >
>> >
>> > __
>> > OpenStack Development Mailing 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
>
>
>
>
> --
> 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
>
> __
> OpenStack Development Mailing 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] [OSC] Quick poll: OpenStackClient command for provision action

[Jim Rollenhagen]

On Tue, Nov 10, 2015 at 12:19:08PM +, Sam Betts (sambetts) wrote:
> So you would end up with a set of commands that look like this:

After reading through this thread, I think this is mostly good, other
than some word choices. I've changed a few inline to feel more natural
(IMHO of course). :)
> 
> Openstack baremetal [node/driver/chassis] list
> Openstack baremetal port list [-node uuid] <- replicate node-port-list
> 
> Openstack baremetal [node/port/driver] show UUID
> Openstack baremetal chassis show [-nodes] UUID  <- replicate chassis-node-list
> 
> Openstack baremetal [node/chassis/port] create
> Openstack baremetal [node/chassis/port] update UUID
> Openstack baremetal [node/chassis/port] delete UUID
> 
> Openstack baremetal [node/chassis] provide UUID
> Openstack baremetal [node/chassis] activate UUID

I prefer 'provision' here.

> Openstack baremetal [node/chassis] rebuild UUID
> Openstack baremetal [node/chassis] inspect UUID
> Openstack baremetal [node/chassis] manage UUID
> Openstack baremetal [node/chassis] abort UUID
> Openstack baremetal [node/chassis] boot UUID
> Openstack baremetal [node/chassis] shutdown UUID

I'd prefer power on / power off.

> Openstack baremetal [node/chassis] reboot UUID
> 
> Openstack baremetal node maintain [-done] UUID

Not sure what the best is here. With my ops hat on, we say things like
"I'm going to maintenance/unmaintenance that node". However it's weird,
because 'unmaintenance' doesn't appear to be a real word. :)
Regardless, I'm not a fan of 'maintain', I think it's a completely
different meaning altogether.

> Openstack baremetal node console [-enable, -disable] UUID <- With no 
> parameters this acts like node-get-console, otherwise acts like 
> node-set-console-mode
> Openstack baremetal node boot-device [-supported, -PXE, -CDROM, etc] UUID <- 
> With no parameters this acts like node-get-boot-device, -supported makes it 
> act like node-get-supported-boot-devices, and with a type of boot device 
> passed in it’ll act like node-set-boot-device

Somewhat in line with what Dean said, I'd prefer less options here.
Though, maybe we don't need any?
Maybe 'node boot device pxe' and 'node boot device cdrom' just work.
Feels close to something I'd say out loud.

> 
> Openstack baremetal [node/driver] passthru

This one is odd because 'passthru' is pretty arbitrary in our API. Maybe
'node vendor ' is better? Or should we just leave this out of OSC
as it's pretty difficult to define the subcommands?

> 
> WDYT? I think I’ve covered most of what exists in the Ironic CLI currently.

Thanks for making this list - I'm looking forward to someone writing a
short spec. :)

// 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] [tripleo] Location of TripleO REST API

[Tzu-Mainn Chen]

- Original Message -

> On 10 November 2015 at 15:08, Tzu-Mainn Chen < tzuma...@redhat.com > wrote:

> > Hi all,
> 

> > At the last IRC meeting it was agreed that the new TripleO REST API
> 
> > should forgo the Tuskar name, and simply be called... the TripleO
> 
> > API. There's one more point of discussion: where should the API
> 
> > live? There are two possibilities:
> 

> > a) Put it in tripleo-common, where the business logic lives. If we
> 
> > do this, it would make sense to rename tripleo-common to simply
> 
> > tripleo.
> 

> +1 - I think this makes most sense if we are not going to support the tripleo
> repo as a library.

Okay, this seems to be the consensus, which is great. 

The leftover question is how to package the renamed repo. 'tripleo' is already 
intuitively in use by tripleo-incubator. 
In IRC, bnemec and trown suggested splitting the renamed repo into two packages 
- 'python-tripleo' and 'tripleo-api', 
which seems sensible to me. 

What do others think? 

Mainn 

> > b) Put it in its own repo, tripleo-api
> 

> > The first option made a lot of sense to people on IRC, as the proposed
> 
> > API is a very thin layer that's bound closely to the code in tripleo-
> 
> > common. The major objection is that renaming is not trivial; however
> 
> > it was mentioned that renaming might not be *too* bad... as long as
> 
> > it's done sooner rather than later.
> 

> > What do people think?
> 

> > Thanks,
> 
> > Tzu-Mainn Chen
> 

> > __
> 
> > OpenStack Development Mailing 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] [oslo][All] Make CONF.set_override with paramter enforce_type=True by default

[Doug Hellmann]

Excerpts from ChangBo Guo's message of 2015-11-17 20:29:53 +0800:
> Hi ALL,
> 
> 1. Problems :
>oslo_config provides method CONF.set_override[1] , developers usually
> use it to change config option's value in tests. That's convenient .
>By default  parameter enforce_type=False,  it doesn't check any type or
> value of override. If set enforce_type=True , will check parameter
>override's type and value.  In production code(running time code),
> oslo_config  always checks  config option's value.
>In short, we test and run code in different ways. so there's  gap:
> config option with wrong type or invalid value can pass tests when
>parameter enforce_type = False in consuming projects.  that means some
> invalid or wrong tests are in our code base.
>There is nova POC result when I enable "enforce_type=true" [2],  and I
> must fix them in [3]
> 
>[1]
> https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py#L2173
>[2]
> http://logs.openstack.org/16/242416/1/check/gate-nova-python27/97b5eff/testr_results.html.gz
>[3]  https://review.openstack.org/#/c/242416/
> https://review.openstack.org/#/c/242717/
> https://review.openstack.org/#/c/243061/
> 
> 2. Proposal
>1) Make  method CONF.set_override with  enforce_type=True  in consuming
> projects. and  fix violations when  enforce_type=True in each project.

Tracking this to ensure we don't break anything will be important.

I like the idea of changing that default.  Thanks for taking on
this work!

Doug

> 
>   2) Make  method CONF.set_override with  enforce_type=True by default in
> oslo_config
> 
>Hope some one from consuming projects can help make  enforce_type=True
> in consuming projects and fix violations,
> 
>You can find more details and comments  in
> https://etherpad.openstack.org/p/enforce_type_true_by_default
> 

__
OpenStack Development Mailing 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] Troubleshooting cross-project comms

[James E. Blair]

Sean Dague  writes:

> Has anyone considered using #openstack-dev, instead of a new meeting
> room? #openstack-dev is mostly a ghost town at this point, and deciding
> that instead it would be the dedicated cross project space, including
> meetings support, might be interesting.

I agree it might be interesting, but why is it better than having a
dedicated cross-project meeting channel?  If your idea is successful,
then periodically the -dev channel will be unavailable for general
(cross-project!) developer communication.  Why not make a cross-project
meeting channel?  It's not hard to make new meeting channels and its not
hard to join them.  Is the idea to try to re-invigorate the -dev channel
by holding meetings there?

-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] [oslo][All] Make CONF.set_override with paramter enforce_type=True by default

[Davanum Srinivas]

+1 to what Doug said. Thanks ChangBo!

-- dims

On Tue, Nov 17, 2015 at 10:47 AM, Doug Hellmann  wrote:
> Excerpts from ChangBo Guo's message of 2015-11-17 20:29:53 +0800:
>> Hi ALL,
>>
>> 1. Problems :
>>oslo_config provides method CONF.set_override[1] , developers usually
>> use it to change config option's value in tests. That's convenient .
>>By default  parameter enforce_type=False,  it doesn't check any type or
>> value of override. If set enforce_type=True , will check parameter
>>override's type and value.  In production code(running time code),
>> oslo_config  always checks  config option's value.
>>In short, we test and run code in different ways. so there's  gap:
>> config option with wrong type or invalid value can pass tests when
>>parameter enforce_type = False in consuming projects.  that means some
>> invalid or wrong tests are in our code base.
>>There is nova POC result when I enable "enforce_type=true" [2],  and I
>> must fix them in [3]
>>
>>[1]
>> https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py#L2173
>>[2]
>> http://logs.openstack.org/16/242416/1/check/gate-nova-python27/97b5eff/testr_results.html.gz
>>[3]  https://review.openstack.org/#/c/242416/
>> https://review.openstack.org/#/c/242717/
>> https://review.openstack.org/#/c/243061/
>>
>> 2. Proposal
>>1) Make  method CONF.set_override with  enforce_type=True  in consuming
>> projects. and  fix violations when  enforce_type=True in each project.
>
> Tracking this to ensure we don't break anything will be important.
>
> I like the idea of changing that default.  Thanks for taking on
> this work!
>
> Doug
>
>>
>>   2) Make  method CONF.set_override with  enforce_type=True by default in
>> oslo_config
>>
>>Hope some one from consuming projects can help make  enforce_type=True
>> in consuming projects and fix violations,
>>
>>You can find more details and comments  in
>> https://etherpad.openstack.org/p/enforce_type_true_by_default
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] [Fuel] HA cluster disk monitoring, failover and recovery

[Bogdan Dobrelya]

On 17.11.2015 15:28, Kyrylo Galanov wrote:
> Hi Team,

Hello

> 
> I have been testing fail-over after free disk space is less than 512 mb.
> (https://review.openstack.org/#/c/240951/)
> Affected node is stopped correctly and services migrate to a healthy node.
> 
> However, after free disk space is more than 512 mb again the node does
> not recover it's state to operating. Moreover, starting the resources
> manually would rather fail. In a nutshell, the pacemaker service / node
> should be restarted. Detailed information is available
> here: 
> https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_monitor_health.html
> 
> How do we address this issue?

According to the docs you provided,
" After a node's health status has turned to red, solve the issue that
led to the problem. Then clear the red status to make the node eligible
again for running resources. Log in to the cluster node and use one of
the following methods:

Execute the following command:

crm node status-attr NODE delete #health_disk

Restart OpenAIS on that node.

Reboot the node.

The node will be returned to service and can run resources again. "

So this looks like an expected behaviour!

What else could be done:
- We should check if we have this nuance documented, and submit a bug to
fuel-docs team, if not yet there.
- Submitting a bug and inspecting logs would be nice to do as well.
I believe some optimizations may be done, bearing in mind this pacemaker
cluster-recheck-interval and failure-timeout story [0].

[0]
http://blog.kennyrasschaert.be/blog/2013/12/18/pacemaker-high-failability/

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


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing 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] Troubleshooting cross-project comms

[Thierry Carrez]

James E. Blair wrote:
> Is the idea to try to re-invigorate the -dev channel
> by holding meetings there?

Right, that was one beneficial side-effect that I expected out of
recycling #openstack-dev. Reinvigorate it through regular discussions.
It also happens to have the most people joined to it due to its history.

-- 
Thierry Carrez (ttx)

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

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

[Emilien Macchi]

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

Thanks!
Emilien

On 11/16/2015 11:39 PM, Emilien Macchi wrote:
> The second one. Sorry for confusion, I sent it from my phone.
> 
> See you tomorrow!
> ---
> Emilien Macchi
> 
> On Nov 16, 2015 1:24 PM, "Iury Gregory"  <mailto:iurygreg...@gmail.com>> wrote:
> 
> Hi Emilien, the link for the agenda
> is 
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-2015111 or 
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151117
> 
> <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151117> ?
> Thanks o/
> 
> 
> 2015-11-16 14:04 GMT-03:00 Emilien Macchi  <mailto:emilien.mac...@gmail.com>>:
> 
> Hello!
> 
> Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC
> in #openstack-meeting-4:
> 
> https
> 
> <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110>://
> 
> <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110>etherpad.openstack.org
> 
> <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110>/p/puppet-openstack-weekly-meeting-2015111
> 
> <https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110>7
> 
> I'm back online tomorrow morning.
> 
> Thanks,
> ---
> Emilien Macchi
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> 
> ~
> /Att[]'s
> Iury Gregory Melo Ferreira 
> //Master student in Computer Science at UFCG/
> /E-mail:  iurygreg...@gmail.com <mailto:iurygreg...@gmail.com>/
> ~
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <http://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
> 

-- 
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] [puppet] weekly meeting #58 and next week

[Emilien Macchi]

Just for the record, here are the meeting notes:
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-11-10-15.00.html

Thanks!

On 11/08/2015 10:08 PM, Matt Fischer wrote:
> We have a very light schedule if anyone would like to discuss bugs or
> other issues, it would be a good time to do so.
> 
> On Sat, Nov 7, 2015 at 12:29 PM, Emilien Macchi
> mailto:emilien.mac...@gmail.com>> wrote:
> 
> Hello!
> 
> Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC
> in #openstack-meeting-4:
> 
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151110
> 
> I'm off all next week (holidays without IRC, and rare access to
> e-mails...), so mfish will be chair.
> 
> During the week, if you have any problem with Puppet CI, you can ping
> degorenko on IRC.
> When I come back, I'll work on 7.0.0 release to create our
> stable/liberty branch.
> 
> Thanks and see you soon,
> Emilien
> 
> __
> OpenStack Development Mailing 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
> 

-- 
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] Is latest PyCharm license still available?

[OpenStack Mailing List Archive]

Link: https://openstack.nimeyo.com/65517/?show=65517#q65517
From: vanderwl 

I tried the link above, but got: "Invitation code is not valid." from the jetbrains website.

Has something in getting the license steps changed again?



__
OpenStack Development Mailing 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-ansible] Mitaka Summit Summary

[Jesse Pretorius]

Hi everyone,

I've put together some thoughts based on the Mitaka Summit from the
OpenStack-Ansible point of view:
http://odyssey4me.github.io/openstack/ansible/mitaka/summit/2015/11/17/mitaka-summit.html

Please feel free to ping me with any feedback!

Thanks,

-- 
Jesse Pretorius
IRC: odyssey4me
__
OpenStack Development Mailing 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][ThirdPartyCI] Running third party CI on networking-foo projects

[Fawad Khaliq]

Folks,

What would be the mechanism to enable a third party CI on a Neutron
sub-project? I am not sure if anyone has already tried it.

I am interesting in adding PLUMgrid CI on networking-plumgrid [1]

cc: Mike

[1] https://github.com/openstack/networking-plumgrid

Thanks,
Fawad Khaliq
__
OpenStack Development Mailing 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]

[Pratik Mallya]

Hello Heat team,

I recently proposed a patch https://review.openstack.org/#/c/246481/ which 
changes some events when resources are signaled. I was wondering if anyone has 
any downstream services that depend on the events being in the format 
specified, since this patch would break that expectation.

(Not sure if this is the correct way to solicit this information. Please let me 
know alternatives, if any :) )

Thanks,
Pratik Mallya
__
OpenStack Development Mailing 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] [oslo][All] Make CONF.set_override with paramter enforce_type=True by default

[Markus Zoeller]

ChangBo Guo  wrote on 11/17/2015 01:29:53 PM:

> From: ChangBo Guo 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 11/17/2015 01:37 PM
> Subject: [openstack-dev] [oslo][All] Make CONF.set_override with 
> paramter enforce_type=True by default
> 
> Hi ALL,

> 1. Problems :
>oslo_config provides method CONF.set_override[1] , developers 
> usually use it to change config option's value in tests. That's 
convenient .
>By default  parameter enforce_type=False,  it doesn't check any 
> type or value of override. If set enforce_type=True , will check 
parameter
>override's type and value.  In production code(running time code), 
> oslo_config  always checks  config option's value.
>In short, we test and run code in different ways. so there's  gap: 
> config option with wrong type or invalid value can pass tests when
>parameter enforce_type = False in consuming projects.  that means 
> some invalid or wrong tests are in our code base.
>There is nova POC result when I enable "enforce_type=true" [2],  
> and I must fix them in [3]
> 
>[1] https://github.com/openstack/oslo.config/blob/master/
> oslo_config/cfg.py#L2173
>[2] http://logs.openstack.org/16/242416/1/check/gate-nova-python27/
> 97b5eff/testr_results.html.gz
>[3]  https://review.openstack.org/#/c/242416/  https://
> review.openstack.org/#/c/242717/  
https://review.openstack.org/#/c/243061/
> 
> 2. Proposal 
>1) Make  method CONF.set_override with  enforce_type=True  in 
> consuming projects. and  fix violations when  enforce_type=True in each 
project.
> 
>   2) Make  method CONF.set_override with  enforce_type=True by default
> in oslo_config
> 
>Hope some one from consuming projects can help make  
> enforce_type=True in consuming projects and fix violations,
> 
>You can find more details and comments  in  https://
> etherpad.openstack.org/p/enforce_type_true_by_default
> 
> -- 
> ChangBo Guo(gcb)


Does it make sense to introduce a hacking check when your changes are
merged? To prevent that new things slip in in Nova during the time period
until "oslo.config" changes the default value?

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] [Fuel] HA cluster disk monitoring, failover and recovery

[Vladimir Kuklin]

Bogdan

I think we should firstly check whether attribute deletion leads to node
starting its services or not. From what I read in the official Pacemaker
documentation, it should work out of the box without the need to restart
the node.
And by the way the quote above mentions 'use ONE of the following methods'
meaning that we could actually use attribute deletion. The 2nd and the 3rd
options do the same - they clear short-living node attribute. So we need to
figure out why OCF script does not update the corresponding attribute by
itself.



On Tue, Nov 17, 2015 at 7:03 PM, Bogdan Dobrelya 
wrote:

> On 17.11.2015 15:28, Kyrylo Galanov wrote:
> > Hi Team,
>
> Hello
>
> >
> > I have been testing fail-over after free disk space is less than 512 mb.
> > (https://review.openstack.org/#/c/240951/)
> > Affected node is stopped correctly and services migrate to a healthy
> node.
> >
> > However, after free disk space is more than 512 mb again the node does
> > not recover it's state to operating. Moreover, starting the resources
> > manually would rather fail. In a nutshell, the pacemaker service / node
> > should be restarted. Detailed information is available
> > here:
> https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_monitor_health.html
> >
> > How do we address this issue?
>
> According to the docs you provided,
> " After a node's health status has turned to red, solve the issue that
> led to the problem. Then clear the red status to make the node eligible
> again for running resources. Log in to the cluster node and use one of
> the following methods:
>
> Execute the following command:
>
> crm node status-attr NODE delete #health_disk
>
> Restart OpenAIS on that node.
>
> Reboot the node.
>
> The node will be returned to service and can run resources again. "
>
> So this looks like an expected behaviour!
>
> What else could be done:
> - We should check if we have this nuance documented, and submit a bug to
> fuel-docs team, if not yet there.
> - Submitting a bug and inspecting logs would be nice to do as well.
> I believe some optimizations may be done, bearing in mind this pacemaker
> cluster-recheck-interval and failure-timeout story [0].
>
> [0]
> http://blog.kennyrasschaert.be/blog/2013/12/18/pacemaker-high-failability/
>
> >
> >
> > Best regards,
> > Kyrylo
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [glance] [nova] Image Signature Verification

[Flavio Percoco]

On 13/11/15 09:35 +, Daniel P. Berrange wrote:

On Thu, Nov 12, 2015 at 08:30:53PM +, Poulos, Brianna L. wrote:

Hello,

There has recently been additional discussion about the best way to handle
image signature verification in glance and nova [1].  There are two
options being discussed for the signature (the examples below using
'RSA-PSS' as the type, and SHA-256 as the hash method):

1. The signature is of the glance checksum of the image data (currently a
hash which is hardcoded to be MD5)
signature = RSA-PSS(SHA-256(MD5(IMAGE-CONTENT)))

2. The signature of the image data directly
signature = RSA-PSS(SHA-256(IMAGE-CONTENT))

The 1st option is what is currently in glance's liberty release [2].  This
approach was chosen with the understanding that the glance checksum would
be updated to be configurable [3].  Although the 2nd option was initially
proposed, the glance community opposed it during the pre-Liberty virtual
mini-summit in May 2015 (due to the performance impact of doing two hashes
of the image data--one for the 'checksum' and the other for the
signature), and it was decided to proceed with the 1st option during the
Liberty summit [4].

During the Mitaka Summit, making the glance checksum configurable was
discussed during a design session [5].  It was decided that instead of
making the 'checksum' image field configurable, it would be preferable to
compute a separate, configurable (on a per-image basis, with a site-wide
default) hash, and then use that hash when MD5 wasn't sufficient (such as
in the case of signature verification). This second hash would be computed
at the same time the MD5 'checksum' was computed.

Which brings us to the nova spec which is under discussion [1], which is
to add the ability to verify signatures in nova.  The nova community has
made it clear that the promise of providing a configurable hash in glance
is not good enough--they never want to support any signatures that use MD5
in any way, shape, or form; nor do they want to rely on asking glance for
what hash option was used.  To that end, the push is to use the 2nd option
to verify signatures in nova from the start.


As well as not wanting MD5, I believe that computing signatures based
on a configurable checksum in glance provides a bad user experiance.
The user generating the signature of their image, now has to have a
way to query glance to find out what checksum it used, in order to
generate their signature. Further if the glance admin ever wants to
change their checksum algorithm, they'd break all existing signatures
by doing so. These are just as important reasons why I want Nova
to use the 2nd option and compute signatures directly on the image
content.


This is a very good point. Thanks for bringing it up, Dan.




Since the glance community no longer seems opposed to the idea of
computing two hashes (the second hash being optional, of course), the 2nd
option has now become valid from the glance perspective.  This would
require modifying the existing implementation in glance to verify a
signature of the image data, rather than verifying a checksum of the image
data, but would have no additional performance hit beyond the cost to
compute the second hash.  Note that the image data would still only be
read once -- the checksum update (for the MD5 hash) and the signature
verification update (for the signature hash) would occur in the same loop.
Although this would mean that signatures generated using option 1 would no
longer verify, since signatures generated using option 1 are based on an
MD5 hash (and were waiting for the checksum configurability before
becoming a viable cryptographic option anyway), this does not pose a
significant issue.


A second point about the current proposal from Nova's POV is that
we do not like the image property names currently used. In Liberty
Nova standardized on the property naming scheme it uses to have 3
naming prefixes

 https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L166

- 'hw_' - properties that affect virtual hardware configuration
- 'os_' - properties that affect guest OS setup / configuration
- 'img_' - properties that affect handling of images by the host

The signature properties are obviously all related to the handling
of images by the host, so from Nova's POV we should have an 'img_'
prefix on all their names.

We probably should have alerted glance devs to this naming convention
before now to avoid this problem, but I guess we forgot. It would be
great if glance devs could bear this preferred naming convention in
mind if there are any future cases where there is a property that
needs to be used by both Nova & Glance code.


+1

Honestly, I wasn't aware there was such a convention. It's sad that we
didn't know this before adding the signature field.


Anyway since the change in the way we calculate signatures on images
is a non-backwards compatible change for users of the current glance
impl, changing these property names at this p

[openstack-dev] [oslo] [nova] default-next-release opt flag

[Alexis Lee]

Often in Nova we introduce an option defaulted off (so as not to break
people) but then we want to make it default in the next release.

Someone suggested an opt flag to mark this but I don't know what impact
they wanted it to have. IE how the user should be alerted about the
presence of these flagged options.

If you are that person, or have opinions on this, please reply :)


Alexis (lxsli)
-- 
Nova developer, Hewlett-Packard Limited.
Registered Office: Cain Road, Bracknell, Berkshire RG12 1HN.
Registered Number: 00690597 England
VAT number: GB 314 1496 79

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

Re: [openstack-dev] [glance] [nova] Image Signature Verification

[Daniel P. Berrange]

On Tue, Nov 17, 2015 at 02:09:42PM -0300, Flavio Percoco wrote:
> On 13/11/15 09:35 +, Daniel P. Berrange wrote:
> >On Thu, Nov 12, 2015 at 08:30:53PM +, Poulos, Brianna L. wrote:
> >>Hello,
> >>
> >>There has recently been additional discussion about the best way to handle
> >>image signature verification in glance and nova [1].  There are two
> >>options being discussed for the signature (the examples below using
> >>'RSA-PSS' as the type, and SHA-256 as the hash method):
> >>
> >>1. The signature is of the glance checksum of the image data (currently a
> >>hash which is hardcoded to be MD5)
> >>signature = RSA-PSS(SHA-256(MD5(IMAGE-CONTENT)))
> >>
> >>2. The signature of the image data directly
> >>signature = RSA-PSS(SHA-256(IMAGE-CONTENT))
> >>
> >>The 1st option is what is currently in glance's liberty release [2].  This
> >>approach was chosen with the understanding that the glance checksum would
> >>be updated to be configurable [3].  Although the 2nd option was initially
> >>proposed, the glance community opposed it during the pre-Liberty virtual
> >>mini-summit in May 2015 (due to the performance impact of doing two hashes
> >>of the image data--one for the 'checksum' and the other for the
> >>signature), and it was decided to proceed with the 1st option during the
> >>Liberty summit [4].
> >>
> >>During the Mitaka Summit, making the glance checksum configurable was
> >>discussed during a design session [5].  It was decided that instead of
> >>making the 'checksum' image field configurable, it would be preferable to
> >>compute a separate, configurable (on a per-image basis, with a site-wide
> >>default) hash, and then use that hash when MD5 wasn't sufficient (such as
> >>in the case of signature verification). This second hash would be computed
> >>at the same time the MD5 'checksum' was computed.
> >>
> >>Which brings us to the nova spec which is under discussion [1], which is
> >>to add the ability to verify signatures in nova.  The nova community has
> >>made it clear that the promise of providing a configurable hash in glance
> >>is not good enough--they never want to support any signatures that use MD5
> >>in any way, shape, or form; nor do they want to rely on asking glance for
> >>what hash option was used.  To that end, the push is to use the 2nd option
> >>to verify signatures in nova from the start.
> >
> >As well as not wanting MD5, I believe that computing signatures based
> >on a configurable checksum in glance provides a bad user experiance.
> >The user generating the signature of their image, now has to have a
> >way to query glance to find out what checksum it used, in order to
> >generate their signature. Further if the glance admin ever wants to
> >change their checksum algorithm, they'd break all existing signatures
> >by doing so. These are just as important reasons why I want Nova
> >to use the 2nd option and compute signatures directly on the image
> >content.
> 
> This is a very good point. Thanks for bringing it up, Dan.
> 
> >
> >>Since the glance community no longer seems opposed to the idea of
> >>computing two hashes (the second hash being optional, of course), the 2nd
> >>option has now become valid from the glance perspective.  This would
> >>require modifying the existing implementation in glance to verify a
> >>signature of the image data, rather than verifying a checksum of the image
> >>data, but would have no additional performance hit beyond the cost to
> >>compute the second hash.  Note that the image data would still only be
> >>read once -- the checksum update (for the MD5 hash) and the signature
> >>verification update (for the signature hash) would occur in the same loop.
> >>Although this would mean that signatures generated using option 1 would no
> >>longer verify, since signatures generated using option 1 are based on an
> >>MD5 hash (and were waiting for the checksum configurability before
> >>becoming a viable cryptographic option anyway), this does not pose a
> >>significant issue.
> >
> >A second point about the current proposal from Nova's POV is that
> >we do not like the image property names currently used. In Liberty
> >Nova standardized on the property naming scheme it uses to have 3
> >naming prefixes
> >
> > https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L166
> >
> >- 'hw_' - properties that affect virtual hardware configuration
> >- 'os_' - properties that affect guest OS setup / configuration
> >- 'img_' - properties that affect handling of images by the host
> >
> >The signature properties are obviously all related to the handling
> >of images by the host, so from Nova's POV we should have an 'img_'
> >prefix on all their names.
> >
> >We probably should have alerted glance devs to this naming convention
> >before now to avoid this problem, but I guess we forgot. It would be
> >great if glance devs could bear this preferred naming convention in
> >mind if there are any future cases where there is a prope

Re: [openstack-dev] [oslo] [nova] default-next-release opt flag

[Clint Byrum]

Excerpts from Alexis Lee's message of 2015-11-17 09:28:31 -0800:
> Often in Nova we introduce an option defaulted off (so as not to break
> people) but then we want to make it default in the next release.
> 
> Someone suggested an opt flag to mark this but I don't know what impact
> they wanted it to have. IE how the user should be alerted about the
> presence of these flagged options.
> 
> If you are that person, or have opinions on this, please reply :)

I'm not that person, but I think it will have limited benefit unless
there is also a flag to pretend its the next release already for testing
purposes. Basically, what you want is the ability for shops to have CI
that runs their deployment/tests with the future default options so they
can drive failures to 0 and be proactive. This would be beneficial to
shops running CD, or stable releases.

__
OpenStack Development Mailing 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] HA cluster disk monitoring, failover and recovery

[Alex Schultz]

On Tue, Nov 17, 2015 at 11:12 AM, Vladimir Kuklin  wrote:
> Bogdan
>
> I think we should firstly check whether attribute deletion leads to node
> starting its services or not. From what I read in the official Pacemaker
> documentation, it should work out of the box without the need to restart the
> node.

It does start up the services when the attribute is cleared. QA has a
test to validate this as part of this change.

> And by the way the quote above mentions 'use ONE of the following methods'
> meaning that we could actually use attribute deletion. The 2nd and the 3rd
> options do the same - they clear short-living node attribute. So we need to
> figure out why OCF script does not update the corresponding attribute by
> itself.
>

https://github.com/ClusterLabs/pacemaker/blob/master/extra/resources/SysInfo#L215-L227

It doesn't have something that updates it to green because essentially
when this condition hits, the sysinfo service is also stopped. It has
no way of knowing when it is cleared because all the resources are
stopped and there is no longer a service running to reset the
attribute.  We would need something outside of pacemaker to mark it OK
or perhaps write a custom health strategy[0][1] that would not stop
the sysinfo task and update the ocf script to update the status to
green if all disks are OK.

-Alex

[0] 
https://github.com/openstack/fuel-library/blob/master/deployment/puppet/cluster/manifests/sysinfo.pp#L50-L55
[1] http://clusterlabs.org/wiki/SystemHealth

>
>
> On Tue, Nov 17, 2015 at 7:03 PM, Bogdan Dobrelya 
> wrote:
>>
>> On 17.11.2015 15:28, Kyrylo Galanov wrote:
>> > Hi Team,
>>
>> Hello
>>
>> >
>> > I have been testing fail-over after free disk space is less than 512 mb.
>> > (https://review.openstack.org/#/c/240951/)
>> > Affected node is stopped correctly and services migrate to a healthy
>> > node.
>> >
>> > However, after free disk space is more than 512 mb again the node does
>> > not recover it's state to operating. Moreover, starting the resources
>> > manually would rather fail. In a nutshell, the pacemaker service / node
>> > should be restarted. Detailed information is available
>> > here:
>> > https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_monitor_health.html
>> >
>> > How do we address this issue?
>>
>> According to the docs you provided,
>> " After a node's health status has turned to red, solve the issue that
>> led to the problem. Then clear the red status to make the node eligible
>> again for running resources. Log in to the cluster node and use one of
>> the following methods:
>>
>> Execute the following command:
>>
>> crm node status-attr NODE delete #health_disk
>>
>> Restart OpenAIS on that node.
>>
>> Reboot the node.
>>
>> The node will be returned to service and can run resources again. "
>>
>> So this looks like an expected behaviour!
>>
>> What else could be done:
>> - We should check if we have this nuance documented, and submit a bug to
>> fuel-docs team, if not yet there.
>> - Submitting a bug and inspecting logs would be nice to do as well.
>> I believe some optimizations may be done, bearing in mind this pacemaker
>> cluster-recheck-interval and failure-timeout story [0].
>>
>> [0]
>> http://blog.kennyrasschaert.be/blog/2013/12/18/pacemaker-high-failability/
>>
>> >
>> >
>> > Best regards,
>> > Kyrylo
>> >
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>> --
>> Best regards,
>> Bogdan Dobrelya,
>> Irc #bogdando
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> 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
>
> __
> OpenStack Development Mailing 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] [glance] [nova] Image Signature Verification

[Flavio Percoco]

On 17/11/15 17:44 +, Daniel P. Berrange wrote:

On Tue, Nov 17, 2015 at 02:09:42PM -0300, Flavio Percoco wrote:

On 13/11/15 09:35 +, Daniel P. Berrange wrote:
>On Thu, Nov 12, 2015 at 08:30:53PM +, Poulos, Brianna L. wrote:
>>Hello,
>>
>>There has recently been additional discussion about the best way to handle
>>image signature verification in glance and nova [1].  There are two
>>options being discussed for the signature (the examples below using
>>'RSA-PSS' as the type, and SHA-256 as the hash method):
>>
>>1. The signature is of the glance checksum of the image data (currently a
>>hash which is hardcoded to be MD5)
>>signature = RSA-PSS(SHA-256(MD5(IMAGE-CONTENT)))
>>
>>2. The signature of the image data directly
>>signature = RSA-PSS(SHA-256(IMAGE-CONTENT))
>>
>>The 1st option is what is currently in glance's liberty release [2].  This
>>approach was chosen with the understanding that the glance checksum would
>>be updated to be configurable [3].  Although the 2nd option was initially
>>proposed, the glance community opposed it during the pre-Liberty virtual
>>mini-summit in May 2015 (due to the performance impact of doing two hashes
>>of the image data--one for the 'checksum' and the other for the
>>signature), and it was decided to proceed with the 1st option during the
>>Liberty summit [4].
>>
>>During the Mitaka Summit, making the glance checksum configurable was
>>discussed during a design session [5].  It was decided that instead of
>>making the 'checksum' image field configurable, it would be preferable to
>>compute a separate, configurable (on a per-image basis, with a site-wide
>>default) hash, and then use that hash when MD5 wasn't sufficient (such as
>>in the case of signature verification). This second hash would be computed
>>at the same time the MD5 'checksum' was computed.
>>
>>Which brings us to the nova spec which is under discussion [1], which is
>>to add the ability to verify signatures in nova.  The nova community has
>>made it clear that the promise of providing a configurable hash in glance
>>is not good enough--they never want to support any signatures that use MD5
>>in any way, shape, or form; nor do they want to rely on asking glance for
>>what hash option was used.  To that end, the push is to use the 2nd option
>>to verify signatures in nova from the start.
>
>As well as not wanting MD5, I believe that computing signatures based
>on a configurable checksum in glance provides a bad user experiance.
>The user generating the signature of their image, now has to have a
>way to query glance to find out what checksum it used, in order to
>generate their signature. Further if the glance admin ever wants to
>change their checksum algorithm, they'd break all existing signatures
>by doing so. These are just as important reasons why I want Nova
>to use the 2nd option and compute signatures directly on the image
>content.

This is a very good point. Thanks for bringing it up, Dan.

>
>>Since the glance community no longer seems opposed to the idea of
>>computing two hashes (the second hash being optional, of course), the 2nd
>>option has now become valid from the glance perspective.  This would
>>require modifying the existing implementation in glance to verify a
>>signature of the image data, rather than verifying a checksum of the image
>>data, but would have no additional performance hit beyond the cost to
>>compute the second hash.  Note that the image data would still only be
>>read once -- the checksum update (for the MD5 hash) and the signature
>>verification update (for the signature hash) would occur in the same loop.
>>Although this would mean that signatures generated using option 1 would no
>>longer verify, since signatures generated using option 1 are based on an
>>MD5 hash (and were waiting for the checksum configurability before
>>becoming a viable cryptographic option anyway), this does not pose a
>>significant issue.
>
>A second point about the current proposal from Nova's POV is that
>we do not like the image property names currently used. In Liberty
>Nova standardized on the property naming scheme it uses to have 3
>naming prefixes
>
> https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L166
>
>- 'hw_' - properties that affect virtual hardware configuration
>- 'os_' - properties that affect guest OS setup / configuration
>- 'img_' - properties that affect handling of images by the host
>
>The signature properties are obviously all related to the handling
>of images by the host, so from Nova's POV we should have an 'img_'
>prefix on all their names.
>
>We probably should have alerted glance devs to this naming convention
>before now to avoid this problem, but I guess we forgot. It would be
>great if glance devs could bear this preferred naming convention in
>mind if there are any future cases where there is a property that
>needs to be used by both Nova & Glance code.

+1

Honestly, I wasn't aware there was such a convention. It's sad

Re: [openstack-dev] [Heat]

[Steven Hardy]

On Tue, Nov 17, 2015 at 05:09:16PM +, Pratik Mallya wrote:
>Hello Heat team,
>I recently proposed a patch https://review.openstack.org/#/c/246481/ which
>changes some events when resources are signaled. I was wondering if anyone
>has any downstream services that depend on the events being in the format
>specified, since this patch would break that expectation.
>(Not sure if this is the correct way to solicit this information. Please
>let me know alternatives, if any :) )

I just commented on the review and the bug.

IMHO we can't do this, it's been part of our user-visible API for as long
as I can remember, thus there's bound to be some folks relying on that
information to determine if a SIGNAL event has happened.

There are other ways to determine the stack action when a signal event
happens, so IMHO this should be postponed until we decide to do a v2 API,
and even then we'll need to maintain compatibility with the old format for
v1.

You could add it to the v2 API wishlist spec:

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

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] [OpenStack-Infra] Report from Gerrit User Summit

[James E. Blair]

Sean Dague  writes:

> Given that it's on track for getting accepted upstream, it's probably
> something we could cherry pick into our deploy, as it won't be a
> divergence issue.

Once it merges upstream, yes.

-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] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Alan Pevec]

2015-11-12 21:37 GMT+01:00 Zane Bitter :
> https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:stable/juno,n,z
>
> It would be nice to treat the remaining 'High' priority one as a blocker.
> The rest aren't a blocker for the release but it would be really nice to at
> least have time to get them all backported and merged before the stable
> branch gets deleted.

There are still quite a few open reviews for Heat Juno, please tell us
which should be merged as freeze exceptions, because immediately after
freeze Juno goes EOL!

* https://review.openstack.org/245368 Medium
https://bugs.launchpad.net/heat/+bug/1424600
* https://review.openstack.org/245373 Medium
https://bugs.launchpad.net/heat/+bug/1424899
* https://review.openstack.org/246113 Medium
https://bugs.launchpad.net/heat/+bug/1471135
* https://review.openstack.org/244957 Medium
https://bugs.launchpad.net/heat/+bug/1418935
* https://review.openstack.org/246192 High
https://bugs.launchpad.net/heat/+bug/1508096
* https://review.openstack.org/246163 Undecided
https://bugs.launchpad.net/heat/+bug/1419693

Cheers,
Alan

__
OpenStack Development Mailing 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] [oslo] [nova] default-next-release opt flag

[Matt Riedemann]

On 11/17/2015 11:28 AM, Alexis Lee wrote:

Often in Nova we introduce an option defaulted off (so as not to break
people) but then we want to make it default in the next release.

Someone suggested an opt flag to mark this but I don't know what impact
they wanted it to have. IE how the user should be alerted about the
presence of these flagged options.

If you are that person, or have opinions on this, please reply :)


Alexis (lxsli)



There is the deprecated_for_removal kwarg, but that doesn't fit here. 
There is the DeprecatedOpt, but that's for moving/renaming options. So 
this is something else, like deprecated_default or 
pending_default_change or something.


--

Thanks,

Matt Riedemann


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

[openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

[Markus Zoeller]

Background
==
The blueprint [1] wants to utilize the *virtlogd* logging deamon from
libvirt. Among others to solve bug [2], one of our oldest ones. The
funny part is, that this libvirt feature is still in development. This
was a trigger to see if we can create a gate job which utilizes the
latest, bleeding edge, version of libvirt to test such features. We
discussed it shortly in IRC [3] (tonyb, bauzas, markus_z) and wanted to
get some feedback here. The summary of the idea is:
* Create a custom repo which contains the latest libvirt version
* Enhance Devstack so that it can point to a custom repo to install
  the built libvirt packages
* Have a nodepool image which is compatible with the libvirt packages
* In case of [1]: check if tempest needs further/changed tests

Open questions
==
* Is already someone working on something like that and I missed it?
* If 'no', is there already a repo which contains the very latest
  libvirt builds which we can utilize?

I haven't done anything with the gates before, which means there is a
very high chance I'm missing something or missunderstanding a concept.
Please let me know what you think.

References
==
[1] Nova spec "Libvirt: Use the virtlogd deamon for logs":
https://review.openstack.org/#/c/234291/
[2] Nova; bugs; "console.log grows indefinitely"
https://bugs.launchpad.net/nova/+bug/832507
[3] #openstack-nova; 2015-11-17:

http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2015-11-17.log.html#t2015-11-17T08:44:57

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] [oslo] [nova] default-next-release opt flag

[Sean Dague]

On 11/17/2015 01:48 PM, Matt Riedemann wrote:
> 
> 
> On 11/17/2015 11:28 AM, Alexis Lee wrote:
>> Often in Nova we introduce an option defaulted off (so as not to break
>> people) but then we want to make it default in the next release.
>>
>> Someone suggested an opt flag to mark this but I don't know what impact
>> they wanted it to have. IE how the user should be alerted about the
>> presence of these flagged options.
>>
>> If you are that person, or have opinions on this, please reply :)
>>
>>
>> Alexis (lxsli)
>>
> 
> There is the deprecated_for_removal kwarg, but that doesn't fit here.
> There is the DeprecatedOpt, but that's for moving/renaming options. So
> this is something else, like deprecated_default or
> pending_default_change or something.

Honestly, with reno now we could probably just add a release note in
when we add it. That's more likely for us to not loose a thing like that.

-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] [nova][infra] Getting a bleeding edge libvirt gate job running

[Ian Wienand]

On 11/18/2015 06:10 AM, Markus Zoeller wrote:
 This

was a trigger to see if we can create a gate job which utilizes the
latest, bleeding edge, version of libvirt to test such features.



* Is already someone working on something like that and I missed it?


I believe the closest we have got is probably [1]; pulling apart some
of the comments there might be helpful

In short, a devstack plugin that installs the latest libvirt is
probably the way to go.

Ongoing, the only issue I see is that we do things to base devstack
that conflict/break this plugin, as we are more-or-less assuming the
distro version (see things like [2], stuff like this comes up every
now and then).


* If 'no', is there already a repo which contains the very latest
   libvirt builds which we can utilize?


For Fedora, there is virt-preview  [3] at least

-i

[1] https://review.openstack.org/#/c/108714/
[2] https://review.openstack.org/246501
[3] https://fedoraproject.org/wiki/Virtualization_Preview_Repository

__
OpenStack Development Mailing 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] [oslo] [nova] default-next-release opt flag

[Sylvain Bauza]

Le 17/11/2015 20:25, Sean Dague a écrit :

On 11/17/2015 01:48 PM, Matt Riedemann wrote:


On 11/17/2015 11:28 AM, Alexis Lee wrote:

Often in Nova we introduce an option defaulted off (so as not to break
people) but then we want to make it default in the next release.

Someone suggested an opt flag to mark this but I don't know what impact
they wanted it to have. IE how the user should be alerted about the
presence of these flagged options.

If you are that person, or have opinions on this, please reply :)


Alexis (lxsli)


There is the deprecated_for_removal kwarg, but that doesn't fit here.
There is the DeprecatedOpt, but that's for moving/renaming options. So
this is something else, like deprecated_default or
pending_default_change or something.

Honestly, with reno now we could probably just add a release note in
when we add it. That's more likely for us to not loose a thing like that.

-Sean



Agreed, it's now far easier to ask for having a release note within the 
change, so the operators can just look at that. It also seems to me far 
better for them to check the release notes rather than trying to see the 
huge nova.conf file...


-Sylvain


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

[Cody Herriges]

Emilien Macchi wrote:
> We did our meeting:
> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-11-17-15.00.html
> 

Now that updates to the wiki doc "Coding_style" are happening, are we
going to block patches that are already proposed that use the old
"" pattern?


-- 
Cody



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] [puppet] weekly meeting #59

[Iury Gregory]

Hi Cody,
If there is patches using $::os_service_default and they are blocked, I
think the owner just need to request removal and continue the work.( I
think )


2015-11-17 17:10 GMT-03:00 Cody Herriges :

> Emilien Macchi wrote:
> > We did our meeting:
> >
> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-11-17-15.00.html
> >
>
> Now that updates to the wiki doc "Coding_style" are happening, are we
> going to block patches that are already proposed that use the old
> "" pattern?
>
>
> --
> Cody
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

~


*Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science at
UFCG*
*E-mail:  iurygreg...@gmail.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] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

[Devananda van der Veen]

Thanks for the list, Sam. I've left some comments inline...

On Tue, Nov 10, 2015 at 4:19 AM, Sam Betts (sambetts) 
wrote:

> So you would end up with a set of commands that look like this:
>
> Openstack baremetal [node/driver/chassis] list
>

will this command support filtering, similar to our CLI ?


> Openstack baremetal port list [—node uuid] <— replicate node-port-list
>

> Openstack baremetal [node/port/driver] show UUID
>

>
Openstack baremetal chassis show [—nodes] UUID  <— replicate
> chassis-node-list
>

this one seems off to me. "show" commands should be displaying the details
of the requested object, not listing a summarized set of objects. Instead
of "chassis show --nodes UUID", I think the command should be "node list
--chassis uuid", which also matches the option to "port list --node uuid".


>
> Openstack baremetal [node/chassis/port] create
> Openstack baremetal [node/chassis/port] update UUID
> Openstack baremetal [node/chassis/port] delete UUID
>

all seem good


>
> Openstack baremetal [node/chassis] provide UUID
> Openstack baremetal [node/chassis] activate UUID
> Openstack baremetal [node/chassis] rebuild UUID
> Openstack baremetal [node/chassis] inspect UUID
> Openstack baremetal [node/chassis] manage UUID
> Openstack baremetal [node/chassis] abort UUID
> Openstack baremetal [node/chassis] boot UUID
> Openstack baremetal [node/chassis] shutdown UUID
> Openstack baremetal [node/chassis] reboot UUID
>

Firstly, I would suggest removing the "chassis" noun here, at least until
we sort out how we want to handle grouping within the service. Right now,
"chassis" resources do not support any verbs - they can only be created and
deleted, and used as a loose logical grouping of nodes.

Secondly, I would change some of these verbs as follows:
  s/activate/deploy/ - because the resulting state transitions will show as
"deploying", etc
  s/boot/poweron/ && s/shutdown/poweroff/ - because that is a more accurate
description of what will be done, and it moves away from the "nova boot"
command, which is completely different.


>
> Openstack baremetal node maintain [—done] UUID
>

I would rename this option as well, but I'm not sure to what. The action
represented by this verb is not a lengthy process (as could be implied by
the verb "maintain", like, "go do some maintenance on it"). This is merely
the changing of a flag within the state of the resource, which instructs
ironic-conductor to leave that node alone without changing any other state,
so perhaps a more appropriate verb would be "ignore" or "exclude"... eg,
"Openstack baremetal node [exclude|include] UUID"



> Openstack baremetal node console [—enable, —disable] UUID <— With no
> parameters this acts like node-get-console, otherwise acts
> like node-set-console-mode
> Openstack baremetal node boot-device [—supported, —PXE, —CDROM, etc] UUID
> <— With no parameters this acts like node-get-boot-device, —supported
> makes it act like node-get-supported-boot-devices, and with a type of boot
> device passed in it’ll act like node-set-boot-device
>
> Openstack baremetal [node/driver] passthru
>

> WDYT? I think I’ve covered most of what exists in the Ironic CLI
> currently.
>
> Sam
>
> From: "Haomeng, Wang" 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, 10 November 2015 11:41
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient
> command for provision action
>
> Hi Sam,
>
> Yes, I understand your format is：
>
> #openstack baremetal  
>
> so these can cover all 'node' operations however if we want to cover
> support port/chassis/driver and more ironic resources, so how about below
> proposal?
>
> #openstack baremetal   
>
> The resource/target can be one item in following list:
>
> node
> port
> chassis
> driver
> ...
>
> Make sense?
>
>
>
>
> On Tue, Nov 10, 2015 at 7:25 PM, Sam Betts (sambetts) 
> wrote:
>
>> Openstack baremetal provision provide or —provide Just doesn’t feel right
>> to me, it feels like I am typing more that I need to and it feels like I’m
>> telling it to do the same action twice.
>>
>> I would much rather see:
>>
>> Openstack baremetal provide UUID
>> Openstack baremetal activate UUID
>> Openstack baremetal delete UUID
>> Openstack baremetal rebuild UUID
>> Openstack baremetal inspect UUID
>> Openstack baremetal manage UUID
>> Openstack baremetal abort UUID
>>
>> And for power:
>>
>> Openstack baremetal boot UUID
>> Openstack beremetal shutdown UUID
>> Openstack baremetal reboot UUID
>>
>> WDYT?
>>
>> Sam
>>
>> From: "Haomeng, Wang" 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Tuesday, 10 November 2015 10:49
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [Ironic] [OSC] Quick p

Re: [openstack-dev] [QA][Tempest] Deprecate or drop about Tempest CLI

[Matthew Treinish]

On Tue, Nov 17, 2015 at 01:39:34AM +, Masayuki Igawa wrote:
> Hi tempest CLI users and developers,
> 
> Now, we are improving Tempest CLI as we discussed at the summit[1] and
>  migrating legacy commands to tempest cli[2].
> 
> In this situation, my concern is 'CLI compatibility'.
> If we'll drop old CLIs support(like my patch), it might break existing
> workflows.
> 
> So I think there are two options.
>  1. Deprecate old tempest CLIs in this Mitaka cycle and we'll drop them at
> the beginning of the N cycle.
>  2. Drop old tempest CLIs in this Mitaka cycle when new CLIs will be
> implemented.
> # Actually, I'd like to just drop old CLIs. :)

As would I, but I agree we need to worry about existing users out there and
being nice to them.

I think we should do option #1, but in [2] we also maintain the old entry point.
We also have the function called by the old entry points emit a single warning
that says to use the new CLI. This way we have the new entry points all setup
and we indicate that everyone should move over to them.

If you started with the tempest-verify-config script you actually would would
fail because devstack currently uses it. So doing the switchover gracefully I
think would be best, because this is the same issue users will potentially hit.

> 
> If you have question and/or opinion, please let me know.
> 
> [1] https://etherpad.openstack.org/p/tempest-cli-improvements
> [2] https://review.openstack.org/#/c/240399/
> 

-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] [keystone] Case for renewability of tokens, increasing expiration time

[Lindsay Pallickal]

On Tue, Nov 17, 2015 at 5:31 AM, Dolph Mathews 
wrote:

>
>
> On Tuesday, November 17, 2015, Lindsay Pallickal 
> wrote:
>
>>
>> It looks like expiration is done this way to limit the damage from stolen
>> tokens, but if a token were stolen, it could be stolen from the same
>> location a username and password will now have to sit, to get around having
>> to re-supply them manually once an hour. Yes, forcing re-auth hourly with a
>> username and password, at the Keystone level, can limit damage if any of
>> the core Openstack services are compromised for the mass theft of tokens.
>> But limited damage will depend just as much on how quickly the compromise
>> is detected. The more time an attacker has in the system, the less his
>> actions will be hampered by a lack of token renewals. VMs can be
>> compromised, and data exported or destroyed given just a small window.
>>
>
> This first part of this is only a "maybe", not a completely true
> assertion. There are *many* more opportunities for individual tokens to be
> exposed than for the credentials used to create them. In the case if a mass
> token compromise, which I consider to be a completely different scenario,
> token expiration probably isn't going it be any help because there's
> probably always a fresher token available to the attacker, anyway, until
> the exploit is closed. Instead, keystone has several means of quickly
> revoking tokens in bulk (revocation events, truncating the UUID token
> table, restarting the memcache token backend, or rotating all your Fernet
> keys away... all depending on your deployment).
>

The token does get sent a lot more often than the username/password
credentials, but as long as both are sent via SSL/TLS, shouldn't the
opportunity for exposure be similar? Although, I could see it being easier
to accidentally send a token in the clear, or in a way vulnerable to a mitm
(ignoring ssl cert issues), as there are frequently more bits of code in
the client that deal using a token, versus a just few bits to secure when
deal with logging in. Tokens get passed around to far more services with
potential vulnerabilities as well, but I see that as a separate issue. I
agree with your comment that token expiration will not really help in a
mass compromise scenario.


>
>>
>> On the other hand, if a user facing application, or a long running
>> service supporting one, needs the API and is to remain convenient, they
>> have to store usernames and passwords. Sometimes that long running service
>> is connected to the outside world and faces security threats, such as when
>> relaying Openstack API requests to their respective internal network
>> endpoints - similar to what Horizon does. I wonder if I use Horizon
>> continuously, whether it will force me to manually re-authenticate hourly,
>> and if not, how it is getting around this problem, with or without storing
>> the username and password.
>>
>
> Bearer tokens are simply not the right solution to this use case. Unless
> horizon were to store your credentials client-side, you will be logged out
> after your keystone.conf [token] expiration passes.
>

I just checked and Horizon re-requests login after an hour, despite
activity. So yeah, Horizon is not storing credentials, which is good.


>
>
>>
>> I suspect it is more probable to button up security closer to the core of
>> Openstack, rather than relying on many third party API consuming
>> apps/services to secure even more compromising credentials. Perhaps effort
>> could be put into auditing for atypical mass token renewal events, like a
>> sudden increase, or accumulating rate of renewal requests in proportion
>> with the number of tokens streamed into compromised state.
>>
>> Allowing a maximum of 3 hours, in 1 hour renewal increments via Keystone,
>> and making that configurable, would be a good compromise for user/outside
>> facing apps/apis. Reducing temptation to adopt the security burden of
>> storing usernames and passwords, especially on a server exposed to the
>> outside or in storage that is outside (cookies & local storage), could
>> itself be a security boon.
>>
>
> Have you tried setting keystone.conf [token] expiration to 10800 (3 hours,
> in seconds)? If so, why doesn't this satisfy your use case? And why expect
> ordinary users to do busy work to hit the same token lifespan that an
> attacker will trivially achieve anyway?
>
>

I wish I had seen that expiration setting earlier. Just what I needed,
thank you.

In retrospect, it does not make sense to force users to do the busy work of
renewal when an attacker could just do the same. Even if the token has
expired a earlier due to non-renewal, causing an intruder misses the
window, it will only be a matter of time before a fresh token is available
through the same vector. I think a 3 hour expiration window will not add a
lot of risk, and the option is already built in, so all is well. Thanks
again.

Lindsay
_

Re: [openstack-dev] [Fuel] Number of IP addresses in a public network

[Roman Prykhodchenko]

Folks, we should resurrect this thread and find a consensus.

> 1 вер. 2015 р. о 15:00 Andrey Danin  написав(ла):
> 
> +1 to Igor.
> 
> It's definitely not a High bug. The biggest problem I see here is a confusing 
> error message with a wrong number of required IPs. AFAIU we cannot fix it 
> easily now so let's postpone it to 8.0 but change a message itself [0] in 7.0.
> 
> [0] 
> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/task/task.py#L1160-L1163
>  
> 
> 
> On Tue, Sep 1, 2015 at 1:39 PM, Igor Kalnitsky  > wrote:
> Hello,
> 
> My 5 cents on it.
> 
> I don't think it's really a High or Critical bug for 7.0. If there's
> not enough IPs the CheckBeforeDeploymentTask will fail. And that's
> actually Ok, it may fail by different reason without starting actual
> deployment (sending message to Astute).
> 
> But I agree it's kinda strange that we don't check IPs during network
> verification step. The good fix in my opinion is to move this check
> into network checker (perhaps keep it here either), but that
> definitely shouldn't be done in 7.0.
> 
> Thanks,
> Igor
> 
> 
> On Mon, Aug 31, 2015 at 2:54 PM, Roman Prykhodchenko  > wrote:
> > Hi folks!
> >
> > Recently a problem that network check does not tell whether there’s enough 
> > IP addresses in a public network [1] was reported. That check is performed 
> > by CheckBeforeDeployment task, but there is two problems that happen 
> > because this verification is done that late:
> >
> >  - A deployment fails, if there’s not enough addresses in specified ranges
> >  - If a user wants to get network configuration they will get an error
> >
> > The solution for this problems seems to be easy and a straightforward patch 
> > [2] was proposed. However, there is a hidden problem which is that patch 
> > does not address which is that installed plugins may reserve VIPs for their 
> > needs. The issue is that they do it just before deployment and so it’s not 
> > possible to get those reservations when a user wants to check their network 
> > set up.
> >
> > The important issue we have to address here is that network configuration 
> > generator will fail, if specified ranges don’t fit all VIPs. There were 
> > several proposals to fix that, I’d like to highlight two of them:
> >
> >  a) Allow VIPs to not have an IP address assigned, if network config 
> > generator works for API output.
> >  That will prevent GET requests from failure, but since IP addresses 
> > for VIPs are required, generator will have to fail, if it generates a 
> > configuration for the orchestrator.
> >  b) Add a release note that users have to calculate IP addresses manually 
> > and put sane ranges in order to not shoot their own legs. Then it’s also 
> > possible to change network verification output to remind users to check the 
> > ranges before starting a deployment.
> >
> > In my opinion we cannot follow (a) because it only masks a problem instead 
> > of providing a fix. Also it requires to change the API which is not a good 
> > thing to do after the SCF. If we choose (b), then we can work on a firm 
> > solution in 8.0 and fix the problem for real.
> >
> >
> > P. S. We can still merge [2], because it checks, if IP ranges can at least 
> > fit the basic configuration. If you agree, I will update it soon.
> >
> > [1] https://bugs.launchpad.net/fuel/+bug/1487996 
> > 
> > [2] https://review.openstack.org/#/c/217267/ 
> > 
> >
> >
> >
> > - 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 
> 
> 
> 
> 
> --
> Andrey Danin
> ada...@mirantis.com 
> skype: gcon.monolake
> __
> OpenStack Development Mailing 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
Des

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

[Cody Herriges]

Iury Gregory wrote:
> Hi Cody,
> If there is patches using $::os_service_default and they are blocked, I
> think the owner just need to request removal and continue the work.( I
> think ) 
> 

Iury,

Now that the standard is $::os_service_default does it mean that current
changes up for review with parameters set to the string '' should be changed to $::os_service_default before merge?


-- 
Cody



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] [Fuel] HA cluster disk monitoring, failover and recovery

[Andrew Beekhof]

> On 18 Nov 2015, at 4:52 AM, Alex Schultz  wrote:
> 
> On Tue, Nov 17, 2015 at 11:12 AM, Vladimir Kuklin  
> wrote:
>> Bogdan
>> 
>> I think we should firstly check whether attribute deletion leads to node
>> starting its services or not. From what I read in the official Pacemaker
>> documentation, it should work out of the box without the need to restart the
>> node.
> 
> It does start up the services when the attribute is cleared. QA has a
> test to validate this as part of this change.
> 
>> And by the way the quote above mentions 'use ONE of the following methods'
>> meaning that we could actually use attribute deletion. The 2nd and the 3rd
>> options do the same - they clear short-living node attribute. So we need to
>> figure out why OCF script does not update the corresponding attribute by
>> itself.
>> 
> 
> https://github.com/ClusterLabs/pacemaker/blob/master/extra/resources/SysInfo#L215-L227
> 
> It doesn't have something that updates it to green because essentially
> when this condition hits, the sysinfo service is also stopped. It has
> no way of knowing when it is cleared because all the resources are
> stopped and there is no longer a service running to reset the
> attribute.

There needs to be a way to mark cluster resources (specifically the sysinfo 
one) as being immune to the “red” condition.
Alas it hasn’t bubbled up the priority list yet.  Complaining definitely helps 
make it more visible :)

In the short-term, a cron job that called the agent would probably do the trick.

>  We would need something outside of pacemaker to mark it OK
> or perhaps write a custom health strategy[0][1] that would not stop
> the sysinfo task and update the ocf script to update the status to
> green if all disks are OK.
> 
> -Alex
> 
> [0] 
> https://github.com/openstack/fuel-library/blob/master/deployment/puppet/cluster/manifests/sysinfo.pp#L50-L55
> [1] http://clusterlabs.org/wiki/SystemHealth
> 
>> 
>> 
>> On Tue, Nov 17, 2015 at 7:03 PM, Bogdan Dobrelya 
>> wrote:
>>> 
>>> On 17.11.2015 15:28, Kyrylo Galanov wrote:
 Hi Team,
>>> 
>>> Hello
>>> 
 
 I have been testing fail-over after free disk space is less than 512 mb.
 (https://review.openstack.org/#/c/240951/)
 Affected node is stopped correctly and services migrate to a healthy
 node.
 
 However, after free disk space is more than 512 mb again the node does
 not recover it's state to operating. Moreover, starting the resources
 manually would rather fail. In a nutshell, the pacemaker service / node
 should be restarted. Detailed information is available
 here:
 https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_monitor_health.html
 
 How do we address this issue?
>>> 
>>> According to the docs you provided,
>>> " After a node's health status has turned to red, solve the issue that
>>> led to the problem. Then clear the red status to make the node eligible
>>> again for running resources. Log in to the cluster node and use one of
>>> the following methods:
>>> 
>>>Execute the following command:
>>> 
>>>crm node status-attr NODE delete #health_disk
>>> 
>>>Restart OpenAIS on that node.
>>> 
>>>Reboot the node.
>>> 
>>> The node will be returned to service and can run resources again. "
>>> 
>>> So this looks like an expected behaviour!
>>> 
>>> What else could be done:
>>> - We should check if we have this nuance documented, and submit a bug to
>>> fuel-docs team, if not yet there.
>>> - Submitting a bug and inspecting logs would be nice to do as well.
>>> I believe some optimizations may be done, bearing in mind this pacemaker
>>> cluster-recheck-interval and failure-timeout story [0].
>>> 
>>> [0]
>>> http://blog.kennyrasschaert.be/blog/2013/12/18/pacemaker-high-failability/
>>> 
 
 
 Best regards,
 Kyrylo
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
>>> 
>>> 
>>> --
>>> Best regards,
>>> Bogdan Dobrelya,
>>> Irc #bogdando
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> 
>> --
>> 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
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscrib

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

[Clayton O'Neill]

On Tue, Nov 17, 2015 at 4:38 PM, Cody Herriges  wrote:

> Now that the standard is $::os_service_default does it mean that current
> changes up for review with parameters set to the string ' DEFAULT>' should be changed to $::os_service_default before merge?
>

The decision was to grandfather any existing patches and any new patches
after today would be required to use $:os_service_default.
__
OpenStack Development Mailing 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] Autoscaling both clusters and containers

[Ryan Rossiter]

Hi all,

I was having a discussion with a teammate with respect to container 
scaling. He likes the aspect of nova-docker that allows you to scale 
(essentially) infinitely almost instantly, assuming you are using a 
large pool of compute hosts. In the case of Magnum, if I'm a container 
user, I don't want to be paying for a ton of vms that just sit idle, but 
I also want to have enough vms to handle my scale when I infrequently 
need it. But above all, when I need scale, I don't want to suddenly have 
to go boot vms and wait for them to start up when I really need it.


I saw [1] which discusses container scaling, but I'm thinking we can 
take this one step further. If I don't want to pay for a lot of vms when 
I'm not using them, could I set up an autoscale policy that allows my 
cluster to expand when my container concentration gets too high on my 
existing cluster? It's kind of a case of nested autoscaling. The 
containers are scaled based on request demand, and the cluster vms are 
scaled based on container count.


I'm unsure of the details of Senlin, but at least looking at Heat 
autoscaling [2], this would not be very hard to add to the Magnum 
templates, and we would forward those on through the bay API. (I figure 
we would do this through the bay, not baymodel, because I can see 
similar clusters that would want to be scaled differently).


Let me know if I'm totally crazy or if this is a good idea (or if you 
guys have already talked about this before). I would be interested in 
your feedback.


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078628.html

[2] https://wiki.openstack.org/wiki/Heat/AutoScaling#AutoScaling_API

--
Thanks,

Ryan Rossiter (rlrossit)


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

Re: [openstack-dev] [openstack-infra] Adding new members to new vitrage-dashboard-core group in gerrit is disabled

[Elizabeth K. Joseph]

On Tue, Nov 17, 2015 at 5:17 AM, GROSZ, Maty (Maty)
 wrote:
> Two questions regarding new project init:
>
> 1) A new change, https://review.openstack.org/#/c/245671/, was merged
> earlier.
> In the change, I created a new gerrit group - vitrage-dashboard–core.
> When I open gerrit UI – I don’t see myself in the list, and I cannot add
> anyone as the option to add is disabled.

This is not done automatically, you need to contact the OpenStack
infrastructure team (of which I'm a part of) to add the initial
member. I have gone ahead and added you to vitrage-dashboard-core.

> 2) Looking in launchpad for Vitrage and python-vitrageclient project:
> How does the “Series and milestones” section and "Development focus:” in
> launchpad is updated? I only see “trunk” and “trunk series” instead of
> mitake/ and mitaka series

I don't know the answer to this one.

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
OpenStack Development Mailing 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] Making stable maintenance its own OpenStack project team

[Matt Riedemann]

On 11/13/2015 8:10 AM, Thierry Carrez wrote:

So.. quick summary of this thread so far.

(-)
* Not enough work to warrant a designated "team", now that the work is
decentralized and the cats are mostly herding themselves
* The change is unlikely to bring a meaningful improvement to the
situation, or sudden new resources

(+)
* An empowered team could tackle new coordination tasks, like engaging
more directly in converging stable branch rules across teams, or
producing tools
* Release management doesn't overlap anymore with stable branch, so
having them under that PTL is limiting and inefficient
* Reinforcing the branding (by giving it its own team) may encourage
more organizations to affect new resources to it

In summary, I think this is worth a try. If the team fails, at least it
will be on its own rather than as the 5th squeaky wheel of release
management (where lack of leadership and focus could be rightly blamed
for failure).

For this to succeed, we need someone to own the effort and push it
forward, and a number of people caring enough about it to attend regular
meetings about it and to lurk on #openstack-stable. I'm fine helping the
team in the spin-off effort but I don't want to lead it (I proved I was
unable to make it my top priority in the past, so I think the team
deserves a more focused lead).

Erno has volunteered to lead. Ihar, Alan (Pevec) and myself don't have
enough time to lead but are happy to help. Anyone else interested to
join that initial group ? Flavio ? Matt ?

Once we have a list of key members we should set up a meeting to discuss
the details.



I've been doing some thinking in the last week and I'm going to throw my 
hat in the ring for leading this. I've definitely played devil's 
advocate in this thread, but I think it also points out several issues 
that are going to require some focused work and communication and I 
think I'm suited to lead that.


Background:

* I've been stable-maint-core since April. I primarily focus on nova 
stable branches but also get into other projects when necessary for 
critical bugs and blocking gate issues.
* Much of my focus is on the CI issues, i.e. Tony's tangled web of 
onions. I already deal enough in QA on trunk that it's a natural 
extension to stable branches.

* python-novaclient release liaison.
* I already do quite a bit of stable branch maintenance internally 
(which is how I got involved with it upstream too). So I have incentive 
to keep it working.


This is basically what I see for PTL of a stable maint team:

1. Helping projects deal with stable branch policy and process. We are 
decentralizing now but I suspect there will still be a lot of learning 
and cat herding needed in individual projects. This includes being 
around to help (I'm always in #openstack-stable) and helping to 
coordinate point releases as needed.


2. Keeping the CI system working on stable. This is already something 
I've been doing on stable for a long time so that just continues. It 
also means keeping a finger on how the periodic nightly jobs are doing 
and getting projects involved/aware when their stable branches are 
failing (bringing that up in the mailing list, project meetings or a 
cross project meeting as needed). An extension of this is seeing what we 
can do to try and keep stable branches around longer, which is clearly 
something the operator community has been wanting.


3. Mentoring. A big part of this thread is talking about a lack of 
resources to work on stable branch issues (usually CI). So part of 
mentoring here is identifying and helping people that are wanting to 
work in this space. A perfect example is tonyb and the work he's done 
the past several months on tracking gate failures and blocking issues. 
It also includes keeping track of who's doing a good job with reviews 
and seeing if they are ready for core.


4. Identifying official tags for a project, which doesn't just mean they 
have a stable branch but that they abide by the stable branch policy 
(what's appropriate to backport) and that they are maintaining their 
stable branches; this means actually reviewing proposed changes, being 
proactive about backporting high severity fixes, and keeping their CI 
jobs clean.


5. Looking for ways to improve processes and tooling. One thing that has 
come up in this thread was a need for tooling to identify backportable 
changes (e.g. a high severity bug is marked as backport potential in 
launchpad but no one has done the backport yet). I'm also not entirely 
sure we have something today that is tracking stable branch review stats 
so that we can identify people that are doing (or cores not doing) reviews.


So this is a bit long-winded but it's what I see as being important for 
a separate team and PTL to do in this space. If we're going to do this, 
I want to make sure these things are covered and I think I'm in a 
position to do that.


--

Thanks,

Matt Riedemann


_

Re: [openstack-dev] [oslo] [nova] default-next-release opt flag

[Matt Riedemann]

On 11/17/2015 2:05 PM, Sylvain Bauza wrote:



Le 17/11/2015 20:25, Sean Dague a écrit :

On 11/17/2015 01:48 PM, Matt Riedemann wrote:


On 11/17/2015 11:28 AM, Alexis Lee wrote:

Often in Nova we introduce an option defaulted off (so as not to break
people) but then we want to make it default in the next release.

Someone suggested an opt flag to mark this but I don't know what impact
they wanted it to have. IE how the user should be alerted about the
presence of these flagged options.

If you are that person, or have opinions on this, please reply :)


Alexis (lxsli)


There is the deprecated_for_removal kwarg, but that doesn't fit here.
There is the DeprecatedOpt, but that's for moving/renaming options. So
this is something else, like deprecated_default or
pending_default_change or something.

Honestly, with reno now we could probably just add a release note in
when we add it. That's more likely for us to not loose a thing like that.

-Sean



Agreed, it's now far easier to ask for having a release note within the
change, so the operators can just look at that. It also seems to me far
better for them to check the release notes rather than trying to see the
huge nova.conf file...

-Sylvain


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



Sure, a release note is justified, just like when we deprecate or rename 
an option.


The thing I like about the deprecated_for_removal kwarg is the warning 
that gets logged when you are still using the thing. I'm sure people see 
release notes for deprecated things and say, I'll add a TODO to clean 
this up in our tooling, but then get busy and forget about it until they 
break. The annoying warning is a constant indicator that this is 
something you need to move off of sooner rather than later.


Just my 2 cents.

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Zane Bitter]

On 17/11/15 13:38, Alan Pevec wrote:

2015-11-12 21:37 GMT+01:00 Zane Bitter :

https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:stable/juno,n,z

It would be nice to treat the remaining 'High' priority one as a blocker.
The rest aren't a blocker for the release but it would be really nice to at
least have time to get them all backported and merged before the stable
branch gets deleted.


There are still quite a few open reviews for Heat Juno, please tell us
which should be merged as freeze exceptions, because immediately after
freeze Juno goes EOL!

* https://review.openstack.org/245368 Medium
https://bugs.launchpad.net/heat/+bug/1424600
* https://review.openstack.org/245373 Medium
https://bugs.launchpad.net/heat/+bug/1424899
* https://review.openstack.org/246113 Medium
https://bugs.launchpad.net/heat/+bug/1471135
* https://review.openstack.org/244957 Medium
https://bugs.launchpad.net/heat/+bug/1418935
* https://review.openstack.org/246192 High
https://bugs.launchpad.net/heat/+bug/1508096
* https://review.openstack.org/246163 Undecided
https://bugs.launchpad.net/heat/+bug/1419693


This is not the last of them either.

I don't want to hold up the release for everybody. We got the 
High-priority fixes from Kilo that had been languishing on the backlog 
in already.


It's nice to get patches merged, but the more important thing is to get 
reviews up because distributors can always grab patches from reviews, 
but once the branch is deleted and there are no more Jenkins tests we 
lose the ability to collaborate in any meaningful way on backports, and 
everybody is on their own. That's what we're trying to focus on at the 
moment.


cheers,
Zane.

__
OpenStack Development Mailing 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] [keystone][stable] nominating lin hua cheng for keystone-stable-maint

[Steve Martinelli]

I'd like to nominate Lin Hua Cheng for keystone-stable-maint. He has been
doing reviews on keystone's liberty and kilo stable branches since mitaka
development has opened, and being a member of horizon-stable-maint, he is
already familiar with stable branch policies. If there are no objections
from the current stable-maint-core and keystone-stable-maint teams, then
I'd like to add him.

Thanks,

Steve Martinelli
Keystone Project Team Lead
__
OpenStack Development Mailing 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][infra] Getting a bleeding edge libvirt gate job running

[Jay Pipes]

On 11/17/2015 11:10 AM, Markus Zoeller wrote:

Background
==
The blueprint [1] wants to utilize the *virtlogd* logging deamon from
libvirt. Among others to solve bug [2], one of our oldest ones. The
funny part is, that this libvirt feature is still in development. This
was a trigger to see if we can create a gate job which utilizes the
latest, bleeding edge, version of libvirt to test such features. We
discussed it shortly in IRC [3] (tonyb, bauzas, markus_z) and wanted to
get some feedback here. The summary of the idea is:
* Create a custom repo which contains the latest libvirt version
* Enhance Devstack so that it can point to a custom repo to install
   the built libvirt packages
* Have a nodepool image which is compatible with the libvirt packages
* In case of [1]: check if tempest needs further/changed tests

Open questions
==
* Is already someone working on something like that and I missed it?


Sean (cc'd) might have some information on what he's doing in the OVS w/ 
DPDK build environment, which AFAIK requires a later build of libvirt 
than available in most distros.



* If 'no', is there already a repo which contains the very latest
   libvirt builds which we can utilize?

I haven't done anything with the gates before, which means there is a
very high chance I'm missing something or missunderstanding a concept.
Please let me know what you think.


A generic "build libvirt or OVS from this source repo" dsvm job would be 
great I think. That would allow overrides in ENV variables to point the 
job to a URI for grabbing sources of OVS (DPDK OVS, mainline OVS) or 
libvirt that would be built into the target nodepool images.


Thoughts?

Best,
-jay


References
==
[1] Nova spec "Libvirt: Use the virtlogd deamon for logs":
 https://review.openstack.org/#/c/234291/
[2] Nova; bugs; "console.log grows indefinitely"
 https://bugs.launchpad.net/nova/+bug/832507
[3] #openstack-nova; 2015-11-17:

http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2015-11-17.log.html#t2015-11-17T08:44:57

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

Re: [openstack-dev] [magnum] Autoscaling both clusters and containers

[Ton Ngo]

Hi Ryan,
 There was a talk in the last Summit on this topics to explore the
options with Magnum, Senlin, Heat, Kubernetes:
https://www.openstack.org/summit/tokyo-2015/videos/presentation/exploring-magnum-and-senlin-integration-for-autoscaling-containers
A demo was shown with Senlin interfacing to Magnum to autoscale.
There was also a Magnum design session to discuss this same topics.
The use cases are similar to what you describe.  Because the subject is
complex, there are many moving parts, and multiple teams/projects are
involved, one outcome of the design session is that we will write a spec on
autoscaling containers and cluster.  A patch should be coming soon, so it
would be great to have your input on the spec.
Ton,



From:   Ryan Rossiter 
To: openstack-dev@lists.openstack.org
Date:   11/17/2015 02:05 PM
Subject:[openstack-dev] [magnum] Autoscaling both clusters and
containers



Hi all,

I was having a discussion with a teammate with respect to container
scaling. He likes the aspect of nova-docker that allows you to scale
(essentially) infinitely almost instantly, assuming you are using a
large pool of compute hosts. In the case of Magnum, if I'm a container
user, I don't want to be paying for a ton of vms that just sit idle, but
I also want to have enough vms to handle my scale when I infrequently
need it. But above all, when I need scale, I don't want to suddenly have
to go boot vms and wait for them to start up when I really need it.

I saw [1] which discusses container scaling, but I'm thinking we can
take this one step further. If I don't want to pay for a lot of vms when
I'm not using them, could I set up an autoscale policy that allows my
cluster to expand when my container concentration gets too high on my
existing cluster? It's kind of a case of nested autoscaling. The
containers are scaled based on request demand, and the cluster vms are
scaled based on container count.

I'm unsure of the details of Senlin, but at least looking at Heat
autoscaling [2], this would not be very hard to add to the Magnum
templates, and we would forward those on through the bay API. (I figure
we would do this through the bay, not baymodel, because I can see
similar clusters that would want to be scaled differently).

Let me know if I'm totally crazy or if this is a good idea (or if you
guys have already talked about this before). I would be interested in
your feedback.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078628.html

[2] https://wiki.openstack.org/wiki/Heat/AutoScaling#AutoScaling_API

--
Thanks,

Ryan Rossiter (rlrossit)


__
OpenStack Development Mailing 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] [nfv][telco][product] Future of telco working group and weekly meeting reminder

[Steve Gordon]

Hi all,

Back in Vancouver [1] we began discussing the growing overlap between OPNFV 
requirements projects and the current mission of the telco working group. 
During this period the product working group, also in part focused on recording 
and prioritizing user stories, has also been hitting its straps. As we have 
recently lost a couple of core members of the telco working group particularly 
on the technical side due to role changes etc. I think it is time to roll its 
activities into these efforts.

With that in mind I would like to propose:

* Submitting the existing telcowg-usecases to the openstack-user-stories 
repository
* Engaging within the product working group (assuming they will have us ;)) as 
owners of these user stories

There is of course still a need to actually *implement* the requirements 
exposed by these user stories but I am hopeful that together we can work 
through a common process for this rather than continuing to attack it 
separately. I would personally still like to see greater direct engagement from 
service providers, but it seems like OPNFV and/or the OpenStack User Committee 
[2] itself might be the right place for this going forward.

I'd like to discuss this proposal further in the weekly meeting. This week's 
Telco Working Group meeting is scheduled for Wednesday the 18th at 1400 UTC. As 
always the agenda etherpad is here:

https://etherpad.openstack.org/p/nfv-meeting-agenda

Thanks all!

Steve

[1] https://etherpad.openstack.org/p/YVR-ops-telco
[2] https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee

__
OpenStack Development Mailing 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] nova-manage db archive_deleted_rows broken

[Matt Riedemann]

On 10/9/2015 1:16 PM, Matt Riedemann wrote:



On 10/9/2015 12:03 PM, Jay Pipes wrote:

On 10/07/2015 11:04 AM, Matt Riedemann wrote:

I'm wondering why we don't reverse sort the tables using the sqlalchemy
metadata object before processing the tables for delete?  That's the
same thing I did in the 267 migration since we needed to process the
tree starting with the leafs and then eventually get back to the
instances table (since most roads lead to the instances table).


Yes, that would make a lot of sense to me if we used the SA metadata
object for reverse sorting.


When I get some free time next week I'm going to play with this.




Another thing that's really weird is how max_rows is used in this code.
There is cumulative tracking of the max_rows value so if the value you
pass in is too small, you might not actually be removing anything.

I figured max_rows meant up to max_rows from each table, not max_rows
*total* across all tables. By my count, there are 52 tables in the nova
db model. The way I read the code, if I pass in max_rows=10 and say it
processes table A and archives 7 rows, then when it processes table B it
will pass max_rows=(max_rows - rows_archived), which would be 3 for
table B. If we archive 3 rows from table B, rows_archived >= max_rows
and we quit. So to really make this work, you have to pass in something
big for max_rows, like 1000, which seems completely random.

Does this seem odd to anyone else?


Uhm, yes it does.

 > Given the relationships between

tables, I'd think you'd want to try and delete max_rows for all tables,
so archive 10 instances, 10 block_device_mapping, 10 pci_devices, etc.

I'm also bringing this up now because there is a thread in the operators
list which pointed me to a set of scripts that operators at GoDaddy are
using for archiving deleted rows:

http://lists.openstack.org/pipermail/openstack-operators/2015-October/008392.html



Presumably because the command in nova doesn't work. We should either
make this thing work or just punt and delete it because no one cares.


The db archive code in Nova just doesn't make much sense to me at all.
The algorithm for purging stuff, like you mention above, does not take
into account the relationships between tables; instead of diving into
the children relations and archiving those first, the code just uses a
simplistic "well, if we hit a foreign key error, just ignore and
continue archiving other things, we will eventually repeat the call to
delete this row" strategy:

https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L6021-L6023



Yeah, I noticed that too and I don't think it actually does anything. We
never actually come back since that would require some
tracking/stack/recursion stuff to retry failed tables, which we don't do.




I had a proposal [1] to completely rework the whole shadow table mess
and db archiving functionality. I continue to believe that is the
appropriate solution for this, and that we should rip out the existing
functionality because it simply does not work properly.

Best,
-jay

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


Are you going to pick that back up? Or sick some minions on 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





I found some time to work on a reverse sort of nova's tables for the db 
archive command, that looks like [1].  It works fine in the unit tests, 
but fails because the deleted instances are referenced by 
instance_actions that aren't deleted.  I see any DB APIs for deleting 
instance actions.


Were we just planning on instance_actions living forever in the database?

Should we soft delete instance_actions when we delete the referenced 
instance?


Or should we (hard) delete instance_actions when we archive (move to 
shadow tables) soft deleted instances?


This is going to be a blocker to getting nova-manage db 
archive_deleted_rows working.


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

--

Thanks,

Matt Riedemann


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

[openstack-dev] [trove] trove unit tests failing on stable/kilo

[Matt Riedemann]

I noticed this failing today:

http://logs.openstack.org/81/206681/3/check/gate-trove-python27/45d645d/console.html#_2015-11-17_17_07_28_061

Looks like https://review.openstack.org/#/c/218701/ and maybe the 
dependent python-troveclient change would need to be backported to 
stable/kilo (neither are clean backports), or we can just skip the test 
on stable/kilo if there is a good reason why it won't work.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [trove] trove unit tests failing on stable/kilo

[Matt Riedemann]

On 11/17/2015 9:22 PM, Matt Riedemann wrote:

I noticed this failing today:

http://logs.openstack.org/81/206681/3/check/gate-trove-python27/45d645d/console.html#_2015-11-17_17_07_28_061


Looks like https://review.openstack.org/#/c/218701/ and maybe the
dependent python-troveclient change would need to be backported to
stable/kilo (neither are clean backports), or we can just skip the test
on stable/kilo if there is a good reason why it won't work.



I also see that the unit test job on stable/kilo is pulling in trunk 
python-troveclient:


http://logs.openstack.org/81/206681/3/check/gate-trove-python27/45d645d/console.html#_2015-11-17_17_07_28_393

Even though we have troveclient capped at 1.1.0 in kilo g-r:

https://github.com/openstack/requirements/blob/stable/kilo/global-requirements.txt#L136

So how is that happening?

Oh, because of this:

https://github.com/openstack/trove/blob/stable/kilo/test-requirements.txt#L17

And that's terriblewhy are we doing that?

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [trove] trove unit tests failing on stable/kilo

[Matt Riedemann]

On 11/17/2015 9:27 PM, Matt Riedemann wrote:



On 11/17/2015 9:22 PM, Matt Riedemann wrote:

I noticed this failing today:

http://logs.openstack.org/81/206681/3/check/gate-trove-python27/45d645d/console.html#_2015-11-17_17_07_28_061



Looks like https://review.openstack.org/#/c/218701/ and maybe the
dependent python-troveclient change would need to be backported to
stable/kilo (neither are clean backports), or we can just skip the test
on stable/kilo if there is a good reason why it won't work.



I also see that the unit test job on stable/kilo is pulling in trunk
python-troveclient:

http://logs.openstack.org/81/206681/3/check/gate-trove-python27/45d645d/console.html#_2015-11-17_17_07_28_393


Even though we have troveclient capped at 1.1.0 in kilo g-r:

https://github.com/openstack/requirements/blob/stable/kilo/global-requirements.txt#L136


So how is that happening?

Oh, because of this:

https://github.com/openstack/trove/blob/stable/kilo/test-requirements.txt#L17


And that's terriblewhy are we doing that?



Attempting to fix here: https://review.openstack.org/#/c/246735/

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [nova] nova-manage db archive_deleted_rows broken

[Jay Pipes]

On 11/17/2015 05:43 PM, Matt Riedemann wrote:

I found some time to work on a reverse sort of nova's tables for the db
archive command, that looks like [1].  It works fine in the unit tests,
but fails because the deleted instances are referenced by
instance_actions that aren't deleted.  I see any DB APIs for deleting
instance actions.

Were we just planning on instance_actions living forever in the database?


Not as far as I understand.


Should we soft delete instance_actions when we delete the referenced
instance?


No.


Or should we (hard) delete instance_actions when we archive (move to
shadow tables) soft deleted instances?


Yes.

Best,
-jay


This is going to be a blocker to getting nova-manage db
archive_deleted_rows working.

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



__
OpenStack Development Mailing 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] nova-manage db archive_deleted_rows broken

[Matt Riedemann]

On 11/17/2015 7:43 PM, Matt Riedemann wrote:



On 10/9/2015 1:16 PM, Matt Riedemann wrote:



On 10/9/2015 12:03 PM, Jay Pipes wrote:

On 10/07/2015 11:04 AM, Matt Riedemann wrote:

I'm wondering why we don't reverse sort the tables using the sqlalchemy
metadata object before processing the tables for delete?  That's the
same thing I did in the 267 migration since we needed to process the
tree starting with the leafs and then eventually get back to the
instances table (since most roads lead to the instances table).


Yes, that would make a lot of sense to me if we used the SA metadata
object for reverse sorting.


When I get some free time next week I'm going to play with this.




Another thing that's really weird is how max_rows is used in this code.
There is cumulative tracking of the max_rows value so if the value you
pass in is too small, you might not actually be removing anything.

I figured max_rows meant up to max_rows from each table, not max_rows
*total* across all tables. By my count, there are 52 tables in the nova
db model. The way I read the code, if I pass in max_rows=10 and say it
processes table A and archives 7 rows, then when it processes table
B it
will pass max_rows=(max_rows - rows_archived), which would be 3 for
table B. If we archive 3 rows from table B, rows_archived >= max_rows
and we quit. So to really make this work, you have to pass in something
big for max_rows, like 1000, which seems completely random.

Does this seem odd to anyone else?


Uhm, yes it does.

 > Given the relationships between

tables, I'd think you'd want to try and delete max_rows for all tables,
so archive 10 instances, 10 block_device_mapping, 10 pci_devices, etc.

I'm also bringing this up now because there is a thread in the
operators
list which pointed me to a set of scripts that operators at GoDaddy are
using for archiving deleted rows:

http://lists.openstack.org/pipermail/openstack-operators/2015-October/008392.html




Presumably because the command in nova doesn't work. We should either
make this thing work or just punt and delete it because no one cares.


The db archive code in Nova just doesn't make much sense to me at all.
The algorithm for purging stuff, like you mention above, does not take
into account the relationships between tables; instead of diving into
the children relations and archiving those first, the code just uses a
simplistic "well, if we hit a foreign key error, just ignore and
continue archiving other things, we will eventually repeat the call to
delete this row" strategy:

https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L6021-L6023




Yeah, I noticed that too and I don't think it actually does anything. We
never actually come back since that would require some
tracking/stack/recursion stuff to retry failed tables, which we don't do.




I had a proposal [1] to completely rework the whole shadow table mess
and db archiving functionality. I continue to believe that is the
appropriate solution for this, and that we should rip out the existing
functionality because it simply does not work properly.

Best,
-jay

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


Are you going to pick that back up? Or sick some minions on 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





I found some time to work on a reverse sort of nova's tables for the db
archive command, that looks like [1].  It works fine in the unit tests,
but fails because the deleted instances are referenced by
instance_actions that aren't deleted.  I see any DB APIs for deleting
instance actions.


I *don't* see any DB APIs for deleting instance actions.

Kind of an important difference there.  Jay got it at least. :)



Were we just planning on instance_actions living forever in the database?

Should we soft delete instance_actions when we delete the referenced
instance?

Or should we (hard) delete instance_actions when we archive (move to
shadow tables) soft deleted instances?

This is going to be a blocker to getting nova-manage db
archive_deleted_rows working.

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



--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] Is latest PyCharm license still available?

[Swapnil Kulkarni]

The PyCharm licences are available for OpenStack developers, please send me
your lauchpad-id off-list, I will help you with the updated link. Thanks

Best Regards,
Swapnil Kulkarni
irc : coolsvap


On Tue, Nov 17, 2015 at 10:06 PM, OpenStack Mailing List Archive <
cor...@gmail.com> wrote:

> Link: https://openstack.nimeyo.com/65517/?show=65517#q65517
> From: vanderwl 
>
> I tried the link above, but got: "Invitation code is not valid." from the
> jetbrains website.
>
> Has something in getting the license steps changed again?
>
> __
> OpenStack Development Mailing 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][ThirdPartyCI] Running third party CI on networking-foo projects

[Takashi Yamamoto]

hi,

On Wed, Nov 18, 2015 at 2:00 AM, Fawad Khaliq  wrote:
> Folks,
>
> What would be the mechanism to enable a third party CI on a Neutron
> sub-project? I am not sure if anyone has already tried it.

networking-ofagent has its third party CI running.
you can ask kakuma for details.

>
> I am interesting in adding PLUMgrid CI on networking-plumgrid [1]
>
> cc: Mike
>
> [1] https://github.com/openstack/networking-plumgrid
>
> Thanks,
> Fawad Khaliq
>
>
> __
> OpenStack Development Mailing 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] [Manila] Attach/detach semantics

[Ben Swartzlander]

On 11/17/2015 10:02 AM, John Spray wrote:

Hi all,

As you may know, there is ongoing work on a spec for Nova to define an
"attach/detach" API for tighter integration with Manila.

The concept here is that this mechanism will be needed to implement
hypervisor mediated FS access using vsock, but that the mechanism
should also be applicable more generally to an "attach" concept for
filesystems accessed over IP networks (like existing NFS filers).

In the hypervisor-mediated case, attach would involve the hypervisor
host connecting as a filesystem client and then re-exporting to the
guest via a local address.  We think this would apply to
driver_handles_share_servers type drivers that support share networks,
by mapping the attach/detach share API to attaching/detaching the
share network from the guest VM.

Does that make sense to people maintaining this type of driver?  For
example, for the netapp and generic drivers, is it reasonable to
expose nova attach/detach APIs that attach and detach the associated
share network?


I'm not sure this proposal makes sense. I would like the share 
attach/detach semantics to be the same for all types of shares, 
regardless of the driver type.


The main challenge with attaching to shares on share servers (with share 
networks) is that there may not exist a network route from the 
hypervisor to the share server, because share servers are only required 
to be accessible from the share network from which they are created. 
This has been a known problem since Liberty because this behaviour 
prevents migration from working, therefore we're proposing a mechanism 
for share-server drivers to provide admin-network-facing interfaces for 
all share servers. This same mechanism should be usable by the Nova when 
doing share attach/detach. Nova would just need to list the export 
locations using an admin-context to see the admin-facing export location 
that it should use.



I've CC'd Luis who is working on the Nova spec.

Regards,
John

__
OpenStack Development Mailing 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] [trove] trove unit tests failing on stable/kilo

[Nikhil Manchanda]

Thanks for putting up that fix Matt.

The dependency on trunk python-troveclient (for stable/kilo) definitely
seems
screwy-- but I'm wondering if this was done for backwards compatibility
reasons?
(i.e. to ensure the latest version of python-troveclient should be able to
work
correctly against all previous releases of trove.)

Either way, I think we should be honoring the requirements specified for
the respective
releases in g-r, so I think that this is the right fix.

Cheers,
Nikhil



On Tue, Nov 17, 2015 at 7:42 PM, Matt Riedemann 
wrote:

>
>
> On 11/17/2015 9:27 PM, Matt Riedemann wrote:
>
>>
>>
>> On 11/17/2015 9:22 PM, Matt Riedemann wrote:
>>
>>> I noticed this failing today:
>>>
>>>
>>> http://logs.openstack.org/81/206681/3/check/gate-trove-python27/45d645d/console.html#_2015-11-17_17_07_28_061
>>>
>>>
>>>
>>> Looks like https://review.openstack.org/#/c/218701/ and maybe the
>>> dependent python-troveclient change would need to be backported to
>>> stable/kilo (neither are clean backports), or we can just skip the test
>>> on stable/kilo if there is a good reason why it won't work.
>>>
>>>
>> I also see that the unit test job on stable/kilo is pulling in trunk
>> python-troveclient:
>>
>>
>> http://logs.openstack.org/81/206681/3/check/gate-trove-python27/45d645d/console.html#_2015-11-17_17_07_28_393
>>
>>
>> Even though we have troveclient capped at 1.1.0 in kilo g-r:
>>
>>
>> https://github.com/openstack/requirements/blob/stable/kilo/global-requirements.txt#L136
>>
>>
>> So how is that happening?
>>
>> Oh, because of this:
>>
>>
>> https://github.com/openstack/trove/blob/stable/kilo/test-requirements.txt#L17
>>
>>
>> And that's terriblewhy are we doing that?
>>
>>
> Attempting to fix here: https://review.openstack.org/#/c/246735/
>
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Autoscaling both clusters and containers

[Egor Guz]

Ryan

I haven’t seen any proposals/implementations from Mesos/Swarm (but  I am not 
following Mesos and Swam community very close these days).
But Kubernetes 1.1 has pod autoscaling 
(https://github.com/kubernetes/kubernetes/blob/master/docs/design/horizontal-pod-autoscaler.md),
which should cover containers auto-scaling. Also there is PR for cluster 
auto-scaling (https://github.com/kubernetes/kubernetes/pull/15304), which
has implementation for GCE, but OpenStack support can be added as well.

—
Egor

From: Ton Ngo mailto:t...@us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 17, 2015 at 16:58
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [magnum] Autoscaling both clusters and containers


Hi Ryan,
There was a talk in the last Summit on this topics to explore the options with 
Magnum, Senlin, Heat, Kubernetes:
https://www.openstack.org/summit/tokyo-2015/videos/presentation/exploring-magnum-and-senlin-integration-for-autoscaling-containers
A demo was shown with Senlin interfacing to Magnum to autoscale.
There was also a Magnum design session to discuss this same topics. The use 
cases are similar to what you describe. Because the subject is complex, there 
are many moving parts, and multiple teams/projects are involved, one outcome of 
the design session is that we will write a spec on autoscaling containers and 
cluster. A patch should be coming soon, so it would be great to have your input 
on the spec.
Ton,

[Inactive hide details for Ryan Rossiter ---11/17/2015 02:05:48 PM---Hi all, I 
was having a discussion with a teammate with resp]Ryan Rossiter ---11/17/2015 
02:05:48 PM---Hi all, I was having a discussion with a teammate with respect to 
container

From: Ryan Rossiter 
mailto:rlros...@linux.vnet.ibm.com>>
To: openstack-dev@lists.openstack.org
Date: 11/17/2015 02:05 PM
Subject: [openstack-dev] [magnum] Autoscaling both clusters and containers





Hi all,

I was having a discussion with a teammate with respect to container
scaling. He likes the aspect of nova-docker that allows you to scale
(essentially) infinitely almost instantly, assuming you are using a
large pool of compute hosts. In the case of Magnum, if I'm a container
user, I don't want to be paying for a ton of vms that just sit idle, but
I also want to have enough vms to handle my scale when I infrequently
need it. But above all, when I need scale, I don't want to suddenly have
to go boot vms and wait for them to start up when I really need it.

I saw [1] which discusses container scaling, but I'm thinking we can
take this one step further. If I don't want to pay for a lot of vms when
I'm not using them, could I set up an autoscale policy that allows my
cluster to expand when my container concentration gets too high on my
existing cluster? It's kind of a case of nested autoscaling. The
containers are scaled based on request demand, and the cluster vms are
scaled based on container count.

I'm unsure of the details of Senlin, but at least looking at Heat
autoscaling [2], this would not be very hard to add to the Magnum
templates, and we would forward those on through the bay API. (I figure
we would do this through the bay, not baymodel, because I can see
similar clusters that would want to be scaled differently).

Let me know if I'm totally crazy or if this is a good idea (or if you
guys have already talked about this before). I would be interested in
your feedback.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078628.html
[2] https://wiki.openstack.org/wiki/Heat/AutoScaling#AutoScaling_API

--
Thanks,

Ryan Rossiter (rlrossit)


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