Re: [Openstack] [Openstack-devel] [Xen-API] nova-xcp-network plugin searching for a xapi0 interface

[Thomas Goirand]

Hi Ewan,

Thanks for your answer.

On 03/21/2012 07:05 AM, Ewan Mellor wrote:
>> -Original Message-
>>
>>> Also, have you tried using DevStack first? It is a good way to get
>> the hang of how the flags work.
>>
>> No it's not! DevStack is for testing with XenServer, and assumes that
>> you'd be working with Ubuntu. Here, I'm testing the Debian packages
>> that
>> we are working on in Debian. Please don't direct me to DevStack, this
>> wont help.
> 
> DevStack _will_ help, and that's why we keep telling you to go look
> there, and I have no idea why you keep refusing.

You are writing the above as if I was being difficult, and refusing to
do my homework. That isn't the case. I have read the scripts, and I did
understand most of it, but some parts are really not easy to understand
without the necessary background knowledge. Namely, the network setup,
which is what I am having issue with currently.

I'm trying to get the VLAN manager to work, and that mode isn't what
Devstack is setting-up: it's setting-up a FlatDHCP. I may try to do a
FlatDHCP to check if it works as expected, but that's not really
satisfying in production for a public cloud.

> You don't have to
> run it, but it's up-to-date, and it's working, so it's a nice, clean,
> self-documenting example of at least one way that someone has managed
> to make this work.

I really *don't agree* with the above. It's not self-documenting, it's
clearly a big hack (not clean at all) that works only in your specific
case (eg: if using CentOS and XenServer 5.6 with Ubuntu Oneiric). As you
said it's "one way" to do things only, and it's all but helping to write
a user documentation or a successful package.

> If you have differences between your system and DevStack because of
> the differences between Debian and Ubuntu or XenServer and XCP, then
> fine. If you have differences that you don't understand, then you're
> probably doing it wrong. That's why we tell you, on a weekly basis,
> to go look at DevStack if you want to see how a flag should be set.

I don't think that the issue is with flags.

> You can either do this the easy way, by following other people's
> working systems, or you can do it the hard way, by deep-diving
> into every single detail. I'm fine if you want to do it the hard
> way -- you'll certainly learn a lot, and it's probably very
> interesting and useful knowledge for the future. Just don't keep
> complaining that it's all too hard and then refuse to take the
> easy option.
> 
> Ewan.

I don't "keep complaining that it's too hard", I complain that there's
little to zero documentation of what is being done, and that one has to
double-guess what is going on in Devstack. You seem to believe that
Devstack is enough to replace a real documentation. If that is the case,
then you are doing a big mistake here.

Remember that I'm a Debian Developer, and that I've been running a
hosting business since 2003. I consider myself as an advance user, which
understands what a vlan is, how bridge is working, and that with all
this, it should be enough knowledge to understand what's going on in a
normal product. It's simply not the case with XCP + Openstack which is
lacking documentation. Have you, by the way, noticed that there's even a
bug that has been filled in Launchpad, about the lack of docs concerning
bridging, OVS and networking?

In a shorter way: if I'm telling you that Devstack isn't enough to
understand what's going on, please trust me!

Lucky, John Garbutt, Dave Scott and Salvatore Orlando have understand
all this, and are trying to help me. As Salvatore just wrote, I am
convince that I'm very close to have the setup working.

Salvatore Orlando has written back to me with some very valuable
information which I need to take time to understand now. I'll read it
carefully today, as I'm sure it will help.

Thomas

P.S: It well may be that there's a bug in Kronos, because when I do "xe
vlan-create", on the screen it's printed "script failing" or something.
I'll test it one more time in order to get the exact error message, and
probably will work with Mike on debugging this issue, which may be
related to the upgrade to the latest version of Open vSwitch (which is
1.4.0 in Debian).

___
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] Please stop the devstack non-sense!

[Joshua Harlow]

Another idea:

http://meego.gitorious.org/meego-developer-tools/spectacle

That python code seems to be able to take a yaml defintion and generate either 
rpm specfiles or debian pkg files.

It might be forked or extended (or both) and used to generate the initial set 
of package definitions for openstack in a non-pkg specific format...

On 3/20/12 11:01 AM, "Justin Santa Barbara"  wrote:

Hi Thomas,

I think devstack has done a lot for the developer's use-case, but I believe we 
should also have a official / semi-official project that does some sort of 
packaging to help the production use-case.  I've proposed a summit discussion: 
http://summit.openstack.org/sessions/view/26

The background: I want a semi-production deployment, but as a developer I still 
want to be able to edit the code (which makes packages inconvenient).  devstack 
is orientated towards e.g. wiping the databases.

I'm hoping that all the various OS packagers can work together, or at least 
tell us what sucks.  As a community, we should solve these problems once, and 
the OpenStack project shouldn't treat them as externalities.  I've been doing 
some initial coding here:
https://github.com/justinsb/openstack-simple-config

The first use case I'm trying to solve is "single node installation of 
OpenStack" that is as easy as possible, but also isn't painting the user into 
the corner.  Think "apt-get openstack", then the user finds they like it and 
grows to a 4 node cluster, all the way up to a 100 node cluster.  So it uses 
KVM, FlatManager, config drive injection, Postgresql, etc. - I'm afraid it is 
still quite "opinionated"!  I have Keystone, Glance & Nova installing.  I'm 
using supervisord to avoid any OS dependencies/flamewars, but I would imagine 
that any OS packager could move it to their preferred init.d flavor easily.  
Swift is next on my list - I was facing the problem that the number of replicas 
isn't changeable, though I have a patch for that now.

If you'd like to work together, I'd love to collaborate (and that holds for 
anyone doing packaging).  I'm hanging out in #openstack-packaging

Justin



___
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-API] nova-xcp-network plugin searching for a xapi0 interface

[Todd Deshane]

On Tue, Mar 20, 2012 at 8:51 PM, Salvatore Orlando
 wrote:

>updated by nova-network, thus ensuring VMs get the IP address specified by the

Looks like the end of this thought got cut off. Was there more?

___
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] Have anyone integrated spice with openstack ?

[Kuo Hugo]

As I know , you have to change libvirt and qemu-kvm versions.

For further information , please check
http://www.spice-space.org/download.html

Server

The SPICE server code is needed when building SPICE support into
QEMU.
0.10.x is the latest stable series. The 0.10.x releases contain the
addition of usb redirection (linux client only), semi-seamless migration,
disabled-by-default multiple client support, and 32 bit server support. It
should be available as a package in your favourite Linux distribution,
which is the preferred way of getting it.
There're some more works have to do though .



2012/3/21 suyi wang 

> Hi all:
> I want to use spice instead of vnc ,  but failed. Have anyone
> integrated spice with openstack ?  Could you share your knowledge with me ?
> Thanks a lot!
>
> --
> Yours.
> suyi
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
+Hugo Kuo+
tonyt...@gmail.com
+ 886 935004793
___
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] Have anyone integrated spice with openstack ?

[suyi wang]

Hi all:
I want to use spice instead of vnc ,  but failed. Have anyone
integrated spice with openstack ?  Could you share your knowledge with me ?
Thanks a lot!

-- 
Yours.
suyi
___
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-API] nova-xcp-network plugin searching for a xapi0 interface

[Salvatore Orlando]

Hi Thomas, 

I can probably help you somehow with Openstack networking on XenServer, as I 
did some work on it in the past.
I see you are trying to use the VLAN manager, but the behaviour is not the 
expected one.
However, since you can spin up instances, and they appear to be attached to the 
appropriate bridge, I'd dare to say you're very close!

In a nutshell, when using the VLAN manager on XenServer:
1) A PIF identified either by (A) the vlan_interface flag or (B) the 
bridge_interface column  in the networks db table will be used for creating a 
XenServer VLAN network. 
 The VLAN tag is found in the vlan column, still in the networks table, and 
by default the first tag is 100, if my memory does not fail me.
2) VIF for VM instances within this network will be plugged in this VLAN 
network. As you said, you won't see the bridge until a VIF is plugged in it. 
This behaviour is the same in XS, XCP, and Kronos.
3) The 'Openstack domU', i.e. the VM running the nova network node, instead 
will not be plugged into this network; since it acts as a gateway for multiple 
VLAN networks, it has to be attached on a VLAN trunk. For this reason it must 
have an interface on the parent bridge of the VLAN bridge where VM instances 
are plugged. I realized this is quite obscure, so to cut a long story short, if 
vlan_interface is eth0 it must be plugged in xenbr0, eth1 --> xenbr1, and so on 
(on Kronos you might also end up with brwlan0).  
4) Within the Openstack domU, 'ip link' is then used to configure VLAN 
interfaces on the 'trunk' port. Each of this vlan interfaces is associated with 
a dnsmasq instance, which will distribute IP addresses to instances. The lease 
file for dnsmasq is constantly updated by nova-network, thus ensuring VMs get 
the IP address specified by the 

With this configuration, VM instances should be able to get the IP address 
assigned to them from the appropriate dnsmasq instance, and should be able to 
communicate without any problem with other VMs on the same network and with the 
their gateway.
The above point (3) probably needs some more explanations. With Open vSwitch, 
we don't really have distinct bridges for different VLANs; even if they appear 
as distinct bridges to linux and xen server, they are actually the same OVS 
instance, which runs a distinct 'fake-bridge' for each VLAN. The 'real' bridge 
is the 'parent' of the fake one. You can easily navigate fake and real bridges 
with ovs-vsctl. 
As you can see I am referring to Openvswitch only. This is for a specific 
reason: the fake-parent mechanism automatically imply that ports which are not 
on a fake bridge are trunk ports. This does not happen with linux bridge. A 
packet forwarded on a VLAN interfaces does not get back in the xenbrX bridge 
for ethX. 

So, coming back to your problem I would check that:
1) The XenServer network whose bridge is xapi0 is configured correctly (check 
PIF, VLAN tag)
2) The Openstack domU is connected to the appropriate bridge according to the 
value of vlan_interface (which seems wrong in your conf file)
3) Open vSwitch is enabled 
4) Check the networks table in your database

I hope I have been exhaustive enough to not become pedant... At this point you 
might wonder why this has not been documented anywhere.
Well, my answer is that it was documented, I am very sure it was. However I 
cannot find the wiki page anymore. I have the sources on my laptop, and I will 
make sure that VLAN networking and possibly all the other network managers on 
xenapi backend are documented; including Quantum.

Regards,
Salvatore


> -Original Message-
> From: openstack-
> bounces+salvatore.orlando=eu.citrix@lists.launchpad.net
> [mailto:openstack-
> bounces+salvatore.orlando=eu.citrix@lists.launchpad.net] On Behalf Of
> John Garbutt
> Sent: 19 March 2012 18:01
> To: 'Thomas Goirand'
> Cc: PKG OpenStack; Dave Scott; openstack@lists.launchpad.net; xen-api
> Subject: Re: [Openstack] [Xen-API] nova-xcp-network plugin searching for a
> xapi0 interface
> 
> Hi,
> 
> Looks like the network configuration is not quite right.
> 
> Have a look at this, for an example of how things could look networking wise
> (when using DevStack and XenServer with two nics):
> http://wiki.openstack.org/XenServer/XenXCPAndXenServer
> 
> The manuals have a good description, although it is a little KVM specific:
> http://docs.openstack.org/trunk/openstack-
> compute/admin/content/configuring-flat-dhcp-networking.html
> 
> I suggested using DevStack because it is the best "documentation" for a
> working set of flags right now (yes, not ideal, we must fix that asap!). Take 
> a
> look:
> https://github.com/openstack-dev/devstack/blob/master/stack.sh#L291
> Note the defaults in the nova code might work for KVM, but will not work for
> XenServer, so you will need to set those flags with more appropriate values.
> 
> Hope that helps,
> John
> 
> -Original Message-
> From: Thomas Goirand [mailto:tho...@goirand.fr]
> Sent:

Re: [Openstack] [Xen-API] nova-xcp-network plugin searching for a xapi0 interface

[Ewan Mellor]

> -Original Message-
> 
> > Also, have you tried using DevStack first? It is a good way to get
> the hang of how the flags work.
> 
> No it's not! DevStack is for testing with XenServer, and assumes that
> you'd be working with Ubuntu. Here, I'm testing the Debian packages
> that
> we are working on in Debian. Please don't direct me to DevStack, this
> wont help.

DevStack _will_ help, and that's why we keep telling you to go look there, and 
I have no idea why you keep refusing.  You don't have to run it, but it's 
up-to-date, and it's working, so it's a nice, clean, self-documenting example 
of at least one way that someone has managed to make this work.

If you have differences between your system and DevStack because of the 
differences between Debian and Ubuntu or XenServer and XCP, then fine.  If you 
have differences that you don't understand, then you're probably doing it 
wrong.  That's why we tell you, on a weekly basis, to go look at DevStack if 
you want to see how a flag should be set.

You can either do this the easy way, by following other people's working 
systems, or you can do it the hard way, by deep-diving into every single 
detail.  I'm fine if you want to do it the hard way -- you'll certainly learn a 
lot, and it's probably very interesting and useful knowledge for the future.  
Just don't keep complaining that it's all too hard and then refuse to take the 
easy option.

Ewan.


___
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] Xen Hypervisor

[Ewan Mellor]

Please supply the actual error messages.  We'll be able to help.

Cheers,

Ewan.

From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net 
[mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf 
Of Alexandre Leites
Sent: Tuesday, March 20, 2012 9:56 AM
To: openstack@lists.launchpad.net
Subject: [Openstack] [OpenStack] Xen Hypervisor

Hi folks,

First let me say that i'm trying to install xen hypervisor and integrate it 
with OpenStack for more than one week. I'm studying OpenStack for a company and 
this company doesn't allow us to use ready scripts (Why? they want to be 
different from the whole world).

I have used some links for references:
https://github.com/openstack-dev/devstack/blob/master/tools/xen/README.md
http://wiki.openstack.org/XenAPI
http://wiki.openstack.org/XenServer/DevStack
http://wiki.openstack.org/XenServer/Install
http://wiki.openstack.org/XenServerDevelopment
http://wiki.openstack.org/XenXCPAndXenServer
http://wiki.xen.org/wiki/XAPI_on_Ubuntu
http://wiki.xen.org/xenwiki/XAPI_on_debian
https://github.com/openstack/openstack-chef/tree/master/cookbooks/xenserver
https://review.openstack.org/#change,5419

Me and my coworker are trying to install this and integrate on a running and 
tested OpenStack infrastructure, so this machines will have just nova-compute 
service. He is trying with XCP and I with XenServer, so let me introduces our 
tries:

1. XCP On Ubuntu (Kronos)
* Install fine
* Doesn't work

2. XCP On CentOS
* Install fine
* We can run a instance of Ubuntu using XenCenter
* Installed nova-compute and configured it.
* No Errors, but when we try to run a instance on it, appears on an error about 
XAPI.
* We read something about privileged guest, how to set it?

3. DevStack (We can't use this, but also tried to)
* Install XenServer (or XCP, we tested on both)
* Following 
https://github.com/openstack-dev/devstack/blob/master/tools/xen/README.md guide
* On Step 4, it wont create ALLINONE.xva and give some errors about directories 
on console (running script with root user on XenServer)

I hope that someone can help me solve this problems, and maybe help someone 
else to install Xen and integrate with OpenStack.

@OffTopic
Why this is so difficult?
___
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's Swift Integration

[Chmouel Boudjnah]

Hi Maru,

I probably can land something by tomorrow or thursday and we can see what
the keystone peoples would want to do with it. since this part of the code
don't affect much keystone core, I have hope this could land before essex
release.

The main problem was that it needed a bit of shuffling around so I wanted
to implement that only for Folsom.

IMO the swift_auth middleware is still usable as it is, having public
container is a use-case but not the most important one.

Cheers,
Chmouel.

On Tue, Mar 20, 2012 at 10:18 PM, Maru Newby  wrote:

> Hi Chmouel,
>
> Skipping for now is pragmatic, but I'd definitely want to implement stubs
> after your change lands to ensure that unit tests always run.
>
> I vote for implementing support for unauthenticated access asap.
>  Anonymous access to Swift is a very important use case, and not having it
> means that  Keystone's swift middleware is not usable as-is.  Deployers
> will have to implement and maintain that functionality themselves until
> this is resolved.  What will it take to have it go in for this release?
>
> Thanks,
>
>
> Maru
>
> On 2012-03-20, at 2:43 AM, Chmouel Boudjnah wrote:
>
> > Hi Maru,
> >
> > Sorry I have been taking long to come to you on this, I have revived
> > review  4529[1] which add the swift tests. I was talking to termie
> > about it sometime ago and the way we decided to do is to skip the
> > tests if Swift is not installed[2]. Feel free to add stubs as this is
> > not ideal.
> >
> > I was working as well on container-sync and anonymous requests but was
> > not sure if this should go in for Folsom or for this release.
> >
> > Cheers,
> > Chmouel.
> >
> > [1] https://review.openstack.org/#change,4529
> > [2] Ideally I would love to have swift.common.*/swiftclient go to
> > another package but that's probably a discussion for Folsom summit.
> >
> > On Tue, Mar 20, 2012 at 3:33 AM, Maru Newby  wrote:
> >> I'd like to write unit tests for keystone.middleware.swift_auth in
> advance of some functional changes (adding support for unauthenticated
> container sync and referrer access).  It appears that swift_auth lacks unit
> tests, though.  Is this due to its dependency on swift, or is there another
> reason?
> >>
> >> Given that untested code is difficult to maintain, what would the best
> option be to add tests for swift_auth?  Ideally the module would just move
> to the swift repo, but if for some reason that's not an option, I'm
> prepared to use stubs.
> >>
> >> Thanks,
> >>
> >>
> >> Maru
> >>
> >> ___
> >> 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] Please stop the devstack non-sense!

[Chris Wright]

* Duncan McGreggor (dun...@dreamhost.com) wrote:
> But, perhaps you just meant: "let's get some consensus from project
> leaders on the recommended way for now" -- and that sounds great to me
> ;-)

Yup, nothing ominous, just community concensus


___
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's Swift Integration

[Maru Newby]

Hi Chmouel,

Skipping for now is pragmatic, but I'd definitely want to implement stubs after 
your change lands to ensure that unit tests always run.

I vote for implementing support for unauthenticated access asap.  Anonymous 
access to Swift is a very important use case, and not having it means that  
Keystone's swift middleware is not usable as-is.  Deployers will have to 
implement and maintain that functionality themselves until this is resolved.  
What will it take to have it go in for this release?

Thanks,


Maru   

On 2012-03-20, at 2:43 AM, Chmouel Boudjnah wrote:

> Hi Maru,
> 
> Sorry I have been taking long to come to you on this, I have revived
> review  4529[1] which add the swift tests. I was talking to termie
> about it sometime ago and the way we decided to do is to skip the
> tests if Swift is not installed[2]. Feel free to add stubs as this is
> not ideal.
> 
> I was working as well on container-sync and anonymous requests but was
> not sure if this should go in for Folsom or for this release.
> 
> Cheers,
> Chmouel.
> 
> [1] https://review.openstack.org/#change,4529
> [2] Ideally I would love to have swift.common.*/swiftclient go to
> another package but that's probably a discussion for Folsom summit.
> 
> On Tue, Mar 20, 2012 at 3:33 AM, Maru Newby  wrote:
>> I'd like to write unit tests for keystone.middleware.swift_auth in advance 
>> of some functional changes (adding support for unauthenticated container 
>> sync and referrer access).  It appears that swift_auth lacks unit tests, 
>> though.  Is this due to its dependency on swift, or is there another reason?
>> 
>> Given that untested code is difficult to maintain, what would the best 
>> option be to add tests for swift_auth?  Ideally the module would just move 
>> to the swift repo, but if for some reason that's not an option, I'm prepared 
>> to use stubs.
>> 
>> Thanks,
>> 
>> 
>> Maru
>> 
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp


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

Re: [Openstack] Keystone auth_token confusion in Swift vs Glance; Persistent tokens or not ?

[Jay Pipes]

Hi Florian, I appreciate your post and sympathize with your 
frustration/confusion. I'll do my best below to help un-confuse :)


On 03/20/2012 12:15 PM, Florian Daniel Otel wrote:

Hello all,

I need some help with inconsistencies and -- in my mind -- confusing
instructions wrt "auth_token" Keytone middleware.

So far I have Keystone and Swift  w/ Keystone auth working well together
(ussing Essex-4 milestone release  of Keystone resp v1.4.6 of Swift).

What I am now  trying is to get  Glance on Swift with Keystone Auth  but
I'm faced with conflicting info that I cannot make sense of

1) Naming inconsistencies -- "token_auth" , "tokenauth" (Keystone resp
Swift) vs "authtoken"  (Glance)

The existing Keystone and Swift docs (e.g. this one:
http://keystone.openstack.org/configuringservices.html#configuring-swift-to-use-keystone*)
*use as names "token_auth" (Keystone) resp "tokenauth" (Swift)  wheareas
in Glance docs the same midldleware (i.e.
"keystone/middleware/auh_token.py") is referred to as "authtoken"  (see
e.g.  here http://glance.openstack.org/authentication.html )

While this may be only pedantic IMHO it would help if things would be
called the same way in different places.  Or, if I'm confusing things,
someone point me out the differences to which is what and why.


Completely agreed, and Chmouel has submitted two patches to address 
these inconsistencies.



2) "auth_token":  Persistent tokens or user/pass ?

As per Jay Pipes comment here:
https://bugs.launchpad.net/glance/+bug/953989/comments/2  (from
2012-03-13)  the concept of long-lived (i.e. persistent) tokens are no
longer supported by the Keystone "auth_token" middleware  -- and that is
listed as why that bug was invalid.


Actually, no not quite. The bug was marked Invalid because the source of 
the issue was three things that Kevin (the bug reporter) had failed to 
do in his setup -- two of which had to do with the authentication and 
one having to do with an incorrect endpoint template placeholder.


Anyway, let me try and explain what the deal is with the "long-lived 
token deprecation" that is mentioned in the bug report.


Previously in Keystone there was the concept of a "service token" -- 
otherwise known as a long-lived token. These special tokens would be 
read from a configuration file or paste-ini file by the auth_token 
middleware that sat, for instance, in the Glance API server pipeline. 
Importantly, these special tokens were **not required to be attached to 
any user or tenant**.


The auth_token middleware is responsible for authenticating -- via 
Keystone -- incoming regular user requests on an API endpoint. For 
example, if I call GET http://example.com:9292/v1/images to get a list 
of images from a Glance API server, and that server was configured with 
the auth_token middleware, then the middleware looks for certain HTTP 
headers in the incoming request.


If the HTTP_X_AUTH_TOKEN header is present in the incoming request,
then the middleware would need to *validate* this authentication token 
with Keystone. This validation call (POST /v2.0/tokens/{$token_id} [1]) 
is a *privileged* call in the Keystone Service Admin API, and as such, 
in order to make the validation request, the HTTP request to Keystone 
itself needs, itself, to supply an HTTP_X_AUTH_TOKEN that is "scoped" to 
some entity that can make this privileged validation call. However, as 
mentioned before, the long-lived "service token" was not scoped to any 
user/tenant, and these "unscoped" tokens were accepted by the validate 
token API call as privileged tokens...


OK, so recent changes removed this inconsistency in the scoping of 
tokens. There are no longer any tokens that are unscoped, and because of 
this, it was found to be more logical to have a user and password 
combination in middleware configuration files instead of a token. So, 
whereas you used to be able to just do:


[filter:authtoken]
...
admin_token = 998877665544

And have a long-lived "service token" with ID "998877665544" added to 
Keystone, you are no longer able to add an unscoped token. Instead, you 
don't add tokens manually at all. Instead, there are privileged user 
accounts that are in a service tenant, and these service user accounts 
are scoped to a set of privileged roles that enable the account to call 
privileged API calls such as POST /v2.0/tokens/{$token} in the Keystone 
Service Admin API.


So, now the middleware configuration looks like this:

[filter:authtoken]
...
service_user = glance
service_password = 

And the auth_token middleware itself actually uses the user/password 
combination to retrieve a privileged token that the middleware stores in 
memory and uses when calling the token validation API calls.


Hope this long explanation makes things a bit more clear and hasn't 
further muddied the waters.


Best,
-jay

[1] 
http://docs.openstack.org/api/openstack-identity-service/2.0/content/GET_validateToken_v2.0_tokens__tokenId__Admin_API_Service_Developer_Operations

Re: [Openstack] Please stop the devstack non-sense!

[Duncan McGreggor]

On Tue, Mar 20, 2012 at 3:14 PM, Chris Wright  wrote:
> * Joshua Harlow (harlo...@yahoo-inc.com) wrote:
>> https://github.com/yahoo/Openstack-DevstackPy
>>
>> Its our chance to make it right :-)
>
> Hopefully your session, or a joint session will make the Common
> development track so we can at least put to rest the best way
> to handle distro agnostic devstack.
>
> thanks,
> -chris

Not sure what the intent here is, but "putting to rest" sounds ominous ;-)

As members of a large and diverse open source project and members of
the larger open source ecosystem, innovation should be embraced. Just
because a decision is made in one cycle, doesn't mean that's the best
way to do something from then on.

I would encourage us, as a group, not to seek (or get chased into) the
rut of dogmatism...

But, perhaps you just meant: "let's get some consensus from project
leaders on the recommended way for now" -- and that sounds great to me
;-)

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

Re: [Openstack] Please stop the devstack non-sense!

[David Kranz]

This is, indeed, the crux of the matter. The release cycle, for both 
diablo and essex, has been that all kinds of incompatible changes are 
made right until
the end. During the critical month before release when we need as many  
people ad possible to deploy and test real clusters, documentation is 
not available. Devstack was a huge step forward in essex because it 
allowed people who already understood the differences between single and 
multi-node to understand and cope with the incompatible changes to the 
components in a way that was known (mostly) to be working. I would guess 
that for every person brave enough to publish their struggles on this 
list, there are many more who do not. The only ways I know to deal with 
this are:


1. More stability. Fewer incompatible changes. This will come over time.
2. Require blueprints, tagged as such, for every API and configuration 
change. Maintain a highly visible list.


The other is longer release cycles with longer freeze periods but that 
is not going to happen.


 -David

On 3/20/2012 2:57 PM, Michael Pittaro wrote:



Is Devstack helpful? I'm sure it is, but for developers only. It's just

bad to think about it as "self-documenting" Openstack, or to think that
it's the solution for everything. It has never been its purpose, and it
isn't taking that path, and thinking that it does is a huge mistake.

Hoping that I will be heard and understood,

Thomas Goirand (zigo)


I think you have hit the real issue of documentation right here.

Devstack has become a lightning rod for install and configuration
problems.  However, I think the real problem is lack of detailed
configuration and installation information - for development,
packagers, and real world installations. devstack is just not
appropriate as a complete replacement for documentation and
dependencies.

Install and configuration documentation is an area we need to focus
on more, and it will need much more community involvement to really
make a difference.  The situation is currently much better than it
was back in September 2011, so progress _is_ being made.

Having said that, the Devstack-Py [1] is an alternative project
which is progressing along nicely.  It is intended to support
multiple distributions, with a focus on developer installs.  Not
100% there yet for all scenarios, but usable and definitely more
hackable.

[1] https://launchpad.net/devstackpy

Mike

___
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] Please stop the devstack non-sense!

[Anne Gentle]

On Tue, Mar 20, 2012 at 1:57 PM, Michael Pittaro  wrote:

>
> Install and configuration documentation is an area we need to focus
> on more, and it will need much more community involvement to really
> make a difference.  The situation is currently much better than it
> was back in September 2011, so progress _is_ being made.
>
>
+1

Agreed, and Mike you've helped here. We need more documentation on
configuration. Specifically here are some doc bugs anyone with the
knowledge could pick up:


 #953134 Docs need Essex info for configuring
nova-api
 openstack-manuals  6

 #953137 Need docs for Configuring the ec2 compatibility api for Compute in
Essex 
 openstack-manuals  6

 #953138 Need doc update for Essex for configuring Compute's storage
system
 openstack-manuals  10

 #953148 Metadata configuration needs to be documented in
Essex
 openstack-manuals  6

 #953151 Network configuration - Linux bridging, OVS, Multi-nic not well
documented for Essex

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

Re: [Openstack] [OpenStack] Xen Hypervisor

[Renuka Apte]

Hi Alexandre,

When using Devstack, which version of Xenserver were you using? If you are 
using 6.0+, the dom0 doesn't have enough space to create an xva, which is why 
we recommend using a separate dev machine.

What errors did it give?

Thanks,
Renuka.

From: Alexandre Leites mailto:alex_...@live.com>>
Date: Tue, 20 Mar 2012 09:56:14 -0700
To: "openstack@lists.launchpad.net" 
mailto:openstack@lists.launchpad.net>>
Subject: [Openstack] [OpenStack] Xen Hypervisor

Hi folks,

First let me say that i'm trying to install xen hypervisor and integrate it 
with OpenStack for more than one week. I'm studying OpenStack for a company and 
this company doesn't allow us to use ready scripts (Why? they want to be 
different from the whole world).

I have used some links for references:
https://github.com/openstack-dev/devstack/blob/master/tools/xen/README.md
http://wiki.openstack.org/XenAPI
http://wiki.openstack.org/XenServer/DevStack
http://wiki.openstack.org/XenServer/Install
http://wiki.openstack.org/XenServerDevelopment
http://wiki.openstack.org/XenXCPAndXenServer
http://wiki.xen.org/wiki/XAPI_on_Ubuntu
http://wiki.xen.org/xenwiki/XAPI_on_debian
https://github.com/openstack/openstack-chef/tree/master/cookbooks/xenserver
https://review.openstack.org/#change,5419

Me and my coworker are trying to install this and integrate on a running and 
tested OpenStack infrastructure, so this machines will have just nova-compute 
service. He is trying with XCP and I with XenServer, so let me introduces our 
tries:

1. XCP On Ubuntu (Kronos)
* Install fine
* Doesn't work

2. XCP On CentOS
* Install fine
* We can run a instance of Ubuntu using XenCenter
* Installed nova-compute and configured it.
* No Errors, but when we try to run a instance on it, appears on an error about 
XAPI.
* We read something about privileged guest, how to set it?

3. DevStack (We can't use this, but also tried to)
* Install XenServer (or XCP, we tested on both)
* Following 
https://github.com/openstack-dev/devstack/blob/master/tools/xen/README.md guide
* On Step 4, it wont create ALLINONE.xva and give some errors about directories 
on console (running script with root user on XenServer)

I hope that someone can help me solve this problems, and maybe help someone 
else to install Xen and integrate with OpenStack.

@OffTopic
Why this is so difficult?
___
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] Please stop the devstack non-sense!

[Joshua Harlow]

Yours might make sense to be added on to devstackPY.

We have a concept of a persona (thanks! to dreamhost pep's) that might be what 
you want/use for this also:

Features:
Supports more than one distribution
   Currently RHEL 6.2 (with epel), Ubuntu 11.10 (12 WIP), Fedora 16 (WIP)
 Supports dry-run mode (to see what would happen)
 Supports varying installation personas (see conf/personas/devstack.sh.yaml)
 A single stack.ini file that shows configuration used/applied
 Supports install/uninstall/starting/stopping of OpenStack components.
   In various styles (daemonizing via forking, screen, upstart)
 Written in python so it matches the style of other OpenStack components.
 Extensively documented distribution specifics (see conf/distros/)
   Packages and pip (with versions known to work!) dependencies
   Any needed distribution specific actions (ie service names...)
 Follows standard software development practices (for everyones sanity).
Functions, classes, objects and more (oh my!)
Still readable by someone with limited python knowledge.
 The ability to be unit-tested!

-Josh

On 3/20/12 11:01 AM, "Justin Santa Barbara"  wrote:

Hi Thomas,

I think devstack has done a lot for the developer's use-case, but I believe we 
should also have a official / semi-official project that does some sort of 
packaging to help the production use-case.  I've proposed a summit discussion: 
http://summit.openstack.org/sessions/view/26

The background: I want a semi-production deployment, but as a developer I still 
want to be able to edit the code (which makes packages inconvenient).  devstack 
is orientated towards e.g. wiping the databases.

I'm hoping that all the various OS packagers can work together, or at least 
tell us what sucks.  As a community, we should solve these problems once, and 
the OpenStack project shouldn't treat them as externalities.  I've been doing 
some initial coding here:
https://github.com/justinsb/openstack-simple-config

The first use case I'm trying to solve is "single node installation of 
OpenStack" that is as easy as possible, but also isn't painting the user into 
the corner.  Think "apt-get openstack", then the user finds they like it and 
grows to a 4 node cluster, all the way up to a 100 node cluster.  So it uses 
KVM, FlatManager, config drive injection, Postgresql, etc. - I'm afraid it is 
still quite "opinionated"!  I have Keystone, Glance & Nova installing.  I'm 
using supervisord to avoid any OS dependencies/flamewars, but I would imagine 
that any OS packager could move it to their preferred init.d flavor easily.  
Swift is next on my list - I was facing the problem that the number of replicas 
isn't changeable, though I have a patch for that now.

If you'd like to work together, I'd love to collaborate (and that holds for 
anyone doing packaging).  I'm hanging out in #openstack-packaging

Justin



___
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] Please stop the devstack non-sense!

[Chris Wright]

* Joshua Harlow (harlo...@yahoo-inc.com) wrote:
> https://github.com/yahoo/Openstack-DevstackPy
> 
> Its our chance to make it right :-)

Hopefully your session, or a joint session will make the Common
development track so we can at least put to rest the best way
to handle distro agnostic devstack.

thanks,
-chris

___
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] Please stop the devstack non-sense!

[Michael Pittaro]

On Tue, Mar 20, 2012 at 9:40 AM, Thomas Goirand  wrote:
> Hi!
>
> I'm again and again always told that I should use Devstack. I don't
> agree, and I'd like to share why. The use of devstack, IMO, has gone out
> of proportions, and it shouldn't have go more far than a Jenkins job.
>
> I'm trying to be constructive and point out issues, hoping it will be
> taken the correct way by the community. (I'm going counter-stream here.)
>
[ snipped ]

> And that's just the first step, later it's the same kind. It's like this
> all-over. Frankly, this is totally unusable in my configuration.
>
> All this is just a big a hack which works only in specific cases. When I
> read in the openstack list that some want to make this hack official, I
> am simply horrified. Even the very simple ifconfig call to get the IP
> address is done wrongly (it's missing LC_ALL=C), and there's lots of
> this kind of assumption.
>

Devstack is definitely an 'opinionated installer', which even
persuaded me to install Ubuntu just to get started  :-)

However, you raise some good points, and many of those should
probably just be logged as bugs against devstack.

> Frankly, this devstack stuff is just a big hack. Nothing is really
> structured with functions. It's not really possible to run the scripts
> twice either (it's not idempotent, AFAIC).
>
> Yes, one can read the devstack scripts and try to understand how it
> works. But it's not easy to follow when you don't know what it's
> supposed to be doing. And let's say one could read and type what it
> does, while adapting it to an environment (Openstack + Kronos in SID, in
> my case), that doesn't give explanations of why things are like that,
> and what kind of configuration choice the user may have. That doesn't
> help either to write a proper documentation or explaining to users how
> all this is supposed to work.
>
> What's making it even worse, is that many people are telling that this
> non-sense scripting is supposed to be a *DOCUMENTATION* ?!? There's
> absolutely *nothing* in the scripts that is explaining why things are
> done. There's comments like this:

[ snipped ...]
>
> And I've been told again, again and again, please use Devstack, because
> this is tested. I'd reply that it has been tested in a few cases, which
> matches some of the developers. These scripts are broken in my
> environment. Reading the scripts doesn't help me to understand. That
> doesn't help me to test my packages. That doesn't help me to write
> documentation.

[ snipped ...]

>> Is Devstack helpful? I'm sure it is, but for developers only. It's just
> bad to think about it as "self-documenting" Openstack, or to think that
> it's the solution for everything. It has never been its purpose, and it
> isn't taking that path, and thinking that it does is a huge mistake.
>
> Hoping that I will be heard and understood,
>
> Thomas Goirand (zigo)
>

I think you have hit the real issue of documentation right here.

Devstack has become a lightning rod for install and configuration
problems.  However, I think the real problem is lack of detailed
configuration and installation information - for development,
packagers, and real world installations. devstack is just not
appropriate as a complete replacement for documentation and
dependencies.

Install and configuration documentation is an area we need to focus
on more, and it will need much more community involvement to really
make a difference.  The situation is currently much better than it
was back in September 2011, so progress _is_ being made.

Having said that, the Devstack-Py [1] is an alternative project
which is progressing along nicely.  It is intended to support
multiple distributions, with a focus on developer installs.  Not
100% there yet for all scenarios, but usable and definitely more
hackable.

[1] https://launchpad.net/devstackpy

Mike

___
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] Xen Hypervisor

[Thomas Goirand]

On 03/21/2012 12:56 AM, Alexandre Leites wrote:
> Hi folks,
> 
> First let me say that i'm trying to install xen hypervisor and integrate
> it with OpenStack for more than one week. I'm studying OpenStack for a
> company and this company doesn't allow us to use ready scripts (Why?
> they want to be different from the whole world).
> 
> I have used some links for references:
> https://github.com/openstack-dev/devstack/blob/master/tools/xen/README.md
> http://wiki.openstack.org/XenAPI
> http://wiki.openstack.org/XenServer/DevStack
> http://wiki.openstack.org/XenServer/Install
> http://wiki.openstack.org/XenServerDevelopment
> http://wiki.openstack.org/XenXCPAndXenServer
> http://wiki.xen.org/wiki/XAPI_on_Ubuntu
> http://wiki.xen.org/xenwiki/XAPI_on_debian
> https://github.com/openstack/openstack-chef/tree/master/cookbooks/xenserver
> https://review.openstack.org/#change,5419
> 
> Me and my coworker are trying to install this and integrate on a running
> and tested OpenStack infrastructure, so this machines will have just
> nova-compute service. He is trying with XCP and I with XenServer, so let
> me introduces our tries:
> 
> 1. XCP On Ubuntu (Kronos)
> * Install fine
> * Doesn't work

Hi,

I've been working with Mike from Citrix on these packages. What exactly
did you install? Just what was available in Ubuntu? These packages would
need to be upgraded to what I've uploaded recently in Debian SID. There
are some notes available here:

http://wiki.xen.org/wiki/XCP_toolstack_on_a_Debian-based_distribution

When you say "Doesn't work", it isn't helpful to know what's wrong. Can
you describe a bit more what doesn't work?

Also, I would advise to try what's in Debian SID, which is more
up-to-date. BTW, if some Ubuntu folks are reading, I would strongly
advise to allow xen-api 1.3.2-4 to be taken from SID, and replace the
(buggy, with sometimes wrong dependencies) 1.3-15 version.

Cheers,

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] Please stop the devstack non-sense!

[Thomas Goirand]

On 03/21/2012 01:35 AM, Mark McLoughlin wrote:
> However, I do think devstack is seriously useful for upstream developers

I have never denied that fact. :)

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] [OpenStack] using xenapi hypervisor

[Sandy Walsh]

http://wiki.openstack.org/XenServer/Development#Legacy_way_to_Prepare_XenServer



From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net 
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of 
Eduardo Nunes [eduardo.ke...@gmail.com]
Sent: Monday, March 19, 2012 3:19 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] [OpenStack] using xenapi hypervisor

I wanna use the xenpi as a hypervisor, i see there are many tutorials, but 
almost all of then is using the devstack, i don't wanna use the devstack, is 
there a tutorial about how i create a domU, what image i sould use on the domU, 
an the conf of xen?
___
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] Please stop the devstack non-sense!

[Justin Santa Barbara]

Hi Thomas,

I think devstack has done a lot for the developer's use-case, but I believe
we should also have a official / semi-official project that does some sort
of packaging to help the production use-case.  I've proposed a summit
discussion: http://summit.openstack.org/sessions/view/26

The background: I want a semi-production deployment, but as a developer I
still want to be able to edit the code (which makes packages inconvenient).
 devstack is orientated towards e.g. wiping the databases.

I'm hoping that all the various OS packagers can work together, or at least
tell us what sucks.  As a community, we should solve these problems once,
and the OpenStack project shouldn't treat them as externalities.  I've been
doing some initial coding here:
https://github.com/justinsb/openstack-simple-config

The first use case I'm trying to solve is "single node installation of
OpenStack" that is as easy as possible, but also isn't painting the user
into the corner.  Think "apt-get openstack", then the user finds they like
it and grows to a 4 node cluster, all the way up to a 100 node cluster.  So
it uses KVM, FlatManager, config drive injection, Postgresql, etc. - I'm
afraid it is still quite "opinionated"!  I have Keystone, Glance & Nova
installing.  I'm using supervisord to avoid any OS dependencies/flamewars,
but I would imagine that any OS packager could move it to their preferred
init.d flavor easily.  Swift is next on my list - I was facing the problem
that the number of replicas isn't changeable, though I have a patch for
that now.

If you'd like to work together, I'd love to collaborate (and that holds for
anyone doing packaging).  I'm hanging out in #openstack-packaging

Justin
___
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 2011-3 with python-novaclient 2.6.4 issue

[Vijay]

Hello,
I am using python-novaclient 2.6.4 with Keystone 2011.3 version.
I am getting the following error:
 
 nova --debug list
('JAY BELTUR \n', 'http://16.78.118.156:5000/tokens')
connect: (16.78.118.156, 5000)
send: 'POST /tokens HTTP/1.1\r\nHost: 16.78.118.156:5000\r\nContent-Length: 
103\r\ncontent-type: application/json\r\naccept-encoding: gzip, 
deflate\r\nuser-agent: python-novaclient\r\n\r\n{"auth": 
{"passwordCredentials": {"username": "adminUser", "password": "secretword"}, 
"tenantId": "2"}}'
reply: 'HTTP/1.1 200 OK\r\n'
header: Content-Type: application/json; charset=UTF-8
header: Content-Length: 946
header: Date: Tue, 20 Mar 2012 17:52:03 GMT
Traceback (most recent call last):
  File "/usr/bin/nova", line 9, in 
    load_entry_point('python-novaclient==2.6.4', 'console_scripts', 'nova')()
  File "/usr/lib/python2.7/dist-packages/novaclient/shell.py", line 219, in main
    OpenStackComputeShell().main(sys.argv[1:])
  File "/usr/lib/python2.7/dist-packages/novaclient/shell.py", line 176, in main
    self.cs.authenticate()
  File "/usr/lib/python2.7/dist-packages/novaclient/v1_1/client.py", line 61, 
in authenticate
    self.client.authenticate()
  File "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 149, in 
authenticate
    auth_url = self._v2_auth(auth_url)
  File "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 200, in 
_v2_auth
    service_catalog.ServiceCatalog(body)
  File "/usr/lib/python2.7/dist-packages/novaclient/service_catalog.py", line 
91, in __init__
    super(ServiceCatalog, self).__init__(resource)
  File "/usr/lib/python2.7/dist-packages/novaclient/service_catalog.py", line 
43, in __init__
    for attr, val in res_value.items():
AttributeError: 'list' object has no attribute 'items'

Thanks,
-VJ___
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] Please stop the devstack non-sense!

[Mark McLoughlin]

Hi Thomas,

On Wed, 2012-03-21 at 00:40 +0800, Thomas Goirand wrote:

> I'm again and again always told that I should use Devstack. I don't
> agree, and I'd like to share why.

I'd summarize your points as:

  - devstack is only tested for a specific version of Ubuntu

  - you're working on making OpenStack available for Debian users

  - devstack is neither documentation nor the canonical way of deploying
OpenStack

  - it's not helpful for upstream developers to point downstream users 
or packagers at devstack

  - developers should work on a git checkout of a single project and 
packages for the other projects

I mostly agree with you. Downstream users want to consume packages and
upstream developers should be concious of what downstream packagers need
to do in order to get OpenStack into the hands of these users.

However, I do think devstack is seriously useful for upstream developers
and I'm delighted that it's gaining Fedora support because it means I'll
use it more for my upstream work.

I've worked as downstream packager and upstream developer on quite a
number of projects before OpenStack and came to the conclusion long ago
that they're two completely different modes of development. When I'm
working on Fedora packaging, I just use packages and a clean Fedora
install. When I'm hacking on upstream code, I completely avoid packages
and use whatever tools (e.g. devstack, virtualenv) other upstream
developers use.

Cheers,
Mark.


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

Re: [Openstack] Please stop the devstack non-sense!

[Chmouel Boudjnah]

Hi Thomas,

On Tue, Mar 20, 2012 at 4:40 PM, Thomas Goirand  wrote:
> The same mess applies in the devstack not-for-XenServer. In some cases,
> some tools are apt-get installed. I can see for example 'apt-get install
> sudo'. But stack.sh assumes (god knows why) that "screen" is already

screen is installed via packages and devstack don't assume it's already
installed :

https://github.com/openstack-dev/devstack/blob/master/files/apts/general

> Frankly, this devstack stuff is just a big hack. Nothing is really
> structured with functions. It's not really possible to run the scripts
> twice either (it's not idempotent, AFAIC).

I haven't tested the xen support but for the default install, I have
quickly spawned a VM on my laptop, downloaded devstack and ran it twice
and except having to kill screen[1] between the two run it was actually
the right thing (ie: redone the configuration).

> I don't think anyway that if you are a developer, you will be working on
> absolutely all packages (nova, glance, keystone, swift, quantum...) that
> we have available in Openstack. In most cases, you'd be working on *one*
> of the Git checkout, and the rest of could well be downloaded and
> installed, either through the PPA, or from Ubuntu directly. So why using
> devstack which will checkout absolutely all components from Github? This
> doesn't make sense either. Also, if this continues, none of the
> developers will be testing the final result (eg: the packages).

we have the ENABLED_SERVICES= variable for that and we have lately
fixed a lot of those bugs.
(albeit it does indeed  check-in nova currently for all services which
is a bug that need to be
fixed).

Chmouel.

[1] Which devstack had kindly advised me to do.

___
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] Please stop the devstack non-sense!

[Joshua Harlow]

Try:

https://github.com/yahoo/Openstack-DevstackPy

Its our chance to make it right :-)

Contributions welcome ;-)

See features @ https://github.com/yahoo/Openstack-DevstackPy/wiki

And a beginner guide @ 
https://github.com/yahoo/Openstack-DevstackPy/wiki/Simple-Setup

Let the revolution begin! Haha :-P

On 3/20/12 9:40 AM, "Thomas Goirand"  wrote:

Hi!

I'm again and again always told that I should use Devstack. I don't
agree, and I'd like to share why. The use of devstack, IMO, has gone out
of proportions, and it shouldn't have go more far than a Jenkins job.

I'm trying to be constructive and point out issues, hoping it will be
taken the correct way by the community. (I'm going counter-stream here.)

Here's the kind of answer I got privately. And that's just as an
example, I could have taken it from someone else. In fact, the persons
who wrote that to me were *really* helpful, and I am very thankful for
their help. (note: removed names since it's of no use for the point I am
willing to make)

Somebody wrote to me:
> I replied:
>> Somebody wrote to me:
>>> I just read in another post of yours that you do not use DevStack.
>>>
>>> Unfortunately resources are tight, and we only work on a number of
>>> possible deployment scenarios and DevStack is one of them. Any
>>> reason why you do not use devstack?
>>
>> Because I'm a Debian Developer working on the packaging of both
>> Openstack and XCP. I'm the one who uploaded XCP (and the other 7
>> packages it needs) in Debian.
>
> I see...
>
> but wouldn't be a better use of anyone's time if you get a hang of how
> things fit together by playing with what it's currently documented
> (albeit in a patchy way?), so that you can come on the mailing list
> with a more accurate description of what the problems are? We can't
> help otherwise.
>
>> So what I want to test is the packaging, not to see if Devstack is
>> written properly...
>
> Your strict attitude is not going to get you anywhere. I could say
> that I want to test DevStack/OpenStack on Ubuntu and I don't give a
> damn about your Debian problems, but I don't, because I care and want
> to help you getting on with OpenStack regardless. Using devstack is
> not the final goal, is just a mean for you to get where you wanna be.

Let me explain.

Devstack, and in my case, the XenServer part of it, makes very dangerous
assumptions. Here they are:
- running XenServer (and not Kronos)
- It will be XenServer 5.6 (and not the latest XCP or XenServer)
- dom0 is running CentOS
- locales are set to English (well, lucky that's the case, but it well
could be that the "ifconfig" call of devstack would fail...).
- running under Ubuntu, or be willing to use non-packaged stuff

A few examples. There's yum calls in the XenServer dom0 scripts, as well
as (even more horrifying) getting a random git version from
googlecode.com, building and "make install", without even checking if my
build environment is sane. There's stuff like echo "FORWARD_IPV4=YES" >>
/etc/sysconfig/network (in Debian, you'd edit /etc/sysctl.conf and run
"sysctl -p). Even the XCP calls are wrong: xe sr-list --minimal
name-label="Local storage" will not return anything on my setup, because
my name-label for the local storage is different (and frankly, why
imposing such name-label when there's a default SR thing?).

Another example. Look at the first bit of the build_domU.sh. It does
start the create_network function, which does this:

if [ ! $(xe network-list --minimal params=bridge | grep -w
--only-matching $br) ]
then
  echo "Specified bridge $br does not exist"
  echo "If you wish to use defaults, please keep the bridge name empty"
  exit 1

Unfortunately, Kronos, which is newer than XenServer 5.6, doesn't create
a bridge when you create a new network. It only creates it when you need
a new interface to join it.

The consequence is very simple: it doesn't work!!!

And that's just the first step, later it's the same kind. It's like this
all-over. Frankly, this is totally unusable in my configuration.

All this is just a big a hack which works only in specific cases. When I
read in the openstack list that some want to make this hack official, I
am simply horrified. Even the very simple ifconfig call to get the IP
address is done wrongly (it's missing LC_ALL=C), and there's lots of
this kind of assumption.

The same mess applies in the devstack not-for-XenServer. In some cases,
some tools are apt-get installed. I can see for example 'apt-get install
sudo'. But stack.sh assumes (god knows why) that "screen" is already
installed. For an unknown reason, stack.sh will also try to write
#includedir /etc/sudoers.d in the sudoers file (isn't it supposed to be
there by default?). I've been reading about "non-apt" distro, but I
believe that it's only Ubuntu centric in fact:
if [[ ! ${DISTRO} =~ (oneiric|precise) ]]; then
...
exit 1
which I think is going too far.

Frankly, this devstack stuff is just a big hack. Nothing is really
structured with functio

Re: [Openstack] [OpenStack] using xenapi hypervisor

[Thomas Goirand]

On 03/20/2012 02:19 AM, Eduardo Nunes wrote:
> I wanna use the xenpi as a hypervisor, i see there are many tutorials,
> but almost all of then is using the devstack, i don't wanna use the
> devstack, is there a tutorial about how i create a domU, what image i
> sould use on the domU, an the conf of xen?

I can see I'm not the only one feeling very frustrated here... :)

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] Can't delete instances with "error" status.

[Guilherme Birk]

I'm attempting to make a python script that controls all my virtual machines. 
Sometimes, when the script identifies that exists an instance with status of 
"error", he creates a new instance and tries to delete the old one with curl 
commands, but I'm not getting any response and the VM isn't deleted. When I 
execute euca-terminate instance  I got nothing too. How I should delete 
instances with error status ? I didn't found any way using nova-manage too. 
  ___
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 auth_token confusion in Swift vs Glance; Persistent tokens or not ?

[Deepak Garg]

HI Florian,

The name of apps/middleware in wsgi pipeline doesn't matter unless the
location pointed by paste.app_factory or
paste.filter_factory remains the same. So, the following two
configurations are same:


[pipeline:main]
pipeline = catch_errors healthcheck cache tokenauth keystone proxy-server

[filter:tokenauth]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
--


[pipeline:main]
pipeline = catch_errors healthcheck cache authtoken keystone proxy-server

[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
--

Please notice that I have just replaced the word 'tokenauth' with
'authtoken'. We may even use the
word 'magictoken' without making any difference as long as the
middleware pointed by "paste.filter_factory =
keystone.middleware.auth_token:filter_factory"  remains the same.

Now whenever you use a nova/swift/quantum cli and pass a token with
it, the corresponding service (say nova in this case)
verifies your passed token with Keystone. Now Keystone needs to be
assured that the service making the 'token validation call'
is a valid one. So it uses the admin_token and other credentials saved
in the conf file of that particular service to get an admin token
and then make a call (using the admin token) to verify the user token.


Hope it answers both of your questions.


Cheers,
Deepak





On Tue, Mar 20, 2012 at 9:45 PM, Florian Daniel Otel
 wrote:
> Hello all,
>
> I need some help with inconsistencies and -- in my mind -- confusing
> instructions wrt "auth_token" Keytone middleware.
>
> So far I have Keystone and Swift  w/ Keystone auth working well together
> (ussing Essex-4 milestone release  of Keystone resp v1.4.6 of Swift).
>
> What I am now  trying is to get  Glance on Swift with Keystone Auth  but I'm
> faced with conflicting info that I cannot make sense of
>
> 1) Naming inconsistencies -- "token_auth" ,  "tokenauth" (Keystone resp
> Swift) vs "authtoken"  (Glance)
>
> The existing Keystone and Swift docs (e.g. this one:
> http://keystone.openstack.org/configuringservices.html#configuring-swift-to-use-keystone
> ) use as names "token_auth" (Keystone) resp  "tokenauth" (Swift)  wheareas
> in Glance docs the same midldleware (i.e.
> "keystone/middleware/auh_token.py") is referred to as "authtoken"  (see
> e.g.  here http://glance.openstack.org/authentication.html )
>
> While this may be only pedantic IMHO it would help if things would be called
> the same way in different places.  Or, if I'm confusing things, someone
> point me out the differences to which is what and why.
>
> 2) "auth_token":  Persistent tokens or user/pass ?
>
> As per Jay Pipes comment here:
> https://bugs.launchpad.net/glance/+bug/953989/comments/2  (from 2012-03-13)
> the concept of long-lived (i.e. persistent) tokens are no longer supported
> by the Keystone "auth_token" middleware  -- and that is listed as why that
> bug was invalid.
>
> Now, that gets me _really_ confused: My working Keystone (again, as per E4)
> + Swift (as per v1.4.6) use persistent tokens just fine. E.g. my WSGI
> pipleline for the swift proxy server looks like this:
>
> [pipeline:main]
> pipeline = catch_errors healthcheck cache tokenauth keystone proxy-server
>
> ..
> with  the corresponding:
>
> ...
> [filter:keystone]
> paste.filter_factory = keystone.middleware.swift_auth:filter_factory
> operator_roles = admin, SwiftOperator
>
> [filter:tokenauth]
> paste.filter_factory = keystone.middleware.auth_token:filter_factory
> service_protocol = http
> service_port = 5000
> service_host = 127.0.0.1
> auth_port = 5001
> auth_host = 127.0.0.1
> admin_token = 999888777666
> delay_auth_decision = 0
> ...
>
> Now, the question is: Since we are now to stop using long-lived tokens
> hardcoded as "admin_token" in "keystone.conf", resp in the "auth_token"
> middleware sections of swift resp, glance, how is a user/pass config
> supposed to look  like  ? examples ?
>
> Sorry if this question is not as clearly laid out is it should be, reason is
> this is all very confusing to me  (maybe time for me to get a rubber
> ducky and explain it all ...)
>
> Thanks in advance for the help,
>
> Florian
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>



-- 

Deepak Garg,
Data Center and Cloud Div.
Citrix R&D, India
Skype-id: deepakgarg.iit

___
Mailing list: https://launchpad.net/~openstack
P

Re: [Openstack] Keystone auth_token confusion in Swift vs Glance; Persistent tokens or not ?

[Chmouel Boudjnah]

On Tue, Mar 20, 2012 at 4:15 PM, Florian Daniel Otel
 wrote:
> 1) Naming inconsistencies -- "token_auth" ,  "tokenauth" (Keystone resp
> Swift) vs "authtoken"  (Glance)
[...]
> While this may be only pedantic IMHO it would help if things would be called

That's correct, I started to address it in devstack[1] and have one on
the way for updating the keystone docs[2] and the manuals.

> Now, the question is: Since we are now to stop using long-lived tokens
> hardcoded as "admin_token" in "keystone.conf", resp in the "auth_token"
> middleware sections of swift resp, glance, how is a user/pass config
> supposed to look  like  ? examples ?

This should be as simple as :

https://github.com/openstack-dev/devstack/blob/master/files/swift/proxy-server.conf#L34

Cheers,
Chmouel.

[1] 
https://github.com/openstack-dev/devstack/commit/bd07d61c4545c52d39b9c957ff9e4423525ca452
[2] https://review.openstack.org/5573

___
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] Xen Hypervisor

[Alexandre Leites]

Hi folks,

First let me say that i'm trying to install xen hypervisor and integrate it 
with OpenStack for more than one week. I'm studying OpenStack for a company and 
this company doesn't allow us to use ready scripts (Why? they want to be 
different from the whole world).

I have used some links for references:
https://github.com/openstack-dev/devstack/blob/master/tools/xen/README.md
http://wiki.openstack.org/XenAPI
http://wiki.openstack.org/XenServer/DevStack
http://wiki.openstack.org/XenServer/Install
http://wiki.openstack.org/XenServerDevelopment
http://wiki.openstack.org/XenXCPAndXenServer
http://wiki.xen.org/wiki/XAPI_on_Ubuntu
http://wiki.xen.org/xenwiki/XAPI_on_debian
https://github.com/openstack/openstack-chef/tree/master/cookbooks/xenserver
https://review.openstack.org/#change,5419

Me and my coworker are trying to install this and integrate on a running and 
tested OpenStack infrastructure, so this machines will have just nova-compute 
service. He is trying with XCP and I with XenServer, so let me introduces our 
tries:

1. XCP On Ubuntu (Kronos)
* Install fine
* Doesn't work

2. XCP On CentOS
* Install fine
* We can run a instance of Ubuntu using XenCenter
* Installed nova-compute and configured it.
* No Errors, but when we try to run a instance on it, appears on an error about 
XAPI.
* We read something about privileged guest, how to set it?

3. DevStack (We can't use this, but also tried to)
* Install XenServer (or XCP, we tested on both)
* Following 
https://github.com/openstack-dev/devstack/blob/master/tools/xen/README.md guide
* On Step 4, it wont create ALLINONE.xva and give some errors about directories 
on console (running script with root user on XenServer)

I hope that someone can help me solve this problems, and maybe help someone 
else to install Xen and integrate with OpenStack.

@OffTopic
Why this is so difficult?
  ___
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] Horizon 2012.1 RC1 available

[Thierry Carrez]

Hello everyone,

The tarball for the first release candidate for OpenStack Dashboard
(Horizon) 2012.1 (codenamed "Essex") is now available at:

https://launchpad.net/horizon/essex/essex-rc1

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the 2012.1 final
version. You are therefore strongly encouraged to test and validate it.

You should test the tarballs above, but you also can directly use the
milestone-proposed branch at:

https://github.com/openstack/horizon/tree/milestone-proposed

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/horizon/+filebug

and tag it "essex-rc-potential" to bring it to Devin's attention.

Note that the "master" branch of Horizon is now open for Folsom
development, feature freeze restrictions no longer apply.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

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

Re: [Openstack] [openstack] [keystone] Keystone XSDs?

[Dolph Mathews]

WADL's and XSD's were recently moved to the identity API repo.

WADL's:
https://github.com/openstack/identity-api/tree/master/openstack-identity-api/src/docbkx


XSD's:
https://github.com/openstack/identity-api/tree/master/openstack-identity-api/src/docbkx/common/xsd

-Dolph

On Tue, Mar 20, 2012 at 10:59 AM, Nguyen, Liem Manh wrote:

>  Hello stackers,
>
> ** **
>
> I checked out the new Keystone (KSL), and the XSD’s and WADL’s are not
> there anymore…  Do they live somewhere else now?
>
> ** **
>
> Thanks,
>
> Liem
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Please stop the devstack non-sense!

[Thomas Goirand]

Hi!

I'm again and again always told that I should use Devstack. I don't
agree, and I'd like to share why. The use of devstack, IMO, has gone out
of proportions, and it shouldn't have go more far than a Jenkins job.

I'm trying to be constructive and point out issues, hoping it will be
taken the correct way by the community. (I'm going counter-stream here.)

Here's the kind of answer I got privately. And that's just as an
example, I could have taken it from someone else. In fact, the persons
who wrote that to me were *really* helpful, and I am very thankful for
their help. (note: removed names since it's of no use for the point I am
willing to make)

Somebody wrote to me:
> I replied:
>> Somebody wrote to me:
>>> I just read in another post of yours that you do not use DevStack.
>>>
>>> Unfortunately resources are tight, and we only work on a number of
>>> possible deployment scenarios and DevStack is one of them. Any
>>> reason why you do not use devstack?
>>
>> Because I'm a Debian Developer working on the packaging of both
>> Openstack and XCP. I'm the one who uploaded XCP (and the other 7
>> packages it needs) in Debian.
>
> I see...
>
> but wouldn't be a better use of anyone's time if you get a hang of how
> things fit together by playing with what it's currently documented
> (albeit in a patchy way?), so that you can come on the mailing list
> with a more accurate description of what the problems are? We can't
> help otherwise.
>
>> So what I want to test is the packaging, not to see if Devstack is
>> written properly...
>
> Your strict attitude is not going to get you anywhere. I could say
> that I want to test DevStack/OpenStack on Ubuntu and I don't give a
> damn about your Debian problems, but I don't, because I care and want
> to help you getting on with OpenStack regardless. Using devstack is
> not the final goal, is just a mean for you to get where you wanna be.

Let me explain.

Devstack, and in my case, the XenServer part of it, makes very dangerous
assumptions. Here they are:
- running XenServer (and not Kronos)
- It will be XenServer 5.6 (and not the latest XCP or XenServer)
- dom0 is running CentOS
- locales are set to English (well, lucky that's the case, but it well
could be that the "ifconfig" call of devstack would fail...).
- running under Ubuntu, or be willing to use non-packaged stuff

A few examples. There's yum calls in the XenServer dom0 scripts, as well
as (even more horrifying) getting a random git version from
googlecode.com, building and "make install", without even checking if my
build environment is sane. There's stuff like echo "FORWARD_IPV4=YES" >>
/etc/sysconfig/network (in Debian, you'd edit /etc/sysctl.conf and run
"sysctl -p). Even the XCP calls are wrong: xe sr-list --minimal
name-label="Local storage" will not return anything on my setup, because
my name-label for the local storage is different (and frankly, why
imposing such name-label when there's a default SR thing?).

Another example. Look at the first bit of the build_domU.sh. It does
start the create_network function, which does this:

if [ ! $(xe network-list --minimal params=bridge | grep -w
--only-matching $br) ]
then
  echo "Specified bridge $br does not exist"
  echo "If you wish to use defaults, please keep the bridge name empty"
  exit 1

Unfortunately, Kronos, which is newer than XenServer 5.6, doesn't create
a bridge when you create a new network. It only creates it when you need
a new interface to join it.

The consequence is very simple: it doesn't work!!!

And that's just the first step, later it's the same kind. It's like this
all-over. Frankly, this is totally unusable in my configuration.

All this is just a big a hack which works only in specific cases. When I
read in the openstack list that some want to make this hack official, I
am simply horrified. Even the very simple ifconfig call to get the IP
address is done wrongly (it's missing LC_ALL=C), and there's lots of
this kind of assumption.

The same mess applies in the devstack not-for-XenServer. In some cases,
some tools are apt-get installed. I can see for example 'apt-get install
sudo'. But stack.sh assumes (god knows why) that "screen" is already
installed. For an unknown reason, stack.sh will also try to write
#includedir /etc/sudoers.d in the sudoers file (isn't it supposed to be
there by default?). I've been reading about "non-apt" distro, but I
believe that it's only Ubuntu centric in fact:
if [[ ! ${DISTRO} =~ (oneiric|precise) ]]; then
...
exit 1
which I think is going too far.

Frankly, this devstack stuff is just a big hack. Nothing is really
structured with functions. It's not really possible to run the scripts
twice either (it's not idempotent, AFAIC).

Yes, one can read the devstack scripts and try to understand how it
works. But it's not easy to follow when you don't know what it's
supposed to be doing. And let's say one could read and type what it
does, while adapting it to an environment (Openstack + Kronos 

Re: [Openstack] [openstack] [keystone] Keystone XSDs?

[Anne Gentle]

Hi Liem,

The WADLs have been moved from the openstack/keystone repo to the
openstack/identity-api repo. Each OpenStack project that has an API has a
separate repo for the API wadls (and docs).

Anne

On Tue, Mar 20, 2012 at 10:59 AM, Nguyen, Liem Manh wrote:

>  Hello stackers,
>
> ** **
>
> I checked out the new Keystone (KSL), and the XSD’s and WADL’s are not
> there anymore…  Do they live somewhere else now?
>
> ** **
>
> Thanks,
>
> Liem
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Keystone auth_token confusion in Swift vs Glance; Persistent tokens or not ?

[Florian Daniel Otel]

Hello all,

I need some help with inconsistencies and -- in my mind -- confusing
instructions wrt "auth_token" Keytone middleware.

So far I have Keystone and Swift  w/ Keystone auth working well together
(ussing Essex-4 milestone release  of Keystone resp v1.4.6 of Swift).

What I am now  trying is to get  Glance on Swift with Keystone Auth  but
I'm faced with conflicting info that I cannot make sense of

1) Naming inconsistencies -- "token_auth" ,  "tokenauth" (Keystone resp
Swift) vs "authtoken"  (Glance)

The existing Keystone and Swift docs (e.g. this one:
http://keystone.openstack.org/configuringservices.html#configuring-swift-to-use-keystone
* ) *use as names "token_auth" (Keystone) resp  "tokenauth" (Swift)
wheareas in Glance docs the same midldleware (i.e.
"keystone/middleware/auh_token.py") is referred to as "authtoken"  (see
e.g.  here http://glance.openstack.org/authentication.html )

While this may be only pedantic IMHO it would help if things would be
called the same way in different places.  Or, if I'm confusing things,
someone point me out the differences to which is what and why.

2) "auth_token":  Persistent tokens or user/pass ?

As per Jay Pipes comment here:
https://bugs.launchpad.net/glance/+bug/953989/comments/2  (from
2012-03-13)  the concept of long-lived (i.e. persistent) tokens are no
longer supported by the Keystone "auth_token" middleware  -- and that is
listed as why that bug was invalid.

Now, that gets me _really_ confused: My working Keystone (again, as per
E4)  + Swift (as per v1.4.6) use persistent tokens just fine. E.g. my WSGI
pipleline for the swift proxy server looks like this:

[pipeline:main]
pipeline = catch_errors healthcheck cache tokenauth keystone proxy-server

..
with  the corresponding:

...
[filter:keystone]
paste.filter_factory = keystone.middleware.swift_auth:filter_factory
operator_roles = admin, SwiftOperator

[filter:tokenauth]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
service_protocol = http
service_port = 5000
service_host = 127.0.0.1
auth_port = 5001
auth_host = 127.0.0.1
admin_token = 999888777666
delay_auth_decision = 0
...

Now, the question is: Since we are now to stop using long-lived tokens
hardcoded as "admin_token" in "keystone.conf", resp in the "auth_token"
middleware sections of swift resp, glance, how is a user/pass config
supposed to look  like  ? examples ?

Sorry if this question is not as clearly laid out is it should be, reason
is this is all very confusing to me  (maybe time for me to get a rubber
ducky and explain it all ...)

Thanks in advance for the help,

Florian
___
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] Cleaning nova database

[David Kranz]

Thanks, Jay. I agree with your comments about Essex. The problem is that 
I have cleaned up after a number of operational problems in a cluster 
that has been up for 3 months. It is hard to reproduce these problems 
when the mean time to failure is so long, and real investigation can be 
dangerous when there are real users. One thing I have done in past 
projects is to have an email address where people are encouraged to 
report 'incidents' like this. Investigation and creation of a proper bug 
report can be dangerous and/or a lot of work but we could encourage 
operators of real systems to just email these problems even if they 
don't have time to investigate. That could help find problems that are 
appearing in the field but don't get picked up in unit tests and such. I 
will file a bug about the bad state.



 -David




On 3/20/2012 11:29 AM, Jay Pipes wrote:

Also, it seems that deleted instances are never removed from the

database. Is that a bug?


No, it's not a bug. But was is a bug is ACTIVE status instances that 
are deleted.


Another issue right now is that Essex has moved on and much of the 
code involved in this stuff is substantially different in trunk. We 
first need to identify whether this issue exists in trunk today, and 
if so, patch trunk and then backport a patch to Diablo...


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



___
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] [keystone] Keystone XSDs?

[Nguyen, Liem Manh]

Hello stackers,

I checked out the new Keystone (KSL), and the XSD's and WADL's are not there 
anymore...  Do they live somewhere else now?

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] Cleaning nova database

[David Kranz]

The users are using nova CLI, not euca. The 'deleted' field is already 
1. The delete fails because the id is a foreign key in the 
virtual_interfaces table. The question is how to excise an instance from 
the database without screwing anything up. Here is the whole row, which 
has a few unexpected values for a deleted instance, and the error. I am 
trying to determine if a bug should be filed. Of course I cannot 
reproduce this.


SQL query:

DELETE FROM `nova`.`instances` WHERE `instances`.`id` =155

MySQL said: Documentation
#1451 - Cannot delete or update a parent row: a foreign key constraint 
fails (`nova`.`virtual_interfaces`, CONSTRAINT 
`virtual_interfaces_ibfk_1` FOREIGN KEY (`instance_id`) REFERENCES 
`instances` (`id`))


  created_at: "2012-01-26 21:31:44"
  updated_at: "2012-02-27 22:35:24"
  deleted_at: "2012-02-27 22:35:35"
  deleted: 1
  id: 155
  user_id: "xx"
  project_id: "test"
  image_ref: 51
  kernel_id: 7
  ramdisk_id: ""
  launch_index: 0
  key_name: "li"
  key_data: "ssh-rsa 
B3NzaC1yc2EDAQABgQCywTW0xypa949d2U5RBjTU9ip9yGapOy/9HwcRL5fgQh0EApVB5eUT7Pg3NgtB1AAVnsvNBguCRNmRzHwu2/kGc8AYNJEwgVGvR8eArrRltV7JriYxtC7/LirHM5EjdJ5paYKGOQAleb5fpfjlYuHd4H8RkYqcBRcriNzmGlJNPQ== 
nova@xg03\n"

  power_state: 5
  vm_state: "active"
  memory_mb: 2048
  vcpus: 1
  local_gb: 20
  hostname: "testworker2"
  host: "xg01"
  user_data: ""
  reservation_id: "r-u29wsnpn"
  launched_at: "2012-02-23 16:08:37"
  display_name: "testworker2"
  display_description: "testworker2"
  locked: 0
  launched_on: "xg01"
  instance_type_id: 5
  uuid: "36741362-b755-4aff-a6c4-7b292acfda0b"
  root_device_name: "/dev/vda"
  config_drive: ""
  task_state: "rebooting"
  default_local_device: "/dev/vdb"


On 3/20/2012 11:27 AM, Leandro Reox wrote:
I think that the quick solution is set deteled to 1 on the offending 
instances


Are u using euca tools ? some inconsistencies are generated by them often

Regards
Lean

On Tue, Mar 20, 2012 at 12:19 PM, David Kranz > wrote:


In a diablo/kvm cluster that has been running for a long time, a
user reported problems with some vms, tried rebooting them and
eventually deleted them. I recently noticed messages in the nova
compute log like: Found 13 in the database and 10 on the hypervisor.

Looking at the source code I understand that this means the
instances have been deleted as far as the hypervisor is concerned,
but nova still thinks they are there.
I found the offending instances in the database and they were
still listed as in the active state even though they
had a deletion date recorded. I tried to delete them but was
unable due to a foreign key error with virtual_interfaces. I could
play around with deleting various things from the database but
there are real users. Is their a documented way to "clean up" the
state of the nova database in such situations? It seems like a bug
that the database could get into this state.

Also, it seems that deleted instances are never removed from the
database. Is that a bug?

 -David

___
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] Essex keystone with remote glance endpoint

[Jason Hedden]

On Mar 19, 2012, at 12:13 PM, Jason Hedden wrote:
> Glance host (192.168.131.142):
> glance # lsb_release -d; uname -a; dpkg -l | egrep "glance|keystone"
> Description:  Ubuntu precise (development branch)
> Linux ubuntu 3.2.0-17-generic #27-Ubuntu SMP Fri Feb 24 15:37:36 UTC 2012 
> x86_64 x86_64 x86_64 GNU/Linux
> ii  glance   2012.1~rc1~20120316.1354-0ubuntu1 
> OpenStack Image Registry and Delivery Service - Daemons
> ii  glance-api   2012.1~rc1~20120316.1354-0ubuntu1 
> OpenStack Image Registry and Delivery Service - API
> ii  glance-client2012.1~rc1~20120316.1354-0ubuntu1 
> OpenStack Image Registry and Delivery Service - Registry
> ii  glance-common2012.1~rc1~20120316.1354-0ubuntu1 
> OpenStack Image Registry and Delivery Service - Common
> ii  glance-registry  2012.1~rc1~20120316.1354-0ubuntu1 
> OpenStack Image Registry and Delivery Service - Registry
> ii  python-glance2012.1~rc1~20120316.1354-0ubuntu1 
> OpenStack Image Registry and Delivery Service - Python library
> ii  python-keystone  2012.1~rc1~20120316.2145-0ubuntu1 
> OpenStack identity service - Python library
> ii  python-keystoneclient2012.1~rc1~20120310.0-0ubuntu1Client 
> libary for Openstack Keystone API

I was able to solve the problem by using the OpenStack PPA's instead of the 
packages in the precise repo.  I'm not sure what exactly fixed it, but here's 
what packages are working for me.

# dpkg -l | egrep "glance|keystone"
ii  glance   
2012.1~rc1~20120320.1379-0ubuntu0~precise22 OpenStack Image Registry and 
Delivery Service - Daemons
ii  glance-api   
2012.1~rc1~20120320.1379-0ubuntu0~precise22 OpenStack Image Registry and 
Delivery Service - API
ii  glance-common
2012.1~rc1~20120320.1379-0ubuntu0~precise22 OpenStack Image Registry and 
Delivery Service - Common
ii  glance-registry  
2012.1~rc1~20120320.1379-0ubuntu0~precise22 OpenStack Image Registry and 
Delivery Service - Registry
ii  python-glance
2012.1~rc1~20120320.1379-0ubuntu0~precise22 OpenStack Image Registry and 
Delivery Service - Python library
ii  python-keystone  2012.1~rc1~20120316.2145-0ubuntu1  
 OpenStack identity service - Python library
ii  python-keystoneclient2012.1~rc1~20120316.86-0ubuntu0~precise1   
 Client libary for Openstack Keystone API

via https://launchpad.net/~openstack-ppa/+archive/bleeding-edge

Thanks for all the help, and suggestions

- Jason
___
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] Cleaning nova database

[Jay Pipes]

On 03/20/2012 11:19 AM, David Kranz wrote:

In a diablo/kvm cluster that has been running for a long time, a user
reported problems with some vms, tried rebooting them and eventually
deleted them. I recently noticed messages in the nova compute log like:
Found 13 in the database and 10 on the hypervisor.

Looking at the source code I understand that this means the instances
have been deleted as far as the hypervisor is concerned, but nova still
thinks they are there.


Correct.


I found the offending instances in the database and they were still
listed as in the active state even though they
had a deletion date recorded. I tried to delete them but was unable due
to a foreign key error with virtual_interfaces. I could play around with
deleting various things from the database but there are real users. Is
their a documented way to "clean up" the state of the nova database in
such situations? It seems like a bug that the database could get into
this state.


I also ran into this issue on Diablo/KVM...


Also, it seems that deleted instances are never removed from the
database. Is that a bug?


No, it's not a bug. But was is a bug is ACTIVE status instances that are 
deleted.


Another issue right now is that Essex has moved on and much of the code 
involved in this stuff is substantially different in trunk. We first 
need to identify whether this issue exists in trunk today, and if so, 
patch trunk and then backport a patch to Diablo...


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] Cleaning nova database

[Leandro Reox]

I think that the quick solution is set deteled to 1 on the offending
instances

Are u using euca tools ? some inconsistencies are generated by them often

Regards
Lean

On Tue, Mar 20, 2012 at 12:19 PM, David Kranz wrote:

> In a diablo/kvm cluster that has been running for a long time, a user
> reported problems with some vms, tried rebooting them and eventually
> deleted them. I recently noticed messages in the nova compute log like:
> Found 13 in the database and 10 on the hypervisor.
>
> Looking at the source code I understand that this means the instances have
> been deleted as far as the hypervisor is concerned, but nova still thinks
> they are there.
> I found the offending instances in the database and they were still listed
> as in the active state even though they
> had a deletion date recorded. I tried to delete them but was unable due to
> a foreign key error with virtual_interfaces. I could play around with
> deleting various things from the database but there are real users. Is
> their a documented way to "clean up" the state of the nova database in such
> situations? It seems like a bug that the database could get into this state.
>
> Also, it seems that deleted instances are never removed from the database.
> Is that a bug?
>
>  -David
>
> __**_
> 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] Cleaning nova database

[David Kranz]

In a diablo/kvm cluster that has been running for a long time, a user 
reported problems with some vms, tried rebooting them and eventually 
deleted them. I recently noticed messages in the nova compute log like: 
Found 13 in the database and 10 on the hypervisor.


Looking at the source code I understand that this means the instances 
have been deleted as far as the hypervisor is concerned, but nova still 
thinks they are there.
I found the offending instances in the database and they were still 
listed as in the active state even though they
had a deletion date recorded. I tried to delete them but was unable due 
to a foreign key error with virtual_interfaces. I could play around with 
deleting various things from the database but there are real users. Is 
their a documented way to "clean up" the state of the nova database in 
such situations? It seems like a bug that the database could get into 
this state.


Also, it seems that deleted instances are never removed from the 
database. Is that a bug?


 -David

___
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 zone" and "availability_zone"

[Anne Gentle]

I believe we have doc tools now that would enable a shared glossary for all
documents. Let me investigate and report back to the list.

Anne

On Tue, Mar 20, 2012 at 6:21 AM, Tim Bell  wrote:

> ** **
>
> It would be useful if there was a glossary of terms related to Openstack.
> It is easy to get confused as many words are overloaded or slightly
> different between different parts of Openstack.
>
> ** **
>
> There is also the page on identity at
> http://docs.openstack.org/diablo/openstack-identity/admin/content/Identity-Service-Concepts-e1362.htmlwhich
>  defines some concepts.
> 
>
> ** **
>
> From http://wiki.openstack.org/Glossary, there is a pointer to
> http://cloudglossary.com/ but the openstack terms are not in there.
>
> ** **
>
> There is also
> http://docs.openstack.org/incubation/openstack-network/developer/quantum-api-1.0/content/Glossary.htmlfor
>  networking.
> 
>
> ** **
>
> Tim
>
> ** **
>
> *From:* openstack-bounces+tim.bell=cern...@lists.launchpad.net [mailto:
> openstack-bounces+tim.bell=cern...@lists.launchpad.net] *On Behalf Of *Sandy
> Walsh
> *Sent:* 20 March 2012 12:07
> *To:* Nicolae Paladi; openstack@lists.launchpad.net
> *Subject:* Re: [Openstack] "nova zone" and "availability_zone"
>
> ** **
>
> Availability Zone is an EC2 concept. Zones were a sharding scheme for
> Nova. Zones are being renamed to Cells to avoid further confusion.
> Availability Zones will remain the same. 
>
> ** **
>
> Hope it helps!
>
> -S
> --
>
> *From:* 
> openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net[openstack-bounces+sandy.walsh=
> rackspace@lists.launchpad.net] on behalf of Nicolae Paladi [
> n.pal...@gmail.com]
> *Sent:* Tuesday, March 20, 2012 6:55 AM
> *To:* openstack@lists.launchpad.net
> *Subject:* [Openstack] "nova zone" and "availability_zone"
>
> Hi all,  
>
> ** **
>
> What is the difference between "nova zone(s)" and "availability_zone"?
>
> In a new deployment, the *services* table in the nova db contains an
> "availability_zone"
>
> column (which is 'nova', but default). 
>
> ** **
>
> If that is not the same as "nova zones"  (which are logical deployments,
> as far as I understood), where is information
>
> about zones stored?
>
> ** **
>
> The only documentation about "zones" in openstack that I could find is
> here:
>
> http://nova.openstack.org/devref/zone.html
>
> ** **
>
> ** **
>
> is there anything on availability zones?
>
> ** **
>
> Cheers, 
>
> /Nicolae.
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ___
> 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] Essex keystone with remote glance endpoint

[stuart . mclaren]

Hi Jason,

Using 'ngrep' may be helpful here to help see what's going on.

# ngrep -W byline -d ethX port 5000 or 35357

where 'ethX' is the relevant ethernet interface, eg 'eth0' or 'lo'.

This should generate output along the following lines so we
can see the glance <-> keystone API exchanges:

T 127.0.0.1:5000 -> 127.0.0.1:36198 [AP]
HTTP/1.1 200 OK.
Content-Type: application/json; charset=UTF-8.
Content-Length: 324.
Date: Tue, 22 Nov 2011 16:56:32 GMT.
.
{
"access": {
"serviceCatalog": [
{
.
.
.

It might be interesting to see ngrep output for the following commands:

glance -T service -I glance -K glance -S keystone -N 
http://192.168.131.141:5000/v2.0 index
glance -I glance -K glance -S keystone -N http://192.168.131.141:5000/v2.0 index

and maybe compare this port too:

glance -I glance -K glance -S keystone -N http://192.168.131.141:35357/v2.0 
index
glance -T service -I glance -K glance -S keystone -N 
http://192.168.131.141:35357/v2.0 index

Thanks,

-Stuart


On Mon, 19 Mar 2012, Jason Hedden wrote:



On Mar 19, 2012, at 12:58 PM, Jay Pipes wrote:


On 03/19/2012 01:13 PM, Jason Hedden wrote:

When following the documentation at https://review.openstack.org/#change,5190 
I'm having trouble getting Glance to authenticate via Keystone.  I have this 
working when everything is installed on a single system, but can't seem to find 
any winning combinations to get a multi-host installation working.

# glance  -I adminUser -K ... -S keystone -N http://192.168.131.141:5000/v2.0' 
index
Failed to show index. Got error:
Response from Keystone does not contain a Glance endpoint.


Try specifying the tenant name with -T .


With both the admin, and glance user I get:
glance # glance -T service -I glance -K glance -S keystone -N 
http://192.168.131.141:5000/v2.0 index
Not authorized to make this request. Check your credentials (OS_AUTH_USER, 
OS_AUTH_KEY, …).

glance # glance -T openstackDemo -I adminUser -K ... -S keystone -N 
http://192.168.131.141:5000/v2.0 index
Not authorized to make this request. Check your credentials (OS_AUTH_USER, 
OS_AUTH_KEY, …).

Just to verify that I'm speaking with keystone at all:
Without the -T:
glance # glance -I adminUser -K ... -S keystone -N 
http://192.168.131.141:5000/v2.0 index
Failed to show index. Got error:
Response from Keystone does not contain a Glance endpoint.

With a bad password and no -T:
Failed to show index. Got error:
Response from Keystone does not contain a Glance endpoint.
glance # glance -I adminUser -K blah -S keystone -N 
http://192.168.131.141:5000/v2.0 index
Not authorized to make this request. Check your credentials (OS_AUTH_USER, 
OS_AUTH_KEY, ...).
___
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] Scalability issue in nova-dhcpbridge

[Anton Blanchard]

Hi Vish,

> I believe it is safe to ignore the old leases.  If nova-network has
> been down for a while it could potentially be nice to refresh all of
> the leases that it knows about, but I don't think it will harm
> anything if you remove it.
> 
> Are you running flatdhcp with a single network host on a large
> install?  I would think that multi_host would be a better choice in
> that case.
> 
> There is also a potentially nasty performance issue in linux_net
> where it creates all of the leases.  It is a very expensive operation
> and needs to be reoptimized after the foreign keys were removed from
> the network tables. Currently it is doing 2 database for every active
> instance in the db.

Thanks for making these changes so quickly. Initial testing shows a
huge improvement. If I push things harder we do slow down somewhat
because each call of nova-dhcpbridge takes time just in the import code:


# cat slow
#!/usr/bin/python

from nova.network import linux_net


# time ./slow 
0.295s


So 500 "old" leases will take 150 seconds to process even though we
are just dropping them. dnsmasq has a dbus interface which I was going
to look at, but for now I just wrapped nova-dhcpbridge with a stupid
shell script:


#!/bin/sh

if [ "$1" == "old" ]; then
exit
fi
exec /opt/stack/nova/bin/nova-dhcpbridge.orig $@


Also "nova list" with 1000 instances is a bit slow (13 seconds on my
setup). It drops to 6.5 seconds if we avoid doing all the queries to
get the hypervisor hostname:


 def _get_hypervisor_hostname(self, context, instance):
+return "junk"
 compute_node = db.compute_node_get_by_host(context,


I wonder if there is a way we can do this via a join.

Anton

___
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] using xenapi hypervisor

[John Garbutt]

Hi,

As Todd said, I am concentrating on getting the developer docs straight first. 
Hence the current fixation on DevStack as a sort of "deployment documentation".

The current idea (feel free to say this will not work for you) is that people 
can try out OpenStack with DevStack, kick the tyres. They can then use that as 
a reference to build another deployment using the tools of their own choosing, 
copying flag files, etc, as required.

Feel free to raise some documentation bugs/requests for areas that you think 
are the most confusing, and we will do our best to look at those first.

Cheers,
John

-Original Message-
From: openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net 
[mailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net] On 
Behalf Of Todd Deshane
Sent: 19 March 2012 10:32
To: Eduardo Nunes
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] [OpenStack] using xenapi hypervisor

On Mon, Mar 19, 2012 at 2:19 PM, Eduardo Nunes  wrote:
> I wanna use the xenpi as a hypervisor, i see there are many tutorials, 
> but almost all of then is using the devstack, i don't wanna use the 
> devstack, is there a tutorial about how i create a domU, what image i 
> sould use on the domU, an the conf of xen?

Some more general documentation has been started here:
https://review.openstack.org/#change,5419

The devstack scripts are written in bash and include example configurations 
within them so that you can make your own custom setups and scripts based on 
them.

There are also chef recipes for working with XenServer here:
https://github.com/openstack/openstack-chef/tree/master/cookbooks/xenserver

If you look carefully at the individual devstack scripts there are techniques 
to build stage files, build XVA files, etc.

The documentation linked from http://wiki.openstack.org/XenServer is still work 
in progress, but is written by the actual developers that are making all of 
this work. The latest devstack scripts are being used and tested by these 
developers as well.

The compute manual, devstack, chef scripts, etc. will evolve over time to 
include more details and even more information, but as things are built up, you 
should just ask if you don't understand something so that we can explain and 
then include more in the documentation.

Hope that helps.

Thanks,
Todd

--
Todd Deshane
http://www.linkedin.com/in/deshantm
http://blog.xen.org/
http://wiki.xen.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

___
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 zone" and "availability_zone"

[Tim Bell]

 

It would be useful if there was a glossary of terms related to Openstack. It
is easy to get confused as many words are overloaded or slightly different
between different parts of Openstack.

 

There is also the page on identity at

http://docs.openstack.org/diablo/openstack-identity/admin/content/Identity-S
ervice-Concepts-e1362.html which defines some concepts.

 

>From  
http://wiki.openstack.org/Glossary, there is a pointer to
 http://cloudglossary.com/ but the openstack
terms are not in there.

 

There is also

http://docs.openstack.org/incubation/openstack-network/developer/quantum-api
-1.0/content/Glossary.html for networking.

 

Tim

 

From: openstack-bounces+tim.bell=cern...@lists.launchpad.net
[mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf Of
Sandy Walsh
Sent: 20 March 2012 12:07
To: Nicolae Paladi; openstack@lists.launchpad.net
Subject: Re: [Openstack] "nova zone" and "availability_zone"

 

Availability Zone is an EC2 concept. Zones were a sharding scheme for Nova.
Zones are being renamed to Cells to avoid further confusion. Availability
Zones will remain the same. 

 

Hope it helps!

-S

  _  

From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf
of Nicolae Paladi [n.pal...@gmail.com]
Sent: Tuesday, March 20, 2012 6:55 AM
To: openstack@lists.launchpad.net
Subject: [Openstack] "nova zone" and "availability_zone"

Hi all,  

 

What is the difference between "nova zone(s)" and "availability_zone"?

In a new deployment, the *services* table in the nova db contains an
"availability_zone"

column (which is 'nova', but default). 

 

If that is not the same as "nova zones"  (which are logical deployments, as
far as I understood), where is information

about zones stored?

 

The only documentation about "zones" in openstack that I could find is here:

http://nova.openstack.org/devref/zone.html

 

 

is there anything on availability zones?

 

Cheers, 

/Nicolae.

 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Nova 2012.1 RC1 available

[Thierry Carrez]

Hello everyone,

Tarballs for the first release candidate for Nova 2012.1 (codenamed
"Essex") and accompanying python-novaclient are now available at:

https://launchpad.net/nova/essex/essex-rc1

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the 2012.1 final
version. You are therefore strongly encouraged to test and validate it.

You should test the tarballs above, but you also can directly use the
milestone-proposed branch at:

https://github.com/openstack/nova/tree/milestone-proposed

Packages for various distributions should follow shortly.

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/nova/+filebug

and tag it "essex-rc-potential" to bring it to Vish's attention.

Note that the "master" branch of Nova is now open for Folsom
development, feature freeze restrictions no longer apply.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

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

Re: [Openstack] Keystone auth issues with Swift

[Chmouel Boudjnah]

Hi Juerg,

On Tue, Mar 20, 2012 at 10:56 AM, Haefliger, Juerg
 wrote:
> Did you start on it already? I made the modifications that you suggested this 
> morning and it seems to work now. I can successfully add and delete images 
> through Glance now. Let me know if you want me to create a patch/review. If 
> so, do I need to file a bug first or is it covered under an existing one?

I haven't start on it as Jay was telling me you were working on this,
feel free to work against this bug
https://bugs.launchpad.net/glance/+bug/944946

(Please don't forget to add the unittest for it).

Thanks,
Chmouel.

___
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] Reminder: OpenStack Project meeting - 21:00 UTC

[Thierry Carrez]

Hello everyone,

Our weekly project & release status meeting will take place at 21:00
UTC this Tuesday in #openstack-meeting on IRC. PTLs, if you can't make
it, please name a substitute on [2].

We will focus on projects that have not published an RC1 yet, in
particular Keystone, to make sure we can reach that critical milestone
soon enough.

Please doublecheck what 21:00 UTC means for your timezone at [1]:
[1] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20120320T21

See the meeting agenda, edit the wiki to add new topics for discussion:
[2] http://wiki.openstack.org/Meetings/ProjectMeeting

Cheers,

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

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

Re: [Openstack] "nova zone" and "availability_zone"

[Sandy Walsh]

Availability Zone is an EC2 concept. Zones were a sharding scheme for Nova. 
Zones are being renamed to Cells to avoid further confusion. Availability Zones 
will remain the same.

Hope it helps!
-S


From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net 
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of 
Nicolae Paladi [n.pal...@gmail.com]
Sent: Tuesday, March 20, 2012 6:55 AM
To: openstack@lists.launchpad.net
Subject: [Openstack] "nova zone" and "availability_zone"

Hi all,

What is the difference between "nova zone(s)" and "availability_zone"?
In a new deployment, the *services* table in the nova db contains an 
"availability_zone"
column (which is 'nova', but default).

If that is not the same as "nova zones"  (which are logical deployments, as far 
as I understood), where is information
about zones stored?

The only documentation about "zones" in openstack that I could find is here:
http://nova.openstack.org/devref/zone.html


is there anything on availability zones?

Cheers,
/Nicolae.




___
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 auth issues with Swift

[Haefliger, Juerg]

Hi Chmouel,

> Hello,
> 
> I was actually going to start working on that today as we have review
> 4893 merged as of last night, basically when you connect with glance to
> swift :
> 
> https://github.com/openstack/glance/blob/master/glance/store/swift.py#L
> 306
> 
> You need to have an option in glance to connect to a auth 2.0 server
> like :
> 
> swift_auth_version = 2
> 
> and pass auth_version=2 to swift_client.Connection :
> 
> https://github.com/openstack/swift/blob/master/swift/common/client.py#L
> 796
> 
> Which should be able to get the images for that username/key stored in
> keystone.
> 
> If you would like to have a go on it please feel free as I don't know
> very glance code-base (but there is always a start :))

Did you start on it already? I made the modifications that you suggested this 
morning and it seems to work now. I can successfully add and delete images 
through Glance now. Let me know if you want me to create a patch/review. If so, 
do I need to file a bug first or is it covered under an existing one?

Thanks a lot for your help
...Juerg


 
> Chmouel.
> 
> PS: Ccing the public mailing-list as I think it would be more useful to
> have those discussions in public.
> 
> 
> From: Haefliger, Juerg [juerg.haefli...@hp.com]
> Sent: 16 March 2012 12:11
> To: Pipes, Jay; Chmouel Boudjnah
> Subject: RE: Re: Fwd: RE: Keystone auth issues with Swift
> 
> Hi guys,
> 
> Thanks for the info.  I still have some questions though.
> 
> I applied https://review.openstack.org/#change,4893 to my local branch.
> When you say 'Glance doesn't speak 2.0' which part of Glance are you
> referring to? The CLI or some other component? Where do I have to make
> modifications to get this working? Glance only or some middleware in
> keystone as well?
> 
> Thanks
> ...Juerg
> 
> 
> > -Original Message-
> > From: Pipes, Jay
> > Sent: Thursday, March 15, 2012 8:54 PM
> > To: Haefliger, Juerg
> > Subject: Fwd: Re: Fwd: RE: Keystone auth issues with Swift
> >
> > Hey again!
> >
> > See below an explanation from Chmouel as to what may be happening...
> >
> > All the best,
> > jay
> >
> >  Original Message 
> > Subject:  Re: Fwd: RE: Keystone auth issues with Swift
> > Date: Tue, 13 Mar 2012 14:09:32 -
> > From: Chmouel Boudjnah 
> > To:   Pipes, Jay 
> >
> >
> >
> > Hello Jay,
> >
> > This is because Glance doesn't 'speak' Auth 2.0 when using
> > swift.client, see this bug :
> >
> > https://bugs.launchpad.net/glance/+bug/944946
> >
> > Would love to make this works but this review has been sitting :
> >
> > https://review.openstack.org/#change,4893
> >
> > The way it should work, should be[1]  :
> >
> > Glance => swift.client (2.0 ''mode'') => Keystone (get us a token) =>
> > Swift => SwiftAuth => Validate token => Access
> >
> > There is probably going to have some caching around this to avoid
> some
> > round trip.
> >
> > Cheers,
> > Chmouel.
> >
> > [1] It may look confusing let me know if you want some kind of
> diagram.
> >
> > On 03/13/2012 01:58 PM, Pipes, Jay wrote:
> > > Hi Chmouel, hoping you might be able to help me out. I've got an
> > > HPer who is trying to get Diablo Glance + Swift working properly
> > > with
> > Keystone.
> > >
> > > Basically, it looks like the Glance auth_token middleware is
> > correctly
> > > handling Keystone authentication and using the swift CLI tool works
> > > fine with Keystone auth.
> > >
> > > However, adding an image through the glance client using a Swift
> > > backend is failing (see below in original email).
> > >
> > > I'm wondering if there's something obvious that I'm missing? AFAIK,
> > > the Glance Swift backend driver simply calls the swift client,
> > passing
> > > in the user/key that is stored in the Glance config
> > > store_swift_auth_user/key values. The token *should* be created by
> > the
> > > swift_auth middleware when it sees an HTTP request with X-Auth-User
> > > and X-Auth-Key headers (that the Glance Swift backend driver
> > supplies), right?
> > >
> > > Thanks in advance for any insight you might have!
> > > -jay
> > >
> > >  Original Message 
> > > Subject: RE: Keystone auth issues with Swift
> > > Date: Tue, 13 Mar 2012 09:09:37 -
> > > From: Haefliger, Juerg > > >
> > > To: Pipes, Jaymailto:jay.pi...@hp.com>>
> > >
> > > Hi Jay,
> > >
> > > Thanks for the suggestion but it didn't help :-(
> > >
> > > Doing some tracing, I can see the following sequence (which is
> > > identical with or without the -A option) when trying to add an
> image
> > > through
> > > glance:
> > >
> > > glance-api: auth_token: env contains'HTTP_X_AUTH_TOKEN'
> > > glance-api: glance_auth_token: req.headers contains'X-Auth-Token'
> > > glance-registry: auth_token: env contains'HTTP_X_AUTH_TOKEN'
> > > glance-registry: glance_auth_token: req.headers contains'X-Auth-
> > Token'
> > > swift-proxy-server: swift_auth: env does not
> > conta

[Openstack] "nova zone" and "availability_zone"

[Nicolae Paladi]

Hi all,

What is the difference between "nova zone(s)" and "availability_zone"?
In a new deployment, the *services* table in the nova db contains an
"availability_zone"
column (which is 'nova', but default).

If that is not the same as "nova zones"  (which are logical deployments, as
far as I understood), where is information
about zones stored?

The only documentation about "zones" in openstack that I could find is here:
http://nova.openstack.org/devref/zone.html


is there anything on availability zones?

Cheers,
/Nicolae.
___
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's Swift Integration

[Chmouel Boudjnah]

Hi Maru,

Sorry I have been taking long to come to you on this, I have revived
review  4529[1] which add the swift tests. I was talking to termie
about it sometime ago and the way we decided to do is to skip the
tests if Swift is not installed[2]. Feel free to add stubs as this is
not ideal.

I was working as well on container-sync and anonymous requests but was
not sure if this should go in for Folsom or for this release.

Cheers,
Chmouel.

[1] https://review.openstack.org/#change,4529
[2] Ideally I would love to have swift.common.*/swiftclient go to
another package but that's probably a discussion for Folsom summit.

On Tue, Mar 20, 2012 at 3:33 AM, Maru Newby  wrote:
> I'd like to write unit tests for keystone.middleware.swift_auth in advance of 
> some functional changes (adding support for unauthenticated container sync 
> and referrer access).  It appears that swift_auth lacks unit tests, though.  
> Is this due to its dependency on swift, or is there another reason?
>
> Given that untested code is difficult to maintain, what would the best option 
> be to add tests for swift_auth?  Ideally the module would just move to the 
> swift repo, but if for some reason that's not an option, I'm prepared to use 
> stubs.
>
> Thanks,
>
>
> Maru
>
> ___
> 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