Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

After more thinking, I agree with Hongbin that instance_type might make customer confused with flavor, what about using server_type? Actually, nova has concept of server group, the "servers" in this group can be vm. pm or container. Thanks! 2015-07-16 11:58 GMT+08:00 Kai Qiang Wu : > Hi Hong Bi

Re: [openstack-dev] OpenStack Mitaka (三鷹) - Our next release name has been selected

A little off-topic, so please forgive me. :) If you go to the Ghibli Museum (and yes, it IS a great experience), be sure to get tickets in advance. You have to buy them at Lawson store before the actual ticket date (no same-day sales). Just a heads up for anyone planning to go. ;) As I sai

[openstack-dev] [Neutron]Request for help to review a patch

Hi, I know that request review is not good in mail list, but the review process of this patch seems freeze except gained two +1 :-) The review url is: https://review.openstack.org/#/c/172875/ Thanks a lot, Wei wang __ OpenS

Re: [openstack-dev] [all][ptl][release] New library release request process

Doug, I'm missing openstackdocstheme and openstack-doc-tools in your import. How do you want to handle these? Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Di

Re: [openstack-dev] [nova] schedule instance based on CPU frequency ?

On 07/15/2015 04:57 PM, Dugger, Donald D wrote: In re: Static CPU frequency. For modern Intel CPUs this really isn't true. Turbo Boost is a feature that allows certain CPUs in certain conditions to actually run at a higher clock rate that what is advertised at power on (the havoc this causes cod

Re: [openstack-dev] [neutron] Should we document the using of "device:owner" of the PORT ?

I'm guessing Salvatore might just be suggesting that we restrict users from populating values that have special meaning (e.g. l3 agent router interface ports). I don't think at this point we could constrain the owner field to essentially an enum at this point. On Wed, Jul 15, 2015 at 10:22 PM, Mik

Re: [openstack-dev] [neutron][security-group] rules for filter mac-addresses

Thanks, but we don't use the blueprint process for feature requests in Neutron. Just file a bug in launchpad and give in an 'rfe' tag, which stands for "request for enhancement". On Tue, Jul 14, 2015 at 5:29 AM, yan_xing...@163.com wrote: > Thank you, Kevin. > I search the blueprint about this p

Re: [openstack-dev] [neutron] questions on neutron-db-migrations

Thanks Ihar. Went through your email and updated HEADS to resolve merging conflicts for my patch. On Wed, Jul 15, 2015 at 1:03 PM, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 07/15/2015 07:17 PM, Madhusudhan Kandadai wrote: > > Hello, > > > > I have notice

Re: [openstack-dev] [tc][all] Tags, explain like I am five?

Thanks that helps! (and I hope it helps others to), A few questions inline... Stefano Maffulli wrote: On 07/15/2015 11:25 AM, Joshua Harlow wrote: So I've been following the TC work on tags, and have been slightly confused by the whole work, so I am wondering if I can get a 'explainlikeimfive'

Re: [openstack-dev] [nova] Proposal for an Experiment

Chris Friesen wrote: On 07/15/2015 09:31 AM, Joshua Harlow wrote: I do like experiments! What about going even farther and trying to integrate somehow into mesos? https://mesos.apache.org/documentation/latest/mesos-architecture/ Replace the hadooop executor, MPI executor with a 'VM executor'

Re: [openstack-dev] [neutron] Should we document the using of "device:owner" of the PORT ?

- Original Message - > Yes please. > This would be a good starting point. > I also think that the ability of editing it, as well as the value it could be > set to, should be constrained. FYI the oVirt project uses this field to identify ports it creates and manages. So if you're going t

Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps

I'd agree with Angus. 在 2015-07-16 12:05:25，"Angus Salkeld" 写道： On Tue, Jun 30, 2015 at 6:09 PM, Julien Danjou wrote: On Mon, Jun 29 2015, Ildikó Váncsa wrote: > I think removing options from the API requires version bump. So if we plan to > do this, that should be introduced in v3 as opposed

Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps

On Tue, Jun 30, 2015 at 6:09 PM, Julien Danjou wrote: > On Mon, Jun 29 2015, Ildikó Váncsa wrote: > > > I think removing options from the API requires version bump. So if we > plan to > > do this, that should be introduced in v3 as opposed to v2, which should > remain > > the same and maintained

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

Hi Hong Bin, Thanks for your reply. I think it is better to discuss the 'platform' Vs instance_type Vs others case first. Attach: initial patch (about the discussion): https://review.openstack.org/#/c/200401/ My other patches all depend on above patch, if above patch can not reach a meaningful

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

Kai, Sorry for the confusion. To clarify, I was thinking how to name the field you proposed in baymodel [1]. I prefer to drop it and use the existing field ‘flavor’ to map the Heat template. [1] https://review.openstack.org/#/c/198984/6 From: Kai Qiang Wu [mailto:wk...@cn.ibm.com] Sent: July-1

Re: [openstack-dev] [magnum] Tom Cammann for core

Welcome Tom! 2015-07-15 6:53 GMT+08:00 Tom Cammann : > Thanks team, happy to be here :) > > Tom > > On 14 Jul 2015, at 23:02, Adrian Otto wrote: > > > > Tom, > > > > It is my pleasure to welcome you to the magnum-core group. We are happy > to have you on the team. > > > > Regards, > > > > Adrian

Re: [openstack-dev] [tc][all] Tags, explain like I am five?

On 07/15/2015 11:25 AM, Joshua Harlow wrote: > So I've been following the TC work on tags, and have been slightly > confused by the whole work, so I am wondering if I can get a > 'explainlikeimfive' (borrowing from reddit terminology) edition of it. I'll try :) You need to think of "tags" as the

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

Hi HongBin, I think flavors introduces more confusion than nova_instance_type or instance_type. As flavors not have binding with 'vm' or 'baremetal', Let me summary the initial question: We have two kinds of templates for kubernetes now, (as templates in heat not flexible like programming lan

[openstack-dev] Please add add 'Fuel' to list topic categories

Hi, I believe we are all receiving a large number of Fuel related messages everyday, but not all of us have the abundant bandwidth to read them. Maybe we can consider adding 'Fuel' to the topic categories we can check on/off when customising the subscription. Currently, the option is to filter ou

Re: [openstack-dev] [Nova][infra][third-party] Intel actively seeking solution to CI issue and getting close to a solution

On 07/15/2015 10:19 PM, yongli he wrote: > Hello OpenStackers! > > The Intel PCI/SRIOV/NGFW/PTAS CI located in China, due to reasons beyond > our control, lost connectivity to the Jenkins servers. The great firewall of China is making quite a few folks unhappy. > Although the CI > system is wor

Re: [openstack-dev] July 15th meeting cancelled

- Original Message - > From: "Calum Loudon" > To: "OpenStack Development Mailing List (not for usage questions)" > > > Hi Steve > > I missed the linked mail as it was sent to the openstack-operators list, not > openstack-dev - was that intentional? Sort of, in that the use case defini

[openstack-dev] [Nova][infra][third-party] Intel actively seeking solution to CI issue and getting close to a solution

Hello OpenStackers! The Intel PCI/SRIOV/NGFW/PTAS CI located in China, due to reasons beyond our control, lost connectivity to the Jenkins servers. Although the CI system is working fine we haven’t been able to report results back for about a month now. We are actively looking for a solution

[openstack-dev] [Tricircle]Team Weekly Meeting 2015.07.15 Roundup

uawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipe...@uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado Tricircle IRC Meeti

Re: [openstack-dev] [magnum][bp] Power Magnum to run on metalwith Hyper

-- Original -- From: “Adrian Otto”; Date: Wed, Jul 15, 2015 02:31 AM To: “OpenStack Development Mailing List (not for usage questions)“; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper Peng, On Jul 13, 2015, at 8:37

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

On Jul 15, 2015, at 1:39 PM, hongbin...@huawei.com wrote: +1 for the idea of using Nova flavor directly. Our initial resistance to using flavor is that you may want the same bay to have a combination of different flavors in it. I suppose this might still be possi

Re: [openstack-dev] [nova] Why is osapi_v3.enabled = False by default?

On Thu, Jul 16, 2015 at 3:03 AM, Sean Dague wrote: > On 07/15/2015 01:44 PM, Matt Riedemann wrote: >> The osapi_v3.enabled option is False by default [1] even though it's >> marked as the CURRENT API and the v2 API is marked as SUPPORTED (and >> we've frozen it for new feature development). >> >>

Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates

Folks, let's execute here. Numbers are still large. Did we have a chance to look over the whole queue? Can we go ahead and abandon changes having -1 or -2 from reviewers for over than a months or so? I'm all for just following standard OpenStack process [1], and then change it only if there is goo

Re: [openstack-dev] [nova] Why is osapi_v3.enabled = False by default?

2015-07-16 3:03 GMT+09:00 Sean Dague : > On 07/15/2015 01:44 PM, Matt Riedemann wrote: >> The osapi_v3.enabled option is False by default [1] even though it's >> marked as the CURRENT API and the v2 API is marked as SUPPORTED (and >> we've frozen it for new feature development). >> >> I got looking

Re: [openstack-dev] [fuel] Deprecation and backwards compaibility Policy

Using lazy census here, I will update the wiki with this process. On Mon, Jun 29, 2015 at 4:22 PM Andrew Woodward wrote: > Some recent specs have proposed changing some of the API's by either > removing parts, or changing them in non-backwards way. Additionally there > are some proposals that ar

Re: [openstack-dev] [Neutron] Proposing Cedric Brandily to Neutron Core Reviewer Team

+1 On 07/15/2015 02:47 PM, Carl Baldwin wrote: As the Neutron L3 Lieutenant along with Kevin Benton for control plane, and Assaf Muller for testing, I would like to propose Cedric Brandily as a member of the Neutron core reviewer team under these areas of focus. Cedric has been a long time cont

Re: [openstack-dev] [nova] schedule instance based on CPU frequency ?

In re: Static CPU frequency. For modern Intel CPUs this really isn't true. Turbo Boost is a feature that allows certain CPUs in certain conditions to actually run at a higher clock rate that what is advertised at power on (the havoc this causes code that depends upon timing based upon CPU spin

Re: [openstack-dev] [Neutron] Proposing Cedric Brandily to Neutron Core Reviewer Team

+1! On Wed, Jul 15, 2015, Carl Baldwin wrote: > As the Neutron L3 Lieutenant along with Kevin Benton for control > plane, and Assaf Muller for testing, I would like to propose Cedric > Brandily as a member of the Neutron core reviewer team under these > areas of focus. > > Cedric has been a long

[openstack-dev] [all] requirements and tox.ini

One thing I've noticed over the last month or so looking at many projects requirements handling is that many projects have deps statements in tox.ini. There are a couple of nuances here I want to call out - and I want advice on where to document for people to find this. Firstly, this: deps = -r{

[openstack-dev] [fuel] Meeting July 16

Please note the IRC meeting is scheduled for 16:00 UTC in #openstack-meeting-alt Please review meeting agenda and update if there is something you wish to discuss. https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Commu

[openstack-dev] [nova] Status of identity v3 support

Hi Everyone, Recently I have started reviewing the patch series about nested quotas in nova [1] and I'm having trouble understanding where we currently are with identity v3 support in nova. From what I read in a semi recent proposal [2] I think things mostly "just work" if you configure to run

Re: [openstack-dev] [puppet] puppet-designate POC implementation of virtualenv and docker support.

I have been meaning to ask you about this, so thanks for posting. I like the approach. Definitely a lot cleaner than the somewhat hardcoded dependencies and subscriptions that are in the modules now. Do you envision that long term the docker/venv/whatever else implementation (like you have in

Re: [openstack-dev] [murano] [congress] murano congress integration test - trusts

Hi folks! I’ve tried to debug this problem and found strange behavior of auth in [1]. So, at least, if in murano.conf we have parameter use_trusts=True, keystone_client.tenant_name returns None [2]. I’ve tried to use v3 auth instead of v2 and, accordingly, replaced tenant_name for auth by trust_id

Re: [openstack-dev] [keystone] token revocation woes

On Wed, Jul 15, 2015 at 4:51 PM, Matt Fischer wrote: > I'm having some issues with keystone revocation events. The bottom line is > that due to the way keystone handles the clean-up of these events[1], > having more than a few leads to: > > - bad performance, up to 2x slower token validation wit

Re: [openstack-dev] [Fuel] Separate repo for Fuel Agent

+1, great to see it is being pushed through. This is not always pleasant work, but it certainly makes our life easier. > 130 vs 7275 in fuel-web (fuel-agent-7.0.0-1.mos7275.noarch.rpm) Two questions: a) how our patching suppose to work if we have lower version now? b) why there is "mos" code name

[openstack-dev] [keystone] token revocation woes

I'm having some issues with keystone revocation events. The bottom line is that due to the way keystone handles the clean-up of these events[1], having more than a few leads to: - bad performance, up to 2x slower token validation with about 600 events based on my perf measurements. - database de

Re: [openstack-dev] [murano] [congress] murano congress integration test - trusts

Just to keep track, Victor started a bug on that:  https://bugs.launchpad.net/murano/+bug/1474938/ Haven’t looked close into the problem, yet, though. Will try to do so some time soon. --  Kirill Zaitsev Murano team Software Engineer Mirantis, Inc On 15 Jul 2015 at 16:44:24, Filip Blaha (filip.b

Re: [openstack-dev] [murano] [congress] murano congress integration test - trusts

Hi Filip, Did you get this resolved? If not, could you point me to the gate failure? I'm on #congress for higher-bandwidth communication. Tim On Wed, Jul 15, 2015 at 6:39 AM Filip Blaha wrote: > Hi all > > our congress integration tests were broken by the change [1] (trusts > enabled by d

Re: [openstack-dev] [puppet] First Sprint proposal

On 2015-07-15 14:04:47 -0700 (-0700), Spencer Krum wrote: > It is also possible to use the openstack-infra asterisk server for voice > chat. Historically this service has out-performed google hangout and > bluejeans. It doesn't use video though. For those who don't have the URL memorized: htt

Re: [openstack-dev] [puppet] First Sprint proposal

It is also possible to use the openstack-infra asterisk server for voice chat. Historically this service has out-performed google hangout and bluejeans. It doesn't use video though. -- Spencer Krum n...@spencerkrum.com On Tue, Jul 14, 2015, at 09:09 AM, Emilien Macchi wrote: > We decided dur

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

+1 for the idea of using Nova flavor directly. Why we introduced the “platform” field to indicate “vm” or “baremetel” is that magnum need to map a bay to a Heat template (which will be used to provision the bay). Currently, Magnum has three layers of mapping: ・ platform: vm or baremetal

Re: [openstack-dev] [nova] Proposal for an Experiment

Chris Friesen wrote: On 07/15/2015 09:31 AM, Joshua Harlow wrote: I do like experiments! What about going even farther and trying to integrate somehow into mesos? https://mesos.apache.org/documentation/latest/mesos-architecture/ Replace the hadooop executor, MPI executor with a 'VM executor'

Re: [openstack-dev] [nova] Proposal for an Experiment

On 07/15/2015 08:18 AM, Ed Leafe wrote: What I'd like to investigate is replacing the current design of having the compute nodes communicating with the scheduler via message queues. This design is overly complex and has several known scalability issues. My thought is to replace this with a Cassa

Re: [openstack-dev] [nova] Proposal for an Experiment

On 07/15/2015 09:31 AM, Joshua Harlow wrote: I do like experiments! What about going even farther and trying to integrate somehow into mesos? https://mesos.apache.org/documentation/latest/mesos-architecture/ Replace the hadooop executor, MPI executor with a 'VM executor' and perhaps we could e

Re: [openstack-dev] [Cinder] Implementation of ABC MetaClasses

On Wed, Jul 8, 2015 at 12:48 AM, Marc Koderer wrote: > > Am 08.07.2015 um 01:37 schrieb Mike Perez : > > > On 18:38 Jun 22, Marc Koderer wrote: > >> > >> Am 20.06.2015 um 01:59 schrieb John Griffith >: > >>> * The BaseVD represents the functionality we require from all drivers. > >>> ​Yep > >>>

Re: [openstack-dev] [Neutron] Proposing Cedric Brandily to Neutron Core Reviewer Team

+1 Excellent addition to the team. Edgar On 7/15/15, 11:47 AM, "Carl Baldwin" wrote: >As the Neutron L3 Lieutenant along with Kevin Benton for control >plane, and Assaf Muller for testing, I would like to propose Cedric >Brandily as a member of the Neutron core reviewer team under these >are

Re: [openstack-dev] [Neutron] Proposing Cedric Brandily to Neutron Core Reviewer Team

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 While I'm an obsolete™ core reviewer and not an official member of any of those subteams, I will nevertheless say that Cedric will be a very valuable addition to the team. His reviews are usually insightful and touch the root of the problem, not mere

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

From what I’m hearing, Akihiro is recommending that we put it somewhere where it’s easy to add horizon cores to the repo, which seems like it’d be very useful. I think we can roll a parallel repo under the neutron tent pretty easily. For the sake of getting collaboration moving, I’d suggest: 1.

Re: [openstack-dev] [Fuel] New Criteria for UX bugs

I've updated the documentation on the wiki with this criteria https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Confirm_and_triage_bugs On Tue, Jul 14, 2015 at 4:22 PM Mike Scherbakov wrote: > Sounds good to start, we can always adjust later if needed. I actually > changed one doc bug prio

Re: [openstack-dev] [neutron] questions on neutron-db-migrations

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/15/2015 07:17 PM, Madhusudhan Kandadai wrote: > Hello, > > I have noticed that neutron project got rid of > neutron/db/migration/alembic_migrations/versions/HEAD file and > renamed it to > neutron/db/migration/alembic_migrations/versions/HEAD

Re: [openstack-dev] [neutron] What does flavor mean for a network?

That begins to looks like nova’s metadata tags and scheduler, which is a valid use case. The underpinnings of flavors could do this, but it’s not in the initial implementation. doug > On Jul 15, 2015, at 12:38 PM, Kevin Benton wrote: > > Wouldn't it be valid to assign flavors to groups of pro

Re: [openstack-dev] [nova] Proposal for an Experiment

On 16 July 2015 at 07:27, Ed Leafe wrote: > On Jul 15, 2015, at 1:08 PM, Maish Saidel-Keesing wrote: > >>> * Consider the cost of introducing a brand new technology into the >>> deployer space. If there _is_ a way to get the desired improvement with, >>> say, just MySQL and some clever sharding,

Re: [openstack-dev] [Neutron] Proposing Cedric Brandily to Neutron Core Reviewer Team

+1 > On Jul 15, 2015, at 1:07 PM, Kyle Mestery wrote: > > +1, Cedric has been a great contributor for a while now! > > On Wed, Jul 15, 2015 at 1:47 PM, Carl Baldwin > wrote: > As the Neutron L3 Lieutenant along with Kevin Benton for control > plane, and Assaf Muller

[openstack-dev] [Tacker][NFV] Devstack plugin support is now available

Heads up. Tacker project now supports installation using a devstack plugin. The latest Tacker installation instruction is available in this wiki [1] Note, the team continues to meet weekly in IRC [2]. Feel free to join if you are interested in an ETSI MANO complaint NFV Orchestrator / VNF Manager.

Re: [openstack-dev] [tc][all] Tags, explain like I am five?

On Wed, Jul 15, 2015 at 12:44 PM, Joshua Harlow wrote: > John Griffith wrote: > >> >> >> On Wed, Jul 15, 2015 at 12:25 PM, Joshua Harlow > > wrote: >> >> So I've been following the TC work on tags, and have been slightly >> confused by the whole work, so I am

Re: [openstack-dev] [nova] Proposal for an Experiment

On Jul 15, 2015, at 1:08 PM, Maish Saidel-Keesing wrote: >> * Consider the cost of introducing a brand new technology into the >> deployer space. If there _is_ a way to get the desired improvement with, >> say, just MySQL and some clever sharding, then that might be a smaller >> pill to swallow f

Re: [openstack-dev] [Neutron] Proposing Cedric Brandily to Neutron Core Reviewer Team

+1, Cedric has been a great contributor for a while now! On Wed, Jul 15, 2015 at 1:47 PM, Carl Baldwin wrote: > As the Neutron L3 Lieutenant along with Kevin Benton for control > plane, and Assaf Muller for testing, I would like to propose Cedric > Brandily as a member of the Neutron core review

Re: [openstack-dev] [oslo] Need new release of stable oslotest with capped mock

Excerpts from Yuriy Taraday's message of 2015-07-15 13:14:13 +: > Hello, oslo team. > > With recent mock nightmare we should not release a new stable version of > oslotest so that projects that depend on oslotest but don't directly depend > on mock will be unblocked in gate. > > I found out a

[openstack-dev] [Neutron] Proposing Cedric Brandily to Neutron Core Reviewer Team

As the Neutron L3 Lieutenant along with Kevin Benton for control plane, and Assaf Muller for testing, I would like to propose Cedric Brandily as a member of the Neutron core reviewer team under these areas of focus. Cedric has been a long time contributor to Neutron showing expertise particularly

Re: [openstack-dev] [tc][all] Tags, explain like I am five?

John Griffith wrote: On Wed, Jul 15, 2015 at 12:25 PM, Joshua Harlow mailto:harlo...@outlook.com>> wrote: So I've been following the TC work on tags, and have been slightly confused by the whole work, so I am wondering if I can get a 'explainlikeimfive' (borrowing from reddit termi

Re: [openstack-dev] [neutron] What does flavor mean for a network?

Wouldn't it be valid to assign flavors to groups of provider networks? e.g. a tenant wants to attach to a network that is wired up to a 40g router so he/she chooses a network of the "fat pipe" flavor. On Wed, Jul 15, 2015 at 10:40 AM, Madhusudhan Kandadai < madhusudhan.openst...@gmail.com> wrote:

Re: [openstack-dev] [tc][all] Tags, explain like I am five?

On Wed, Jul 15, 2015 at 12:25 PM, Joshua Harlow wrote: > So I've been following the TC work on tags, and have been slightly > confused by the whole work, so I am wondering if I can get a > 'explainlikeimfive' (borrowing from reddit terminology) edition of it. > > I always thought tags were going

Re: [openstack-dev] [grenade] future direction on partial upgrade support

Sean, OK, moving thread to openstack-dev. We'd like to help with this work if there is more to do. What are the next steps and what areas need help? Thanks, Will > -Original Message- > From: Sean Dague [mailto:s...@dague.net] > Sent: Wednesday, July 15, 2015 3:10 AM > To: Du, Dolpher

Re: [openstack-dev] [nova] Proposal for an Experiment

On 16 July 2015 at 02:18, Ed Leafe wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 ... > What I'd like to investigate is replacing the current design of having > the compute nodes communicating with the scheduler via message queues. > This design is overly complex and has several known

[openstack-dev] [tc][all] Tags, explain like I am five?

So I've been following the TC work on tags, and have been slightly confused by the whole work, so I am wondering if I can get a 'explainlikeimfive' (borrowing from reddit terminology) edition of it. I always thought tags were going to be something like: http://i.imgur.com/rcAnMkX.png (I'm not

[openstack-dev] [swift] Swift container sync process is consuming 100% CPU

In our production swift cluster, we have container sync middleware enabled in the pipeline. But swift container sync is not configured. We noticed 100% CPU utilization and a lot of read/write i/os from the swift-container-sync process on our meta data nodes recently after we have seen increasin

Re: [openstack-dev] [nova] Proposal for an Experiment

On 07/15/15 20:40, Clint Byrum wrote: What you describe is a spike. It's a grand plan, and you don't need anyone's permission, so huzzah for the spike! As far as what should be improved, I hear a lot that having multiple schedulers does not scale well, so I'd suggest that as a primary target (ma

Re: [openstack-dev] [nova] Why is osapi_v3.enabled = False by default?

On 07/15/2015 01:44 PM, Matt Riedemann wrote: > The osapi_v3.enabled option is False by default [1] even though it's > marked as the CURRENT API and the v2 API is marked as SUPPORTED (and > we've frozen it for new feature development). > > I got looking at this because osapi_v3.enabled is True in

[openstack-dev] [nova] Why is osapi_v3.enabled = False by default?

The osapi_v3.enabled option is False by default [1] even though it's marked as the CURRENT API and the v2 API is marked as SUPPORTED (and we've frozen it for new feature development). I got looking at this because osapi_v3.enabled is True in nova.conf in both the check-tempest-dsvm-nova-v21-fu

Re: [openstack-dev] [Nova] Device names supplied to the boot request

On 07/15/15 at 12:19pm, Matt Riedemann wrote: On 7/15/2015 11:23 AM, Nikola Đipanov wrote: I'll keep this email brief since this has been a well known issue for some time now. Problem: Libvirt can't honour device names specified at boot for any volumes requested as part of block_device_mappin

Re: [openstack-dev] [nova] Proposal for an Experiment

What you describe is a spike. It's a grand plan, and you don't need anyone's permission, so huzzah for the spike! As far as what should be improved, I hear a lot that having multiple schedulers does not scale well, so I'd suggest that as a primary target (maybe measure the _current_ problem, and t

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

I agree with German. Let’s keep things together for now. Susanne From: Eichberger, German Sent: Wednesday, July 15, 2015 1:31 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Balle, Susanne; Tonse, Milan Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutr

[openstack-dev] [lbaas] [octavia] No meeting today 7/15

All, This week is the L4-L7 mid cycle so we will skip today¹s meeting ‹ German __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http:

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

Hi, Let’s move it into the LBaaS repo that seems like the right place for me — Thanks, German From: "Jain, Vivek" mailto:vivekj...@ebay.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, July 14, 2015 at 10:22

Re: [openstack-dev] [Cinder] FFE Request: Re-add Quobyte Cinder Driver

Hello Mike! Thanks for looking into this. Yes, the fails are caused by the two open bugs i mentioned [1,2]. We will continue to see into those. Regards Silvan [1] https://bugs.launchpad.net/nova/+bug/1465416 [2] https://bugs.launchpad.net/cinder/+bug/1473116 2015-07-15 0:07 GMT+02:00 Mike Perez

Re: [openstack-dev] [Nova] Device names supplied to the boot request

On 7/15/2015 11:23 AM, Nikola Đipanov wrote: I'll keep this email brief since this has been a well known issue for some time now. Problem: Libvirt can't honour device names specified at boot for any volumes requested as part of block_device_mapping. What we currently do is in case they do get

[openstack-dev] [neutron] questions on neutron-db-migrations

Hello, I have noticed that neutron project got rid of neutron/db/migration/alembic_migrations/versions/HEAD file and renamed it to neutron/db/migration/alembic_migrations/versions/HEADS May I know the reason why this happened? I may have overlooked some documentation with respect to the change. I

Re: [openstack-dev] [cinder] Need a new release of os-brick for Python 3

On 10:45 Jul 15, Victor Stinner wrote: > Hi, > > The latest release of os-brick is not compatible with Python 3. > Different patches were merged to fix Python 3 support. "tox -e py34" > now executes all tests and all tests pass on Python 3.4. > > I need a release of os-brick to port Cinder to Pyt

Re: [openstack-dev] [Nova] Device names supplied to the boot request

On 7/15/2015 11:23 AM, Nikola Đipanov wrote: I'll keep this email brief since this has been a well known issue for some time now. Problem: Libvirt can't honour device names specified at boot for any volumes requested as part of block_device_mapping. What we currently do is in case they do get

Re: [openstack-dev] [neutron] What does flavor mean for a network?

> On Jul 15, 2015, at 9:54 AM, Neil Jerram wrote: > > I've been reading available docs about the forthcoming Neutron flavors > framework, and am not yet sure I understand what it means for a network. > > Is it a way for an admin to provide a particular kind of network, and then > for a tenant

Re: [openstack-dev] [neutron] What does flavor mean for a network?

On Wed, Jul 15, 2015 at 9:25 AM, Kyle Mestery wrote: > On Wed, Jul 15, 2015 at 10:54 AM, Neil Jerram > wrote: > >> I've been reading available docs about the forthcoming Neutron flavors >> framework, and am not yet sure I understand what it means for a network. >> >> > In reality, this is envisi

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

Maybe somehow I missed the point, but why not just use raw Nova flavors? They already abstract away irconic vs kvm vs hyperv/etc. Thanks, Kevin From: Daneyon Hansen (danehans) [daneh...@cisco.com] Sent: Wednesday, July 15, 2015 9:20 AM To: OpenStack Development M

Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates

On Sun, Jul 05, 2015 at 12:00:55AM +, Steven Dake (stdake) wrote: > Lars had a repo he maintains. Magnum had a repo it maintained. We > wanted one source of truth. The deal was we would merge all the > things into heat-coe-templates, delete larsks/heat-kubernetes and > delete the magnum temp

Re: [openstack-dev] [nova][vmware] questions about some skipped tests in vmware/nsx ci

On 7/15/2015 11:17 AM, Matt Riedemann wrote: I was looking at NSX CI results on [1] which is related to volumes and noticed that tempest.api.compute.volumes.test_attach_volume.AttachVolumeTestJSON.test_attach_detach_volume is being skipped, is there a reason why? Attach and detach of volumes

Re: [openstack-dev] [neutron] What does flavor mean for a network?

On Wed, Jul 15, 2015 at 10:54 AM, Neil Jerram wrote: > I've been reading available docs about the forthcoming Neutron flavors > framework, and am not yet sure I understand what it means for a network. > > In reality, this is envisioned more for service plugins (e.g. flavors of LBaaS, VPNaaS, and

[openstack-dev] [Nova] Device names supplied to the boot request

I'll keep this email brief since this has been a well known issue for some time now. Problem: Libvirt can't honour device names specified at boot for any volumes requested as part of block_device_mapping. What we currently do is in case they do get specified, we persist them as is, so that we can

[openstack-dev] [nova][vmware] questions about some skipped tests in vmware/nsx ci

I was looking at NSX CI results on [1] which is related to volumes and noticed that tempest.api.compute.volumes.test_attach_volume.AttachVolumeTestJSON.test_attach_detach_volume is being skipped, is there a reason why? Attach and detach of volumes is a pretty basic operation for a virt driver i

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

All, IMO virt_type does not properly describe bare metal deployments. What about using the compute_driver parameter? compute_driver = None (StrOpt) Driver to use for controlling virtualization. Options include: libvirt.LibvirtDriver, xenapi.XenAPIDriver, fake.FakeDriver, baremetal.BareMetalD

Re: [openstack-dev] [Fuel] Separate repo for Fuel Agent

Nice work, Vladimir. Thank you for pushing this, it's really important step to decouple things from consolidated repository. -- Best regards, Oleg Gelbukh On Wed, Jul 15, 2015 at 6:47 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > I'm glad to announce that everything about this tas

[openstack-dev] [all][ptl][release] New library release request process

PTLs and release liaisons, We are ready to take the next step in implementing the new library release process, and start using gerrit for release request reviews. The new repository openstack/releases is set up with back-history for all of our current releases. There are full instructions in the

[openstack-dev] [neutron] What does flavor mean for a network?

I've been reading available docs about the forthcoming Neutron flavors framework, and am not yet sure I understand what it means for a network. Is it a way for an admin to provide a particular kind of network, and then for a tenant to know what they're attaching their VMs to? How does it diff

Re: [openstack-dev] [Fuel] Separate repo for Fuel Agent

I'm glad to announce that everything about this task is done. ISO build job uses this new repository [1]. BVT is green. Fuel Agent rpm spec has been moved to the new repo and perestroika has also been switched to build fuel-agent package from the new repo. The only difference that could potentially

Re: [openstack-dev] [nova] Proposal for an Experiment

I do like experiments! What about going even farther and trying to integrate somehow into mesos? https://mesos.apache.org/documentation/latest/mesos-architecture/ Replace the hadooop executor, MPI executor with a 'VM executor' and perhaps we could eliminate a large part of the scheduler code (

Re: [openstack-dev] Why do we need python-fasteners and not just oslo.concurrency?

For the same reason we don't move all of sqlalchemy into oslo.db. This is further explained @ - https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary#Choosing_a_Name - http://specs.openstack.org/openstack/oslo-specs/specs/policy/naming-libraries.html#proposed-policy Taskflow, tooz and oth

Re: [openstack-dev] [nova] Proposal for an Experiment

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/15/2015 09:49 AM, Matt Riedemann wrote: > Without reading the whole thread, couldn't you just do a feature > branch (but that would require reviews in gerrit which we don't > want), or fork the repo in github and just hack on it there without

Re: [openstack-dev] [Openstack][nova]

On 7/15/2015 5:41 AM, John Garbutt wrote: On 14 July 2015 at 21:43, Cale Rath wrote: Hi, I created a patch to fail on the proxy call to Neutron for used limits, found here: https://review.openstack.org/#/c/199604/ This patch was done because of this: http://docs.openstack.org/developer/nova

  1   2   >