Re: [Openstack] Proposal for Dashboard as an official OpenStack project

[Thierry Carrez]

Devin Carlen wrote:
> I believe the time is right to make the dashboard an official OpenStack 
> project.
> 
> To my knowledge, no other projects have gone through the incubation process 
> to become an official project, so in some ways we are in uncharted territory.
> 
> Is there an officially documented process to make this happen?  

It needs to be proposed to the PPB for acceptance. Please put it on the
meeting agenda at [1].

[1] http://wiki.openstack.org/Governance/PPB

Note that the PPB still needs to finalize the evolution of its current
"Project addition" process [2] to accommodate the new
Core/Incubation/Related project types [3] with clear process to move
from one to another.

[2] http://wiki.openstack.org/Governance/Approved/NewProjectProcess
[3] http://wiki.openstack.org/ProjectTypes

Maybe we can do everything in one meeting :)

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] DRBD storage for Openstack installations

[Oleg Gelbukh]

Hi
Our approach was defined by need to combine storage and compute on the same
hosts.
Our configuration is dual-primary, so we can run nova-compute and virtual
servers on both nodes and have them with write access to volumes. DRBD
allows this mode out-of-box now, but it requires clustered file system or
great caution when runnning LVM on it.
But nova-volume must run on one node of drbd-connected pair, while the
second gets copy of lvm data via drbd. The tricky part is that it seems we
must activate volumes and volume groups on the peer node, but automation of
this is relatively easy.
For now, we are not going to share volumes outside of drbd-peers pair for
live migration or as attachable volumes, except some special cases like
migrating VMs between drbd pairs.
Looking forward to read couple of words on your approach.

2011/5/26 Diego Parrilla Santamaría 

> Hi Oleg,
>
> thank you very much for your post, it's really didactic. We are taking a
> different approach for HA at storage level, but I have worked formerly with
> DRBD and I think it's a very good choice.
>
> I'm curious about how you have deployed nova-volume nodes in your
> architecture. You don't specify if the two nodes of the DRBD cluster run one
> or two instances of nova-volume. If you run one instance probably you have
> implemented some kind of fault-tolerant active-passive service if the
> nova-volume process fails in the active node, but I would like to know if
> you can run an active-active two nova-volume instances on two different
> physical nodes on top of the DRBD shared resource.
>
> Regards
> Diego
>
> --
> Diego Parrilla
> *CEO*
> *www.stackops.com | * diego.parri...@stackops.com** | +34 649 94 43 29 |
> skype:diegoparrilla*
> * 
>
>
>
> On Thu, May 26, 2011 at 1:29 PM, Oleg Gelbukh wrote:
>
>> Hi,
>> We were researching Openstack for our private cloud, and want to share
>> experience and get tips from community as we go on.
>>
>> We have settled on DRBD as shared storage platform for our installation.
>> LVM is used over the drbd device to mange logical volumes. OCFS2 file system
>> is created on one of volumes, mounted and set up as *image_path* and *
>> instance_path* in the *nova.conf*, other space is reserved for storage
>> volumes (managed by nova-volume).
>>
>> As a result, we have shared storage suitable for features such as live
>> migration and snapshots. We also have some level of fault-tolerance, with
>> DRBD I/O error handling, which automatically redirects I/O requests to peer
>> node over network in case of primary node failure. We created 
>> scriptfor
>>  bootstrapping lost VMs in two crash scenarios:
>> * dom0 host restart/domU failure: restore VMs on the same host
>> * dom0 host failure: restore VMs on peer node
>> We are considering such pair of servers with shared storage as a basic
>> block for the cloud structure.
>>
>> For whom it may interest, the details of DRBD installation are 
>> here.
>> I'll be glad to answer any questions and highly appreciate feedback on this.
>>
>> Oleg S. Gelbukh,
>> Mirantis Inc.
>> www.mirantis.com
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Keystone Release #1 - seeking community input

[James Weir]

 Hi,

Completely agree with your last statement,but always good to know what 
other people are doing around identity (albiet web identity in this case).
I am not the best person to run with that integration, however, I know 
the guy that would be.  I will reach out to him to see if that would be 
an interesting side project.


Cheers
James


On 5/26/11 4:22 PM, Ziad Sawalha wrote:
Hi James – this is interesting work. Desire to incorporate it into 
Keystone will increase when and if it gains traction. Either way, if 
this is something someone (you?) wants to implement as a keystone 
plug-in, that's why we made it pluggable.


Reconfirming also that we're specifically not trying to solve identity 
(or web identity) with Keystone. We're focused on providing a 
framework for integrating any existing standard (or custom) identity 
solution into OpenStack.


Thanks for the link.

Z

From: James Weir >

Date: Thu, 26 May 2011 09:52:54 +0200
To: Ziad Sawalha >
Cc: "openstack@lists.launchpad.net 
" >

Subject: Re: [Openstack] Keystone Release #1 - seeking community input

Hi,

Unsure if this is interesting also to consider under the keystone project:

http://www.w3.org/wiki/Foaf+ssl

This is more for social web, but might be interesting for user 
authentication.


Regards
James


On 5/26/11 9:04 AM, Ziad Sawalha wrote:

Hi Everyone!

It's been a while since the summit in Santa Clara. It was great 
meeting with everyone who was there – looking forward to the next one!


Since the summit, we've been working on Keystone and figuring out how 
to integrate it into OpenStack (Nova, Swift, Glance, and the 
dashboard). There has been much activity on the project. The code, 
design, and API has been changing daily. Anyone interested, please 
join us.


*_RELEASE 1_*
Milestone 1 for Diablo is right around the corner already! The goal 
remains to create a common auth system supporting existing use cases. 
There are a couple of proposals we'd like community input on before 
we get too far into the implementation:


   1. API spec
   2. Scope of first release

*API Spec*
We've published an API spec doc which we've been altering as requests 
come in for changes. The spec includes proposals for a core API that 
covers:


* tokens: for authentication
* tenants: for isolating and grouping resources to support
  multi-tenancy
* users: because we have to!
* roles: to support the Nova roles (see
  http://nova.openstack.org/runnova/managing.users.html for roles
  and users)
* credentials: to address the EC2, Rackspace auth,
  multiple-credentials question

The draft spec is on github and includes both the core APIs and 
additional extensions needed to make Keystone function as a 
stand-alone system. We'd like to lock it down as soon as is 
feasible. R1 is too close (June 2nd) so we probably won't be done by 
then, but aiming for Friday June 10th gives us a good couple of weeks 
to get there and then a couple of weeks to firm up implementation and 
tests, so we should be able to hit R2 with a locked down API.



*Scope of R1*
For the first Diablo milestone, we're aiming to support the user 
stories listed in http://wiki.openstack.org/KeystoneR1



*_ANNOUNCEMENTS_*

*Repo*
We're moving the source to the Rackspace repo (mainly because we can 
add multiple admins). Please start using the new repo. I will keep 
both in sync for a while.


https://github.com/rackspace/keystone/

I was able to change my config with those commands:

git remote rm origin
git remote add origin -m master -t master
https://your/-login/@github.com/rackspace/keystone.git


As you open new issues, please use the Rackspace repo.

*Participate*
If you're interested in joining the team and working on Keystone, 
we'd love the input and help. Just let me know. And, of course, 
anyone is welcome to submit code, blueprints, issues, etc…


Looking forward to hearing from ya'll.

Ziad

Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
atab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


___
Mailing list:https://launchpad.net/~openstack
Post to :openstack@lists.launchpad.net
Unsubscribe :https://launchpad.net/~openstack
More help   :https://help.launchpad.net/ListHelp



--
James Weir
Chief Technology Officer
james.w...@usharesoft.com
Linkedin:http://www.linkedin.com/in/jamesweir
Tel: +3

[Openstack] Access to OpenStack cluster for Scalr and rest of the community

[Sebastian Stadil]

Fellow Cloudsters, good morning!

Is there anyone in the community that could lend us access to an OpenStack
cluster we could use to start supporting it in Scalr? We've asked many
times, but every request has fizzled out, so we're reaching out with the
mailing list this time.

Our requirements are minimal, we just need to spin up 2-3 small instances a
couple times a day for maybe 2 weeks.

A community cluster would be welcome too, but I think we're a long way to
having one.

Cheers,
Sebastian
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Getting pagination right

[Jay Pipes]

On Thu, May 26, 2011 at 9:56 AM, Michael Barton
 wrote:
> On Wed, May 25, 2011 at 2:40 PM, Jay Pipes  wrote:
>
>> The pagination in Swift is not consistent. Inserts into the Swift
>> databases in between the time of the initial query and the requesting
>> the "next page" can result in rows from the original first page
>> getting on the new second page.
>
> No, you only get records not on the first page, because you're sending
> a marker of the last item from the first page.  Though even if that
> were the case, I wouldn't do very much work to try and provide some
> sort of point-in-time consistent view of the database for pagination.

Pagination after the page you are on is not consistent. Meaning, if I
do a query, go to page 2, I can refresh and the contents of the page
may change. That is not a consistent view of data, and that's what I
was referring to. Sorry if that was confusing...

>> On Wed, May 25, 2011 at 3:32 PM, Greg Holt  wrote:
>>> select w from x where y > marker order by y limit z
>
>> LIMIT X OFFSET Y clause. Your query above would return ALL the rows
>> that match WHERE y > marker. That's not what we want. We want a
>> segment of those rows.
>
> He had a limit clause in there.
>
> The reason we usually shy from offsets is they don't scale.  I don't
> know what cardinality you're expecting on these tables, but if you're
> querying for an offset of a million, offset's gotta go count a million
> records before it can return any results.  For a marker query, it can
> just do an index lookup.

Sure, I'll grant you that. Not disagreeing with you on the scalability
issues around OFFSET (at least as implemented in most RDBMS).

My point was about consistent view of data sets and ensuring that page
X of a result set doesn't change over time.

But, it sounds like folks aren't really concerned about the
consistency of the view as much as the scalability concerns, and I'm
perfectly cool with ditching OFFSET in favour of a last-record marker.

-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Keystone Release #1 - seeking community input

[Ziad Sawalha]

Agreed. We could create a list of potential standards, protocols, and 
integration work and maintain it in the README file. I'll get that in…


From: James Weir mailto:james.w...@usharesoft.com>>
Date: Fri, 27 May 2011 10:24:36 +0200
To: Ziad Sawalha mailto:ziad.sawa...@rackspace.com>>
Cc: "openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] Keystone Release #1 - seeking community input

Hi,

Completely agree with your last statement,but always good to know what other 
people are doing around identity (albiet web identity in this case).
I am not the best person to run with that integration, however, I know the guy 
that would be.  I will reach out to him to see if that would be an interesting 
side project.

Cheers
James


On 5/26/11 4:22 PM, Ziad Sawalha wrote:
Hi James – this is interesting work. Desire to incorporate it into Keystone 
will increase when and if it gains traction. Either way, if this is something 
someone (you?) wants to implement as a keystone plug-in, that's why we made it 
pluggable.

Reconfirming also that we're specifically not trying to solve identity (or web 
identity) with Keystone. We're focused on providing a framework for integrating 
any existing standard (or custom) identity solution into OpenStack.

Thanks for the link.

Z

From: James Weir mailto:james.w...@usharesoft.com>>
Date: Thu, 26 May 2011 09:52:54 +0200
To: Ziad Sawalha mailto:ziad.sawa...@rackspace.com>>
Cc: "openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] Keystone Release #1 - seeking community input

Hi,

Unsure if this is interesting also to consider under the keystone project:

http://www.w3.org/wiki/Foaf+ssl

This is more for social web, but might be interesting for user authentication.

Regards
James


On 5/26/11 9:04 AM, Ziad Sawalha wrote:
Hi Everyone!

It's been a while since the summit in Santa Clara. It was great meeting with 
everyone who was there – looking forward to the next one!

Since the summit, we've been working on Keystone and figuring out how to 
integrate it into OpenStack (Nova, Swift, Glance, and the dashboard). There has 
been much activity on the project. The code, design, and API has been changing 
daily. Anyone interested, please join us.

RELEASE 1
Milestone 1 for Diablo is right around the corner already! The goal remains to 
create a common auth system supporting existing use cases. There are a couple 
of proposals we'd like community input on before we get too far into the 
implementation:

  1.  API spec
  2.  Scope of first release

API Spec
We've published an API spec doc which we've been altering as requests come in 
for changes. The spec includes proposals for a core API that covers:

  *   tokens: for authentication
  *   tenants: for isolating and grouping resources to support multi-tenancy
  *   users: because we have to!
  *   roles: to support the Nova roles (see 
http://nova.openstack.org/runnova/managing.users.html for roles and users)
  *   credentials: to address the EC2, Rackspace auth, multiple-credentials 
question

The draft spec is on github and includes both the core APIs and additional 
extensions needed to make Keystone function as a stand-alone system. We'd like 
to lock it down as soon as is feasible. R1 is too close (June 2nd) so we 
probably won't be done by then, but aiming for Friday June 10th gives us a good 
couple of weeks to get there and then a couple of weeks to firm up 
implementation and tests, so we should be able to hit R2 with a locked down API.


Scope of R1
For the first Diablo milestone, we're aiming to support the user stories listed 
in http://wiki.openstack.org/KeystoneR1


ANNOUNCEMENTS

Repo
We're moving the source to the Rackspace repo (mainly because we can add 
multiple admins). Please start using the new repo. I will keep both in sync for 
a while.

https://github.com/rackspace/keystone/

I was able to change my config with those commands:
git remote rm origin
git remote add origin -m master -t master 
https://your-lo...@github.com/rackspace/keystone.git

As you open new issues, please use the Rackspace repo.

Participate
If you're interested in joining the team and working on Keystone, we'd love the 
input and help. Just let me know. And, of course, anyone is welcome to submit 
code, blueprints, issues, etc…

Looking forward to hearing from ya'll.

Ziad


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com

[Openstack] Fwd: help wanted: porting sqlalchemy-migrate for SQLAlchemy 0.7 and sqlalchemy-migrate maintenance

[Jay Pipes]

FYI, this has implications for both Nova and Glance.

Our relevant bug on Launchpad for this is here:

https://bugs.launchpad.net/glance/+bug/787296

Ta,
-jay


-- Forwarded message --
From: Jan Dittberner 
Date: Thu, May 26, 2011 at 11:41 AM
Subject: help wanted: porting sqlalchemy-migrate for SQLAlchemy 0.7
and sqlalchemy-migrate maintenance
To: sqlalch...@googlegroups.com
Cc: migrate-us...@googlegroups.com, migrate-annou...@googlegroups.com


Hello,

I work on making sqlalchemy-migrate [1] work with SQLAlchemy 0.7. I
fixed all broken unit tests except for one related to adding a new
column with a foreign key to an existing table. We have a continues
integration system (Jenkins CI) at [2] that provides the output of the
failing test. The problem is with some changed behaviour of the
SchemaVisitor API (or the Column objects). Until SQLAlchemy 0.6 it was
possible to get the constraints object for the ForeignKey arguments of
a column. The test at [3] creates a new Column instance and adds it to
the table. Afterwards our ANSIColumnGenerator [4] is triggered to
generate the necessary SQL statements. Until SQLAlchemy 0.6 the code
for generating the foreign key constraints could be generated properly
but now the constraint is None instead of a ForeignKeyConstraint. I
tried to just ignore fk.constraint if it is None, which expectedly did
not generate a statement. I also tried to construct a
ForeignKeyConstraint instance and pass that to the AddConstraint
constructor. This approach added a second ForeignKey instance to the
Column which is not desired too.

Can you please give me hints in the right direction or provide help to
fix this issue?

We would also like to invite interested developers to join the
sqlalchemy-migrate project because it has no maintainers with enough
time to keep it in a good shape. I think it would be great if the test
coverage and code quality would be improved but neither me nor the
other current maintainers have enough time to do these necessary
prerequisites. We have a quite long list of outstanding issues [5]
that need some triaging and fixes and should give a good start for
interested developers.

[1] http://code.google.com/p/sqlalchemy-migrate/
[2] http://jenkins.gnuviech-server.de/job/sqlalchemy-migrate-all/
[3] http://code.google.com/p/sqlalchemy-migrate/source/browse/migrate/tests/changeset/test_changeset.py#160
[4] http://code.google.com/p/sqlalchemy-migrate/source/browse/migrate/changeset/ansisql.py#87
[5] http://code.google.com/p/sqlalchemy-migrate/issues/list


Regards
Jan Dittberner

--
You received this message because you are subscribed to the Google
Groups "migrate-users" group.
To post to this group, send email to migrate-us...@googlegroups.com.
To unsubscribe from this group, send email to
migrate-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/migrate-users?hl=en.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Getting pagination right

[Thorsten von Eicken]

On 5/27/2011 6:05 AM, Jay Pipes wrote:
>
> But, it sounds like folks aren't really concerned about the
> consistency of the view as much as the scalability concerns, and I'm
> perfectly cool with ditching OFFSET in favour of a last-record marker.
>
THere's consistency and consistency. We need some form of consistency
and thus prefer no pagination, and marker-based pagination over
offset-based. Specifically, when iterating through all pages all items
in the collection must be returned, or said differently, the pagination
must ensure that no items get dropped because they moved from one page
to another while the iteration was happening. Marker-based pagination
achieves that. We don't need point-in-time consistency while iterating
through pages.
Thanks!
Thorsten - CTO RightScale

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Getting pagination right

[Jay Pipes]

On Fri, May 27, 2011 at 10:45 AM, Thorsten von Eicken
 wrote:
> On 5/27/2011 6:05 AM, Jay Pipes wrote:
>>
>> But, it sounds like folks aren't really concerned about the
>> consistency of the view as much as the scalability concerns, and I'm
>> perfectly cool with ditching OFFSET in favour of a last-record marker.
>>
> THere's consistency and consistency. We need some form of consistency
> and thus prefer no pagination, and marker-based pagination over
> offset-based. Specifically, when iterating through all pages all items
> in the collection must be returned, or said differently, the pagination
> must ensure that no items get dropped because they moved from one page
> to another while the iteration was happening. Marker-based pagination
> achieves that. We don't need point-in-time consistency while iterating
> through pages.

Fair enough.

-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Welcome Belinda Lopez, OpenStack Training Manager

[Anne Gentle]

Hi all -
I have been meaning to introduce you to Belinda Lopez, our OpenStack
training manager here at Rackspace. She has a strong technical writing
background and will be developing training curriculum, managing classes, and
creating a certification program for OpenStack in collaboration with you
all. It's a tall order but since she has experience with Ubuntu cloud
training and training trainers at NASA I think she'll sort it out. :) I
believe Belinda's even going to start an OpenStack glossary so I know we've
hired the right person. Tenants and accounts and users, oh my.

Belinda works out of her home near Galveston, Texas, but will be coming to
various locations, rolling out training programs and working with trainers. You
may have had a chance to meet her in person at the Design Summit, but I also
wanted to be sure to e-introduce her to the list. We welcome her warmly!

Thanks,
Anne
*Anne Gentle*
a...@openstack.org
 my blog  | my
book|
LinkedIn  |
Delicious|
Twitter 
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Welcome Belinda Lopez, OpenStack Training Manager

[Jay Pipes]

On Fri, May 27, 2011 at 11:10 AM, Anne Gentle  wrote:
> Hi all -
> I have been meaning to introduce you to Belinda Lopez, our OpenStack
> training manager here at Rackspace. She has a strong technical writing
> background and will be developing training curriculum, managing classes, and
> creating a certification program for OpenStack in collaboration with you
> all. It's a tall order but since she has experience with Ubuntu cloud
> training and training trainers at NASA I think she'll sort it out. :)

Welcome to you, Belinda! Glad to have you on the team. :)

> I believe Belinda's even going to start an OpenStack glossary so I know we've
> hired the right person.

I suggest the first word in the glossary be "metadata". Good luck! ;)

-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Conclusion on Pagination (hopefully!) :)

[Jay Pipes]

Thanks all for some awesome input on the pagination thread. I wanted
to summarize what I think were the conclusions to come out of it.
Please do let me know if I got it right.

Proposal:

1) Push the LIMIT variable into the database API layer
2) Ensure that all queries that return a set of results have an ORDER
BY expression to them
3) Push the marker into the database API layer. Continue to have the
marker variable be a value of a unique key (primary key for now at
least). Use a WHERE field > $marker LIMIT $pagesize construct.

I *think* this is what's agreed upon? It's basically the Swift model
with a variation that the order of results is not static (it can be
specified by the user).

Please ++ if that looks good and I'll draw up a blueprint

Thanks!
jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Openstack swift SAIO script with IPv6 support

[Marcelo Martis]

Morning,

If anyone is interested in checking this out and have any thoughts. I 
have created this swift SAIO setup script a few weeks back and I'm 
trying to improve it as much as I can when time allows. I have recently 
added ipv6 support to it, which means I can setup an openstack-swift 
SAIO vm/slice on full ipv6 (global or ula addresses).


So far I have only tested/developed the script with Ubuntu 10.04 but it 
should be ok on 10.10 I believe


https://github.com/btorch/swift-saio.sh


Marcelo Martins
Openstack-swift
btorch...@zeroaccess.org 
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Welcome Belinda Lopez, OpenStack Training Manager

[Ed Leafe]

On May 27, 2011, at 11:55 AM, Jay Pipes wrote:

>> I believe Belinda's even going to start an OpenStack glossary so I know we've
>> hired the right person.
> 
> I suggest the first word in the glossary be "metadata". Good luck! ;)


Ooohh.. that's mean!


-- Ed Leafe



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace. 
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message. 
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Starting an OpenStack web/docs meeting

[Anne Gentle]

Hi all -

Great refresh on both the openstack.org site by Todd Morey (wow, that was a
ton of work) and the front page of the wiki by Thierry. Way to go!

I'm looking at all our web properties all the time and I am inspired to
start holding monthly meetings to gather contributors together, share
information, and to help people get to know the process around each web
site. From the main site to the wiki to each RST site to the docs site, they
all serve a common purpose and we want to make them helpful and useful and
awesome.

We'll use IRC and the meeting bot and the openstack-meeting channel to hold
these meetings. Now, to find a good time. Since we have contributors around
the world and I'd like to report to the dev meetings
on Tuesdays, I'd like to propose that we start with the first Monday of the
month, June 6, 2011 at 9:00 pm CST Monday evening (02:00
UTC).
We'll just meet monthly at first and adjust as needed.

As a side note, I'm getting ready for the Open Help Conference in Cincinnati
June 3-5. If ever a conference was finely tuned to my needs, this one is it,
with talks about open source docs, open source support, and open source
certification programs all on the list. :)

Hope to see you in #openstack-meeting for our first meeting.

Thanks,

Anne
*Anne Gentle*
a...@openstack.org
 my blog  | my
book|
LinkedIn  |
Delicious|
Twitter 
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Starting an OpenStack web/docs meeting

[Joshua McKenty]

Is there somewhere you could add an iCal feed of these meetings? (meetup.com or 
your own google account would work). I love me some iCal.

Joshua McKenty
Piston Cloud Computing, Inc.
(650) 283-6846
jos...@piston.cc



On 2011-05-27, at 9:29 AM, Anne Gentle wrote:

> Hi all -
> 
> Great refresh on both the openstack.org site by Todd Morey (wow, that was a 
> ton of work) and the front page of the wiki by Thierry. Way to go! 
> 
> I'm looking at all our web properties all the time and I am inspired to start 
> holding monthly meetings to gather contributors together, share information, 
> and to help people get to know the process around each web site. From the 
> main site to the wiki to each RST site to the docs site, they all serve a 
> common purpose and we want to make them helpful and useful and awesome.
> 
> We'll use IRC and the meeting bot and the openstack-meeting channel to hold 
> these meetings. Now, to find a good time. Since we have contributors around 
> the world and I'd like to report to the dev meetings
> on Tuesdays, I'd like to propose that we start with the first Monday of the 
> month, June 6, 2011 at 9:00 pm CST Monday evening (02:00 UTC). We'll just 
> meet monthly at first and adjust as needed.
> 
> As a side note, I'm getting ready for the Open Help Conference in Cincinnati 
> June 3-5. If ever a conference was finely tuned to my needs, this one is it, 
> with talks about open source docs, open source support, and open source 
> certification programs all on the list. :)
> 
> Hope to see you in #openstack-meeting for our first meeting. 
> 
> Thanks,
> 
> Anne
> Anne Gentle 
> a...@openstack.org
> my blog | my book | LinkedIn | Delicious | Twitter
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Standardizing resource IDs on UUID?

[Erik Carlin]

With the proliferation of new openstack services being built, is there any 
reason not to use UUID as the standard resource ID format?

Erik


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Conclusion on Pagination (hopefully!) :)

[Jorge Williams]

Jay,

+1 on this,  however, I would also add linking to the API layer -- as we do in 
compute 1.1. Links make it supper easy for language bindings to traverse pages 
-- especially in the case that Thorsten points to, where you want to traverse 
all items in the collection.  In this case, a client can keep following the 
next link until there aren't any. Links  are less error prone, and easier to 
use in that  they keep clients from having to mess with markers at all.  The 
href is based on a marker of course, but the client doesn't have to construct 
the URL. 

-jOrGe W.

On May 27, 2011, at 11:00 AM, Jay Pipes wrote:

> Thanks all for some awesome input on the pagination thread. I wanted
> to summarize what I think were the conclusions to come out of it.
> Please do let me know if I got it right.
> 
> Proposal:
> 
> 1) Push the LIMIT variable into the database API layer
> 2) Ensure that all queries that return a set of results have an ORDER
> BY expression to them
> 3) Push the marker into the database API layer. Continue to have the
> marker variable be a value of a unique key (primary key for now at
> least). Use a WHERE field > $marker LIMIT $pagesize construct.
> 
> I *think* this is what's agreed upon? It's basically the Swift model
> with a variation that the order of results is not static (it can be
> specified by the user).
> 
> Please ++ if that looks good and I'll draw up a blueprint
> 
> Thanks!
> jay
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Standardizing resource IDs on UUID?

[Ed Leafe]

On May 27, 2011, at 1:15 PM, Erik Carlin wrote:

> With the proliferation of new openstack services being built, is there any 
> reason not to use UUID as the standard resource ID format?

The consensus at the last summit was to move to UUIDs for instance IDs. 
The biggest concerns were that a) it breaks the current API (which can be 
updated), and it breaks the EC2 API (which can't be updated). I know that there 
were some ideas for working around the ec2 issues, but I don't remember them.

I think moving ahead, UUIDs scale way better than locally-generated 
sequential integers.



-- Ed Leafe




___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Standardizing resource IDs on UUID?

[Mark Washenberger]

+1 for UUIDs.

If we agree on this approach, there is some difficulty incorporating it into 
nova as Ed has identified. However, any other projects, especially those hoping 
to be adopted as Openstack projects by the PPB, can probably switch to this 
approach more immediately.

Just a thought.

"Ed Leafe"  said:

> On May 27, 2011, at 1:15 PM, Erik Carlin wrote:
> 
>> With the proliferation of new openstack services being built, is there any 
>> reason
>> not to use UUID as the standard resource ID format?
> 
>   The consensus at the last summit was to move to UUIDs for instance IDs. 
> The
> biggest concerns were that a) it breaks the current API (which can be 
> updated),
> and it breaks the EC2 API (which can't be updated). I know that there were 
> some
> ideas for working around the ec2 issues, but I don't remember them.
> 
>   I think moving ahead, UUIDs scale way better than locally-generated 
> sequential
> integers.
> 
> 
> 
> -- Ed Leafe
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Standardizing resource IDs on UUID?

[Vishvananda Ishaya]

+1

We have blueprints for migrating nova but it will take some time.

On May 27, 2011, at 1:02 PM, Mark Washenberger wrote:

> +1 for UUIDs.
> 
> If we agree on this approach, there is some difficulty incorporating it into 
> nova as Ed has identified. However, any other projects, especially those 
> hoping to be adopted as Openstack projects by the PPB, can probably switch to 
> this approach more immediately.
> 
> Just a thought.
> 
> "Ed Leafe"  said:
> 
>> On May 27, 2011, at 1:15 PM, Erik Carlin wrote:
>> 
>>> With the proliferation of new openstack services being built, is there any 
>>> reason
>>> not to use UUID as the standard resource ID format?
>> 
>>  The consensus at the last summit was to move to UUIDs for instance IDs. 
>> The
>> biggest concerns were that a) it breaks the current API (which can be 
>> updated),
>> and it breaks the EC2 API (which can't be updated). I know that there were 
>> some
>> ideas for working around the ec2 issues, but I don't remember them.
>> 
>>  I think moving ahead, UUIDs scale way better than locally-generated 
>> sequential
>> integers.
>> 
>> 
>> 
>> -- Ed Leafe
>> 
>> 
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] bexar swift socket issue?

[Jon Slenk]

hi,

has anybody else (i've been searching but haven't yet precisely hit
pay-dirt) seen socket hangups with wsgi-related socket/worker code?
this is bexar swift.

thanks :)

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] DRBD storage for Openstack installations

[Nelson Nahum]

At Zadara Storage, we are working on a block storage system for the cloud.
We didn't published much info yet but if somebody is interested I will be
happy to be in a call and explain what we are doing.

Nelson Nahum
CTO
nel...@zadarastorage.com


2011/5/27 Oleg Gelbukh 

> Hi
> Our approach was defined by need to combine storage and compute on the same
> hosts.
> Our configuration is dual-primary, so we can run nova-compute and virtual
> servers on both nodes and have them with write access to volumes. DRBD
> allows this mode out-of-box now, but it requires clustered file system or
> great caution when runnning LVM on it.
> But nova-volume must run on one node of drbd-connected pair, while the
> second gets copy of lvm data via drbd. The tricky part is that it seems we
> must activate volumes and volume groups on the peer node, but automation of
> this is relatively easy.
> For now, we are not going to share volumes outside of drbd-peers pair for
> live migration or as attachable volumes, except some special cases like
> migrating VMs between drbd pairs.
> Looking forward to read couple of words on your approach.
>
> 2011/5/26 Diego Parrilla Santamaría 
>
>> Hi Oleg,
>>
>> thank you very much for your post, it's really didactic. We are taking a
>> different approach for HA at storage level, but I have worked formerly with
>> DRBD and I think it's a very good choice.
>>
>> I'm curious about how you have deployed nova-volume nodes in your
>> architecture. You don't specify if the two nodes of the DRBD cluster run one
>> or two instances of nova-volume. If you run one instance probably you have
>> implemented some kind of fault-tolerant active-passive service if the
>> nova-volume process fails in the active node, but I would like to know if
>> you can run an active-active two nova-volume instances on two different
>> physical nodes on top of the DRBD shared resource.
>>
>> Regards
>> Diego
>>
>> --
>> Diego Parrilla
>> *CEO*
>> *www.stackops.com | * diego.parri...@stackops.com** | +34 649 94 43 29 |
>> skype:diegoparrilla*
>> * 
>>
>>
>>
>> On Thu, May 26, 2011 at 1:29 PM, Oleg Gelbukh wrote:
>>
>>> Hi,
>>> We were researching Openstack for our private cloud, and want to share
>>> experience and get tips from community as we go on.
>>>
>>> We have settled on DRBD as shared storage platform for our installation.
>>> LVM is used over the drbd device to mange logical volumes. OCFS2 file system
>>> is created on one of volumes, mounted and set up as *image_path* and *
>>> instance_path* in the *nova.conf*, other space is reserved for storage
>>> volumes (managed by nova-volume).
>>>
>>> As a result, we have shared storage suitable for features such as live
>>> migration and snapshots. We also have some level of fault-tolerance, with
>>> DRBD I/O error handling, which automatically redirects I/O requests to peer
>>> node over network in case of primary node failure. We created 
>>> scriptfor
>>>  bootstrapping lost VMs in two crash scenarios:
>>> * dom0 host restart/domU failure: restore VMs on the same host
>>> * dom0 host failure: restore VMs on peer node
>>> We are considering such pair of servers with shared storage as a basic
>>> block for the cloud structure.
>>>
>>> For whom it may interest, the details of DRBD installation are 
>>> here.
>>> I'll be glad to answer any questions and highly appreciate feedback on this.
>>>
>>> Oleg S. Gelbukh,
>>> Mirantis Inc.
>>> www.mirantis.com
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Proposal for Dashboard as an official OpenStack project

[Devin Carlen]

Thanks Thierry and Josh.  I added it to the agenda for the next PPB meeting.


Devin




On May 27, 2011, at 12:32 AM, Thierry Carrez wrote:

> Devin Carlen wrote:
>> I believe the time is right to make the dashboard an official OpenStack 
>> project.
>> 
>> To my knowledge, no other projects have gone through the incubation process 
>> to become an official project, so in some ways we are in uncharted territory.
>> 
>> Is there an officially documented process to make this happen?  
> 
> It needs to be proposed to the PPB for acceptance. Please put it on the
> meeting agenda at [1].
> 
> [1] http://wiki.openstack.org/Governance/PPB
> 
> Note that the PPB still needs to finalize the evolution of its current
> "Project addition" process [2] to accommodate the new
> Core/Incubation/Related project types [3] with clear process to move
> from one to another.
> 
> [2] http://wiki.openstack.org/Governance/Approved/NewProjectProcess
> [3] http://wiki.openstack.org/ProjectTypes
> 
> Maybe we can do everything in one meeting :)
> 
> -- 
> Thierry Carrez (ttx)
> Release Manager, OpenStack
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Conclusion on Pagination (hopefully!) :)

[Devin Carlen]

++  That's the right approach!


On May 27, 2011, at 9:00 AM, Jay Pipes wrote:

> Thanks all for some awesome input on the pagination thread. I wanted
> to summarize what I think were the conclusions to come out of it.
> Please do let me know if I got it right.
> 
> Proposal:
> 
> 1) Push the LIMIT variable into the database API layer
> 2) Ensure that all queries that return a set of results have an ORDER
> BY expression to them
> 3) Push the marker into the database API layer. Continue to have the
> marker variable be a value of a unique key (primary key for now at
> least). Use a WHERE field > $marker LIMIT $pagesize construct.
> 
> I *think* this is what's agreed upon? It's basically the Swift model
> with a variation that the order of results is not static (it can be
> specified by the user).
> 
> Please ++ if that looks good and I'll draw up a blueprint
> 
> Thanks!
> jay
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Standardizing resource IDs on UUID?

[Jay Pipes]

I think Erik's looking for a timeframe for this, too.

We could implement this tomorrow in Glance, but there's been a
conscience decision to use URIs as an image's globally-unique
identifier, and to allow Glance registries to implement whatever image
ID they wanted. This can, of course, change, but would break on
existing Glance installations. The same would be true of Nova, of
course. Old instances would need to be migrated to the new key as
well.

In Nova, I would say the following must all occur:

1) Change the ID in the model from autoinc keys to string/text UUIDs
2) Remove the current logic in various places that looks for integer keys
3) Add a field to the necessary tables for storing the EC2 ID (internal_id?)
4) Update all the test cases to use non-integer keys (PITA)
5) Test, test, test

-jay

On Fri, May 27, 2011 at 4:05 PM, Vishvananda Ishaya
 wrote:
> +1
>
> We have blueprints for migrating nova but it will take some time.
>
> On May 27, 2011, at 1:02 PM, Mark Washenberger wrote:
>
>> +1 for UUIDs.
>>
>> If we agree on this approach, there is some difficulty incorporating it into 
>> nova as Ed has identified. However, any other projects, especially those 
>> hoping to be adopted as Openstack projects by the PPB, can probably switch 
>> to this approach more immediately.
>>
>> Just a thought.
>>
>> "Ed Leafe"  said:
>>
>>> On May 27, 2011, at 1:15 PM, Erik Carlin wrote:
>>>
 With the proliferation of new openstack services being built, is there any 
 reason
 not to use UUID as the standard resource ID format?
>>>
>>>      The consensus at the last summit was to move to UUIDs for instance 
>>> IDs. The
>>> biggest concerns were that a) it breaks the current API (which can be 
>>> updated),
>>> and it breaks the EC2 API (which can't be updated). I know that there were 
>>> some
>>> ideas for working around the ec2 issues, but I don't remember them.
>>>
>>>      I think moving ahead, UUIDs scale way better than locally-generated 
>>> sequential
>>> integers.
>>>
>>>
>>>
>>> -- Ed Leafe
>>>
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Proposal for Dashboard as an official OpenStack project

[Everett Toews]

+1

The end user experience in OpenStack would greatly benefit from having an
official web application that developers can focus their effort on.

Devin, if this process winds up involving a vote or if there's is any other
way we can support this, please let us know.

Thanks,
Everett

On Thu, May 26, 2011 at 2:05 PM, Devin Carlen wrote:

> Hello all,
>
> For quite a while now, the OpenStack Dashboard has existed as an incubation
> project.  There is quite a bit of development effort going into it now from
> a number of different companies.  Current projects underway include, but are
> not limited to:
>
>  * swift support
>  * internationalization
>  * a new theme
>  * OpenStack API support
>  * integration with Keystone project
>
> This project is quickly gaining contributors, and is in use by a large
> number of members of the community.
>
> I believe the time is right to make the dashboard an official OpenStack
> project.
>
> To my knowledge, no other projects have gone through the incubation process
> to become an official project, so in some ways we are in uncharted
> territory.
>
> Is there an officially documented process to make this happen?
>
>
> Devin
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Proposal for Dashboard as an official OpenStack project

[Lorin Hochstein]

+1

We're actively working with dashboard.

Lorin


- Original Message -
From: "Everett Toews" 
To: "Devin Carlen" 
Cc: openstack@lists.launchpad.net
Sent: Friday, May 27, 2011 5:43:32 PM
Subject: Re: [Openstack] Proposal for Dashboard as an official OpenStack
project


+1 


The end user experience in OpenStack would greatly benefit from having an 
official web application that developers can focus their effort on. 


Devin, if this process winds up involving a vote or if there's is any other way 
we can support this, please let us know. 


Thanks, 
Everett 


On Thu, May 26, 2011 at 2:05 PM, Devin Carlen < devin.car...@gmail.com > wrote: 


Hello all, 

For quite a while now, the OpenStack Dashboard has existed as an incubation 
project. There is quite a bit of development effort going into it now from a 
number of different companies. Current projects underway include, but are not 
limited to: 

* swift support 
* internationalization 
* a new theme 
* OpenStack API support 
* integration with Keystone project 

This project is quickly gaining contributors, and is in use by a large number 
of members of the community. 

I believe the time is right to make the dashboard an official OpenStack 
project. 

To my knowledge, no other projects have gone through the incubation process to 
become an official project, so in some ways we are in uncharted territory. 

Is there an officially documented process to make this happen? 


Devin 
___ 
Mailing list: https://launchpad.net/~openstack 
Post to : openstack@lists.launchpad.net 
Unsubscribe : https://launchpad.net/~openstack 
More help : https://help.launchpad.net/ListHelp 


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] bexar swift socket issue?

[Jon Slenk]

hi,

On Fri, May 27, 2011 at 1:18 PM, Jon Slenk  wrote:
> has anybody else (i've been searching but haven't yet precisely hit
> pay-dirt) seen socket hangups with wsgi-related socket/worker code?
> this is bexar swift.

In particular, has anybody seen issues / experimented with
swift/common/wsgi.py line 130 "eventlet.hubs.use_hub('poll')"? We
think we're seeing something akin to Java's notifyAll() bad behaviour,
increasing as more connections come in. Wondering if a different hub
like 'select' is known to help.

thanks.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Updating SystemUsageData blueprint w.r.t. accounts/tenants

[Jesse Andrews]

A few of us were looking at starting to implement
http://wiki.openstack.org/SystemUsageData, starting with updating the
spec to reflect plans related to unified auth (the keystone project).

In the blueprint, it was called out that data was to be aggregated by
Account ID - which it claimed is NOT the same as a project.

My understanding of how unified auth will work is:

   Nova will be sent a Tenant, User, Roles/Groups from the auth_token middleware

If this is so, accounts (things that bind many tenants together) would
exist outside of nova, so this level of aggregation (multiple tenants
into an account) would occur in an external billing system, not in
Nova.

I'd like to clarify this so I can update the blueprint.  (or
alternatively clarify how tenants/users and ... work)

Thanks,
Jesse

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Updating SystemUsageData blueprint w.r.t. accounts/tenants

[Ziad Sawalha]

Project is indeed the equivalent of tenant.

The multi-tenant-accounting blueprint says usage must be TAGGED with the
tenant so that an operator can map and aggregate usage as is appropriate
for their own business logic.

If we aggregate by tenant, we just need ton recognize that there may
eventually be a use case where an operator needs the data pre-aggregation.


On 5/27/11 6:46 PM, "Jesse Andrews"  wrote:

>A few of us were looking at starting to implement
>http://wiki.openstack.org/SystemUsageData, starting with updating the
>spec to reflect plans related to unified auth (the keystone project).
>
>In the blueprint, it was called out that data was to be aggregated by
>Account ID - which it claimed is NOT the same as a project.
>
>My understanding of how unified auth will work is:
>
>   Nova will be sent a Tenant, User, Roles/Groups from the auth_token
>middleware
>
>If this is so, accounts (things that bind many tenants together) would
>exist outside of nova, so this level of aggregation (multiple tenants
>into an account) would occur in an external billing system, not in
>Nova.
>
>I'd like to clarify this so I can update the blueprint.  (or
>alternatively clarify how tenants/users and ... work)
>
>Thanks,
>Jesse
>
>___
>Mailing list: https://launchpad.net/~openstack
>Post to : openstack@lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Feedback on HTTP APIs

[Mark Nottingham]

Hi,

I've started looking at the 1.1 API draft [1] and want to give some feedback. 
The draft says that feedback is welcome on the bug queue [2], but I suspect 
it'd be better to have a dialogue, at least initially. Should I file bugs, or 
discuss here?

I'm looking at it primarily from a HTTP standpoint, with an emphasis on 
interoperability. My background is from working on HTTP (I've contributed to 
several implementations and currently chair the IETF's HTTPbis Working Group), 
Atom (I was an editor of the Atom Syndication Format specification), and Web 
Services (for my sins, I was involved in SOAP, WS-Policy, WS-Addressing, WS-I, 
Web Services attachments and a fair number of other efforts in that glorious 
stuff-up).

Cheers,


1. 

 April 25, 2011 version
2. 

--
Mark Nottingham   http://www.mnot.net/




___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Feedback on HTTP APIs

[Jay Pipes]

On Fri, May 27, 2011 at 8:52 PM, Mark Nottingham  wrote:
> Hi,
>
> I've started looking at the 1.1 API draft [1] and want to give some feedback. 
> The draft says that feedback is welcome on the bug queue [2], but I suspect 
> it'd be better to have a dialogue, at least initially. Should I file bugs, or 
> discuss here?

Hi Mark! Welcome :)

Please feel free to get a conversation going here on the mailing list!
If action items come out of the conversation, we'll make bugs and
blueprints accordingly.

Cheers!
jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Feedback on HTTP APIs

[Jorge Williams]

Hi Mark,

I think that the most convenient place to leave comments is in the web help 
version:

http://docs.openstack.org/cactus/openstack-compute/developer/openstack-compute-api-1.1/content/index.html

If you scroll down you'll see there's a place for comments at the end of every 
page.

Looking forward to your comments,

-jOrGe W.

On May 27, 2011, at 7:52 PM, Mark Nottingham wrote:

> Hi,
> 
> I've started looking at the 1.1 API draft [1] and want to give some feedback. 
> The draft says that feedback is welcome on the bug queue [2], but I suspect 
> it'd be better to have a dialogue, at least initially. Should I file bugs, or 
> discuss here?
> 
> I'm looking at it primarily from a HTTP standpoint, with an emphasis on 
> interoperability. My background is from working on HTTP (I've contributed to 
> several implementations and currently chair the IETF's HTTPbis Working 
> Group), Atom (I was an editor of the Atom Syndication Format specification), 
> and Web Services (for my sins, I was involved in SOAP, WS-Policy, 
> WS-Addressing, WS-I, Web Services attachments and a fair number of other 
> efforts in that glorious stuff-up).
> 
> Cheers,
> 
> 
> 1. 
> 
>  April 25, 2011 version
> 2. 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp