Re: [openstack-dev] [Solum] Proposed changes to solum-core

Congrats new reviewers On Tuesday, January 28, 2014 8:54 AM, Noorul Islam Kamal Malmiyoda wrote: On Tue, Jan 28, 2014 at 2:30 AM, Adrian Otto wrote: > Solum Core Reviewers, > > Thanks everyone for your feedback. I have made the adjustments. Welcome to > the core group Angus and Noorul. Tha

[openstack-dev] 答复: Proposed Logging Standards

I think it is also good for general i18n effort -原始邮件- 发件人: "Christopher Yeoh" 发送时间: ‎2014/‎1/‎28 11:02 收件人: "OpenStack Development Mailing List (not for usage questions)" 主题: Re: [openstack-dev] Proposed Logging Standards On Tue, Jan 28, 2014 at 12:55 AM, Sean Dague wrote: On 01/27

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Hi Nrupal, We definitely consider both these cases. Agree with you that we should aim to support both. BR, Irena From: Jani, Nrupal [mailto:nrupal.j...@intel.com] Sent: Monday, January 27, 2014 11:17 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev]

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Hi Robert, Thank you for raising this issue. Neutron side support for hybrid compute node is part of the mission I want to achieve by implementing: https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type. I think it should be allowed to run more than one agent on certain node and Me

Re: [openstack-dev] extending keystone identity

>From your original email, it sounds like you want to extend the existing LDAP identity driver implementation, rather than writing a custom driver from scratch, which is what you've written. The TemplatedCatalog driver sort of follows that pattern with the KVS catalog driver, although it's not a sp

[openstack-dev] [gantt] Scheduler sub-group meeting agenda 1/28

1) Memcached based scheduler updates 2) Scheduler code forklift 3) Opens -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-b

Re: [openstack-dev] [Solum] Proposed changes to solum-core

On Tue, Jan 28, 2014 at 2:30 AM, Adrian Otto wrote: > Solum Core Reviewers, > > Thanks everyone for your feedback. I have made the adjustments. Welcome to > the core group Angus and Noorul. Thanks again Monty. > Thank you all for the votes. Regards, Noorul > On Jan 27, 2014, at 12:54 PM, Ku

Re: [openstack-dev] extending keystone identity

I dug a bit more and found this in the logs: (keystone.common.wsgi): 2014-01-27 19:07:13,851 WARNING The action you have requested has not been implemented. Despite basing my (super simple) code on the SQL or LDAP backends, I must be doing something wrong. -->> I've placed my backend code

Re: [openstack-dev] extending keystone identity

Dolph, I appreciate the response and pointing me in the right direction. Here's what I have so far: CONF = config.CONF LOG = logging.getLogger(__name__) class Identity(identity.Driver): def __init__(self): super(Identity, self).__init__() LOG.debug('My authentication m

Re: [openstack-dev] Proposed Logging Standards

On Tue, Jan 28, 2014 at 12:55 AM, Sean Dague wrote: > On 01/27/2014 09:07 AM, Macdonald-Wallace, Matthew wrote: > > Hi Sean, > > > > I'm currently working on moving away from the "built-in" logging to use > log_config= and the python logging framework so that we can start > shipping to logstash/s

Re: [openstack-dev] [Ceilometer] [TripleO] adding process/service monitoring

On 28 January 2014 14:59, Richard Su wrote: > Hi, > > I have been looking into how to add process/service monitoring to > tripleo. Here I want to be able to detect when an openstack dependent > component that is deployed on an instance has failed. And when a failure > has occurred I want to be not

Re: [openstack-dev] [nova]Why not allow to create a vm directly with two VIF in the same network

Hi Paul: I am very glad to do the thing that puts together the practical use cases in which the same VM would benefit from multiple virtual connections to the same network, whatever it takes, I think we should at least guarantee the consistency of creating vms with nics and attaching nics.

Re: [openstack-dev] [oslo] log message translations

I think it is a good approach for i18n team, since I don't think all log needs to be translated, and enterprise who needs i18n can take what ever they need to translate, and not all of them. On Tue, Jan 28, 2014 at 3:02 AM, Doug Hellmann wrote: > > > > On Mon, Jan 27, 2014 at 1:51 PM, Daniel P.

[openstack-dev] [Ceilometer] [TripleO] adding process/service monitoring

Hi, I have been looking into how to add process/service monitoring to tripleo. Here I want to be able to detect when an openstack dependent component that is deployed on an instance has failed. And when a failure has occurred I want to be notified and eventually see it in Tuskar. Ceilometer doesn

[openstack-dev] Hacking repair scripts

Hi all, I have had in my ~/bin for a while a little script that I finally got around to tuning up and I thought others might be interested in it/find it useful. The concept is similar to https://pypi.python.org/pypi/autopep8 but does a really simple action to start. As many of u know the impor

Re: [openstack-dev] [Keystone] bp proposal: quotas on users and projects per domain

- Original Message - > From: "Florent Flament" > To: openstack-dev@lists.openstack.org > Sent: Friday, 24 January, 2014 8:07:28 AM > Subject: Re: [openstack-dev] [Keystone] bp proposal: quotas on users and > projects per domain > > I understand that not everyone may be interested in su

Re: [openstack-dev] [Solum] Proposed changes to solum-core

On 27/01/14 21:00 +, Adrian Otto wrote: Solum Core Reviewers, Thanks everyone for your feedback. I have made the adjustments. Welcome to the core group Angus and Noorul. Thanks again Monty. Thank you everyone for your support! -Angus Regards, Adrian On Jan 27, 2014, at 12:54 PM, Kur

Re: [openstack-dev] [keystone][heat] Migration to keystone v3 API questions

- Original Message - > From: "Steven Hardy" > To: openstack-dev@lists.openstack.org > Sent: Thursday, 23 January, 2014 9:21:47 PM > Subject: [openstack-dev] [keystone][heat] Migration to keystone v3 API > questions > > Hi all, > > I've recently been working on migrating the hea

Re: [openstack-dev] [Solum] Oslo Context and SecurityContext

On 27/01/14 22:53 +, Adrian Otto wrote: On Jan 27, 2014, at 2:39 PM, Paul Montgomery wrote: Solum community, I created several different approaches for community consideration regarding Solum context, logging and data confidentiality. Two of these approaches are documented here: https:/

Re: [openstack-dev] extending keystone identity

_check_password() is a private/internal API, so we make no guarantees about it's stability. Instead, override the public authenticate() method with something like this: def authenticate(self, user_id, password, domain_scope=None): if user_id in SPECIAL_LIST_OF_USERS: # compa

Re: [openstack-dev] [qa] Tempest test validation

On Fri, 24 Jan 2014 11:58:42 -0800 Franck Yelles wrote: > Hi everyone, > Hi - note that the openstack-qa mailing list is no longer being used (we should really remove it!). I've CC'd your email along to openstack-dev with the [qa] tag in the subject line. > I would need some clarification of t

Re: [openstack-dev] [Solum] Oslo Context and SecurityContext

On Jan 27, 2014, at 2:39 PM, Paul Montgomery wrote: > Solum community, > > I created several different approaches for community consideration > regarding Solum context, logging and data confidentiality. Two of these > approaches are documented here: > > https://wiki.openstack.org/wiki/Solum/L

[openstack-dev] [Solum]

Solum community, I created several different approaches for community consideration regarding Solum context, logging and data confidentiality. Two of these approaches are documented here: https://wiki.openstack.org/wiki/Solum/Logging A) Plain Oslo Log/Config/Context is in the "Example of Oslo L

Re: [openstack-dev] Mistral + taskflow mini-meetup

Just a note also: Taskflow's in a way is event-driven also, a workflow goes through various events and those events cause further actions (state-transitions, notifications, forward-progress). I fully expect the https://review.openstack.org/#/c/63155 (yes not oslo.messaging, but someday when th

Re: [openstack-dev] [savanna] Savanna 2014.1.b2 (Icehouse-2) dev milestone available

On 01/23/2014 11:59 AM, Sergey Lukjanov wrote: Hi folks, the second development milestone of Icehouse cycle is now available for Savanna. Here is a list of new features and fixed bug: https://launchpad.net/savanna/+milestone/icehouse-2 and here you can find tarballs to download it: http://ta

Re: [openstack-dev] What's Up Doc? Jan 27 2014

Sorry, must send a correction: Wednesday at 14:00:00 UTC is the time for the Wednesday Doc Team meeting on IRC in #openstack-meeting-alt this week. (Not 03:00). Thanks Matt and Summer for asking! Anne On Mon, Jan 27, 2014 at 9:35 AM, Anne Gentle wrote: > This week we have two chances to talk d

Re: [openstack-dev] MariaDB support

On Mon, Jan 27, 2014 at 1:43 PM, Don Kehn wrote: > check with the trove folks they might be testing percona. > > We don’t test Nova or other Openstack pieces against Percona. We do test Percona as a underlying datastore within Trove though. > > On Mon, Jan 27, 2014 at 2:34 PM, Michael Still w

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

On Mon, 2014-01-27 at 21:14 +, Jani, Nrupal wrote: > Hi, > > > > There are two possibilities for the hybrid compute nodes > > - In the first case, a compute node has two NICs, one SRIOV > NIC & the other NIC for the VirtIO > > - In the 2nd case, Compute node has only one

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

On Mon, 2014-01-27 at 22:31 +0100, Ian Wells wrote: > In any case, as discussed in the meeting, this is an optimisation and > not something we have to solve in the initial release, because: > +1 for this. We should keep it as future enhancement effort. --jyh _

Re: [openstack-dev] MariaDB support

check with the trove folks they might be testing percona. On Mon, Jan 27, 2014 at 2:34 PM, Michael Still wrote: > On Sat, Jan 25, 2014 at 5:32 AM, Tim Bell wrote: > >> >> >> We are reviewing options between MySQL and MariaDB. RHEL 7 beta seems to >> have MariaDB as the default MySQL-like DB. >

Re: [openstack-dev] [Ceilometer] Issues with transformers

On 27/01/14 23:41, Julien Danjou wrote: On Mon, Jan 27 2014, Adrian Turjak wrote: I created a gauge metric that is updated via notifications, and a pollster. The data from both of those needs to be transformed in to a cumulative metric. The transformer object works as intended, but the issue i

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 28th

Live migration for the first release is intended to be covered by macvtap, in my mind - direct mapped devices have limited support in hypervisors aiui. It seemed we had a working theory for that, which we test out and see if it's going to work. -- Ian. On 27 January 2014 21:38, Robert Li (baoli

Re: [openstack-dev] MariaDB support

On Sat, Jan 25, 2014 at 5:32 AM, Tim Bell wrote: > > > We are reviewing options between MySQL and MariaDB. RHEL 7 beta seems to > have MariaDB as the default MySQL-like DB. > > > > Can someone summarise the status of the OpenStack in terms of > > > > -What MySQL-flavor is/are currently te

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

On 27 January 2014 15:58, Robert Li (baoli) wrote: > Hi Folks, > > In today's meeting, we discussed a scheduler issue for SRIOV. The basic > requirement is for coexistence of the following compute nodes in a cloud: > -- SRIOV only compute nodes > -- non-SRIOV only compute nodes >

[openstack-dev] extending keystone identity

I'm looking to create a simple Identity driver that will look at usernames. A small number of specific users should be authenticated by looking at a hard-coded password in keystone.conf, while any other users should fall back to LDAP authentication. I based my original driver on what's found her

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Hi, There are two possibilities for the hybrid compute nodes - In the first case, a compute node has two NICs, one SRIOV NIC & the other NIC for the VirtIO - In the 2nd case, Compute node has only one SRIOV NIC, where VFs are used for the VMs, either macvtap or direct assign

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Ok, this is something that's going to be added in ml2. I was looking at the bind_port() routine in mech_agent.py. The routine check_segment_for_agent() seems to be performing static check. So we are going to add something like check_vnic_type_for_agent(), I guess? Is the pairing of an agent with

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

On Mon, 2014-01-27 at 14:58 +, Robert Li (baoli) wrote: > Hi Folks, > > > In today's meeting, we discussed a scheduler issue for SRIOV. The > basic requirement is for coexistence of the following compute nodes in > a cloud: > -- SRIOV only compute nodes > -- non-SRIOV only compute

Re: [openstack-dev] Proposed Logging Standards

Sean and John, I would be happy to help out with this for Cinder. Let me know how I can help. Jay S. Bryant IBM Cinder Subject Matter Expert & Cinder Core Member Department 7YLA, Building 015-2, Office E125, Rochester, MN Telephone: (507) 253-4270, FAX (507) 253-6410 TIE Line: 553-4270

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Hi Robert, Please see inline From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Monday, January 27, 2014 10:29 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV Hi Irena, I agree on your first comment. see

Re: [openstack-dev] [savanna] savannaclient v2 api

We should consider turning "mains" into a string instead of a list for v2. Hive and Pig Oozie actions use mains, and each may only specify a single

Re: [openstack-dev] [Solum] Proposed changes to solum-core

Solum Core Reviewers, Thanks everyone for your feedback. I have made the adjustments. Welcome to the core group Angus and Noorul. Thanks again Monty. Regards, Adrian On Jan 27, 2014, at 12:54 PM, Kurt Griffiths wrote: > +1 > > On 1/27/14, 11:54 AM, "Monty Taylor" wrote: > >> On 01/24/201

Re: [openstack-dev] [Solum] Proposed changes to solum-core

+1 On 1/27/14, 11:54 AM, "Monty Taylor" wrote: >On 01/24/2014 05:32 PM, Adrian Otto wrote: >> Solum Core Reviewers, >> >> I propose the following changes to solum-core: >> >> +asalkeld >> +noorul >> -mordred >> >> Thanks very much to mordred for helping me to bootstrap the reviewer >>team. Pleas

Re: [openstack-dev] Proposed Logging Standards

On Mon, Jan 27, 2014 at 6:07 AM, Sean Dague wrote: > Back at the beginning of the cycle, I pushed for the idea of doing some > log harmonization, so that the OpenStack logs, across services, made > sense. I've pushed a proposed changes to Nova and Keystone over the past > couple of days. > > This

[openstack-dev] stevedore 0.14

I have just released a new version of stevedore, 0.14, which includes a change to stop checking version numbers of dependencies for plugins. This should eliminate one class of problems we've seen where we get conflicting requirements to install, and the libraries are compatible, but the way stevedo

[openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 28th

Hi Folks, Check out 1 Agenda on Jan 28th, 2014. Please update if I have missed any thing. Let's finalize who's doing what tomorrow. I'm thinking to work on the nova SRIOV items, but the live migration may be a s

[openstack-dev] Neutron: Seeking suggestions about vendor service driver persisting info...

Hi, I'm working on a vendor driver for VPNaaS. The device I'm using has different 'id' requirements for some of the resources related to VPN. For example, the IPSec policy information can be identified by an ID up to 31 characters long, whereas with OpenStack the ID will be a 36 character UUID.

Re: [openstack-dev] Proposed Logging Standards

On Mon, 2014-01-27 at 08:07 -0500, Sean Dague wrote: > Back at the beginning of the cycle, I pushed for the idea of doing some > log harmonization, so that the OpenStack logs, across services, made > sense. I've pushed a proposed changes to Nova and Keystone over the past > couple of days. > > Thi

Re: [openstack-dev] Mistral + taskflow mini-meetup

Josh, thanks for sharing this with the community. Just a couple of words as an addition to that.. The driver for this conversation is that TaskFlow library and Mistral service in many ways do similar things: task processing combined somehow (flow or workflow). However, there’s a number of diffe

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Hi Irena, I agree on your first comment. see inline as well. thanks, Robert On 1/27/14 10:54 AM, "Irena Berezovsky" mailto:ire...@mellanox.com>> wrote: Hi Robert, all, My comments inline Regards, Irena From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Monday, January 27, 2014 5:05 PM To

Re: [openstack-dev] [oslo] log message translations

Jay Pipes wrote: >Have you ever tried using Google Translate for anything more than very >simple phrases? >The results can be... well, interesting ;) And given the amount of >technical terms used in these messages, I doubt GT or any automated >translating service would provide a whole lot of valu

Re: [openstack-dev] [Neutron] Representing PEM Format file as string

Hi Rajesh yes. Please take a looks nova keypair-add implementation https://github.com/openstack/python-novaclient/blob/e3d686f39ad9787a70894dff3db9352be6b3f0dd/novaclient/v1_1/shell.py#L2372 2014-01-27 Rajesh Mohan : > Nachi, > > I did not know that we could give files names. Since we had String

[openstack-dev] [oslo] team meeting Friday 31 Jan 1400 UTC

The Oslo team has a few items we need to discuss, so I'm calling a meeting for this Friday, 31 Jan. Our normal slot is 1400 UTC Friday in #openstack-meeting. The agenda [1] includes 2 items (so far): 1. log translations (see the other thread started today) 2. parallelizing our tests If you have

[openstack-dev] Reviewday data download problem

A few days ago, a change I submitted to reviewday to generate JSON results for easy consumption by an application merged. I was hoping that this could be used with next-review to help me prioritize reviews. So I was expecting to now be able to go to the URL and get the .json file, like this: curl

Re: [openstack-dev] [Neutron] Representing PEM Format file as string

Nachi, I did not know that we could give files names. Since we had String in the database, I assumed we need to give string as input. I guess, the neutron client will convert the file to string and then call the API. That should work. Thanks for the clarification. On Mon, Jan 27, 2014 at 10:4

Re: [openstack-dev] [savanna] paramiko requirement of >= 1.9.0?

Currently we have paramiko >= 1.9.0 in both global-requirements and savanna: https://review.openstack.org/#/c/68088/ https://review.openstack.org/#/c/69045/ On Tue, Jan 21, 2014 at 3:41 PM, Sergey Lukjanov wrote: > Here is a change for global-requirements > https://review.openstack.org/#/c/6808

Re: [openstack-dev] [oslo] log message translations

On Mon, 2014-01-27 at 19:06 +, CARVER, PAUL wrote: > Joshua Harlow wrote: > >From what I know most all (correct me if I am wrong) open source projects > >don't translate log messages; so it seems odd to be the special snowflake > >project/s. > > >Do people find this type of translation useful?

Re: [openstack-dev] [oslo] log message translations

Joshua Harlow wrote: >From what I know most all (correct me if I am wrong) open source projects >don't translate log messages; so it seems odd to be the special snowflake >project/s. >Do people find this type of translation useful? >It'd be nice to know how many people really do so the benefit/dr

Re: [openstack-dev] [oslo] log message translations

On Mon, Jan 27, 2014 at 1:51 PM, Daniel P. Berrange wrote: > On Mon, Jan 27, 2014 at 01:12:19PM -0500, Doug Hellmann wrote: > > On Mon, Jan 27, 2014 at 12:58 PM, Daniel P. Berrange < > berra...@redhat.com>wrote: > > > > > On Mon, Jan 27, 2014 at 12:42:28PM -0500, Doug Hellmann wrote: > > > > We ha

[openstack-dev] [infra] Meeting Tuesday January 28th at 19:00 UTC

The OpenStack Infrastructure (Infra) team is hosting our weekly meeting tomorrow, Tuesday January 28th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) Everyone interested in inf

Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords

+1 for the ones “ipv6_” prefix. On Jan 27, 2014, at 1:15 PM, Veiga, Anthony wrote: > I vote address them (ipv6_). There's no guarantee of forward > compatibility with a new protocol and this way it can't be confused with a > (non-existant) selection method for IPv4, either. Also, future u

Re: [openstack-dev] [Neutron] Representing PEM Format file as string

On Mon, 2014-01-27 at 10:49 -0800, Nachi Ueno wrote: > Hi Rajesh > > May I ask why we need single line representation of PEM format? > For CLI, we will use file_name as same as nova keypair-add. > We won't specify PEM on the URL. ++ -jay ___ OpenStac

Re: [openstack-dev] [oslo] log message translations

On Mon, Jan 27, 2014 at 01:12:19PM -0500, Doug Hellmann wrote: > On Mon, Jan 27, 2014 at 12:58 PM, Daniel P. Berrange > wrote: > > > On Mon, Jan 27, 2014 at 12:42:28PM -0500, Doug Hellmann wrote: > > > We have a blueprint open for separating translated log messages into > > > different domains so

Re: [openstack-dev] [Neutron] Representing PEM Format file as string

Hi Rajesh May I ask why we need single line representation of PEM format? For CLI, we will use file_name as same as nova keypair-add. We won't specify PEM on the URL. 2014-01-27 Rajesh Mohan : > Thanks John. > > My initial approach is similar to Keystone's. This is mainly to unblock me > from

Re: [openstack-dev] [oslo] log message translations

+1 I've never understood this either personally. >From what I know most all (correct me if I am wrong) open source projects don't translate log messages; so it seems odd to be the special snowflake project/s. Do people find this type of translation useful? It'd be nice to know how many people re

Re: [openstack-dev] [Neutron] Representing PEM Format file as string

Thanks John. My initial approach is similar to Keystone's. This is mainly to unblock me from making progress on the driver. Nachi is doing the API part. I will discuss with him to explore other options. Can you send us the link to your review? Thanks, -Rajesh Mohan On Mon, Jan 27, 2014 at 6:

[openstack-dev] Mistral + taskflow mini-meetup

Hi all, In order to encourage further discussion off IRC and more in public I'd like to share a etherpad that was worked on during a 'meetup' with some of the mistral folks and me. https://etherpad.openstack.org/p/taskflow-mistral-jan-meetup It was more of a (mini) in-person meetup but I thoug

Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords

I vote address them (ipv6_). There's no guarantee of forward compatibility with a new protocol and this way it can't be confused with a (non-existant) selection method for IPv4, either. Also, future updates of other protocols would require a new attribute and break the API less. -Anthony >OK -

Re: [openstack-dev] [oslo] log message translations

On Mon, Jan 27, 2014 at 12:58 PM, Daniel P. Berrange wrote: > On Mon, Jan 27, 2014 at 12:42:28PM -0500, Doug Hellmann wrote: > > We have a blueprint open for separating translated log messages into > > different domains so the translation team can prioritize them differently > > (focusing on error

Re: [openstack-dev] [TripleO] State preserving upgrades working, next MVP selection?

- Original Message - > From: "Clint Byrum" > To: "openstack-dev" > Sent: Monday, January 27, 2014 12:48:23 PM > Subject: Re: [openstack-dev] [TripleO] State preserving upgrades working, > next MVP selection? > > Excerpts from Dan Prince's message of 2014-01-27 09:22:21 -0800: > >

Re: [openstack-dev] [oslo] log message translations

On Mon, Jan 27, 2014 at 12:42:28PM -0500, Doug Hellmann wrote: > We have a blueprint open for separating translated log messages into > different domains so the translation team can prioritize them differently > (focusing on errors and warnings before debug messages, for example) [1]. > Feedback?

Re: [openstack-dev] [Solum] Proposed changes to solum-core

On 01/24/2014 05:32 PM, Adrian Otto wrote: Solum Core Reviewers, I propose the following changes to solum-core: +asalkeld +noorul -mordred Thanks very much to mordred for helping me to bootstrap the reviewer team. Please reply with your votes. +1 My pleasure - you guys seem like you're off

Re: [openstack-dev] Proposed Logging Standards

What I'd like to find out now: 1) who's interested in this topic? Please include me. 2) who's interested in helping flesh out the guidelines for various log levels? Please include me. 3) who's interested in helping get these kinds of patches into various projects in OpenStack? 4) which project

Re: [openstack-dev] [TripleO] State preserving upgrades working, next MVP selection?

Excerpts from Dan Prince's message of 2014-01-27 09:22:21 -0800: > > - Original Message - > > From: "Robert Collins" > > To: "OpenStack Development Mailing List" > > Sent: Sunday, January 26, 2014 3:30:22 PM > > Subject: [openstack-dev] [TripleO] State preserving upgrades working, >

[openstack-dev] [oslo] log message translations

We have a blueprint open for separating translated log messages into different domains so the translation team can prioritize them differently (focusing on errors and warnings before debug messages, for example) [1]. Some concerns were raised related to the review [2], and I would like to address t

Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords

OK - any suggestions for the names of API attributes? The PDF[0] shared does not specify the names of the attributes, so I had two ideas for the names of the two new attributes being added to the Subnet resource: Either prefix them with "ipv6" * ipv6_ra_mode * ipv6_address_mode Or don't prefix

Re: [openstack-dev] [TripleO] State preserving upgrades working, next MVP selection?

- Original Message - > From: "Robert Collins" > To: "OpenStack Development Mailing List" > Sent: Sunday, January 26, 2014 3:30:22 PM > Subject: [openstack-dev] [TripleO] State preserving upgrades working, next > MVP selection? > > So great news - we've now got state preserving upgrade

Re: [openstack-dev] [Climate] [Ceilometer] Integration

Hi Julien, 2014/1/27 Julien Danjou > Hi, > > I've created a blueprint for Climate support in Ceilometer: > > https://blueprints.launchpad.net/ceilometer/+spec/climate-support > > I've added a list of resources that I think should be metered. I'm not > sure about the other ones that I encoun

Re: [openstack-dev] [qa] [Tempest - Stress Test] : some improvements / issues on the stress test framework

Hi Julien, please don't forget the [qa] tag - otherwise your lost in the ML noise ;) Ok thanks for the bug reports. I confirmed 1273245 and 1273254 but I am not totally sure with 1273186. Could you give some more details how the CLI interface will look like? Or simply propose a patch. It could

[openstack-dev] [Keystone] - Cloud federation on top of the Apache

Dear all, We have Identity Provider and mapping CRUD operations already merged, so it's a good point to prepare Keystone and Apache to handle SAML (as a starter) requests/responses. For the next OpenStack release it'd be the Apache that handles SAML communication. In order to force SAML authen

Re: [openstack-dev] [Climate] [Ceilometer] Integration

Julien, great :) Thanks for starting this initiative, it's really interesting and we want to include that functionality to 0.2 Climate - as discussed in https://etherpad.openstack.org/p/climate-0.2 Thank you Dina On Mon, Jan 27, 2014 at 8:12 PM, Julien Danjou wrote: > Hi, > > I've created a b

Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles

I'd argue that we should call it 'overcloud role' - at least from the modeling point of view - since the tuskar-api calls a deployment an overcloud. But I like the general direction of the term-renaming! Mainn - Original Message - > Based on this thread which didn't seem to get clear out

[openstack-dev] [Climate] [Ceilometer] Integration

Hi, I've created a blueprint for Climate support in Ceilometer: https://blueprints.launchpad.net/ceilometer/+spec/climate-support I've added a list of resources that I think should be metered. I'm not sure about the other ones that I encountered in Climate; feel free to amend that list in the

Re: [openstack-dev] Proposed Logging Standards

> > I've also noticed just now that we appear to be "re-inventing" some parts of > the logging framework (openstack.common.log.WriteableLogger for example > appears to be a "catchall" when we should just be handing off to the default > logger and letting the python logging framework decide what to

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Hi Robert, all, My comments inline Regards, Irena From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Monday, January 27, 2014 5:05 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV Hi Folks, In today's meet

Re: [openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles

Based on this thread which didn't seem to get clear outcome, I have one last suggestion: * Deployment Role It looks that it might satisfy participants of this discussion. When I internally talked to people it got the best reactions from already suggested terms. Depending on your reactions f

[openstack-dev] What's Up Doc? Jan 27 2014

This week we have two chances to talk docs -- the IRC meeting for US and Europe is every other Wednesday in #openstack-meeting-alt at 03:00 UTC. We're also hosting a hangout on air on Wednesday, January 29, 2014 at 20:00:00 UTC. Look for a Hangouts On Air invitation on Google Plus. 1. In review a

Re: [openstack-dev] [Solum] Proposed changes to solum-core

On 01/24/2014 08:32 PM, Adrian Otto wrote: > Solum Core Reviewers, > > I propose the following changes to solum-core: > > +asalkeld > +noorul > -mordred > > Thanks very much to mordred for helping me to bootstrap the reviewer team. > Please reply with your votes. +1 -- Russell Bryant __

Re: [openstack-dev] [Solum] Proposed changes to solum-core

+1 -Original Message- From: "Murali Allada" Sent: Sunday, January 26, 2014 8:19pm To: "OpenStack Development Mailing List (not for usage questions)" Cc: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [Solum] Proposed changes to solum-core

[openstack-dev] [Tempest - Stress Test] : some improvements / issues on the stress test framework

Hi everyone, I would like to discuss some ideas / behavior that seems broken in the stress test part of Tempest. I opened some tickets in Launchpad and I would like to get the feedback of the community on these ideas / issues : - Provide kwargs from UnitTest to stress test scenarios (https://

Re: [openstack-dev] Proposed Logging Standards

On 01/27/2014 09:44 AM, Macdonald-Wallace, Matthew wrote: >> -Original Message- >> From: Sean Dague [mailto:s...@dague.net] >> Sent: 27 January 2014 14:26 >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] Proposed Logging Standards >> >> On

Re: [openstack-dev] [Neutron][LBaaS] Securing RPC channel between the server and the agent

On 01/27/2014 09:37 AM, Eugene Nikanorov wrote: > Hi folks, > > As we are going to add ssl implementation to lbaas which would be based > on well-known haproxy+stunnel combination, there is one problem that we > need to solve: securing communication channel between neutron-server and > the agent.

Re: [openstack-dev] [Tempest - Stress test] : cleanup() removing resources for all tenants with an admin_manager

Hello Boris, Rally seemes to be a really interesting tool and I will eventually using it for full scale benchmarking. However I will focus on tempest based tests for the time being in order to have these tests replayed regularly during the integration process. I believe that my needs are covere

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Hi Folks, In today's meeting, we discussed a scheduler issue for SRIOV. The basic requirement is for coexistence of the following compute nodes in a cloud: -- SRIOV only compute nodes -- non-SRIOV only compute nodes -- Compute nodes that can support both SRIOV and non-SRIOV port

Re: [openstack-dev] Proposed Logging Standards

> -Original Message- > From: Sean Dague [mailto:s...@dague.net] > Sent: 27 January 2014 14:26 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] Proposed Logging Standards > > On 01/27/2014 09:07 AM, Macdonald-Wallace, Matthew wrote: > > Hi Se

Re: [openstack-dev] [Nova] bp proposal: discovery of peer instances through metadata service

Day, Phil wrote: > > >> We already have a mechanism now where an instance can push metadata as > >> a way of Windows instances sharing their passwords - so maybe this could > >> build on that somehow - for example each instance pushes the data its > >> willing to share with other instances owned b

Re: [openstack-dev] Proposed Logging Standards

> -Original Message- > From: Sean Dague [mailto:s...@dague.net] > Sent: 27 January 2014 14:26 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] Proposed Logging Standards > > On 01/27/2014 09:07 AM, Macdonald-Wallace, Matthew wrote: > > Hi Se

Re: [openstack-dev] Proposed Logging Standards

On Mon, Jan 27, 2014 at 8:07 AM, Sean Dague wrote: > Back at the beginning of the cycle, I pushed for the idea of doing some > log harmonization, so that the OpenStack logs, across services, made > sense. I've pushed a proposed changes to Nova and Keystone over the past > couple of days. > > This

Re: [openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core

As a reviewee of Matt I vote +1 On 11/23/2013 10:17 AM, Gary Kotton wrote: This message has been archived. View the original item

[openstack-dev] [Neutron][LBaaS] Securing RPC channel between the server and the agent

Hi folks, As we are going to add ssl implementation to lbaas which would be based on well-known haproxy+stunnel combination, there is one problem that we need to solve: securing communication channel between neutron-server and the agent. I see several approaches here: 1) Rely on secure messaging

  1   2   >