Re: [Openstack] [OpenStack] preallocation

[Vishvananda Ishaya]

You can disable using backing files with the following config:
use_cow_images=false

You should be aware that you likely won't be able to snapshot images unless you 
make sure to upload them all in qcow format and also set:
force_raw_images=false

On Apr 9, 2012, at 9:37 PM, William Herry wrote:

> Hi
> 
> I read from an article that said use preallocation can improve disk I/O 
> performance in kvm, when I add it to openstack, suck error come to me
> 
> (nova.rpc.amqp): TRACE: Stderr: 'Backing file and preallocation cannot be 
> used at the same time\nqemu-img: 
> /usr/local/lib/python2.7/dist-packages/nova-2012.1-py2.7.egg/instances/instance-000e/disk:
>  error while creating qcow2: Invalid argument\n'
> 
> I was added it to utils.py in virt/libvirt directory (line 77)
> 
> def create_cow_image(backing_file, path):
> """Create COW image
> 
> Creates a COW image with the given backing file
> 
> :param backing_file: Existing image on which to base the COW image
> :param path: Desired location of the COW image
> """
> execute(FLAGS.qemu_img, 'create', '-f', 'qcow2', '-o',
>  'preallocation=metadata,cluster_size=2M,backing_file=%s' %
>   backing_file, path)
> 
> here is the article: 
> http://itscblog.tamu.edu/improve-disk-io-performance-in-kvm/
> 
> so what is Backing file for, can I disable it for use preallocation cause I 
> can't got both
> 
> Thanks
> 
> -- 
> 
> ===
> William Herry
> 
> williamherrych...@gmail.com
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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

[Openstack] [OpenStack] preallocation

[William Herry]

Hi

I read from an article that said use preallocation can improve disk I/O
performance in kvm, when I add it to openstack, suck error come to me

(nova.rpc.amqp): TRACE: Stderr: 'Backing file and preallocation cannot be
used at the same time\nqemu-img:
/usr/local/lib/python2.7/dist-packages/nova-2012.1-py2.7.egg/instances/instance-000e/disk:
error while creating qcow2: Invalid argument\n'

I was added it to utils.py in virt/libvirt directory (line 77)

def create_cow_image(backing_file, path):
"""Create COW image

Creates a COW image with the given backing file

:param backing_file: Existing image on which to base the COW image
:param path: Desired location of the COW image
"""
execute(FLAGS.qemu_img, 'create', '-f', 'qcow2', '-o',
 'preallocation=metadata,cluster_size=2M,backing_file=%s' %
  backing_file, path)

here is the article:
http://itscblog.tamu.edu/improve-disk-io-performance-in-kvm/

so what is Backing file for, can I disable it for use preallocation cause I
can't got both

Thanks

-- 

===
William Herry

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

Re: [Openstack] Image API v2 Draft 4

[Monty Taylor]

On 04/09/2012 04:11 PM, Jay Pipes wrote:
> On 04/09/2012 07:07 PM, Jorge Williams wrote:
>>
>> On Apr 9, 2012, at 6:03 PM, Justin Santa Barbara wrote:
>>
>>> How about we discuss this further at the summit :-)
>>>
>>>
>>> I think that's a sensible proposal. We're not likely to reach a good
>>> conclusion here. I think my viewpoint is that even json-dressed-as-xml
>>> is fine; no end-user gives two hoots what our JSON/XML/HPSTR looks
>>> like. I'd wager most users of the EC2 API have never even seen the
>>> data representation!
>>
>>
>> I take it you didn't attend the glorious JSON debate of a couple of
>> summits ago :-)
> 
> Glorious it was indeed.
> 
>> I'm up for round two,
> 
> Only with beer. :) I still owe you a couple I think!

I refuse to not be there for that. Please make sure I'm in the room.
With a video camera. And a bottle of whiskey.

Monty

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

[Openstack] [OpenStack]Swift + Keystone + Cyberduck

[William Herry]

Hi

I am try to use Cyberduck as the client of Swift storage, my swift use
keystone as the auth system, any one has successful experience can share
with me, or is there any other client software for swift

In fact I can't make Cyberduck work when I use tempauth as the auth, which
can work with cloudberry and cloudfuse, but as I know, in windows only
Cyberduck can support Keystone

Thanks

William

-- 

===
William Herry

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

Re: [Openstack] Image API v2 Draft 4

[Luis Gervaso]

Hi,

I have been fighting with these issues.

Here is the proposed solution i am currently using on OpenStack Java SDK.

*Every representation should implement a common interface*

The jaxb annotations for marshalling and unmarshalling XML reside on xml
implementation class
The gson annotations for serialization and deserialization of JSON reside
on json implementation class

This approach is unobstrussive with XML/JSON representations

I think 95% of the API works well mixing jaxb/gson annotations on the same
implementation classes.

This has another advantage, you can switch from one to another service
provider sharing the same model,
that's the interfaces model but the implentation.

Does it make sense for you?

Luis

On Tue, Apr 10, 2012 at 1:11 AM, Jay Pipes  wrote:

> On 04/09/2012 07:07 PM, Jorge Williams wrote:
>
>>
>> On Apr 9, 2012, at 6:03 PM, Justin Santa Barbara wrote:
>>
>> How about we discuss this further at the summit :-)
>>>
>>>
>>> I think that's a sensible proposal. We're not likely to reach a good
>>> conclusion here. I think my viewpoint is that even json-dressed-as-xml
>>> is fine; no end-user gives two hoots what our JSON/XML/HPSTR looks
>>> like. I'd wager most users of the EC2 API have never even seen the
>>> data representation!
>>>
>>
>>
>> I take it you didn't attend the glorious JSON debate of a couple of
>> summits ago :-)
>>
>
> Glorious it was indeed.
>
>
>  I'm up for round two,
>>
>
> Only with beer. :) I still owe you a couple I think!
>
>  -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
>



-- 
---
Luis Alberto Gervaso Martin
Woorea Solutions, S.L
CEO & CTO
mobile: (+34) 627983344
luis@ woorea.es
___
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] Image API v2 Draft 4

[Jay Pipes]

On 04/09/2012 07:07 PM, Jorge Williams wrote:


On Apr 9, 2012, at 6:03 PM, Justin Santa Barbara wrote:


How about we discuss this further at the summit :-)


I think that's a sensible proposal. We're not likely to reach a good
conclusion here. I think my viewpoint is that even json-dressed-as-xml
is fine; no end-user gives two hoots what our JSON/XML/HPSTR looks
like. I'd wager most users of the EC2 API have never even seen the
data representation!



I take it you didn't attend the glorious JSON debate of a couple of
summits ago :-)


Glorious it was indeed.


I'm up for round two,


Only with beer. :) I still owe you a couple I think!


-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] Image API v2 Draft 4

[Jorge Williams]

On Apr 9, 2012, at 6:03 PM, Justin Santa Barbara wrote:

How about we discuss this further at the summit :-)

I think that's a sensible proposal.  We're not likely to reach a good 
conclusion here.  I think my viewpoint is that even json-dressed-as-xml is 
fine; no end-user gives two hoots what our JSON/XML/HPSTR looks like.  I'd 
wager most users of the EC2 API have never even seen the data representation!


I take it you didn't attend the glorious JSON debate of a couple of summits ago 
:-)

I'm up for round two,

-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] Image API v2 Draft 4

[Justin Santa Barbara]

>
> Extensible lists are pointless. Lists have no attributes other than their
> length. I made this point a couple design summits ago... but whatever :)


Looks like the Sapir-Whorf hypothesis might be true after all ;-)

Let's dust off the pugil-sticks for the design summit..
___
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] Image API v2 Draft 4

[Justin Santa Barbara]

>
> How about we discuss this further at the summit :-)
>

I think that's a sensible proposal.  We're not likely to reach a good
conclusion here.  I think my viewpoint is that even json-dressed-as-xml is
fine; no end-user gives two hoots what our JSON/XML/HPSTR looks like.  I'd
wager most users of the EC2 API have never even seen the data
representation!
___
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] Image API v2 Draft 4

[Jorge Williams]

Justin,

>From a JAX-RS / Java  persecutive, starting with an XML schema and having that 
>dictate what the JSON will look like -- doesn't just make sense -- it makes 
>life *A LOT* easier. And a lot of services written in Java do just that.   
>Unfortunately, as you pointed out, this approach has the  tendency to create 
>very  unJSONic JSON -- in that case JSON is just an afterthought..it's a 
>second class citizen -- essentially it's XML with curly braces...and that 
>doesn't jive well with dynamic languages.

You can go the other route and start from JSON to create XML -- and some well 
intended folks do this, but you end up in the other direction...essentially you 
have , which is essentially JSON in XML form.  That kind of XML sucks 
and it's pretty useless if you work with static languages like Java and .Net -- 
where having a static (but extensible) schema is really useful.

That's the world we live in today...static languages work really well with XML 
and dynamic languages work really well with JSON.  In my opinion, you have to 
account for both and treat both as first class citizens.   I'd vote for having 
an abstract model and treat the XML and JSON  as different renderings.   Doing 
so is not easy as pie -- but it's not rocket science either.

I am totally with you on a couple of points though:

1.  We do need to differentiate between user data and core attributes. Jay and 
I have had debates about this before.
2.  Having entirely dynamic discoverable schema, seems nice, but it has the 
potential to introduce a lot of complexity.   In particular, i'm not exactly 
sure how to process the schema and  keep the goodness that comes from using a 
statically typed language.   And, as you point out,  it's not clear how one 
would support multiple media types given that approach.

How about we discuss this further at the summit :-)

-jOrGe W.


On Apr 9, 2012, at 4:14 PM, Justin Santa Barbara wrote:

When you're designing JSON considering only JSON, you'd probably use {
key1: value1 } - as you have done.  If you're designing generically,
you'd probably use { key: key1, value: value1 }.

You mean we'd have to do dumb crap because XML doesn't have the native concept 
of a list? ;)

XML has lists, as does Avro, ProtocolBuffers & Thrift.  XML supports extensible 
lists, which is why the syntax is different.


You'd *think* this would work. In practice, however, it really doesn't. Neither 
does (good, valid) code generation...

Of course it works!  Every JAX-RS webserver does this.  You just can't start 
with JSON first and expect everything to magically be OK.

If you think it doesn't work, can you provide an example?

You start with an abstract model, and then check what it looks like in JSON, in 
XML, in ProtocolBuffers, in Avro, in Thrift, in HPSTR, etc...  If you start 
with JSON, then of course it won't work.  If we're going to treat XML as an 
afterthought, then I'd rather we just didn't support XML at all (and yes, I 
absolutely mean that - it is good that Glance is honest that they don't support 
XML.)

Even ignoring XML, I can't help but think that not having a strict delineation 
between user-provided data and the structure of your document is a pretty risky 
idea.


In the 2.0 API we *are* specifying it in JSON. JSON Schema, specifically...

Are JSON schemas an April Fool's joke?  Once you introduce schemas, you might 
as well just go with XML ;-)

> I think the only thing you need to avoid is
"no changing-at-runtime keys"; I think this makes it compatible
with XML, Avro, ProtocolBuffers & Thrift.

That is antithetical to having dynamic, but discoverable, schemas. JSON Schema 
(and XSD, fwiw) provide things like additionalProperties and  for just 
this sort of thing. Making a schema entirely static is really only useful for 
generating (bad and soon-to-be-outdated) client code.

Having dynamic and discoverable schemas enables clients to respond to 
backwards-compatible schema changes (like the addition of standard properties 
or the addition of "extra-standard" additionalProperties) without having to 
recompile a client or change any client code at all...

I couldn't disagree more: "what does it mean"?  There's the implicit contract 
underlying the interface; the semantics that underpin the syntax.  e.g. syntax: 
a glance image id is a string, semantics: the id is unique to a glance 
installation and is used to refer to an image in REST calls.

xsd:any allows you to put elements _from another schema_ into your XML 
document.  That foreign schema defines the semantics of those elements.  It's 
schemas all the way down, giving semantics to your syntax.

If your additional properties in Glance are properly schematized, then that's 
great.  But true cross-representation schemas are an open problem, I believe, 
so you're really painting yourself into a corner (how do you support XML 
output, if you let people upload arbitrary JSON schemas?)


Incidentally, I just heard about yet another new format - 

[Openstack] Agreeing a common set of Image Properties

[Justin Santa Barbara]

>
>
>> Are the major and minor numbers going to be sufficient versioning
>>> information? See for example PEP 386 for more detailed version strings (
>>> http://www.python.org/dev/peps/pep-0386/).
>>>
>>
>> For a distro, I believe yes.  Do you have a counter-example?
>>
>
> Not off the top of my head, but I really only use RedHat variants or
> Ubuntu variants, so I thought I would bring it up in case there are others
> that use different schemes. For example, how about pre-releases?
>

Good point (and ick!)  I like the PEP 386 / maven idea; non-official
releases get a suffix like "minor=0-SNAPSHOT" or "minor-0-beta1" or
"minor=0-20120401"?



> It seems suboptimal, but I guess it's reasonable to expect the caller of
> the API to be able to provide the distro-specific package name for the
> application or library they want included in the image.
>

I expect the most common use-case is that the caller wants e.g. Debian
Squeeze + a list of packages (openssh-server, mysql-server, nginx,
apache2).  It might see the following images:

#1 has packages: openssh-server
#2 has packages: openssh-server, mysql-server
#3 has packages: openssh-server, mysql-server, nginx, gnome-desktop

Now it could choose #1, in which case it know it needs to install mysql,
nginx + apache2.  It's always better to install #2, which avoids
downloading & installing mysql-server.

#3 may or may not be "better"; the caller may have to uninstall
gnome-desktop to reduce the attack surface area; that may be more expensive
than starting with #2.  I imagine most callers will actually choose an
image which has a strict subset of images; it's simpler.

That raises two issues: should openssh-server be listed (and what about
hypervisor specific packages)?  What do we do about meta-packages (like
gnome-desktop)?

The easy answer here is that the name of every installed package is listed
(as generated by the system package list tool e.g. dpkg).  But that would
be a big list...
___
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] Image API v2 Draft 4

[Jay Pipes]

On 04/09/2012 05:14 PM, Justin Santa Barbara wrote:

When you're designing JSON considering only JSON, you'd probably
use {

key1: value1 } - as you have done.  If you're designing generically,
you'd probably use { key: key1, value: value1 }.


You mean we'd have to do dumb crap because XML doesn't have the
native concept of a list? ;)


XML has lists, as does Avro, ProtocolBuffers & Thrift.  XML supports
extensible lists, which is why the syntax is different.


Extensible lists are pointless. Lists have no attributes other than 
their length. I made this point a couple design summits ago... but 
whatever :)



You'd *think* this would work. In practice, however, it really
doesn't. Neither does (good, valid) code generation...

Of course it works!  Every JAX-RS webserver does this.  You just can't
start with JSON first and expect everything to magically be OK.


I'm not aware that I said to "start with JSON first and expect 
everything to magically be OK". I believe I put both JSON Schema and 
XSDs in the Images API 2.0 proposal?



If you think it doesn't work, can you provide an example?


I was referring specifically to the Keystone Legacy code that attempted 
to generate JSON from XSDs and WADLs. But for the life of me, I can't 
now find the code in GitHub that shows what I'm talking about... meh.



You start with an abstract model, and then check what it looks like in
JSON, in XML, in ProtocolBuffers, in Avro, in Thrift, in HPSTR, etc...


I'm not opposed to using an abstract model, I was just saying that the 
"easy as pie" solution you offered of "just having to create a new 
generator, etc" isn't in practice so easy and often leads to 
hard-to-debug subtle differences in output format that aren't fixable 
just be "editing the abstract model"...



  If you start with JSON, then of course it won't work. If we're going
to treat XML as an afterthought, then I'd rather we just didn't support
XML at all (and yes, I absolutely mean that - it is good that Glance is
honest that they don't support XML.)


Glad we took the high road ;P


Even ignoring XML, I can't help but think that not having a strict
delineation between user-provided data and the structure of your
document is a pretty risky idea.


Not quite sure I follow you here... are you referring to dynamic schemas 
here?



In the 2.0 API we *are* specifying it in JSON. JSON Schema,
specifically...

Are JSON schemas an April Fool's joke?  Once you introduce schemas, you
might as well just go with XML ;-)


I personally find JSON Schema to be as robust, and infinitely more 
readable, as XSD.



 > I think the only thing you need to avoid is

"no changing-at-runtime keys"; I think this makes it compatible
with XML, Avro, ProtocolBuffers & Thrift.

That is antithetical to having dynamic, but discoverable, schemas.
JSON Schema (and XSD, fwiw) provide things like additionalProperties
and  for just this sort of thing. Making a schema entirely
static is really only useful for generating (bad and
soon-to-be-outdated) client code.

Having dynamic and discoverable schemas enables clients to respond
to backwards-compatible schema changes (like the addition of
standard properties or the addition of "extra-standard"
additionalProperties) without having to recompile a client or change
any client code at all...

I couldn't disagree more: "what does it mean"?  There's the implicit
contract underlying the interface; the semantics that underpin the
syntax.  e.g. syntax: a glance image id is a string, semantics: the id
is unique to a glance installation and is used to refer to an image in
REST calls.


I think you're muddying WADL and XSD above?


xsd:any allows you to put elements _from another schema_ into your XML
document.  That foreign schema defines the semantics of those elements.
  It's schemas all the way down, giving semantics to your syntax.


That's exactly what JSON Schema's additionalProperties allows...


If your additional properties in Glance are properly schematized, then
that's great.  But true cross-representation schemas are an open
problem, I believe, so you're really painting yourself into a corner
(how do you support XML output, if you let people upload arbitrary JSON
schemas?)


They are absolutely properly schematized. They are nothing more than 
false (indicating the schema is fixed) or a list of other schemas...



Incidentally, I just heard about yet another new format - apparently
this one is going to be the standard for use with node.js
- Hypertext-Powered-State-__Transfer-Representation.

HPSTR? H(i)PST(e)R? Are you sure that wasn't an April Fool's Joke? :)

Are you sure it wasn't mine? ;-)


:)

-jay

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

Re: [Openstack] Image API v2 Draft 4

[Justin Santa Barbara]

>
> When you're designing JSON considering only JSON, you'd probably use {
>>
> key1: value1 } - as you have done.  If you're designing generically,
>> you'd probably use { key: key1, value: value1 }.
>>
>
> You mean we'd have to do dumb crap because XML doesn't have the native
> concept of a list? ;)


XML has lists, as does Avro, ProtocolBuffers & Thrift.  XML supports
extensible lists, which is why the syntax is different.



> You'd *think* this would work. In practice, however, it really doesn't.
>> Neither does (good, valid) code generation...
>
>
Of course it works!  Every JAX-RS webserver does this.  You just can't
start with JSON first and expect everything to magically be OK.

If you think it doesn't work, can you provide an example?

You start with an abstract model, and then check what it looks like in
JSON, in XML, in ProtocolBuffers, in Avro, in Thrift, in HPSTR, etc...  If
you start with JSON, then of course it won't work.  If we're going to treat
XML as an afterthought, then I'd rather we just didn't support XML at all
(and yes, I absolutely mean that - it is good that Glance is honest that
they don't support XML.)

Even ignoring XML, I can't help but think that not having a strict
delineation between user-provided data and the structure of your document
is a pretty risky idea.


In the 2.0 API we *are* specifying it in JSON. JSON Schema, specifically...
>

Are JSON schemas an April Fool's joke?  Once you introduce schemas, you
might as well just go with XML ;-)


> > I think the only thing you need to avoid is
>
>> "no changing-at-runtime keys"; I think this makes it compatible
>> with XML, Avro, ProtocolBuffers & Thrift.
>>
>
> That is antithetical to having dynamic, but discoverable, schemas. JSON
> Schema (and XSD, fwiw) provide things like additionalProperties and
>  for just this sort of thing. Making a schema entirely static is
> really only useful for generating (bad and soon-to-be-outdated) client code.
>

> Having dynamic and discoverable schemas enables clients to respond to
> backwards-compatible schema changes (like the addition of standard
> properties or the addition of "extra-standard" additionalProperties)
> without having to recompile a client or change any client code at all...


I couldn't disagree more: "what does it mean"?  There's the implicit
contract underlying the interface; the semantics that underpin the syntax.
 e.g. syntax: a glance image id is a string, semantics: the id is unique to
a glance installation and is used to refer to an image in REST calls.

xsd:any allows you to put elements _from another schema_ into your XML
document.  That foreign schema defines the semantics of those elements.
 It's schemas all the way down, giving semantics to your syntax.

If your additional properties in Glance are properly schematized, then
that's great.  But true cross-representation schemas are an open problem, I
believe, so you're really painting yourself into a corner (how do you
support XML output, if you let people upload arbitrary JSON schemas?)


Incidentally, I just heard about yet another new format - apparently
>> this one is going to be the standard for use with node.js
>> - Hypertext-Powered-State-**Transfer-Representation.
>>
>
> HPSTR? H(i)PST(e)R? Are you sure that wasn't an April Fool's Joke? :)
>

Are you sure it wasn't mine? ;-)
___
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] Agreeing a common set of Image Properties

[Doug Hellmann]

On Mon, Apr 9, 2012 at 12:40 PM, Justin Santa Barbara
wrote:

> On Mon, Apr 9, 2012 at 8:18 AM, Doug Hellmann  > wrote:
>
>> I'm thinking of the os prefix as standing for OpenStack, not Operating
>>> System.
>>>
>>
>> I would never have guessed that from the context. Why OpenStack instead
>> of Operating System?
>>
>
> We reserve this limited region of the namespace (openstack.org: or os:)
> for keys that we agree to have general meaning.  In return for not using
> that prefix for their own purposes, anyone uploading images knows that
> there will no collisions, no matter what cloud that image lands on, and no
> matter what additional values openstack.org defines in the future.
>

That makes sense.


>
> In general, I'd suggest that prefixing custom properties with your domain
> name is "a good idea" for the long term, but that's a separate issue.
>
> Sounds like you'd prefer openstack.org:version or openstack.org:os_version.
>  Both work for me, I think I prefer the second.
>

I do, too.


>
>
>> Are the major and minor numbers going to be sufficient versioning
>> information? See for example PEP 386 for more detailed version strings (
>> http://www.python.org/dev/peps/pep-0386/).
>>
>
> For a distro, I believe yes.  Do you have a counter-example?
>

Not off the top of my head, but I really only use RedHat variants or Ubuntu
variants, so I thought I would bring it up in case there are others that
use different schemes. For example, how about pre-releases?


>
>   The package names may vary depending on the platform, so the names
>> probably shouldn't be tied to the names of the packages themselves but to
>> the projects. Or maybe that's just a taxonomy problem that should be left
>> up to the taggers.
>>
>
> Absolutely.  The package name would be meaningful/comparable only after
> the distro/major/minor combo.  I can't imagine any distro changing package
> names within a release.  So we really do defer this issue to the distro.
>

It seems suboptimal, but I guess it's reasonable to expect the caller of
the API to be able to provide the distro-specific package name for the
application or library they want included in the image.
___
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] Image API v2 Draft 4

[Kiall Mac Innes]

On Mon, Apr 9, 2012 at 7:16 PM, Justin Santa Barbara wrote:
>
> When you're designing JSON considering only JSON, you'd probably use {
> key1: value1 } - as you have done.  If you're designing generically, you'd
> probably use { key: key1, value: value1 }.
>

I, literally. die a little inside each and every time I see this kind of
JSON. Once you start producing JSON like this, you may as well just stick
with XML. Parsing it will be easier.

JSON and XML have different strengths and weaknesses, if you only allow the
common ground of functionality to be used you end up with a mediocre at
best implementation of both.

Thanks,
Kiall
___
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] Image API v2 Draft 4

[Jay Pipes]

On 04/09/2012 02:16 PM, Justin Santa Barbara wrote:

Justin, what does "design a model which works with XML" mean?

Simply avoiding the handful of things that are specific to JSON (or
specific to XML).  Nothing too onerous (no angle brackets)!


I see, gotcha.


I think this is only done in the image properties.

No, the image properties have been removed in the 2.0 Images API and
replaced with the standard concept of "tags":


https://docs.google.com/__document/d/1rb7ZVn0Du___5NZqUyQpqUZSmv7Qd66TMHYAtvsow7__LH4/edit#heading=h.__y10rq9pdt27y



I was looking at properties in "GET /schemas/image/access" and "GET
/schemas/access".  In general, the Glance 2.0 model is very close to
being XML-compatible.


OK.


On the downside: The JSON isn't as JSON-ic as it could be.

In what ways?

When you're designing JSON considering only JSON, you'd probably use {
key1: value1 } - as you have done.  If you're designing generically,
you'd probably use { key: key1, value: value1 }.


You mean we'd have to do dumb crap because XML doesn't have the native 
concept of a list? ;)



On the upside: You need never worry about XML again

We haven't worried about it at all up until now. And Glance has been
perfectly fine without it. ;)

Well yes, I agree that our XML support generally is sufficiently buggy
as to be unusable, hence unused.  I don't actually care about XML, I
just care about having a well-specified API that works.


I wasn't actually talking about Nova. :) Glance doesn't have ANY support 
for XML at all. It's been using JSON and only JSON from its inception... 
 And for the record, we will absolutely NOT be generating JSON from XML 
schemas. That is pure lunacy.



In my opinion, the way to do that is to specify a model, and we have
JSON and XML representations of that model.  If we design the model
right, JSON & XML both "just work" without any code (and less code =
less bugs).


I shall refer you to Keystone Legacy to see how well that strategy works 
in practice.


> Moreover, when someone introduces another data interchange

format, we again just write one piece of middleware, one documentation
generator, and we're done.  Doing this by hand for each format is simply
busywork.


You'd *think* this would work. In practice, however, it really doesn't. 
Neither does (good, valid) code generation...



I don't care whether we specify the model as a Python class, Java class,
XML schema, JSON schema, or using stick figures with long arms pointing
at boxes.  You can even specify it in JSON if you stick to a "lowest
common denominator" subset.


In the 2.0 API we *are* specifying it in JSON. JSON Schema, specifically...

> I think the only thing you need to avoid is

"no changing-at-runtime keys"; I think this makes it compatible
with XML, Avro, ProtocolBuffers & Thrift.


That is antithetical to having dynamic, but discoverable, schemas. JSON 
Schema (and XSD, fwiw) provide things like additionalProperties and 
 for just this sort of thing. Making a schema entirely static 
is really only useful for generating (bad and soon-to-be-outdated) 
client code.


Having dynamic and discoverable schemas enables clients to respond to 
backwards-compatible schema changes (like the addition of standard 
properties or the addition of "extra-standard" additionalProperties) 
without having to recompile a client or change any client code at all...



I don't think it should be a big deal for the JSON format to avoid
dynamic keys, given how much you win whenever you have to support a new
format.


By dynamic keys, are you referring to the additionalProperties? If so, I 
disagree.



Incidentally, I just heard about yet another new format - apparently
this one is going to be the standard for use with node.js
- Hypertext-Powered-State-Transfer-Representation.


HPSTR? H(i)PST(e)R? Are you sure that wasn't an April Fool's Joke? :)

Best,
-jay

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

[Openstack] Installation of Essex from tar files

[Vijay]

Hello,
I am installing openstack from latest Essex released tar files. Installing from 
tar files does not seem to install all the dependencies. What is the best 
way(or configuration) to install from tar files. I do not want to install from 
github as it is continuously getting changed. 
Or is there a url that hosts these released essex versions that I can source 
from?
Thanks,
-Vijay___
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 database optimizing

[Jay Pipes]

On 04/09/2012 03:02 PM, Sean Dague wrote:

There are a lot of possible issues contained in this bug -
https://bugs.launchpad.net/nova/+bug/964824, which I'm happy to break
out as separate issues to be handled in launchpad, so they can each be
dealt with on their own merits.


Actually, if you make it a blueprint, you can use:

partially-implements bp 

in your commit message(s) and the blueprint commentary will be 
progressively updated by Gerrit to include links to all the relevant 
patchsets.


You can see here for an example of how this occurs:

https://blueprints.launchpad.net/glance/+spec/api-2

Note that Gerrit automatically includes the text you see in the 
Whiteboard area when it seems merge proposals with commits referencing 
"partially-implements bp api-2"...



But before I get started on this process, are there any objections to
separating out the issues and just banging these out? Also, who are the
right review folks for this?


I'll make sure I look into them all. I'd also recommend Monty Taylor, 
Gabe Westmaas, Mark Washenberger, Brian Lamar, and/or Patrick Galbraith.


Best,
-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] [Nova] removing nova-direct-api

[Devin Carlen]

+1  It doesn't have to go home but it can't stay here.


On Apr 9, 2012, at 12:31 PM, Kevin L. Mitchell wrote:

> On Mon, 2012-04-09 at 11:58 -0700, Vishvananda Ishaya wrote:
>> +1 to removal.  I just tested to see if it still works, and due to our
>> policy checking and loading objects before sending them into
>> compute.api, it no longer functions. Probably wouldn't be too hard to
>> fix it, but clearly no one is using it so lets axe it.
> 
> Also +1 for removal.  I discovered this thing when I was first trying to
> figure out how the API worked, and it confused me no end…
> -- 
> Kevin L. Mitchell 
> 
> 
> ___
> 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] removing nova-direct-api

[Kevin L. Mitchell]

On Mon, 2012-04-09 at 11:58 -0700, Vishvananda Ishaya wrote:
> +1 to removal.  I just tested to see if it still works, and due to our
> policy checking and loading objects before sending them into
> compute.api, it no longer functions. Probably wouldn't be too hard to
> fix it, but clearly no one is using it so lets axe it.

Also +1 for removal.  I discovered this thing when I was first trying to
figure out how the API worked, and it confused me no end…
-- 
Kevin L. Mitchell 


___
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] removing nova-direct-api

[Sandy Walsh]

/me wears black armband.

Would love to see DirectApi v2 be the de facto OS API implementation.
The spec could be the same, it's just a (better) implementation detail.

-S

On 04/09/2012 03:58 PM, Vishvananda Ishaya wrote:
> +1 to removal.  I just tested to see if it still works, and due to our
> policy checking and loading objects before sending them into
> compute.api, it no longer functions. Probably wouldn't be too hard to
> fix it, but clearly no one is using it so lets axe it.
> 
> Vish
> 
> On Apr 9, 2012, at 11:19 AM, Joe Gordon wrote:
> 
>> Hi All,
>>
>> The other day I noticed that in addition to EC2 and OpenStack APIs
>> there is a third API type: "nova-direct-api."  As best I can tell,
>> this was used early on for development/testing before the EC2 and
>> OpenStack APIs were mature.
>>
>> My question is, since most of the code hasn't been touched in over a
>> year and we have two mature documented APIs, is anyone using this?  If
>> not, I propose to remove it.
>>
>>
>> Proposed Change:  https://review.openstack.org/6375
>>
>>
>> best,
>> Joe
>> ___
>> 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] Nova database optimizing

[Sean Dague]

There are a lot of possible issues contained in this bug - 
https://bugs.launchpad.net/nova/+bug/964824, which I'm happy to break 
out as separate issues to be handled in launchpad, so they can each be 
dealt with on their own merits.


But before I get started on this process, are there any objections to 
separating out the issues and just banging these out? Also, who are the 
right review folks for this? The first change is ready for review at - 
https://review.openstack.org/#change,5970


Thanks much,

-Sean

--
Sean Dague
IBM Linux Technology Center
email: slda...@us.ibm.com
alt-email: sda...@linux.vnet.ibm.com


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

Re: [Openstack] [Nova] removing nova-direct-api

[Vishvananda Ishaya]

+1 to removal.  I just tested to see if it still works, and due to our policy 
checking and loading objects before sending them into compute.api, it no longer 
functions. Probably wouldn't be too hard to fix it, but clearly no one is using 
it so lets axe it.

Vish

On Apr 9, 2012, at 11:19 AM, Joe Gordon wrote:

> Hi All,
> 
> The other day I noticed that in addition to EC2 and OpenStack APIs there is a 
> third API type: "nova-direct-api."  As best I can tell, this was used early 
> on for development/testing before the EC2 and OpenStack APIs were mature.
> 
> My question is, since most of the code hasn't been touched in over a year and 
> we have two mature documented APIs, is anyone using this?  If not, I propose 
> to remove it.
> 
> 
> Proposed Change:  https://review.openstack.org/6375
> 
> 
> best,
> Joe
> ___
> 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] Agreeing a common set of Image Properties

[Jay Pipes]

On 04/09/2012 02:41 PM, Justin Santa Barbara wrote:

I should probably clarify my terminology a little here, as I may have
mangled it:

  * I'm talking about additional/extension properties, not properties
that are well-known to Glance
  * However, we agree to use a common set of properties to mean certain
things.

In other words, we all agree to call Debian
"openstack.org:distro=debian.org " rather than
"os_distro=Debian" on Cloud1, "distro=debian.org " on
Cloud2, "name=Debian Squeeze" on Cloud3 etc


Sure.


3 main pieces of metadata: os:distro, os:version_major,
os:version_minor


In the proposed Images API 2.0, we use JSON Schema's
additionalProperties collection to allow for discoverable custom
properties. For the properties you list above, you could either add
those properties with the prefix you propose above (in
additionalProperties), or argue for inclusion in the standard
"properties" collection of the Image Entry schema. You can see both
the properties and a sample of what additionalProperties are used
for shown in the schema:


https://docs.google.com/__document/d/1rb7ZVn0Du___5NZqUyQpqUZSmv7Qd66TMHYAtvsow7__LH4/edit#heading=h.__1nk6x0hs4enq



Ah, OK I understand the proposed  2.0 API a bit better now.

I'd like to solve this now though, not in 6 / 12 / 18 months.  It sounds
like my proposal is compatible with the new API as well, so no problem
there!


Yes, I hear you :)


  * Some clouds will automatically respin images e.g. weekly
with the
latest updates.  This could also be exposed through metadata.
  os:updated_through= "20120301" ?

Possible, though a version identifier would also work. Or simply a
query like:
GET

/images/sort_by=created_at&__sort_order=desc&limit=1&__property-os:distro=Debian
(and you can do that in the existing API as well, BTW)

created_at != updated_through in general.   As a simple example, the
cloud provider might make a "clean" image (stock Debian 6.0.3) at the
same time as you make a totally up-to-date image.


You can use updated_at as well in the existing API... though of course, 
it only refers to the image metadata, not the image file itself since 
that is static read-only once uploaded...



Not sure what you mean by a version identifier?


Debian 6.0.3 is a version identifier...


  * Some clouds will offer only bare images, some will provide a
variety
e.g. bare, LAMP, Hadoop, etc.  Should we use the native package
names to indicate additional packages?  e.g.
os:packages="apache2,mysql,__php5" ?

IMHO, no. That would get overkill. In the new API, you could use
tags, though. Or you could add a custom extension in the new API so
that you could expose packages as a subresource of /images//.

It is important to differentiate a "minimal" image from a "loaded"
image, users will typically want a loaded image, code will typically
want a bare image; alternative suggestions are welcome.  If we're going
to use tags in 2.0, shouldn't we use properties/metadata today?


Your definition of loaded != others' definition of loaded ;) I'm not 
sure there is going to be a whole lot of success in defining what loaded 
means, though there might be a better success of determining what 
"minimal" means.


Yes, in the existing API, you would use properties. And prefixing those 
properties is perfectly acceptable. Just pointing out we've come up with 
a different solution (tags plus a discoverable schema) in the 2.0 
proposed API.



As a (programmatic) consumer of these images, my wishlist:

  * A cloud will have to put on whatever drivers / agents they
need to,
but ideally these should otherwise be clean images, with minimal
deviation from the stock install.  (Or 'clean' images should be
available alongside other images)  It would be great if I
could be
launch a 'clean' image on any OpenStack cloud and have it behave
more or less the same; I shouldn't have to second guess any
additional tweaks.


No disagreement from me here, but I don't see how this relates to a
common set of image properties? Could you elaborate?

Here's what I see on Cloud X (edited to protect the party, and I removed
the kernels/ramdisks):

417 Debian Squeeze 6.0.3 Server 64-bit 20120123ACTIVE
x_image_type=machine, image_location=local, image_state=available,
project_id=None, x_md_version=1, kernel_id=415, min_ram=0,
ramdisk_id=416, x_image_id=c89dee3bca7a62103f7d88d2a02f4dc8, owner=None,
x_image_builddate=20120123, architecture=amd64, min_disk=0,
x_image_version=1x1.1
414 CentOS 6.2 Server 64-bit 20120125  ACTIVE
x_image_type=machine, 

Re: [Openstack] Agreeing a common set of Image Properties

[Justin Santa Barbara]

I should probably clarify my terminology a little here, as I may have
mangled it:

   - I'm talking about additional/extension properties, not properties that
   are well-known to Glance
   - However, we agree to use a common set of properties to mean certain
   things.

In other words, we all agree to call Debian "openstack.org:distro=debian.org"
rather than "os_distro=Debian" on Cloud1, "distro=debian.org" on Cloud2,
"name=Debian Squeeze" on Cloud3 etc

3 main pieces of metadata: os:distro, os:version_major, os:version_minor
>>
>
> In the proposed Images API 2.0, we use JSON Schema's additionalProperties
> collection to allow for discoverable custom properties. For the properties
> you list above, you could either add those properties with the prefix you
> propose above (in additionalProperties), or argue for inclusion in the
> standard "properties" collection of the Image Entry schema. You can see
> both the properties and a sample of what additionalProperties are used for
> shown in the schema:
>
> https://docs.google.com/**document/d/1rb7ZVn0Du_**
> 5NZqUyQpqUZSmv7Qd66TMHYAtvsow7**LH4/edit#heading=h.**1nk6x0hs4enq


Ah, OK I understand the proposed  2.0 API a bit better now.

I'd like to solve this now though, not in 6 / 12 / 18 months.  It sounds
like my proposal is compatible with the new API as well, so no problem
there!


>  * Some clouds will automatically respin images e.g. weekly with the
>>latest updates.  This could also be exposed through metadata.
>>  os:updated_through= "20120301" ?
>>
>
> Possible, though a version identifier would also work. Or simply a query
> like:
> GET /images/sort_by=created_at&**sort_order=desc&limit=1&**
> property-os:distro=Debian
> (and you can do that in the existing API as well, BTW)
>

created_at != updated_through in general.   As a simple example, the cloud
provider might make a "clean" image (stock Debian 6.0.3) at the same time
as you make a totally up-to-date image.

Not sure what you mean by a version identifier?


>  * Some clouds will offer only bare images, some will provide a variety
>>e.g. bare, LAMP, Hadoop, etc.  Should we use the native package
>>names to indicate additional packages?  e.g.
>>os:packages="apache2,mysql,**php5" ?
>>
>
> IMHO, no. That would get overkill. In the new API, you could use tags,
> though. Or you could add a custom extension in the new API so that you
> could expose packages as a subresource of /images//.
>

It is important to differentiate a "minimal" image from a "loaded" image,
users will typically want a loaded image, code will typically want a bare
image; alternative suggestions are welcome.  If we're going to use tags in
2.0, shouldn't we use properties/metadata today?

 As a (programmatic) consumer of these images, my wishlist:
>>
>>  * A cloud will have to put on whatever drivers / agents they need to,
>>but ideally these should otherwise be clean images, with minimal
>>deviation from the stock install.  (Or 'clean' images should be
>>available alongside other images)  It would be great if I could be
>>launch a 'clean' image on any OpenStack cloud and have it behave
>>more or less the same; I shouldn't have to second guess any
>>additional tweaks.
>>
>
> No disagreement from me here, but I don't see how this relates to a common
> set of image properties? Could you elaborate?
>

Here's what I see on Cloud X (edited to protect the party, and I removed
the kernels/ramdisks):

417 Debian Squeeze 6.0.3 Server 64-bit 20120123ACTIVE
x_image_type=machine, image_location=local, image_state=available,
project_id=None, x_md_version=1, kernel_id=415, min_ram=0, ramdisk_id=416,
x_image_id=c89dee3bca7a62103f7d88d2a02f4dc8, owner=None,
x_image_builddate=20120123, architecture=amd64, min_disk=0,
x_image_version=1x1.1
414 CentOS 6.2 Server 64-bit 20120125  ACTIVE
x_image_type=machine, image_location=local, image_state=available,
project_id=None, x_md_version=1, kernel_id=412, min_ram=0, ramdisk_id=413,
x_image_id=f2fbb1bf37a13e7c5da897c7082684df, owner=None,
x_image_builddate=20120125, architecture=x86_64, min_disk=0,
x_image_version=1x1
229 Ubuntu Oneiric 11.10 Server 64-bit 20111212ACTIVE
image_location=local, image_state=available, kernel_id=228, min_ram=0,
min_disk=0, architecture=amd64, owner=None, project_id=None


227 Ubuntu Natty 11.04 Server 64-bit 20111212  ACTIVE
image_location=local, image_state=available, kernel_id=226, min_ram=0,
min_disk=0, architecture=amd64, owner=None, project_id=None


225 Ubuntu Maverick 10.10 Server 64-bit 20111212   ACTIVE
image_location=local, image_state=available, kernel_id=224, min_ram=0,
min_disk=0, architecture=amd64, owner=None, project_id=None


223 Ubuntu Lucid 10.04 LTS Server 64-bit 20111212  ACTIVE
image_location=local, image_state=available, kernel_id=222, 

[Openstack] [Nova] removing nova-direct-api

[Joe Gordon]

Hi All,

The other day I noticed that in addition to EC2 and OpenStack APIs there is
a third API type: "nova-direct-api."  As best I can tell, this was used
early on for development/testing before the EC2 and OpenStack APIs were
mature.

My question is, since most of the code hasn't been touched in over a year
and we have two mature documented APIs, is anyone using this?  If not, I
propose to remove it.


Proposed Change:  https://review.openstack.org/6375


best,
Joe
___
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] Image API v2 Draft 4

[Justin Santa Barbara]

>
> Justin, what does "design a model which works with XML" mean?


Simply avoiding the handful of things that are specific to JSON (or
specific to XML).  Nothing too onerous (no angle brackets)!


> I think this is only done in the image properties.
>>
>
> No, the image properties have been removed in the 2.0 Images API and
> replaced with the standard concept of "tags":
>
> https://docs.google.com/**document/d/1rb7ZVn0Du_**
> 5NZqUyQpqUZSmv7Qd66TMHYAtvsow7**LH4/edit#heading=h.**y10rq9pdt27y


I was looking at properties in "GET /schemas/image/access" and "GET
/schemas/access".  In general, the Glance 2.0 model is very close to being
XML-compatible.

 On the downside: The JSON isn't as JSON-ic as it could be.
>>
>
> In what ways?


When you're designing JSON considering only JSON, you'd probably use {
key1: value1 } - as you have done.  If you're designing generically, you'd
probably use { key: key1, value: value1 }.

 On the upside: You need never worry about XML again
>>
>
> We haven't worried about it at all up until now. And Glance has been
> perfectly fine without it. ;)
>

Well yes, I agree that our XML support generally is sufficiently buggy as
to be unusable, hence unused.  I don't actually care about XML, I just care
about having a well-specified API that works.

In my opinion, the way to do that is to specify a model, and we have JSON
and XML representations of that model.  If we design the model right, JSON
& XML both "just work" without any code (and less code = less bugs).
 Moreover, when someone introduces another data interchange format, we
again just write one piece of middleware, one documentation generator, and
we're done.  Doing this by hand for each format is simply busywork.

I don't care whether we specify the model as a Python class, Java class,
XML schema, JSON schema, or using stick figures with long arms pointing at
boxes.  You can even specify it in JSON if you stick to a "lowest common
denominator" subset.  I think the only thing you need to avoid is "no
changing-at-runtime keys"; I think this makes it compatible with XML, Avro,
ProtocolBuffers & Thrift.

I don't think it should be a big deal for the JSON format to avoid dynamic
keys, given how much you win whenever you have to support a new format.

Incidentally, I just heard about yet another new format - apparently this
one is going to be the standard for use with node.js
- Hypertext-Powered-State-Transfer-Representation.  Apparently JSON is too
complicated now - with its strict need for quote marks and multiple data
types and all that over engineering, so HPSTR just sends the values; you
just use convention over configuration to infer the keys.  I trust it's not
going to be a lot of work for OpenStack to support it.

> See you in a week!

Looking forward to it!
___
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] boot from iso image

[Vishvananda Ishaya]

Assuming you are using kvm, the iso replaces the root drive of the system, so 
the next disk will be the ephemeral drive.  Are you sure the ephemeral drive in 
the flavor/instance_type isn't 20G?

Vish

On Apr 8, 2012, at 10:37 PM, William Herry wrote:

> Hi
> 
> I am try the openstack's new feature of boot from iso image, and after 
> installation it boot up a working system, it is really awesome
> 
> but I have a little question is that, I give 10G disk when i create this 
> instance but during the installation and after boot up, I got almost 20G, 
> what's going on here? did i miss configure some, I am use essex rc1
> 
> Thanks 
> 
> -- 
> 
> ===
> William Herry
> 
> williamherrych...@gmail.com
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Openstack] Agreeing a common set of Image Properties

[Jay Pipes]

On 04/07/2012 06:13 PM, Justin Santa Barbara wrote:

Is there a (de-facto) standard for image metadata/properties?  I'd like
to be able to able to launch e.g. the Debian Squeeze image provided by
the cloud.  This is particularly important for clouds that don't allow
image upload, but likely this will remain useful because different
clouds will have different tweaks needed (e.g installing the right
drivers based on the hypervisor).

I could try "smart"-parsing the names, but it seems like metadata is the
right way to do this, and I see no reason why any cloud would gain any
advantage from not adopting a common convention.  I know some clouds
have started implementing their own approaches, but I don't believe
anyone is locked into anything.

In the interest of efficiency, I'm going to make a proposal for people
to attack:

3 main pieces of metadata: os:distro, os:version_major, os:version_minor


In the proposed Images API 2.0, we use JSON Schema's 
additionalProperties collection to allow for discoverable custom 
properties. For the properties you list above, you could either add 
those properties with the prefix you propose above (in 
additionalProperties), or argue for inclusion in the standard 
"properties" collection of the Image Entry schema. You can see both the 
properties and a sample of what additionalProperties are used for shown 
in the schema:


https://docs.google.com/document/d/1rb7ZVn0Du_5NZqUyQpqUZSmv7Qd66TMHYAtvsow7LH4/edit#heading=h.1nk6x0hs4enq


Questions / ideas for other properties:

  * Some clouds will automatically respin images e.g. weekly with the
latest updates.  This could also be exposed through metadata.
  os:updated_through= "20120301" ?


Possible, though a version identifier would also work. Or simply a query 
like:


GET 
/images/sort_by=created_at&sort_order=desc&limit=1&property-os:distro=Debian


(and you can do that in the existing API as well, BTW)


  * Some clouds will offer only bare images, some will provide a variety
e.g. bare, LAMP, Hadoop, etc.  Should we use the native package
names to indicate additional packages?  e.g.
os:packages="apache2,mysql,php5" ?


IMHO, no. That would get overkill. In the new API, you could use tags, 
though. Or you could add a custom extension in the new API so that you 
could expose packages as a subresource of /images//.



As a (programmatic) consumer of these images, my wishlist:

  * A cloud will have to put on whatever drivers / agents they need to,
but ideally these should otherwise be clean images, with minimal
deviation from the stock install.  (Or 'clean' images should be
available alongside other images)  It would be great if I could be
launch a 'clean' image on any OpenStack cloud and have it behave
more or less the same; I shouldn't have to second guess any
additional tweaks.


No disagreement from me here, but I don't see how this relates to a 
common set of image properties? Could you elaborate?



  * I would like to be able to launch the clean image and install
updates myself, in case I don't want a particular update.  Providing
a fast apt cache is much better than providing respun images, for my
use-case.  I would be great if old images stuck around, therefore!


Again, no disagreement, but I'm also confused how this relates to 
standard image properties...


Best,
-jay


Justin

---

Justin Santa Barbara
Founder, FathomDB




___
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] Image API v2 Draft 4

[Jay Pipes]

On 04/09/2012 12:56 PM, Justin Santa Barbara wrote:

APPENDIX B: Outstanding issues

4) Need to write xsds :(

This is easy if you design a model which works with XML.  If you have an
XML compatible model, you can generate an XSD and a JSON model from
that.  Also, it means you can just use common middleware to map XML to
JSON, rather than coding XML parsing functions.


Justin, what does "design a model which works with XML" mean?


I think the one thing you'd have to change is that XML won't allow you
to serialize a dictionary with elements as keys (e.g. { "key1":
"value1", "key2": "value2" }, you have to do this: [ { "key": "key1",
"value": "value1" }, { "key": "key2", "value": "value2" } ]

I think this is only done in the image properties.


No, the image properties have been removed in the 2.0 Images API and 
replaced with the standard concept of "tags":


https://docs.google.com/document/d/1rb7ZVn0Du_5NZqUyQpqUZSmv7Qd66TMHYAtvsow7LH4/edit#heading=h.y10rq9pdt27y


On the downside: The JSON isn't as JSON-ic as it could be.


In what ways?


On the upside: You need never worry about XML again


We haven't worried about it at all up until now. And Glance has been 
perfectly fine without it. ;)


See you in a week!

-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] Image API v2 Draft 4

[Justin Santa Barbara]

>
> APPENDIX B: Outstanding issues
>
> 4) Need to write xsds :(
>

This is easy if you design a model which works with XML.  If you have an
XML compatible model, you can generate an XSD and a JSON model from that.
 Also, it means you can just use common middleware to map XML to JSON,
rather than coding XML parsing functions.

I think the one thing you'd have to change is that XML won't allow you to
serialize a dictionary with elements as keys (e.g. { "key1": "value1",
"key2": "value2" }, you have to do this: [ { "key": "key1", "value":
"value1" }, { "key": "key2", "value": "value2" } ]

I think this is only done in the image properties.

On the downside: The JSON isn't as JSON-ic as it could be.
On the upside: You need never worry about XML again
___
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] Instance can't reach dhcp or metadata

[Dan Wendlandt]

On Mon, Apr 9, 2012 at 4:57 AM, Nicolas de BONFILS wrote:

> Hi,
>
> Thanks for the advice but I instead of using FlatManager, I use
> QuantumManager *
> (network_manager=nova.network.quantum.manager.QuantumManager)
> *
> Also, to be more accurate, Quantum assign an ip to my VM (I see it in
> horizon and in nova/quantum mysql db), but the VM doe not get it.
>

Hi Nicolas,

You may be hitting a known issue with QuantumManager + DHCP + Melange:
- https://bugs.launchpad.net/quantum/+bug/949234

Looks like a partial fix was suggested for QuantumManager in Nova, but
validation ran into a possible melange issue, that ultimately was rejected,
without submitting the QuantumManager fix:
- https://bugs.launchpad.net/melange/+bug/951499

Can you try just applying the one-liner patch described in 949234 and see
if it solves your problem?  If so, we can get that merged in.

Dan



>
> Regards
>
> ---
> Nicolas
>
>
>
> On Mon, Apr 9, 2012 at 13:04,  wrote:
>
>>
>> Hi Nicolas,
>>
>> You need another interface ( say eth1 UP & running ) .   Configure
>> br100 to use eth1 .
>>
>>
>>
>> typically your configuration will look like the below ..
>>
>>
>>
>> */etc/network/interfaces*
>> # This file describes the network interfaces available on your system
>> # and how to activate them. For more information, see interfaces(5).
>>
>> # The loopback network interface
>> auto lo
>> iface lo inet loopback
>>
>> # The primary network interface
>> allow-hotplug eth0
>> iface eth0 inet dhcp
>>
>> auto eth1
>>
>> auto br100
>> iface br100 inet static
>> bridge_ports   eth1
>> address 10.0.0.1
>> netmask 255.255.255.0
>> bridge_stp off
>> bridge_fd 0
>>
>>
>>
>> nova.conf will have the following lines too..
>>
>> --fixed_range=10.0.0.0/24
>> --network_size=256
>> --network_manager=nova.network.manager.FlatManager
>> --flat_interface=eth1
>> --flat_injected=False
>> --public_interface=eth0
>>
>>
>> Meena Raja
>> Consultant
>> __
>> *WIPRO TECHNOLOGIES
>> *No 53/1 Ganapa Towers ,Near Madivala Police Station , Hosur Main Road
>> ,Bangalore-560068
>> Hand Phone : +91-9880549725 | Desk : +91-80-39912554 |Fax No:
>> +91-80-25502160
>> Email : raja.me...@wipro.com | Website : www.wipro.com
>>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~
___
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] Agreeing a common set of Image Properties

[Justin Santa Barbara]

On Mon, Apr 9, 2012 at 8:18 AM, Doug Hellmann
wrote:

> I'm thinking of the os prefix as standing for OpenStack, not Operating
>> System.
>>
>
> I would never have guessed that from the context. Why OpenStack instead of
> Operating System?
>

We reserve this limited region of the namespace (openstack.org: or os:) for
keys that we agree to have general meaning.  In return for not using that
prefix for their own purposes, anyone uploading images knows that there
will no collisions, no matter what cloud that image lands on, and no matter
what additional values openstack.org defines in the future.

In general, I'd suggest that prefixing custom properties with your domain
name is "a good idea" for the long term, but that's a separate issue.

Sounds like you'd prefer openstack.org:version or openstack.org:os_version.
 Both work for me, I think I prefer the second.


> Are the major and minor numbers going to be sufficient versioning
> information? See for example PEP 386 for more detailed version strings (
> http://www.python.org/dev/peps/pep-0386/).
>

For a distro, I believe yes.  Do you have a counter-example?

  The package names may vary depending on the platform, so the names
> probably shouldn't be tied to the names of the packages themselves but to
> the projects. Or maybe that's just a taxonomy problem that should be left
> up to the taggers.
>

Absolutely.  The package name would be meaningful/comparable only after the
distro/major/minor combo.  I can't imagine any distro changing package
names within a release.  So we really do defer this issue to the distro.
___
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] [Doc] Docs meeting today, Monday 2000 UTC (3:00 CST)

[Lorin Hochstein]

My fault, I just mixed up CDT and PDT in my head (I'm on EDT).

Take care,

Lorin
--
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com





On Apr 9, 2012, at 11:15 AM, Anne Gentle wrote:

> It used to be 2:00 CST but now it's 3:00 CST. 
> 
> Here's the UTC converter I used:
> 
> http://timeanddate.com/worldclock/meetingtime.html?iso=20120409&p1=400
> 
> Thanks for checking! Please confirm my methods are correct. :)
> 
> Anne
> 
> On Mon, Apr 9, 2012 at 10:13 AM, Lorin Hochstein  
> wrote:
> Anne:
> 
> Can you confirm the time? The wiki page says March 9, 2012, 2000 UTC (3:00 
> CST).
> 
>  But isn't 2000 UTC the same as 1:00 PM CDT?
> 
> Take care,
> 
> Lorin
> --
> Lorin Hochstein
> Lead Architect - Cloud Services
> Nimbis Services, Inc.
> www.nimbisservices.com
> 
> 
> 
> 
> 
> On Apr 9, 2012, at 10:57 AM, Anne Gentle wrote:
> 
>> Hi all,
>> If you're interested in the state of the docs and planning docs sessions for 
>> the Design Summit, please attend this afternoon's doc team meeting. Feel 
>> free to add to the agenda at wiki.openstack.org/Meetings/DocTeamMeeting.
>> 
>> Action items from the last meeting
>> Design Summit planning
>> General documentation status
>> api.openstack.org site and extensions
>> Open discussion
>> Thanks,
>> 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] Bringing High Availability to OpenStack Keystone and Glance

[Adam Young]

On 04/09/2012 05:02 AM, Martin Gerhard Loschwitz wrote:

Am 04.04.12 09:28, schrieb Alex Glikson:

We have a prototype of similar capabilities targeting Nova services, using 
ZooKeeper (heartbeat/membership, leader election, etc -- will share with the 
community soon). Would be interesting to compare the two approaches.

Regards,
Alex




Hello Alex,

great to hear that! Comparing the two approaches will definetely be an
interesting thing once we have comparable solutions for both methods
available (i.e. glance or keystone integration for ZooKeeper or Nova in-
tegration for Pacemaker).

The reason I started with Glance and Keystone is the fact that I expect
it to be particularly more difficult to catch all odds and ends when it
comes to integrating Nova into Pacemaker. For example, verifying that
a process called "nova-network" is running isn't difficult, but making
sure that on the very same system exactly the network-configuration is
in place (iptables-wise etc. pp.) that is necessary to consider
nova-network running is a lot harder. I'm completely open if anyone has
ideas on how to fiddle with this the best way :)

Best regards
Martin

For either approach,  would running the Services in HTTPD make it 
easier, harder, or no different to maintain HA?





___
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] Agreeing a common set of Image Properties

[Doug Hellmann]

On Sat, Apr 7, 2012 at 6:13 PM, Justin Santa Barbara wrote:

> Is there a (de-facto) standard for image metadata/properties?  I'd like to
> be able to able to launch e.g. the Debian Squeeze image provided by the
> cloud.  This is particularly important for clouds that don't allow image
> upload, but likely this will remain useful because different clouds will
> have different tweaks needed (e.g installing the right drivers based on the
> hypervisor).
>
> I could try "smart"-parsing the names, but it seems like metadata is the
> right way to do this, and I see no reason why any cloud would gain any
> advantage from not adopting a common convention.  I know some clouds have
> started implementing their own approaches, but I don't believe anyone is
> locked into anything.
>
> In the interest of efficiency, I'm going to make a proposal for people to
> attack:
>
> 3 main pieces of metadata: os:distro, os:version_major, os:version_minor
>

> I'm thinking of the os prefix as standing for OpenStack, not Operating
> System.
>

I would never have guessed that from the context. Why OpenStack instead of
Operating System?


>  I'd like to 'reserve' the os prefix for 'agreed' prefixes.  Maybe this
> should be openstack.org:distro ?
>

> os:distro would be the primary domain name of the distro, i.e. redhat.com,
> ubuntu.com, debian.org, centos.org etc
>
> os:version_major would be the major version of the release:
> debian.org: 6.0, 5.0, 4.0, 3.1, 3.0, 2.2, 2.1, 2.0
> ubuntu.com: 10.04, 10.10, 11.04, 11.10, 12.04
>
> Numbers seem more machine-friendly than codenames - 6.0, not squeeze -
> humans will probably use the image names.
>

Are the major and minor numbers going to be sufficient versioning
information? See for example PEP 386 for more detailed version strings (
http://www.python.org/dev/peps/pep-0386/).


>
> os:version_minor would be the minor version of the release (because it's a
> minor revision, hopefully we shouldn't normally have to check this,
> although we might want to select the latest always).
>
> So os:distro="debian.org" os:version_major "6.0" os:version_minor "3"
> would be an image of debian 6.0.3.
>
> Questions / ideas for other properties:
>
>- Some clouds will automatically respin images e.g. weekly with the
>latest updates.  This could also be exposed through metadata.
> os:updated_through= "20120301" ?
>- Some clouds will offer only bare images, some will provide a variety
>e.g. bare, LAMP, Hadoop, etc.  Should we use the native package names to
>indicate additional packages?  e.g. os:packages="apache2,mysql,php5" ?
>
> The package names may vary depending on the platform, so the names
probably shouldn't be tied to the names of the packages themselves but to
the projects. Or maybe that's just a taxonomy problem that should be left
up to the taggers.


>
>
> As a (programmatic) consumer of these images, my wishlist:
>
>- A cloud will have to put on whatever drivers / agents they need to,
>but ideally these should otherwise be clean images, with minimal deviation
>from the stock install.  (Or 'clean' images should be available alongside
>other images)  It would be great if I could be launch a 'clean' image on
>any OpenStack cloud and have it behave more or less the same; I shouldn't
>have to second guess any additional tweaks.
>- I would like to be able to launch the clean image and install
>updates myself, in case I don't want a particular update.  Providing a fast
>apt cache is much better than providing respun images, for my use-case.  I
>would be great if old images stuck around, therefore!
>
>
> Justin
>
> ---
>
> Justin Santa Barbara
> Founder, FathomDB
>
>
>
> ___
> 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] [Doc] Docs meeting today, Monday 2000 UTC (3:00 CST)

[Anne Gentle]

It used to be 2:00 CST but now it's 3:00 CST.

Here's the UTC converter I used:

http://timeanddate.com/worldclock/meetingtime.html?iso=20120409&p1=400

Thanks for checking! Please confirm my methods are correct. :)

Anne

On Mon, Apr 9, 2012 at 10:13 AM, Lorin Hochstein
wrote:

> Anne:
>
> Can you confirm the time? The wiki page says March 9, 2012, 2000 UTC (3:00
> CST).
>
>  But isn't 2000 UTC the same as 1:00 PM CDT?
>
> Take care,
>
> Lorin
> --
> Lorin Hochstein
> Lead Architect - Cloud Services
> Nimbis Services, Inc.
> www.nimbisservices.com
>
>
>
>
>
> On Apr 9, 2012, at 10:57 AM, Anne Gentle wrote:
>
> Hi all,
> If you're interested in the state of the docs and planning docs sessions
> for the Design Summit, please attend this afternoon's doc team meeting.
> Feel free to add to the agenda at
> wiki.openstack.org/Meetings/DocTeamMeeting.
>
>
>- Action items from the last meeting
>- Design Summit planning
>- General documentation status
>- api.openstack.org site and extensions
>- Open discussion
>
> Thanks,
> 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] [Doc] Docs meeting today, Monday 2000 UTC (3:00 CST)

[Lorin Hochstein]

Anne:

Can you confirm the time? The wiki page says March 9, 2012, 2000 UTC (3:00 CST).

 But isn't 2000 UTC the same as 1:00 PM CDT?

Take care,

Lorin
--
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com





On Apr 9, 2012, at 10:57 AM, Anne Gentle wrote:

> Hi all,
> If you're interested in the state of the docs and planning docs sessions for 
> the Design Summit, please attend this afternoon's doc team meeting. Feel free 
> to add to the agenda at wiki.openstack.org/Meetings/DocTeamMeeting.
> 
> Action items from the last meeting
> Design Summit planning
> General documentation status
> api.openstack.org site and extensions
> Open discussion
> Thanks,
> 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

[Openstack] [Doc] Docs meeting today, Monday 2000 UTC (3:00 CST)

[Anne Gentle]

Hi all,
If you're interested in the state of the docs and planning docs sessions
for the Design Summit, please attend this afternoon's doc team meeting.
Feel free to add to the agenda at wiki.openstack.org/Meetings/DocTeamMeeting
.


   - Action items from the last meeting
   - Design Summit planning
   - General documentation status
   - api.openstack.org site and extensions
   - Open discussion

Thanks,
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

[Openstack] Gerrit review pending since 7 days ..

[Vaze, Mandar]

https://review.openstack.org/#change,6076 has been open since Apr 2nd.
I understand everyone must have been busy with Essex release up to 5th.

Can someone please take a look and approve ? (It is a trivial change)

Thanks,
-Mandar

__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data.  If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding___
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] Can we use Openstack to sell only VPS?

[Eric Dodemont]

  
  
Munesh,

OpenStack supports LXC (LinuX Container) through the use of libvirt.
LXC is a virtualization similar to Virtuozzo / OpenVZ
(virtualization of the OS, not of the HW).

Since version 2012.1 (Essex), volume attachment is supported.

Please note that LXC support is still having some problems, like
this (very annoying) one:

nova delete lxc-instance umounts the wrong rootfs 
https://bugs.launchpad.net/nova/+bug/971621

Br,

Eric


On 04/07/2012 03:25 PM, Munesh Singh wrote:

  
  
  
  
  
Dear All,
 
Can we use Openstack to
sell only VPS?
 
Like we use for virtuozzo.

 
Warm Regards
 
Munesh Jadoun
CEO &
  Founder

-
ZNet
  Technologies Pvt. Ltd.- Web Hosting
Company.
Group Website:
  www.znetcorp.com

  Ventures:
www.znetlive.in
  |
  www.dotpulse.com
  |
  www.iconcube.com
Call:
+91-141-4070666 | India Toll FREE: 1-800-102-9638 (ZNET)
India Address (HO): D-10/52, Opp. Chitrakoot Stadium,
Chitrakoot, Vaishali Nagar, Jaipur-21 (India)
-
This message
is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any other use of the
email by you is prohibited.
 
  
  
  
  
  ___
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] Instance can't reach dhcp or metadata

[Nicolas de BONFILS]

Hi,

Thanks for the advice but I instead of using FlatManager, I use
QuantumManager *
(network_manager=nova.network.quantum.manager.QuantumManager)
*
Also, to be more accurate, Quantum assign an ip to my VM (I see it in
horizon and in nova/quantum mysql db), but the VM doe not get it.

Regards

---
Nicolas



On Mon, Apr 9, 2012 at 13:04,  wrote:

>
> Hi Nicolas,
>
> You need another interface ( say eth1 UP & running ) .   Configure
> br100 to use eth1 .
>
>
>
> typically your configuration will look like the below ..
>
>
>
> */etc/network/interfaces*
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
>
> # The loopback network interface
> auto lo
> iface lo inet loopback
>
> # The primary network interface
> allow-hotplug eth0
> iface eth0 inet dhcp
>
> auto eth1
>
> auto br100
> iface br100 inet static
> bridge_ports   eth1
> address 10.0.0.1
> netmask 255.255.255.0
> bridge_stp off
> bridge_fd 0
>
>
>
> nova.conf will have the following lines too..
>
> --fixed_range=10.0.0.0/24
> --network_size=256
> --network_manager=nova.network.manager.FlatManager
> --flat_interface=eth1
> --flat_injected=False
> --public_interface=eth0
>
>
> Meena Raja
> Consultant
> __
> *WIPRO TECHNOLOGIES
> *No 53/1 Ganapa Towers ,Near Madivala Police Station , Hosur Main Road
> ,Bangalore-560068
> Hand Phone : +91-9880549725 | Desk : +91-80-39912554 |Fax No:
> +91-80-25502160
> Email : raja.me...@wipro.com | Website : www.wipro.com
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] What is the correct config for vnc or novnc to successfully enable VNC CONSOLE in a browser?

[raja.meena]

Eric ,

 In the nova configuration file , --novncproxy_port=65535   is set . you are 
trying to use the url 
--novncproxy_base_url=http://192.168.0.202:6080/vnc_auto.html

you have overridden the default port 6080  to 65535. Please look into this & 
correct the port ..

This should solve the connection error ..


Meena Raja
Consultant
__
WIPRO TECHNOLOGIES
No 53/1 Ganapa Towers ,Near Madivala Police Station , Hosur Main Road 
,Bangalore-560068
Hand Phone : +91-9880549725 | Desk : +91-80-39912554 |Fax No: +91-80-25502160
Email : raja.me...@wipro.com | Website : www.wipro.com

From: openstack-bounces+raja.meena=wipro@lists.launchpad.net 
[openstack-bounces+raja.meena=wipro@lists.launchpad.net] on behalf of Eric 
Luo [staywithmyhe...@gmail.com]
Sent: Saturday, April 07, 2012 1:58 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] What is the correct config for vnc or novnc to 
successfully enable VNC CONSOLE in a browser?

Hello ,all
I installed Openstack as a all-in-one solution ,I got everything runs correctly 
,I can ssh to my VMs etc. But there is a problem here: I can not use the VNC 
tag in dashboard.
I have installed the nova-consoleauth and novnc by "apt-get" .but I can not 
statrt the nova-novncproxy service (by the way ,the nova-vncproxy service 
always runs OK),
When I use the command  root@ubuntu:~# service novnc start
I got the following with nothing else:
 * Starting OpenStack NoVNC proxy  nova-novncproxy

It only says "starting",but does not say "started"!

actually it is not started ,by command   service novnc status, it says:   * 
nova-novncproxy is not running.

when I use command  nova-novncproxy --flagfile=/etc/nova/nova.conf   ,I got the 
following:

WARNING: no 'numpy' module, HyBi protocol support disabled
Traceback (most recent call last):
  File "/usr/bin/nova-novncproxy", line 40, in 
flags.DEFINE_boolean('verbose', False,
AttributeError: 'module' object has no attribute 'DEFINE_boolean'

When I use command  nova get-vnc-console testVM novnc


+---++
|  Type |Url
 |
+---++
| novnc | 
http://192.168.0.202:6080/vnc_auto.html?token=e1095862-deb9-4cb5-9ec9-44aa0200342e
 |
+---++

but When pasted the url above into my chrome ,I got the following :
Oops! Google Chrome could not connect to 
192.168.0.202:6080
Suggestions:

  *   Try reloading the page
  *
Search on Google:when I click the "VNC " tag in dashboard ,I got the folloing :

This webpage is not available
Google Chrome's connection attempt to 192.168.0.202 was rejected. The website 
may be down, or your network may not be properly configured.
Here are some suggestions:

  *   
Reload
 this webpage later.
  *   Check your Internet connection. Restart any router, modem, or other 
network devices you may be using.
  *   Add Google Chrome as a permitted program in your firewall's or antivirus 
software's settings. If it is already a permitted program, try deleting it from 
the list of permitted programs and adding it again.
  *   If you use a proxy server, check your proxy settings or contact your 
network administrator to make sure the proxy server is working. If you don't 
believe you should be using a proxy server, adjust your proxy settings: Go to 
the wrench menu > Settings > Under the Hood > Change Proxy Settings... and make 
sure your configuration is set to "no proxy" or "direct."

Error 102 (net::ERR_CONNECTION_REFUSED): The server refused the connection.
I hvae an nova config as following:
--dhcpbridge_flagfile=/etc/nova/nova.conf
--dhcpbridge=/usr/bin/nova-dhcpbridge
--logdir=/var/log/nova
--state_path=/var/lib/nova
--lock_path=/var/lock/nova
--allow_admin_api=true
--use_deprecated_auth=false
--auth_strategy=keystone
--scheduler_driver=nova.scheduler.simple.SimpleScheduler
--s3_host=192.168.0.202
--ec2_host=192.168.0.202
--rabbit_host=192.168.0.202
--cc_host=192.168.0.202
--nova_url=http://192.168.0.202:8774/v1.1/
--routing_source_ip=192.168.0.202
--glance_api_servers=192.168.0.202:9292
--image_service=nova.image.glance.GlanceImageService
--iscsi_ip_prefix=192.168.0
--sql_connection=mysql://novadbadmin:123456@192.168.0.202/nova
--ec2_url=http://192.168.0.202:8773/services/Cloud
--keystone_ec2_url=http://192.168.0.202:5000/v2.0/ec2tokens
--api_paste_config=/etc/nova/api-paste.ini
--libvirt_type=kvm
--libvirt_use_virtio_for_bridges=true
--start_guests_on_host_boot=false
--

Re: [Openstack] Instance can't reach dhcp or metadata

[raja.meena]

Hi Nicolas,

You need another interface ( say eth1 UP & running ) .   Configure br100 to 
use eth1 .



typically your configuration will look like the below ..



/etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

auto eth1

auto br100
iface br100 inet static
bridge_ports   eth1
address 10.0.0.1
netmask 255.255.255.0
bridge_stp off
bridge_fd 0



nova.conf will have the following lines too..


--fixed_range=10.0.0.0/24
--network_size=256
--network_manager=nova.network.manager.FlatManager
--flat_interface=eth1
--flat_injected=False
--public_interface=eth0





Meena Raja
Consultant
__
WIPRO TECHNOLOGIES
No 53/1 Ganapa Towers ,Near Madivala Police Station , Hosur Main Road 
,Bangalore-560068
Hand Phone : +91-9880549725 | Desk : +91-80-39912554 |Fax No: +91-80-25502160
Email : raja.me...@wipro.com | Website : www.wipro.com

From: openstack-bounces+raja.meena=wipro@lists.launchpad.net 
[openstack-bounces+raja.meena=wipro@lists.launchpad.net] on behalf of 
Nicolas de BONFILS [ndebonf...@gmail.com]
Sent: Monday, April 09, 2012 3:57 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] Instance can't reach dhcp or metadata

Hi stackers,

I got, using devstack, openstack running. I can launch instance correctly (as 
seen in horizon state) but the instance can't reach the dhcp or the metadata.

Here the topology (as it should be, but I maybe need to configured otherwise in 
the conf) of my server (one box only) :

  *   router : 192.168.23.1
  *   server
 *   ip : 192.168.23.5 (with dhcp but always the same)
 *   interface with external (network and internet) : eth0
 *   interface for openvswitch bridge : br100
 *   interface for nova/quantum/melange bridge : br100
  *   openstack
 *   glance with file backend
 *   quantum and melange for networking
 *   openvswitch as plugin

You can find all the config files and log here : 
https://gist.github.com/2342747.
And networking info below.

Any tips, or pointing misconfiguration will be very appreciated.

/etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

auto br100
iface br100 inet static
address 10.0.0.1
netmask 255.255.255.0
bridge_stp off
bridge_fd 0

ip addr show

1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet 169.254.169.254/32 scope link lo
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: ipddp0:  mtu 585 qdisc noop state DOWN qlen 1000
link/ip/ddp 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether f4:XX:04:10:XX:XX brd ff:ff:ff:ff:ff:ff
inet 192.168.23.5/24 brd 192.168.23.255 scope 
global eth0
inet6 XX:e35:XX:dce0:XX:4ff:fe10:675b/64 scope global dynamic
   valid_lft 86091sec preferred_lft 86091sec
inet6 XX::f66d:XX:fe10:XX/64 scope link
   valid_lft forever preferred_lft forever
18: tap9cec6d69-f0:  mtu 1500 qdisc 
pfifo_fast state DOWN qlen 500
link/ether 12:23:4b:e3:3e:e7 brd ff:ff:ff:ff:ff:ff
19: tapba4b75d8-10:  mtu 1500 qdisc 
pfifo_fast state DOWN qlen 500
link/ether ce:40:f0:7c:48:b1 brd ff:ff:ff:ff:ff:ff
20: tap828bc57f-57:  mtu 1500 qdisc 
pfifo_fast state DOWN qlen 500
link/ether 52:69:4a:f4:45:d7 brd ff:ff:ff:ff:ff:ff
23: br100:  mtu 1500 qdisc noqueue 
state UNKNOWN
link/ether f2:a9:d2:11:8b:49 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global br100
inet6 fe80::f0a9:d2ff:fe11:8b49/64 scope link
   valid_lft forever preferred_lft forever
24: tapcf8c4c18-f3:  mtu 1500 qdisc 
pfifo_fast state DOWN qlen 500
link/ether d2:9f:4e:cf:ce:fa brd ff:ff:ff:ff:ff:ff
25: tap60c76595-d6:  mtu 1500 qdisc 
pfifo_fast state DOWN qlen 500
link/ether 76:90:ce:a4:25:6c brd ff:ff:ff:ff:ff:ff
26: tap34019134-5f:  mtu 1500 qdisc 
pfifo_fast state DOWN qlen 500
link/ether 2e:4f:bc:16:07:71 brd ff:ff:ff:ff:ff:ff
31: tap90748d8d-5d:  mtu 1500 qdisc pfifo_fast 
state UP qlen 500
link/ether 26:45:91:52:12:bd brd ff:ff:ff:ff:ff:ff
inet6 fe80::2445:91ff:fe52:12bd/64 scope link
   valid_lft forever preferred_lft forever
32: tapf937eb70-ff:  mtu 1500 qdisc pfifo_fast 
state UP qlen 500

Re: [Openstack] What is the correct config for vnc or novnctosuccessfully enable VNC CONSOLE in a browser?

[Kiall Mac Innes]

Vncserver listen can be either one of the IPs or 0.0.0.0.

The proxyclient address needs to be one of the compute nodes ips though.

Thanks,
Kiall

Sent from my phone.
On Apr 9, 2012 11:52 a.m., "Yong Sheng Gong"  wrote:

> I think
> --vncserver_listen must be one of the ips of compute-node.
>
>
> -openstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote: -
>
> To: "Anthony Young" 
> From: ".。o 0 O泡泡" <501640...@qq.com> <501640...@qq.com>
> Sent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.net
> Date: 04/09/2012 06:16PM
> Cc: openstack 
> Subject: Re: [Openstack] What is the correct config for vnc or
> novnctosuccessfully enable VNC CONSOLE in a browser?
>
>
> **
> thanks for your answer.
>
> the option of --vncserver_listen is always 0.0.0.0 during I having any
> change for other vnc's options in nova.conf
>
> by the way ,if I set --vncserver_listen to controlnote's IP ,can novnc
> work fine when instance is in compute-note??
>
> thanks
> dming
>
>
> -- Original --
> *From: * "Anthony 
> Young"
> ;
> *Date: * Mon, Apr 9, 2012 02:23 PM
> *To: * ".。o 0 O泡泡"<501640...@qq.com> <501640...@qq.com>; **
> *Cc: * 
> "openstack";
> **
> *Subject: * Re: [Openstack] What is the correct config for vnc or
> novnctosuccessfully enable VNC CONSOLE in a browser?
>
> See below:
>
>>
>> but I get some thing strange for:
>> if I set
>> --vnc_enabled=true
>> --novncproxy_base_url=http://localhost:6080/vnc_auto.html
>> --vncserver_proxyclient_address=localhost
>> --vncserver_listen=0.0.0.0
>> in nova.conf that it return
>> Oops! Google Chrome could not connect to 
>> localhost:6080
>> in dashboard,but work fine when I use command *nova get-vnc-console demo
>> novnc ..*It return a url as
>> http://localhost:6080/vnc_auto.html?token=XX..
>> then I enter this url in chrome with
>> http://172.18.187.110:6080/vnc_auto.html?token=XX
>> ps:172.18.187.110 is the public ip of my openstack server..
>> *It can return my VM's screen ..*
>> *
>> *
>> however,when I set
>> --vnc_enabled=true
>> --novncproxy_base_url=http://172.18.187.110:6080/vnc_auto.html
>> --vncserver_proxyclient_address=172.18.187.110
>> --vncserver_listen=0.0.0.0
>>
>> and restart all the services ..
>> both dashboard and url from command *nova get-vnc-console demo novnc *returns
>> server connot connect
>> **
>> *I am wondering how would localhost and 172.18.187.110 be not the same???
>> *
>> *
>> *
>>
>
>
> If you launched this instance before you specified --vncserver_listen,
> then the instance's vnc server will bind 127.0.0.1. Furthermore, this
> configuration will be baked into the instances libvirt.xml file, so changes
> to --vncserver_listen in your nova.conf will not have any effect for
> already existing instances.
>
> Did you happen to launch this instance before you set --vncserver_listen
> to 0.0.0.0? If so, you may try to launch another instance and see if vnc is
> working properly.
>
> Just for the record, --vncserver_listen is generally set to the hosts
> management ip, rather than the public ip or 0.0.0.0, for security reasons.
>
>> **
>> thanks
>>
>> dming
>>  -- Original --
>> *From: * "Kiall Mac Innes";
>> *Date: * Sat, Apr 7, 2012 07:15 PM
>> *To: * "Eric Luo";**
>> *Cc: * "openstack";**
>> *Subject: * Re: [Openstack] What is the correct config for vnc or novnc
>> tosuccessfully enable VNC CONSOLE in a browser?
>> For anyone else who might be hng the same issue.. These two packages,
>> combined with these options will get novnc working on precise..
>>
>> --vnc_enabled=true
>> --novncproxy_base_url=http://78.153.XXX.XXX:6080/vnc_auto.html
>> --vncserver_proxyclient_address=78.153.XXX.XXX
>> --vncserver_listen=0.0.0.0
>>
>> I've intentionally kept the version numbers identical to the packages
>> currently in the precise repo's. This will hopefully let apt "do the right
>> thing" once an official update is released..
>>
>> http://dl.dropbox.com/u/1400487/novnc_2012.1~e3%2Bdfsg-1_amd64.deb
>>
>> http://dl.dropbox.com/u/1400487/python-novnc_2012.1~e3%2Bdfsg-1_all.deb
>>
>> Thanks,
>> Kiall
>>
>>
>> On Sat, Apr 7, 2012 at 11:14 AM, Kiall Mac Innes wrote:
>>
>>> The novnc package included in 12.04 is outdated/broken..
>>>
>>> I know Chuck is planning to fix it ASAP..
>>>
>>> In the meantime, I hacked together a fixed .deb.. I can stick it
>>> somewhere for you to download if you like?
>>>
>>> Thanks,
>>> Kiall
>>>
>>> Sent from my phone.
>>> On Apr 7, 2012 9:31 a.m., "Eric Luo"  wrote:
>>>
 Hello ,all
 I installed Openstack as a all-in-one solution ,I got everything runs
 correctly ,I can ssh to my VMs etc. But there is a problem here: I 

Re: [Openstack] What is the correct config for vnc or novnctosuccessfully enable VNC CONSOLE in a browser?

[Yong Sheng Gong]

I think--vncserver_listen must be one of the ips of compute-node.-openstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote: -To: "Anthony Young" From: ".。o 0 O泡泡" <501640...@qq.com>Sent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.netDate: 04/09/2012 06:16PMCc: openstack Subject: Re: [Openstack] What is the correct config for vnc or	novnctosuccessfully enable VNC CONSOLE in a browser?thanks for your answer.the option of --vncserver_listen is always 0.0.0.0 during I having any change for other vnc's options in nova.conf by the way ,if I set --vncserver_listen to controlnote's IP ,can novnc work fine when instance is in compute-note??thanks dming -- Original --From:  "Anthony Young";Date:  Mon, Apr 9, 2012 02:23 PMTo:  ".。o 0 O泡泡"<501640...@qq.com>; Cc:  "openstack"; Subject:  Re: [Openstack] What is the correct config for vnc or novnctosuccessfully enable VNC CONSOLE in a browser? See below:
but I get some thing strange for:if I set --vnc_enabled=true--novncproxy_base_url=http://localhost:6080/vnc_auto.html
--vncserver_proxyclient_address=localhost--vncserver_listen=0.0.0.0in nova.conf that it return 
Oops! Google Chrome could not connect to localhost:6080 in dashboard,but work fine when I use command nova get-vnc-console demo novnc  ..It return a url as http://localhost:6080/vnc_auto.html?token=XX..
then I enter this url in chrome with http://172.18.187.110:6080/vnc_auto.html?token=XX 
ps:172.18.187.110 is the public ip of my openstack server..It can return my VM's screen ..
however,when I set
--vnc_enabled=true--novncproxy_base_url=http://172.18.187.110:6080/vnc_auto.html
--vncserver_proxyclient_address=172.18.187.110--vncserver_listen=0.0.0.0and restart all the services ..
both dashboard and url from command nova get-vnc-console demo novnc returns server connot connect I am wondering how would localhost and 172.18.187.110 be not the same???
If you launched this instance before you specified --vncserver_listen, then the instance's vnc server will bind 127.0.0.1.  Furthermore, this configuration will be baked into the instances libvirt.xml file, so changes to --vncserver_listen in your nova.conf will not have any effect for already existing instances.
Did you happen to launch this instance before you set --vncserver_listen to 0.0.0.0?  If so, you may try to launch another instance and see if vnc is working properly.Just for the record, --vncserver_listen is generally set to the hosts management ip, rather than the public ip or 0.0.0.0, for security reasons.
 
thanksdming 
-- Original --From:  "Kiall Mac Innes";
Date:  Sat, Apr 7, 2012 07:15 PMTo:  "Eric Luo";Cc:  "openstack";
Subject:  Re: [Openstack] What is the correct config for vnc or novnc tosuccessfully enable VNC CONSOLE in a browser? For anyone else who might be hng the same issue.. These two packages, combined with these options will get novnc working on precise..--vnc_enabled=true--novncproxy_base_url=http://78.153.XXX.XXX:6080/vnc_auto.html--vncserver_proxyclient_address=78.153.XXX.XXX
--vncserver_listen=0.0.0.0I've intentionally kept the version numbers identical to the packages currently in the precise repo's. This will hopefully let apt "do the right thing" once an official update is released..
http://dl.dropbox.com/u/1400487/novnc_2012.1~e3%2Bdfsg-1_amd64.debhttp://dl.dropbox.com/u/1400487/python-novnc_2012.1~e3%2Bdfsg-1_all.deb Thanks,KiallOn Sat, Apr 7, 2012 at 11:14 AM, Kiall Mac Innes  wrote:

The novnc package included in 12.04 is outdated/broken..I know Chuck is planning to fix it ASAP..In the meantime, I hacked together a fixed .deb.. I can stick it somewhere for you to download if you like?
Thanks,KiallSent from my phone.On Apr 7, 2012 9:31 a.m., "Eric Luo"  wrote:

Hello ,allI installed Openstack as a all-in-one solution ,I got everything runs correctly ,I can ssh to my VMs etc. But there is a problem here: I can not use the VNC tag in dashboard.
I have installed the nova-consoleauth and novnc by "apt-get" .but I can not statrt the nova-novncproxy service (by the way ,the nova-vncproxy service always runs OK),When I use the command root@ubuntu:~# service novnc start
I got the following with nothing else:* Starting OpenStack NoVNC proxy nova-novncproxyIt only says "starting",but does not say "started"!
actually it is not started ,by command service novnc status, it says: * nova-novncproxy is not running.when I use command nova-novncproxy --flagfile=/etc/nova/nova.conf ,I got the following:
WARNING: no 'numpy' module, HyBi protocol support disabledTraceback (most recent call last):File "/usr/bin/nova-novncproxy", line 40, in 
flags.DEFINE_boolean('verbose', False,AttributeError: 'module' object has no attribute 'DEFINE_boolean'When I use command nova get-vnc-console testVM novnc
+---+

[Openstack] Instance can't reach dhcp or metadata

[Nicolas de BONFILS]

Hi stackers,

I got, using devstack, openstack running. I can launch instance correctly
(as seen in horizon state) but the instance can't reach the dhcp or the
metadata.

Here the topology (as it *should* be, but I maybe need to configured
otherwise in the conf) of my server (one box only) :

   - router : 192.168.23.1
   - server
   - ip : 192.168.23.5 (with dhcp but always the same)
  - interface with external (network and internet) : eth0
  - interface for openvswitch bridge : br100
  - interface for nova/quantum/melange bridge : br100
   - openstack
  - glance with file backend
  - quantum and melange for networking
  - openvswitch as plugin

You can find all the config files and log here :
https://gist.github.com/2342747.
And networking info below.

Any tips, or pointing misconfiguration will be very appreciated.

> */etc/network/interfaces*
>
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
>
> # The loopback network interface
> auto lo
> iface lo inet loopback
>
> # The primary network interface
> allow-hotplug eth0
> iface eth0 inet dhcp
>
> auto br100
> iface br100 inet static
> address 10.0.0.1
> netmask 255.255.255.0
> bridge_stp off
> bridge_fd 0
>
*ip addr show*
>
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet 169.254.169.254/32 scope link lo
> inet6 ::1/128 scope host
>valid_lft forever preferred_lft forever
> 2: ipddp0:  mtu 585 qdisc noop state DOWN qlen
> 1000
> link/ip/ddp 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 3: eth0:  mtu 1500 qdisc pfifo_fast state
> UP qlen 1000
> link/ether f4:XX:04:10:XX:XX brd ff:ff:ff:ff:ff:ff
> inet 192.168.23.5/24 brd 192.168.23.255 scope global eth0
> inet6 XX:e35:XX:dce0:XX:4ff:fe10:675b/64 scope global dynamic
>valid_lft 86091sec preferred_lft 86091sec
> inet6 XX::f66d:XX:fe10:XX/64 scope link
>valid_lft forever preferred_lft forever
> 18: tap9cec6d69-f0:  mtu 1500 qdisc
> pfifo_fast state DOWN qlen 500
> link/ether 12:23:4b:e3:3e:e7 brd ff:ff:ff:ff:ff:ff
> 19: tapba4b75d8-10:  mtu 1500 qdisc
> pfifo_fast state DOWN qlen 500
> link/ether ce:40:f0:7c:48:b1 brd ff:ff:ff:ff:ff:ff
> 20: tap828bc57f-57:  mtu 1500 qdisc
> pfifo_fast state DOWN qlen 500
> link/ether 52:69:4a:f4:45:d7 brd ff:ff:ff:ff:ff:ff
> 23: br100:  mtu 1500 qdisc
> noqueue state UNKNOWN
> link/ether f2:a9:d2:11:8b:49 brd ff:ff:ff:ff:ff:ff
> inet 10.0.0.1/24 brd 10.0.0.255 scope global br100
> inet6 fe80::f0a9:d2ff:fe11:8b49/64 scope link
>valid_lft forever preferred_lft forever
> 24: tapcf8c4c18-f3:  mtu 1500 qdisc
> pfifo_fast state DOWN qlen 500
> link/ether d2:9f:4e:cf:ce:fa brd ff:ff:ff:ff:ff:ff
> 25: tap60c76595-d6:  mtu 1500 qdisc
> pfifo_fast state DOWN qlen 500
> link/ether 76:90:ce:a4:25:6c brd ff:ff:ff:ff:ff:ff
> 26: tap34019134-5f:  mtu 1500 qdisc
> pfifo_fast state DOWN qlen 500
> link/ether 2e:4f:bc:16:07:71 brd ff:ff:ff:ff:ff:ff
> 31: tap90748d8d-5d:  mtu 1500 qdisc
> pfifo_fast state UP qlen 500
> link/ether 26:45:91:52:12:bd brd ff:ff:ff:ff:ff:ff
> inet6 fe80::2445:91ff:fe52:12bd/64 scope link
>valid_lft forever preferred_lft forever
> 32: tapf937eb70-ff:  mtu 1500 qdisc
> pfifo_fast state UP qlen 500
> link/ether 42:4e:31:c3:77:ba brd ff:ff:ff:ff:ff:ff
> inet6 fe80::404e:31ff:fec3:77ba/64 scope link
>valid_lft forever preferred_lft forever
> 33: tap010cac48-f4:  mtu 1500 qdisc
> pfifo_fast state UP qlen 500
> link/ether b6:3e:1c:ee:ca:45 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::b43e:1cff:feee:ca45/64 scope link
>valid_lft forever preferred_lft forever
>
*nova-manage service list*
>
> Binary   Host Zone
> Status State Updated_At
> nova-compute 192.168.23.5nova
> enabled:-)   2012-04-09 11:12:33
> nova-network 192.168.23.5nova
> enabled:-)   2012-04-09 11:12:32
> nova-volume  192.168.23.5nova
> enabled:-)   2012-04-09 11:12:32
> nova-scheduler   192.168.23.5nova
> enabled:-)   2012-04-09 11:12:32
> nova-cert192.168.23.5   nova
> enabled:-)   2012-04-09 11:12:32
> nova-consoleauth 192.168.23.5nova
> enabled:-)   2012-04-09 11:12:31
>

*brctl show*
>
> bridge name bridge id   STP enabled interfaces
>


Thanks,

---
Nicolas
___
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] What is the correct config for vnc or novnctosuccessfully enable VNC CONSOLE in a browser?

[.。o 0 O泡泡]

thanks for your answer.


the option of --vncserver_listen is always 0.0.0.0 during I having any change 
for other vnc's options in nova.conf 


by the way ,if I set --vncserver_listen to controlnote's IP ,can novnc work 
fine when instance is in compute-note??


thanks 
dming


 
-- Original --
From:  "Anthony Young";
Date:  Mon, Apr 9, 2012 02:23 PM
To:  ".。o 0 O泡泡"<501640...@qq.com>; 
Cc:  "openstack"; 
Subject:  Re: [Openstack] What is the correct config for vnc or 
novnctosuccessfully enable VNC CONSOLE in a browser?

 
See below:
 

but I get some thing strange for:
if I set 
--vnc_enabled=true

--novncproxy_base_url=http://localhost:6080/vnc_auto.html
 --vncserver_proxyclient_address=localhost

--vncserver_listen=0.0.0.0
in nova.conf that it return 

 Oops! Google Chrome could not connect to localhost:6080 
in dashboard,but work fine when I use command nova get-vnc-console demo novnc  
..It return a url as http://localhost:6080/vnc_auto.html?token=XX..
 then I enter this url in chrome with 
http://172.18.187.110:6080/vnc_auto.html?token=XX 
 ps:172.18.187.110 is the public ip of my openstack server..
It can return my VM's screen ..
 

however,when I set
 --vnc_enabled=true

--novncproxy_base_url=http://172.18.187.110:6080/vnc_auto.html
 --vncserver_proxyclient_address=172.18.187.110

--vncserver_listen=0.0.0.0



and restart all the services ..
 both dashboard and url from command nova get-vnc-console demo novnc returns 
server connot connect
 
I am wondering how would localhost and 172.18.187.110 be not the same???
 








If you launched this instance before you specified --vncserver_listen, then the 
instance's vnc server will bind 127.0.0.1.  Furthermore, this configuration 
will be baked into the instances libvirt.xml file, so changes to 
--vncserver_listen in your nova.conf will not have any effect for already 
existing instances.
 

Did you happen to launch this instance before you set --vncserver_listen to 
0.0.0.0?  If so, you may try to launch another instance and see if vnc is 
working properly.


Just for the record, --vncserver_listen is generally set to the hosts 
management ip, rather than the public ip or 0.0.0.0, for security reasons.
  
 
thanks


dming
 
 -- Original --
From:  "Kiall Mac Innes";
 Date:  Sat, Apr 7, 2012 07:15 PM
To:  "Eric Luo";
Cc:  "openstack";
 Subject:  Re: [Openstack] What is the correct config for vnc or novnc 
tosuccessfully enable VNC CONSOLE in a browser?

 
For anyone else who might be hng the same issue.. These two packages, combined 
with these options will get novnc working on precise.. 

--vnc_enabled=true
--novncproxy_base_url=http://78.153.XXX.XXX:6080/vnc_auto.html
--vncserver_proxyclient_address=78.153.XXX.XXX
 --vncserver_listen=0.0.0.0




I've intentionally kept the version numbers identical to the packages currently 
in the precise repo's. This will hopefully let apt "do the right thing" once an 
official update is released..
 

http://dl.dropbox.com/u/1400487/novnc_2012.1~e3%2Bdfsg-1_amd64.deb


http://dl.dropbox.com/u/1400487/python-novnc_2012.1~e3%2Bdfsg-1_all.deb 
 
Thanks,
Kiall




On Sat, Apr 7, 2012 at 11:14 AM, Kiall Mac Innes  wrote:
 

 
The novnc package included in 12.04 is outdated/broken..

I know Chuck is planning to fix it ASAP..

In the meantime, I hacked together a fixed .deb.. I can stick it somewhere for 
you to download if you like?
 

Thanks,
Kiall

Sent from my phone.


On Apr 7, 2012 9:31 a.m., "Eric Luo"  wrote:
 



 Hello ,allI installed Openstack as a all-in-one solution ,I got everything 
runs correctly ,I can ssh to my VMs etc. But there is a problem here: I can not 
use the VNC tag in dashboard.
 I have installed the nova-consoleauth and novnc by "apt-get" .but I can not 
statrt the nova-novncproxy service (by the way ,the nova-vncproxy service 
always runs OK),
When I use the command root@ubuntu:~# service novnc start
 I got the following with nothing else:
* Starting OpenStack NoVNC proxy nova-novncproxy


It only says "starting",but does not say "started"!


 actually it is not started ,by command service novnc status, it says: * 
nova-novncproxy is not running.


when I use command nova-novncproxy --flagfile=/etc/nova/nova.conf ,I got the 
following:
 

WARNING: no 'numpy' module, HyBi protocol support disabled
Traceback (most recent call last):
File "/usr/bin/nova-novncproxy", line 40, in 
 flags.DEFINE_boolean('verbose', False,
AttributeError: 'module' object has no attribute 'DEFINE_boolean'



When I use command nova get-vnc-console testVM novnc
 



+---++
| Type | Url |
+---++
 | novnc | 
http://192.168.0..202:6080/vnc_auto.html?token=e1095862-deb9-4cb5-9ec9-44aa0200342e
 |
 
+---+

Re: [Openstack] Bringing High Availability to OpenStack Keystone and Glance

[Martin Gerhard Loschwitz]

Am 04.04.12 09:28, schrieb Alex Glikson:
> We have a prototype of similar capabilities targeting Nova services, using 
> ZooKeeper (heartbeat/membership, leader election, etc -- will share with the 
> community soon). Would be interesting to compare the two approaches.
> 
> Regards,
> Alex
> 
> 
> 

Hello Alex,

great to hear that! Comparing the two approaches will definetely be an
interesting thing once we have comparable solutions for both methods
available (i.e. glance or keystone integration for ZooKeeper or Nova in-
tegration for Pacemaker). 

The reason I started with Glance and Keystone is the fact that I expect
it to be particularly more difficult to catch all odds and ends when it
comes to integrating Nova into Pacemaker. For example, verifying that
a process called "nova-network" is running isn't difficult, but making
sure that on the very same system exactly the network-configuration is
in place (iptables-wise etc. pp.) that is necessary to consider 
nova-network running is a lot harder. I'm completely open if anyone has
ideas on how to fiddle with this the best way :)

Best regards
Martin

-- 
Martin Gerhard Loschwitz
Chief Brand Officer, Principal Consultant
hastexo Professional Services

CONFIDENTIALITY NOTICE: This e-mail and/or the accompanying documents
are privileged and confidential under applicable law. The person who
receives this message and who is not the addressee, one of his employees
or an agent entitled to hand it over to the addressee, is informed that
he may not use, disclose or reproduce the contents thereof. Should you
have received this e-mail (or any copy thereof) in error, please let us
know by telephone or e-mail without delay and delete the message from
your system. Thank you.

___
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] What is the correct config for vnc or novnc tosuccessfully enable VNC CONSOLE in a browser?

[Yong Sheng Gong]

		About configuration items in nova.conf
	
		
			

	#read by nova-compute to compose vnc-console URL
	# for novnc
	novncproxy_base_url=http://controlnode:6080/vnc_auto.html
	# for xvpvnc
	xvpvncproxy_base_url=http://controlnode:6081/console
	#read by nova-compute to instantiate VMs
	vncserver_listen=controlnode
	
	#read by libvirt driver to compute vnc-console URL
	vncserver_proxyclient_address=controlnode 
	-openstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote: -To: .。o 0 O泡泡 <501640...@qq.com>From: Anthony Young Sent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.netDate: 04/09/2012 02:23PMCc: openstack Subject: Re: [Openstack] What is the correct config for vnc or novnc tosuccessfully enable VNC CONSOLE in a browser?See below:
but I get some thing strange for:if I set --vnc_enabled=true--novncproxy_base_url=http://localhost:6080/vnc_auto.html
--vncserver_proxyclient_address=localhost--vncserver_listen=0.0.0.0in nova.conf that it return 
Oops! Google Chrome could not connect to localhost:6080 in dashboard,but work fine when I use command nova get-vnc-console demo novnc  ..It return a url as http://localhost:6080/vnc_auto.html?token=XX..
then I enter this url in chrome with http://172.18.187.110:6080/vnc_auto.html?token=XX 
ps:172.18.187.110 is the public ip of my openstack server..It can return my VM's screen ..
however,when I set
--vnc_enabled=true--novncproxy_base_url=http://172.18.187.110:6080/vnc_auto.html
--vncserver_proxyclient_address=172.18.187.110--vncserver_listen=0.0.0.0and restart all the services ..
both dashboard and url from command nova get-vnc-console demo novnc returns server connot connect I am wondering how would localhost and 172.18.187.110 be not the same???
If you launched this instance before you specified --vncserver_listen, then the instance's vnc server will bind 127.0.0.1.  Furthermore, this configuration will be baked into the instances libvirt.xml file, so changes to --vncserver_listen in your nova.conf will not have any effect for already existing instances.
Did you happen to launch this instance before you set --vncserver_listen to 0.0.0.0?  If so, you may try to launch another instance and see if vnc is working properly.Just for the record, --vncserver_listen is generally set to the hosts management ip, rather than the public ip or 0.0.0.0, for security reasons.
 
thanksdming 
-- Original --From:  "Kiall Mac Innes";
Date:  Sat, Apr 7, 2012 07:15 PMTo:  "Eric Luo";Cc:  "openstack";
Subject:  Re: [Openstack] What is the correct config for vnc or novnc tosuccessfully enable VNC CONSOLE in a browser? For anyone else who might be hng the same issue.. These two packages, combined with these options will get novnc working on precise..--vnc_enabled=true--novncproxy_base_url=http://78.153.XXX.XXX:6080/vnc_auto.html--vncserver_proxyclient_address=78.153.XXX.XXX
--vncserver_listen=0.0.0.0I've intentionally kept the version numbers identical to the packages currently in the precise repo's. This will hopefully let apt "do the right thing" once an official update is released..
http://dl.dropbox.com/u/1400487/novnc_2012.1~e3%2Bdfsg-1_amd64.debhttp://dl.dropbox.com/u/1400487/python-novnc_2012.1~e3%2Bdfsg-1_all.deb Thanks,KiallOn Sat, Apr 7, 2012 at 11:14 AM, Kiall Mac Innes  wrote:

The novnc package included in 12.04 is outdated/broken.I know Chuck is planning to fix it ASAP..In the meantime, I hacked together a fixed .deb.. I can stick it somewhere for you to download if you like?
Thanks,KiallSent from my phone.On Apr 7, 2012 9:31 a.m., "Eric Luo"  wrote:

Hello ,allI installed Openstack as a all-in-one solution ,I got everything runs correctly ,I can ssh to my VMs etc. But there is a problem here: I can not use the VNC tag in dashboard.
I have installed the nova-consoleauth and novnc by "apt-get" .but I can not statrt the nova-novncproxy service (by the way ,the nova-vncproxy service always runs OK),When I use the command root@ubuntu:~# service novnc start
I got the following with nothing else:* Starting OpenStack NoVNC proxy nova-novncproxyIt only says "starting",but does not say "started"!
actually it is not started ,by command service novnc status, it says: * nova-novncproxy is not running.when I use command nova-novncproxy --flagfile=/etc/nova/nova.conf ,I got the following:
WARNING: no 'numpy' module, HyBi protocol support disabledTraceback (most recent call last):File "/usr/bin/nova-novncproxy", line 40, in 
flags.DEFINE_boolean('verbose', False,AttributeError: 'module' object has no attribute 'DEFINE_boolean'When I use command nova get-vnc-console testVM novnc
+---++| Type | Url |+---+--

Re: [Openstack] [Ops] OpenStack and Operations: Input from the Wild

[Huang Zhiteng]

Thanks.  Now I understand the performance metrics you guys were talking
about.  It'd be good if we can have some tool reporting numbers for a cloud
just like 'mpstat', 'iostat' did for a system.

On Mon, Apr 9, 2012 at 3:06 PM, Tim Bell  wrote:

> Availability metrics for me are ones that allow me to tell if the service
> is up, degraded or down. Each of us as we start production monitoring need
> to work out how many nova, glance and swift processes of which type should
> be running.  Furthermore, we need to add basic ‘ping’ style probes to see
> that the services are responding as expected. 
>
> ** **
>
> Performance metrics are for cases where we want to record how well the
> system is running. Examples of number of REST calls/second, VMs
> created/second etc.  These are the kind of metrics which feed into capacity
> planning, bottleneck identification, trending.
>
> ** **
>
> Building up an open, standard and consistent set will avoid duplicate
> effort as sites deploy to production and allow us to keep the monitoring up
> to date when the internals of OpenStack change.
>
> ** **
>
> Tim
>
> ** **
>
> *From:* Huang Zhiteng [mailto:winsto...@gmail.com]
> *Sent:* 09 April 2012 05:42
> *To:* Tim Bell
> *Cc:* David Kranz; Andrew Clay Shafer;
> openstack-operat...@lists.openstack.org; Duncan McGreggor; openstack
>
> *Subject:* Re: [Openstack] [Ops] OpenStack and Operations: Input from the
> Wild
>
> ** **
>
> Hi Tim,
>
> Could you elaborate more on 'performance metrics'?  Like what kind of
> metrics are considered as performance ones?  Thanks.
>
> On Sat, Apr 7, 2012 at 2:13 AM, Tim Bell  wrote:
>
>  
>
> Splitting monitoring into
>
>  
>
> 1.   Gathering of metrics (availability, performance) and reporting
> in a standard fashion should be part of OpenStack. 
>
> 2.   Best practice sensors should sample the metrics and provide
> alarms for issues which could cause service impacts. Posting of these
> alarms to a monitoring system should be based on plug ins
>
> 3.   Reference implementations for standard monitoring systems such
> as Nagios should be available that queries the data above and feeds it into
> the package selected
>
>  
>
> Each site does not want to be involved in defining the best practice.
> Equally, each monitoring system should not have to have an intimate
> understanding of OpenStack to produce a red/green light.  The components
> for 1 and 2 fall under the associated openstack component. Component 3 is
> the monitoring solution provider.
>
>  
>
> Tim
>
>  
>
> *From:* openstack-bounces+tim.bell=cern...@lists.launchpad.net [mailto:
> openstack-bounces+tim.bell=cern...@lists.launchpad.net] *On Behalf Of *David
> Kranz
> *Sent:* 06 April 2012 16:44
> *To:* Andrew Clay Shafer
> *Cc:* openstack-operat...@lists.openstack.org; openstack; Duncan McGreggor
> *Subject:* Re: [Openstack] [Ops] OpenStack and Operations: Input from the
> Wild
>
>  
>
> This is a really great list! With regard to cluster health and monitoring,
> I did a bunch of stuff with Swift before turning to nova and really
> appreciated the
> way each swift service has a "healthcheck" call that can be used by a
> monitoring system. While I don't think providing a production-ready
> monitoring system should be part of core OpenStack, it is the core
> architects who really know what needs to be checked to ensure that a system
> is healthy. There are various sets of poking at ports, process lists and so
> on that Crowbar, Zenoss, etc. set up but it would be a big improvement for
> deployers if each openstack service provided healthcheck apis based on
> expert knowledge of what is supposed to be happening inside. That would
> also insulate deployers from changes in the code that might impact what it
> means to be running properly. Looking forward to the discussion.
>
>  -David
>
>
>
> On 4/6/2012 1:06 AM, Andrew Clay Shafer wrote: 
>
> Interested in devops.
>
>  
>
> Off the top of my head.
>
>  
>
> live upgrades
>
> api queryable indications of cluster health
>
> api queryable cluster version and configuration info
>
> enabling monitoring as a first class concern in OpenStack (either as a
> cross cutting concern, or as it's own project)
>
> a framework for gathering and sharing performance benchmarks with
> architecture and configuration
>
>  
>
>  
>
> On Thu, Apr 5, 2012 at 1:52 PM, Duncan McGreggor 
> wrote:
>
> For anyone interested in DevOps, Ops, cloud hosting management, etc.,
> there's a proposed session we could use your feedback on for topics of
> discussion:
>  http://summit.openstack.org/sessions/view/57
>
> Respond with your thoughts and ideas, and I'll be sure to add them to the
> list.
>
> Thanks!
>
> d
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://lau

Re: [Openstack] Melange Unittests

[Vaze, Mandar]

Copying  /opt/stack/mélange/etc/mélange/mélange.conf to /etc resolved the 
problem i.e. test cases started executing.
But that seems like BAD idea since running test cases trashed my DB ( I have 
single box devstack installation)

-Mandar

-Original Message-
From: Vaze, Mandar 
Sent: Monday, April 09, 2012 11:49 AM
To: 'Jason Kölker'; openstack@lists.launchpad.net
Subject: RE: [Openstack] Melange Unittests

Commenting line 32-EOF from setup.cfg didn't help I also pip installed 
openstack.nose_plugin - still didn't help

Even if I try to run single test module, I still see same error(s) e.g. "python 
run_tests.py unit.test_ipam_models"
I run these from /opt/stack/mélange

Here are the actual/detailed errors I see :

==
ERROR: 
--
Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/nose/suite.py", line 208, in run
self.setUp()
  File "/usr/lib/pymodules/python2.7/nose/suite.py", line 291, in setUp
self.setupContext(ancestor)
  File "/usr/lib/pymodules/python2.7/nose/suite.py", line 314, in setupContext
try_run(context, names)
  File "/usr/lib/pymodules/python2.7/nose/util.py", line 478, in try_run
return func()
  File "/opt/stack/melange/melange/tests/functional/__init__.py", line 32, in 
setup
db_api.db_reset(conf, db_based_ip_generator, db_based_mac_generator)
  File "/opt/stack/melange/melange/db/sqlalchemy/api.py", line 259, in db_reset
db_sync(options)
  File "/opt/stack/melange/melange/db/sqlalchemy/api.py", line 246, in db_sync
migration.db_sync(options, version, repo_path)
  File "/opt/stack/melange/melange/db/sqlalchemy/migration.py", line 124, in 
db_sync
upgrade(options, version=version, repo_path=repo_path)
  File "/opt/stack/melange/melange/db/sqlalchemy/migration.py", line 66, in 
upgrade
return versioning_api.upgrade(sql_connection, repo_path, version)
  File "/usr/lib/python2.7/dist-packages/migrate/versioning/api.py", line 186, 
in upgrade
return _migrate(url, repository, version, upgrade=True, err=err, **opts)
  File "", line 2, in _migrate
  File "/usr/lib/python2.7/dist-packages/migrate/versioning/util/__init__.py", 
line 159, in with_engine
return f(*a, **kw)
  File "/usr/lib/python2.7/dist-packages/migrate/versioning/api.py", line 365, 
in _migrate
schema.runchange(ver, change, changeset.step)
  File "/usr/lib/python2.7/dist-packages/migrate/versioning/schema.py", line 
91, in runchange
change.run(self.engine, step)
  File "/usr/lib/python2.7/dist-packages/migrate/versioning/script/py.py", line 
145, in run
script_func(engine)
  File 
"/opt/stack/melange/melange/db/sqlalchemy/migrate_repo/versions/002_device_id_to_uuid.py",
 line 29, in upgrade
_db_connect()
  File 
"/opt/stack/melange/melange/db/sqlalchemy/migrate_repo/versions/002_device_id_to_uuid.py",
 line 62, in _db_connect
conf, app = config.Config.load_paste_app('melange', options, args)
  File "/opt/stack/melange/melange/common/config.py", line 37, in load_paste_app
conf, app = openstack_config.load_paste_app(*args, **kwargs)
  File "/opt/stack/melange/melange/openstack/common/config.py", line 283, in 
load_paste_app
args, config_dir)
  File "/opt/stack/melange/melange/openstack/common/config.py", line 252, in 
load_paste_config
"Cannot load application %s" % app_name)
RuntimeError: Unable to locate any configuration file. Cannot load application 
mélange


-Mandar


-Original Message-
From: openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net 
[mailto:openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net] On 
Behalf Of Jason Kölker
Sent: Friday, April 06, 2012 8:21 PM
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] Melange Unittests

On Fri, 2012-04-06 at 13:11 +, Vaze, Mandar wrote:
> I tried to run ./run_tests.sh (without virtualenv) I kept on getting error 
> related to "unable to find config file"
> I ran the tests from /opt/stack/mélange Same errors when I run "python 
> run_tests.py"
> /opt/stack/mélange/etc/mélange/mélange.conf is present and valid.
> 
> How do I pass the config file to run_tests ? (Shouldn't it pick it up
> automatically)

The nova test runner is busted. We had converted it to use tox, but as 
Brian/James has found out there is an issue with the openstack.nose_plugin and 
something in melange causing tests to not be picked up by the collector.

For the time being edit setup.cfg and comment out lines 32-EOF. Since melange 
is merging with quantum, my plan is to fix them as I merge them into the 
quantum tests.

Happy Hacking!

7-11


___
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] [Ops] OpenStack and Operations: Input from the Wild

[Tim Bell]

Availability metrics for me are ones that allow me to tell if the service is
up, degraded or down. Each of us as we start production monitoring need to
work out how many nova, glance and swift processes of which type should be
running.  Furthermore, we need to add basic 'ping' style probes to see that
the services are responding as expected. 

 

Performance metrics are for cases where we want to record how well the
system is running. Examples of number of REST calls/second, VMs
created/second etc.  These are the kind of metrics which feed into capacity
planning, bottleneck identification, trending.

 

Building up an open, standard and consistent set will avoid duplicate effort
as sites deploy to production and allow us to keep the monitoring up to date
when the internals of OpenStack change.

 

Tim

 

From: Huang Zhiteng [mailto:winsto...@gmail.com] 
Sent: 09 April 2012 05:42
To: Tim Bell
Cc: David Kranz; Andrew Clay Shafer;
openstack-operat...@lists.openstack.org; Duncan McGreggor; openstack
Subject: Re: [Openstack] [Ops] OpenStack and Operations: Input from the Wild

 

Hi Tim,

Could you elaborate more on 'performance metrics'?  Like what kind of
metrics are considered as performance ones?  Thanks.

On Sat, Apr 7, 2012 at 2:13 AM, Tim Bell  wrote:

 

Splitting monitoring into

 

1.   Gathering of metrics (availability, performance) and reporting in a
standard fashion should be part of OpenStack. 

2.   Best practice sensors should sample the metrics and provide alarms
for issues which could cause service impacts. Posting of these alarms to a
monitoring system should be based on plug ins

3.   Reference implementations for standard monitoring systems such as
Nagios should be available that queries the data above and feeds it into the
package selected

 

Each site does not want to be involved in defining the best practice.
Equally, each monitoring system should not have to have an intimate
understanding of OpenStack to produce a red/green light.  The components for
1 and 2 fall under the associated openstack component. Component 3 is the
monitoring solution provider.

 

Tim

 

From: openstack-bounces+tim.bell=cern...@lists.launchpad.net
[mailto:openstack-bounces+tim.bell 
=cern...@lists.launchpad.net] On Behalf Of David Kranz
Sent: 06 April 2012 16:44
To: Andrew Clay Shafer
Cc: openstack-operat...@lists.openstack.org; openstack; Duncan McGreggor
Subject: Re: [Openstack] [Ops] OpenStack and Operations: Input from the Wild

 

This is a really great list! With regard to cluster health and monitoring, I
did a bunch of stuff with Swift before turning to nova and really
appreciated the 
way each swift service has a "healthcheck" call that can be used by a
monitoring system. While I don't think providing a production-ready
monitoring system should be part of core OpenStack, it is the core
architects who really know what needs to be checked to ensure that a system
is healthy. There are various sets of poking at ports, process lists and so
on that Crowbar, Zenoss, etc. set up but it would be a big improvement for
deployers if each openstack service provided healthcheck apis based on
expert knowledge of what is supposed to be happening inside. That would also
insulate deployers from changes in the code that might impact what it means
to be running properly. Looking forward to the discussion.

 -David



On 4/6/2012 1:06 AM, Andrew Clay Shafer wrote: 

Interested in devops.

 

Off the top of my head.

 

live upgrades

api queryable indications of cluster health

api queryable cluster version and configuration info

enabling monitoring as a first class concern in OpenStack (either as a cross
cutting concern, or as it's own project)

a framework for gathering and sharing performance benchmarks with
architecture and configuration

 

 

On Thu, Apr 5, 2012 at 1:52 PM, Duncan McGreggor 
wrote:

For anyone interested in DevOps, Ops, cloud hosting management, etc.,
there's a proposed session we could use your feedback on for topics of
discussion:
 http://summit.openstack.org/sessions/view/57

Respond with your thoughts and ideas, and I'll be sure to add them to the
list.

Thanks!

d

___
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@l