Re: [openstack-dev] [Nova][TripleO] Nested resources

2013-12-09 Thread Robert Collins
On 6 December 2013 14:11, Fox, Kevin M wrote: > I think the security issue can be handled by not actually giving the > underlying resource to the user in the first place. > > So, for example, if I wanted a bare metal node's worth of resource for my own > containering, I'd ask for a bare metal no

Re: [openstack-dev] [neutron] Creating "recipes" for mimicking behavior of nova-networking network managers.

2013-12-09 Thread Brent Eagles
On 12/09/2013 04:05 PM, Brent Eagles wrote: On 12/04/2013 07:56 PM, Tom Fifield wrote: On 05/12/13 01:14, Brent Eagles wrote: Hi, < snip > I think that's a great idea. What kind of format would you like to see the recepies in? Regards, Tom I think a wiki is the right way to start. It w

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

2013-12-09 Thread Tzu-Mainn Chen
> >* created as part of undercloud install process > >* can create additional management nodes (F) > > * Resource nodes > > > > ^ nodes is again confusing layers - nodes are > > what things are deployed to, but they aren't the entry point > > > > Can you,

Re: [openstack-dev] [ironic][qa] How will ironic tests run in tempest?

2013-12-09 Thread Robert Collins
On 10 December 2013 07:37, Devananda van der Veen wrote: > > We can test the ironic services, database, and the driver interfaces by > using our "fake" driver within a single devstack VM today (I'm not sure the > exercises for all of this have been written yet, but it's practical to test > it). O

[openstack-dev] [Solum] Language pack attributes schema

2013-12-09 Thread Georgy Okrokvertskhov
Hi, As a part of Language pack workgroup session we created an etherpad for language pack attributes definition. Please find a first draft of language pack attributes here: https://etherpad.openstack.org/p/Solum-Language-pack-json-format We have identified a minimal list of attributes which shoul

Re: [openstack-dev] [Solum] [Security]

2013-12-09 Thread Paul Montgomery
Thanks Clayton! I added your new content. To all: The OpenStack Security Guide is a very good resource to read - http://docs.openstack.org/security-guide/content/openstack_user_guide.html Apologies for not being up to speed on how things work in OpenStack yet but here is a list of topics that I

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

2013-12-09 Thread Robert Collins
On 10 December 2013 09:55, Tzu-Mainn Chen wrote: >> >* created as part of undercloud install process >> By that note I meant, that Nodes are not resources, Resource instances >> run on Nodes. Nodes are the generic pool of hardware we can deploy >> things onto. > > I don't think "resource

[openstack-dev] [Ceilometer] Nomination of Sandy Walsh to core team

2013-12-09 Thread Herndon, John Luke
Hi There! I¹m not 100% sure what the process is around electing an individual to the core team (i.e., can a non-core person nominate someone?). However, I believe the ceilometer core team could use a member who is more active in the development of the event pipeline. A core developer in this area

Re: [openstack-dev] TransportURL and virtualhost/exchnage (was Re: [Oslo] Layering olso.messaging usage of config)

2013-12-09 Thread Mark McLoughlin
Hi Gordon, On Fri, 2013-12-06 at 18:36 +, Gordon Sim wrote: > On 11/18/2013 04:44 PM, Mark McLoughlin wrote: > > On Mon, 2013-11-18 at 11:29 -0500, Doug Hellmann wrote: > >> IIRC, one of the concerns when oslo.messaging was split out was > >> maintaining support for existing deployments with c

[openstack-dev] anyone aware of networking issues with grizzly live migration of kvm instances?

2013-12-09 Thread Chris Friesen
Hi, We've got a grizzly setup using quantum networking and libvirt/kvm with VIR_MIGRATE_LIVE set. I was live-migrating an instance back and forth between a couple of compute nodes. It worked fine for maybe half a dozen migrations and then after a migration I could no longer ping it. It ap

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

2013-12-09 Thread Jay Dobies
So the question is are we looking at /nodes/ that have a /current role/, or are we looking at /roles/ that have some /current nodes/. My contention is that the role is the interesting thing, and the nodes is the incidental thing. That is, as a sysadmin, my hierarchy of concerns is something li

[openstack-dev] Neutron Distributed Virtual Router

2013-12-09 Thread Vasudevan, Swaminathan (PNB Roseville)
Hi Folks, We are in the process of defining the API for the Neutron Distributed Virtual Router, and we have a question. Just wanted to get the feedback from the community before we implement and post for review. We are planning to use the "distributed" flag for the routers that are supposed to

Re: [openstack-dev] [heat] Core criteria, review stats vs reality

2013-12-09 Thread Steven Hardy
On Tue, Dec 10, 2013 at 08:34:04AM +1300, Robert Collins wrote: > On 10 December 2013 00:31, Steven Hardy wrote: > > Hi all, > > > > So I've been getting concerned about $subject recently, and based on some > > recent discussions so have some other heat-core folks, so I wanted to start > > a discu

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

2013-12-09 Thread Robert Collins
On 10 December 2013 10:57, Jay Dobies wrote: >> >> So we have: >> - node - a physical general purpose machine capable of running in >> many roles. Some nodes may have hardware layout that is particularly >> useful for a given role. >> - role - a specific workload we want to map onto one or mo

Re: [openstack-dev] [keystone] Service scoped role definition

2013-12-09 Thread David Chadwick
Hi Arvind this is still mixing up two separate concepts: naming and policy constraints. Scope is a policy constraint but in the proposal below is also part of the unique naming of the role. The fields making up both concepts need to be separate (e.g. what if 2 different roles from the same domain

Re: [openstack-dev] [Oslo] First steps towards amqp 1.0

2013-12-09 Thread Gordon Sim
On 12/09/2013 07:15 PM, Russell Bryant wrote: On 12/09/2013 12:56 PM, Gordon Sim wrote: In the case of Nova (and others that followed Nova's messaging patterns), I firmly believe that for scaling reasons, we need to move toward it becoming the norm to use peer-to-peer messaging for most things.

Re: [openstack-dev] [olso] [cinder] upgrade issues in lock_path in cinder after oslo utils sync

2013-12-09 Thread Mark McLoughlin
On Mon, 2013-12-09 at 11:11 -0600, Ben Nemec wrote: > On 2013-12-09 10:55, Sean Dague wrote: > > On 12/09/2013 11:38 AM, Clint Byrum wrote: > >> Excerpts from Sean Dague's message of 2013-12-09 08:17:45 -0800: > >>> On 12/06/2013 05:40 PM, Ben Nemec wrote: > On 2013-12-06 16:30, Clint Byrum wr

Re: [openstack-dev] Retiring "reverify no bug"

2013-12-09 Thread Mark McLoughlin
On Mon, 2013-12-09 at 10:49 -0800, James E. Blair wrote: > Hi, > > On Wednesday December 11, 2013 we will remove the ability to use > "reverify no bug" to re-trigger gate runs for changes that have failed > tests. > > This was previously discussed[1] on this list. There are a few key > things to

Re: [openstack-dev] [heat] Core criteria, review stats vs reality

2013-12-09 Thread Robert Collins
On 10 December 2013 11:04, Steven Hardy wrote: >> So it's a gross mischaracterisation to imply that a democratic process >> aided by some [crude] stats has been reduced to name & shame, and a >> rather offensive one. > > Yes I have read your monthly core reviewer update emails[1] and I humbly > a

Re: [openstack-dev] [neutron] Questions on logging setup for development

2013-12-09 Thread Vishvananda Ishaya
On Dec 6, 2013, at 2:09 PM, Paul Michali wrote: > Hi, > > For Neutron, I'm creating a module (one of several eventually) as part of a > new blueprint I'm working on, and the associated unit test module. I'm in > really early development, and just running this UT module as a standalone > scri

Re: [openstack-dev] [keystone] Service scoped role definition

2013-12-09 Thread Tiwari, Arvind
I think that make sense, how does below data model looks? { "role": { "id": "76e72a", "name": "---role_name---", (resource name spaced name e.g. nova.east.admin) "scope": { "id": "---id---", (resource_id) "type": "service | file | domain etc.", "endpoint

[openstack-dev] [keystone][heat] ec2tokens, v3 credentials and request signing

2013-12-09 Thread Steven Hardy
Hi all, I have some queries about what the future of the ec2tokens API is for keystone, context as we're looking to move Heat from a horrible mixture of v2/v3 keystone to just v3, currently I'm not sure we can: - The v3/credentials API allows ec2tokens to be stored (if you create the access/sec

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

2013-12-09 Thread Tzu-Mainn Chen
Thanks for the explanation! I'm going to claim that the thread revolves around two main areas of disagreement. Then I'm going to propose a way through: a) Manual Node Assignment I think that everyone is agreed that automated node assignment through nova-scheduler is by far the most ideal case

Re: [openstack-dev] [Oslo] First steps towards amqp 1.0

2013-12-09 Thread Russell Bryant
On 12/09/2013 05:16 PM, Gordon Sim wrote: > On 12/09/2013 07:15 PM, Russell Bryant wrote: >> On 12/09/2013 12:56 PM, Gordon Sim wrote: In the case of Nova (and others that followed Nova's messaging patterns), I firmly believe that for scaling reasons, we need to move toward it becomi

Re: [openstack-dev] Retiring "reverify no bug"

2013-12-09 Thread James E. Blair
Mark McLoughlin writes: > I wonder could we make it standard practice for an infra bug to get > filed whenever there's a known issue causing gate jobs to fail so that > everyone can use that bug number when re-triggering? > > (Apologies if that's already happening) > > I guess we'd want to broadc

Re: [openstack-dev] [Nova][TripleO] Nested resources

2013-12-09 Thread Mark McLoughlin
On Tue, 2013-12-10 at 09:40 +1300, Robert Collins wrote: > On 6 December 2013 14:11, Fox, Kevin M wrote: > > I think the security issue can be handled by not actually giving the > > underlying resource to the user in the first place. > > > > So, for example, if I wanted a bare metal node's worth

Re: [openstack-dev] [heat] Core criteria, review stats vs reality

2013-12-09 Thread Steven Hardy
On Tue, Dec 10, 2013 at 11:25:49AM +1300, Robert Collins wrote: > On 10 December 2013 11:04, Steven Hardy wrote: > > >> So it's a gross mischaracterisation to imply that a democratic process > >> aided by some [crude] stats has been reduced to name & shame, and a > >> rather offensive one. > > >

[openstack-dev] [Nova][Cells] compute api and objects

2013-12-09 Thread Sam Morrison
Hi, I’m trying to fix up some cells issues related to objects. Do all compute api methods take objects now? cells is still sending DB objects for most methods (except start and stop) and I know there are more than that. Eg. I know lock/unlock, shelve/unshelve take objects, I assume there are ot

Re: [openstack-dev] How to best make User Experience a priority in every project

2013-12-09 Thread Kurt Griffiths
I love the idea of treating usability as a first-class citizen; to do that, we definitely need a core set of people who are passionate about the topic in order to keep it alive in the OpenStack gestalt. Contributors tend to prioritize work on new, concrete features over “non-functional” requirem

Re: [openstack-dev] [heat] Core criteria, review stats vs reality

2013-12-09 Thread Mark McLoughlin
On Mon, 2013-12-09 at 10:00 -0500, Russell Bryant wrote: > On 12/09/2013 07:43 AM, Thierry Carrez wrote: > > Steven Hardy wrote: > >> [...] > >> The issues I have are: > >> - Russell's stats (while very useful) are being used by some projects as > >> the principal metric related to -core membersh

Re: [openstack-dev] [Oslo] First steps towards amqp 1.0

2013-12-09 Thread Mark McLoughlin
On Mon, 2013-12-09 at 16:05 +0100, Flavio Percoco wrote: > Greetings, > > As $subject mentions, I'd like to start discussing the support for > AMQP 1.0[0] in oslo.messaging. We already have rabbit and qpid drivers > for earlier (and different!) versions of AMQP, the proposal would be > to add an a

Re: [openstack-dev] [heat] Core criteria, review stats vs reality

2013-12-09 Thread Angus Salkeld
On 09/12/13 11:31 +, Steven Hardy wrote: Hi all, So I've been getting concerned about $subject recently, and based on some recent discussions so have some other heat-core folks, so I wanted to start a discussion where we can agree and communicate our expectations related to nomination for he

Re: [openstack-dev] [neutron] Questions on logging setup for development

2013-12-09 Thread Paul Michali
Thanks! That worked PCM (Paul Michali) MAIL p...@cisco.com IRCpcm_ (irc.freenode.net) TW@pmichali GPG key4525ECC253E31A83 Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 On Dec 9, 2013, at 5:27 PM, Vishvananda Ishaya wrote: > > On Dec

Re: [openstack-dev] [Tripleo] Core reviewer update Dec

2013-12-09 Thread Robert Collins
On 6 December 2013 21:56, Jaromir Coufal wrote: > > Hey there, > > thanks Rob for keeping eye on this. Speaking for myself, as current > non-coder it was very hard to keep pace with others, especially when UI was > on hold and I was designing future views. I'll continue working on designs > much

Re: [openstack-dev] [Oslo] First steps towards amqp 1.0

2013-12-09 Thread Mike Wilson
This is the first time I've heard of the dispatch router, I'm really excited now that I've looked at it a bit. Thx Gordon and Russell for bringing this up. I'm very familiar with the scaling issues associated with any kind of brokered messaging solution. We grew an Openstack installation to about 7

Re: [openstack-dev] Neutron Distributed Virtual Router

2013-12-09 Thread Mike Wilson
I guess the question that immediately comes to mind is, is there anyone that doesn't want a distributed router? I guess there could be someone out there that hates the idea of traffic flowing in a balanced fashion, but can't they just run a single router then? Does there really need to be some flag

Re: [openstack-dev] Neutron Distributed Virtual Router

2013-12-09 Thread Ian Wells
I would imagine that, from the Neutron perspective, you get a single router whether or not it's distributed. I think that if a router is distributed - regardless of whether it's tenant-tenant or tenant-outside - it certainly *could* have some sort of SLA flag, but I don't think a simple 'distribut

Re: [openstack-dev] [keystone][heat] ec2tokens, v3 credentials and request signing

2013-12-09 Thread Yee, Guang
There's a HMAC-based generic signature authentication plugin patch which should meet your needs. https://review.openstack.org/#/c/40036/ Now the hard part, code review. :) Guang > -Original Message- > From: Steven Hardy [mailto:sha...@redhat.com] > Sent: Monday, December 09, 2013 2:34

Re: [openstack-dev] [keystone] Service scoped role definition

2013-12-09 Thread Adam Young
On 12/09/2013 05:31 PM, Tiwari, Arvind wrote: I think that make sense, how does below data model looks? { "role": { "id": "76e72a", "name": "---role_name---", (resource name spaced name e.g. nova.east.admin) "scope": { "id": "---id---", (resource_id)

Re: [openstack-dev] Neutron Distributed Virtual Router

2013-12-09 Thread Yongsheng Gong
If distributed router is good enough, why do we still need non-distributed router? On Tue, Dec 10, 2013 at 9:04 AM, Ian Wells wrote: > I would imagine that, from the Neutron perspective, you get a single > router whether or not it's distributed. I think that if a router is > distributed - rega

Re: [openstack-dev] [keystone][heat] ec2tokens, v3 credentials and request signing

2013-12-09 Thread Adam Young
On 12/09/2013 05:34 PM, Steven Hardy wrote: Hi all, I have some queries about what the future of the ec2tokens API is for keystone, context as we're looking to move Heat from a horrible mixture of v2/v3 keystone to just v3, currently I'm not sure we can: - The v3/credentials API allows ec2to

Re: [openstack-dev] Neutron Distributed Virtual Router

2013-12-09 Thread Nachi Ueno
Hi Yong NSX have two kind of router. Edge and distributed router. Edge node will work as some VPN services and advanced service nodes. Actually, VPNaaS OSS impl is running in l3-agent. so IMO, we need l3-agent also for basis of some edge services. 2013/12/9 Yongsheng Gong : > If distributed

[openstack-dev] OK to Use Flufl.enum

2013-12-09 Thread Adam Young
While Python 3 has enumerated types, Python 2 does not, and the standard package to provide id, Flufl.enum, is not yet part of our code base. Is there any strong objection to including Flufl.enum? http://pythonhosted.org/flufl.enum/ It makes for some very elegant code, especially for enumerat

Re: [openstack-dev] OK to Use Flufl.enum

2013-12-09 Thread Alex Gaynor
Would it make sense to use the `enum34` package, which is a backport of teh enum package from py3k? Alex On Mon, Dec 9, 2013 at 7:37 PM, Adam Young wrote: > While Python 3 has enumerated types, Python 2 does not, and the standard > package to provide id, Flufl.enum, is not yet part of our code

[openstack-dev] Scheduler sub-group agenda 12/10

2013-12-09 Thread Dugger, Donald D
1) Scheduler as a Service (review BP https://blueprints.launchpad.net/nova/+spec/forklift-scheduler-breakout ) 2) Memcached based scheduler updates 3) Instance groups -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786 _

Re: [openstack-dev] Neutron Distributed Virtual Router

2013-12-09 Thread Akihiro Motoki
Neutron defines "provider" attribute and it is/will be used in advanced services (LB, FW, VPN). Doesn't it fit for a distributed router case? If we can cover all services with one concept, it would be nice. According to this thread, we assumes at least two types "edge" and "distributed". Though

Re: [openstack-dev] [Tripleo] Core reviewer update Dec

2013-12-09 Thread Joe Gordon
On Dec 10, 2013 2:37 AM, "Robert Collins" wrote: > > On 6 December 2013 21:56, Jaromir Coufal wrote: > > > > > Hey there, > > > > thanks Rob for keeping eye on this. Speaking for myself, as current > > non-coder it was very hard to keep pace with others, especially when UI was > > on hold and I w

Re: [openstack-dev] [Neutron] Third-party testing

2013-12-09 Thread Yoshihiro Kaneko
2013/12/10 Matt Riedemann : > > > On Sunday, December 08, 2013 11:32:50 PM, Yoshihiro Kaneko wrote: >> >> Hi Neutron team, >> >> I'm working on building Third-party testing for Neutron Ryu plugin. >> I intend to use Jenkins and gerrit-trigger plugin. >> >> It is required that Third-party testing pr

Re: [openstack-dev] [Neutron] DHCP Agent Reliability

2013-12-09 Thread Isaku Yamahata
On Mon, Dec 09, 2013 at 08:07:12PM +0900, Isaku Yamahata wrote: > On Mon, Dec 09, 2013 at 08:43:59AM +1300, > Robert Collins wrote: > > > On 9 December 2013 01:43, Maru Newby wrote: > > > > > > > >>> If AMQP service is set up not to lose notification, notifications will > > >>> be piled up >

Re: [openstack-dev] [Neutron] DHCP Agent Reliability

2013-12-09 Thread Robert Collins
On 10 December 2013 19:16, Isaku Yamahata wrote: > Answering myself. If connection is closed, it will reconnects automatically > at rpc layer. See neutron.openstack.common.rpc.impl_{kombu, qpid}.py. > So notifications during reconnects can be lost if AMQP service is set > to discard notifications

Re: [openstack-dev] [Tripleo] Core reviewer update Dec

2013-12-09 Thread Mark McLoughlin
On Tue, 2013-12-10 at 13:31 +1300, Robert Collins wrote: > We have a bit of a bug in OpenStack today, IMO, in that there is more > focus on being -core than on being a good effective reviewer. IMO > that's backwards: the magic switch that lets you set +2 and -2 is a > responsibility, and that has

Re: [openstack-dev] [Neutron] DHCP Agent Reliability

2013-12-09 Thread Isaku Yamahata
On Tue, Dec 10, 2013 at 07:28:10PM +1300, Robert Collins wrote: > On 10 December 2013 19:16, Isaku Yamahata wrote: > > > Answering myself. If connection is closed, it will reconnects automatically > > at rpc layer. See neutron.openstack.common.rpc.impl_{kombu, qpid}.py. > > So notifications dur

Re: [openstack-dev] [Keystoneclient] [Keystone] [Solum] Last released version of keystoneclient does not work with python33

2013-12-09 Thread Chmouel Boudjnah
On Fri, Dec 6, 2013 at 4:30 PM, Dolph Mathews wrote: > > ++ and the other errors I was hitting all have open patches in gerrit to > see them fixed. It didn't seem like we were far off, but I haven't tested > all these patches together yet to find out if they're just hiding even more > problems. Ei

<    1   2