[Openstack] OpenStack and OpenFlow

[Yoshisato Ushio]

Hello Folks,
I am interested in the use of OpenFlow technology with OpenStack. But
honestly speaking, I have no deep expertise in OpenStack.Then let me ask
questions.

Q1) In order to use openflow features with OpenStack, such as, Open vSwitch
or OpenFlow capable HW switches, can I assume that all I should do for this
is to develop a quantum plugin module for openflow under nova manager ?
Q2) Are there any open-source codes of quantum plugin for openflow ?

Any advice would be greatly appreciated,
Yoshisato Ushio
___
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] [Nova] [Keystone] Nova projects (Diablo)

[Akira Yoshiyama]

Hi Vish,

I just uploaded s3_token patches for swift and keystone to:

http://www.debian.or.jp/~yosshy/openstack-diablo

We have nova/glance/swift/keystone cluster with s3_token and patched
ec2_token for keystone.
We can upload image files, register them and run instances on them with
Euca2ools as usual.

Regards,
Akira Yoshiyama
2011/10/29 6:50 "Vishvananda Ishaya" :

> This is correct  Unfortunately, you won't be able to use euca-upload-bundle
> properly.  I am trying to figure out a way to allow euca-upload-bundle to
> work, but for now it will only work with deprecated auth.
>
> Devstack shows how you can create users, tenants, roles and credentials in
> keystone that you can then use through the ec2 api.
>
> Vish
>
> On Oct 28, 2011, at 1:49 PM, Nguyen, Liem Manh wrote:
>
> Thanks, Heck…  So, to use Nova with keystone, it appears that I do not need
> to create Nova projects anymore.  So, is there any other configuration I
> should do to use the euc* tools with Keystone?
> ** **
> Liem
> ** **
> *From:* Joseph Heck [mailto:he...@me.com]
> *Sent:* Friday, October 28, 2011 1:18 PM
> *To:* Nguyen, Liem Manh
> *Cc:* openstack@lists.launchpad.net
> *Subject:* Re: [Openstack] [Nova] [Keystone] Nova projects (Diablo)
> ** **
> Liem,
> ** **
> There's some newer documentation that we just created at
> keystone.openstack.org related to setting up and configuring Keystone.
> Look into the page at http://keystone.openstack.org/configuring.html,
> which also has detail on how to configure Nova to work with Keystone.
> ** **
> -joe
> ** **
> On Oct 28, 2011, at 10:50 AM, Nguyen, Liem Manh wrote:
>
>
> 
> Hi Stackers,
>  
> For the Diablo release, I would like to use Keystone as the auth
> component…   Do I still need to use lazy provisioning (nova_auth_token.py)
> in my pipeline to provision Nova projects (i.e., is Nova project creating
> still required)?  Also, is there an example of how the novarc should be
> configured for Keystone?
>  
> Thanks,
> Liem
>  
> ___
> 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] proliferation of websites (was Re: [Nova] [Keystone] Nova projects (Diablo))

[Anne Gentle]

Stef and others - the audience determines which website serves them best. Sites 
with projectname.openstack.org are specifically for Python devs who need to get 
a dev environment going. 

The site segmentation is described on wiki.openstack.org/Documentation/HowTo.

Anne Gentle
Content Stacker
a...@openstack.org


On Oct 28, 2011, at 6:26 PM, Jay Pipes  wrote:

> On Fri, Oct 28, 2011 at 7:18 PM, Stefano Maffulli  
> wrote:
>> On Fri, 2011-10-28 at 13:17 -0700, Joseph Heck wrote:
>>> There's some newer documentation that we just created at
>>> keystone.openstack.org related to setting up and configuring Keystone.
>>> Look into the page at http://keystone.openstack.org/configuring.html,
>>> which also has detail on how to configure Nova to work with Keystone.
>> 
>> Creating more websites can lead to lots of confusion for OpenStack as a
>> project down the road. I have received lots of comments from users and
>> new partners that the first approach to the project in general is
>> frightening. We should try to keep documents, recipes, etc in few places
>> where google can find them.
>> 
>> what's the rationale for putting this documentation on
>> keystone.openstack.org instead of reusing one of the other sites we
>> already have, like openstack.org/wiki?
> 
> Hey Stef,
> 
> All the core projects have developer-specific docs at
> http://$PROJECT.openstack.org.
> 
> 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

___
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] proliferation of websites (was Re: [Nova] [Keystone] Nova projects (Diablo))

[Joseph Heck]

Stef - 

As Jay mentioned, I was following the pattern that the core projects already 
had in place. 

The documentation embedded in the project (which is specifically aimed at 
contributors) is in this setup. I haven't yet updated the docbook pieces (which 
become docs.openstack.org HTML & PDF) because I'm waiting for feedback from the 
Keystone team on some questions based on what I wrote for internal consumption.

-joe

On Oct 28, 2011, at 4:26 PM, Jay Pipes wrote:
> On Fri, Oct 28, 2011 at 7:18 PM, Stefano Maffulli  
> wrote:
>> On Fri, 2011-10-28 at 13:17 -0700, Joseph Heck wrote:
>>> There's some newer documentation that we just created at
>>> keystone.openstack.org related to setting up and configuring Keystone.
>>> Look into the page at http://keystone.openstack.org/configuring.html,
>>> which also has detail on how to configure Nova to work with Keystone.
>> 
>> Creating more websites can lead to lots of confusion for OpenStack as a
>> project down the road. I have received lots of comments from users and
>> new partners that the first approach to the project in general is
>> frightening. We should try to keep documents, recipes, etc in few places
>> where google can find them.
>> 
>> what's the rationale for putting this documentation on
>> keystone.openstack.org instead of reusing one of the other sites we
>> already have, like openstack.org/wiki?
> 
> Hey Stef,
> 
> All the core projects have developer-specific docs at
> http://$PROJECT.openstack.org.
> 
> 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


___
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] proliferation of websites (was Re: [Nova] [Keystone] Nova projects (Diablo))

[Stefano Maffulli]

On Fri, 2011-10-28 at 19:26 -0400, Jay Pipes wrote:
> All the core projects have developer-specific docs at
> http://$PROJECT.openstack.org. 

got it. I still wonder whether we should find a better home for these
docs and include them in a more visible path. 

For example, if it was under docs.openstack.org/developer/$PROJECT and
formatted to include the top navigation bar (Home | Project |
Community...) I think it would help.

How hard would it be to achieve?

/stef


___
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] proliferation of websites (was Re: [Nova] [Keystone] Nova projects (Diablo))

[Joseph Heck]

I like the idea - but I don't know what it would take to create it. I don't 
think openstack.org or docs.openstack.org content sites are managed in a repo. 
I believe I heard that Todd Morey was managing those sites, but I might be 
wrong.

-joe

On Oct 28, 2011, at 4:38 PM, Stefano Maffulli wrote:
> On Fri, 2011-10-28 at 19:26 -0400, Jay Pipes wrote:
>> All the core projects have developer-specific docs at
>> http://$PROJECT.openstack.org. 
> 
> got it. I still wonder whether we should find a better home for these
> docs and include them in a more visible path. 
> 
> For example, if it was under docs.openstack.org/developer/$PROJECT and
> formatted to include the top navigation bar (Home | Project |
> Community...) I think it would help.
> 
> How hard would it be to achieve?
> 
> /stef
> 
> 
> ___
> 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] proliferation of websites (was Re: [Nova] [Keystone] Nova projects (Diablo))

[Stefano Maffulli]

On Fri, 2011-10-28 at 13:17 -0700, Joseph Heck wrote:
> There's some newer documentation that we just created at
> keystone.openstack.org related to setting up and configuring Keystone.
> Look into the page at http://keystone.openstack.org/configuring.html,
> which also has detail on how to configure Nova to work with Keystone.

Creating more websites can lead to lots of confusion for OpenStack as a
project down the road. I have received lots of comments from users and
new partners that the first approach to the project in general is
frightening. We should try to keep documents, recipes, etc in few places
where google can find them.

what's the rationale for putting this documentation on
keystone.openstack.org instead of reusing one of the other sites we
already have, like openstack.org/wiki?

/stef



___
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] proliferation of websites (was Re: [Nova] [Keystone] Nova projects (Diablo))

[Jay Pipes]

On Fri, Oct 28, 2011 at 7:18 PM, Stefano Maffulli  wrote:
> On Fri, 2011-10-28 at 13:17 -0700, Joseph Heck wrote:
>> There's some newer documentation that we just created at
>> keystone.openstack.org related to setting up and configuring Keystone.
>> Look into the page at http://keystone.openstack.org/configuring.html,
>> which also has detail on how to configure Nova to work with Keystone.
>
> Creating more websites can lead to lots of confusion for OpenStack as a
> project down the road. I have received lots of comments from users and
> new partners that the first approach to the project in general is
> frightening. We should try to keep documents, recipes, etc in few places
> where google can find them.
>
> what's the rationale for putting this documentation on
> keystone.openstack.org instead of reusing one of the other sites we
> already have, like openstack.org/wiki?

Hey Stef,

All the core projects have developer-specific docs at
http://$PROJECT.openstack.org.

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] Push vs Polling (from Versioning Thread)

[Monsyne Dragon]

On Oct 27, 2011, at 10:20 PM, Bryan Taylor wrote:

> Just to be clear we are talking about APIs fit for customer consumption here, 
> not internal integrations where both ends are under our control.
> 
> On 10/27/2011 11:38 AM, George Reese wrote:
>>> I disagree. The web was designed specifically to solve the distributed 
>>> scaling problem and it's based on HTTP polling. It scales pretty well. The 
>>> argument against polling not scaling inevitably neglects using caching 
>>> properly.
>> The web was not designed to deal with a bunch of clients needing to
>> know about infrastructure changes the instant they happen.
> Neither physics nor math were designed for that either. The CAP theorem 
> simply doesn't allow a distributed system with an uptime guarantee to 
> communicate changes "the instant they happen". Once you realize the best your 
> clients can hope for is eventual consistency, the sooner you'll realize that 
> polling is just fine.

In theory, your theory describes the situation . In practice it's different. 
:-> 
Yes, clients cant get truly instant notifications. What they can get is ASAP 
notifications. Which is what they really need/want in some situations.

Now, this could be implemented by polling some sort of "changes since: X"  
resource, as in the Fielding article, or it could be done via a push system.  
Which one is appropriate depends on the relative importance of a number of 
things like acceptable latency of notifications since the event, frequency of 
notifications, requited reliability, etc to the client, and the relative cost 
of retrieving certain information to the serving system. 

In the case of Nova, we have use cases for both methods.

> BTW, here's Roy Fielding's article on this subject of poll vs push.
> http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons
>> And API data should not be cached. The Rackspace API used to do that,
>> and it created a mess.
> I'm not sure what you are referring to, but this is a classic strawman. 
> Somebody implemented a "mess" using caching, so caching is bad!? You didn't 
> say what the mess was, so there's no way to even evaluate your statement.
>>> Push doesn't scaled because it requires the server to know about every 
>>> client and track conversational state with them.
>> No, it doesn't. You push changes as they occur to a message queue. A
>> separate system tracks subscribers and sends them out. There is no
>> conversational state if done right.
> 
> A "separate" system? That's why you think it's simple -- you push the hard 
> part outside of your box and claim victory. It's not a separate system, it's 
> all one big cloud. If there are N interested clients the process you 
> described requires O(N) resources. Moving it to another tier means it's 
> somebody else's O(N) resources. You are illustrating Fielding's point in the 
> article above: "People need to understand that general-purpose PubSub is not 
> a solution to scalability problems — it simply moves the problem somewhere 
> else, and usually to a place that is inversely supported by the economics. "
> 
> How exactly does this separate system know where to "send them out" to? Each 
> client has to tell it and you have to store it and look it up on a per 
> outbound message basis. And keep it accurate. Customers just love keeping you 
> informed of where they want to send their messages. Do you know what happens 
> when they forget to tell you they moved and they don't get the message? They 
> blame you and ask for a credit memo. And do you know what happens when you 
> tell them no. They go to your competitor. If there is no conversational 
> state, then you aren't waiting for an acknowledgement from the other side for 
> each message and you can't prove that it was delivered or even try again.

It is a separate system, if you can make use of systems someone else has 
already designed & tested for you.  The easiest work is that someone else has 
already done for you.  (For example, we don't worry about making use of the 
worlds largest/oldest push notification system (email) where needed. Postfix 
has already been designed for us. ) Hubs (and other pubsub/queueing) systems 
already exist.  And the reliability issue is a red herring.  push/messaging 
systems are often of less than guaranteed reliability, which is fine if 
communicated. There are many use cases where that is "good enough".  

In any case the order of  resources needed is closer to O(N * Fp) for a polling 
system, where N is the number of clients, and Fp is the polling frequency  
(i.e. the inverse of the minimum acceptable latency).  The order for a push 
system is roughly O(N * Fe) where N is the number of clients, and Fe is the 
frequency of events you need to notify clients about.  

Which is appropriate depends on if Fe < Fp.  If your clients need notification 
at low latency of infrequent events, they will pound your API servers thru the 
floor with their polling when  a push syste

Re: [Openstack] [Nova] [Keystone] Nova projects (Diablo)

[Kiall Mac Innes]

Just add the ec2 credentials to keystone, apply the keystone patch mentioned
earlier if your using Diablo branches, and you're good to go.

Check out how devstack does it, While it's not a production platform, it's a
great reference.

Kiall
On Oct 28, 2011 10:42 p.m., "Nguyen, Liem Manh" 
wrote:

>  Thanks, Heck…  So, to use Nova with keystone, it appears that I do not
> need to create Nova projects anymore.  So, is there any other configuration
> I should do to use the euc* tools with Keystone?
>
> ** **
>
> Liem
>
> ** **
>
> *From:* Joseph Heck [mailto:he...@me.com]
> *Sent:* Friday, October 28, 2011 1:18 PM
> *To:* Nguyen, Liem Manh
> *Cc:* openstack@lists.launchpad.net
> *Subject:* Re: [Openstack] [Nova] [Keystone] Nova projects (Diablo)
>
> ** **
>
> Liem,
>
> ** **
>
> There's some newer documentation that we just created at
> keystone.openstack.org related to setting up and configuring Keystone.
> Look into the page at http://keystone.openstack.org/configuring.html,
> which also has detail on how to configure Nova to work with Keystone.
>
> ** **
>
> -joe
>
> ** **
>
> On Oct 28, 2011, at 10:50 AM, Nguyen, Liem Manh wrote:
>
>
>
> 
>
> Hi Stackers,
>
>  
>
> For the Diablo release, I would like to use Keystone as the auth
> component…   Do I still need to use lazy provisioning (nova_auth_token.py)
> in my pipeline to provision Nova projects (i.e., is Nova project creating
> still required)?  Also, is there an example of how the novarc should be
> configured for Keystone?
>
>  
>
> Thanks,
>
> Liem
>
>  
>
> ___
> 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] OpenSTack Minimum Spec

[Matt Dietz]

For the record, I'm currently running XenServer 6 inside of a VMWare
Fusion install on my Mac, with 2GB of RAM dedicated to the entire VM. I
created a new instance_type that creates 64MB instances. Works great so
far!

On 10/28/11 3:31 PM, "Jay Pipes"  wrote:

>2011/10/28 Frans Thamura :
>> 2011/10/29 Jay Pipes :
>>> FWIW, my test machine at home is from System76. It's got 24G RAM and
>>> an i7 12-core processor and runs OpenStack via devstack.sh pretty well
>>> :) All for around $2400USD. You can get a 4-core, 16G system for aroun
>>> $700USD a box.
>>
>> hi jay,
>>
>> r u sure openstack must run minimum spec 24GB RAM or 16GB?
>>
>> how about 8GB?
>
>I didn't say that :) It will run on much less, yes.
>-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] OpenStack Dashboard Gerrit/Github Transition

[Joseph Heck]

I'm working on that with the transition right now - we hope to get it back in 
place shortly, and are working through some of the issues of getting this 
backed with Gerrit now.

-joe

On Oct 28, 2011, at 1:53 PM, Kiall Mac Innes wrote:
> Hi Devin,
> 
> Should we expect a diablo/stable branch? I'm only asking because the old 
> branches are now gone.
> 
> Thanks,
> Kiall
> 
> On Oct 28, 2011 9:48 p.m., "Devin Carlen"  wrote:
> Hello all,
> 
> We have officially completed the Gerrit/Github transition for Horizon.  This 
> is the last time we'll have to move things for a while. I promise. :)
> 
> The official Horizon repo is now at:
> 
>https://github.com/openstack/horizon
> 
> 
> Gerrit workflow instructions are here:
> 
>http://wiki.openstack.org/GerritWorkflow
> 
> 
> Thanks to James Blair, Thierry Carrez, and Monty Taylor for all their help 
> lately.
> 
> 
> 
> Best,
> 
> 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] OpenStack Dashboard Gerrit/Github Transition

[Devin Carlen]

This will be fixed shortly.  Until then we do have tags:

https://github.com/openstack/horizon/tags


Thanks,

Devin

On Oct 28, 2011, at 1:53 PM, Kiall Mac Innes wrote:

> Hi Devin,
> 
> Should we expect a diablo/stable branch? I'm only asking because the old 
> branches are now gone.
> 
> Thanks,
> Kiall
> 
> On Oct 28, 2011 9:48 p.m., "Devin Carlen"  wrote:
> Hello all,
> 
> We have officially completed the Gerrit/Github transition for Horizon.  This 
> is the last time we'll have to move things for a while. I promise. :)
> 
> The official Horizon repo is now at:
> 
>https://github.com/openstack/horizon
> 
> 
> Gerrit workflow instructions are here:
> 
>http://wiki.openstack.org/GerritWorkflow
> 
> 
> Thanks to James Blair, Thierry Carrez, and Monty Taylor for all their help 
> lately.
> 
> 
> 
> Best,
> 
> 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] [Nova] [Keystone] Nova projects (Diablo)

[Vishvananda Ishaya]

This is correct  Unfortunately, you won't be able to use euca-upload-bundle 
properly.  I am trying to figure out a way to allow euca-upload-bundle to work, 
but for now it will only work with deprecated auth.

Devstack shows how you can create users, tenants, roles and credentials in 
keystone that you can then use through the ec2 api.

Vish

On Oct 28, 2011, at 1:49 PM, Nguyen, Liem Manh wrote:

> Thanks, Heck…  So, to use Nova with keystone, it appears that I do not need 
> to create Nova projects anymore.  So, is there any other configuration I 
> should do to use the euc* tools with Keystone?
>  
> Liem
>  
> From: Joseph Heck [mailto:he...@me.com] 
> Sent: Friday, October 28, 2011 1:18 PM
> To: Nguyen, Liem Manh
> Cc: openstack@lists.launchpad.net
> Subject: Re: [Openstack] [Nova] [Keystone] Nova projects (Diablo)
>  
> Liem,
>  
> There's some newer documentation that we just created at 
> keystone.openstack.org related to setting up and configuring Keystone. Look 
> into the page at http://keystone.openstack.org/configuring.html, which also 
> has detail on how to configure Nova to work with Keystone.
>  
> -joe
>  
> On Oct 28, 2011, at 10:50 AM, Nguyen, Liem Manh wrote:
> 
> 
> Hi Stackers,
>  
> For the Diablo release, I would like to use Keystone as the auth component…   
> Do I still need to use lazy provisioning (nova_auth_token.py) in my pipeline 
> to provision Nova projects (i.e., is Nova project creating still required)?  
> Also, is there an example of how the novarc should be configured for Keystone?
>  
> Thanks,
> Liem
>  
> ___
> 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] [Nova] [Keystone] Nova projects (Diablo)

[Nguyen, Liem Manh]

Thanks, Heck...  So, to use Nova with keystone, it appears that I do not need 
to create Nova projects anymore.  So, is there any other configuration I should 
do to use the euc* tools with Keystone?

Liem

From: Joseph Heck [mailto:he...@me.com]
Sent: Friday, October 28, 2011 1:18 PM
To: Nguyen, Liem Manh
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] [Nova] [Keystone] Nova projects (Diablo)

Liem,

There's some newer documentation that we just created at 
keystone.openstack.org related to setting up and 
configuring Keystone. Look into the page at 
http://keystone.openstack.org/configuring.html, which also has detail on how to 
configure Nova to work with Keystone.

-joe

On Oct 28, 2011, at 10:50 AM, Nguyen, Liem Manh wrote:


Hi Stackers,

For the Diablo release, I would like to use Keystone as the auth component...   
Do I still need to use lazy provisioning (nova_auth_token.py) in my pipeline to 
provision Nova projects (i.e., is Nova project creating still required)?  Also, 
is there an example of how the novarc should be configured for Keystone?

Thanks,
Liem

___
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] OpenStack Dashboard Gerrit/Github Transition

[Kiall Mac Innes]

Hi Devin,

Should we expect a diablo/stable branch? I'm only asking because the old
branches are now gone.

Thanks,
Kiall
On Oct 28, 2011 9:48 p.m., "Devin Carlen"  wrote:

> Hello all,
>
> We have officially completed the Gerrit/Github transition for Horizon.
>  This is the last time we'll have to move things for a while. I promise. :)
>
> The official Horizon repo is now at:
>
>https://github.com/openstack/horizon
>
>
> Gerrit workflow instructions are here:
>
>http://wiki.openstack.org/GerritWorkflow
>
>
> Thanks to James Blair, Thierry Carrez, and Monty Taylor for all their help
> lately.
>
>
>
> Best,
>
> 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] [Nova] [Keystone] Nova projects (Diablo)

[Joseph Heck]

Liem,

There's some newer documentation that we just created at keystone.openstack.org 
related to setting up and configuring Keystone. Look into the page at 
http://keystone.openstack.org/configuring.html, which also has detail on how to 
configure Nova to work with Keystone.

-joe

On Oct 28, 2011, at 10:50 AM, Nguyen, Liem Manh wrote:

> Hi Stackers,
>  
> For the Diablo release, I would like to use Keystone as the auth component…   
> Do I still need to use lazy provisioning (nova_auth_token.py) in my pipeline 
> to provision Nova projects (i.e., is Nova project creating still required)?  
> Also, is there an example of how the novarc should be configured for Keystone?
>  
> Thanks,
> Liem
>  
> ___
> 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] +1, All services should have WADLs

[Joseph Heck]

Well said John.

-joe

On Oct 28, 2011, at 8:26 AM, John Dickinson wrote:
> On Oct 28, 2011, at 10:04 AM, Ed Leafe wrote:
>>  Swift had the advantage of starting out as a closed source project that 
>> only had to serve a single master, and thus didn't need external 
>> orchestration to keep it on track. Nova, OTOH, as a community development 
>> effort, essentially had to be all things to all people, which is unworkable; 
>> hence the need for some up-front design to keep some sort of focus to the 
>> development. The problem is that this inevitably descends into bikeshedding, 
>> which has been prominently on display in this thread.
> 
> I absolutely do not want to compare different openstack projects. That all 
> too often is perceived as an "us vs them", and I want to avoid that 
> altogether. Yes, nova and swift and glance and keystone and horizon are 
> different. My point from earlier is that because the projects are different 
> (in scope, users, and dev lifecycle), statements like "all openstack projects 
> need to do X" are either meaningless or unmanageable.
> 
> Openstack is a collection if different parts that should work together, but 
> that doesn't mean that there are one size fits all solutions to issues that 
> come up. These discussions around the One True Way to do things are a 
> distraction at best. If you have 2 people arguing about the best way for an 
> aspect of a particular project should work, have them both code it up (or 
> write the docs or design the UI or whatever) and then compare and choose the 
> best implementation. Bikeshedding (along with complaining about bikeshedding 
> [meta!]) feels satisfying, but it's a hollow pursuit that distracts from 
> getting things done.
> 
> --John___
> 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] OpenSTack Minimum Spec

[Frans Thamura]

2011/10/29 Jay Pipes :
> FWIW, my test machine at home is from System76. It's got 24G RAM and
> an i7 12-core processor and runs OpenStack via devstack.sh pretty well
> :) All for around $2400USD. You can get a 4-core, 16G system for aroun
> $700USD a box.

hi jay,

r u sure openstack must run minimum spec 24GB RAM or 16GB?

how about 8GB?


>
> 2011/10/28 Frans Thamura 
>>
>> thx for the reply..
>>
>> i use this spec P4 1.5GB, Dell Optiplex i believe..
>>
>> but i love if the spec that i create, confirmed good enough for student to 
>> learn
>>
>> F
>>
>>
>> 2011/10/28 Diego Parrilla Santamaría 
>>>
>>> Frans,
>>> the single node configuration of the Stackops Distro can work in very 
>>> modest environments. A P4 and 1.5GB should be enough if you want to deploy 
>>> m1.tiny instances with QEMU. If you want to manage the deployment in a 
>>> training lab probably you should check the tool.
>>> Cheers
>>> Diego
>>> -
>>> --
>>> Diego Parrilla
>>> CEO
>>> www.stackops.com |  diego.parri...@stackops.com | +34 649 94 43 29 
>>> | skype:diegoparrilla
>>>
>>>  ADVERTENCIA LEGAL 
>>> Le informamos, como destinatario de este mensaje, que el correo electrónico 
>>> y las comunicaciones por medio de Internet no permiten asegurar ni 
>>> garantizar la confidencialidad de los mensajes transmitidos, así como 
>>> tampoco su integridad o su correcta recepción, por lo que STACKOPS 
>>> TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. 
>>> Si no consintiese en la utilización del correo electrónico o de las 
>>> comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro 
>>> conocimiento de manera inmediata. Este mensaje va dirigido, de manera 
>>> exclusiva, a su destinatario y contiene información confidencial y sujeta 
>>> al secreto profesional, cuya divulgación no está permitida por la ley. En 
>>> caso de haber recibido este mensaje por error, le rogamos que, de forma 
>>> inmediata, nos lo comunique mediante correo electrónico remitido a nuestra 
>>> atención y proceda a su eliminación, así como a la de cualquier documento 
>>> adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o 
>>> utilización de este mensaje, o de cualquier documento adjunto al mismo, 
>>> cualquiera que fuera su finalidad, están prohibidas por la ley.
>>>
>>> * PRIVILEGED AND CONFIDENTIAL 
>>> We hereby inform you, as addressee of this message, that e-mail and 
>>> Internet do not guarantee the confidentiality, nor the completeness or 
>>> proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. 
>>> does not assume any liability for those circumstances. Should you not agree 
>>> to the use of e-mail or to communications via Internet, you are kindly 
>>> requested to notify us immediately. This message is intended exclusively 
>>> for the person to whom it is addressed and contains privileged and 
>>> confidential information protected from disclosure by law. If you are not 
>>> the addressee indicated in this message, you should immediately delete it 
>>> and any attachments and notify the sender by reply e-mail. In such case, 
>>> you are hereby notified that any dissemination, distribution, copying or 
>>> use of this message or any attachments, for any purpose, is strictly 
>>> prohibited by law.
>>>
>>>
>>>
>>> On Fri, Oct 28, 2011 at 7:21 AM, Frans Thamura  wrote:

 hi all

 i am writing specification for polytechnics related for lab,

 the regulator said, 1 PC must be for 1 student

 and several polytechnics have limited budget

 can share all?

 i have Pentium 4, run in single node :) but i think multicore
 processor are better,

 so for play around i recommend i7, for server i recommend 2 core Xeon for 
 lab.


 my plan

 1 PC = 1 student

 we will create group, to make student can do multinode.



 --
 Frans Thamura (曽志胜)
 Chief of Advisory
 Meruvian.
 Integrated Hypermedia Java Solution Provider.

 Mobile: +628557888699
 Blog: http://blogs.mervpolis.com/roller/flatburger (id)

 FB: http://www.facebook.com/meruvian
 TW: http://www.twitter.com/meruvian / @meruvian
 Website: http://www.meruvian.org

 "We grow because we share the same belief."

 ___
 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: ht

Re: [Openstack] OpenSTack Minimum Spec

[Jay Pipes]

2011/10/28 Frans Thamura :
> 2011/10/29 Jay Pipes :
>> FWIW, my test machine at home is from System76. It's got 24G RAM and
>> an i7 12-core processor and runs OpenStack via devstack.sh pretty well
>> :) All for around $2400USD. You can get a 4-core, 16G system for aroun
>> $700USD a box.
>
> hi jay,
>
> r u sure openstack must run minimum spec 24GB RAM or 16GB?
>
> how about 8GB?

I didn't say that :) It will run on much less, yes.
-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] +1, All services should have WADLs

[Matt Dietz]

Couldn't agree more with this

On a side-note, I'm now going to sign all emails as

Weird,

-Matt

On 10/28/11 12:54 PM, "Jay Pipes"  wrote:

>On Fri, Oct 28, 2011 at 1:39 AM, John Dickinson  wrote:
>> I am concerned about some of the implications that are being discussed.
>>
>> 1) A WADL is part of documentation of an API. Nobody is going to object
>>to more documentation.
>>
>> 2) Being an open-source project, if somebody wants to commit to
>>creating and maintaining a WADL for a particular part of Openstack, they
>>are free to. Alternately, persuade somebody else to do it. However,
>>having a WADL to describe a particular component of openstack is not
>>something that can be forced onto that component. Phrases like "All
>>services should have WADLs" are either meaningless (unenforcible or not
>>really all services) or oppressive (mandating requirements on a project).
>>
>> 3) A WADL is not a replacement for any sort of dev documentation, and
>>in fact, still requires there to be human-readable dev docs.
>>
>> Specifically for swift, not one of the current developers are going to
>>either write or maintain a WADL for the swift API. However, we'll be
>>happy to assist anyone who wants to write and maintain docs for swift,
>>including WADLs.
>>
>> The important thing is that code talks. If you want WADLs (or your
>>flavor of WADLs), make them! Stop trying to architect systems for
>>architects. These things are meant to be used. Let's focus on what is
>>necessary for getting a reliable system into the hands of those who will
>>be using it.
>>
>> (Just about all of the above goes for things like API versioning, too.
>>And packaging vs tarballs vs python libraries. And polling vs pushing.
>>And the true meaning of what a ReST interface is.)
>
>Not sure what this means from a personal existential viewpoint, but I
>completely agree with John.
>
>Weird.
>
>-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

[Openstack] OpenStack Dashboard Gerrit/Github Transition

[Devin Carlen]

Hello all,

We have officially completed the Gerrit/Github transition for Horizon.  This is 
the last time we'll have to move things for a while. I promise. :)

The official Horizon repo is now at:

https://github.com/openstack/horizon


Gerrit workflow instructions are here:

http://wiki.openstack.org/GerritWorkflow


Thanks to James Blair, Thierry Carrez, and Monty Taylor for all their help 
lately.



Best,

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

Re: [Openstack] Patched euca-tools to work w/ keystone

[Ziad Sawalha]

I think this was it:
https://github.com/openstack/keystone/commit/2bb474331d73e7c6d2a507cb097c50
cfe65ad6b6

Will try to get it in the back ports.

Z

On 10/28/11 1:57 PM, "Razique Mahroua"  wrote:

>Hey, 
>I never found out, in fact I only recall some mails exchange on a mailing
>list, basically, there are two lines to change into :
>/usr/local/lib/python2.6/dist-packages/keystone-1.0-py2.6.egg/keystone/mid
>dleware/ec2_token.py
>
>   # o = urlparse(FLAGS.keystone_ec1_url)
>   o = urlparse(FLAGS.keystone_ec2_url)
>
>and : 
>   # token_id = result['auth']['token']['id']
>   token_id = result['access']['token']['id']
>
>Regards,
>Razique
>
>Le 28 oct. 2011 à 20:04, Leandro Reox a écrit :
>
>> Hi guys,
>> 
>> Anyone got the link to download the patched euca tools that work with
>>keystone auth tokens to query the nova api ?
>> 
>> Regards
>> 
>> Lean ___
>> 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] Keystone versioning and tarballs

[Yun Mao]

The problem looks like that only users with role ['projectmanager',
'sysadmin'] can run instances. The demo user created by devstack only
has "Member" role. Not sure how it's mapped to the roles described in
http://docs.openstack.org/diablo/openstack-compute/admin/content/users-and-projects.html

After switching to admin user, it works fine.

Anyway, this keystone vs old authentication is really confusing..

On Thu, Oct 27, 2011 at 10:43 PM, Yun Mao  wrote:
> I think I'm close to figuring this out. You can take a look at the
> devstack scripts. In particular,
> https://github.com/cloudbuilders/devstack/blob/master/files/keystone_data.sh
>
> Then you can source openrc to get the EC2_* environment variables.
>
> However, it only works for euca-describe-instances,
> euca-describe-images, at least for me.
>
> When I tried euca-run-instances, the error is:
> $ euca-run-instances ami-0004
> Warning: failed to parse error message from AWS: :1:0: syntax error
> None: None
>
> The log on the nova-api daemon looks like this:
> 2011-10-27 18:29:22,288 DEBUG nova [-] HTTP PERF: 0.01362 seconds to
> GET 127.0.0.1:35357 /v2.0/tokens/bd9c6abd-eeb4-4ba9-b49e-7aafe790ef9c)
> from (pid=2774) getresponse
> /opt/stack/keystone/keystone/common/bufferedhttp.py:99
> 2011-10-27 18:29:22,301 DEBUG nova [-] HTTP PERF: 0.01282 seconds to
> GET 127.0.0.1:35357 /v2.0/tokens/bd9c6abd-eeb4-4ba9-b49e-7aafe790ef9c)
> from (pid=2774) getresponse
> /opt/stack/keystone/keystone/common/bufferedhttp.py:99
> 2011-10-27 18:29:22,302 DEBUG nova.api [-] action: RunInstances from
> (pid=2774) __call__ /opt/stack/nova/nova/api/ec2/__init__.py:240
> 2011-10-27 18:29:22,302 DEBUG nova.api [-] arg: ImageId         val:
> ami-000 from (pid=2774) __call__
> /opt/stack/nova/nova/api/ec2/__init__.py:242
> 2011-10-27 18:29:22,303 DEBUG nova.api [-] arg: MaxCount
>  val: 1 from (pid=2774) __call__
> /opt/stack/nova/nova/api/ec2/__init__.py:242
> 2011-10-27 18:29:22,303 DEBUG nova.api [-] arg: MinCount
>  val: 1 from (pid=2774) __call__
> /opt/stack/nova/nova/api/ec2/__init__.py:242
> 2011-10-27 18:29:22,303 DEBUG nova.api [-] arg: InstanceType
>  val: m1.small from (pid=2774) __call__
> /opt/stack/nova/nova/api/ec2/__init__.py:242
> 2011-10-27 18:29:22,303 AUDIT nova.api
> [4f056dc4-6515-4bd0-bd09-0c1584b9fc39 demo 2] Unauthorized request for
> controller=CloudController and action=RunInstances
> 2011-10-27 18:29:22,304 INFO nova.api
> [4f056dc4-6515-4bd0-bd09-0c1584b9fc39 demo 2] 0.60822s 127.0.0.1 POST
> /services/Cloud/ CloudController:RunInstances 401 [Boto/2.0 (linux2)]
> application/x-www-form-urlencoded text/plain
>
> Does anyone know what's going on? Thanks,
>
> Yun
>
> On Tue, Oct 25, 2011 at 8:51 AM, David Kranz  wrote:
>> Along the same lines,  how do you export the shell variables for euca-tools
>> with keystone since nova-manage to create the zipfile does not work?
>>
>>  -David
>>
>> On 10/24/2011 8:29 PM, Vishvananda Ishaya wrote:
>>
>> Speaking of keystone diablo tag, it is currently missing the following
>> commit:
>> https://github.com/openstack/keystone/commit/2bb474331d73e7c6d2a507cb097c50cfe65ad6b6
>> This commit is required for the ec2 api to work with keystone.  Seems like
>> we need to move the tag or create a keystone/stable branch and pull this in.
>> Vish
>> On Oct 24, 2011, at 12:03 AM, Mark McLoughlin wrote:
>>
>> Hey,
>>
>> I just noticed a few things when reviewing the Fedora packaging of
>> keystone:
>>
>>  - There's no diablo release tarball on https://launchpad.net/keystone
>>    like other projects
>>
>>  - The 2011.3 tag in git has version=1.0 in setup.py. Which versioning
>>    scheme is keystone going to follow?
>>
>>  - The version in master is non-numeric 'essex' rather than e.g.
>>    2011.3 or 1.1
>>
>> Thanks,
>> Mark.
>>
>>
>> ___
>> 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] OpenSTack Minimum Spec

[Jay Pipes]

FWIW, my test machine at home is from System76. It's got 24G RAM and
an i7 12-core processor and runs OpenStack via devstack.sh pretty well
:) All for around $2400USD. You can get a 4-core, 16G system for aroun
$700USD a box.

http://system76.com

I've had laptops and desktops from them and I highly recommend them.
They come with Ubuntu installed, so no need to either pay for a
Windows license/tax or wipe Windows partition and install a *nix.

Cheers,
-jay

2011/10/28 Frans Thamura 
>
> thx for the reply..
>
> i use this spec P4 1.5GB, Dell Optiplex i believe..
>
> but i love if the spec that i create, confirmed good enough for student to 
> learn
>
> F
>
>
> 2011/10/28 Diego Parrilla Santamaría 
>>
>> Frans,
>> the single node configuration of the Stackops Distro can work in very modest 
>> environments. A P4 and 1.5GB should be enough if you want to deploy m1.tiny 
>> instances with QEMU. If you want to manage the deployment in a training lab 
>> probably you should check the tool.
>> Cheers
>> Diego
>> -
>> --
>> Diego Parrilla
>> CEO
>> www.stackops.com |  diego.parri...@stackops.com | +34 649 94 43 29 
>> | skype:diegoparrilla
>>
>>  ADVERTENCIA LEGAL 
>> Le informamos, como destinatario de este mensaje, que el correo electrónico 
>> y las comunicaciones por medio de Internet no permiten asegurar ni 
>> garantizar la confidencialidad de los mensajes transmitidos, así como 
>> tampoco su integridad o su correcta recepción, por lo que STACKOPS 
>> TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. 
>> Si no consintiese en la utilización del correo electrónico o de las 
>> comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro 
>> conocimiento de manera inmediata. Este mensaje va dirigido, de manera 
>> exclusiva, a su destinatario y contiene información confidencial y sujeta al 
>> secreto profesional, cuya divulgación no está permitida por la ley. En caso 
>> de haber recibido este mensaje por error, le rogamos que, de forma 
>> inmediata, nos lo comunique mediante correo electrónico remitido a nuestra 
>> atención y proceda a su eliminación, así como a la de cualquier documento 
>> adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o 
>> utilización de este mensaje, o de cualquier documento adjunto al mismo, 
>> cualquiera que fuera su finalidad, están prohibidas por la ley.
>>
>> * PRIVILEGED AND CONFIDENTIAL 
>> We hereby inform you, as addressee of this message, that e-mail and Internet 
>> do not guarantee the confidentiality, nor the completeness or proper 
>> reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. does 
>> not assume any liability for those circumstances. Should you not agree to 
>> the use of e-mail or to communications via Internet, you are kindly 
>> requested to notify us immediately. This message is intended exclusively for 
>> the person to whom it is addressed and contains privileged and confidential 
>> information protected from disclosure by law. If you are not the addressee 
>> indicated in this message, you should immediately delete it and any 
>> attachments and notify the sender by reply e-mail. In such case, you are 
>> hereby notified that any dissemination, distribution, copying or use of this 
>> message or any attachments, for any purpose, is strictly prohibited by law.
>>
>>
>>
>> On Fri, Oct 28, 2011 at 7:21 AM, Frans Thamura  wrote:
>>>
>>> hi all
>>>
>>> i am writing specification for polytechnics related for lab,
>>>
>>> the regulator said, 1 PC must be for 1 student
>>>
>>> and several polytechnics have limited budget
>>>
>>> can share all?
>>>
>>> i have Pentium 4, run in single node :) but i think multicore
>>> processor are better,
>>>
>>> so for play around i recommend i7, for server i recommend 2 core Xeon for 
>>> lab.
>>>
>>>
>>> my plan
>>>
>>> 1 PC = 1 student
>>>
>>> we will create group, to make student can do multinode.
>>>
>>>
>>>
>>> --
>>> Frans Thamura (曽志胜)
>>> Chief of Advisory
>>> Meruvian.
>>> Integrated Hypermedia Java Solution Provider.
>>>
>>> Mobile: +628557888699
>>> Blog: http://blogs.mervpolis.com/roller/flatburger (id)
>>>
>>> FB: http://www.facebook.com/meruvian
>>> TW: http://www.twitter.com/meruvian / @meruvian
>>> Website: http://www.meruvian.org
>>>
>>> "We grow because we share the same belief."
>>>
>>> ___
>>> 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://laun

Re: [Openstack] Patched euca-tools to work w/ keystone

[Razique Mahroua]

Hey, 
I never found out, in fact I only recall some mails exchange on a mailing list, 
basically, there are two lines to change into : 
/usr/local/lib/python2.6/dist-packages/keystone-1.0-py2.6.egg/keystone/middleware/ec2_token.py

# o = urlparse(FLAGS.keystone_ec1_url)
o = urlparse(FLAGS.keystone_ec2_url)

and : 
# token_id = result['auth']['token']['id']
token_id = result['access']['token']['id']

Regards,
Razique

Le 28 oct. 2011 à 20:04, Leandro Reox a écrit :

> Hi guys,
> 
> Anyone got the link to download the patched euca tools that work with 
> keystone auth tokens to query the nova api ?
> 
> Regards
> 
> Lean ___
> 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] +1, All services should have WADLs

[Jay Pipes]

On Fri, Oct 28, 2011 at 1:39 AM, John Dickinson  wrote:
> I am concerned about some of the implications that are being discussed.
>
> 1) A WADL is part of documentation of an API. Nobody is going to object to 
> more documentation.
>
> 2) Being an open-source project, if somebody wants to commit to creating and 
> maintaining a WADL for a particular part of Openstack, they are free to. 
> Alternately, persuade somebody else to do it. However, having a WADL to 
> describe a particular component of openstack is not something that can be 
> forced onto that component. Phrases like "All services should have WADLs" are 
> either meaningless (unenforcible or not really all services) or oppressive 
> (mandating requirements on a project).
>
> 3) A WADL is not a replacement for any sort of dev documentation, and in 
> fact, still requires there to be human-readable dev docs.
>
> Specifically for swift, not one of the current developers are going to either 
> write or maintain a WADL for the swift API. However, we'll be happy to assist 
> anyone who wants to write and maintain docs for swift, including WADLs.
>
> The important thing is that code talks. If you want WADLs (or your flavor of 
> WADLs), make them! Stop trying to architect systems for architects. These 
> things are meant to be used. Let's focus on what is necessary for getting a 
> reliable system into the hands of those who will be using it.
>
> (Just about all of the above goes for things like API versioning, too. And 
> packaging vs tarballs vs python libraries. And polling vs pushing. And the 
> true meaning of what a ReST interface is.)

Not sure what this means from a personal existential viewpoint, but I
completely agree with John.

Weird.

-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] Handling Schema Changes in Keystone

[Ziad Sawalha]

Thanks, pvo. This looks like good. We'd like to follow what other projects do. 
Has there been any feedback on this BP? Will this be "the way" to handle things 
in OpenStack?

The easiest way for us to handle this now for schema migrations to Keystone is 
to follow Jesse's suggestion and use SQL Alchemy migrate_repo. We'll do that 
for schema changes currently in our branches and will work towards adopting the 
BP above.

Z



From: Paul Voccio mailto:paul.voc...@rackspace.com>>
Date: Tue, 25 Oct 2011 19:33:57 -0500
To: Brian Schott 
mailto:brian.sch...@nimbisservices.com>>, Ziad 
Sawalha mailto:ziad.sawa...@rackspace.com>>
Cc: "openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] Handling Schema Changes in Keystone

There is a BP out for how to handle continuious delivery and db upgrades within 
Nova. It does address some of the issues that keystone may face but feedback on 
the doc would be appreciated.

https://blueprints.launchpad.net/nova/+spec/deployability-improvements

pvo

From: Brian Schott 
mailto:brian.sch...@nimbisservices.com>>
Date: Tue, 25 Oct 2011 18:16:30 -0400
To: Ziad Sawalha mailto:ziad.sawa...@rackspace.com>>
Cc: "openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] Handling Schema Changes in Keystone

It's probably the best approach that doesn't depend on the Django ORM (like 
South).  Does anyone use the "experimental" command line migrate to generate 
the migrate script?  I always did it by hand.
http://packages.python.org/sqlalchemy-migrate/

On the dev side, one of the big headaches in nova migrate_repo has been that 
the file numbering by hand meant that competing feature teams that needed to 
incorporate a schema change had to keep bumping the number every time a new 
version file got committed.  We talked about relaxing migrate_repo numbering 
rules so that you could create a 999_my_pending_change.py file that didn't 
break the version numbering adjacency checks.  I don't know if that happened.  
Otherwise, every time a new file arrived in trunk, we all had to manually 
renumber our development files from 055_x to 056_x...  Not a big deal, but 
annoying when you pushed a branch up for review, then it broke because 
something else arrived in the same number slot.

On the deploy side, complicated table transforms don't always map well to all 
database backends and I don't think here is any unit testing with populated 
fixtures for data upgrade/downgrade. Don't know if this has been an issue in 
real deployments, but the opportunity for sysadmin excellence is certainly 
there

Brian

-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.com
ph: 443-274-6064  fx: 443-274-6060







On Oct 25, 2011, at 5:45 PM, Ziad Sawalha wrote:

Our schema right now is auto generated from the model using sqlalchemy. 
Whenever we change the model, the generated schema is different for new 
installations but this does not address existing deployments.

Looking for feedback on how to handle this better:
anotherjesses offered: 
https://github.com/openstack/nova/tree/master/nova/db/sqlalchemy/migrate_repo

Questions:
- Has anyone used this on the dev side?
- Has anyone used this on the deployment/ops side?

Would love to hear from you how you started it (we have multiple versions of 
our schema out there, so where do we start) and what was the experience 
updating versions.

Regards,

Ziad
___
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] Patched euca-tools to work w/ keystone

[Leandro Reox]

Hi guys,

Anyone got the link to download the patched euca tools that work with
keystone auth tokens to query the nova api ?

Regards

Lean
___
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] Push vs Polling (from Versioning Thread)

[Jorge Williams]

Huh?  I didn't write that.  George did.

On Oct 28, 2011, at 11:35 AM, Caitlin Bestler wrote:

> Jorge Williams wrote:
> 
>> Push notifications don't make your core system any more complex. You push 
>> the change to a message queue and rely on another system to do the work.
> 
> That is only true if the messaging system and the core system are largely 
> independent, which could have some implications that would probably be fine 
> for
> most human users but could be quite problematic for applications.
> 
> Can the push notification system block the core system? If not the push 
> notifications ultimately become unreliable. A human who is not notified that
> a given update once in 10,000 times is probably just going to shrug it off.  
> But an application that needs to know it is looking at the most recent version
> of a document before it modifies it is ultimately going to have to rely on 
> polling, or have the notification be built into the core system complete with
> throttling of updates when absolutely necessary to ensure that notifications 
> are sent.
> 
> 
> 
> ___
> 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] Push vs Polling (from Versioning Thread)

[Jorge Williams]

On Oct 28, 2011, at 10:33 AM, George Reese wrote:

> You are describing an all-purpose system, not one that supports the narrow 
> needs of IaaS state notifications. 
> 
> There's no reason in this scenario to guarantee message delivery. 

Like I said, there are a lot of factors to consider.  And guarantee delivery 
may or may not be a requirement based on your use case. For example, wouldn't 
we want to monitor based on state changes? Missing a message could mean not 
sending an alert, right? How do you compensate for that if you don't guarantee 
delivery?





___
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] [Nova] [Keystone] Nova projects (Diablo)

[Nguyen, Liem Manh]

Hi Stackers,

For the Diablo release, I would like to use Keystone as the auth component...   
Do I still need to use lazy provisioning (nova_auth_token.py) in my pipeline to 
provision Nova projects (i.e., is Nova project creating still required)?  Also, 
is there an example of how the novarc should be configured for Keystone?

Thanks,
Liem

___
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] Push vs Polling (from Versioning Thread)

[George Reese]

There are ways around that without guaranteed message delivery.

Sent from my iPhone

On Oct 28, 2011, at 11:41, Bryan Taylor  wrote:

> On 10/28/2011 10:33 AM, George Reese wrote:
>
>> There's no reason in this scenario to guarantee message delivery.
>
> Usage, billing, support all require guaranteed message delivery. "Oops, 
> sorry, we don't bill sometimes because we lose messages" just doesn't fly 
> with executives, shareholders, and the SEC. With customers, lost messages = 
> credit memos and lost customers.
>
> ___
> 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] Push vs Polling (from Versioning Thread)

[Caitlin Bestler]

Jorge Williams wrote:

>  Push notifications don't make your core system any more complex. You push 
> the change to a message queue and rely on another system to do the work.

That is only true if the messaging system and the core system are largely 
independent, which could have some implications that would probably be fine for
most human users but could be quite problematic for applications.

Can the push notification system block the core system? If not the push 
notifications ultimately become unreliable. A human who is not notified that
a given update once in 10,000 times is probably just going to shrug it off.  
But an application that needs to know it is looking at the most recent version
of a document before it modifies it is ultimately going to have to rely on 
polling, or have the notification be built into the core system complete with
throttling of updates when absolutely necessary to ensure that notifications 
are sent.



___
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] [Nova] [Keystone] Nova projects (Diablo)

[Nguyen, Liem Manh]

Hi Stackers,

For the Diablo release, I would like to use Keystone as the auth component...   
Do I still need to use lazy provisioning (nova_auth_token.py) in my pipeline to 
provision Nova projects (i.e., is Nova project creating still required)?  Is 
not, is there an example of how the novarc should be configured to allow, say, 
uploading an image for a given Keystone tenant?

Thanks,
Liem
___
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] Push vs Polling (from Versioning Thread)

[Bryan Taylor]

On 10/28/2011 10:33 AM, George Reese wrote:


There's no reason in this scenario to guarantee message delivery.


Usage, billing, support all require guaranteed message delivery. "Oops, 
sorry, we don't bill sometimes because we lose messages" just doesn't 
fly with executives, shareholders, and the SEC. With customers, lost 
messages = credit memos and lost customers.


___
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] +1, All services should have WADLs

[John Dickinson]

On Oct 28, 2011, at 10:04 AM, Ed Leafe wrote:
>   Swift had the advantage of starting out as a closed source project that 
> only had to serve a single master, and thus didn't need external 
> orchestration to keep it on track. Nova, OTOH, as a community development 
> effort, essentially had to be all things to all people, which is unworkable; 
> hence the need for some up-front design to keep some sort of focus to the 
> development. The problem is that this inevitably descends into bikeshedding, 
> which has been prominently on display in this thread.

I absolutely do not want to compare different openstack projects. That all too 
often is perceived as an "us vs them", and I want to avoid that altogether. 
Yes, nova and swift and glance and keystone and horizon are different. My point 
from earlier is that because the projects are different (in scope, users, and 
dev lifecycle), statements like "all openstack projects need to do X" are 
either meaningless or unmanageable.

Openstack is a collection if different parts that should work together, but 
that doesn't mean that there are one size fits all solutions to issues that 
come up. These discussions around the One True Way to do things are a 
distraction at best. If you have 2 people arguing about the best way for an 
aspect of a particular project should work, have them both code it up (or write 
the docs or design the UI or whatever) and then compare and choose the best 
implementation. Bikeshedding (along with complaining about bikeshedding 
[meta!]) feels satisfying, but it's a hollow pursuit that distracts from 
getting things done.

--John

smime.p7s
Description: S/MIME cryptographic signature
___
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] Push vs Polling (from Versioning Thread)

[George Reese]

You are describing an all-purpose system, not one that supports the narrow
needs of IaaS state notifications.

There's no reason in this scenario to guarantee message delivery.

Sent from my iPhone

On Oct 28, 2011, at 10:09, Jorge Williams 
wrote:


 On Oct 28, 2011, at 8:11 AM, George Reese wrote:

 Push notifications don't make your core system any more complex. You push
the change to a message queue and rely on another system to do the work.

 The other system is scalable. It has no need to be stateless and can be run
in an on-demand format using agents to handle the growing/shrinking
notification needs.

 Bryan brings up the point that some of these subscription endpoints may go
away. That's a total red-herring. You have mechanisms in place to detect
failed deliveries and unsubscribe after a time (among other strategies).



 I think what Bryan is saying is this.  Someone, on "another system", lets
call it a hub,  has to do the work of tracking what messages have been
received by a particular client.  The failure scenarios there can cause a
lot of head aches.

 You can try to scale  hubs out horizontally, but each hub will be handling
a different set of clients at a particular point in time.  So that data
needs to be tracked.  The best you can do is to have a central data store
tracking when a client has received and acknowledged a particular message.
If there are a lot of clients that's a lot of data to sort through and
partition.  If you don't have a central store then a particular hub will be
responsible for a certain set of clients. And in this case, how many clients
should be tracked by a hub? 100? 1000? 100,000?  The more clients a hub
handles the more memory it needs to use to track those clients.  If a hub is
at  capacity  but you're monitoring system is starting to detect disk
failures, how do you migrate those clients to another hub? Do you split the
clients up among existing hubs, if so what's the algorithm there?  Or do you
have to stand up a new hub?

 As for the other failure states, the issue isn't just about detecting
failed deliveries, it's about tracking down successful deliveries too.  Say
after immediately sending a message to client A, that hub goes down.
 There's no record in the system that the message was sent  to client A.
 How do we detect that that happened? If we do detect it should we resend
the message here? Keep in mind,  the client may have received it but may or
may not have acknowledged it.  If we do resend the message, will that mess
up the client?  Does the client even care?

 There's a whole lot of inefficiencies to.  Consider that there are some
cases where the client also needs to track what messages have been received.
Both the client and the hub are tracking the state in this scenario and
that's pretty inefficient.  I would argue far more inefficient than the
polling scenario because it involves memory and potentially storage space.
 If the client doesn't really care to track state we are tracking it at the
hub for no reason.

 Say we have a client that's tracking sate, maybe saving it to the
datastore. (We have a lot of customers that do this.)  The client receives a
message, but before it can save it, it goes down.  Upon coming up again, it
has no awareness of the lost message, will it be delivered again? How?  How
does the client inform the hub of it's state?

 Other questions arise:  How long should you track clients before you
unsubscribe them? etc...etc...

 There's just so many similar scenarios that add a lot of complexity and I
would argue, at cloud scale, far greater inefficiencies into the system.

 With the polling scenario, the work is split between the server and the
client.  The server keeps track of the messages.  The client keeps track of
it's own state (what was the last message received? etc).  It's scalable
and, I would argue more efficient,  because it allows the client to track
state if it wants to, when it wants to, how it wants to.  On the server end
statelessness means that each pubsub node is a carbon copy of another -- if
one goes down another can replace it with no problem -- no need to transfer
sate.  What's more, the memory usage of the node is constant, no matter how
many clients are hitting it.

 That's not to say that polling is always the right choice.  As Mark said,
there are a lot of factors to consider.  In cases where there are a large
number of messages latencies may increase dramatically. It's just that when
we're talking web scale, it is *usually* a good choice.

 -jOrGe W.
___
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] rsync errors / swift benchmarking

[Sharif Islam]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


When I run swift-bench with higher numbers (-n and -g +) I sometime
see lots of failures with GET and DEL. I noticed these in the log:


> Oct 28 10:38:30 b001 object-replicator rsync: failed to connect to 
> 172.29.202.13: No route to host (113)
> Oct 28 10:38:30 b001 object-replicator rsync error: error in socket IO (code 
> 10) at clientserver.c(124) [sender=3.0.6]
> Oct 28 10:38:30 b001 object-replicator Bad rsync return code: ['rsync', 
> '--recursive', '--whole-file', '--human-readable', '--xattrs', 
> '--itemize-changes', '--ignore-existing', '--timeout=30', '--contimeout=30', 
> '/srv/node/sda3/objects/104691/561', '/srv/node/sda3/objects/104691/274', 
> '[172.29.202.13]::object/sda3/objects/104691'] -> 10
> Oct 28 10:38:30 b001 object-replicator rsync: failed to connect to 
> 172.29.202.14: No route to host (113)
> Oct 28 10:38:30 b001 object-replicator rsync error: error in socket IO (code 
> 10) at clientserver.c(124) [sender=3.0.6]
> Oct 28 10:38:30 b001 object-replicator Bad rsync return code: ['rsync', 
> '--recursive', '--whole-file', '--human-readable', '--xattrs', 
> '--itemize-changes', '--ignore-existing', '--timeout=30', '--contimeout=30', 
> '/srv/node/sda3/objects/104691/561', '/srv/node/sda3/objects/104691/274', 
> '[172.29.202.14]::object/sda3/objects/104691'] -> 10
> Oct 28 10:38:33 b001 object-replicator rsync: failed to connect to 
> 172.29.202.13: No route to host (113)
> Oct 28 10:38:33 b001 object-replicator rsync error: error in socket IO (code 
> 10) at clientserver.c(124) [sender=3.0.6]
> Oct 28 10:38:33 b001 object-replicator Bad rsync return code: ['rsync', 
> '--recursive', '--whole-file', '--human-readable', '--xattrs', 
> '--itemize-changes', '--ignore-existing', '--timeout=30', '--contimeout=30', 
> '/srv/node/sda3/objects/245260/6b2', 
> '[172.29.202.13]::object/sda3/objects/245260'] -> 10
> Oct 28 10:38:33 b001 object-replicator rsync: failed to connect to 
> 172.29.202.13: No route to host (113)
> Oct 28 10:38:33 b001 object-replicator rsync error: error in socket IO (code 
> 10) at clientserver.c(124) [sender=3.0.6]
> Oct 28 10:38:33 b001 object-replicator Bad rsync return code: ['rsync', 
> '--recursive', '--whole-file', '--human-readable', '--xattrs', 
> '--itemize-changes', '--ignore-existing', '--timeout=30', '--contimeout=30', 
> '/srv/node/sda3/objects/113759/b74', 
> '[172.29.202.13]::object/sda3/objects/113759'] -> 10
> Oct 28 10:38:33 b001 object-replicator rsync: failed to connect to 
> 172.29.202.14: No route to host (113)
> Oct 28 10:38:33 b001 object-replicator rsync error: error in socket IO (code 
> 10) at clientserver.c(124) [sender=3.0.6]
> Oct 28 10:38:33 b001 object-replicator Bad rsync return code: ['rsync', 
> '--recursive', '--whole-file', '--human-readable', '--xattrs', 
> '--itemize-changes', '--ignore-existing', '--timeout=30', '--contimeout=30', 
> '/srv/node/sda3/objects/113759/b74', 
> '[172.29.202.14]::object/sda3/objects/113759'] -> 10
> Oct 28 10:38:33 b001 object-replicator rsync: failed to connect to 
> 172.29.202.13: No route to host (113)
> Oct 28 10:38:33 b001 object-replicator rsync error: error in socket IO (code 
> 10) at clientserver.c(124) [sender=3.0.6]
> Oct 28 10:38:33 b001 object-replicator Bad rsync return code: ['rsync', 
> '--recursive', '--whole-file', '--human-readable', '--xattrs', 
> '--itemize-changes', '--ignore-existing', '--timeout=30', '--contimeout=30', 
> '/srv/node/sda3/objects/30751/272', 
> '[172.29.202.13]::object/sda3/objects/30751'] -> 10


I have some details here about my setup and numbers from swift-bench:

http://paste.openstack.org/show/2948/

I have one proxy node and 8 storage nodes, no SSL terminator/LB yet. I
ran the swift-bench from one the storages nodes.

The failures and errors are not consistent. For instance, yesterday I
noticed more failures, today it seems better. I would appreciate if
someone can suggest something to improve the performance. thanks.


- --sharif




- -- 
Sharif Islam
Senior Systems Analyst/Programmer
FutureGrid (http://futuregrid.org)
Pervasive Technology Institute, Indiana University Bloomington
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOqs5YAAoJEACffes9SivFskUH/126OjjMmKTkQHg4OpGJIfht
l5iOjsVZJCR3maIhENi2x3CiiY+EZ3yMKQWq+YReTWnui2bCN/laApt6VAT2385I
DrYztRVKj110/Wbc/rEY5mq3HWZwVZsqhqnCAMk2oW00Iaizlko3C5U+2JDLkBp3
mBbltk5j5mB8hf2Nen2Bv3onEvEgCUicI84FzIg5he1jg+Y5FpDfMNxyYBlVisyL
Ai/Lg/dBE8OYg8hWm9IdMckj/SQI4FQddwGD9HIeJlBgFG9ePgh7qf9Q8AfmXC3X
XqGbH3XVBgiDtWdm7ZBEyHalSVUoK2HYYmqzeq43efxozkChR74qLvMsusiy6lc=
=TC2I
-END PGP SIGNATURE-

___
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] +1, All services should have WADLs

[Ed Leafe]

On Oct 28, 2011, at 12:39 AM, John Dickinson wrote:

> The important thing is that code talks. If you want WADLs (or your flavor of 
> WADLs), make them! Stop trying to architect systems for architects. These 
> things are meant to be used. Let's focus on what is necessary for getting a 
> reliable system into the hands of those who will be using it.

This distills the discussion to its essence. Code talks. What we're all 
dancing around is who decides what that code is going to say. Do the developers 
decide this as they create the actual product, and then have that product 
documented after the fact? Or do some "architects" (god, do I hate that term in 
a software context!) decide ahead of time what the code is going to say, and 
then it's up to the devs to make it so.

Swift had the advantage of starting out as a closed source project that 
only had to serve a single master, and thus didn't need external orchestration 
to keep it on track. Nova, OTOH, as a community development effort, essentially 
had to be all things to all people, which is unworkable; hence the need for 
some up-front design to keep some sort of focus to the development. The problem 
is that this inevitably descends into bikeshedding, which has been prominently 
on display in this thread.



-- 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] Push vs Polling (from Versioning Thread)

[Jorge Williams]

On Oct 28, 2011, at 8:11 AM, George Reese wrote:

Push notifications don't make your core system any more complex. You push the 
change to a message queue and rely on another system to do the work.

The other system is scalable. It has no need to be stateless and can be run in 
an on-demand format using agents to handle the growing/shrinking notification 
needs.

Bryan brings up the point that some of these subscription endpoints may go 
away. That's a total red-herring. You have mechanisms in place to detect failed 
deliveries and unsubscribe after a time (among other strategies).


I think what Bryan is saying is this.  Someone, on "another system", lets call 
it a hub,  has to do the work of tracking what messages have been received by a 
particular client.  The failure scenarios there can cause a lot of head aches.

You can try to scale  hubs out horizontally, but each hub will be handling a 
different set of clients at a particular point in time.  So that data needs to 
be tracked.  The best you can do is to have a central data store tracking when 
a client has received and acknowledged a particular message.   If there are a 
lot of clients that's a lot of data to sort through and partition.  If you 
don't have a central store then a particular hub will be responsible for a 
certain set of clients. And in this case, how many clients should be tracked by 
a hub? 100? 1000? 100,000?  The more clients a hub handles the more memory it 
needs to use to track those clients.  If a hub is at  capacity  but you're 
monitoring system is starting to detect disk failures, how do you migrate those 
clients to another hub? Do you split the clients up among existing hubs, if so 
what's the algorithm there?  Or do you have to stand up a new hub?

As for the other failure states, the issue isn't just about detecting failed 
deliveries, it's about tracking down successful deliveries too.  Say after 
immediately sending a message to client A, that hub goes down.  There's no 
record in the system that the message was sent  to client A.  How do we detect 
that that happened? If we do detect it should we resend the message here? Keep 
in mind,  the client may have received it but may or may not have acknowledged 
it.  If we do resend the message, will that mess up the client?  Does the 
client even care?

There's a whole lot of inefficiencies to.  Consider that there are some cases 
where the client also needs to track what messages have been received. Both the 
client and the hub are tracking the state in this scenario and that's pretty 
inefficient.  I would argue far more inefficient than the polling scenario 
because it involves memory and potentially storage space.  If the client 
doesn't really care to track state we are tracking it at the hub for no reason.

Say we have a client that's tracking sate, maybe saving it to the datastore. 
(We have a lot of customers that do this.)  The client receives a message, but 
before it can save it, it goes down.  Upon coming up again, it has no awareness 
of the lost message, will it be delivered again? How?  How does the client 
inform the hub of it's state?

Other questions arise:  How long should you track clients before you 
unsubscribe them? etc...etc...

There's just so many similar scenarios that add a lot of complexity and I would 
argue, at cloud scale, far greater inefficiencies into the system.

With the polling scenario, the work is split between the server and the client. 
 The server keeps track of the messages.  The client keeps track of it's own 
state (what was the last message received? etc).  It's scalable and, I would 
argue more efficient,  because it allows the client to track state if it wants 
to, when it wants to, how it wants to.  On the server end statelessness means 
that each pubsub node is a carbon copy of another -- if one goes down another 
can replace it with no problem -- no need to transfer sate.  What's more, the 
memory usage of the node is constant, no matter how many clients are hitting it.

That's not to say that polling is always the right choice.  As Mark said, there 
are a lot of factors to consider.  In cases where there are a large number of 
messages latencies may increase dramatically. It's just that when we're talking 
web scale, it is *usually* a good choice.

-jOrGe W.




___
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] live_migration Permission denied

[Jay Pipes]

Hi again, Alex,

The appropriate place to submit these things is either as a bug
report, or as a question on Launchpad Answers.

For questions like this (where you aren't sure if it is a bug or not),
use Launchpad Answers:

http://answers.launchpad.net/nova

Thanks!
-jay

On Thu, Oct 27, 2011 at 6:52 AM, aliex_liu  wrote:
> control node:
> 011-10-27 17:57:41,819 CRITICAL nova [-] UnboundLocalError local variable
> 'filename' referenced before assignment
> [u'Traceback (most recent call last):\n', u'  File
> "/usr/lib/pymodules/python2.6/nova/rpc.py", line 188, in _receive\n    rval
> = node_func(context=ctxt, **node_args)\n', u'  File
> "/usr/lib/pymodules/python2.6/nova/scheduler/manager.py", line 83, in
> _schedule\n    **kwargs)\n', u'  File
> "/usr/lib/pymodules/python2.6/nova/scheduler/driver.py", line 101, in
> schedule_live_migration\n    self._live_migration_common_check(context,
> instance_ref, dest)\n', u'  File
> "/usr/lib/pymodules/python2.6/nova/scheduler/driver.py", line 196, in
> _live_migration_common_check\n
> self.mounted_on_same_shared_storage(context, instance_ref, dest)\n', u'
> File "/usr/lib/pymodules/python2.6/nova/scheduler/driver.py", line 313, in
> mounted_on_same_shared_storage\n    "args": {\'filename\': filename}})\n',
> u"UnboundLocalError: local variable 'filename' referenced before
> assignment\n"]
> (nova): TRACE: Traceback (most recent call last):
> (nova): TRACE:   File "/usr/bin/nova-manage", line 1122, in 
> (nova): TRACE: main()
> (nova): TRACE:   File "/usr/bin/nova-manage", line , in main
> (nova): TRACE: fn(*argv)
> (nova): TRACE:   File "/usr/bin/nova-manage", line 643, in live_migration
> (nova): TRACE: "topic": FLAGS.compute_topic}})
> (nova): TRACE:   File "/usr/lib/pymodules/python2.6/nova/rpc.py", line 385,
> in call
> (nova): TRACE: raise wait_msg.result
> (nova): TRACE: RemoteError: UnboundLocalError local variable 'filename'
> referenced before assignment
>
> compute node:
>
> 2011-10-27 15:09:03,379 ERROR nova [-] Exception during message handling
> (nova): TRACE: Traceback (most recent call last):
> (nova): TRACE:   File "/usr/lib/pymodules/python2.6/nova/rpc.py", line 188,
> in _receive
> (nova): TRACE: rval = node_func(context=ctxt, **node_args)
> (nova): TRACE:   File "/usr/lib/pymodules/python2.6/nova/exception.py", line
> 126, in _wrap
> (nova): TRACE: raise Error(str(e))
> (nova): TRACE: Error: [Errno 13] Permission denied:
> '/var/lib/nova/instances/tmpI5oQvP'
> (nova): TRACE:
> 2011-10-27 15:09:03,379 ERROR nova.rpc [-] return [Errno 13] Permission
> denied: '/var/lib/nova/instances/tmpI5oQvP'  exception
>
> what cause this error,and what should i do?
> 2011-10-27
> 
> aliex_liu
> ___
> 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] Rabbitmq always throw exception

[Jay Pipes]

Hi Alex,

Please use the Launchpad Answers area for asking questions like this.

http://answers.launchpad.net/nova

Thanks,
-jay

On Thu, Oct 27, 2011 at 6:07 AM, aliex_liu  wrote:
> I can log in the instance,and its status is running
> but the rabbitmq.log always throw exception
>
> some of the log:
> =INFO REPORT 27-Oct-2011::18:02:55 ===
> accepted TCP connection on 0.0.0.0:5672 from 192.168.1.10:49119
>
> =INFO REPORT 27-Oct-2011::18:02:55 ===
> starting TCP connection <0.4209.0> from 192.168.1.10:49119
>
> =WARNING REPORT 27-Oct-2011::18:02:55 ===
> exception on TCP connection <0.4209.0> from 192.168.1.10:49119
> connection_closed_abruptly
>
> =INFO REPORT 27-Oct-2011::18:02:55 ===
> closing TCP connection <0.4209.0> from 192.168.1.10:49119
>
> =INFO REPORT 27-Oct-2011::18:03:44 ===
> accepted TCP connection on 0.0.0.0:5672 from 192.168.1.10:49120
>
> =INFO REPORT 27-Oct-2011::18:03:44 ===
> starting TCP connection <0.4422.0> from 192.168.1.10:49120
>
> =WARNING REPORT 27-Oct-2011::18:03:44 ===
> exception on TCP connection <0.4422.0> from 192.168.1.10:49120
> connection_closed_abruptly
>
> =INFO REPORT 27-Oct-2011::18:03:44 ===
> closing TCP connection <0.4422.0> from 192.168.1.10:49120
>
> when i stop the instance,the rabbitmq server will not throw these exceptions
> why? this is OK?
> 2011-10-27
> 
> aliex_liu
> ___
> 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] Compute API schema docs now available

[Anne Gentle]

Oh I can't take the credit at all, Jorge Williams created the xslts.

Turns out, David is still debugging so that examples show, but thanks for
the encouragement!

Anne

 *Anne Gentle*
a...@openstack.org
 my blog  | my
book|
LinkedIn  |
Delicious|
Twitter 
On Fri, Oct 28, 2011 at 2:14 AM, Razique Mahroua
wrote:

> Awesome work !
> You did a splendid job here.
> Thank you
>
> Le 28 oct. 2011 à 05:23, Anne Gentle a écrit :
>
> All,
>
> You can now browse through the Compute API 1.1 schemas here:
>
> http://docs.openstack.org/api/openstack-compute/1.1/xsd/
>
> If other APIs would like to provide schemas, we can use the xslt transforms
> to create these pages for browsing for other APIs. The source files are
> located in http://github.com/openstack/compute-api/ repository.
>
> I haven't figured out yet how to link to this from the
> docs.openstack.org/api landing page but suggestions are welcome.
>
> Thanks to David Cramer for debugging these to get them working.
> Anne
> ___
> 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] Push vs Polling (from Versioning Thread)

[George Reese]

When you look at the scalability issue solely from the perspective of the cloud 
provider, requiring polling is the lazier, but not really more scalable 
solution. Especially if you go nuts with caching. Then it might be even a bit 
more scalable.

But when you look at the distributed systems use cases, it's terrible for the 
system as a whole. People are polling your API because they want to know 
whether or not the state of the system is different from what they "remember" 
it to be. The more critical it is for them to rapidly know about changes, the 
more often they poll. Yes, there are ways to determine when changes are more 
likely to occur and thus optimize the polling interval. Some clients may be, in 
your eyes as the provider, overly aggressive. But who the hell are you to judge 
their use case and throttle them?

But here's the bottom line: The vast majority of work is completely wasted when 
polling is the change propagation method.

Push notifications don't make your core system any more complex. You push the 
change to a message queue and rely on another system to do the work.

The other system is scalable. It has no need to be stateless and can be run in 
an on-demand format using agents to handle the growing/shrinking notification 
needs.

Bryan brings up the point that some of these subscription endpoints may go 
away. That's a total red-herring. You have mechanisms in place to detect failed 
deliveries and unsubscribe after a time (among other strategies). 

The bottom line: When you push changes, the vast majority of your work is 
meaningful work when pushing is the change propagation method.

Let's do the math. Let's say I am interested in any change in VM state so I can 
auto-scale/auto-recover. Let's use a fairly simplistic polling strategy, but do 
it efficiently (and assume the API enables me to make a single API call to get 
state for all VMs). Let's pick 1 query/minute (in reality, you wouldn't pick a 
flat polling rate like this, but it is useful for this thought experiment).

Now multiply that times 1,000 customers. Or 100,000. Or 1,000,000. 

Now let's say that the client is going through a cloud management service. And 
that service is serving 20% of your customer base. They are likely making 
queries across a wide range of resources, not just VMs. And they have to scale 
the polling from their end.

Both sides are thus engaged in trying to figure out a way to scale work that is 
almost entirely pointless work. 

There's a reason you see the cloud management tools "pushing push". We've seen 
this IaaS polling across a bunch of clouds. It sucks.

-George

--
George Reese - Chief Technology Officer, enStratus
e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: 
+1.612.338.5041
enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - 
http://www.enstratus.com
To schedule a meeting with me: http://tungle.me/GeorgeReese



smime.p7s
Description: S/MIME cryptographic signature
___
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] FOSDEM 2012: OpenStack Devroom

[James Bailey]

On 20 October 2011 08:45, Thierry Carrez  wrote:
> James Bailey wrote:
>> On 19 October 2011 16:29, Russell Bryant  wrote:
>>> Hopefully it works out!  I love FOSDEM.
>>>
>>> One thing that might help the application is to note that you're willing to
>>> increase the scope of the devroom if needed.  Preference is given to
>>> requests that cover a domain that includes multiple projects as opposed to
>>> requests for a single project.  So, for example, you could request an
>>> OpenStack devroom, but note that you'd also be willing to expand it to cover
>>> something like "Cloud Infrastructure", and invite other related projects to
>>> participate as well if you can't have just an OpenStack room.
>>
>> This would be something I would be very interested in.
>>
>> last year the Devops room was run pretty much by Puppet labs but they
>> covered Chef/Vagrant, Cfengine, Foreman, Gepetto even some Windows.
>> You could cover the core projects Nova, Swift, Glance and Keystone,
>> then open it up to people like Dell with Barclamp, maybe some of the
>> Storage back end folk getting involved now like Ceph or Nexenta might
>> be interested. I am sure others I can not think of are also
>> interested.
>
> That's very good feedback, thanks !
>
> I will make sure to include that in the application.

Further the Fosdem conversation, Jochen Maes @sejo_it one of the
Fosdem core team is tweeting about wanting more main track proposals,
I think Openstack should be cheeky and apply, if only so I don't have
to camp out for space in the dev room. ;)

It would be nice if who ever in the community is organising this to
post some updates as time goes on.

Jim :)

___
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] OpenSTack Minimum Spec

[Frans Thamura]

thx for the reply..

i use this spec P4 1.5GB, Dell Optiplex i believe..

but i love if the spec that i create, confirmed good enough for student to
learn

F


2011/10/28 Diego Parrilla Santamaría 

> Frans,
>
> the single node configuration of the Stackops Distro can work in very
> modest environments. A P4 and 1.5GB should be enough if you want to deploy
> m1.tiny instances with QEMU. If you want to manage the deployment in a
> training lab probably you should check the tool.
>
> Cheers
> Diego
> -
> --
> Diego Parrilla
> *CEO*
> *www.stackops.com | * diego.parri...@stackops.com** | +34 649 94 43 29 |
> skype:diegoparrilla*
> * 
> *
>
> *
>
>  ADVERTENCIA LEGAL 
> Le informamos, como destinatario de este mensaje, que el correo electrónico
> y las comunicaciones por medio de Internet no permiten asegurar ni
> garantizar la confidencialidad de los mensajes transmitidos, así como
> tampoco su integridad o su correcta recepción, por lo que STACKOPS
> TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias.
> Si no consintiese en la utilización del correo electrónico o de las
> comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro
> conocimiento de manera inmediata. Este mensaje va dirigido, de manera
> exclusiva, a su destinatario y contiene información confidencial y sujeta al
> secreto profesional, cuya divulgación no está permitida por la ley. En caso
> de haber recibido este mensaje por error, le rogamos que, de forma
> inmediata, nos lo comunique mediante correo electrónico remitido a nuestra
> atención y proceda a su eliminación, así como a la de cualquier documento
> adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o
> utilización de este mensaje, o de cualquier documento adjunto al mismo,
> cualquiera que fuera su finalidad, están prohibidas por la ley.
>
> * PRIVILEGED AND CONFIDENTIAL 
> We hereby inform you, as addressee of this message, that e-mail and
> Internet do not guarantee the confidentiality, nor the completeness or
> proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L.
> does not assume any liability for those circumstances. Should you not agree
> to the use of e-mail or to communications via Internet, you are kindly
> requested to notify us immediately. This message is intended exclusively for
> the person to whom it is addressed and contains privileged and confidential
> information protected from disclosure by law. If you are not the addressee
> indicated in this message, you should immediately delete it and any
> attachments and notify the sender by reply e-mail. In such case, you are
> hereby notified that any dissemination, distribution, copying or use of this
> message or any attachments, for any purpose, is strictly prohibited by law.
>
>
>
>
>
> On Fri, Oct 28, 2011 at 7:21 AM, Frans Thamura  wrote:
>
>> hi all
>>
>> i am writing specification for polytechnics related for lab,
>>
>> the regulator said, 1 PC must be for 1 student
>>
>> and several polytechnics have limited budget
>>
>> can share all?
>>
>> i have Pentium 4, run in single node :) but i think multicore
>> processor are better,
>>
>> so for play around i recommend i7, for server i recommend 2 core Xeon for
>> lab.
>>
>>
>> my plan
>>
>> 1 PC = 1 student
>>
>> we will create group, to make student can do multinode.
>>
>>
>>
>> --
>> Frans Thamura (曽志胜)
>> Chief of Advisory
>> Meruvian.
>> Integrated Hypermedia Java Solution Provider.
>>
>> Mobile: +628557888699
>> Blog: http://blogs.mervpolis.com/roller/flatburger (id)
>>
>> FB: http://www.facebook.com/meruvian
>> TW: http://www.twitter.com/meruvian / @meruvian
>> Website: http://www.meruvian.org
>>
>> "We grow because we share the same belief."
>>
>> ___
>> 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] Meeting time changes due to end of DST

[Thierry Carrez]

Hi everyone,

We are entering the bi-annual two-week period of meeting time disruption
! Europe ends DST on Sunday, Oct 30. The US ends DST on Sunday, Nov 6.
Other countries may vary...

The meeting times are announced in UTC time, so please doublecheck how
that translates in your timezone for the following weeks.

Resources:

http://www.timeanddate.com/worldclock/fixedtime.html?iso=2001T21
translates UTC time for you, just replace date and time to query your
own meeting time.

http://wiki.openstack.org/Meetings
has a complete list, together with a link to a GMT-aligned iCal feed
that should continue to work over the next weeks !

Cheers,

-- 
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] OpenSTack Minimum Spec

[Diego Parrilla Santamaría]

Frans,

the single node configuration of the Stackops Distro can work in very modest
environments. A P4 and 1.5GB should be enough if you want to deploy m1.tiny
instances with QEMU. If you want to manage the deployment in a training lab
probably you should check the tool.

Cheers
Diego
-
-- 
Diego Parrilla
*CEO*
*www.stackops.com | * diego.parri...@stackops.com** | +34 649 94 43 29 |
skype:diegoparrilla*
* 
*

*

 ADVERTENCIA LEGAL 
Le informamos, como destinatario de este mensaje, que el correo electrónico
y las comunicaciones por medio de Internet no permiten asegurar ni
garantizar la confidencialidad de los mensajes transmitidos, así como
tampoco su integridad o su correcta recepción, por lo que STACKOPS
TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias.
Si no consintiese en la utilización del correo electrónico o de las
comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro
conocimiento de manera inmediata. Este mensaje va dirigido, de manera
exclusiva, a su destinatario y contiene información confidencial y sujeta al
secreto profesional, cuya divulgación no está permitida por la ley. En caso
de haber recibido este mensaje por error, le rogamos que, de forma
inmediata, nos lo comunique mediante correo electrónico remitido a nuestra
atención y proceda a su eliminación, así como a la de cualquier documento
adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o
utilización de este mensaje, o de cualquier documento adjunto al mismo,
cualquiera que fuera su finalidad, están prohibidas por la ley.

* PRIVILEGED AND CONFIDENTIAL 
We hereby inform you, as addressee of this message, that e-mail and Internet
do not guarantee the confidentiality, nor the completeness or proper
reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. does
not assume any liability for those circumstances. Should you not agree to
the use of e-mail or to communications via Internet, you are kindly
requested to notify us immediately. This message is intended exclusively for
the person to whom it is addressed and contains privileged and confidential
information protected from disclosure by law. If you are not the addressee
indicated in this message, you should immediately delete it and any
attachments and notify the sender by reply e-mail. In such case, you are
hereby notified that any dissemination, distribution, copying or use of this
message or any attachments, for any purpose, is strictly prohibited by law.





On Fri, Oct 28, 2011 at 7:21 AM, Frans Thamura  wrote:

> hi all
>
> i am writing specification for polytechnics related for lab,
>
> the regulator said, 1 PC must be for 1 student
>
> and several polytechnics have limited budget
>
> can share all?
>
> i have Pentium 4, run in single node :) but i think multicore
> processor are better,
>
> so for play around i recommend i7, for server i recommend 2 core Xeon for
> lab.
>
>
> my plan
>
> 1 PC = 1 student
>
> we will create group, to make student can do multinode.
>
>
>
> --
> Frans Thamura (曽志胜)
> Chief of Advisory
> Meruvian.
> Integrated Hypermedia Java Solution Provider.
>
> Mobile: +628557888699
> Blog: http://blogs.mervpolis.com/roller/flatburger (id)
>
> FB: http://www.facebook.com/meruvian
> TW: http://www.twitter.com/meruvian / @meruvian
> Website: http://www.meruvian.org
>
> "We grow because we share the same belief."
>
> ___
> 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] describing APIs for OpenStack consumers

[Bryan Taylor]

On 10/27/2011 05:52 PM, Mark Nottingham wrote:

Generating WADL (or anything else) from code is fine, as long as we have the 
processes / tools (e.g., CI) in place to assure that a trivial code change 
doesn't make a backwards-incompatible change in what we expose to clients.

You bring up a really good point here.

Do we?


I doubt it. I vaguely recall there were WSDL backwards compatibility 
checkers, which implies there must be XSD backwards compatibility 
checkers.  I don't know of anything that can do this for WADL. And 
without some mechanism to define a JSON format in a machine readable 
way, I'm not even sure how you could possibly accomplish this for JSON.



(really, we should have these in place regardless of how things are generated)

We should.



___
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] Compute API schema docs now available

[Razique Mahroua]

Awesome work !
You did a splendid job here.
Thank you

Le 28 oct. 2011 à 05:23, Anne Gentle a écrit :

> All, 
> 
> You can now browse through the Compute API 1.1 schemas here: 
> 
> http://docs.openstack.org/api/openstack-compute/1.1/xsd/
> 
> If other APIs would like to provide schemas, we can use the xslt transforms 
> to create these pages for browsing for other APIs. The source files are 
> located in http://github.com/openstack/compute-api/ repository.
> 
> I haven't figured out yet how to link to this from the docs.openstack.org/api 
> landing page but suggestions are welcome. 
> 
> Thanks to David Cramer for debugging these to get them working. 
> 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

Re: [Openstack] Push vs Polling (from Versioning Thread)

[Bryan Taylor]

On 10/27/2011 02:14 PM, Monsyne Dragon wrote:

The web was not designed to deal with a bunch of clients needing to
know about infrastructure changes the instant they happen.

True.  This whole issue is the reason Nova's existing notification system  is 
designed  as a push system.  Currently it's used to push error notifications 
and usage info, but there is no reason it could not eventually also provide 
notifications to end users.  After watching demos of large cloud users where 
they were polling apis to see when their instances were ready (and often 
spinning up new ones when that didn't happen fast enough)
I kept that use case in mind when coding the notifications system.
You are really doing ATOM + PSH, so you offer both push and pull models 
to clients, right?


The standard way to do long running operations is to POST and get back a 
request resource that you poll to see the status and preferably some 
kind of progress metric. It will eventually link to the outputs. 
Contrast this with a system where they submit their request and wait to 
hear back when it's done.  In both cases, let's say their request takes 
45 seconds to complete. After 30 seconds they get impatiant. In the 
first scenario they reload the request resource hoping its done and see 
their request is at 67%. They refresh 3 times in 6 seconds and see it's 
80% done. In the push scenario all they know is they haven't gotten word 
it's done. There's no way for them to take action to find out anything 
or ask for progress.


Expecting the requester to watch a feed until their item shows up is 
bad, because they really want a high resolution look at their request, 
not a course grained look across all requests, so give them a resource 
suitable for their use case. It's like asking a sports fan to watch the 
news to find out who wins. They want to watch their team, not know who 
wins. Other people just want to know who wins, for all the games. It's 
different views into the same events.

No, it doesn't. You push changes as they occur to a message queue. A
separate system tracks subscribers and sends them out. There is no
conversational state if done right.

Indeed. this is how the notifications system is/can work right now. If you turn 
notifications on, nova pushes them to a rabbit queue.  A separate app, namely a 
hub using the standard PubSubHubbub protocol, (plus an external rabbit queue -> 
 feed generator app we wrote, called Yagi) manages the subscriptions and pings the 
subscribers.
I'll be one of your clients, actually. I don't think PubSubHubbub helps 
me much. Pitch me on why it's worth my time to go understand its 
registration protocol and why I should implement a server and poke holes 
in firewalls for you to call me as opposed to just running a cron job 
that unrolls the new pages of the feed to the end and sleeps. There's a 
reason this model won out.


An arguable advantage to a client is that I get slightly better data 
latency. But I'm polling within my data latency needs already.



Push notifications are the only mechanism for solving the scaling issue.
You push any changes to a message queue. Agents pick up the changes and
send them on to subscriber endpoints. Not that hard.

Not that hard with a few fairly reliable clients. Very hard with a web scale 
set of unreliable clients while I simultaneously need to scale the back end.

Actually, we are already implementing this at 200+node scale in nova, since 
this is  how we are handling the collection of  usage data for billing.  At the 
moment is seems to be working reasonably well. We are not using the  PSH hubs 
atm, since we are pushing to a few internal consumers via AtomPub, and don't 
need the complex subscription management, but from our point of view, pinging a 
hub is no different from what we already do, and the hub handles the 
subscription details.
You advocate ATOM + PSH and I advocate ATOM + cache. The big difference 
is that clients have to know and care about PSH to use it, whereas with 
a cache, they don't.



It would be nice to one day support notifications of end-users, as I think it 
would be of great benefit to them. There's work that would need to be done 
around hub/Yagi auth, and I think there is some bigger fish to fry, nova 
functionality-wise at the moment, but it is something to keep in mind.

Let Repose handle auth for you and add a varnish cache in front of your 
atom feed and let them poll you. Done. You might want rate limiting that 
favors conditional GETs, but the Repose team should handle that.




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