[openstack-dev] [designate] Designate performance issues

Hi all. I have setup kilo designate services with powerdns backend and mysql innodb storage in a single node. The services function well at first. However, after inserting 13k A records via API within 3 domains (5k, 5k, 3k for each), the service stops working. designate-api returns 500 and many R

Re: [openstack-dev] [Nova][Cinder] Questions re progress

> So others have/will chime in here... one thing I think is kinda missing in > the statement above is the "single host", that's actually the whole point > of Ceph and other vendor driven clustered storage technologies out there. > There's a ton to choose from at this point, open source as well as >

Re: [openstack-dev] [Nova][Cinder] Questions re progress

Hi Adam, Disclaimer: i work for a company interested in providing solutions based on openstack, but this email should not be considered marketing/promotional Regarding your second question "Using Swift as a back-end for Cinder", we already have a solution for this, a part of which is a Cinder dri

[openstack-dev] [Ceilometer]Add hardware pollster of memory buffer and cache

Hello everyone, I am using Ceilometer to monitor both physical servers and virtutal machines in IAAS. And I found current Ceilometer only support 4 memory oid of SNMP: _memory_total_oid = "1.3.6.1.4.1.2021.4.5.0" _memory_avail_real_oid = "1.3.6.1.4.1.2021.4.6.0" _memory_total_swap_oi

[openstack-dev] [infra][horizon] Need help at debugging requirements issue

Hello, I was trying to raise the cap for Django in[1]. It looks quite simple, current requirements is Django>=1.4.2,<1.7 and I simply removed the upper boundary: Django>=1.4.2 with the result, django-nose is not installed any more. (That's a rest dependency for horizon), it's listed in the same g

Re: [openstack-dev] [Fuel] Let's stick to OpenStack global requirements

Roman, all >>> - OSCI mirror should contain the maximum version of a requirement >>> that matches its version specification. I'm not sure it's good idea. We should stay so close to upstream distro as we can. It should be very important reason to update package against it's upstream distro

Re: [openstack-dev] [Fuel] Let's stick to OpenStack global requirements

Just one question regarding this bit: > >>> There are some plans (unfortunately I do not know details, so maybe > someone from OSCI could tell more) to split those repositories > Splitting of repositories doesn't help to solve python packages > conflicts because master node uses a number of openst

Re: [openstack-dev] [Fuel] FFE python-fuelclient improvements

https://review.openstack.org/#/q/status:open+project:stackforge/python-fuelclient+branch:master+topic:bp/re-thinking-fuel-client,n,z > 17 бер. 2015 о 18:51 Mike

Re: [openstack-dev] [Keystone][FFE] - IdP ID (remote_id) registration and validation

This is a good workaround to allow the authentication on the IdP but with the new websso is problematic because you do not know which mapping to use but you have the "Shib-Identity-Provider". With the new information the entityIDs are associated with the keystone IdP so it is easy to find the ri

[openstack-dev] [heat][congress] Stack lifecycle plugpoint as an enabler for cloud provider's services

Hi, I'm looking at this interesting blueprint https://blueprints.launchpad.net/heat/+spec/stack-lifecycle-plugpoint and I hope you can easily clarify some things to me. I see the following statements related to this BP: * [in "problem description" section]: "There are at least two primary use c

Re: [openstack-dev] [Fuel] Let's stick to OpenStack global requirements

Folks, > I assume you meant: "If a requirement that previously was only in Fuel > Requirements is merged to Global Requirements, it should be removed > from *Fuel* Requirements». Exactly. > I'm not sure it's good idea. > We should stay so close to upstream distro as we can. It should be > very i

Re: [openstack-dev] [Fuel] FFE python-fuelclient improvements

+1 from me also On Thu, Mar 19, 2015 at 1:07 PM, Roman Prykhodchenko wrote: > > https://review.openstack.org/#/q/status:open+project:stackforge/python-fuelclient+branch:master+topic:bp/re-thinking-fuel-client,n,z > > 17 бер. 2015 о 18:51 Mike Scherbakov > написав(ла): > > Roman, > it would be g

Re: [openstack-dev] [Fuel] Let's stick to OpenStack global requirements

Folks, >>> Correct me if I am wrong, but isn't it what we have containers on master >>> node for? >>> On the master node itself conflicts won’t happen because the components are >>> run in their containers. Do you propose to use _separate_ package repository for each docker container? (It means

Re: [openstack-dev] [Fuel] Let's stick to OpenStack global requirements

I guess it would depend on how many docker containers are running on master node and if we are able to pull off such stunt :). I am not familiar with the amount of work needed to do sth like that, so the proposition may be silly. Just let me know if it is. On Thu, Mar 19, 2015 at 11:51 AM, Dmitry

[openstack-dev] [Neutron] VLAN transparency support

Hi, It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others. I do not think that this is the correct way to go and we should do this as all other extensions have been

Re: [openstack-dev] [Kolla] PTL Candidacy

Congrats, sdake !! -- pshige 2015-03-18 16:09 GMT+09:00 Daniel Comnea : > Congrats Steve! > > On Wed, Mar 18, 2015 at 12:51 AM, Daneyon Hansen (danehans) > wrote: >> >> >> Congratulations Steve! >> >> Regards, >> Daneyon Hansen >> Software Engineer >> Email: [email protected] >> Phone: 30

Re: [openstack-dev] [Keystone][FFE] - IdP ID (remote_id) registration and validation

This is more in line with my argument that we should not have 100 different end points and mapping rules for a federation of 100 IdPs, but rather one end point and one mapping for all trusted IdPs. But I still think that in order to make this design waterproof we need a trusted attributes policy as

[openstack-dev] [oslo.config][kolla] modular backends for oslo.cfg

Hello, While on a long oversea flight with Sebastien Han we were talking how he had implemented ceph-docker with central configuration over etcd. We quickly came up to the conclusion that if we wanted to have that in Kolla it would be neat if it was done straight from oslo.config so that would qui

Re: [openstack-dev] [Neutron] VLAN transparency support

Hi, This patch has the same addition too - https://review.openstack.org/#/c/154921/. We should also revert that one. Thanks Gary From: Gary Kotton mailto:[email protected]>> Reply-To: OpenStack List mailto:[email protected]>> Date: Thursday, March 19, 2015 at 1:14 PM To: OpenSta

Re: [openstack-dev] [Neutron] Neutron extenstions

Hi, Changed the subject so that it may draw a little attention. There were 2 patches approved that kind of break the API (in my humble opinion): https://review.openstack.org/#/c/154921/ and https://review.openstack.org/#/c/158420/ In both of these two new fields were added to the base attributes -

[openstack-dev] [Fuel] development tools

Hello, Some time ago I wrote some small tools that make Fuel development easier and it was suggested to add info about them to the documentation -- here's the review link [1]. Evgenyi Li correctly pointed out that we already have something like fuel_development already in fuel-web. I think though

Re: [openstack-dev] Mellanox request for permission for Nova CI

Hi Joe, Sorry for the late response. Here are some latest logs for the Nova CI: http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20150318_1650/ http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20150318_1506/ http://144.76.193.39/ci-artifacts/37/165437/1/check-nov

Re: [openstack-dev] [Fuel] development tools

As I wrote in the review already: I like the idea of merging those two tools and making a separate repository. After that we could make they more visible in our documentation and wiki so they could benefit from being used by broader audience. Same for vagrant configuration - if it's useful (and it

Re: [openstack-dev] [designate] Designate performance issues

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/19/2015 07:41 AM, stanzgy wrote: > Hi all. I have setup kilo designate services with powerdns backend and mysql > innodb storage in a single node. > The services function well at first. However, after inserting 13k A records via API within 3 d

Re: [openstack-dev] [Fuel] development tools

Hi folks, I agree, lets create separate repo with its own cores and remove fuel_development from fuel-web. But in this case I'm not sure if we should merge the patch which has links to non-stackforge repositories, because location is going to be changed soon. Also it will be cool to publish it o

Re: [openstack-dev] [designate] Designate performance issues

Hi Zhang, Thank you for reporting the bug. The number of records does not seem too high. At this point I do not have a suggestion to improve the situation, but I will investigate this. Could you file a bug report? Relevant log snippets would also be helpful. --vinod From: stanzgy mailto:stan.

Re: [openstack-dev] [Fuel] development tools

+1 -- there is no point for commiting that review with external urls if those repos are to be created in stackforge. P. On 03/19/2015 03:02 PM, Evgeniy L wrote: > Hi folks, > > I agree, lets create separate repo with its own cores and remove > fuel_development from fuel-web. > > But in this cas

Re: [openstack-dev] [Fuel] development tools

+1 for moving fuel_development into separate repo. On Thu, Mar 19, 2015 at 5:02 PM, Evgeniy L wrote: > Hi folks, > > I agree, lets create separate repo with its own cores and remove > fuel_development from fuel-web. > > But in this case I'm not sure if we should merge the patch which > has links

Re: [openstack-dev] [infra][horizon] Need help at debugging requirements issue

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/19/2015 10:16 AM, Matthias Runge wrote: > Hello, > > I was trying to raise the cap for Django in[1]. It looks quite > simple, current requirements is Django>=1.4.2,<1.7 and I simply > removed the upper boundary: Django>=1.4.2 > > with the resul

Re: [openstack-dev] [horizon][heat]Vote for Openstack L summit topic "The Heat Orchestration Template Builder: A demonstration"

Nikunj, aren't you going to present this talk together with Drago Rosson since he's the sole developer of Hotbuilder? That would be fair. Anyways, thanks for advertising Hotbuilder and Merlin :), both me and Drago have been spending inexcusably too little time spreading the word in the mailing li

[openstack-dev] [documentation]OpenStack API Reference for VPNaaS...

Hi, I created and am trying to work on https://bugs.launchpad.net/openstack-api-site/+bug/1433561. Is there someone who can advise me on how to create the WADL file for VPNaaS? I see the LBaaS one and can manually try to convert the old VPNaaS API documentation to a similar format, using a text e

Re: [openstack-dev] [oslo.config][kolla] modular backends for oslo.cfg

Chmouel, Nice! Ben added a topic "Alternative file formats for oslo.config" for Liberty[1]. this would be great if we can talk about alternative backends as well :) -- dims [1] https://etherpad.openstack.org/p/liberty-oslo-summit-planning On Thu, Mar 19, 2015 at 8:31 AM, Chmouel Boudjnah wrot

Re: [openstack-dev] [Neutron] Neutron extenstions

On Thu, Mar 19, 2015 at 05:37:59AM PDT, Gary Kotton wrote: > In my opinion these should be added as separate extensions. The spec that was approved for these patches does list the new attribute as being added to the Network object. http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nf

Re: [openstack-dev] [Neutron] Neutron extenstions

Hi Gary, First I’m seeing these, but I don’t see that they’re required on input, unless I’m mis-reading those reviews. Additional of new output fields to a json object, or adding optional inputs, is not generally considered to be backwards incompatible behavior in an API. Does OpenStack have a

Re: [openstack-dev] [Neutron] Neutron extenstions

?Isn't this argument as to whether those fields should be turned off/on, versus just always being on? Are there any guidelines as to what fields are allowed to be added in that base resource attr map? If ML2 needs these and other fields, should they just always be on? Thanks, Brandon _

Re: [openstack-dev] [cinder] All Cinder Volume Drivers Must Have A Third Party CI by March 19, 2014

On Wed, Mar 18, 2015 at 11:38 PM, Bharat Kumar wrote: > Regarding the GlusterFS CI: > > As I am dealing with end to end CI process of GlusterFS, please modify the > contact person to "[email protected]". > > Because of this I may miss important announcements from you regarding the > CI.

[openstack-dev] [Ironic][FFE] secure boot support in iLO drivers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, This feature [0] enables secure boot mode for hardware which supports UEFI. Ironic added support for UEFI in Juno. This is an incremental improvement, allowing those users to benefit more from their hardware's security features. After this morni

Re: [openstack-dev] [Ironic][FFE] secure boot support in iLO drivers

Corrected [1] is below (link for pxe_ilo patch review): [1] https://review.openstack.org/#/c/154808/ On Thu, Mar 19, 2015 at 10:24 PM, Devananda van der Veen < [email protected]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > All, > > This feature [0] enables secure boot mod

Re: [openstack-dev] [Neutron] Neutron extenstions

Hi, Until now all changes to the API’s have been made in separate extensions and not in the base. These should actually be on the provider networks extension. First this code is not supported by any of the plugins other than the ML2 (I am not sure if this break things – it certain broke the unit

Re: [openstack-dev] Stable/icehouse: oslo.messaging RPCClient segmentation fault core dumped

Hello everyone, I have dug into this problem and I realized that this piece of code is working on a CentOS 6.6 running Openstack stable icehouse installed with RDO. My guess is that there may be an issue either with the operating system or with the devstack installation. If you have any clue, p

Re: [openstack-dev] [Ironic][FFE] secure boot support in iLO drivers

woops! thanks... -Devananda On Thu, Mar 19, 2015 at 10:04 AM, Ramakrishnan G wrote: > > Corrected [1] is below (link for pxe_ilo patch review): > > [1] https://review.openstack.org/#/c/154808/ > > On Thu, Mar 19, 2015 at 10:24 PM, Devananda van der Veen > wrote: >> >> -BEGIN PGP SIGNED MES

Re: [openstack-dev] [Fuel] Let's stick to OpenStack global requirements

On Thu, Mar 19, 2015 at 3:16 AM, Roman Prykhodchenko wrote: >> I'm not sure it's good idea. >> We should stay so close to upstream distro as we can. It should be >> very important reason to update package against it's upstream distro > The issue is the following: OpenStack’s components are tested

Re: [openstack-dev] [Fuel] Let's stick to OpenStack global requirements

Maciej, Maintaining multiple versions of the same package concurrently and tracking their compatibility with the many different components of OpenStack and Fuel creates additional work on many different levels, from spec branch management to repo management to validation to container building and

Re: [openstack-dev] [Keystone][FFE] - Reseller Implementation

In addition, In the last keystone meeting in March 17 in the IRC channel we decided that Henry Nash (keystone core) will sponsor this feature as a FFE. Cheers, Raildo On Tue, Mar 17, 2015 at 5:36

Re: [openstack-dev] [Neutron] Neutron extenstions

There are precedents for this. For example, the attributes that currently exist for IPv6 advertisement are very similar: - added during the run of a stable Neutron API - properties added on a Neutron object (MTU and VLAN affect network, but IPv6 affects subnet - same principle though) - settable,

Re: [openstack-dev] [Neutron] Neutron extenstions

On Thu, Mar 19, 2015 at 11:24:16AM PDT, Ian Wells wrote: > There are precedents for this. For example, the attributes that currently > exist for IPv6 advertisement are very similar: I'll also note that the API changes landed in Icehouse, but the implementation missed the Icehouse deadline and wa

Re: [openstack-dev] [Neutron] Neutron extenstions

Hi, Just the fact that we did this does not make it right. But I guess that we are starting to bend the rules. I think that we really need to be far more diligent about this kind of stuff. Having said that we decided the following on IRC: 1. Mtu will be left in the core (all plugins should be aware

Re: [openstack-dev] [Neutron] VLAN transparency support

Per the other discussion on attributes, I believe the change walks in historical footsteps and it's a matter of project policy choice. That aside, you raised a couple of other issues on IRC: - backward compatibility with plugins that haven't adapted their API - this is addressed in the spec, whic

Re: [openstack-dev] [TripleO] QuintupleO Overview

On 03/17/2015 01:59 AM, Smigiel, Dariusz wrote: >> On 17 March 2015 at 09:30, Ben Nemec >> wrote: >>> So I've successfully done a deployment to a QuintupleO environment. \o/ >> >> \o/ >> > > Great news! Congrats! > > @Ben, are you planning to keep it up-to-date or create repo with README? > I wo

Re: [openstack-dev] [Neutron] VLAN transparency support

With regards to the MTU can you please point me to where we validate that the MTU defined by the tenant is actually <= the supported MTU on the network. I did not see this in the code (maybe I missed something). From: Ian Wells mailto:[email protected]>> Reply-To: OpenStack List mailto:op

Re: [openstack-dev] [oslo.config][kolla] modular backends for oslo.cfg

And don't forget about: https://review.openstack.org/#/c/130047/ Sounds pretty similar (the proxy could proxy to anything, etc.d, zookeeper, a email system, a snail, a web-service, whatever...). -Josh Davanum Srinivas wrote: Chmouel, Nice! Ben added a topic "Alternative file formats for o

Re: [openstack-dev] [Fuel] development tools

we already have a package with the name fuel-utils please see [1]. I -1'd the CR over it. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-March/059206.html On Thu, Mar 19, 2015 at 7:11 AM, Alexander Kislitsky wrote: > +1 for moving fuel_development into separate repo. > > On Thu, Mar

Re: [openstack-dev] [TripleO] QuintupleO Overview

As promised, the demo video: https://www.youtube.com/watch?v=XvCEBWin7eE -Ben On 03/19/2015 02:01 PM, Ben Nemec wrote: > On 03/17/2015 01:59 AM, Smigiel, Dariusz wrote: >>> On 17 March 2015 at 09:30, Ben Nemec >>> wrote: So I've successfully done a deployment to a QuintupleO environment. \o

[openstack-dev] [Glance] [all] glance_store release 0.4.0

The glance_store release management team is pleased to announce: Release of glance_store version 0.4.0 Please find the details related to the release at: https://launchpad.net/glance-store/+milestone/v0.4.0 Please report the issues through launchpad: https://bugs.launchpad.net/gla

[openstack-dev] [Glance] [all] python-glanceclient release 0.17.0

The python-glanceclient release management team is pleased to announce: Release of python-glanceclient version 0.17.0 Please find the details related to the release at: https://launchpad.net/python-glanceclient/+milestone/v0.17.0 Please report the issues through launchpad: https:/

[openstack-dev] [nova] Whether microversion implementation only need to be applied to first layer API?

During http://lists.openstack.org/pipermail/openstack-dev/2015-March/059000.html, we had some discussions on whether we need version specific code remaining even we suggest user can use API version directly in API, [1][2] aiming to remove that And if we should keep following stuff , then [3][4]

[openstack-dev] [neutron][lbaas] canceling meeting

Hi lbaas'ers, Now that lbaasv2 has "shipped", the need for a regular weekly meeting is greatly reduced. I propose that we cancel the regular meeting, and discuss neutron-y things during the neutron on-demand agenda, and octavia things in the already existing octavia meetings. Any objections/al

Re: [openstack-dev] [Openstack-operators] [all][qa][gabbi][rally][tempest] Extend "rally verfiy" to unify work with Gabbi, Tempest and all in-tree functional tests

I have an alternative solution for `rally verify start` command. What do you think about similar management stuff for verifiers as we have for deployments? It requires several changes: - `rally verifiers` command: Implementation of new command, which will manage(install, reinstall, remove, confi

Re: [openstack-dev] [Neutron] Neutron extenstions

On 19 March 2015 at 11:44, Gary Kotton wrote: > Hi, > Just the fact that we did this does not make it right. But I guess that we > are starting to bend the rules. I think that we really need to be far more > diligent about this kind of stuff. Having said that we decided the > following on IRC: >

[openstack-dev] [Group-Based-Policy] Service Chain Instance ownership

Hello Folks, [tl;dr] On implicit chains, the Service Chain Instance ownership in GBP is inconsistent, depending on the actor triggering the chain. Possible solution is to have all the implicit SCI owned by an admin, or by the provider of the chain. Any suggestion is welcome. [boringpostwithexamp

[openstack-dev] [Group-Based-Policy] Use cases for External Policy chains

Hello, As a follow up on [0] I have a question for the community. There are multiple use cases for a PTG *providing* a ServiceChain which is *consumed* by an External Policy (think about LB/FW/IDS and so forth). However, given the current set of services we support, I don't see any use case for ha

Re: [openstack-dev] [Neutron] VLAN transparency support

If my memory does not fail me, changes to the API (new resources, new resource attributes or new operations allowed to resources) have always been done according to these criteria: - an opt-in approach: this means we know the expected behavior of the plugin as someone has coded the plugin in

[openstack-dev] Refrain Refrain

I OK kook i rigor w assessment of ofiii __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listi

Re: [openstack-dev] [Neutron] Neutron extenstions

Forwarding my reply to the other thread here: If my memory does not fail me, changes to the API (new resources, new resource attributes or new operations allowed to resources) have always been done according to these criteria: - an opt-in approach: this means we know the expected behavio

[openstack-dev] [cinder] Status of Huawei Volume CI

Hi Mike, Regarding the Huawei Volume CI: As I am dealing with the CI process of Huawei, please modify the contact person to "[email protected]", so I won't miss important announcements from you regarding the CI.‍ The CI of huawei 18000 ISCSI and huawei 18000 FC

[openstack-dev] [Fuel} Separating Ceph pools depending on storage type

Hello, I want to initiate a discussion about different backend storage types for Ceph. Now all types of drives (HDD, SAS, SSD) are treated the same way, so the performance can vary widely. It would be good to detect SSD drives and create separate Ceph pool for them. From the user perspective, it

[openstack-dev] [cinder] May you reconsider about huawei driver?

Hi Mike, I have seen the patch at https://review.openstack.org/#/c/165990/ saying that huawei driver will be removed because “the maintainer does not have a CI reporting to ensure their driver integration is successful”. But in fact we really have a CI months ago and it is really reporting to

[openstack-dev] [magnum] Memory recommendation for running magnum with devstack

Team, Do we have a ballpark amount for the memory of the devstack machine to run magnum? I am running devstack as a VM with (4 VCPU/50G-Disk/8G-Mem) and running magnum on it as per[1]. I am observing the kube-Nodes goes often in "SHUTOFF" state. If I do 'nova reset-state', the instance goes

Re: [openstack-dev] [magnum] Memory recommendation for running magnum with devstack

Hi Surojit, I think 8G of RAM and 80G of disk should be considered the minimum. The guide will create 3 m1.small VMs (each with 2G of RAM and 20G of disk), and 2 volumes (5G each). In your case, I am not sure why you get the memory error. Probably, you could walk-around it by creating a flavor wi

[openstack-dev] [cinder] I will add Dorado and T CI within one week if I can't revome Dorado and T driver

Hi Mike, * Maybe I have a misunderstand of the warning you said that all drivers must have a CI. I have taken that as if the Dorado and T driver did not have a CI then the Dorado and T driver will be removed from the community individually. If I can't remove Dorado and T driver individ

Re: [openstack-dev] [murano] PTL elections

On Wed, Mar 18, 2015 at 6:59 AM, Serg Melikyan wrote: > Thank you! > > On Wed, Mar 18, 2015 at 8:28 AM, Sergey Lukjanov > wrote: > >> The PTL candidacy proposal time frame ended and we have only one >> candidate. >> >> So, Serg Melikyan, my congratulations! >> >> Results documented in >> https:/

Re: [openstack-dev] [Fuel} Separating Ceph pools depending on storage type

hi, generally speaking it would be nice to have the possibility to define availability zones. and this could be used as well to group, not only computing resources, but also storage ones. for this if i am not wrong there is already a discussion or blueprint on this from mirantis folks. then i am no

Re: [openstack-dev] [Neutron] VLAN transparency support

API extension is the only way that users know which features are available unitl we support API microversioning (v2.1 or something). I believe VLAN transparency support should be implemented as an extension, not by changing the core resources attribute directly. Otherwise users (including Horizon)

Re: [openstack-dev] [Fuel} Separating Ceph pools depending on storage type

Right now, we create pools for images, compute, volumes, and radosgw creates a bunch, all are assigned to the default crush map. from the Ceph side, In order to create a pool where we could separate it from another pool is to create a ruleset in the cursh map to isolate the devices, then the pools

Re: [openstack-dev] [Neutron] VLAN transparency support

Hi, So at the moment we have something that is half baked. Say we take the MTU support as an example: There is a configuration flag ‘advertise_mtu’ (the default value is False) – this is set by an admin, but a tenant can define the mtu setting when creating a network. So by default the tenant se