Re: [Openstack] API Spec

[Thor Wolpert]

That sounds fair.  I listened to Linus talk about a similar thing when
in the early days they tried to pack in features, and only later
started to try and constrain what got into the "core".  There was some
interesting debate about the new features as they often didn't know
how they would be best used and grow until after people started using
them.  As such they looked to try and maintain backwards compatibility
as best they could until people had enough warning to migrate
(measured in years).

Sounds like a similar dilemma to me.

Thor HW

On Mon, Aug 22, 2011 at 9:49 PM, Jorge Williams
 wrote:
>
> I say we up the version number when we can't ensure backward compatibility.  
> As to how long older versions should be supported.  Hard to say.  It depends 
> on a lot of factors, and at the end of the day it may come up to how popular 
> a version is and how  willing and able operators and client devs are to 
> upgrading.
>
> -jOrGe W.
>
>
> On Aug 22, 2011, at 8:49 PM, Thor Wolpert wrote:
>
>> I agree the Specs shouldn't change often ... but just to use your
>> examples, they where all simplifications of larger specs that took
>> years to create.
>>
>> If an API changes and is deprecated, how long does backwards
>> compatibility stay in place?
>>
>> Thanks,
>> Thor W
>>
>> On Mon, Aug 22, 2011 at 5:49 PM, Jan Drake  wrote:
>>> +1
>>>
>>>
>>>
>>>
>>> On Aug 22, 2011, at 5:06 PM, Jay Pipes  wrote:
>>>
 ++

 On Mon, Aug 22, 2011 at 7:59 PM, Jorge Williams
  wrote:
> Hi Vish,
> I don't have a problem moving the spec out of docs manuals and into 
> another
> project even the nova repo.   But, I do have a number of issues with the
> approach that you're proposing. First, I think that fundamentally there
> should be a decoupling of the spec and the implementation.   If you have 
> the
> spec generated from the code than essentially the spec is whatever the 
> code
> does. It's very difficult to interoperate with specs that are generated 
> this
> way as the specs tend to be very brittle and opaque (since you have to 
> study
> the code). If you introduce a  bug in the code that bug filters it's way 
> all
> the way to the spec (this was a big problem with SOAP and CORBA). It's
> difficult to detect errors because you cant validate. By keeping the
> implementation and the spec separate you can validate one against the 
> other.
>
> Second, I don't think that the core OpenStack API should change with every
> OpenStack release. There are a number of efforts to provide multiple
> implementation of an existing OpenStack API.  We should encourage this, 
> but
> it becomes difficult if the core spec is in constant flux.  Certainly you
> can use the extension mechanism to bring functionality out to market
> quickly, but the process of deciding what goes into the core should be 
> more
> deliberate. Really good specs, shouldn't need to change very often, think
> HTTP, X11, SMTP, etc. We need to encourage clients to write support for 
> our
> spec and we need to also encourage other implementors to write
> implementations for it. These efforts become very difficult if the spec is
> in constant flux.
> -jOrGe W.
> On Aug 22, 2011, at 5:43 PM, Vishvananda Ishaya wrote:
>
> Hey Everyone,
> We discussed at the Diablo design summit having API spec changes be 
> proposed
> along with code changes and reviewed according to the merge process that 
> we
> use for code.  This has been impossible up until now because the canonical
> spec has been in the openstack-manuals project.
> My suggestion is that we move the openstack-compute spec into the nova
> source tree.  During a six-month release we can propose changes to the 
> spec
> by proposing along with the code that changes it.  In the final freeze for
> the release, we can increment the spec version number and copy the current
> version of the spec into openstack-manuals and that will be the locked 
> down
> spec for that release.
> This means that openstack 1.1 will be the official spec for diablo, at 
> which
> point we will start working on a new api (we can call it 1.2 but it might 
> be
> best to use a temporary name like 'latest') during the essex release 
> cycle,
> then at essex release we lock the spec down and it becomes the new version
> of the openstack api.
> Ultimately I would like the spec to be generated from the code, but as a
> first pass, we should at least be able to edit the future version of the
> spec as we make changes.  I've proposed the current version of the spec
> here:
> https://code.launchpad.net/~vishvananda/nova/add-api-docs/+merge/72506
> Are there any issues with this approach?
> Vish
>
> This email may include confidential information. If you received it in
>>

Re: [Openstack] API Spec

[Jorge Williams]

I say we up the version number when we can't ensure backward compatibility.  As 
to how long older versions should be supported.  Hard to say.  It depends on a 
lot of factors, and at the end of the day it may come up to how popular a 
version is and how  willing and able operators and client devs are to upgrading.

-jOrGe W.


On Aug 22, 2011, at 8:49 PM, Thor Wolpert wrote:

> I agree the Specs shouldn't change often ... but just to use your
> examples, they where all simplifications of larger specs that took
> years to create.
> 
> If an API changes and is deprecated, how long does backwards
> compatibility stay in place?
> 
> Thanks,
> Thor W
> 
> On Mon, Aug 22, 2011 at 5:49 PM, Jan Drake  wrote:
>> +1
>> 
>> 
>> 
>> 
>> On Aug 22, 2011, at 5:06 PM, Jay Pipes  wrote:
>> 
>>> ++
>>> 
>>> On Mon, Aug 22, 2011 at 7:59 PM, Jorge Williams
>>>  wrote:
 Hi Vish,
 I don't have a problem moving the spec out of docs manuals and into another
 project even the nova repo.   But, I do have a number of issues with the
 approach that you're proposing. First, I think that fundamentally there
 should be a decoupling of the spec and the implementation.   If you have 
 the
 spec generated from the code than essentially the spec is whatever the code
 does. It's very difficult to interoperate with specs that are generated 
 this
 way as the specs tend to be very brittle and opaque (since you have to 
 study
 the code). If you introduce a  bug in the code that bug filters it's way 
 all
 the way to the spec (this was a big problem with SOAP and CORBA). It's
 difficult to detect errors because you cant validate. By keeping the
 implementation and the spec separate you can validate one against the 
 other.
 
 Second, I don't think that the core OpenStack API should change with every
 OpenStack release. There are a number of efforts to provide multiple
 implementation of an existing OpenStack API.  We should encourage this, but
 it becomes difficult if the core spec is in constant flux.  Certainly you
 can use the extension mechanism to bring functionality out to market
 quickly, but the process of deciding what goes into the core should be more
 deliberate. Really good specs, shouldn't need to change very often, think
 HTTP, X11, SMTP, etc. We need to encourage clients to write support for our
 spec and we need to also encourage other implementors to write
 implementations for it. These efforts become very difficult if the spec is
 in constant flux.
 -jOrGe W.
 On Aug 22, 2011, at 5:43 PM, Vishvananda Ishaya wrote:
 
 Hey Everyone,
 We discussed at the Diablo design summit having API spec changes be 
 proposed
 along with code changes and reviewed according to the merge process that we
 use for code.  This has been impossible up until now because the canonical
 spec has been in the openstack-manuals project.
 My suggestion is that we move the openstack-compute spec into the nova
 source tree.  During a six-month release we can propose changes to the spec
 by proposing along with the code that changes it.  In the final freeze for
 the release, we can increment the spec version number and copy the current
 version of the spec into openstack-manuals and that will be the locked down
 spec for that release.
 This means that openstack 1.1 will be the official spec for diablo, at 
 which
 point we will start working on a new api (we can call it 1.2 but it might 
 be
 best to use a temporary name like 'latest') during the essex release cycle,
 then at essex release we lock the spec down and it becomes the new version
 of the openstack api.
 Ultimately I would like the spec to be generated from the code, but as a
 first pass, we should at least be able to edit the future version of the
 spec as we make changes.  I've proposed the current version of the spec
 here:
 https://code.launchpad.net/~vishvananda/nova/add-api-docs/+merge/72506
 Are there any issues with this approach?
 Vish
 
 This email may include confidential information. If you received it in
 error, please delete 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
 
 
>>> 
>>> ___
>>> 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/~op

Re: [Openstack] API Spec

[Jorge Williams]

Inline

On Aug 22, 2011, at 9:12 PM, Anne Gentle wrote:

I think it makes sense to have an openstack-api project with all the API docs 
(specs and learning materials) gathered in one place. I think it's preferable 
to have the API separated out from the code for several reasons - ease of 
review, ease of check out, also for learning materials for the API itself.


+1

I'd envision these would go in it for starters:

Compute API (docbook, core + extensions)
Glance API (RST to docbook, core)
Keystone API (docbook, incubation, core + extensions)
Swift API (docbook, core)

Notes:
- Yep, Keystone moved their docbook out of the core code base due to the 
"overhead" associated with a large-ish document ensconced with the code.
- Glance's API is documented in a single RST page. We have a simple RST to 
docbook tool inhouse at Rackspace that lets me take updates and move them into 
docbook.
- Just today I had a request to bring the Load Balancing API into 
openstack-manuals for comments and review from 
http://wiki.openstack.org/Atlas-LB, since our wiki doesn't enable comments. I'm 
not sure what to do with nascent APIs for review that aren't yet in incubation.

So these are some of my observations having worked with the API docs for a 
while, to consider while seeking the ideal solution:
Incubation - how do we indicate an API is incubated?
Pre-incubation/review period - how could a team offer an API up for community 
review and commenting?
Core - how do we indicate what is core and how to get extensions? At Rackspace 
the Compute API team is working on a solution to getting extensions and telling 
people how to use them once they're available.
Source - DocBook is the source for the two biggest API docs, Compute and Object 
Storage, Keystone is a close third, and I can get DocBook out of Glance. Do we 
need to set DocBook as the standard source?
Output - I'd also like to focus on not only API specs but also deliverables 
that help people learn the APIs, such as the frameworks recently opensourced by 
Mashery (example: http://developer.klout.com/iodocs) and Wordnik 
(http://swagger.wordnik.com/). If we also deliver this type of web tool, we'd 
also need JSON or XML as source files (many of which are already embedded into 
the DocBook).

I'd like the best of both worlds - API specs and self-documenting APIs. I think 
we can get there, and I think a separate API project with a core review team 
moves us in that direction.


+1

Thanks for the good discussion here.
Anne


Anne Gentle

my blog | my 
book | 
LinkedIn | 
Delicious | 
Twitter

On Mon, Aug 22, 2011 at 7:49 PM, Jan Drake 
mailto:jan_dr...@hotmail.com>> wrote:
+1




On Aug 22, 2011, at 5:06 PM, Jay Pipes 
mailto:jaypi...@gmail.com>> wrote:

> ++
>
> On Mon, Aug 22, 2011 at 7:59 PM, Jorge Williams
> mailto:jorge.willi...@rackspace.com>> wrote:
>> Hi Vish,
>> I don't have a problem moving the spec out of docs manuals and into another
>> project even the nova repo.   But, I do have a number of issues with the
>> approach that you're proposing. First, I think that fundamentally there
>> should be a decoupling of the spec and the implementation.   If you have the
>> spec generated from the code than essentially the spec is whatever the code
>> does. It's very difficult to interoperate with specs that are generated this
>> way as the specs tend to be very brittle and opaque (since you have to study
>> the code). If you introduce a  bug in the code that bug filters it's way all
>> the way to the spec (this was a big problem with SOAP and CORBA). It's
>> difficult to detect errors because you cant validate. By keeping the
>> implementation and the spec separate you can validate one against the other.
>>
>> Second, I don't think that the core OpenStack API should change with every
>> OpenStack release. There are a number of efforts to provide multiple
>> implementation of an existing OpenStack API.  We should encourage this, but
>> it becomes difficult if the core spec is in constant flux.  Certainly you
>> can use the extension mechanism to bring functionality out to market
>> quickly, but the process of deciding what goes into the core should be more
>> deliberate. Really good specs, shouldn't need to change very often, think
>> HTTP, X11, SMTP, etc. We need to encourage clients to write support for our
>> spec and we need to also encourage other implementors to write
>> implementations for it. These efforts become very difficult if the spec is
>> in constant flux.
>> -jOrGe W.
>> On Aug 22, 2011, at 5:43 PM, Vishvananda Ishaya wrote:
>>
>> Hey Everyone,
>> We discussed at the Diablo design summit having API spec changes be proposed
>> along with code changes and reviewed according to the merge process that we
>> use for code.  This

Re: [Openstack] API Spec

[Jorge Williams]

On Aug 22, 2011, at 8:59 PM, Vishvananda Ishaya wrote:

> Inline
> 
> On Aug 22, 2011, at 4:15 PM, Jay Pipes wrote:
> 
>> It may be just me, but having DocBookXML in the source tree is hideous
>> to me. Not only does it clutter the source tree with non-RST
>> documentation, but as you know, reviewing diffs of XML is just about
>> makes people want to slit their throats with a spoon. There is a
>> special type of person (Anne!) that seem to be impervious to the
>> throat-slitting urge and can successfully digest such a review
>> request, but for many, the process is too painful.
> 
> I hate xml changes as well, but anne + people in manuals don't really have 
> the expertise to know if something belongs in the api.  *-core should be 
> responsible for the spec for the project.


Agreed there should be someone in the loop that can help validate the changes. 
A manuals person alone should not suffice to let those type of changes go into 
the spec.  I think we can adjust our process to be able to accomplish this.   
Doesn't gerrit help for this sort of stuff? 

>> 
>> In addition to the above gripe, the development, stability, and
>> enhancement of the OpenStack APIs can and should (IMHO) be managed
>> separately from the source code of the project. The API can evolve in
>> the openstack-manuals project and developers can code the OpenStack
>> subproject to match the API documented in openstack-manuals project
>> (at the tagged version). So, for instance, if the compute API needs to
>> change, the API documentation changes would be proposed in
>> openstack-manuals, reviewed, discussed and approved. The new API docs
>> would be published to something like
>> http://docs.openstack.org/compute/2.0/ and developers coding Essex
>> features having to do with implementing such a 2.0 API would refer to
>> the API documentation there while writing the feature...
> 
> If we want to separate the xml code out, we can do a separate nova-spec repo 
> for the spec, but this should be managed by nova-core

Having a separate nova-spec repo is a good idea. I've never been a fan of 
having them all in a single repo.  You still want a writer in the loop to check 
style, apply the latest templates, do general editing etc.

-jOrGe W.
This email may include confidential information. If you received it in error, 
please delete 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] API Spec

[Jorge Williams]

Comments inline

On Aug 22, 2011, at 9:05 PM, Vishvananda Ishaya wrote:

> Inline
> On Aug 22, 2011, at 4:59 PM, Jorge Williams wrote:
> 
>> Hi Vish,
>> 
>> I don't have a problem moving the spec out of docs manuals and into another 
>> project even the nova repo.   But, I do have a number of issues with the 
>> approach that you're proposing. First, I think that fundamentally there 
>> should be a decoupling of the spec and the implementation.   If you have the 
>> spec generated from the code than essentially the spec is whatever the code 
>> does. It's very difficult to interoperate with specs that are generated this 
>> way as the specs tend to be very brittle and opaque (since you have to study 
>> the code). If you introduce a  bug in the code that bug filters it's way all 
>> the way to the spec (this was a big problem with SOAP and CORBA). It's 
>> difficult to detect errors because you cant validate. By keeping the 
>> implementation and the spec separate you can validate one against the other. 
> 
> The spec SHOULD BE exactly what the code does, verifiably.  I'm proposing 
> that we have exactly the existing document, only that the xml and json 
> examples in the spec are actually generated from the code so that we know 
> they are accurate.  This is a minor point to me though, and could be 
> accomplished by testing the spec against the code as well.

Let's say you generate the samples from the code.  Everything works great.  The 
samples represent exactly what the code is doing.  A client developer takes a 
look at the spec samples and develops an app against it.  Then a merge request 
goes through that changes the format of the JSON inadvertently in a subtle way. 
 Now the client is out of synch and breaks. The client dev looks back at the 
spec,  not only has the code changed but the spec has changed too since it's 
generated, -- the client therefore  assumes that the bug is his bad -- so he 
changes the code to match the spec.  Things work great, until the service 
developer notices that the merge changed the format of the JSON and changes it 
back to what it used to be -- now the client is broken againAnyway that 
illustrates why these type of approaches are brittle. 

Here's what I think is a better approach.  Design your API and write the 
samples by hand. You may design schema for your XML representation and verify 
that your samples validate. Write tests that check the generated XML and JSON  
that comes out of your service against the hand written versions and, if 
applicable, against the schema.  You know the API is done when the tests pass.  
If a merge  comes in that changes the representation then the tests will fail. 
Either way there's not much you can do in your code that can change's the spec 
from under your client's feet because the spec and the code are separate.  Sure 
during early development the spec and the code may be out of synch, but at 
least the client knows where you're headed and can work to meet you there.

So yes, you should be using those samples for testing. You just shouldn't be 
generating the samples from the code. The code SHOULD DO what the spec says 
verifiably -- not the other way around.


> 
>> 
>> Second, I don't think that the core OpenStack API should change with every 
>> OpenStack release. There are a number of efforts to provide multiple 
>> implementation of an existing OpenStack API.  We should encourage this, but 
>> it becomes difficult if the core spec is in constant flux.  Certainly you 
>> can use the extension mechanism to bring functionality out to market 
>> quickly, but the process of deciding what goes into the core should be more 
>> deliberate. Really good specs, shouldn't need to change very often, think 
>> HTTP, X11, SMTP, etc. We need to encourage clients to write support for our 
>> spec and we need to also encourage other implementors to write 
>> implementations for it. These efforts become very difficult if the spec is 
>> in constant flux.
> 
> Incrementing the version number is only a problem if we fail to support the 
> old versions.  At the rate we are adding new functionality, I think we will 
> easily need a new spec every six months for the foreseeable future.  If there 
> are no reasonable changes in a six month period, we can skip a release and 
> not have a new version of the spec
> 

Things have been changing because we've been working hard to realize what the 
code API should be.  Once we have this settled, I don't see a big reason why 
the core spec should change every 6 months. In fact, functionality wise the 
core API you see in 1.1 today hasn't really changed all that much in comparison 
to the 1.0 API.


-jOrGe W.

This email may include confidential information. If you received it in error, 
please delete it.


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

Re: [Openstack] API Spec

[Jorge Williams]

Christopher,

I agree that a feature that is generically applicable to all implementations 
should be in the core API.  I also agree that we should be having debates at 
proposal time rather than merge time -- which is one of the benefits of having 
a separate spec -- we can debate the spec before we spend time implementing  
the feature.

That said, just because a feature isn't in core, doesn't mean that the feature 
isn't useful. There may be useful features that are applicable to a particular 
vendor (pricing), or that not all backends can support (Xen vs KVM), or that if 
they were included in the core would set the bar for a standard deployment very 
high because it relies on dependencies with other services (backup schedules).  
So it makes sense for there to be a slim core API that you know you can count 
on no matter what -- and this API should cover all the basics (create, delete, 
reboot, etc), and if there are other goodies available by the deployment a 
client should be able to detect them. At least that's how I see things.

-jOrGe W.

On Aug 22, 2011, at 8:19 PM, Christopher MacGown wrote:

The fundamental problem with throwing all new API features into ext/ is that 
support for core features ends up being a political football that the various 
vendors can play with each other. A user of OpenStack shouldn't have to check 
whether each feature within core is supported at the API level by their 
provider. By accepting code into trunk, we as *-core are generally asserting 
that a feature is generically useful across all implementations of OpenStack. 
Blueprints for which there is some controversy around API exposure or feature 
correctness should be vigorously debated at proposal, not at merge. And in my 
opinion, if a feature isn't useful enough to expose through the API, why are we 
including it in trunk?

Christopher MacGown
Piston Cloud Computing, Inc.
w: (650) 24-CLOUD
m: (415) 300-0944
ch...@pistoncloud.com

On Aug 22, 2011, at 4:59 PM, Jorge Williams wrote:

Hi Vish,

I don't have a problem moving the spec out of docs manuals and into another 
project even the nova repo.   But, I do have a number of issues with the 
approach that you're proposing. First, I think that fundamentally there should 
be a decoupling of the spec and the implementation.   If you have the spec 
generated from the code than essentially the spec is whatever the code does. 
It's very difficult to interoperate with specs that are generated this way as 
the specs tend to be very brittle and opaque (since you have to study the 
code). If you introduce a  bug in the code that bug filters it's way all the 
way to the spec (this was a big problem with SOAP and CORBA). It's difficult to 
detect errors because you cant validate. By keeping the implementation and the 
spec separate you can validate one against the other.

Second, I don't think that the core OpenStack API should change with every 
OpenStack release. There are a number of efforts to provide multiple 
implementation of an existing OpenStack API.  We should encourage this, but it 
becomes difficult if the core spec is in constant flux.  Certainly you can use 
the extension mechanism to bring functionality out to market quickly, but the 
process of deciding what goes into the core should be more deliberate. Really 
good specs, shouldn't need to change very often, think HTTP, X11, SMTP, etc. We 
need to encourage clients to write support for our spec and we need to also 
encourage other implementors to write implementations for it. These efforts 
become very difficult if the spec is in constant flux.

-jOrGe W.

On Aug 22, 2011, at 5:43 PM, Vishvananda Ishaya wrote:

Hey Everyone,

We discussed at the Diablo design summit having API spec changes be proposed 
along with code changes and reviewed according to the merge process that we use 
for code.  This has been impossible up until now because the canonical spec has 
been in the openstack-manuals project.

My suggestion is that we move the openstack-compute spec into the nova source 
tree.  During a six-month release we can propose changes to the spec by 
proposing along with the code that changes it.  In the final freeze for the 
release, we can increment the spec version number and copy the current version 
of the spec into openstack-manuals and that will be the locked down spec for 
that release.

This means that openstack 1.1 will be the official spec for diablo, at which 
point we will start working on a new api (we can call it 1.2 but it might be 
best to use a temporary name like 'latest') during the essex release cycle, 
then at essex release we lock the spec down and it becomes the new version of 
the openstack api.

Ultimately I would like the spec to be generated from the code, but as a first 
pass, we should at least be able to edit the future version of the spec as we 
make changes.  I've proposed the current version of the spec here:

https://code.launchpad.net/~vishvanand

Re: [Openstack] Ubuntu run instance error + xen

[Chuck Short]

On Mon, 22 Aug 2011 12:10:59 -0700
Joshua Harlow  wrote:

> Here is also the libvirt.xml section that might be useful:
> 
> $ more instance-0033/libvirt.xml
> 
> instance-0033
> 524288
> 
> linux
> /dev/xvda
> 
> /home/ctoteam/nova/nova/..//instances/instance-0033/kernel
> ro
> 
> 
> 
> 
> 1
> 
> 
> 
>  file='/home/ctoteam/nova/nova/..//instances/instance-0033/disk'/>
>  
> 
> 
> 
> On 8/22/11 11:28 AM, "Joshua Harlow"  wrote:
> 
> Attempting to follow your notes.
> 
> I have the following ubuntu kernel.
> 
> Linux version 2.6.35-24-virtual
> 
> This is just a standard ubuntu UEC image.
> 
> With command line options.
Hi,

Can you try the oneiric version of Ubuntu, You'll probably have an
easier time since it is using Xen 4.1.1 and Oneiric 3.0 with xen
modules built into the linux-image-server debian package.

Regards
chuck

> 
> Command line: root=/dev/xvda ro
> 
> I've got a dom0 running with the following.
> 
> menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 and XEN
> 4.0-amd64' --class debian --class gnu-linux --class gnu --class os
> --class xen {
> 
> Which seems to be right.
> 
> The following error still occurs.
> 
> [0.190303] md: Waiting for all devices to be available before
> autodetect [0.190315] md: If you don't use raid, use
> raid=noautodetect [0.190508] md: Autodetecting RAID arrays.
> [0.190520] md: Scanned 0 and added 0 devices.
> [0.190528] md: autorun ...
> [0.190534] md: ... autorun DONE.
> [0.190629] VFS: Cannot open root device "xvda" or
> unknown-block(0,0) [0.190641] Please append a correct "root="
> boot option; here are the available partitions: [0.190658]
> ca00 1441792 sda driver: vbd [0.190671] Kernel panic -
> not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
> [0.190683] Pid: 1, comm: swapper Not tainted 2.6.35-24-virtual
> #42-Ubuntu [0.190693] Call Trace:
> 
> When switching it to sda it works though. Following your notes it
> seems like the dom0 kernel version shouldn't be having this issue?
> 
> http://lists.debian.org/debian-l10n-english/2010/12/msg00059.html
> 
> On 8/20/11 6:53 AM, "Thomas Goirand"  wrote:
> 
> On 08/20/2011 05:40 AM, Joshua Harlow wrote:
> > So what I've figured out is the following seems to work with xen4.
> 
> The naming of sda vs xvda has nothing to do with the hypervisor, and a
> lot to do with your kernel.
> 
> Thomas
> 
> 


___
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] API Spec

[Vishvananda Ishaya]

Inline
On Aug 22, 2011, at 4:59 PM, Jorge Williams wrote:

> Hi Vish,
> 
> I don't have a problem moving the spec out of docs manuals and into another 
> project even the nova repo.   But, I do have a number of issues with the 
> approach that you're proposing. First, I think that fundamentally there 
> should be a decoupling of the spec and the implementation.   If you have the 
> spec generated from the code than essentially the spec is whatever the code 
> does. It's very difficult to interoperate with specs that are generated this 
> way as the specs tend to be very brittle and opaque (since you have to study 
> the code). If you introduce a  bug in the code that bug filters it's way all 
> the way to the spec (this was a big problem with SOAP and CORBA). It's 
> difficult to detect errors because you cant validate. By keeping the 
> implementation and the spec separate you can validate one against the other. 

The spec SHOULD BE exactly what the code does, verifiably.  I'm proposing that 
we have exactly the existing document, only that the xml and json examples in 
the spec are actually generated from the code so that we know they are 
accurate.  This is a minor point to me though, and could be accomplished by 
testing the spec against the code as well.

> 
> Second, I don't think that the core OpenStack API should change with every 
> OpenStack release. There are a number of efforts to provide multiple 
> implementation of an existing OpenStack API.  We should encourage this, but 
> it becomes difficult if the core spec is in constant flux.  Certainly you can 
> use the extension mechanism to bring functionality out to market quickly, but 
> the process of deciding what goes into the core should be more deliberate. 
> Really good specs, shouldn't need to change very often, think HTTP, X11, 
> SMTP, etc. We need to encourage clients to write support for our spec and we 
> need to also encourage other implementors to write implementations for it. 
> These efforts become very difficult if the spec is in constant flux.

Incrementing the version number is only a problem if we fail to support the old 
versions.  At the rate we are adding new functionality, I think we will easily 
need a new spec every six months for the foreseeable future.  If there are no 
reasonable changes in a six month period, we can skip a release and not have a 
new version of the spec

> 
> -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] API Spec

[Anne Gentle]

I think it makes sense to have an openstack-api project with all the API
docs (specs and learning materials) gathered in one place. I think it's
preferable to have the API separated out from the code for several reasons -
ease of review, ease of check out, also for learning materials for the API
itself.

I'd envision these would go in it for starters:

Compute API (docbook, core + extensions)
Glance API (RST to docbook, core)
Keystone API (docbook, incubation, core + extensions)
Swift API (docbook, core)

Notes:
- Yep, Keystone moved their docbook out of the core code base due to the
"overhead" associated with a large-ish document ensconced with the code.
- Glance's API is documented in a single RST page. We have a simple RST to
docbook tool inhouse at Rackspace that lets me take updates and move them
into docbook.
- Just today I had a request to bring the Load Balancing API into
openstack-manuals for comments and review from
http://wiki.openstack.org/Atlas-LB, since our wiki doesn't enable comments.
I'm not sure what to do with nascent APIs for review that aren't yet in
incubation.

So these are some of my observations having worked with the API docs for a
while, to consider while seeking the ideal solution:
Incubation - how do we indicate an API is incubated?
Pre-incubation/review period - how could a team offer an API up for
community review and commenting?
Core - how do we indicate what is core and how to get extensions? At
Rackspace the Compute API team is working on a solution to getting
extensions and telling people how to use them once they're available.
Source - DocBook is the source for the two biggest API docs, Compute and
Object Storage, Keystone is a close third, and I can get DocBook out of
Glance. Do we need to set DocBook as the standard source?
Output - I'd also like to focus on not only API specs but also deliverables
that help people learn the APIs, such as the frameworks recently opensourced
by Mashery (example: http://developer.klout.com/iodocs) and Wordnik (
http://swagger.wordnik.com/). If we also deliver this type of web tool, we'd
also need JSON or XML as source files (many of which are already embedded
into the DocBook).

I'd like the best of both worlds - API specs and self-documenting APIs. I
think we can get there, and I think a separate API project with a core
review team moves us in that direction.

Thanks for the good discussion here.
Anne

* *
*Anne Gentle*

my blog  | my
book|
LinkedIn  |
Delicious|
Twitter 
On Mon, Aug 22, 2011 at 7:49 PM, Jan Drake  wrote:

> +1
>
>
>
>
> On Aug 22, 2011, at 5:06 PM, Jay Pipes  wrote:
>
> > ++
> >
> > On Mon, Aug 22, 2011 at 7:59 PM, Jorge Williams
> >  wrote:
> >> Hi Vish,
> >> I don't have a problem moving the spec out of docs manuals and into
> another
> >> project even the nova repo.   But, I do have a number of issues with the
> >> approach that you're proposing. First, I think that fundamentally there
> >> should be a decoupling of the spec and the implementation.   If you have
> the
> >> spec generated from the code than essentially the spec is whatever the
> code
> >> does. It's very difficult to interoperate with specs that are generated
> this
> >> way as the specs tend to be very brittle and opaque (since you have to
> study
> >> the code). If you introduce a  bug in the code that bug filters it's way
> all
> >> the way to the spec (this was a big problem with SOAP and CORBA). It's
> >> difficult to detect errors because you cant validate. By keeping the
> >> implementation and the spec separate you can validate one against the
> other.
> >>
> >> Second, I don't think that the core OpenStack API should change with
> every
> >> OpenStack release. There are a number of efforts to provide multiple
> >> implementation of an existing OpenStack API.  We should encourage this,
> but
> >> it becomes difficult if the core spec is in constant flux.  Certainly
> you
> >> can use the extension mechanism to bring functionality out to market
> >> quickly, but the process of deciding what goes into the core should be
> more
> >> deliberate. Really good specs, shouldn't need to change very often,
> think
> >> HTTP, X11, SMTP, etc. We need to encourage clients to write support for
> our
> >> spec and we need to also encourage other implementors to write
> >> implementations for it. These efforts become very difficult if the spec
> is
> >> in constant flux.
> >> -jOrGe W.
> >> On Aug 22, 2011, at 5:43 PM, Vishvananda Ishaya wrote:
> >>
> >> Hey Everyone,
> >> We discussed at the Diablo design summit having API spec changes be
> proposed
> >> along with code changes and reviewed according to the merge process that
> we
> >> use for code.  This has been impossible up until now because the
> canonical
> >> spec has

[Openstack] Keystone Update (and API spec)

[Ziad Sawalha]

Hi Everyone,

Here's a quick Keystone API update. We had aimed to lock down the API last 
Sunday but have been running behind. However, we now have an updated spec. 
We've updated the documentation, WADL, XSD, and sample files in Keystone to 
reflect the core Keystone API we are aiming to implement for Diablo. The specs 
are available here (and in simple text below):

Service (Public) API: 
https://github.com/openstack/keystone/raw/master/keystone/content/service/identitydevguide.pdf
Admin (Private/Privileged) API: 
https://github.com/openstack/keystone/raw/master/keystone/content/admin/identityadminguide.pdf
WADLs/XSD all available in the keystone/content folders in the source code

The latest changes include:

· Minimizing the core API to handle authentication functionality only. 
To do this, we narrowed down the API calls to the list at the bottom of this 
email (also listed on the whiteboard for 
https://blueprints.launchpad.net/keystone/+spec/identity-api).

· We've split the API into Service and Admin APIs (where the Service 
API is generally what is exposed on the internet while the Admin API is on a 
controlled network).

· We've moved the majority of the CRUD logic to extensions (this allows 
the Keystone API to be implemented on top of any back-end system; ex. LDAP).

· Extension support for multiple credentials (as defined 
inhttps://blueprints.launchpad.net/keystone/+spec/support-multiple-credentials)

· Extension support for service registration 
(https://blueprints.launchpad.net/keystone/+spec/keystone-service-registration)

· Removing the default tenant id 
(https://blueprints.launchpad.net/keystone/+spec/remove-default-tenant)

· Refactoring calls to support POST instead of PUT 
(https://github.com/rackspace/keystone/issues/134)

· Support in the model for roles for a user without a tenant 
(https://blueprints.launchpad.net/keystone/+spec/roles-for-none-tenant)


Updates:

  *   We're now using the Gerrit workflow to integrate with Launchpad: 
http://wiki.openstack.org/GerritWorkflow
  *   We're in the process of moving issues to Launchpad (waiting on Launchpad 
to complete the import). We'll be turning off the github.com/rackspace repo as 
soon as that is done.
  *   I'd like to introduce Joe Savak, who has joined the Rackspace team and 
will be dedicated to Identity (and therefore working closely with the Keystone 
project)

A big thank you to everyone who has contributed to the code and setting up the 
environment so far: THANK YOU!

We look forward to your continued input and help as we continue to work toward 
completing the Diablo release. Let us know what you think!

Thanks,
Ziad & Joe

Keystone v2.0 API
Service API:

POST /tokens
Returns a token in exchange for valid credentials.

GET /tenants
Returns a list of tenants for the token provided in the X-Auth-Token 
header.

This implies that a token without a specific tenant returns a list of 
all tenants
associated with the user, and that a token that has a tenant returns 
the single
tenant the token is associated with.

Admin API (Superset of Service API):

POST /tokens
Returns a token in exchange for valid credentials.

GET /tokens/{token_id}
Validates a token.

Returns token expiration, user info, and the user's roles for the given
token.

HEAD /tokens/{token_id}
Validates a token (for performance).

GET /tokens/{token_id}?belongsTo={tenant_id}
Validates that a token belongs to a specific tenant.

Returns token expiration, user info, and the user's roles for the given
token.

HEAD /tokens/{token_id}?belongsTo={tenant_id}
Validates that a token belongs to a specific tenant (for performance).

GET /users/?username={user_name}
Returns detailed information about a specific user, by user name.

GET /users/{user_id}
Returns detailed information about a specific user, by user id.

GET /users/{user_id}/roles
Returns global roles for a specific user (excludes tenant roles).

GET /tenants
Returns a list of all tenants.

GET /tenants/?name={tenant_name}
Returns detailed information about a tenant, by name.

GET /tenants/{tenant_id}
Returns detailed information about a tenant, by id.

GET /tenants/{tenant_id}/endpoints
Returns a list of endpoints associated with a specific tenant.

GET /tenants/{tenant_id}/users/{user_id}/roles
Returns a list of roles for a user on a specific tenant.
This email may include confidential information. If you received it in error, 
please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~op

Re: [Openstack] OpenStack Identity: Keystone API Proposal

[Ziad Sawalha]

We've trimmed down the API significantly and decoupled it from the reference 
implementation we have. That means that behavior can now be determined by the 
implementation or deployment. As long as the contract is adhered to, the way 
the roles and tenants are returned can vary. Here are two examples:

1. In the case of Rackspace, for example, we'll return a token that gives you 
access to a the tenants you own.
2. In the use case documented in the code repo under docs/design, the token 
returned does not have access to any tenants by default and a call to GET 
/tenants is used to get a list of tenants available.

That means the following in answering your questions:
>> Are all possible Service Endpoints returned after authentication based upon 
>> the users relationship to various tenants via roles?
Not necessarily. All endpoints that you get access to by default (as determined 
by the provider) are returned. A further call to GET /tenants could return 
additional tenants you could access by making a scoped authentication call.

>> When the Auth Component validates the token, are all possible roles and 
>> Groups across tenants for that user returned?
All roles (no groups, we've moved those out to an extension for now) that that 
token provides access to should be returned. However, the spec does not dictate 
that these roles be fixed or even stored in the backend. This allows for 
someone implementing a Keystone-compatible API endpoint on top of a system 
which dynamically evaluates and returns a list of roles based on the 
credentials provided (or maybe even the time of day they were presented).

Z

From: "Rouault, Jason (Cloud Services)" 
mailto:jason.roua...@hp.com>>
Date: Thu, 21 Jul 2011 19:53:14 +
To: Ziad Sawalha 
mailto:ziad.sawa...@rackspace.com>>, 
"openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: RE: OpenStack Identity: Keystone API Proposal

Ziad,

What is the expected behavior when requesting and using an unscoped token?  Are 
all possible Service Endpoints returned after authentication based upon the 
users relationship to various tenants via roles?  When the Auth Component 
validates the token, are all possible roles and Groups across tenants for that 
user returned?

Thanks,

Jason

From: 
openstack-bounces+jason.rouault=hp@lists.launchpad.net
 [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf 
Of Ziad Sawalha
Sent: Thursday, July 21, 2011 12:52 PM
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal

Hot, Texas summer regards to all!

Since my last note we have had much progress on Keystone. Particularly:

  *   We now have Nova, Dashboard, Glance, and Keystone integration 
(https://github.com/cloudbuilders/deploy.sh
  *   We've done some work on Swift integration 
(https://github.com/rackspace/keystone/blob/master/keystone/middleware/swift_auth.py)
  *   LDAP an be your backend (https://github.com/rackspace/keystone/pull/102)
  *   We're incubating! Keystone is now officially an OpenStack Incubation 
project.
  *   And many other updates, enhanced testing, stability improvements, etc…
In my last note I called out our latest API proposal and asked for input. We've 
received much of that input – thank you - and have four new blueprints to 
change the API. These are:

  1.  Support Service Registration (blueprint here 
https://blueprints.launchpad.net/keystone/+spec/keystone-service-registration).
  2.  Remove support for 'default' tenant. Instead, a 'Member' or 'default' 
role can be used to manage a default tenant (this may be implemented in the 
legacy_token_auth front end (blueprint here: 
https://blueprints.launchpad.net/keystone/+spec/remove-default-tenant).
  3.  Support for EC2 API and non-password credentials (blueprint here: 
https://blueprints.launchpad.net/keystone/+spec/support-multiple-credentials).
  4.  Support for API versioning in the service catalog (blueprint here: 
https://blueprints.launchpad.net/keystone/+spec/service-catalog-version-support).
I'd like to invite comments on those blueprints (here, by email, or on the 
whiteboards or on the keystone issues list on github. Use the medium you 
prefer). As well as any new blueprint proposals to change the API.

I'd also like to propose a date for locking down the 2.0 API for Diablo. We're 
going to need some time to finish the implementation by feature freeze (Sept 
10th), so I'd like to open the debate up for about three weeks and propose we 
lock down the API by the end of the weekend of August 14th.

Give us your requirements… and let me know if the dates don't work for you or 
your projects/teams.

Best,

Ziad


From: Ziad Sawalha 
mailto:ziad.sawa...@rackspace.com>>
Date: Fri, 10 Jun 2011 18:24:21 -0500
To: "openstack@lists.launchpad.net

Re: [Openstack] API Spec

[Thor Wolpert]

I agree the Specs shouldn't change often ... but just to use your
examples, they where all simplifications of larger specs that took
years to create.

If an API changes and is deprecated, how long does backwards
compatibility stay in place?

Thanks,
Thor W

On Mon, Aug 22, 2011 at 5:49 PM, Jan Drake  wrote:
> +1
>
>
>
>
> On Aug 22, 2011, at 5:06 PM, Jay Pipes  wrote:
>
>> ++
>>
>> On Mon, Aug 22, 2011 at 7:59 PM, Jorge Williams
>>  wrote:
>>> Hi Vish,
>>> I don't have a problem moving the spec out of docs manuals and into another
>>> project even the nova repo.   But, I do have a number of issues with the
>>> approach that you're proposing. First, I think that fundamentally there
>>> should be a decoupling of the spec and the implementation.   If you have the
>>> spec generated from the code than essentially the spec is whatever the code
>>> does. It's very difficult to interoperate with specs that are generated this
>>> way as the specs tend to be very brittle and opaque (since you have to study
>>> the code). If you introduce a  bug in the code that bug filters it's way all
>>> the way to the spec (this was a big problem with SOAP and CORBA). It's
>>> difficult to detect errors because you cant validate. By keeping the
>>> implementation and the spec separate you can validate one against the other.
>>>
>>> Second, I don't think that the core OpenStack API should change with every
>>> OpenStack release. There are a number of efforts to provide multiple
>>> implementation of an existing OpenStack API.  We should encourage this, but
>>> it becomes difficult if the core spec is in constant flux.  Certainly you
>>> can use the extension mechanism to bring functionality out to market
>>> quickly, but the process of deciding what goes into the core should be more
>>> deliberate. Really good specs, shouldn't need to change very often, think
>>> HTTP, X11, SMTP, etc. We need to encourage clients to write support for our
>>> spec and we need to also encourage other implementors to write
>>> implementations for it. These efforts become very difficult if the spec is
>>> in constant flux.
>>> -jOrGe W.
>>> On Aug 22, 2011, at 5:43 PM, Vishvananda Ishaya wrote:
>>>
>>> Hey Everyone,
>>> We discussed at the Diablo design summit having API spec changes be proposed
>>> along with code changes and reviewed according to the merge process that we
>>> use for code.  This has been impossible up until now because the canonical
>>> spec has been in the openstack-manuals project.
>>> My suggestion is that we move the openstack-compute spec into the nova
>>> source tree.  During a six-month release we can propose changes to the spec
>>> by proposing along with the code that changes it.  In the final freeze for
>>> the release, we can increment the spec version number and copy the current
>>> version of the spec into openstack-manuals and that will be the locked down
>>> spec for that release.
>>> This means that openstack 1.1 will be the official spec for diablo, at which
>>> point we will start working on a new api (we can call it 1.2 but it might be
>>> best to use a temporary name like 'latest') during the essex release cycle,
>>> then at essex release we lock the spec down and it becomes the new version
>>> of the openstack api.
>>> Ultimately I would like the spec to be generated from the code, but as a
>>> first pass, we should at least be able to edit the future version of the
>>> spec as we make changes.  I've proposed the current version of the spec
>>> here:
>>> https://code.launchpad.net/~vishvananda/nova/add-api-docs/+merge/72506
>>> Are there any issues with this approach?
>>> Vish
>>>
>>> This email may include confidential information. If you received it in
>>> error, please delete 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
>>>
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Openstack] API Spec

[Vishvananda Ishaya]

Inline

On Aug 22, 2011, at 4:15 PM, Jay Pipes wrote:

> It may be just me, but having DocBookXML in the source tree is hideous
> to me. Not only does it clutter the source tree with non-RST
> documentation, but as you know, reviewing diffs of XML is just about
> makes people want to slit their throats with a spoon. There is a
> special type of person (Anne!) that seem to be impervious to the
> throat-slitting urge and can successfully digest such a review
> request, but for many, the process is too painful.

I hate xml changes as well, but anne + people in manuals don't really have the 
expertise to know if something belongs in the api.  *-core should be 
responsible for the spec for the project.
> 
> In addition to the above gripe, the development, stability, and
> enhancement of the OpenStack APIs can and should (IMHO) be managed
> separately from the source code of the project. The API can evolve in
> the openstack-manuals project and developers can code the OpenStack
> subproject to match the API documented in openstack-manuals project
> (at the tagged version). So, for instance, if the compute API needs to
> change, the API documentation changes would be proposed in
> openstack-manuals, reviewed, discussed and approved. The new API docs
> would be published to something like
> http://docs.openstack.org/compute/2.0/ and developers coding Essex
> features having to do with implementing such a 2.0 API would refer to
> the API documentation there while writing the feature...

If we want to separate the xml code out, we can do a separate nova-spec repo 
for the spec, but this should be managed by nova-core

> 
> Just my 2 cents,
> -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] API Spec

[Jan Drake]

+1




On Aug 22, 2011, at 5:06 PM, Jay Pipes  wrote:

> ++
> 
> On Mon, Aug 22, 2011 at 7:59 PM, Jorge Williams
>  wrote:
>> Hi Vish,
>> I don't have a problem moving the spec out of docs manuals and into another
>> project even the nova repo.   But, I do have a number of issues with the
>> approach that you're proposing. First, I think that fundamentally there
>> should be a decoupling of the spec and the implementation.   If you have the
>> spec generated from the code than essentially the spec is whatever the code
>> does. It's very difficult to interoperate with specs that are generated this
>> way as the specs tend to be very brittle and opaque (since you have to study
>> the code). If you introduce a  bug in the code that bug filters it's way all
>> the way to the spec (this was a big problem with SOAP and CORBA). It's
>> difficult to detect errors because you cant validate. By keeping the
>> implementation and the spec separate you can validate one against the other.
>> 
>> Second, I don't think that the core OpenStack API should change with every
>> OpenStack release. There are a number of efforts to provide multiple
>> implementation of an existing OpenStack API.  We should encourage this, but
>> it becomes difficult if the core spec is in constant flux.  Certainly you
>> can use the extension mechanism to bring functionality out to market
>> quickly, but the process of deciding what goes into the core should be more
>> deliberate. Really good specs, shouldn't need to change very often, think
>> HTTP, X11, SMTP, etc. We need to encourage clients to write support for our
>> spec and we need to also encourage other implementors to write
>> implementations for it. These efforts become very difficult if the spec is
>> in constant flux.
>> -jOrGe W.
>> On Aug 22, 2011, at 5:43 PM, Vishvananda Ishaya wrote:
>> 
>> Hey Everyone,
>> We discussed at the Diablo design summit having API spec changes be proposed
>> along with code changes and reviewed according to the merge process that we
>> use for code.  This has been impossible up until now because the canonical
>> spec has been in the openstack-manuals project.
>> My suggestion is that we move the openstack-compute spec into the nova
>> source tree.  During a six-month release we can propose changes to the spec
>> by proposing along with the code that changes it.  In the final freeze for
>> the release, we can increment the spec version number and copy the current
>> version of the spec into openstack-manuals and that will be the locked down
>> spec for that release.
>> This means that openstack 1.1 will be the official spec for diablo, at which
>> point we will start working on a new api (we can call it 1.2 but it might be
>> best to use a temporary name like 'latest') during the essex release cycle,
>> then at essex release we lock the spec down and it becomes the new version
>> of the openstack api.
>> Ultimately I would like the spec to be generated from the code, but as a
>> first pass, we should at least be able to edit the future version of the
>> spec as we make changes.  I've proposed the current version of the spec
>> here:
>> https://code.launchpad.net/~vishvananda/nova/add-api-docs/+merge/72506
>> Are there any issues with this approach?
>> Vish
>> 
>> This email may include confidential information. If you received it in
>> error, please delete 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
>> 
>> 
> 
> ___
> 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] API Spec

[Jay Pipes]

++

On Mon, Aug 22, 2011 at 7:59 PM, Jorge Williams
 wrote:
> Hi Vish,
> I don't have a problem moving the spec out of docs manuals and into another
> project even the nova repo.   But, I do have a number of issues with the
> approach that you're proposing. First, I think that fundamentally there
> should be a decoupling of the spec and the implementation.   If you have the
> spec generated from the code than essentially the spec is whatever the code
> does. It's very difficult to interoperate with specs that are generated this
> way as the specs tend to be very brittle and opaque (since you have to study
> the code). If you introduce a  bug in the code that bug filters it's way all
> the way to the spec (this was a big problem with SOAP and CORBA). It's
> difficult to detect errors because you cant validate. By keeping the
> implementation and the spec separate you can validate one against the other.
>
> Second, I don't think that the core OpenStack API should change with every
> OpenStack release. There are a number of efforts to provide multiple
> implementation of an existing OpenStack API.  We should encourage this, but
> it becomes difficult if the core spec is in constant flux.  Certainly you
> can use the extension mechanism to bring functionality out to market
> quickly, but the process of deciding what goes into the core should be more
> deliberate. Really good specs, shouldn't need to change very often, think
> HTTP, X11, SMTP, etc. We need to encourage clients to write support for our
> spec and we need to also encourage other implementors to write
> implementations for it. These efforts become very difficult if the spec is
> in constant flux.
> -jOrGe W.
> On Aug 22, 2011, at 5:43 PM, Vishvananda Ishaya wrote:
>
> Hey Everyone,
> We discussed at the Diablo design summit having API spec changes be proposed
> along with code changes and reviewed according to the merge process that we
> use for code.  This has been impossible up until now because the canonical
> spec has been in the openstack-manuals project.
> My suggestion is that we move the openstack-compute spec into the nova
> source tree.  During a six-month release we can propose changes to the spec
> by proposing along with the code that changes it.  In the final freeze for
> the release, we can increment the spec version number and copy the current
> version of the spec into openstack-manuals and that will be the locked down
> spec for that release.
> This means that openstack 1.1 will be the official spec for diablo, at which
> point we will start working on a new api (we can call it 1.2 but it might be
> best to use a temporary name like 'latest') during the essex release cycle,
> then at essex release we lock the spec down and it becomes the new version
> of the openstack api.
> Ultimately I would like the spec to be generated from the code, but as a
> first pass, we should at least be able to edit the future version of the
> spec as we make changes.  I've proposed the current version of the spec
> here:
> https://code.launchpad.net/~vishvananda/nova/add-api-docs/+merge/72506
> Are there any issues with this approach?
> Vish
>
> This email may include confidential information. If you received it in
> error, please delete 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
>
>

___
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] API Spec

[Jorge Williams]

Hi Vish,

I don't have a problem moving the spec out of docs manuals and into another 
project even the nova repo.   But, I do have a number of issues with the 
approach that you're proposing. First, I think that fundamentally there should 
be a decoupling of the spec and the implementation.   If you have the spec 
generated from the code than essentially the spec is whatever the code does. 
It's very difficult to interoperate with specs that are generated this way as 
the specs tend to be very brittle and opaque (since you have to study the 
code). If you introduce a  bug in the code that bug filters it's way all the 
way to the spec (this was a big problem with SOAP and CORBA). It's difficult to 
detect errors because you cant validate. By keeping the implementation and the 
spec separate you can validate one against the other.

Second, I don't think that the core OpenStack API should change with every 
OpenStack release. There are a number of efforts to provide multiple 
implementation of an existing OpenStack API.  We should encourage this, but it 
becomes difficult if the core spec is in constant flux.  Certainly you can use 
the extension mechanism to bring functionality out to market quickly, but the 
process of deciding what goes into the core should be more deliberate. Really 
good specs, shouldn't need to change very often, think HTTP, X11, SMTP, etc. We 
need to encourage clients to write support for our spec and we need to also 
encourage other implementors to write implementations for it. These efforts 
become very difficult if the spec is in constant flux.

-jOrGe W.

On Aug 22, 2011, at 5:43 PM, Vishvananda Ishaya wrote:

Hey Everyone,

We discussed at the Diablo design summit having API spec changes be proposed 
along with code changes and reviewed according to the merge process that we use 
for code.  This has been impossible up until now because the canonical spec has 
been in the openstack-manuals project.

My suggestion is that we move the openstack-compute spec into the nova source 
tree.  During a six-month release we can propose changes to the spec by 
proposing along with the code that changes it.  In the final freeze for the 
release, we can increment the spec version number and copy the current version 
of the spec into openstack-manuals and that will be the locked down spec for 
that release.

This means that openstack 1.1 will be the official spec for diablo, at which 
point we will start working on a new api (we can call it 1.2 but it might be 
best to use a temporary name like 'latest') during the essex release cycle, 
then at essex release we lock the spec down and it becomes the new version of 
the openstack api.

Ultimately I would like the spec to be generated from the code, but as a first 
pass, we should at least be able to edit the future version of the spec as we 
make changes.  I've proposed the current version of the spec here:

https://code.launchpad.net/~vishvananda/nova/add-api-docs/+merge/72506

Are there any issues with this approach?

Vish

This email may include confidential information. If you received it in error, 
please delete 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] API Spec

[Jay Pipes]

Hi Vish! Comments inline...

On Mon, Aug 22, 2011 at 6:43 PM, Vishvananda Ishaya
 wrote:
> Hey Everyone,
> We discussed at the Diablo design summit having API spec changes be proposed
> along with code changes and reviewed according to the merge process that we
> use for code.  This has been impossible up until now because the canonical
> spec has been in the openstack-manuals project.

Well, it's not been impossible :) It's just that the openstack-manuals
project doesn't go through the same code review process as Nova,
Swift, and Glance :) That can easily be changed, no?

> My suggestion is that we move the openstack-compute spec into the nova
> source tree.  During a six-month release we can propose changes to the spec
> by proposing along with the code that changes it.  In the final freeze for
> the release, we can increment the spec version number and copy the current
> version of the spec into openstack-manuals and that will be the locked down
> spec for that release.

It may be just me, but having DocBookXML in the source tree is hideous
to me. Not only does it clutter the source tree with non-RST
documentation, but as you know, reviewing diffs of XML is just about
makes people want to slit their throats with a spoon. There is a
special type of person (Anne!) that seem to be impervious to the
throat-slitting urge and can successfully digest such a review
request, but for many, the process is too painful.

In addition to the above gripe, the development, stability, and
enhancement of the OpenStack APIs can and should (IMHO) be managed
separately from the source code of the project. The API can evolve in
the openstack-manuals project and developers can code the OpenStack
subproject to match the API documented in openstack-manuals project
(at the tagged version). So, for instance, if the compute API needs to
change, the API documentation changes would be proposed in
openstack-manuals, reviewed, discussed and approved. The new API docs
would be published to something like
http://docs.openstack.org/compute/2.0/ and developers coding Essex
features having to do with implementing such a 2.0 API would refer to
the API documentation there while writing the feature...

Just my 2 cents,
-jay

> This means that openstack 1.1 will be the official spec for diablo, at which
> point we will start working on a new api (we can call it 1.2 but it might be
> best to use a temporary name like 'latest') during the essex release cycle,
> then at essex release we lock the spec down and it becomes the new version
> of the openstack api.
> Ultimately I would like the spec to be generated from the code, but as a
> first pass, we should at least be able to edit the future version of the
> spec as we make changes.  I've proposed the current version of the spec
> here:
> https://code.launchpad.net/~vishvananda/nova/add-api-docs/+merge/72506
> Are there any issues with this approach?
> Vish
> ___
> 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] API Spec

[Vishvananda Ishaya]

Hey Everyone,

We discussed at the Diablo design summit having API spec changes be proposed 
along with code changes and reviewed according to the merge process that we use 
for code.  This has been impossible up until now because the canonical spec has 
been in the openstack-manuals project.

My suggestion is that we move the openstack-compute spec into the nova source 
tree.  During a six-month release we can propose changes to the spec by 
proposing along with the code that changes it.  In the final freeze for the 
release, we can increment the spec version number and copy the current version 
of the spec into openstack-manuals and that will be the locked down spec for 
that release.

This means that openstack 1.1 will be the official spec for diablo, at which 
point we will start working on a new api (we can call it 1.2 but it might be 
best to use a temporary name like 'latest') during the essex release cycle, 
then at essex release we lock the spec down and it becomes the new version of 
the openstack api.

Ultimately I would like the spec to be generated from the code, but as a first 
pass, we should at least be able to edit the future version of the spec as we 
make changes.  I've proposed the current version of the spec here:

https://code.launchpad.net/~vishvananda/nova/add-api-docs/+merge/72506

Are there any issues with this approach?

Vish___
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] Git/Gerrit workflow changes for Glance/Keystone

[James E. Blair]

Hi,

Monty and I have added a script originally from the Gluster project to
the Glance and Keystone repositories.  It's designed to make the initial
setup of a newly cloned Git repository with Gerrit easier, and to smooth
the process of submitting changes.  We expect to use the same process
with Swift and Nova when they transition to Git, so early use and
feedback is important.

If you are a Glance or Keystone developer using the Git/Gerrit/Github
workflow, we recommend that you change your git "review" alias in
~/.gitconfig to the following:

 cut 
[alias]
review = !sh `git rev-parse --show-toplevel`/tools/rfc.sh
 cut 

And check the wiki for updated instructions on submitting changes:

  http://wiki.openstack.org/GerritWorkflow#Normal_Workflow

Mostly we've dropped several steps that are now handled automatically by
the script, but there is additional information in there about linking
bugs and blueprints.

If you have a moment to help test the initial project setup functions
performed by the script, we'd greatly appreciate it if you would clone a
new copy of the repository following the instructions here:

  http://wiki.openstack.org/GerritWorkflow#Project_Setup

If you have any problems or questions, feel free to respond here, talk
to mtaylor or jeblair on IRC, file a bug at
https://launchpad.net/openstack-ci>, or submit a patch to
https://github.com/openstack/openstack-ci>.

Thanks!

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

Re: [Openstack] [Keystone] [Nova] server list fails

[Nguyen, Liem Manh]

FYI... I got it working by updating Nova bits to trunk.  I was using an older 
version of Nova.

Cheers,
Liem

From: openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net 
[mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] On Behalf 
Of Nguyen, Liem Manh
Sent: Monday, August 22, 2011 1:16 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] [Keystone] [Nova] server list fails

Hello Stackers,

I tried to run Nova with Keystone (populated with sampledata.sh), using the 
nova-api-paste.ini from Keystone.  Everything seems fine, but when I tried to 
get a list of servers:

curl -v -H 'X-Auth-Token: 887665443383838' http://127.0.0.1:8774/v1.0/servers

I received:

nova.api.openstack): TRACE: Traceback (most recent call last):
(nova.api.openstack): TRACE:   File 
"/usr/lib/pymodules/python2.6/nova/api/openstack/__init__.py", line 60, in 
__call__
(nova.api.openstack): TRACE: return req.get_response(self.application)
(nova.api.openstack): TRACE:   File 
"/usr/lib/pymodules/python2.6/webob/request.py", line 919, in get_response
(nova.api.openstack): TRACE: application, catch_exc_info=False)
(nova.api.openstack): TRACE:   File 
"/usr/lib/pymodules/python2.6/webob/request.py", line 887, in call_application
(nova.api.openstack): TRACE: app_iter = application(self.environ, 
start_response)
(nova.api.openstack): TRACE:   File 
"/root/keystone/keystone/middleware/auth_token.py", line 186, in __call__
(nova.api.openstack): TRACE: return self._forward_request(env, 
start_response, proxy_headers)
(nova.api.openstack): TRACE:   File 
"/root/keystone/keystone/middleware/auth_token.py", line 310, in 
_forward_request
(nova.api.openstack): TRACE: return self.app(env, start_response)
(nova.api.openstack): TRACE:   File 
"/usr/lib/pymodules/python2.6/webob/dec.py", line 147, in __call__
(nova.api.openstack): TRACE: resp = self.call_func(req, *args, 
**self.kwargs)
(nova.api.openstack): TRACE:   File 
"/usr/lib/pymodules/python2.6/webob/dec.py", line 208, in call_func
(nova.api.openstack): TRACE: return self.func(req, *args, **kwargs)
(nova.api.openstack): TRACE:   File 
"/root/keystone/keystone/middleware/nova_auth_token.py", line 96, in __call__
(nova.api.openstack): TRACE: auth_token=auth_token)
(nova.api.openstack): TRACE: TypeError: __init__() got an unexpected keyword 
argument 'auth_token'

Keystone seems to auth fine, though.  Any idea?

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

Re: [Openstack] RPC interfaces?

[Soren Hansen]

2011/8/22 Joshua Harlow :
> Does anyone know if there is a plan to have the RPC/MQ interface between
> openstack components be defined/documented.

We certainly should. We need to be much more careful than we've been
in the past about defining these interfaces and be mindful when we
change them. If we don't, upgrading a Nova deployment is going to be
very painful.

We should go through these API's, review them, document them and write
tests (of they don't exist already) that validate that the
documentation is accurate. That way we'll have a much better chance of
knowing when something breaks backwards or forwards compatibility.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/

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

[Openstack] [Keystone] [Nova] server list fails

[Nguyen, Liem Manh]

Hello Stackers,

I tried to run Nova with Keystone (populated with sampledata.sh), using the 
nova-api-paste.ini from Keystone.  Everything seems fine, but when I tried to 
get a list of servers:

curl -v -H 'X-Auth-Token: 887665443383838' http://127.0.0.1:8774/v1.0/servers

I received:

nova.api.openstack): TRACE: Traceback (most recent call last):
(nova.api.openstack): TRACE:   File 
"/usr/lib/pymodules/python2.6/nova/api/openstack/__init__.py", line 60, in 
__call__
(nova.api.openstack): TRACE: return req.get_response(self.application)
(nova.api.openstack): TRACE:   File 
"/usr/lib/pymodules/python2.6/webob/request.py", line 919, in get_response
(nova.api.openstack): TRACE: application, catch_exc_info=False)
(nova.api.openstack): TRACE:   File 
"/usr/lib/pymodules/python2.6/webob/request.py", line 887, in call_application
(nova.api.openstack): TRACE: app_iter = application(self.environ, 
start_response)
(nova.api.openstack): TRACE:   File 
"/root/keystone/keystone/middleware/auth_token.py", line 186, in __call__
(nova.api.openstack): TRACE: return self._forward_request(env, 
start_response, proxy_headers)
(nova.api.openstack): TRACE:   File 
"/root/keystone/keystone/middleware/auth_token.py", line 310, in 
_forward_request
(nova.api.openstack): TRACE: return self.app(env, start_response)
(nova.api.openstack): TRACE:   File 
"/usr/lib/pymodules/python2.6/webob/dec.py", line 147, in __call__
(nova.api.openstack): TRACE: resp = self.call_func(req, *args, 
**self.kwargs)
(nova.api.openstack): TRACE:   File 
"/usr/lib/pymodules/python2.6/webob/dec.py", line 208, in call_func
(nova.api.openstack): TRACE: return self.func(req, *args, **kwargs)
(nova.api.openstack): TRACE:   File 
"/root/keystone/keystone/middleware/nova_auth_token.py", line 96, in __call__
(nova.api.openstack): TRACE: auth_token=auth_token)
(nova.api.openstack): TRACE: TypeError: __init__() got an unexpected keyword 
argument 'auth_token'

Keystone seems to auth fine, though.  Any idea?

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

[Openstack] RPC interfaces?

[Joshua Harlow]

Does anyone know if there is a plan to have the RPC/MQ interface between 
openstack components be defined/documented.

It seems like it would be something pretty useful to allow others to use/extend 
instead of being a hidden python only RPC method.

Like right now I see the following which looks like python JSON based RPC (via 
MQ):

If say these interfaces were agreed upon, then there is nothing stopping other 
nova components being written in say java

{
'args': {
'instance_id': 52L,
'request_spec': {
'instance_properties': {
'state_description': 'scheduling',
'availability_zone': None,
'ramdisk_id': '',
'instance_type_id': 2L,
'user_data': '',
'vm_mode': None,
'reservation_id': 'r-mziqq3bp',
'root_device_name': None,
'user_id': 'admin',
'display_description': None,
'key_data': 'ssh-rsa',
'state': 0,
'project_id': 'admin',
'metadata': {

},
'kernel_id': '30',
'key_name': u'mykey',
'display_name': None,
'local_gb': 0L,
'locked': False,
'launch_time': '2011-08-22T19: 15: 05Z',
'memory_mb': 512L,
'vcpus': 1L,
'image_ref': 31,
'architecture': None,
'os_type': None
},
'instance_type': {
'rxtx_quota': 0L,
'local_gb': 0L,
'name': 'm1.tiny',
'deleted': False,
'created_at': None,
'updated_at': None,
'memory_mb': 512L,
'vcpus': 1L,
'rxtx_cap': 0L,
'flavorid': 1L,
'swap': 0L,
'extra_specs': {

},
'deleted_at': None,
'id': 2L
},
'num_instances': 1,
'filter': 'nova.scheduler.host_filter.InstanceTypeFilter',
'blob': None
},
'availability_zone': None,
'topic': 'compute',
'admin_password': None,
'injected_files': None
},
'method': 'run_instance'
}


___
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] Ubuntu run instance error + xen

[Joshua Harlow]

Here is also the libvirt.xml section that might be useful:

$ more instance-0033/libvirt.xml

instance-0033
524288

linux
/dev/xvda

/home/ctoteam/nova/nova/..//instances/instance-0033/kernel
ro




1









On 8/22/11 11:28 AM, "Joshua Harlow"  wrote:

Attempting to follow your notes.

I have the following ubuntu kernel.

Linux version 2.6.35-24-virtual

This is just a standard ubuntu UEC image.

With command line options.

Command line: root=/dev/xvda ro

I've got a dom0 running with the following.

menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 and XEN 4.0-amd64' 
--class debian --class gnu-linux --class gnu --class os --class xen {

Which seems to be right.

The following error still occurs.

[0.190303] md: Waiting for all devices to be available before autodetect
[0.190315] md: If you don't use raid, use raid=noautodetect
[0.190508] md: Autodetecting RAID arrays.
[0.190520] md: Scanned 0 and added 0 devices.
[0.190528] md: autorun ...
[0.190534] md: ... autorun DONE.
[0.190629] VFS: Cannot open root device "xvda" or unknown-block(0,0)
[0.190641] Please append a correct "root=" boot option; here are the 
available partitions:
[0.190658] ca00 1441792 sda driver: vbd
[0.190671] Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)
[0.190683] Pid: 1, comm: swapper Not tainted 2.6.35-24-virtual #42-Ubuntu
[0.190693] Call Trace:

When switching it to sda it works though. Following your notes it seems like 
the dom0 kernel version shouldn't be having this issue?

http://lists.debian.org/debian-l10n-english/2010/12/msg00059.html

On 8/20/11 6:53 AM, "Thomas Goirand"  wrote:

On 08/20/2011 05:40 AM, Joshua Harlow wrote:
> So what I've figured out is the following seems to work with xen4.

The naming of sda vs xvda has nothing to do with the hypervisor, and a
lot to do with your kernel.

Thomas


___
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] Xen and Nova networking

[Todd Deshane]

2011/8/22 Rogério Vinhal Nunes :
> Hi, I'm new to Nova and would like to clear up some issues.
>
> The Nova's compute node networking configuration creates the default bridge
> (br100), copying eth0 values and connecting the actual eth0 along with the
> VMs. Xen does almost that, it renames the physical eth0 to peth0 and creates
> a bridge named eth0 that connects the VMs and peth0.
>
> Could Nova work using the Xen's eth0 bridge? I think if it was the old
> '"xenbr0" bridge it could be easier just to change the bridge name in the
> DB, but how does that work even with the controller not habing Xen installed
> (so eth0 would be the real interface)?
>

What version of Xen do you have and on what distro?

Xen 4.1+ doesn't do this crazy renaming anymore and instead uses the
built in distro supported networking. Using the distro supported
networking is likely to work better, so it is often recommended. See:

http://wiki.xensource.com/xenwiki/HostConfiguration/Networking (this
should work with any version of Xen + Linux)

> Also, in the Administrator's Manual, it says that you need KVM + libvirt for
> live migration, would Nova work with Xen for live migration?
>

It should work the same, but I don't know how much it has been tested.
Let us know if it doesn't work.

A lot of the Xen testing up to this point has been on Citrix XenServer
and its open source counterpart XCP. We'd love to see Xen the
hypervisor work fine as it seems that is some interest there too.

libvirt works with Xen hypervisor, so it should work just like it does with KVM.

Feel free to bring xen-specific issues over to the appropriate xen
mailings lists.

Thanks,
Todd

-- 
Todd Deshane
http://www.linkedin.com/in/deshantm
http://www.xen.org/products/cloudxen.html
http://runningxen.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] Ubuntu run instance error + xen

[Joshua Harlow]

Attempting to follow your notes.

I have the following ubuntu kernel.

Linux version 2.6.35-24-virtual

This is just a standard ubuntu UEC image.

With command line options.

Command line: root=/dev/xvda ro

I've got a dom0 running with the following.

menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 and XEN 4.0-amd64' 
--class debian --class gnu-linux --class gnu --class os --class xen {

Which seems to be right.

The following error still occurs.

[0.190303] md: Waiting for all devices to be available before autodetect
[0.190315] md: If you don't use raid, use raid=noautodetect
[0.190508] md: Autodetecting RAID arrays.
[0.190520] md: Scanned 0 and added 0 devices.
[0.190528] md: autorun ...
[0.190534] md: ... autorun DONE.
[0.190629] VFS: Cannot open root device "xvda" or unknown-block(0,0)
[0.190641] Please append a correct "root=" boot option; here are the 
available partitions:
[0.190658] ca00 1441792 sda driver: vbd
[0.190671] Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)
[0.190683] Pid: 1, comm: swapper Not tainted 2.6.35-24-virtual #42-Ubuntu
[0.190693] Call Trace:

When switching it to sda it works though. Following your notes it seems like 
the dom0 kernel version shouldn't be having this issue?

http://lists.debian.org/debian-l10n-english/2010/12/msg00059.html

On 8/20/11 6:53 AM, "Thomas Goirand"  wrote:

On 08/20/2011 05:40 AM, Joshua Harlow wrote:
> So what I've figured out is the following seems to work with xen4.

The naming of sda vs xvda has nothing to do with the hypervisor, and a
lot to do with your kernel.

Thomas


___
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] Xen and Nova networking

[Rogério Vinhal Nunes]

Hi, I'm new to Nova and would like to clear up some issues.

The Nova's compute node networking configuration creates the default bridge
(br100), copying eth0 values and connecting the actual eth0 along with the
VMs. Xen does almost that, it renames the physical eth0 to peth0 and creates
a bridge named eth0 that connects the VMs and peth0.

Could Nova work using the Xen's eth0 bridge? I think if it was the old
'"xenbr0" bridge it could be easier just to change the bridge name in the
DB, but how does that work even with the controller not habing Xen installed
(so eth0 would be the real interface)?

Also, in the Administrator's Manual, it says that you need KVM + libvirt for
live migration, would Nova work with Xen for live migration?

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

Re: [Openstack] Ubuntu run instance error + xen

[Joshua Harlow]

Sounds good.

I'll check it out.

Would this still be needed in the libvirt template?

/usr/lib/xen-4.0/bin/pygrub

On 8/20/11 6:53 AM, "Thomas Goirand"  wrote:

On 08/20/2011 05:40 AM, Joshua Harlow wrote:
> So what I've figured out is the following seems to work with xen4.

The naming of sda vs xvda has nothing to do with the hypervisor, and a
lot to do with your kernel.

Thomas


___
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] [SPAM] euca-authorize err in diablo

[haynes.davis]

Hi Wayne,

8774 isnt returning anything. And  nova list gives "n/a (HTTP 400)"

regards,
Haynes



From: Wayne A. Walls [mailto:wa...@openstack.org]
Sent: Friday, August 19, 2011 8:57 PM
To: Davis, Haynes; openstack@lists.launchpad.net
Subject: Re: [SPAM] [Openstack] euca-authorize err in diablo

Greetings, Haynes!

Are you wanting to run the ec2 API specifically?  I will defer to the list, but 
I believe sometime recently the OSAPI became the default API in Nova, and that 
might explain why 8773 isn't returning anything.  Do you see anything on 8774?

I would guess that none of the euca commands are working for you at this time, 
have you tried the OSAPI commands?
nova list
nova flavor-list
nova image-list
etc..

Cheers,


Wayne




From: mailto:haynes.da...@accenture.com>>
Date: Fri, 19 Aug 2011 20:06:28 +0530
To: mailto:openstack@lists.launchpad.net>>
Subject: [SPAM] [Openstack] euca-authorize err in diablo

HI,

I am installing Diablo using ppa:nova-core/milestone in Lucid. I am following 
the installation steps of OpenStack Compute
Administration Manual for cactus.

While I run euca-authorize -P icmp -t -1:-1 default I get err [Errno 111] 
Connection refused.

Nova.conf is

# cat  /etc/nova/nova.conf
--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
--verbose
--s3_host=x.x.x.x
--rabbit_host= x.x.x.x
--cc_host= x.x.x.x
--ec2_url=http:// x.x.x.x:8773/services/Cloud
--fixed_range=10.0.0.0/16
--network_size=64
--FAKE_subdomain=ec2
--routing_source_ip= x.x.x.x
--sql_connection=mysql://nova:notnova@ x.x.x.x /nova
--network_manager=nova.network.manager.FlatManager


# ps -ef | grep nova
root  1103  1071  0 10:06 ?00:00:00 /usr/bin/python 
/usr/bin/nova-objectstore --uid 109 --gid 65534 --pidfile 
/var/run/nova/nova-objectstore.pid --flagfile=/etc/nova/nova.conf --nodaemon 
--logfile=/var/log/nova/nova-objectstore.log
root  5247 15896  0 10:22 pts/100:00:00 tail -f 
/var/log/nova/nova-api.log
nova 19228 1  1 10:29 ?00:00:00 su -c nova-compute 
--flagfile=/etc/nova/nova.conf nova
nova 19241 19228 45 10:29 ?00:00:00 /usr/bin/python 
/usr/bin/nova-compute --flagfile=/etc/nova/nova.conf
nova 19300 1  0 10:29 ?00:00:00 su -c nova-api 
--flagfile=/etc/nova/nova.conf nova
nova 19308 19300  0 10:29 ?00:00:00 /usr/bin/python 
/usr/bin/nova-api --flagfile=/etc/nova/nova.conf
nova 19323 1  0 10:29 ?00:00:00 su -c nova-scheduler 
--flagfile=/etc/nova/nova.conf nova
nova 19332 19323  0 10:29 ?00:00:00 /usr/bin/python 
/usr/bin/nova-scheduler --flagfile=/etc/nova/nova.conf
nova 19348 1  0 10:29 ?00:00:00 su -c nova-network 
--flagfile=/etc/nova/nova.conf nova
nova 19355 19348  0 10:29 ?00:00:00 /usr/bin/python 
/usr/bin/nova-network --flagfile=/etc/nova/nova.conf
root 19360 10126  0 10:29 pts/000:00:00 grep --color=auto nova


netstat -anp | grep 8773 gives no output

# ps -ef | grep dns
nobody1325 1  0 10:06 ?00:00:00 dnsmasq --strict-order 
--bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= 
--except-interface lo --listen-address 192.168.122.1 --dhcp-range 
192.168.122.2,192.168.122.254 --dhcp-lease-max=253 --dhcp-no-override

if I do killall dnsmasq and service nova-network restart dnsmasq doesn't come 
up.




Any help is appreciated.
Is any  Diablo install doc available?

Regards,
Haynes




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