Re: [openstack-dev] [Openstack] [cinder] Proposal for Ollie Leahy to join cinder-core

+1 On Thu, Jul 18, 2013 at 11:17 AM, Phillip Pao wrote: > +1 > > > On Wed, Jul 17, 2013 at 2:59 PM, Qing He wrote: > >> +1 >> >> ** ** >> >> *From:* Huang Zhiteng [mailto:[email protected]] >> *Sent:* Wednesday, July 17, 2013 2:56 PM >> >> *To:* OpenStack Development Mailing List >> *Su

Re: [openstack-dev] [cinder] Proposal for Ollie Leahy to join cinder-core

Mark McLoughlin wrote: > It is assumed that all core team members are wearing their "upstream > hat" and aren't there merely to represent their employers interests. Indeed, we should assume that everyone is wearing their upstream hat. And fix it if they don't, rather than preventively establish ru

[openstack-dev] Idea of Openstack Project Template

Hi all, I have a idea about create a project about Openstack Project Template. So i have spent several hours to create a basic *prototype* on github, which can only create project on ubuntu 12.04. https://github.com/JimJiangX/BoneDragon It can create a openstack project by modify config file and

Re: [openstack-dev] Change in openstack/neutron[master]: Add method to get iptables traffic counters

Hi Brian, For iptables rules, see below Yes the only way to setup metering labels/rules is the neutronclient. I agree with you about the future enhancement. Regards, Sylvain - Original Message - From: "Brian Haley" To: "Sylvain Afchain" Cc: [email protected] Sent: Th

[openstack-dev] About fixing old DB migrations

Hi all, I have some question about fixing old DB migrations. If we are now in havana. And some broken migration was added in Havana. Why we are not able to fix it directly? Instead of chaining few lines, we should add new migration that do some magic. For example in this migration https://revie

Re: [openstack-dev] [Heat] Long-term, how do we make heat image/flavor name agnostic?

On 18/07/13 08:14, Thomas Spatzier wrote: Steve Baker wrote on 18.07.2013 00:00:40: On 07/18/2013 08:53 AM, Gabriel Hurley wrote: I spent a bunch of time working with and understanding Heat in H2, and I find myself with one overarching question which I wonder if anyone's thought about or even

Re: [openstack-dev] About fixing old DB migrations

On 18/07/13 11:34, Boris Pavlovic wrote: > Hi all, > > I have some question about fixing old DB migrations. > > If we are now in havana. And some broken migration was added in Havana. > Why we are not able to fix it directly? > > Instead of chaining few lines, we should add new migration that

Re: [openstack-dev] [Swift] erasure codes, digging deeper

On Thu, Jul 18, 2013 at 12:42 AM, John Dickinson wrote: > * Erasure codes (vs replicas) will be set on a per-container basis I was wondering if there was any reasons why it couldn't be as per-account basis as this would allow an operator to have different type of an account and different pric

Re: [openstack-dev] [Heat] Long-term, how do we make heat image/flavor name agnostic?

On 18 July 2013 08:53, Gabriel Hurley wrote: > I spent a bunch of time working with and understanding Heat in H2, and I find > myself with one overarching question which I wonder if anyone's thought about > or even answered already... > > At present, the CloudFormation template format is the fir

Re: [openstack-dev] Chalenges with highly available service VMs

> I'd still like the simpler and more general purpose 'disable spoofing' > option as well. That doesn't allow MAC spoofing and it doesn't work > for what I'm up to. Read the document properly, Ian. I take back the MAC spoofing comment, but it still won't work for what I'm up to ;) _

Re: [openstack-dev] Chalenges with highly available service VMs

On 18 July 2013 00:45, Aaron Rosen wrote: > Hi Ian, > > For shared networks if the network is set to port_security_enabled=True then > the tenant will not be able to remove port_security_enabled from their port > if they are not the owner of the network. I believe this is the correct > behavior we

Re: [openstack-dev] [Nova] New DB column or new DB table?

On 07/17/2013 10:54 PM, Lu, Lianhao wrote: Hi fellows, Currently we're implementing the BP https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling. The main idea is to have an extensible plugin framework on nova-compute where every plugin can get different metrics(e.g. CPU ut

Re: [openstack-dev] About fixing old DB migrations

On 07/18/2013 05:54 AM, Nikola Đipanov wrote: Heya, Rule is because (I believe at least) - in the spirit of continuous integration - people should be able to deploy continuously anything on master. Due to the nature of schema versioning as done by sqlalchemy-migrate - changing a migration woul

[openstack-dev] [keystone] long term fate of UUID token?

Because it came up in this devstack review - https://review.openstack.org/#/c/37151/ I'm curious what the long term fate of UUID token is in keystone. It's no longer the default, but is it expected to continue to be supported for the forseable future? If it's being deprecated in keystone, now

Re: [openstack-dev] [keystone] long term fate of UUID token?

There's still appears to be considerable demand for UUID tokens, considering their simplicity relative to PKI tokens (no additional setup required, convenient length for copy/pasting around). There are also trade-offs when deciding between UUID and PKI tokens (e.g. network chatter vs CPU time, revo

Re: [openstack-dev] [Swift] erasure codes, digging deeper

Check out the slides I linked. The plan is to enable an EC policy that is then set on a container. A cluster may have a replication policy and one or more EC policies. Then the user will be able to choose the policy for a particular container. --John On Jul 18, 2013, at 2:50 AM, Chmouel Bou

Re: [openstack-dev] [Heat] Long-term, how do we make heat image/flavor name agnostic?

Robert, On Jul 18, 2013, at 3:08 AM, Robert Collins wrote: > On 18 July 2013 08:53, Gabriel Hurley wrote: >> I spent a bunch of time working with and understanding Heat in H2, and I >> find myself with one overarching question which I wonder if anyone's thought >> about or even answered alre

[openstack-dev] Opinions needed: Changing method signature in RPC callback ...

Hey y'all! Running into an interesting little dilemma with a branch I'm working on. Recently, I introduced a branch in oslo-common to optionally .reject() a kombu message on an exception. Currently, we always .ack() all messages even if the processing callback fails. For Ceilometer, this is a prob

Re: [openstack-dev] Opinions needed: Changing method signature in RPC callback ...

On 07/18/2013 11:09 AM, Sandy Walsh wrote: > 2. make a generic CallContext() object to include with message that has > anything else we need (a one-time signature break) > > call_context = CallContext({"delivery_info": {...}, "wait": False}) > callback(message, call_context) or just callback(me

Re: [openstack-dev] [Nova] New DB column or new DB table?

Hi All, I would like to chip in with something from the side here (sorry to stretch the discussion out). I was looking for a mechanism to do something like this in the context of this blueprint on network aware scheduling: https://blueprints.launchpad.net/nova/+spec/network-bandwidth-entitleme

[openstack-dev] Swift storage allocation

Are there lun sizing recommendations / ratios for allocating storage between containers, accounts, and objects? i.e. Given 1TB of total storage capacity how many luns should be created and how should they be allocated? Main use case is probably a consideration -- backups might require less acco

Re: [openstack-dev] [Openstack] [cinder] Proposal for Ollie Leahy to join cinder-core

+1 From: ZG Niu [mailto:[email protected]] Sent: Thursday, July 18, 2013 12:00 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Openstack] [cinder] Proposal for Ollie Leahy to join cinder-core +1 On Thu, Jul 18, 2013 at 11:17 AM, Phillip Pao mailto:[email protected]

Re: [openstack-dev] Opinions needed: Changing method signature in RPC callback ...

On Thu, 2013-07-18 at 11:09 -0300, Sandy Walsh wrote: > 3. some other ugly python hack that I haven't thought of yet. I have two possibilities, though neither is really ideal. One is to provide a duplicate call for registering the callback, but where the callback has the extra arguments. The oth

Re: [openstack-dev] Opinions needed: Changing method signature in RPC callback ...

On 07/18/2013 12:26 PM, Kevin L. Mitchell wrote: > On Thu, 2013-07-18 at 11:09 -0300, Sandy Walsh wrote: >> 3. some other ugly python hack that I haven't thought of yet. > > I have two possibilities, though neither is really ideal. One is to > provide a duplicate call for registering the callba

Re: [openstack-dev] [Nova] New DB column or new DB table?

On 07/18/2013 10:44 AM, Murray, Paul (HP Cloud Services) wrote: Hi All, I would like to chip in with something from the side here (sorry to stretch the discussion out). I was looking for a mechanism to do something like this in the context of this blueprint on network aware scheduling: https

[openstack-dev] Quantum to Neutron migration guide

Hi, I was wondering if there is a Quantum to Neutron migration guide that we can provide our users. Thanks chuck ___ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] [cinder] Proposal for Ollie Leahy to join cinder-core

On Wed, Jul 17, 2013 at 8:09 AM, Duncan Thomas wrote: > Hi Everybody > > I'd like to propose Ollie Leahy for cinder core. He has been doing > plenty of reviews and bug fixes, provided useful and tasteful negative > reviews (something often of far higher value than a +1) and has joined > in various

Re: [openstack-dev] [Openstack] [cinder] Proposal for Ollie Leahy to join cinder-core

On Thu, Jul 18, 2013 at 10:30 AM, thingee wrote: > On Wed, Jul 17, 2013 at 8:09 AM, Duncan Thomas wrote: > >> Hi Everybody >> >> I'd like to propose Ollie Leahy for cinder core. He has been doing >> plenty of reviews and bug fixes, provided useful and tasteful negative >> reviews (something often

Re: [openstack-dev] Opinions needed: Changing method signature in RPC callback ...

On 07/18/2013 10:09 AM, Sandy Walsh wrote: Hey y'all! Running into an interesting little dilemma with a branch I'm working on. Recently, I introduced a branch in oslo-common to optionally .reject() a kombu message on an exception. Currently, we always .ack() all messages even if the processing c

Re: [openstack-dev] [Nova] New DB column or new DB table?

Hi Jay, Lianhao, All, Sorry if this comes out of order - for some reason I am not receiving the messages so I'm cut-and-pasting from the archive :( I think I might mean something closer to Brian's blue print (now I've seen it) https://blueprints.launchpad.net/nova/+spec/heterogeneous-instance-

Re: [openstack-dev] [Heat] Long-term, how do we make heat image/flavor name agnostic?

Excerpts from Adrian Otto's message of 2013-07-18 06:31:10 -0700: > Robert, > > On Jul 18, 2013, at 3:08 AM, Robert Collins > wrote: > > > On 18 July 2013 08:53, Gabriel Hurley wrote: > >> I spent a bunch of time working with and understanding Heat in H2, and I > >> find myself with one overa

Re: [openstack-dev] [Savanna] Savanna 0.2 is released!

JFYI Savanna Dashboard is already available at PYPI as savanna-dashboard. Big thanks for OpenStack Infra guys for help! Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. On Jul 16, 2013, at 2:14, Sergey Lukjanov wrote: > Hello everyone, > > I'm very happy to announce the i

Re: [openstack-dev] Opinions needed: Changing method signature in RPC callback ...

On Thu, Jul 18, 2013 at 9:44 AM, Jay Pipes wrote: > On 07/18/2013 10:09 AM, Sandy Walsh wrote: > >> Hey y'all! >> >> Running into an interesting little dilemma with a branch I'm working on. >> Recently, I introduced a branch in oslo-common to optionally .reject() a >> kombu message on an exceptio

Re: [openstack-dev] Neutron/MPLS VPNaaS

Hi Lai Your BP looks very similer what I talked on the summit. https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-mpls-vpn Let's merge two of them. One comment on your bp is quagga supports this use case? Best Nachi 2013/7/17 Lai Xuejiao : > Hi, everyone > > Here is a new BP of MPLS

Re: [openstack-dev] [Swift] erasure codes, digging deeper

I'm with Chmouel though. It seems to me that EC policy should be chosen by the provider and not the client. For public storage clouds, I don't think you can make the assumption that all users/clients will understand the storage/latency tradeoffs and benefits. On Thu, Jul 18, 2013 at 8:11 AM, Jo

[openstack-dev] [Savanna] Team meeting reminder July 18 18:00 UTC

Hi folks, We'll be have the Savanna team meeting today as usual in #openstack-meeting-alt channel. Agenda: * Savann 0.2 release! * General news/updates * Savanna architecture discussions * EDP discussions http://www.timeanddate.com/worldclock/fixedtime.html?msg=Savanna+Meeting&iso=20130718T18

[openstack-dev] Fix for bug in @synchronized decorator coming

Hi all, During the review of https://review.openstack.org/#/c/36350/ Flavio mentioned that I should send something to the ml to notify people of the coming change in behavior, so here it is. The short version is that right now if you use external locking without specifying a lock_path in eit

Re: [openstack-dev] Chalenges with highly available service VMs

Is there something this is missing that could be added to cover your use case? I'd be curious to hear where this doesn't work for your case. One would need to implement the port_security extension if they want to completely allow all ips/macs to pass and they could state which ones are explicitly

[openstack-dev] Savanna EDP sequence diagrams added for discussion...

Hi all, Here is a page to hold sequence diagrams for Savanna EDP, based on current launchpad blueprints. We thought it might be helpful to create some diagrams for discussion as the component specs are written and the API is worked out: https://wiki.openstack.org/wiki/Savanna/EDP_Sequences

Re: [openstack-dev] [Swift] erasure codes, digging deeper

I'm not sure if I agree with the giving justifications (harder to bill, confusing to users), but I *do* think it could simplify some of the implementation (since users can't create accounts withe the "wrong" storage policy willy nilly). I think eventually some use cases may want mixed accounts (pa

Re: [openstack-dev] [Swift] erasure codes, digging deeper

Are you talking about the parameters for EC or the fact that something is erasure coded vs replicated? For the first, that's exactly what we're thinking: a deployer sets up one (or more) policies and calls them Alice, Bob, or whatever, and then the API client can set that on a particular contai

[openstack-dev] A vision for Keystone

I wrote up an essay that, I hope, explains where Keystone is headed as far as token management. http://adam.younglogic.com/2013/07/a-vision-for-keystone/ It is fairly long (2000 words) but I attempted to make it readable, and to provide the context for what we are doing. There are several bl

Re: [openstack-dev] [Swift] erasure codes, digging deeper

I think you are missing the point. What I'm talking about is who chooses what data is EC and what is not. The point that I am trying to make is that the operators of swift clusters should decide what data is EC, not the clients/users. How the data is stored should be totally transparent to the u

[openstack-dev] [Oslo-incubator] Request for meeting

Hey all, Just wanted to throw a word out to see if we could get an Oslo meeting scheduled, or if anyone else has some topics that would be relevant to discuss pertaining to recent Oslo work. I have a change in Oslo that I would like to discuss, but I don't think it would justify a meeting on it'

Re: [openstack-dev] [Swift] erasure codes, digging deeper

A solution to this might be to set the default policy as a configuration setting in the proxy. If you want a replicated swift cluster just allow this policy in the proxy and set it to default. The same for EC cluster, just set the allowed policy to EC. If you want both (and let your users decide wh

Re: [openstack-dev] [Swift] erasure codes, digging deeper

Yes, and I'd imagine that the normal default would be for replicated data. Moving the granularity from a container to account-based, as Chmouel and Chuck said, is interesting too. --John On Jul 18, 2013, at 11:32 AM, Christian Schwede wrote: > A solution to this might be to set the default po

[openstack-dev] [Ironic] [Ceilometer] wsme.api.Response ?

Woops, I meant to send this to the dev list... On Thu, Jul 18, 2013 at 11:35 AM, Devananda van der Veen < [email protected]> wrote: > It's in the docs, but is this supported yet? > > I see a note in Ceilometer saying to use it once wsme 0.5b3 is available, > which it isn't. Returning a Resp

Re: [openstack-dev] [Oslo-incubator] Request for meeting

Hi, On Thu, 2013-07-18 at 13:15 -0500, Lance D Bragstad wrote: > > Hey all, > > Just wanted to throw a word out to see if we could get an Oslo meeting > scheduled, or if anyone else has some topics that would be relevant to > discuss pertaining to recent Oslo work. I have a change in Oslo that I

[openstack-dev] [Savanna] Team meeting minutes July 18

Thanks everyone who have joined today's Savanna meeting. Here are the logs from the last meeting (July, 18): Minutes: http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-07-18-18.07.html Minutes (text): http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-07-18-18.07.

Re: [openstack-dev] [Oslo-incubator] Request for meeting

Hey Mark, Sorry for the spam, thanks for the notice! Best Regards, Lance Bragstad Software Engineer - OpenStack Cloud Solutions and OpenStack Development T/L 553-5409, External 507-253-5409 [email protected], Bld 015-2/C118 From: Mark McLoughlin To: OpenStack Development Mailing Li

Re: [openstack-dev] Opinions needed: Changing method signature in RPC callback ...

On Thu, Jul 18, 2013 at 10:09 AM, Sandy Walsh wrote: > > My worry is busting all the other callbacks out there that use > olso-common.rpc > These callback methods are part of the Kombu driver (and maybe part of Qpid), but are NOT part of the RPC abstraction. These are private methods. They can be

[openstack-dev] KMIP client for volume encryption key management

A blueprint and spec to add a client that implements OASIS KMIP standard was recently added: https://blueprints.launchpad.net/nova/+spec/kmip-client-for-volume-encryption https://wiki.openstack.org/wiki/KMIPclient We're looking for feedback to the set of questions in the spec. Any additional i

[openstack-dev] [Neutron][Requirement] SQLAlchemy raises None, causes TypeError

Hi folks Sometimes, I got "SQLAlchemy raises None, causes TypeError" This get debugging hard, because it hides real reasons. It looks like the problem of combining eventlet and sqlalchemy. http://stackoverflow.com/questions/9525220/sqlalchemy-raises-none-causes-typeerror Latest version of sqlal

Re: [openstack-dev] Opinions needed: Changing method signature in RPC callback ...

On 07/18/2013 03:55 PM, Eric Windisch wrote: > On Thu, Jul 18, 2013 at 10:09 AM, Sandy Walsh > wrote: > > > My worry is busting all the other callbacks out there that use > olso-common.rpc > > > These callback methods are part of the Kombu driver (an

Re: [openstack-dev] [Neutron][Requirement] SQLAlchemy raises None, causes TypeError

Hi Nachi, Usually that exception is raised when something goes wrong during transaction commit (__exit__ of with block that we usually use) I do session.flush() manually to see specific exception in such cases. In case exception is potentially unavoidable, explicitly calling flush() seems to be a

Re: [openstack-dev] [Savanna-all] Savanna EDP sequence diagrams added for discussion...

fyi, updates to the diagram based on feedback On Thu, 2013-07-18 at 13:49 -0400, Trevor McKay wrote: > Hi all, > > Here is a page to hold sequence diagrams for Savanna EDP, > based on current launchpad blueprints. We thought it might be helpful to > create some diagrams for discussion as the

Re: [openstack-dev] [Neutron][Requirement] SQLAlchemy raises None, causes TypeError

Hi Eugene Thanks for tips. I'm trying to investigate this one https://bugs.launchpad.net/neutron/+bug/1202797 Since we are using with context.session.. without flush for many place, it is good to fix this lib side bug. I have tested devstack with sqlalcemy 0.7.10 but it looks like keystone don't

Re: [openstack-dev] Opinions needed: Changing method signature in RPC callback ...

> > These callback methods are part of the Kombu driver (and maybe part of > > Qpid), but are NOT part of the RPC abstraction. These are private > > methods. They can be broken for external consumers of these methods, > > because there shouldn't be any. It will be a good lesson to anyone that > > t

[openstack-dev] [keystone] Split the Identity Backend blueprint

On Thu, Jul 18, 2013 at 3:05 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis) wrote: > Hello Dolph, > > I am writing to find out why the “Split the Identity Backend” blueprint (* > https://blueprints.launchpad.net/keystone/+spec/split-identity*

Re: [openstack-dev] [keystone] Split the Identity Backend blueprint

On Thu, Jul 18, 2013 at 5:01 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis) wrote: > Thank you for the explanation. Next question, do you have any > documentation on how to use the new feature? > > ** > Unfortunately, I don't see any documentation in the patches referenced by the reviews

Re: [openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.

Hi, I wanted to raise another design failure of why creating the port on nova-compute is bad. Previously, we have encountered this bug ( https://bugs.launchpad.net/neutron/+bug/1160442). What was causing the issue was that when nova-compute calls into quantum to create the port; quantum creates th

[openstack-dev] [nova] core review request - 34947

Hi, looking for some cores to check this out again: https://review.openstack.org/#/c/34947/ Basically it was already approved but failed to merge. I resolved the merge conflict, now it just needs approval again. I haven't been able to catch the previous approvers on IRC so trying the mailing

Re: [openstack-dev] [Neutron][Requirement] SQLAlchemy raises None, causes TypeError

On 07/18/2013 03:48 PM, Nachi Ueno wrote: Sometimes, I got "SQLAlchemy raises None, causes TypeError" This get debugging hard, because it hides real reasons. It looks like the problem of combining eventlet and sqlalchemy. http://stackoverflow.com/questions/9525220/sqlalchemy-raises-none-causes

Re: [openstack-dev] [Neutron][Requirement] SQLAlchemy raises None, causes TypeError

Hi David Thanks for your information. hmm it looks long way.. 2013/7/18 David Ripton : > On 07/18/2013 03:48 PM, Nachi Ueno wrote: > >> Sometimes, I got "SQLAlchemy raises None, causes TypeError" >> This get debugging hard, because it hides real reasons. >> >> It looks like the problem of combini

[openstack-dev] [barbican] Havana M2 Release

Hello folks, We are pleased to announce a Havana M2 release for the Barbican key management project, as detailed here: https://launchpad.net/cloudkeep/+announcements Thanks, John ___ OpenStack-dev mailing list [email protected] http://

Re: [openstack-dev] [Heat] Long-term, how do we make heat image/flavor name agnostic?

Generally spot-on with what Adrian said, but I have one question from that email: > Mappings is one of the high level concepts in CFN that I think can be > completely eliminated with auto-discovery. What do you mean by this? What kind of autodiscovery, and where? I'm all for eliminating mapping

Re: [openstack-dev] [Heat] Long-term, how do we make heat image/flavor name agnostic?

Thanks Steve, > InstanceType and ImageId could even be specified in the environment file > that is specified on launch, so they don't need to be specified in the launch > command, ie env.yaml: > parameters: > KeyName: heat_key > InstanceType: m1.micro > ImageId: ubuntu-vm-heat-cfntools-tempe

[openstack-dev] Hacking 0.6.0 Released

Hi All, I am pleased to announce we have just released version 0.6.0 of OpenStack's Style Guide tool, hacking. In addition to bug fixes version 0.6.0 introduces several new checks: H102: Apache 2.0 license header not found H103: header does not match Apache 2.0 License notice H231: Python 3.x in

Re: [openstack-dev] Chalenges with highly available service VMs

On 18 July 2013 19:48, Aaron Rosen wrote: > Is there something this is missing that could be added to cover your use > case? I'd be curious to hear where this doesn't work for your case. One > would need to implement the port_security extension if they want to > completely allow all ips/macs to p

Re: [openstack-dev] Chalenges with highly available service VMs

Yup: I'm definitely happy to review and give hints. Blueprint: https://docs.google.com/document/d/18trYtq3wb0eJK2CapktN415FRIVasr7UkTpWn9mLq5M/edit https://review.openstack.org/#/c/19279/ < patch that merged the feature; Aaron On Thu, Jul 18, 2013 at 5:15 PM, Ian Wells wrote: > On 18 July 2

Re: [openstack-dev] [vmware] VMwareAPI sub-team status update

I figure this out BTW. I had set up the account as "hartsock" then change the name to "hartsocks" the single sign on recognized me as the same person but the gerrit review system did not. I've moved the patch under "hartsocks" and now I can see all the settings. I would like to have the accounts

Re: [openstack-dev] [keystone] Split the Identity Backend blueprint

On 07/18/2013 06:10 PM, Dolph Mathews wrote: On Thu, Jul 18, 2013 at 5:01 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis) mailto:[email protected]>> wrote: Thank you for the explanation. Next question, do you have any documentation on how to use the new feature? Unfortunately,

Re: [openstack-dev] [Nova] New DB column or new DB table?

Sean Dague wrote on 2013-07-18: > On 07/17/2013 10:54 PM, Lu, Lianhao wrote: >> Hi fellows, >> >> Currently we're implementing the BP >> https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling. >> The main idea is to have > an extensible plugin framework on nova-compute where ev

[openstack-dev] [barbican] Use common openstack crypto from oslo ?

I was taking a look at Barbican sources on github and I noticed there is an implementation of a crypto class there. I was wondering if Barbican can be made to use the crypto utils pushed to oslo-incubator instead of using a project specific version. I ask because the implementation seem incomplet

Re: [openstack-dev] [barbican] Use common openstack crypto from oslo ?

On Thu, 2013-07-18 at 22:16 -0400, Simo Sorce wrote: > I was taking a look at Barbican sources on github and I noticed there is > an implementation of a crypto class there. > > I was wondering if Barbican can be made to use the crypto utils pushed > to oslo-incubator instead of using a project spe

Re: [openstack-dev] [Keystone] Reviewers wanted: Delegated Auth a la Oauth

Hi David, This email is long overdue. 1. I don't recall ever stating that we were going to use OAuth 1.0a over 2.0, or vice versa. I've checked https://etherpad.openstack.org/havana-saml-oauth-scim and https://etherpad.openstack.org/havana-external-auth and couldn't find anything that said defin