Re: [Openstack] [Metering] Meeting agenda for Thursday at 16:00 UTC (May 17th, 2012)

[Nick Barcet]

On 05/16/2012 08:44 PM, Nick Barcet wrote:
> Hi,
> 
> The metering project team holds a weekly meeting in #openstack-meeting,
> Thursdays at 1600 UTC
> .
> Everyone is welcome.
> 
> Since we were not able to conclude on the API discussion last week we
> continued our dicussions on the list and on the #openstack-metering
> channel and are now coming with a better proposal (or we are at least
> hoping it is better).
> 
> http://wiki.openstack.org/Meetings/MeteringAgenda
> Topic: external API definition (part 2)
> 
>   * Agree on update to schema to include JSON formated metadata as
> described at [1]
>   * Agree on API proposal described at [2]
>   * Agree on format for date_time.  Suggestion is to use ISO but seeking
> validation for best practice for REST
>   * Agree on the use of a transparent cache for aggregation
>   * Open discussion (if we have any time left)
> 
> [1] http://wiki.openstack.org/EfficientMetering#Storage
> [2] http://wiki.openstack.org/EfficientMetering/APIProposalv1

The meeting took place yesterday, a summary follows.

=
#openstack-meeting Meeting
==

Meeting started by nijaba at 16:01:26 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-17-16.01.log.html

Meeting summary
---

* agenda http://wiki.openstack.org/Meetings/MeteringAgenda  (nijaba,
  16:01:26)

* actions from previous meetings  (nijaba, 16:02:14)
  * dachary add info to the wiki on the topic of poll versus push
(nijaba, 16:02:26)
  * dhellmann: reformulate the API proposal as a start point for the
dicussion on the ML  (nijaba, 16:03:25)

* Agree on update to schema to include JSON formated metadata  (nijaba,
  16:05:55)
  * LINK: http://wiki.openstack.org/EfficientMetering#Storage  (nijaba,
16:05:55)
  * AGREED: to update to schema to include JSON formated metadata
(nijaba, 16:10:40)

* Agree on API proposal  (nijaba, 16:10:56)
  * LINK: http://wiki.openstack.org/EfficientMetering/APIProposalv1
(nijaba, 16:10:56)
  * AGREED: on API proposal
http://wiki.openstack.org/EfficientMetering/APIProposalv1  (nijaba,
16:15:01)
  * ACTION: flacoste to follow on the discussion about a bus only
implementation  (nijaba, 16:17:43)

* Agree on format for date_time  (nijaba, 16:15:22)
  * Suggestion is to use ISO but seeking validation for best practice
for REST  (nijaba, 16:15:22)
  * ACTION: nijaba to add the use to UTC for datetime  (nijaba,
16:17:03)
  * AGREED: to use ISO for datetime  (nijaba, 16:18:54)

* Agree on the use of a transparent cache for aggregation  (nijaba,
  16:19:11)
  * AGREED: caching is an implementation detail  (nijaba, 16:23:58)

* Open discussion  (nijaba, 16:24:28)
  * ACTION: dhellmann to document a counter for discrete event as an
example  (nijaba, 16:29:02)

Meeting ended at 16:31:15 UTC.

Action items, by person
---

* dhellmann
  * dhellmann to document a counter for discrete event as an example
* flacoste
  * flacoste to follow on the discussion about a bus only implementation
* nijaba
  * nijaba to add the use to UTC for datetime

Next week's meeting will cover the choice of a messaging queue for the
project.

Cheers,
--
Nick Barcet 
aka: nijaba, nicolas



signature.asc
Description: OpenPGP digital 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] [metering] Choice of a messaging queue

[Nick Barcet]

Hello everyone,

Next week's irc meeting will have for goal to choose a reference
messaging queue service for the ceilometer project.  For this meeting to
be able to be successful, a discussion on the choices that we have to
make need to occur first right here.

To open the discussion here are a few requirements that I would consider
important for the queue to support:

a) the queue must guaranty the delivery of messages.
To the contrary of monitoring, loss of events may have important billing
impacts, it therefore cannot be an option that message be lost.

b) the client should be able to store and forward.
As the load of system or traffic increases, or if the client is
temporarily disconnected, client element of the queue should be able to
hold messages in a local queue to be emitted as soon as condition permit.

c) client must authenticate
Only client which hold a shared private key should be able to send
messages on the queue.

d) queue may support client signing of individual messages
Each message should be individually signed by the agent that emits it in
order to guaranty non repudiability.  This function can be done by the
queue client or by the agent prior to en-queuing of messages.

d) queue must be highly available
the queue servers must be able to support multiple instances running in
parallel in order to support continuation of operations with the loss of
one server.  This should be achievable without the need to use complex
fail over systems and shared storage.

e) queue should be horizontally scalable
The scalability of queue servers should be achievable by increasing the
number of servers.

Not sure this list is exhaustive or viable, feel free to comment on it,
but the real question is: which queue should we be using here?

Cheers,
--
Nick Barcet 
aka: nijaba, nicolas




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [metering] example of discrete counter

[Nick Barcet]

On 05/17/2012 10:48 PM, Doug Hellmann wrote:
> I have added a row to the list of counters for discrete events such as
> uploading an image to glance [1]. Please let me know if you think I need
> more exposition to explain discrete counters.
> 
> Doug
> 
> [1] http://wiki.openstack.org/EfficientMetering?action=diff&rev2=89&rev1=87
> 

Thanks Doug, it looks good to me.

Cheers,
Nick




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [metering] Do we need an API and storage?

[Thierry Carrez]

Doug Hellmann wrote:
> On Thu, May 17, 2012 at 5:47 AM, Nick Barcet  > wrote:
> 
> On 05/17/2012 11:13 AM, Loic Dachary wrote:
> > On 05/16/2012 11:00 PM, Francis J. Lacoste wrote:
> >>
> >> I'm now of the opinion that we exclude storage and API from the
> >> metering project scope. Let's just focus on defining a metering
> >> message format, bus, and maybe a client-library to make it easy to
> >> write metering consumers.
> 
> 
> The plan, as I understand it, is to ensure that all metering messages
> appear on a common bus using a documented format. Deployers who do not
> want the storage system and REST API will not need to use it, and can
> set up their own clients to listen on that bus. I'm not sure how much of
> a client library is needed, since the bus is AMQP and the messages are
> JSON, both of which have standard libraries in most common languages.
> [...]

You can certainly architect it in a way so that storage and API are
optional: expose metering messages on the bus, and provide an
optionally-run aggregation component that exposes a REST API (and that
would use the metering-consumer client library). That would give
deployers the option to poll via REST or implement their own alternate
aggregation using the metering-consumer client lib, depending on the
system they need to integrate with.

Having the aggregation component clearly separate and optional will
serve as a great example of how it could be done (and what are the
responsibilities of the aggregation component). I would still do a
(minimal) client library to facilitate integration, but maybe that's
just me :)

-- 
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] Blueprint and core cleanup

[Thierry Carrez]

Vishvananda Ishaya wrote:
> *Core Cleanup*
> [...]
> If a former core member has time to start participating in reviews
> again, i think he should be able to review for a couple of weeks or two
> and send an email to the list saying, "Hey, I've got time to review
> again, can I be added back in".  If we don't here any -1 votes by other
> core members for three days we will bring them back.  In other words,
> its former members can be accelerated back into core.  Sound reasonable?

Yes.

> *Blueprint Cleanup*
> 
> As I mentioned in my previous email, I've now obsoleted all blueprints
> not targetted to folsom. The blueprint system has been used for "feature
> requests", and I don't think it is working because there is no one
> grabbing unassigned blueprints. I think it has to be up to the drafter
> of the blueprint to find a person/team to actually implement the
> blueprint or it will just sit there. Therefore I've removed all of the
> "good idea" blueprints. This was kind of sad, because there were some
> really good ideas there.

We discussed for quite some time that "wishlist" bugs that don't get
worked on for some time should be closed as "Opinion/Wishlist"... and
use that search to get a nice list of "things that sound like a good
idea but nobody has had time to work on". Maybe we should create
wishlist bugs for stuff on obsoleted blueprints, so that we have a
single place to look for abandoned good ideas ?

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

[Openstack] Multiple NOVA-INST-DIR/instances

[Sergio Ariel de la Campa Saiz]

Hi:

Some days ago, I post a question about nova, but I did it in a wrong way. 
Thanks Igor, I hit me and now I rewrite the doubt:

Is it possible to configurate more than one --instances_path in nova.conf in 
order to get more than one NOVA-INST-DIR/instances???
I have multiple two NFS server and more than one compute node. I need that each 
node could launch its instances in any NFS server, in such a way that  some 
instances will be launched in the  NFS-server-1 and other instances in the 
NFS-server-2, but at the same time to be possible to migrate instances between 
nodes.
Is it possible???

Thanks a lot.

Sergio Ariel
de la Campa Saiz
GMV-SES Infraestructura /
GMV-SES Infrastructure





GMV
Isaac Newton, 11
P.T.M. Tres Cantos
E-28760 Madrid
Tel.
+34 91 807 21 00
Fax
+34 91 807 21 99
 www.gmv.com









De: Igor Laskovy [igor.lask...@gmail.com]
Enviado el: miércoles, 16 de mayo de 2012 20:05
Para: Sergio Ariel de la Campa Saiz
CC: Emilien Macchi; openstack-operat...@lists.openstack.org; 

Asunto: Re: [Openstack-operators] nova and multiple storages

ccing openstack@lists.launchpad.net

On Wed, May 16, 2012 at 10:19 AM, Sergio Ariel de la Campa Saiz 
mailto:saca...@gmv.com>> wrote:
Sorry to everyone if I didn´t tell exactly what I need, but Igor is right... I 
need to configurate more than one NOVA-INST-DIR/instances/ by NFS.

Thanks to Igor :-) :-)
Thanks to Emilien too :-) :-)
Sergio Ariel
de la Campa Saiz
GMV-SES Infraestructura /
GMV-SES Infrastructure





GMV
Isaac Newton, 11
P.T.M. Tres Cantos
E-28760 Madrid
Tel.
+34 91 807 21 00
Fax
+34 91 807 21 99
 www.gmv.com













De: 
openstack-operators-boun...@lists.openstack.org
 
[openstack-operators-boun...@lists.openstack.org]
 En nombre de Igor Laskovy 
[igor.lask...@gmail.com]
Enviado el: lunes, 14 de mayo de 2012 16:30
Para: Emilien Macchi
CC: Sergio Ariel de la Campa Saiz; 
openstack-operat...@lists.openstack.org
Asunto: Re: [Openstack-operators] nova and multiple storages


I guess Sergio told about more than one NOVA-INST-DIR/instances/

On May 14, 2012 3:11 PM, "Emilien Macchi" 
mailto:emilien.mac...@stackops.com>> wrote:
Hi Sergio,


When you talk about more than one storage, do you mean about Multi-Pathing ?

You can use multi storage node for VMs, and you can use Nexenta Software which 
has a specific drvier for Openstack modules. In this case, you use iSCSI as a 
SAN, and High available storage with a lot of nice features.

You can read more about how to use it 
here
.


Good luck !



On Mon, May 14, 2012 at 1:46 PM, Sergio Ariel de la Campa Saiz 
mailto:saca...@gmv.com>> wrote:
Hi:

I was wondering if it possible to configure each nova node to use more than one 
storage, I mean, if each node can storage its instances in more than one nfs 
server.

How to configure this??

Thanks a lot...

Sergio Ariel
de la Campa Saiz
GMV-SES Infraestructura /
GMV-SES Infrastructure





GMV
Isaac Newton, 11
P.T.M. Tres Cantos
E-28760 Madrid
Tel.
+34 91 807 21 00
Fax
+34 91 807 21 99
www.gmv.com








This message including any attachments may contain confidential information, 
according to our Information Security Management System, and intended solely 
for a specific individual to whom they are addressed. Any unauthorised copy, 
disclosure or distribution of this message is strictly forbidden. If you have 
received this transmission in error, please notify the sender immediately and 
delete it.

Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener 
información clasificada por su emisor como confidencial en el marco de su 
Sistema de Gestión de Seguridad de la Información siendo para uso exclusivo del 
destinatario, quedando prohibida su divulgación copia o distribución a terceros 
sin la autorización expresa del remitente. Si Vd. ha recibido este mensaje 
erróneamente, se ruega lo notifique al remitente y proceda a su borrado. 
Gracias por su colaboración.

Esta mensagem, incluindo qualquer ficheiro anexo, pode conter informação 
confidencial, de acordo com nosso Sistema de Gestão de Segurança da Informação, 
sendo para uso exclusivo do destinatário e estando proibida a sua divulgação, 
cópia ou distribuição a terceiros sem autorização expressa do remetente da 
mesma. Se recebeu esta mensagem por engano, por favor avise de imediato o 
remetente e apague-a. Obrigado pela sua colaboração.


___
Openstack-operators mailing list
openstack-ope

Re: [Openstack] [Openstack-operators] Multiple NOVA-INST-DIR/instances

[Igor Laskovy]

Hi Sergio,

Maybe you can mount dedicated NFS share for each VM already inside
NOVA-INST-DIR/instances directory ? And than you can control where each VM
will resides.

Igor Laskovy
Kiev, Ukraine
On May 18, 2012 12:43 PM, "Sergio Ariel de la Campa Saiz" 
wrote:

>  Hi:
>
> Some days ago, I post a question about nova, but I did it in a wrong way
> . Thanks Igor, I hit me and now I rewrite the doubt:
>
> Is it possible to configurate more than one --instances_path in nova.confin 
> order
>  to get more than one NOVA-INST-DIR/instances???
>  I have multiple two NFS server and more than one compute node. I need
>  that each node could launch its instances in any NFS server, in sucha way
>  that  some instances will be launched in the  NFS-server-1 and other
>  instances in the NFS-server-2, but at the same time to be possible to
>  migrate instances between nodes.
> Is it possible???
>
> Thanks a lot.
>
>
>*Sergio Ariel *
>
> *de la Campa Saiz*
>
> GMV-SES Infraestructura /
> GMV-SES Infrastructure
>
>
>
>
>
>
>
> *GMV*
>
> Isaac Newton, 11
> P.T.M. Tres Cantos
> E-28760 Madrid
> Tel.
>
> +34 91 807 21 00
> Fax
>
> +34 91 807 21 99
>  www.gmv.com
>
>
>
>
>
>
>
>  --
> *De:* Igor Laskovy [igor.lask...@gmail.com]
> *Enviado el:* miércoles, 16 de mayo de 2012 20:05
> *Para:* Sergio Ariel de la Campa Saiz
> *CC:* Emilien Macchi; openstack-operat...@lists.openstack.org; <
> openstack@lists.launchpad.net>
> *Asunto:* Re: [Openstack-operators] nova and multiple storages
>
>  ccing openstack@lists.launchpad.net
>
> On Wed, May 16, 2012 at 10:19 AM, Sergio Ariel de la Campa Saiz <
> saca...@gmv.com> wrote:
>
>>  Sorry to everyone if I didn´t tell exactly what I need, but Igor isright...
>> I need to configurate more than one NOVA-INST-DIR/instances/ by NFS.
>>
>> Thanks to Igor :-) :-)
>> Thanks to Emilien too :-) :-)
>>
>>*Sergio Ariel *
>>
>> *de la Campa Saiz*
>>
>> GMV-SES Infraestructura /
>> GMV-SES Infrastructure
>>
>>
>>
>>
>>
>>
>>
>> *GMV*
>>
>> Isaac Newton, 11
>> P.T.M. Tres Cantos
>> E-28760 Madrid
>> Tel.
>>
>> +34 91 807 21 00
>> Fax
>>
>> +34 91 807 21 99
>>  www.gmv.com
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  --
>> *De:* openstack-operators-boun...@lists.openstack.org [
>> openstack-operators-boun...@lists.openstack.org] En nombre de Igor
>> Laskovy [igor.lask...@gmail.com]
>> *Enviado el:* lunes, 14 de mayo de 2012 16:30
>> *Para:* Emilien Macchi
>> *CC:* Sergio Ariel de la Campa Saiz;
>> openstack-operat...@lists.openstack.org
>> *Asunto:* Re: [Openstack-operators] nova and multiple storages
>>
>>I guess Sergio told about more than one NOVA-INST-DIR/instances/
>> On May 14, 2012 3:11 PM, "Emilien Macchi" 
>> wrote:
>>
>>> Hi Sergio,
>>>
>>>
>>> When you talk about more than one storage, do you mean about
>>> Multi-Pathing ?
>>>
>>> You can use multi storage node for VMs, and you can use Nexenta Software
>>> which has a specific drvier for Openstack modules. In this case, you use
>>> iSCSI as a SAN, and High available storage with a lot of nice features.
>>>
>>> You can read more about how to use it 
>>> here
>>> .
>>>
>>>
>>> Good luck !
>>>
>>>
>>>
>>> On Mon, May 14, 2012 at 1:46 PM, Sergio Ariel de la Campa Saiz <
>>> saca...@gmv.com> wrote:
>>>
  Hi:

 I was wondering if it possible to configure each nova node to use
 more than one storage, I mean, if each node can storage its instancesin 
 more than
  one nfs server.

 How to configure this??

 Thanks a lot...


*Sergio Ariel *

 *de la Campa Saiz*

 GMV-SES Infraestructura /
 GMV-SES Infrastructure







 *GMV*

 Isaac Newton, 11
 P.T.M. Tres Cantos
 E-28760 Madrid
 Tel.

 +34 91 807 21 00
 Fax

 +34 91 807 21 99
 www.gmv.com






   **
 --
 This message including any attachments may contain confidential
 information, according to our Information Security Management System, and
 intended solely for a specific individual to whom they are addressed. Any
 unauthorised copy, disclosure or distribution of this message is strictly
 forbidden. If you have received this transmission in error, please notify
 the sender immediately and delete it. **
 --
 Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
 contener información clasificada por su emisor como confidencial en el
 marco de su Sistema de Gestión de Seguridad de la Información siendo para
 uso exclusivo del destinatario, quedando prohibida su divulgación copia o
 distribución a terceros sin la autorización expresa del remitente. Si Vd.
 ha recibido este mensaje erróneamente, se ruega lo notifique al remitente y
 proceda a su borrado. 

[Openstack] BadRequest: Can not find requested image (HTTP 400)

[Milind]

Hi,

I am getting error while executing following command.

root@ucmaster:/home/milindx/mil# nova boot --image tty-linux --flavor
m1.small --key_name test my-first-server
ERROR: Can not find requested image (HTTP 400)

Following information will help

root@ucmaster:/home/milindx/mil# cat /etc/nova/nova.conf | grep glance
--image_service=nova.image.glance.GlanceImageService
--glance_api_servers=10.253.59.152:9292

root@ucmaster:/home/milindx/mil# nova image-list
+--+--+++
|  ID  |   Name   | Status | Server
|
+--+--+++
| 057f5695-7af5-4d42-ab17-2f0f36f99ee2 | tty-linux| ACTIVE |
|
| 1cfd638b-1187-4f35-a0dd-76352742b762 | tty-kernel   | ACTIVE |
|
| 40c6e4ec-9b49-4f5c-989d-57cd2691fa12 | tty-linuxkernel  | ACTIVE |
|
| a726d350-c187-401b-823c-7bb1527aaa1d | tty-linuxramdisk | ACTIVE |
|
| b1c79ba2-aef0-4dfc-8e0f-f1f223bea1f1 | tty  | ACTIVE |
|
| b3240f79-5b6f-450c-beff-5c8ecdabcf00 | tty-ramdisk  | ACTIVE |
|
+--+--+++
root@ucmaster:/home/milindx/mil#

root@ucmaster:/home/milindx/mil# nova-manage service list
2012-05-18 17:15:30 DEBUG nova.utils
[req-0997c625-ef9c-45ab-96a9-77a211d87459 None None] backend  from
(pid=15253) __get_backend /usr/lib/python2.7/dist-packages/nova/utils.py:658
Binary   Host Zone
Status State Updated_At
nova-scheduler   ucmaster nova
enabled:-)   2012-05-18 11:45:25
nova-volume  ucmaster nova
enabled:-)   2012-05-18 11:45:25
nova-compute ucmaster nova
enabled:-)   2012-05-18 11:45:21
nova-certucmaster nova
enabled:-)   2012-05-18 11:45:25
nova-consoleauth ucmaster nova
enabled:-)   2012-05-18 11:45:25
nova-network ucmaster nova
enabled:-)   2012-05-18 11:45:25

I have deleted and added images using glance still problem persists, any
one know what could be problem.

Regards,
Milind
___
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] BadRequest: Can not find requested image (HTTP 400)

[Razique Mahroua]

Hi, it's weird, I remember someone having the same issue.Edit
 : herehttps://lists.launchpad.net/openstack/msg11742.htmlIt
 may be related to the bug ? 	   
   	Milind  
  18 mai 2012 13:46Hi,I am getting error 
while executing following command.root@ucmaster:/home/milindx/mil#
 nova boot --image tty-linux --flavor m1.small --key_name test 
my-first-serverERROR: Can not find requested image (HTTP 400)
Following information will helproot@ucmaster:/home/milindx/mil#
 cat /etc/nova/nova.conf | grep glance--image_service=nova.image.glance.GlanceImageService--glance_api_servers=10.253.59.152:9292
root@ucmaster:/home/milindx/mil# nova image-list+--+--+++| 
 ID  |   Name   | Status | Server |+--+--+++
| 057f5695-7af5-4d42-ab17-2f0f36f99ee2 | tty-linux    | ACTIVE 
|    || 1cfd638b-1187-4f35-a0dd-76352742b762 | tty-kernel   |
 ACTIVE |    || 40c6e4ec-9b49-4f5c-989d-57cd2691fa12 | 
tty-linuxkernel  | ACTIVE |    |
| a726d350-c187-401b-823c-7bb1527aaa1d | tty-linuxramdisk | ACTIVE 
|    || b1c79ba2-aef0-4dfc-8e0f-f1f223bea1f1 | tty  |
 ACTIVE |    || b3240f79-5b6f-450c-beff-5c8ecdabcf00 | 
tty-ramdisk  | ACTIVE |    |
+--+--+++root@ucmaster:/home/milindx/mil#root@ucmaster:/home/milindx/mil#
 nova-manage service list2012-05-18 17:15:30 DEBUG nova.utils 
[req-0997c625-ef9c-45ab-96a9-77a211d87459 None None] backend  from 
(pid=15253) __get_backend 
/usr/lib/python2.7/dist-packages/nova/utils.py:658
Binary   Host Zone 
Status State Updated_Atnova-scheduler   
ucmaster nova enabled    :-)   
2012-05-18 11:45:25nova-volume  
ucmaster nova enabled    :-)   
2012-05-18 11:45:25
nova-compute ucmaster nova 
enabled    :-)   2012-05-18 11:45:21nova-cert    
ucmaster nova enabled    :-)   
2012-05-18 11:45:25
nova-consoleauth ucmaster nova 
enabled    :-)   2012-05-18 11:45:25nova-network 
ucmaster nova enabled    :-)   
2012-05-18 11:45:25
I have deleted and added images using glance still problem persists,
 any one know what could be problem.Regards,Milind

___Mailing list: 
https://launchpad.net/~openstackPost to : 
openstack@lists.launchpad.netUnsubscribe : 
https://launchpad.net/~openstackMore help   : 
https://help.launchpad.net/ListHelp-- Nuage & Co - Razique Mahroua 
razique.mahr...@gmail.com








 






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

[Openstack] How to access an instance from Dashboard using VNC (password)?

[Jorge Luiz Correa]

Hi all,

how we can access an instance using the dashboard and the VNC it provides?
For example, if a common user creates an instance and click on VNC tab, he
will be able to see a VNC console and login screen. How can he know the
password? If the instance is created in command line with nova boot 
there is an output that shows the root password. But, from inside
dashboard, I couldn't find where to get a similar information.

Thanks!

-- 
- MSc. Correa, J.L.
___
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] BadRequest: Can not find requested image (HTTP 400)

[Milind]

Is there any way to find out if image is exists with the help of glance
command?
I checked everything all parameters are properly configured in conf files.

On Fri, May 18, 2012 at 5:19 PM, Razique Mahroua
wrote:

> Hi,
> it's weird, I remember someone having the same issue.
> Edit : here
> https://lists.launchpad.net/openstack/msg11742.html
>
> It may be related to the bug ?
>
>  Milind 
>  18 mai 2012 13:46
> Hi,
>
> I am getting error while executing following command.
>
> root@ucmaster:/home/milindx/mil# nova boot --image tty-linux --flavor
> m1.small --key_name test my-first-server
> ERROR: Can not find requested image (HTTP 400)
>
> Following information will help
>
> root@ucmaster:/home/milindx/mil# cat /etc/nova/nova.conf | grep glance
> --image_service=nova.image.glance.GlanceImageService
> --glance_api_servers=10.253.59.152:9292
>
> root@ucmaster:/home/milindx/mil# nova image-list
>
> +--+--+++
> |  ID  |   Name   | Status |
> Server |
>
> +--+--+++
> | 057f5695-7af5-4d42-ab17-2f0f36f99ee2 | tty-linux| ACTIVE
> ||
> | 1cfd638b-1187-4f35-a0dd-76352742b762 | tty-kernel   | ACTIVE
> ||
> | 40c6e4ec-9b49-4f5c-989d-57cd2691fa12 | tty-linuxkernel  | ACTIVE
> ||
> | a726d350-c187-401b-823c-7bb1527aaa1d | tty-linuxramdisk | ACTIVE
> ||
> | b1c79ba2-aef0-4dfc-8e0f-f1f223bea1f1 | tty  | ACTIVE
> ||
> | b3240f79-5b6f-450c-beff-5c8ecdabcf00 | tty-ramdisk  | ACTIVE
> ||
>
> +--+--+++
> root@ucmaster:/home/milindx/mil#
>
> root@ucmaster:/home/milindx/mil# nova-manage service list
> 2012-05-18 17:15:30 DEBUG nova.utils
> [req-0997c625-ef9c-45ab-96a9-77a211d87459 None None] backend  'nova.db.sqlalchemy.api' from
> '/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.pyc'> from
> (pid=15253) __get_backend /usr/lib/python2.7/dist-packages/nova/utils.py:658
> Binary   Host Zone
> Status State Updated_At
> nova-scheduler   ucmaster nova
> enabled:-)   2012-05-18 11:45:25
> nova-volume  ucmaster nova
> enabled:-)   2012-05-18 11:45:25
> nova-compute ucmaster nova
> enabled:-)   2012-05-18 11:45:21
> nova-certucmaster nova
> enabled:-)   2012-05-18 11:45:25
> nova-consoleauth ucmaster nova
> enabled:-)   2012-05-18 11:45:25
> nova-network ucmaster nova
> enabled:-)   2012-05-18 11:45:25
>
> I have deleted and added images using glance still problem persists, any
> one know what could be problem.
>
> Regards,
> Milind
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
> --
> Nuage & Co - Razique Mahroua
> razique.mahr...@gmail.com
>
>
>
>
<><>___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Dashboard] Can't access images/snapshots

[Leander Bessa Beernaert]

Ok, i've removed swift from the endpoints and services. Nova volumes is
running with a 2GB file as volume on disk and the log files seem ok.
However, i still keep getting this error for volume-list (
http://paste.openstack.org/show/17991/) and this error for snapshot-list (
http://paste.openstack.org/show/17992/).

On Thu, May 17, 2012 at 7:39 PM, Gabriel Hurley
wrote:

>  Two points:
>
> ** **
>
> Nova Volume is a required service for Essex Horizon. That’s documented,
> and there are plans to make it optional for Folsom. However, not having it
> should yield a pretty error message in the dashboard, not a KeyError in
> novaclient, which leads me to my second point…
>
> ** **
>
> It sounds like your Keystone service catalog is misconfigured. If you’re
> seeing Swift (AKA Object Store) in the dashboard, that means it’s in your
> keystone service catalog. Swift is a completely optional component and is
> triggered on/off by the presence of an “object-store” endpoint returned by
> Keystone.
>
> ** **
>
> I’d check and make sure the services listed in Keystone’s catalog are
> correct for what’s actually running in your environment.
>
> ** **
>
> All the best,
>
> ** **
>
> **-  **Gabriel
>
> ** **
>
> *From:* 
> openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net[mailto:
> openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] *On
> Behalf Of *Leander Bessa Beernaert
> *Sent:* Thursday, May 17, 2012 8:45 AM
> *To:* Sébastien Han
> *Cc:* openstack@lists.launchpad.net
> *Subject:* Re: [Openstack] [Dashboard] Can't access images/snapshots
>
> ** **
>
> Now i made sure nova-volume is installed and running. I still keep running
> into the same problem. It also happens from the command line tool. This is
> the output produced > http://paste.openstack.org/show/17929/
>
> On Thu, May 17, 2012 at 11:17 AM, Leander Bessa Beernaert <
> leande...@gmail.com> wrote:
>
> I have no trouble from the command line. One thing i find peculiar is that
> i haven't installed swift and nova-volume yet and they show up as enabled
> services in the dashboard. Is that normal?
>
> ** **
>
> On Wed, May 16, 2012 at 11:39 PM, Sébastien Han 
> wrote:
>
> Hi,
>
> ** **
>
> Do you also have an error when retrieving from the command line?
>
>
> 
>
> ~Cheers!
>
>
>
> 
>
> On Wed, May 16, 2012 at 5:38 PM, Leander Bessa Beernaert <
> leande...@gmail.com> wrote:
>
>  Hello,
>
> ** **
>
> I keep running into this error when i try to list the images/snapshot in
> dashboard: http://paste.openstack.org/show/17820/
>
> ** **
>
> This is my local_settings.py file: http://paste.openstack.org/show/17822/ ,
> am i missing something?
>
> ** **
>
> Regards,
>
> ** **
>
> Leander 
>
> ** **
>
> ___
> 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] BadRequest: Can not find requested image (HTTP 400)

[Vaze, Mandar]

Milind,

Nova boot command takes Image and Flavor IDs, not names
Can you try "nova boot -image  057f5695-7af5-4d42-ab17-2f0f36f99ee2 " instead ?
Similarly, you may need to use -flavor 2 instead of --flavor m1.small

If you are interested in looking at code, see "def do_boot" in 
novaclient/v1_1/shell.py under python-novaclient repo.

nova help boot
usage: nova boot [--flavor ] [--image ] [--meta ]
 [--file ] [--key_name ]
 [--user_data ]
 [--availability_zone ]
 [--security_groups ]
 [--block_device_mapping ]
 [--hint ]
 [--nic ]
 [--config-drive ] [--poll]
 

Boot a new server.

Positional arguments:
  Name for the new server

Optional arguments:
  --flavor  Flavor ID (see 'nova flavor-list').
  --imageImage ID (see 'nova image-list').

Hope this helps.

-Mandar

From: openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net 
[mailto:openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net] On 
Behalf Of Milind
Sent: Friday, May 18, 2012 5:16 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] BadRequest: Can not find requested image (HTTP 400)

Hi,

I am getting error while executing following command.

root@ucmaster:/home/milindx/mil# nova boot --image tty-linux --flavor m1.small 
--key_name test my-first-server
ERROR: Can not find requested image (HTTP 400)

Following information will help

root@ucmaster:/home/milindx/mil# cat /etc/nova/nova.conf | grep glance
--image_service=nova.image.glance.GlanceImageService
--glance_api_servers=10.253.59.152:9292

root@ucmaster:/home/milindx/mil# nova image-list
+--+--+++
|  ID  |   Name   | Status | Server |
+--+--+++
| 057f5695-7af5-4d42-ab17-2f0f36f99ee2 | tty-linux| ACTIVE ||
| 1cfd638b-1187-4f35-a0dd-76352742b762 | tty-kernel   | ACTIVE ||
| 40c6e4ec-9b49-4f5c-989d-57cd2691fa12 | tty-linuxkernel  | ACTIVE ||
| a726d350-c187-401b-823c-7bb1527aaa1d | tty-linuxramdisk | ACTIVE ||
| b1c79ba2-aef0-4dfc-8e0f-f1f223bea1f1 | tty  | ACTIVE ||
| b3240f79-5b6f-450c-beff-5c8ecdabcf00 | tty-ramdisk  | ACTIVE ||
+--+--+++
root@ucmaster:/home/milindx/mil#

root@ucmaster:/home/milindx/mil# nova-manage service list
2012-05-18 17:15:30 DEBUG nova.utils [req-0997c625-ef9c-45ab-96a9-77a211d87459 
None None] backend  from (pid=15253) 
__get_backend /usr/lib/python2.7/dist-packages/nova/utils.py:658
Binary   Host Zone Status   
  State Updated_At
nova-scheduler   ucmaster nova enabled  
  :-)   2012-05-18 11:45:25
nova-volume  ucmaster nova enabled  
  :-)   2012-05-18 11:45:25
nova-compute ucmaster nova enabled  
  :-)   2012-05-18 11:45:21
nova-certucmaster nova enabled  
  :-)   2012-05-18 11:45:25
nova-consoleauth ucmaster nova enabled  
  :-)   2012-05-18 11:45:25
nova-network ucmaster nova enabled  
  :-)   2012-05-18 11:45:25

I have deleted and added images using glance still problem persists, any one 
know what could be problem.

Regards,
Milind


__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data.  If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] How to access an instance from Dashboard using VNC (password)?

[Vaze, Mandar]

Ø  But, from inside dashboard, I couldn't find where to get a similar 
information.

>From Dashboard,  Click "Edit Instance" button on far right, and click on "View 
>Log"
Scroll at the end, you'll see the password.

-Mandar


__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data.  If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] BadRequest: Can not find requested image (HTTP 400)

[Vaze, Mandar]

Ø  Is there any way to find out if image is exists with the help of glance 
command?
"glance image-list"

See my other email for your original problem

-Mandar

__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data.  If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] About openstack common client

[Andrew Bogott]

On 5/18/12 12:16 AM, Yong Sheng Gong wrote:


Hi,
I just want to ask about the relationship among openstackclient 
https://launchpad.net/python-openstackclientand other clients.
Will openstackclient replace other clients ( such as quantum client, 
keystone client, nova client, xx) or just a supplement?
My understanding (and hope) is that ultimately there will be a 
separation between shell interfaces and REST interfaces.  
Openstackclient will implement the commandline, and the other clients 
(python-novaclient, python-glanceclient, etc.) will provide python APIs 
for REST clients, of which openstackclient is one.


by now, the openstackclient is calling codes from other clients, so it 
seems it is just another client wrapper. In this case, we will have to 
implement two set of front codes to call specific client. One will be 
in openstackclient, and one will be in separate client itself.
I expect non-common shell clients to be deprecated and eventually ripped 
out.  We're probably a bit too early in the game to explicitly 
discourage development on those shell commands though.


-Andrew
___
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 network external gateway

[George Mihaiescu]

You can try the solution proposed by Vish on February 23, 2012.

Put the flag and the config file on the nodes with nova-network as they have 
dnsmasq running:

 

 

" Then you can use

--dnsmasq_config_file=/path/to/config

in that config file you can use:

dhcp_opiton=3, to force vms to use your router as their gateway. "

 

 

 



From: openstack-bounces+george.mihaiescu=q9@lists.launchpad.net 
[mailto:openstack-bounces+george.mihaiescu=q9@lists.launchpad.net] On 
Behalf Of Sergio Ariel de la Campa Saiz
Sent: Friday, May 18, 2012 8:49 AM
To: openstack@lists.launchpad.net; openstack-operat...@lists.openstack.org
Subject: [Openstack] nova network external gateway

 

Hi:

 

I have installed Essex and I´m using vlan networking. All virtual machines use 
the same vlan, but I want all of them use an external gateway, I mean, a real 
router of my network instead of a nova node.
I have read about it and I have found a parameter named: dhcpoption=3,  but I don´t know where to put it. I know that dnsmasq loads it but... from 
where?? I did not find any dnsmasq.conf in my system and, in the other hand, I 
put it in my nova.conf file and nothing happened.

 

Thanks in advance

 

Good luck...

Sergio Ariel 

de la Campa Saiz

GMV-SES Infraestructura / 
GMV-SES Infrastructure

 

 

 

GMV 

Isaac Newton, 11
P.T.M. Tres Cantos
E-28760 Madrid
Tel. 

+34 91 807 21 00
Fax 

+34 91 807 21 99
www.gmv.com 

 

 

 



size=2 width="100%" align=center> 

This message including any attachments may contain confidential information, 
according to our Information Security Management System, and intended solely 
for a specific individual to whom they are addressed. Any unauthorised copy, 
disclosure or distribution of this message is strictly forbidden. If you have 
received this transmission in error, please notify the sender immediately and 
delete it. 



Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener 
información clasificada por su emisor como confidencial en el marco de su 
Sistema de Gestión de Seguridad de la Información siendo para uso exclusivo del 
destinatario, quedando prohibida su divulgación copia o distribución a terceros 
sin la autorización expresa del remitente. Si Vd. ha recibido este mensaje 
erróneamente, se ruega lo notifique al remitente y proceda a su borrado. 
Gracias por su colaboración. 



Esta mensagem, incluindo qualquer ficheiro anexo, pode conter informação 
confidencial, de acordo com nosso Sistema de Gestão de Segurança da Informação, 
sendo para uso exclusivo do destinatário e estando proibida a sua divulgação, 
cópia ou distribuição a terceiros sem autorização expressa do remetente da 
mesma. Se recebeu esta mensagem por engano, por favor avise de imediato o 
remetente e apague-a. Obrigado pela sua colaboração. 



___
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] About openstack common client

[Doug Hellmann]

On Fri, May 18, 2012 at 10:09 AM, Andrew Bogott wrote:

>  On 5/18/12 12:16 AM, Yong Sheng Gong wrote:
>
>
> Hi,
> I just want to ask about the relationship among openstackclient
> https://launchpad.net/python-openstackclient and other clients.
> Will openstackclient replace other clients ( such as quantum client,
> keystone client, nova client, xx) or just a supplement?
>
> My understanding (and hope) is that ultimately there will be a separation
> between shell interfaces and REST interfaces.  Openstackclient will
> implement the commandline, and the other clients (python-novaclient,
> python-glanceclient, etc.) will provide python APIs for REST clients, of
> which openstackclient is one.
>

That is also my understanding of The Plan.


> by now, the openstackclient is calling codes from other clients, so it
> seems it is just another client wrapper. In this case, we will have to
> implement two set of front codes to call specific client. One will be in
> openstackclient, and one will be in separate client itself.
>
> I expect non-common shell clients to be deprecated and eventually ripped
> out.  We're probably a bit too early in the game to explicitly discourage
> development on those shell commands though.
>

I'm waffling on agreeing with you here. It is true that (AFAIK) we aren't
set up for packaging builds yet for semi-official installations (i.e., not
using devstack), but I would like to have people who are more familiar with
the other command line programs contributing to the common client, too.

Doug
___
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 state machine simplification and clarification

[Mark Washenberger]

Hi Yun,

This proposal looks very good to me. I am glad you included in it the 
requirement that hard deletes can take place in any vm/task/power state. 

I however feel that a similar requirement exists for revert resize. It should 
be possible to issue a RevertResize command for any task_state (assuming that a 
resize is happening or has recently happened and is not yet confirmed). The 
code to support this capability doesn't exist yet, but I want to ask you: is it 
compatible with your proposal to allow RevertResize in any task state?

"Yun Mao"  said:

> Hi,
> 
> There are vm_states, task_states, and power_states for each VM. The
> use of them is complicated. Some states are confusing, and sometimes
> ambiguous. There also lacks a guideline to extend/add new state. This
> proposal aims to simplify things, explain and define precisely what
> they mean, and why we need them. A new user-friendly behavior of
> deleting a VM is also discussed.
> 
> A TL;DR summary:
> * power_state is the hypervisor state, loaded “bottom-up” from compute
> worker;
> * vm_state reflects the stable state based on API calls, matching user
> expectation, revised “top-down” within API implementation.
> * task_state reflects the transition state introduced by in-progress API 
> calls.
> * “hard” delete of a VM should always succeed no matter what.
> * power_state and vm_state may conflict with each other, which needs
> to be resolved case-by-case.
> 
> It's not a definite guide yet and is up for discussion. I'd like to
> thank vishy and comstud for the early input. comstud: the task_state
> is different from when you looked at it. It's a lot closer to what's
> in the current code.
> 
> The full text is here and is editable by anyone like etherpad.
> 
> https://docs.google.com/document/d/1nlKmYld3xxpTv6Xx0Iky6L46smbEqg7-SWPu_o6VJws/edit?pli=1
> 
> Thanks,
> 
> Yun
> 
> ___
> 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] [metering] Choice of a messaging queue

[Doug Hellmann]

On Fri, May 18, 2012 at 4:42 AM, Nick Barcet wrote:

> Hello everyone,
>
> Next week's irc meeting will have for goal to choose a reference
> messaging queue service for the ceilometer project.  For this meeting to
> be able to be successful, a discussion on the choices that we have to
> make need to occur first right here.
>
> To open the discussion here are a few requirements that I would consider
> important for the queue to support:
>
> a) the queue must guaranty the delivery of messages.
> To the contrary of monitoring, loss of events may have important billing
> impacts, it therefore cannot be an option that message be lost.
>
> b) the client should be able to store and forward.
> As the load of system or traffic increases, or if the client is
> temporarily disconnected, client element of the queue should be able to
> hold messages in a local queue to be emitted as soon as condition permit.
>
> c) client must authenticate
> Only client which hold a shared private key should be able to send
> messages on the queue.
>

Does the username/password authentication of rabbitmq meet this requirement?


>
> d) queue may support client signing of individual messages
> Each message should be individually signed by the agent that emits it in
> order to guaranty non repudiability.  This function can be done by the
> queue client or by the agent prior to en-queuing of messages.
>

We can embed the message signature in the message, so this requirement
shouldn't have any bearing on the bus itself. Unless I'm missing something?


>
> d) queue must be highly available
> the queue servers must be able to support multiple instances running in
> parallel in order to support continuation of operations with the loss of
> one server.  This should be achievable without the need to use complex
> fail over systems and shared storage.
>
> e) queue should be horizontally scalable
> The scalability of queue servers should be achievable by increasing the
> number of servers.
>
> Not sure this list is exhaustive or viable, feel free to comment on it,
> but the real question is: which queue should we be using here?
>

While I see the benefit of discussing requirements for the message bus
platform in general, I'm not sure we need to dictate a specific
implementation. If we say we are going to use the nova RPC library to
communicate with the bus for sending and receiving messages, then we can
use all of the tools for which there are drivers in nova -- rabbit, qpid,
zeromq (assuming someone releases a driver, which I think is being worked
on somewhere), etc. This leaves the decision of which bus to use up to the
deployer, where the decision belongs. It also means we won't end up
choosing a tool for which the other projects have no driver, leading us to
have to create one and add a new dependency to the project.

Doug
___
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] [metering] Do we need an API and storage?

[Doug Hellmann]

On Fri, May 18, 2012 at 5:27 AM, Thierry Carrez wrote:

> Doug Hellmann wrote:
> > On Thu, May 17, 2012 at 5:47 AM, Nick Barcet  > > wrote:
> >
> > On 05/17/2012 11:13 AM, Loic Dachary wrote:
> > > On 05/16/2012 11:00 PM, Francis J. Lacoste wrote:
> > >>
> > >> I'm now of the opinion that we exclude storage and API from the
> > >> metering project scope. Let's just focus on defining a metering
> > >> message format, bus, and maybe a client-library to make it easy to
> > >> write metering consumers.
> >
> >
> > The plan, as I understand it, is to ensure that all metering messages
> > appear on a common bus using a documented format. Deployers who do not
> > want the storage system and REST API will not need to use it, and can
> > set up their own clients to listen on that bus. I'm not sure how much of
> > a client library is needed, since the bus is AMQP and the messages are
> > JSON, both of which have standard libraries in most common languages.
> > [...]
>
> You can certainly architect it in a way so that storage and API are
> optional: expose metering messages on the bus, and provide an
> optionally-run aggregation component that exposes a REST API (and that
> would use the metering-consumer client library). That would give
> deployers the option to poll via REST or implement their own alternate
> aggregation using the metering-consumer client lib, depending on the
> system they need to integrate with.
>
> Having the aggregation component clearly separate and optional will
> serve as a great example of how it could be done (and what are the
> responsibilities of the aggregation component). I would still do a
> (minimal) client library to facilitate integration, but maybe that's
> just me :)


I can see some benefit to that, especially when it comes to validating the
message signatures.

Doug
___
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] error in documentation regarding novnc configuration on newly added compute node

[Staicu Gabriel]

Hi all,

I observed an error in documentation regarding the configuration needed to be 
done on additional compute-nodes in order to allow vnc access to instances.
>From what I understood from doc you just have to copy nova.conf on additional 
>nodes.
However there are some changes to made in the nova.conf of the node you want to 
add or the cloud.
The parameters to be changed 
are:--vncserver_proxyclient_address;--vncserver_listen

If on the cloud master they have the values:

--vncserver_proxyclient_address=$ip_cloud_master
--vncserver_listen=$ip_cloud_master

On the newly added compute node they have to be:
--vncserver_proxyclient_address=$ip_compute_node
--vncserver_listen=$ip_compute_node
>From my testing and small understanding :) these values are as such:
-vncserver_listen is the address that you will find in libvirt.xml 
corresponding to the instance started on this server. If you put a value 
different from the ip addresses on this server the instances won't come up.
-vncserver_proxyclient_address is the address that nova-consoleauth will 
associate with the requested token.

I don't know if I explained clearly enough so I will give an example.
I have 2 servers in my cloud, node01(master_cloud), node02(compute_node). If on 
node02 the value vncserver_proxyclient_address is $ip_cloud_master after I 
start an instance on node02 vnc will direct me to $ip_cloud_master:5900 which 
is an old instance created on node01. If If on node02 the value 
vncserver_proxyclient_address is $ip_compute_node
 after I start an instance on node02 vnc will direct me to 
$ip_compute_node:5900 which is what I am looking for. BINGO!!

Regards,
Gabriel___
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] BadRequest: Can not find requested image (HTTP 400)

[Razique Mahroua]

You can run a $ glance index, but there are high chances you 
would see them... 	   
   	Vaze, Mandar  
  18 mai 2012 15:15







Ø 
Is there any way to find out if image
 is exists with the help of glance command?
“glance image-list”
 
See
 my other email for your original problem
 
-Mandar


__
Disclaimer:This email and any attachments are sent in strictest 
confidence for the sole use of the addressee and may contain legally 
privileged, confidential, and proprietary data.  If you are not the 
intended recipient, please advise the sender by replying promptly to 
this email and then delete and destroy this email and any attachments 
without any further use, copying or forwarding
 	   
   	Milind  
  18 mai 2012 14:26Is there any way to find out if
 image is exists with the help of glance command?I checked 
everything all parameters are properly configured in conf files.

 	   
   	Milind  
  18 mai 2012 13:46Hi,I am getting error 
while executing following command.root@ucmaster:/home/milindx/mil#
 nova boot --image tty-linux --flavor m1.small --key_name test 
my-first-serverERROR: Can not find requested image (HTTP 400)
Following information will helproot@ucmaster:/home/milindx/mil#
 cat /etc/nova/nova.conf | grep glance--image_service=nova.image.glance.GlanceImageService--glance_api_servers=10.253.59.152:9292
root@ucmaster:/home/milindx/mil# nova image-list+--+--+++| 
 ID  |   Name   | Status | Server |+--+--+++
| 057f5695-7af5-4d42-ab17-2f0f36f99ee2 | tty-linux    | ACTIVE 
|    || 1cfd638b-1187-4f35-a0dd-76352742b762 | tty-kernel   |
 ACTIVE |    || 40c6e4ec-9b49-4f5c-989d-57cd2691fa12 | 
tty-linuxkernel  | ACTIVE |    |
| a726d350-c187-401b-823c-7bb1527aaa1d | tty-linuxramdisk | ACTIVE 
|    || b1c79ba2-aef0-4dfc-8e0f-f1f223bea1f1 | tty  |
 ACTIVE |    || b3240f79-5b6f-450c-beff-5c8ecdabcf00 | 
tty-ramdisk  | ACTIVE |    |
+--+--+++root@ucmaster:/home/milindx/mil#root@ucmaster:/home/milindx/mil#
 nova-manage service list2012-05-18 17:15:30 DEBUG nova.utils 
[req-0997c625-ef9c-45ab-96a9-77a211d87459 None None] backend  from 
(pid=15253) __get_backend 
/usr/lib/python2.7/dist-packages/nova/utils.py:658
Binary   Host Zone 
Status State Updated_Atnova-scheduler   
ucmaster nova enabled    :-)   
2012-05-18 11:45:25nova-volume  
ucmaster nova enabled    :-)   
2012-05-18 11:45:25
nova-compute ucmaster nova 
enabled    :-)   2012-05-18 11:45:21nova-cert    
ucmaster nova enabled    :-)   
2012-05-18 11:45:25
nova-consoleauth ucmaster nova 
enabled    :-)   2012-05-18 11:45:25nova-network 
ucmaster nova enabled    :-)   
2012-05-18 11:45:25
I have deleted and added images using glance still problem persists,
 any one know what could be problem.Regards,Milind

___Mailing list: 
https://launchpad.net/~openstackPost to : 
openstack@lists.launchpad.netUnsubscribe : 
https://launchpad.net/~openstackMore help   : 
https://help.launchpad.net/ListHelp-- Nuage & Co - Razique Mahroua 
razique.mahr...@gmail.com








 






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

Re: [Openstack] [metering] Choice of a messaging queue

[Adam Young]

I think you want to write to the AMQP spec as much as possible and allow 
multiple implementations.  Opentack supports Rabit MQ and QPID, and you 
should be able to use either.




On 05/18/2012 04:42 AM, Nick Barcet wrote:

Hello everyone,

Next week's irc meeting will have for goal to choose a reference
messaging queue service for the ceilometer project.  For this meeting to
be able to be successful, a discussion on the choices that we have to
make need to occur first right here.

To open the discussion here are a few requirements that I would consider
important for the queue to support:

a) the queue must guaranty the delivery of messages.
To the contrary of monitoring, loss of events may have important billing
impacts, it therefore cannot be an option that message be lost.

b) the client should be able to store and forward.
As the load of system or traffic increases, or if the client is
temporarily disconnected, client element of the queue should be able to
hold messages in a local queue to be emitted as soon as condition permit.

c) client must authenticate
Only client which hold a shared private key should be able to send
messages on the queue.

d) queue may support client signing of individual messages
Each message should be individually signed by the agent that emits it in
order to guaranty non repudiability.  This function can be done by the
queue client or by the agent prior to en-queuing of messages.

d) queue must be highly available
the queue servers must be able to support multiple instances running in
parallel in order to support continuation of operations with the loss of
one server.  This should be achievable without the need to use complex
fail over systems and shared storage.

e) queue should be horizontally scalable
The scalability of queue servers should be achievable by increasing the
number of servers.

Not sure this list is exhaustive or viable, feel free to comment on it,
but the real question is: which queue should we be using here?

Cheers,
--
Nick Barcet
aka: nijaba, nicolas




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


___
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] Understanding Integration Bridge and MACs

[Salman Malik]

Thanks Yamahata. I have tried the all-in-one configuration and it worked 
without any problems.
I will soon try the multi-node setup and will let you know of any 
problems/questions.

I appreciate all the hard work that openstack community is putting in the 
project.

Thanks,
Salman

> Date: Thu, 17 May 2012 21:04:23 +0900
> From: yamah...@valinux.co.jp
> To: salma...@live.com
> CC: openstack@lists.launchpad.net
> Subject: Re: [Openstack] Understanding Integration Bridge and MACs
> 
> Hi. Sorry for delayed replay.
> 
> Now precreated VM image is available for easy evaluation.
> It is announced on ryu-de...@lists.sourceforge.net,
> I site it for sure. I hope you can get successful result.
> 
> > From: FUJITA Tomonori 
> > Subject: pre-configured VM image file for OpenStack environment with Ryu
> >
> > Hi,
> > 
> > We created a VM image file that enables you to easily set up
> > multi-node Nova environment with Ryu in your desktop machine:
> > 
> > https://github.com/osrg/ryu/wiki/RYU-OpenStack-environment-VM-image-file-HOWTO
> > 
> > Enjoy!
> 
> On Sun, May 13, 2012 at 07:42:14PM -0500, Salman Malik wrote:
> > Hi Dan and Others,
> > 
> > I am trying to understand the actions taken by Ryu when the new instance 
> > sends
> > DHCP discover message to dnsmasq. When I launch new instannce it keeps on
> > sending discover messages and controller keeps on dropping these messages. 
> > But
> > looking at the traffic I couldn't exactly map which MAC address belonged to
> > which entity. Can someone help me with my understanding of the MAC 
> > addresses.
> > Using ifconfig , "ovs-ofctl show br-int" and "ovs-ofctl snoop br-int" 
> > (output
> > shown after MAC addresses), I know exactly about some MAC addresses and 
> > can't
> > figure out some of them:
> > 
> > Interfaces  |HWAddress  |IP-addr
> > -
> > eth0|08:00:27:7a:ff:65|10.0.3.15
> > eth1|08:00:27:16:d5:09  |   
> > 10.0.0.10  > gw-82bd3a73-dc|fa:16:3e:49:57:1b  |10.0.0.1   
> > <
> > plugged into br-int (this is the --listen-address of my two dnsmasqs)
> > br-int   |08:00:27:16:d5:09 |   
> >  > new-instance  |02:d8:47:48:35:26  <== MAC address of 
> > newly
> > launched instance? (see output below)
> > 
> > Unkown |fa:16:3e:5e:02:17   <==Seemingly unknown
> > MAC address(which is related to the new instance?)
> > Unkown  |33:33:00:00:00:16   <== MAC address
> > related to multicast ?
> > 
> > 
> > Questions:
> > 
> > 1. What is gw-82bd3a73-dc interface ?
> > 2. I am kind of unsure why br-int is so useful?
> > 3. Why doesn't br-int don't have any IP address?
> > 4. Why do we need to plugin a compute node's interface to br-int? (so that
> > guest instances on remote host can communicate with each other?)
> > 5. What is the relationship b/w 02:d8:47:48:35:26 and fa:16:3e:5e:02:17 MAC
> > addresses in the following output?
> > 
> > =
> > Output of : ovs-ofctl snoop br-int
> > =
> > OFPT_ECHO_REQUEST (xid=0x0): 0 bytes of payload
> > OFPT_ECHO_REPLY (xid=0x0): 0 bytes of payload
> > OFPT_PORT_STATUS (xid=0x0): ADD: 7(tap76127847-b1): addr:02:d8:47:48:35:26
> >  config: 0
> >  state:  LINK_DOWN
> >  current:10MB-FD COPPER
> > OFPT_FLOW_MOD (xid=0x491662da): DEL priority=0 buf:0x0 actions=drop
> > OFPT_BARRIER_REQUEST (xid=0x491662db):
> > OFPT_BARRIER_REPLY (xid=0x491662db):
> > OFPT_PORT_STATUS (xid=0x0): MOD: 7(tap76127847-b1): addr:02:d8:47:48:35:26
> >  config: 0
> >  state:  0
> >  current:10MB-FD COPPER
> > OFPT_ECHO_REQUEST (xid=0x0): 0 bytes of payload
> > OFPT_ECHO_REPLY (xid=0x0): 0 bytes of payload
> > OFPT_PACKET_IN (xid=0x0): total_len=90 in_port=7 data_len=90 
> > buffer=0x0167
> > tunnel0:in_port0007:tci(0) macfa:16:3e:5e:02:17->33:33:00:00:00:16 type86dd
> > proto58 tos0 ipv6::->ff02::16 port143->0
> > fa:16:3e:5e:02:17 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: 
> > :: >
> > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), 
> > length 28
> > OFPT_PACKET_OUT (xid=0x491662dc): in_port=7 actions_len=0 actions=drop 
> > buffer=
> > 0x0167
> > OFPT_PACKET_IN (xid=0x0): total_len=322 in_port=7 data_len=128 buffer=
> > 0x0168
> > tunnel0:in_port0007:tci(0) macfa:16:3e:5e:02:17->ff:ff:ff:ff:ff:ff type0800
> > proto17 tos0 ip0.0.0.0->255.255.255.255 port68->67
> > fa:16:3e:5e:02:17 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 128:
> > truncated-ip - 194 bytes missing! 0.0.0.0.68 > 255.255.255.255.67: 
> > BOOTP/DHCP,
> > Request from fa:16:3e:5e:02:17, length 280
> > OF

[Openstack] Instances don't get an IP from DHCP (Quantum, OVS, multi-node computes)

[Emilien Macchi]

Hi,

Since 2 weeks, I've been looking for a solution with a Quantum + OVS issue.

The situation :

2 servers :

Essex-1 - Eth0 : 10.68.1.40 - ETH1 : connected to br-int OVS bridge
-> Glance, Nova-*, Keystone, Horizon, Quantum-Server, KVM, OVS,
Quantum-Agent
-> nova.conf :
https://github.com/EmilienM/doc-openstack/blob/master/Configuration%20Files/Essex-1/nova.conf

Essex-2 - Eth0 : 10.68.1.45 - ETH1 : connected to br-int OVS bridge
-> nova-compute, KVM, Quantum-Agent
-> nova.conf :
https://github.com/EmilienM/doc-openstack/blob/master/Configuration%20Files/Essex-1/nova.conf

I've followed http://openvswitch.org/openstack/documentation/ and
http://docs.openstack.org/trunk/openstack-network/admin/content/

I've created th network with :
nova-manage network create --label=mysql
--fixed_range_v4=192.168.113.0/24--project_id=d2f0dc48a8944c6e96cb88c772376f06
--bridge=br-int
--bridge_interface=eth1

What's not working :
-> When I create an instance from dashboard, the VM does not get an IP from
DHCP server (hosted on ESSEX-1).
You can see the logs here : http://paste.openstack.org/show/17997/

What I did to investigate :
-> dhcpdump -i br-int : I can see DHCPDISCOVER on both servers (without
answers)
-> ps -ef | grep dnsmasq :
nobody 6564 1 0 14:12 ? 00:00:00 /usr/sbin/dnsmasq --strict-order
--bind-interfaces --conf-file= --domain=novalocal
--pid-file=/var/lib/nova/networks/nova-gw-0f427a46-3f.pid
--listen-address=192.168.113.1 --except-interface=lo
--dhcp-range=192.168.113.2,static,120s --dhcp-lease-max=256
--dhcp-hostsfile=/var/lib/nova/networks/nova-gw-0f427a46-3f.conf
--dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro
root 6565 6564 0 14:12 ? 00:00:00 /usr/sbin/dnsmasq --strict-order
--bind-interfaces --conf-file= --domain=novalocal
--pid-file=/var/lib/nova/networks/nova-gw-0f427a46-3f.pid
--listen-address=192.168.113.1 --except-interface=lo
--dhcp-range=192.168.113.2,static,120s --dhcp-lease-max=256
--dhcp-hostsfile=/var/lib/nova/networks/nova-gw-0f427a46-3f.conf
--dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro
root 16536 6192 0 14:40 pts/14 00:00:00 grep --color=auto dnsm

Is my nova.conf correct ?
What's wrong with my configuration ?
Is there a problem with DNSMASQ ?

I would apreciate any idea !

Regards

-- 
Emilien Macchi
*SysAdmin (Intern)*
*www.stackops.com* | emilien.mac...@stackops.com** | skype:memilien69
*

*

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

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

[Dean Troyer]

On Fri, May 18, 2012 at 12:16 AM, Yong Sheng Gong  wrote:
> I just want to ask about the relationship among openstackclient
> https://launchpad.net/python-openstackclient and other clients.
> Will openstackclient replace other clients ( such as quantum client,
> keystone client, nova client, xx) or just a supplement?

It will be a fully-functional-and-then-some replacement.

> by now, the openstackclient is calling codes from other clients, so it seems
> it is just another client wrapper. In this case, we will have to implement
> two set of front codes to call specific client. One will be in
> openstackclient, and one will be in separate client itself.

I'm not sure what you are implementing here; if it is an interface
that uses the CLI to drive OpenStack then you only need to talk to one
CLI (openstackclient) or to the existing CLIs (*client).
openstackclient has an advantage for scripted use in that it has an
option for easily parsable output.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [Openstack] About openstack common client

[Dean Troyer]

On Fri, May 18, 2012 at 9:17 AM, Doug Hellmann
 wrote:
>> I expect non-common shell clients to be deprecated and eventually ripped
>> out.  We're probably a bit too early in the game to explicitly discourage
>> development on those shell commands though.
>
> I'm waffling on agreeing with you here. It is true that (AFAIK) we aren't
> set up for packaging builds yet for semi-official installations (i.e., not
> using devstack), but I would like to have people who are more familiar with
> the other command line programs contributing to the common client, too.

I expect the existing project-specific CLIs to be around fot some
time.  The bit that openstackclient replaces is actually pretty small
code-wise so maintaining them isn't as much duplicated work as it
might seem.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [Openstack] [metering] Choice of a messaging queue

[Julien Danjou]

On Fri, May 18 2012, Doug Hellmann wrote:

> While I see the benefit of discussing requirements for the message bus
> platform in general, I'm not sure we need to dictate a specific
> implementation. If we say we are going to use the nova RPC library to
> communicate with the bus for sending and receiving messages, then we can
> use all of the tools for which there are drivers in nova -- rabbit, qpid,
> zeromq (assuming someone releases a driver, which I think is being worked
> on somewhere), etc. This leaves the decision of which bus to use up to the
> deployer, where the decision belongs. It also means we won't end up
> choosing a tool for which the other projects have no driver, leading us to
> have to create one and add a new dependency to the project.

+1

-- 
Julien Danjou
// eNovance  http://enovance.com
// ✉ julien.dan...@enovance.com  ☎ +33 1 49 70 99 81

___
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] [metering] Choice of a messaging queue

[Eric Windisch]

The nova rpc implementation is moving into openstack common, I agree with using 
this abstraction.

As per ZeroMQ, I'm the author of that plugin. There is a downloadable plugin 
for Essex and I'm preparing to make a Folsom merge prop within the next week or 
so, if all goes well.

Sent from my iPad

On May 18, 2012, at 7:26, Doug Hellmann  wrote:

> 
> 
> On Fri, May 18, 2012 at 4:42 AM, Nick Barcet  
> wrote:
> Hello everyone,
> 
> Next week's irc meeting will have for goal to choose a reference
> messaging queue service for the ceilometer project.  For this meeting to
> be able to be successful, a discussion on the choices that we have to
> make need to occur first right here.
> 
> To open the discussion here are a few requirements that I would consider
> important for the queue to support:
> 
> a) the queue must guaranty the delivery of messages.
> To the contrary of monitoring, loss of events may have important billing
> impacts, it therefore cannot be an option that message be lost.
> 
> b) the client should be able to store and forward.
> As the load of system or traffic increases, or if the client is
> temporarily disconnected, client element of the queue should be able to
> hold messages in a local queue to be emitted as soon as condition permit.
> 
> c) client must authenticate
> Only client which hold a shared private key should be able to send
> messages on the queue.
> 
> Does the username/password authentication of rabbitmq meet this requirement?
>  
> 
> d) queue may support client signing of individual messages
> Each message should be individually signed by the agent that emits it in
> order to guaranty non repudiability.  This function can be done by the
> queue client or by the agent prior to en-queuing of messages.
> 
> We can embed the message signature in the message, so this requirement 
> shouldn't have any bearing on the bus itself. Unless I'm missing something?
>  
> 
> d) queue must be highly available
> the queue servers must be able to support multiple instances running in
> parallel in order to support continuation of operations with the loss of
> one server.  This should be achievable without the need to use complex
> fail over systems and shared storage.
> 
> e) queue should be horizontally scalable
> The scalability of queue servers should be achievable by increasing the
> number of servers.
> 
> Not sure this list is exhaustive or viable, feel free to comment on it,
> but the real question is: which queue should we be using here?
> 
> While I see the benefit of discussing requirements for the message bus 
> platform in general, I'm not sure we need to dictate a specific 
> implementation. If we say we are going to use the nova RPC library to 
> communicate with the bus for sending and receiving messages, then we can use 
> all of the tools for which there are drivers in nova -- rabbit, qpid, zeromq 
> (assuming someone releases a driver, which I think is being worked on 
> somewhere), etc. This leaves the decision of which bus to use up to the 
> deployer, where the decision belongs. It also means we won't end up choosing 
> a tool for which the other projects have no driver, leading us to have to 
> create one and add a new dependency to the project.
> 
> Doug
> 
> ___
> 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] [metering] Choice of a messaging queue

[Doug Hellmann]

On Fri, May 18, 2012 at 11:02 AM, Eric Windisch wrote:

> The nova rpc implementation is moving into openstack common, I agree with
> using this abstraction.
>

That's a good point, I forgot about that.


>
> As per ZeroMQ, I'm the author of that plugin. There is a downloadable
> plugin for Essex and I'm preparing to make a Folsom merge prop within the
> next week or so, if all goes well.
>

Excellent!


>
> Sent from my iPad
>
> On May 18, 2012, at 7:26, Doug Hellmann 
> wrote:
>
>
>
> On Fri, May 18, 2012 at 4:42 AM, Nick Barcet wrote:
>
>> Hello everyone,
>>
>> Next week's irc meeting will have for goal to choose a reference
>> messaging queue service for the ceilometer project.  For this meeting to
>> be able to be successful, a discussion on the choices that we have to
>> make need to occur first right here.
>>
>> To open the discussion here are a few requirements that I would consider
>> important for the queue to support:
>>
>> a) the queue must guaranty the delivery of messages.
>> To the contrary of monitoring, loss of events may have important billing
>> impacts, it therefore cannot be an option that message be lost.
>>
>> b) the client should be able to store and forward.
>> As the load of system or traffic increases, or if the client is
>> temporarily disconnected, client element of the queue should be able to
>> hold messages in a local queue to be emitted as soon as condition permit.
>>
>> c) client must authenticate
>> Only client which hold a shared private key should be able to send
>> messages on the queue.
>>
>
> Does the username/password authentication of rabbitmq meet this
> requirement?
>
>
>>
>> d) queue may support client signing of individual messages
>> Each message should be individually signed by the agent that emits it in
>> order to guaranty non repudiability.  This function can be done by the
>> queue client or by the agent prior to en-queuing of messages.
>>
>
> We can embed the message signature in the message, so this requirement
> shouldn't have any bearing on the bus itself. Unless I'm missing something?
>
>
>>
>> d) queue must be highly available
>> the queue servers must be able to support multiple instances running in
>> parallel in order to support continuation of operations with the loss of
>> one server.  This should be achievable without the need to use complex
>> fail over systems and shared storage.
>>
>> e) queue should be horizontally scalable
>> The scalability of queue servers should be achievable by increasing the
>> number of servers.
>>
>> Not sure this list is exhaustive or viable, feel free to comment on it,
>> but the real question is: which queue should we be using here?
>>
>
> While I see the benefit of discussing requirements for the message bus
> platform in general, I'm not sure we need to dictate a specific
> implementation. If we say we are going to use the nova RPC library to
> communicate with the bus for sending and receiving messages, then we can
> use all of the tools for which there are drivers in nova -- rabbit, qpid,
> zeromq (assuming someone releases a driver, which I think is being worked
> on somewhere), etc. This leaves the decision of which bus to use up to the
> deployer, where the decision belongs. It also means we won't end up
> choosing a tool for which the other projects have no driver, leading us to
> have to create one and add a new dependency to the project.
>
> Doug
>
> ___
> 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] [metering] Choice of a messaging queue

[Eric Windisch]

> 
> 
> a) the queue must guaranty the delivery of messages.
> To the contrary of monitoring, loss of events may have important billing
> impacts, it therefore cannot be an option that message be lost.

Losing messages should always be an option, in the extreme cases. If a message 
is undeliverable for an excessive amount of time, it should be dropped. 
Otherwise, you'll need the queuing equivalent of a DBA doing periodic cleanup, 
which isn't very cloudy (or scalable).

I agree that the failure cases here are different than we'd normally see with 
Nova. Timeouts on messages would need to be much higher, and potentially 
disablable (but I do insist that a timeout, even if high, should be used).

> 
> b) the client should be able to store and forward.
> As the load of system or traffic increases, or if the client is
> temporarily disconnected, client element of the queue should be able to
> hold messages in a local queue to be emitted as soon as condition permit.

The zeromq driver definitely does this (kind of). It will try and send all 
messages at once via green threads, which is effectively the same thing. The 
nice thing is that with 0mq, when a message is sent, delivery to a peer is 
confirmed. 

I think, but may be wrong, that rabbit and qpid essentially do the same for 
store and forward, blocking their green threads until they hit a successful 
connection to the queue, or a timeout. With the amqp drivers, the sender only 
has a confirmation of delivery to the queuing server, not to the destination.
 
One thing the zeromq driver doesn't do is resume sending attempts across a 
service restart. Messages aren't durable in that fashion. This is largely 
because the timeout in Nova does not need to be very large, so there would be 
very little benefit. This goes back to your point in 'a'. Adding this feature 
would be relatively minor, it just wasn't needed in Nova. Actually, this 
limitation would be presumably true of rabbit and qpid as well, in the store 
and forward case.

> c) client must authenticate
> Only client which hold a shared private key should be able to send
> messages on the queue.
> d) queue may support client signing of individual messages
> Each message should be individually signed by the agent that emits it in
> order to guaranty non repudiability.  This function can be done by the
> queue client or by the agent prior to en-queuing of messages


There is a Folsom blueprint to add signing and/or encryption to the rpc layer.

> d) queue must be highly available
> the queue servers must be able to support multiple instances running in
> parallel in order to support continuation of operations with the loss of
> one server.  This should be achievable without the need to use complex
> fail over systems and shared storage.


> e) queue should be horizontally scalable
> The scalability of queue servers should be achievable by increasing the
> number of servers.

d/e are NOT properties of the rabbit (and qpid?) driver today in Nova, but it 
could (should) be made to work this way. You get this with the zeromq driver, 
of course ;)

> 
> Not sure this list is exhaustive or viable, feel free to comment on it,
> but the real question is: which queue should we be using here?

The OpenStack common rpc mechanism, for sure. I'm biased, but I believe that 
while the zeromq driver is the newest, it is the only driver that meets all of 
the above requirements, except, to the exceptions marked above.

Improving the other implementations should be done, but I don't know of anyone 
committed to that work.

Regards,
Eric Windisch
___
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 state machine simplification and clarification

[Gabe Westmaas]

I agree, this looks much more clear compared to where we are now.

I'd like to understand the difference between a soft and hard delete.
Does an API user have to specify that in some way?  I definitely agree
that you should be able to delete in any state, I would rather it not be a
requirement that the user interact differently when they want to delete a
server that has a task state already set.

Gabe

What exactly is a hard delete from the standpoint of a customer?  Is this
just a delete

On 5/18/12 10:20 AM, "Mark Washenberger" 
wrote:

>Hi Yun,
>
>This proposal looks very good to me. I am glad you included in it the
>requirement that hard deletes can take place in any vm/task/power state.
>
>I however feel that a similar requirement exists for revert resize. It
>should be possible to issue a RevertResize command for any task_state
>(assuming that a resize is happening or has recently happened and is not
>yet confirmed). The code to support this capability doesn't exist yet,
>but I want to ask you: is it compatible with your proposal to allow
>RevertResize in any task state?
>
>"Yun Mao"  said:
>
>> Hi,
>> 
>> There are vm_states, task_states, and power_states for each VM. The
>> use of them is complicated. Some states are confusing, and sometimes
>> ambiguous. There also lacks a guideline to extend/add new state. This
>> proposal aims to simplify things, explain and define precisely what
>> they mean, and why we need them. A new user-friendly behavior of
>> deleting a VM is also discussed.
>> 
>> A TL;DR summary:
>> * power_state is the hypervisor state, loaded ³bottom-up² from compute
>> worker;
>> * vm_state reflects the stable state based on API calls, matching user
>> expectation, revised ³top-down² within API implementation.
>> * task_state reflects the transition state introduced by in-progress
>>API calls.
>> * ³hard² delete of a VM should always succeed no matter what.
>> * power_state and vm_state may conflict with each other, which needs
>> to be resolved case-by-case.
>> 
>> It's not a definite guide yet and is up for discussion. I'd like to
>> thank vishy and comstud for the early input. comstud: the task_state
>> is different from when you looked at it. It's a lot closer to what's
>> in the current code.
>> 
>> The full text is here and is editable by anyone like etherpad.
>> 
>> 
>>https://docs.google.com/document/d/1nlKmYld3xxpTv6Xx0Iky6L46smbEqg7-SWPu_
>>o6VJws/edit?pli=1
>> 
>> Thanks,
>> 
>> Yun
>> 
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> 
>
>
>
>___
>Mailing list: https://launchpad.net/~openstack
>Post to : openstack@lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp


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

Re: [Openstack] RFC: Plugin framework draft

[Andrew Bogott]

On 5/17/12 4:38 PM, Doug Hellmann wrote:




In the wikistatus plugin I notice that you modify the global FLAGS 
when wikistatus.py is imported. Is that the right time to do that, or 
should it happen during the on-load handler in the plugin class? Or 
maybe even in the plugin manager, which could ask the plugin for the 
new options and then modify FLAGS itself. It seems like lots of Nova 
code modifies FLAGS during import, but having an explicit trigger for 
that (rather than depending on import order) seems safer to me.
I don't feel strongly about this -- I'm just following the example set 
by existing Nova code.  Can you think of a corner case where loading it 
at import time would cause problems?  Alternatively, can you think of a 
corner case where we would want a flag to be defined during the magic 
moment /between/ import time and the load callback?


I can't think of a case for either, although I have the vague feeling 
that the latter is slightly more possible (if still improbable.)




If the entry point for each plugin is given a unique name (instead of 
being called "plugin", as the sharedfs plugin is) we would be able to 
log "loading plugin X" as well as provide options to control which 
plugins are activated. I don't know if that latter idea is a goal or not.
If leaving in that option is free, then I'm all for it.  I'm still a bit 
new to entry points... is the entry-point name a totally arbitrary string?


Also, is supporting unique names the same thing as /requiring/ unique 
names?  Would this ultimately result in us needing a governed, 
hierarchical namespace?




- Two different loading pathways -- is that useful or just confusing?



"One and only one obvious way to do it."


OK, I'm convinced.  Outside of the common client, are entrypoints 
already a hard dependency elsewhere in OpenStack such that we don't lose 
anything by requiring them?



- Should the plugin base class interpose itself between the plugin
and python-openstackclient in order to enforce interface
versioning?  Is that even possible?


We could probably figure out a way to do that, but I don't know why 
you would want to. What did you have in mind? Which interface are you 
worried about versioning, the CLI itself?


I'm not sure I do want to, but here's my concern:  Right now the common 
client's API for extending the commandline is entirely internal to the 
common client itself.  When I write the sharedfs plugin to make use of 
that same API, I'm treating that internal API as external... and I don't 
like being the only person in the world doing that.


Of course, if the expectation is that that common client API will soon 
become public/documented/frozen anyway, then there's no problem.


-Andrew

___
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] Instances don't get an IP from DHCP (Quantum, OVS, multi-node computes)

[Dan Wendlandt]

discussion is being tracked here:
https://answers.launchpad.net/quantum/+question/197701

dan

On Fri, May 18, 2012 at 7:46 AM, Emilien Macchi  wrote:

> Hi,
>
> Since 2 weeks, I've been looking for a solution with a Quantum + OVS issue.
>
> The situation :
>
> 2 servers :
>
> Essex-1 - Eth0 : 10.68.1.40 - ETH1 : connected to br-int OVS bridge
> -> Glance, Nova-*, Keystone, Horizon, Quantum-Server, KVM, OVS,
> Quantum-Agent
> -> nova.conf :
> https://github.com/EmilienM/doc-openstack/blob/master/Configuration%20Files/Essex-1/nova.conf
>
> Essex-2 - Eth0 : 10.68.1.45 - ETH1 : connected to br-int OVS bridge
> -> nova-compute, KVM, Quantum-Agent
> -> nova.conf :
> https://github.com/EmilienM/doc-openstack/blob/master/Configuration%20Files/Essex-1/nova.conf
>
> I've followed http://openvswitch.org/openstack/documentation/ and
> http://docs.openstack.org/trunk/openstack-network/admin/content/
>
> I've created th network with :
> nova-manage network create --label=mysql 
> --fixed_range_v4=192.168.113.0/24--project_id=d2f0dc48a8944c6e96cb88c772376f06
>  --bridge=br-int
> --bridge_interface=eth1
>
> What's not working :
> -> When I create an instance from dashboard, the VM does not get an IP
> from DHCP server (hosted on ESSEX-1).
> You can see the logs here : http://paste.openstack.org/show/17997/
>
> What I did to investigate :
> -> dhcpdump -i br-int : I can see DHCPDISCOVER on both servers (without
> answers)
> -> ps -ef | grep dnsmasq :
> nobody 6564 1 0 14:12 ? 00:00:00 /usr/sbin/dnsmasq --strict-order
> --bind-interfaces --conf-file= --domain=novalocal
> --pid-file=/var/lib/nova/networks/nova-gw-0f427a46-3f.pid
> --listen-address=192.168.113.1 --except-interface=lo
> --dhcp-range=192.168.113.2,static,120s --dhcp-lease-max=256
> --dhcp-hostsfile=/var/lib/nova/networks/nova-gw-0f427a46-3f.conf
> --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro
> root 6565 6564 0 14:12 ? 00:00:00 /usr/sbin/dnsmasq --strict-order
> --bind-interfaces --conf-file= --domain=novalocal
> --pid-file=/var/lib/nova/networks/nova-gw-0f427a46-3f.pid
> --listen-address=192.168.113.1 --except-interface=lo
> --dhcp-range=192.168.113.2,static,120s --dhcp-lease-max=256
> --dhcp-hostsfile=/var/lib/nova/networks/nova-gw-0f427a46-3f.conf
> --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro
> root 16536 6192 0 14:40 pts/14 00:00:00 grep --color=auto dnsm
>
> Is my nova.conf correct ?
> What's wrong with my configuration ?
> Is there a problem with DNSMASQ ?
>
> I would apreciate any idea !
>
> Regards
>
> --
> Emilien Macchi
> *SysAdmin (Intern)*
> *www.stackops.com* | emilien.mac...@stackops.com** | skype:memilien69
> *
>
> *
>
>  ADVERTENCIA LEGAL 
> Le informamos, como destinatario de este mensaje, que el correo
> electrónico y las comunicaciones por medio de Internet no permiten asegurar
> ni garantizar la confidencialidad de los mensajes transmitidos, así como
> tampoco su integridad o su correcta recepción, por lo que STACKOPS
> TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias.
> Si no consintiese en la utilización del correo electrónico o de las
> comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro
> conocimiento de manera inmediata. Este mensaje va dirigido, de manera
> exclusiva, a su destinatario y contiene información confidencial y sujeta
> al secreto profesional, cuya divulgación no está permitida por la ley. En
> caso de haber recibido este mensaje por error, le rogamos que, de forma
> inmediata, nos lo comunique mediante correo electrónico remitido a nuestra
> atención y proceda a su eliminación, así como a la de cualquier documento
> adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o
> utilización de este mensaje, o de cualquier documento adjunto al mismo,
> cualquiera que fuera su finalidad, están prohibidas por la ley.
>
> * PRIVILEGED AND CONFIDENTIAL 
> We hereby inform you, as addressee of this message, that e-mail and
> Internet do not guarantee the confidentiality, nor the completeness or
> proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L.
> does not assume any liability for those circumstances. Should you not agree
> to the use of e-mail or to communications via Internet, you are kindly
> requested to notify us immediately. This message is intended exclusively
> for the person to whom it is addressed and contains privileged and
> confidential information protected from disclosure by law. If you are not
> the addressee indicated in this message, you should immediately delete it
> and any attachments and notify the sender by reply e-mail. In such case,
> you are hereby notified that any dissemination, distribution, copying or
> use of this message or any attachments, for any purpose, is strictly
> prohibited by law.
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.la

Re: [Openstack] nova state machine simplification and clarification

[Gabe Westmaas]

Also, with this proposal I'd be a lot more interested in exposing task
state as a part of the API eventually.  This is helpful to communicate
whether or not other actions would be allowed in certain states.  For
example, right now we don't allow other actions when a server is
snapshotting, but while the server is being snapshotted, the state is set
to ACTIVE.  With these well thought out states, I think we could more
safely expose those task states, and we would just have to be vigilant
about adding new ones to make sure they make sense to expose to end users.

Gabe

On 5/18/12 10:20 AM, "Mark Washenberger" 
wrote:

>Hi Yun,
>
>This proposal looks very good to me. I am glad you included in it the
>requirement that hard deletes can take place in any vm/task/power state.
>
>I however feel that a similar requirement exists for revert resize. It
>should be possible to issue a RevertResize command for any task_state
>(assuming that a resize is happening or has recently happened and is not
>yet confirmed). The code to support this capability doesn't exist yet,
>but I want to ask you: is it compatible with your proposal to allow
>RevertResize in any task state?
>
>"Yun Mao"  said:
>
>> Hi,
>> 
>> There are vm_states, task_states, and power_states for each VM. The
>> use of them is complicated. Some states are confusing, and sometimes
>> ambiguous. There also lacks a guideline to extend/add new state. This
>> proposal aims to simplify things, explain and define precisely what
>> they mean, and why we need them. A new user-friendly behavior of
>> deleting a VM is also discussed.
>> 
>> A TL;DR summary:
>> * power_state is the hypervisor state, loaded ³bottom-up² from compute
>> worker;
>> * vm_state reflects the stable state based on API calls, matching user
>> expectation, revised ³top-down² within API implementation.
>> * task_state reflects the transition state introduced by in-progress
>>API calls.
>> * ³hard² delete of a VM should always succeed no matter what.
>> * power_state and vm_state may conflict with each other, which needs
>> to be resolved case-by-case.
>> 
>> It's not a definite guide yet and is up for discussion. I'd like to
>> thank vishy and comstud for the early input. comstud: the task_state
>> is different from when you looked at it. It's a lot closer to what's
>> in the current code.
>> 
>> The full text is here and is editable by anyone like etherpad.
>> 
>> 
>>https://docs.google.com/document/d/1nlKmYld3xxpTv6Xx0Iky6L46smbEqg7-SWPu_
>>o6VJws/edit?pli=1
>> 
>> Thanks,
>> 
>> Yun
>> 
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> 
>
>
>
>___
>Mailing list: https://launchpad.net/~openstack
>Post to : openstack@lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp


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

[Openstack] Understanding Network Setup - nova-network

[Alisson Soares Limeira Pontes]

Hello,

i have a setup with a Controller node and two Compute nodes. The topology
is as in the figure attached. I followed the hastexo manual <
http://www.hastexo.com/resources/docs/installing-openstack-essex-20121-ubuntu-1204-precise-pangolin>,
but installing just the modules as described in the figure (attached).
The private network is the nova fixed_range=192.168.22.32/27
The public network is the nova floating_range=10.4.5.32/27
I can launch VMs and access them with no problem.
But from a VM inside the cloud I cannot access any machine from a range
other than the fixed_range (192.168.22.32/27).

Does anyone know what can it be?
How can the controller resolve NAT coming from a node outside the cloud,
while cannot resolve coming from a VM in the cloud?


Also, i would like to understand the nova-network setup using flat dhcp.

br100 in controller assumes the ip 192.168.22.33 (from dhcp i guess,
different from eth1 that is 192.168.22.1).
In the computes, br100 assumes the same ip as the eth1.
All nodes have a vrbr0 with the same ip 192.168.122.1, why '.122.'?


br100 bridges all the VMs inside a physical server and vrbr0 bridges all
br100, is that?

# network specific settings of nova.conf
--network_manager=nova.network.manager.FlatDHCPManager
--public_interface=eth0
--flat_interface=eth1
--flat_network_bridge=br100
--fixed_range=192.168.22.32/27
--floating_range=10.4.5.32/27
--network_size=32
--flat_network_dhcp_start=192.168.22.33
--flat_injected=False
--force_dhcp_release

Ah, i actually do not know if this is the best topology for the setup.

I appreciate any help.

Thanks.

-- 
*Alisson*
___
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] How to access an instance from Dashboard using VNC (password)?

[Jorge Luiz Correa]

Here is the instance full log:

http://pastebin.com/SfmzZ4ET

It is an ubuntu precise cloud image. It doesn't output the password.

Curious...

On Fri, May 18, 2012 at 10:12 AM, Vaze, Mandar wrote:

>   **Ø  **But, from inside dashboard, I couldn't find where to get a
> similar information.
>
> ** **
>
> From Dashboard,  Click “Edit Instance” button on far right, and click on
> “View Log”
>
> Scroll at the end, you’ll see the password.
>
> ** **
>
> -Mandar
>
> ** **
>
> __
> Disclaimer:This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding
>



-- 
- MSc. Correa, J.L.
___
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] [metering] Choice of a messaging queue

[Caitlin Bestler]

Nick Barcet wrote:


> a) the queue must guaranty the delivery of messages.
> To the contrary of monitoring, loss of events may have important billing 
> impacts, it therefore cannot be an option that message be lost.

I don't think absolute reliability is desirable for this application. SCTP 
partial reliability may be a better model.

Ultimately, full reliability requires the ability to block new messages from 
being produced. In the context of billing, that would mean that
a failure of the billing system to consume its messages would result in 
stopping new services from being provided.

Obviously you want to avoid that, but if the billing system fails do you want 
to stop providing services as well? You get no billable time in
either case, but I think providing services without metering for billing will 
keep your customers so that you can bill them for their usage
after you have restarted the billing system.

A partial reliability system would provide a finite amount of storage for 
in-flight messages that probably should be configured for something
Like3x the longest anticipated failure by the consuming entities to drain the 
queue. And it should guarantee that there will be no loss of
Messages without an explicit exception being produced (somethink like 
"EMERGENCY: 2000 billing messages just erased. Interim storage
is fully committed. Where is the consumer?")



___
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 service catalogue has non-core services?

[Nguyen, Liem Manh]

Hi Stackers,

I ran the sample_data.sh script in Keystone and saw that we have populated a 
few more services, such as ec2, dashboard and nova-volume.  Are these meant to 
be "core" services or extension services?  The definition of "core" services is 
defined here:

https://github.com/openstack/identity-api/blob/3d2e8a470733979b792d04bcfe3745731befbe8d/openstack-identity-api/src/docbkx/common/xsd/services.xsd

Extension services should be in the format of :

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] Openstack Essex - Guide for Ubuntu 12.04

[Yi Sun]

On 05/18/2012 03:44 AM, Emilien Macchi wrote:
> Yi,
>
> On Fri, May 18, 2012 at 7:47 AM, Yi Sun  > wrote:
>
> Emilien,
> I'm using your document to setup an environment, so far I have two
> issues, hope you could help out.
> 1. the Linux bridge driver is install/loaded during the install
> process. I tried to remove it by add it into modprobe blacklist,
> but it is still installed after reboot.
>
>
> We don't care about it, we use OVS bridging.
In the INSTALL.Linux file that comes with OVS source code, it has
following comments:
**
 The Open vSwitch datapath requires bridging support
  (CONFIG_BRIDGE) to be built as a kernel module.  (This is common
  in kernels provided by Linux distributions.)  The bridge module
  must not be loaded or in use.  If the bridge module is running
  (check with "lsmod | grep bridge"), you must remove it ("rmmod
  bridge") before starting the datapath.

Anyway, I have find out how to remove bridge and stp. Just use following
commands:

# virsh net-destroy default
# virsh net-autostart --disable default

 
>
> 2. I can start quantum-server manually without any problem, but it
> will fall if it is auto started during system boot up.
>
>
> Do you have logs files ?
>
Do you know how to turn on the log for quantum-server? I did not find
anything in /var/log/quantum.

Thx
Yi
___
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] [metering] Choice of a messaging queue

[Doug Hellmann]

On Fri, May 18, 2012 at 11:40 AM, Eric Windisch wrote:

>
> >
> >
> > a) the queue must guaranty the delivery of messages.
> > To the contrary of monitoring, loss of events may have important billing
> > impacts, it therefore cannot be an option that message be lost.
>
> Losing messages should always be an option, in the extreme cases. If a
> message is undeliverable for an excessive amount of time, it should be
> dropped. Otherwise, you'll need the queuing equivalent of a DBA doing
> periodic cleanup, which isn't very cloudy (or scalable).
>
> I agree that the failure cases here are different than we'd normally see
> with Nova. Timeouts on messages would need to be much higher, and
> potentially disablable (but I do insist that a timeout, even if high,
> should be used).
>
> >
> > b) the client should be able to store and forward.
> > As the load of system or traffic increases, or if the client is
> > temporarily disconnected, client element of the queue should be able to
> > hold messages in a local queue to be emitted as soon as condition permit.
>
> The zeromq driver definitely does this (kind of). It will try and send all
> messages at once via green threads, which is effectively the same thing.
> The nice thing is that with 0mq, when a message is sent, delivery to a peer
> is confirmed.
>
> I think, but may be wrong, that rabbit and qpid essentially do the same
> for store and forward, blocking their green threads until they hit a
> successful connection to the queue, or a timeout. With the amqp drivers,
> the sender only has a confirmation of delivery to the queuing server, not
> to the destination.
>
> One thing the zeromq driver doesn't do is resume sending attempts across a
> service restart. Messages aren't durable in that fashion. This is largely
> because the timeout in Nova does not need to be very large, so there would
> be very little benefit. This goes back to your point in 'a'. Adding this
> feature would be relatively minor, it just wasn't needed in Nova. Actually,
> this limitation would be presumably true of rabbit and qpid as well, in the
> store and forward case.
>
> > c) client must authenticate
> > Only client which hold a shared private key should be able to send
> > messages on the queue.
> > d) queue may support client signing of individual messages
> > Each message should be individually signed by the agent that emits it in
> > order to guaranty non repudiability.  This function can be done by the
> > queue client or by the agent prior to en-queuing of messages
>
>
> There is a Folsom blueprint to add signing and/or encryption to the rpc
> layer.
>

See https://review.stackforge.org/#/c/39/ for a simple implementation.


>
> > d) queue must be highly available
> > the queue servers must be able to support multiple instances running in
> > parallel in order to support continuation of operations with the loss of
> > one server.  This should be achievable without the need to use complex
> > fail over systems and shared storage.
>
>
> > e) queue should be horizontally scalable
> > The scalability of queue servers should be achievable by increasing the
> > number of servers.
>
> d/e are NOT properties of the rabbit (and qpid?) driver today in Nova, but
> it could (should) be made to work this way. You get this with the zeromq
> driver, of course ;)
>
> >
> > Not sure this list is exhaustive or viable, feel free to comment on it,
> > but the real question is: which queue should we be using here?
>
> The OpenStack common rpc mechanism, for sure. I'm biased, but I believe
> that while the zeromq driver is the newest, it is the only driver that
> meets all of the above requirements, except, to the exceptions marked above.
>
> Improving the other implementations should be done, but I don't know of
> anyone committed to that work.
>
> Regards,
> Eric Windisch
> ___
> 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] RFC: Plugin framework draft

[Doug Hellmann]

On Fri, May 18, 2012 at 12:16 PM, Andrew Bogott wrote:

>  On 5/17/12 4:38 PM, Doug Hellmann wrote:
>
>
> 
>
>
> In the wikistatus plugin I notice that you modify the global FLAGS when
> wikistatus.py is imported. Is that the right time to do that, or should it
> happen during the on-load handler in the plugin class? Or maybe even in the
> plugin manager, which could ask the plugin for the new options and then
> modify FLAGS itself. It seems like lots of Nova code modifies FLAGS during
> import, but having an explicit trigger for that (rather than depending on
> import order) seems safer to me.
>
> I don't feel strongly about this -- I'm just following the example set by
> existing Nova code.  Can you think of a corner case where loading it at
> import time would cause problems?  Alternatively, can you think of a corner
> case where we would want a flag to be defined during the magic moment
> /between/ import time and the load callback?
>

I don't know enough about how the flags code works or whether the order of
flag declarations matters. I based my comments on the fact that I have been
burned in the (distant) past by library code that modified global state on
import (Zope) so I avoid the pattern and stick with explicit triggers. If
the flags module supports modification in an indeterminate order, which the
existing convention implies, then what you have should be fine.


>
> I can't think of a case for either, although I have the vague feeling that
> the latter is slightly more possible (if still improbable.)
>
>
>
>  If the entry point for each plugin is given a unique name (instead of
> being called "plugin", as the sharedfs plugin is) we would be able to log
> "loading plugin X" as well as provide options to control which plugins are
> activated. I don't know if that latter idea is a goal or not.
>
> If leaving in that option is free, then I'm all for it.  I'm still a bit
> new to entry points... is the entry-point name a totally arbitrary string?
>

The names need to work as variable names for ConfigParser. I don't think
they can include whitespace or '.' but I'm not sure about other
restrictions.

Also, is supporting unique names the same thing as /requiring/ unique
> names?  Would this ultimately result in us needing a governed, hierarchical
> namespace?
>

You cannot have two entry points with the same name in the same setup.py,
but you can have duplicate names from different setup.py files. Whether you
want to do that depends on how you are using the plugins. In this case, it
shouldn't matter if there are duplicates *unless* we provide an option to
enable/disable plugins.


>
>
>
>  - Two different loading pathways -- is that useful or just confusing?
>>
>
>
>  "One and only one obvious way to do it."
>
>
> OK, I'm convinced.  Outside of the common client, are entrypoints already
> a hard dependency elsewhere in OpenStack such that we don't lose anything
> by requiring them?
>

>From what I have seen all of the projects use setuptools/distribute for
packaging, so using entry points will not add any new dependencies.


>
>
>
>
>> - Should the plugin base class interpose itself between the plugin and
>> python-openstackclient in order to enforce interface versioning?  Is that
>> even possible?
>>
>
>  We could probably figure out a way to do that, but I don't know why you
> would want to. What did you have in mind? Which interface are you worried
> about versioning, the CLI itself?
>
>
> I'm not sure I do want to, but here's my concern:  Right now the common
> client's API for extending the commandline is entirely internal to the
> common client itself.  When I write the sharedfs plugin to make use of that
> same API, I'm treating that internal API as external... and I don't like
> being the only person in the world doing that.
>

The command plugin API for the common CLI is intended to be public and will
be documented. I thought we were going to put the command implementations
in project-specific packages (so that you only got the quantum commands if
you installed the python-quantumclient package, for example). Dean
convinced me we should just put the core stuff into one package, so we went
that route. Extensions can plug directly in. We will document the base
classes within the openstackclient library, but extensions can also write
directly against the cliff framework classes if they do not need any of the
features specific to the unified CLI.

Of course, if the expectation is that that common client API will soon
> become public/documented/frozen anyway, then there's no problem.
>
> -Andrew
>
>
___
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] Using Nova APIs from Javascript: possible?

[javier cerviño]

Due to problems people are facing with CORS we've already included further
description and a video of how the JavaScript portal can be used. We'll
work with the fantastic people from StackOps on the implementation of a
basic HTTP proxy which could be used until we find a solution to implement
CORS in OpenStack components.

In the meantime you can see video, description and code in here:
http://ging.github.com/horizon-js/

On 30 April 2012 13:56, Nick Lothian  wrote:

> I'm testing out the existing  JStack code at the moment.
>
> It's been enjoyable process so far.
> On Apr 30, 2012 7:30 PM, "javier cerviño"  wrote:
>
>> Hi Adrian,
>>
>> I've just seen you submitted your Swift-based CORS implementation to
>> Gerrit. Would you mind if we do the same for Nova, Keystone and Glance? On
>> the other hand, it could be better to wait for its approval because we
>> could apply changes proposed by the reviewers to the rest of components.
>>
>> We've just started to implement Glance API support in jStack, and then I
>> will started with Swift. Is anybody out there who wants to join this
>> challenge? You're welcome to propose changes, write code, and so on. The
>> idea is to develop full OpenStack API in JavaScript, so that community
>> could start working with it.
>>
>> Cheers,
>> Javier.
>>
>> 2012/4/27 javier cerviño 
>>
>>> Hi!
>>>
>>> We have just published the code of the portal in Github. You can find it
>>> in https://github.com/ging/horizon-js. It will only work with Keystone
>>> and Nova if they have CORS implemented.
>>>
>>> Adrian, we didn't make big changes in your code, only logger classes and
>>> a little problem we found with PUT requests in some cases (I have to take a
>>> deeper look into this problem, anyway). We've made tests from  iPhone,
>>> iPad, Safari, Firefox and Chrome and we didn't have any problems. But on
>>> the other hand CORS doesn't work in IE9 with PUT and DELETE methods. Next
>>> week I will test it with Android and Opera browsers.
>>>
>>> Sure! It will be very interesting to submit your code to gerrit!!
>>>
>>> Diego, I will talk with Joaquin to check if we can show you a demo in
>>> two weeks!!
>>>
>>> Cheers,
>>> Javier.
>>>
>>> 2012/4/27 Adrian Smith 
>>>
 I'd be really interested to hear how you go on with the CORS middleware 
 Javier.
 Did it work as-is or did you have to modify it? Was there much effort
 involved in using it with Nova?

 From your experience it sounds like there's decent CORS support in
 browsers now so it's probably time to submit this change to gerrit.

 Adrian


 2012/4/27 Diego Parrilla Santamaría <
 diego.parrilla.santama...@gmail.com>

> Awesome Javier
>
> Anxiously waiting for a meeting with you guys to see your progress!
>
> Cheers
> Diego
>  --
> Diego Parrilla
> *CEO*
> *www.stackops.com | * diego.parri...@stackops.com** | +34 649 94 43 29|
> skype:diegoparrilla*
> * 
> *
>
> *
>
>
>
>
> On Thu, Apr 26, 2012 at 9:50 AM, javier cerviño 
> wrote:
>
>> Hi all,
>>
>> I'm glad to hear that there's a lot of interest in the implementation
>> of Openstack JavaScript clients. Actually, in my group we're
>> developing a "single page" application developed entirely in
>> JavaScript, that widely supports Nova and Keystone APIs.  This work is
>> part of a European Project called FI-Ware (http://www.fi-ware.eu/),
>> in
>> which we are currently using Openstack APIs.
>>
>> We've modified Nova and Keystone installations by adding CORS support.
>> We did it by implementing a kind of filter on their APIs. For doing
>> this we used Adam's implementation
>> (https://github.com/adrian/swift/tree/cors), and we adapted it to
>> Nova
>> and Keystone components. We also developed a JS library
>> (http://ging.github.com/jstack/) that can be used by both web and
>> Node.js applications, for example. This library aims to provide same
>> functionalities as python-novaclient, adding support for Keystone API.
>>
>> And finally we are copying Openstack horizon functionality, using JS
>> library and other frameworks such as jQuery and Backbone.js to
>> implement the web application. This web application is an
>> "early-stage" work, but we will probably publish it by the end of this
>> week. I will let you know the github link.
>>
>> We didn't find much problems with CORS implementation and support in
>> browsers.  For the time being, according to our experiments, the only
>> web browser that is not usable at all with this technology is Internet
>> Explorer, but we have tried it in Google Chrome, Safari and Firefox as
>> well and we didn't have any problems.
>>
>> Cheers,
>> Javier Cerviño.
>>
>> On 26 April 2012 06:28, Nick Lothian  wrote:
>>>

Re: [Openstack] Openstack Essex - Guide for Ubuntu 12.04

[Emilien Macchi]

Hi,

On Fri, May 18, 2012 at 7:13 PM, Yi Sun  wrote:

>  On 05/18/2012 03:44 AM, Emilien Macchi wrote:
>
> Yi,
>
> On Fri, May 18, 2012 at 7:47 AM, Yi Sun  wrote:
>
>> Emilien,
>> I'm using your document to setup an environment, so far I have two
>> issues, hope you could help out.
>> 1. the Linux bridge driver is install/loaded during the install process.
>> I tried to remove it by add it into modprobe blacklist, but it is still
>> installed after reboot.
>>
>
> We don't care about it, we use OVS bridging.
>
> In the INSTALL.Linux file that comes with OVS source code, it has
> following comments:
>
> **
>  The Open vSwitch datapath requires bridging support
>   (CONFIG_BRIDGE) to be built as a kernel module.  (This is common
>   in kernels provided by Linux distributions.)  The bridge module
>   must not be loaded or in use.  If the bridge module is running
>   (check with "lsmod | grep bridge"), you must remove it ("rmmod
>   bridge") before starting the datapath.
>
> 
> Anyway, I have find out how to remove bridge and stp. Just use following
> commands:
>
> # virsh net-destroy default
> # virsh net-autostart --disable default
>
> Ok. Thank's for information.



>
>
>   2. I can start quantum-server manually without any problem, but it will
>> fall if it is auto started during system boot up.
>>
>
You should modify the init script with
--*logfile*=/var/log/quantum/quantum-server.log
flag.

Regards




> Do you have logs files ?
>
>   Do you know how to turn on the log for quantum-server? I did not find
> anything in /var/log/quantum.
>
> Thx
> Yi
>



-- 
Emilien Macchi
*SysAdmin (Intern)*
*www.stackops.com* | emilien.mac...@stackops.com** | skype:memilien69
*

*

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

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

[Doug Davis]

Vish wrote on 05/17/2012 02:18:19 PM:
...
> 3 Feature Branch in Core
> 
> We are doing some work to support Feature and Subsystem branches in 
> our CI system. 3rd party apis could live in a feature branch so that
> they can be tested using our CI infrastructure. This is very similar
> to the above solution, and gives us a temporary place to do 
> development until the internal apis are more stable. Changes to 
> internal apis and 3rd party apis could be done concurrently in the 
> branch and tested. 

can you elaborate on this last sentence?  When you say "changes to 
internal
apis" do you mean "in general" or only when in the context of those
3rd party APIs needing a change?  I can't see the core developers wanting
to do internal API changes in a 3rd party api branch.  I would expect
3rd party api branches to mainly include just stuff that sits on top of
the internal APIs and (hopefully very few) internal API tweaks.
Which to me means that these 3rd party API branches should be continually 
rebased off of the trunk to catch breaking changes immediately.

If I understand it correctly, of those options, I like option 3 because 
then the CI stuff will detect breakages in the 3rd party APIs right away
and not until some later date when it'll be harder to fix (or undo) those
internal API changes.

-Doug Davis
d...@us.ibm.com___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Openstack Essex - Guide for Ubuntu 12.04

[Yi Sun]

On 05/18/2012 10:51 AM, Emilien Macchi wrote:
>
>  
>>
>> 2. I can start quantum-server manually without any problem,
>> but it will fall if it is auto started during system boot up.
>>
>
> You should modify the init script with
> --/logfile/=/var/log/quantum/quantum-server.log flag.
Ok, let me give it a try. thanks
Yi
___
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] RFC - dynamically loading virt drivers

[Jay Pipes]

On 05/17/2012 06:38 PM, Vishvananda Ishaya wrote:

On May 17, 2012, at 1:52 PM, Sean Dague wrote:


What I'm mostly looking for is comments on approach. Is importutils the 
prefered way to go about this (which is the nova.volume approach) now, or 
should this be using utils.LazyPluggable as is in nova.db.api, or some other 
approach entirely? Comments, redirections, appreciated.


-1 to LazyPluggable

So we already have plugabillity by just specifying a different compute_driver 
config option.  I don't like that we defer another level in compute and call 
get_connection.  IMO the best cleanup would be to remove the get_connection 
altogether and just construct the driver directly based on compute_driver.

The main issue with changing this is breaking existing installs.

So I guess this would be my strategy:

a) remove get_connection from the drivers (and just have it construct the 
'connection' class directly)
b) modify the global get_connection to construct the drivers for backwards 
compatibilty
c) modify the documentation to suggest changing drivers by specifying the full 
path to the driver instead of connection_type
d) rename the connection classes to something reasonable representing drivers 
(libvirt.driver:LibvirtDriver() vs libvirt.connection.LibvirtConnection)
e) bonus points if it could be done with a short path for ease of use 
(compute_driver=libvirt.LibvirtDriver vs 
compute_driver=nova.virt.libvirt.driver.LibvirtDriver)


+1

-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] Openstack Essex - Guide for Ubuntu 12.04

[Yi Sun]

BTW-- now, I got a new problem:
1. the network is up
2. VM is up.

But I can not access the VM through anything (now console, vnc and
network). I saw you have sent another e-mail for the interface issue
inside VM.  How did you access the VM console?
Thanks
Yi


On 05/18/2012 10:51 AM, Emilien Macchi wrote:
>
>  
>>
>> 2. I can start quantum-server manually without any problem,
>> but it will fall if it is auto started during system boot up.
>>
>
> You should modify the init script with
> --/logfile/=/var/log/quantum/quantum-server.log flag.

___
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 state machine simplification and clarification

[Yun Mao]

Hi Mark,

I haven't looked at resize related API calls very closely. But what
you are saying makes sense. revert_resize() should be able to preempt
an existing resize() call, which might get stuck. I'm not clear how
the leftovers will be garbage collected yet.

Yun

On Fri, May 18, 2012 at 10:20 AM, Mark Washenberger
 wrote:
> Hi Yun,
>
> This proposal looks very good to me. I am glad you included in it the 
> requirement that hard deletes can take place in any vm/task/power state.
>
> I however feel that a similar requirement exists for revert resize. It should 
> be possible to issue a RevertResize command for any task_state (assuming that 
> a resize is happening or has recently happened and is not yet confirmed). The 
> code to support this capability doesn't exist yet, but I want to ask you: is 
> it compatible with your proposal to allow RevertResize in any task state?
>
> "Yun Mao"  said:
>
>> Hi,
>>
>> There are vm_states, task_states, and power_states for each VM. The
>> use of them is complicated. Some states are confusing, and sometimes
>> ambiguous. There also lacks a guideline to extend/add new state. This
>> proposal aims to simplify things, explain and define precisely what
>> they mean, and why we need them. A new user-friendly behavior of
>> deleting a VM is also discussed.
>>
>> A TL;DR summary:
>> * power_state is the hypervisor state, loaded “bottom-up” from compute
>> worker;
>> * vm_state reflects the stable state based on API calls, matching user
>> expectation, revised “top-down” within API implementation.
>> * task_state reflects the transition state introduced by in-progress API 
>> calls.
>> * “hard” delete of a VM should always succeed no matter what.
>> * power_state and vm_state may conflict with each other, which needs
>> to be resolved case-by-case.
>>
>> It's not a definite guide yet and is up for discussion. I'd like to
>> thank vishy and comstud for the early input. comstud: the task_state
>> is different from when you looked at it. It's a lot closer to what's
>> in the current code.
>>
>> The full text is here and is editable by anyone like etherpad.
>>
>> https://docs.google.com/document/d/1nlKmYld3xxpTv6Xx0Iky6L46smbEqg7-SWPu_o6VJws/edit?pli=1
>>
>> Thanks,
>>
>> Yun
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Openstack] nova state machine simplification and clarification

[Yun Mao]

Gabe,

There is a flag reclaim_instance_interval on API. If it's set to 0 (by
default), everything is hard_delete. Otherwise, it's soft_delete. and
will be automatically hard deleted after the configured interval.
There is also an API extension to as force_delete, which is hard
delete no matter what.

Right now I *think* task_state is already exposed via some API
(extension?). Otherwise the dashboard won't be able to see it.

Thanks,

Yun


On Fri, May 18, 2012 at 12:26 PM, Gabe Westmaas
 wrote:
> Also, with this proposal I'd be a lot more interested in exposing task
> state as a part of the API eventually.  This is helpful to communicate
> whether or not other actions would be allowed in certain states.  For
> example, right now we don't allow other actions when a server is
> snapshotting, but while the server is being snapshotted, the state is set
> to ACTIVE.  With these well thought out states, I think we could more
> safely expose those task states, and we would just have to be vigilant
> about adding new ones to make sure they make sense to expose to end users.
>
> Gabe
>
> On 5/18/12 10:20 AM, "Mark Washenberger" 
> wrote:
>
>>Hi Yun,
>>
>>This proposal looks very good to me. I am glad you included in it the
>>requirement that hard deletes can take place in any vm/task/power state.
>>
>>I however feel that a similar requirement exists for revert resize. It
>>should be possible to issue a RevertResize command for any task_state
>>(assuming that a resize is happening or has recently happened and is not
>>yet confirmed). The code to support this capability doesn't exist yet,
>>but I want to ask you: is it compatible with your proposal to allow
>>RevertResize in any task state?
>>
>>"Yun Mao"  said:
>>
>>> Hi,
>>>
>>> There are vm_states, task_states, and power_states for each VM. The
>>> use of them is complicated. Some states are confusing, and sometimes
>>> ambiguous. There also lacks a guideline to extend/add new state. This
>>> proposal aims to simplify things, explain and define precisely what
>>> they mean, and why we need them. A new user-friendly behavior of
>>> deleting a VM is also discussed.
>>>
>>> A TL;DR summary:
>>> * power_state is the hypervisor state, loaded ³bottom-up² from compute
>>> worker;
>>> * vm_state reflects the stable state based on API calls, matching user
>>> expectation, revised ³top-down² within API implementation.
>>> * task_state reflects the transition state introduced by in-progress
>>>API calls.
>>> * ³hard² delete of a VM should always succeed no matter what.
>>> * power_state and vm_state may conflict with each other, which needs
>>> to be resolved case-by-case.
>>>
>>> It's not a definite guide yet and is up for discussion. I'd like to
>>> thank vishy and comstud for the early input. comstud: the task_state
>>> is different from when you looked at it. It's a lot closer to what's
>>> in the current code.
>>>
>>> The full text is here and is editable by anyone like etherpad.
>>>
>>>
>>>https://docs.google.com/document/d/1nlKmYld3xxpTv6Xx0Iky6L46smbEqg7-SWPu_
>>>o6VJws/edit?pli=1
>>>
>>> Thanks,
>>>
>>> Yun
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>>___
>>Mailing list: https://launchpad.net/~openstack
>>Post to     : openstack@lists.launchpad.net
>>Unsubscribe : https://launchpad.net/~openstack
>>More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Openstack] RFC - dynamically loading virt drivers

[Sean Dague]

On 05/17/2012 06:38 PM, Vishvananda Ishaya wrote:
>

So we already have plugabillity by just specifying a different compute_driver 
config option.  I don't like that we defer another level in compute and call 
get_connection.  IMO the best cleanup would be to remove the get_connection 
altogether and just construct the driver directly based on compute_driver.

The main issue with changing this is breaking existing installs.

So I guess this would be my strategy:

a) remove get_connection from the drivers (and just have it construct the 
'connection' class directly)
b) modify the global get_connection to construct the drivers for backwards 
compatibilty
c) modify the documentation to suggest changing drivers by specifying the full 
path to the driver instead of connection_type
d) rename the connection classes to something reasonable representing drivers 
(libvirt.driver:LibvirtDriver() vs libvirt.connection.LibvirtConnection)
e) bonus points if it could be done with a short path for ease of use 
(compute_driver=libvirt.LibvirtDriver vs 
compute_driver=nova.virt.libvirt.driver.LibvirtDriver)


On point c), is the long term view that .conf options are going to 
specify full class names? It seems like this actually gets kind of 
confusing to admins.



What are your thoughts on the following approach, which is related, but 
a little different?


a) have compute_driver take a module name in nova.virt. which is loaded 
with some standard construction method that all drivers would implement 
in their __init__.py. Match all existing module names to connection_type 
names current in use. Basically just jump to e, but also make all 
drivers conform some factory interface so "libvirt" is actually enough 
to get you nova.virt.libvirt.connect()


b) if compute_driver is not specified, use connection_type, but spit out 
a deprecation warning that the option is going away. (Removed fully in 
G). Because compute_drivers map to existing connection_types this just 
works with only a little refactoring in the drivers.


c) remove nova/virt/connection.py

The end result is that every driver is a self contained subdir in 
nova/virt/DRIVERNAME/.



* one test fails for Fake in test_virt_drivers, but only when it's run as the 
full unit test, not when run on it's own. It looks like it has to do with 
FakeConnection.instance() caching, which actually confuses me a bit, as I would 
have assumed one unit test file couldn't affect another (i.e. they started a 
clean env each time).


Generally breakage like this is due to some global state that is not cleaned 
up, so if FakeConnection is caching globally, then this could happen.


It is keeping global state, I'll look at fixing that independently.

-Sean

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


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

Re: [Openstack] Nova subsystem branches and feature branches

[Mark McLoughlin]

Hey,

Hi On Mon, 2012-05-14 at 14:51 +0200, Thierry Carrez wrote:
> James E. Blair wrote:
> > Vish, Thierry, and I spent some time together this week at UDS trying to
> > reconcile their needs and your suggestions.  I believe Thierry is going
> > to write that up and send it to the list soon.
> 
> While at UDS we took some time to discuss a subsystem branch models that
> would work for Vish (PTL/developer), Jim (CI/infra) and me (release
> time). We investigated various models and came up with "Vish's
> supercombo subsystem model" (see model 5 at the bottom of
> http://wiki.openstack.org/SubsystemsBranchModel for a graph).

It's great you guys got to dig into this in detail, see inline for
thoughts

> In this model:
> 
> * You have a "master" branch which contains release-ready features and
> bugfixes. Milestones are cut directly from it.
> 
> * Subsystem branches with area experts are used wherever possible. The
> subsystem maintainer should maintain this branch so that it can directly
> be merged into master when "ready" (all or nothing). Subsystem
> maintainers are allowed to propose a merge commit to master.

Yep, except I still think having the subsystem maintainer create and
propose a merge commits will be a scaling issue in this process.

To walk through an example, you've got some work on a subsystem branch:

  o--o--o  <- sub
 /
 o--o--o--o--o--o  <- master

The subsystem maintainer is ready for this to be merged into master, so
creates a merge commit:

  o--o--o-o  <- sub
 /   /
 o--o--o--o--o--o  <- master

and proposes that. However, there's another subsystem branch merge
already queued which gets merged first. This merge isn't a fast-forward,
but Gerrit is able to do it since there is no merge conflicts:

  o--o--o-o  <- sub
 /   /
 o--o--o--o--o--o--o  <- master
  \\  /
   o--o--o--o+  <- sub2

Now, the "sub" merge commit proposal is accepted but fails to merge
because of merge conflicts. The maintainer creates another merge and
proposes that:

  o--o--o-o--o  <- sub
 /   /  /
 o--o--o--o--o--o--o  <- master
  \\  /
   o--o--o--o+  <- sub2

and that gets approved quickly and merged as a fast-forward:

  o--o--o-o-+  
 /   /   \
 o--o--o--o--o--o--o--o  <- sub  <- master
  \\  /
   o--o--o--o+  <- sub2


The alternative is that the maintainer of the master branch is creating
the merge commits and resolving conflicts (like Linus):

  o--o--o  <- sub
 /
 o--o--o--o--o--o  <- master
  \
   o--o--o  <- sub2

The two subsystem maintainers send their pull requests and the master
maintainer merges them in the same order:

  o--o--o---+  <- sub
 /   \
 o--o--o--o--o--o--o--o  <- master
  \   /
   o--o--o---+  <- sub2

If you compare to the result when gerrit is merging, we have two less
merge commits with this model and one less subsystem maintainer
roundtrip.

> * Bugfixes get proposed directly to master

I think bugfixes relevant to a particular subsystem need to go through
master, since that's where the domain experts are doing reviews.

> * Features can be directly proposed to master, although they should be
> redirected to a subsystem branch when one exists for that area
> 
> * Only features that are release-ready should be accepted into master.
> Final approval of merges on master will therefore be limited to the
> corresponding project release team.

Woah, I didn't see that one coming :-)

Deciding what is ready for merging is the project leader's job IMHO.

> * Milestones are directly cut from master. A couple of days before each
> milestone, we will have a soft freeze during which only bugfixes are merged
> 
> * Between the last milestone and RC1, a soft freeze is enforced during
> which only bugfixes are merged (can last for a couple weeks)
> 
> * In order to limit the master freeze, at RC1 and until release, a
> specific release branch is cut from master. That specific release branch
> directly gets release-critical (targeted) bugfixes, and gets merged back
> into master periodically.

This release branch thing (to avoid cherry-picking) is probably workable
since the time between RC1 and release is relatively short, but I think
we'll want to eventually to get to a point where the subsystem branches
have alleviate much of the pain involved with just locking down master
between the last milestone and release.

> Benefits of this model:
> * We enable subsystems, which for larger projects let people specialize
> on an area of the code and avoids having to be an expert in all things
> * Subsystems become a staging ground for features that are not release-ready

This sets off loud alarm bells for me.

A subsystem maintainer should never merge anything which could not be
merged into master without more work. Without that rule, the subsystem
branch gets blocked from merging into master until a feature developer
finish

Re: [Openstack] [metering] Do we need an API and storage?

[Francis J. Lacoste]

On 12-05-17 08:14 AM, Doug Hellmann wrote:
> 
> 
> On Thu, May 17, 2012 at 5:47 AM, Nick Barcet  > wrote:
> 
> On 05/17/2012 11:13 AM, Loic Dachary wrote:
> > On 05/16/2012 11:00 PM, Francis J. Lacoste wrote:
> >>
> >> I'm now of the opinion that we exclude storage and API from the
> >> metering project scope. Let's just focus on defining a metering
> >> message format, bus, and maybe a client-library to make it easy to
> >> write metering consumers.
> 
> 
> The plan, as I understand it, is to ensure that all metering messages
> appear on a common bus using a documented format. Deployers who do not
> want the storage system and REST API will not need to use it, and can
> set up their own clients to listen on that bus. I'm not sure how much of
> a client library is needed, since the bus is AMQP and the messages are
> JSON, both of which have standard libraries in most common languages.

Like Thierry Carrez mentioned, the main use for a library was to handle
validation of message signature in a handy fashion. Bug I agree that
this client library would just be a thin convenience wrapper around the
bus protocol.


> 
> >
> > Getting rid of the storage imposes a constraint on the billing system
> > : it must make 100% sure that once a message is consumed it will be
> > reliably archived. It also adds a constraint on the chosen bus : it
> > must be able to retain all messages for as long as a consumer needs,
> > which may be days or weeks. Or it adds a constraint on the billing
> > system which must make 100% sure it will consume all relevant
> > messages the bus at all times before they expire.
> 
> 
> That's exactly right. It will be easier for me to bridge between our two
> systems by pulling a day's worth of details from the ceilometer API and
> storing them in the billing system using a batch job, rather than trying
> to ensure that the billing database performs well enough to record the
> information in real time. My goal is to not have to change the billing
> system at all.

That's good information to have. Which means that a REST API + storage
component definitively has some values for some integration cases.

-- 
Francis J. Lacoste
francis.laco...@canonical.com



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] RFC - dynamically loading virt drivers

[Doug Hellmann]

On Fri, May 18, 2012 at 3:08 PM, Sean Dague wrote:

> On 05/17/2012 06:38 PM, Vishvananda Ishaya wrote:
> >
>
>> So we already have plugabillity by just specifying a different
>> compute_driver config option.  I don't like that we defer another level in
>> compute and call get_connection.  IMO the best cleanup would be to remove
>> the get_connection altogether and just construct the driver directly based
>> on compute_driver.
>>
>> The main issue with changing this is breaking existing installs.
>>
>> So I guess this would be my strategy:
>>
>> a) remove get_connection from the drivers (and just have it construct the
>> 'connection' class directly)
>> b) modify the global get_connection to construct the drivers for
>> backwards compatibilty
>> c) modify the documentation to suggest changing drivers by specifying the
>> full path to the driver instead of connection_type
>> d) rename the connection classes to something reasonable representing
>> drivers (libvirt.driver:LibvirtDriver(**) vs libvirt.connection.**
>> LibvirtConnection)
>> e) bonus points if it could be done with a short path for ease of use
>> (compute_driver=libvirt.**LibvirtDriver vs compute_driver=nova.virt.**
>> libvirt.driver.LibvirtDriver)
>>
>
> On point c), is the long term view that .conf options are going to specify
> full class names? It seems like this actually gets kind of confusing to
> admins.
>
>
> What are your thoughts on the following approach, which is related, but a
> little different?
>
> a) have compute_driver take a module name in nova.virt. which is loaded
> with some standard construction method that all drivers would implement in
> their __init__.py. Match all existing module names to connection_type names
> current in use. Basically just jump to e, but also make all drivers conform
> some factory interface so "libvirt" is actually enough to get you
> nova.virt.libvirt.connect()
>

Andrew Bogott is working on a common plugin architecture. Under that system
plugins will have well-known, but short names and be loaded using
setuptools entry points (allowing them to be named independently of their
code/filesystem layout and packaged and installed separately from
nova). Could the drivers be loaded from these plugins?


>
> b) if compute_driver is not specified, use connection_type, but spit out a
> deprecation warning that the option is going away. (Removed fully in G).
> Because compute_drivers map to existing connection_types this just works
> with only a little refactoring in the drivers.
>
> c) remove nova/virt/connection.py
>
> The end result is that every driver is a self contained subdir in
> nova/virt/DRIVERNAME/.
>
>
>  * one test fails for Fake in test_virt_drivers, but only when it's run as
>>> the full unit test, not when run on it's own. It looks like it has to do
>>> with FakeConnection.instance() caching, which actually confuses me a bit,
>>> as I would have assumed one unit test file couldn't affect another (i.e.
>>> they started a clean env each time).
>>>
>>
>> Generally breakage like this is due to some global state that is not
>> cleaned up, so if FakeConnection is caching globally, then this could
>> happen.
>>
>
> It is keeping global state, I'll look at fixing that independently.
>
>
>-Sean
>
> --
> Sean Dague
> IBM Linux Technology Center
> email: sda...@linux.vnet.ibm.com
> alt-email: slda...@us.ibm.com
>
>
> __**_
> Mailing list: 
> https://launchpad.net/~**openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : 
> https://launchpad.net/~**openstack
> More help   : 
> https://help.launchpad.net/**ListHelp
>
___
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] [metering] Do we need an API and storage?

[Francis J. Lacoste]

On 12-05-18 05:27 AM, Thierry Carrez wrote:
> You can certainly architect it in a way so that storage and API are
> optional: expose metering messages on the bus, and provide an
> optionally-run aggregation component that exposes a REST API (and that
> would use the metering-consumer client library). That would give
> deployers the option to poll via REST or implement their own alternate
> aggregation using the metering-consumer client lib, depending on the
> system they need to integrate with.
> 
> Having the aggregation component clearly separate and optional will
> serve as a great example of how it could be done (and what are the
> responsibilities of the aggregation component). I would still do a
> (minimal) client library to facilitate integration, but maybe that's
> just me :)

Right, I like this approach very much.

The main thing I'm worried about is that we are building a system that
has no use in _itself_. It's all about enabling integration in
third-party billing system, but we aren't building such an integration
as part of this project.

We could easily implement something that lacks our focus. Maybe, that's
an argument for building a simple billing app as part of OpenStack as a
proof of concept that the metering system can be integrated.

Sure, interested parties will try to integrate it once we have early
versions of it, but that still increase the feedback cycle on our
API/architecture hypotheses.

Cheers

-- 
Francis J. Lacoste
francis.laco...@canonical.com



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [metering] Do we need an API and storage?

[Francis J. Lacoste]

On 12-05-18 04:49 PM, Francis J. Lacoste wrote:
>>  On 12-05-17 08:14 AM, Doug Hellmann wrote:
>> > The plan, as I understand it, is to ensure that all metering messages
>> > appear on a common bus using a documented format. Deployers who do not
>> > want the storage system and REST API will not need to use it, and can
>> > set up their own clients to listen on that bus. I'm not sure how much of
>> > a client library is needed, since the bus is AMQP and the messages are
>> > JSON, both of which have standard libraries in most common languages.

> Like Thierry Carrez mentioned, the main use for a library was to handle
> validation of message signature in a handy fashion. Bug I agree that
> this client library would just be a thin convenience wrapper around the
> bus protocol.
> 

Of course, it was you in your reply to Thierry that mentioned this :-)


-- 
Francis J. Lacoste
francis.laco...@canonical.com



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [metering] Do we need an API and storage?

[Doug Hellmann]

On Fri, May 18, 2012 at 4:53 PM, Francis J. Lacoste <
francis.laco...@canonical.com> wrote:

> On 12-05-18 05:27 AM, Thierry Carrez wrote:
> > You can certainly architect it in a way so that storage and API are
> > optional: expose metering messages on the bus, and provide an
> > optionally-run aggregation component that exposes a REST API (and that
> > would use the metering-consumer client library). That would give
> > deployers the option to poll via REST or implement their own alternate
> > aggregation using the metering-consumer client lib, depending on the
> > system they need to integrate with.
> >
> > Having the aggregation component clearly separate and optional will
> > serve as a great example of how it could be done (and what are the
> > responsibilities of the aggregation component). I would still do a
> > (minimal) client library to facilitate integration, but maybe that's
> > just me :)
>
> Right, I like this approach very much.
>
> The main thing I'm worried about is that we are building a system that
> has no use in _itself_. It's all about enabling integration in
> third-party billing system, but we aren't building such an integration
> as part of this project.
>

Well, several of us actually *are* building such integration systems at the
same time that we are building ceilometer. That's where these requirements
are coming from! :-) I don't expect to be releasing all of the code for
that integration, but I will release what I can and I am happy to talk
about the general requirements and constraints for the rest on the list to
help with the design of ceilometer.


> We could easily implement something that lacks our focus. Maybe, that's
> an argument for building a simple billing app as part of OpenStack as a
> proof of concept that the metering system can be integrated.
>

I would not object if you wanted to do that, but I have a high degree of
confidence that we can produce something usable and useful without going
that far.


>
> Sure, interested parties will try to integrate it once we have early
> versions of it, but that still increase the feedback cycle on our
> API/architecture hypotheses.
>

I could shorten that feedback cycle if folks would do code reviews for the
outstanding items at
https://review.stackforge.org/#/q/status:open+project:stackforge/ceilometer,n,zso
I could stand up a copy of what has already been implemented. ;-)

In all seriousness, it seems reasonable for us to concentrate on the
front-end pieces (collecting and storing) for this release, and build a
"good enough" API service to retrieve data. Even if that means I end up
having to retrieve all of the raw records and process them myself, I can
still get my project done as a proof of concept and we can refine the API
as we go along using the experience I (and others) gain this time around.

Doug
___
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] [Dashboard] Can't access images/snapshots

[Vishvananda Ishaya]

i think you need to update your endpoint to:

http://192.168.111.202:8776/v1/%(tenant_id)s

note that the volume endpoint should be v1 not v2

Vish

On May 18, 2012, at 6:01 AM, Leander Bessa Beernaert wrote:

> Ok, i've removed swift from the endpoints and services. Nova volumes is 
> running with a 2GB file as volume on disk and the log files seem ok. However, 
> i still keep getting this error for volume-list 
> (http://paste.openstack.org/show/17991/) and this error for snapshot-list 
> (http://paste.openstack.org/show/17992/).
> 
> On Thu, May 17, 2012 at 7:39 PM, Gabriel Hurley  
> wrote:
> Two points:
> 
>  
> 
> Nova Volume is a required service for Essex Horizon. That’s documented, and 
> there are plans to make it optional for Folsom. However, not having it should 
> yield a pretty error message in the dashboard, not a KeyError in novaclient, 
> which leads me to my second point…
> 
>  
> 
> It sounds like your Keystone service catalog is misconfigured. If you’re 
> seeing Swift (AKA Object Store) in the dashboard, that means it’s in your 
> keystone service catalog. Swift is a completely optional component and is 
> triggered on/off by the presence of an “object-store” endpoint returned by 
> Keystone.
> 
>  
> 
> I’d check and make sure the services listed in Keystone’s catalog are correct 
> for what’s actually running in your environment.
> 
>  
> 
> All the best,
> 
>  
> 
> -  Gabriel
> 
>  
> 
> From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net 
> [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On 
> Behalf Of Leander Bessa Beernaert
> Sent: Thursday, May 17, 2012 8:45 AM
> To: Sébastien Han
> Cc: openstack@lists.launchpad.net
> Subject: Re: [Openstack] [Dashboard] Can't access images/snapshots
> 
>  
> 
> Now i made sure nova-volume is installed and running. I still keep running 
> into the same problem. It also happens from the command line tool. This is 
> the output produced > http://paste.openstack.org/show/17929/
> 
> On Thu, May 17, 2012 at 11:17 AM, Leander Bessa Beernaert 
>  wrote:
> 
> I have no trouble from the command line. One thing i find peculiar is that i 
> haven't installed swift and nova-volume yet and they show up as enabled 
> services in the dashboard. Is that normal?
> 
>  
> 
> On Wed, May 16, 2012 at 11:39 PM, Sébastien Han  
> wrote:
> 
> Hi,
> 
>  
> 
> Do you also have an error when retrieving from the command line?
> 
> 
> 
> ~Cheers!
> 
> 
> 
> 
> On Wed, May 16, 2012 at 5:38 PM, Leander Bessa Beernaert 
>  wrote:
> 
> Hello,
> 
>  
> 
> I keep running into this error when i try to list the images/snapshot in 
> dashboard: http://paste.openstack.org/show/17820/
> 
>  
> 
> This is my local_settings.py file: http://paste.openstack.org/show/17822/ , 
> am i missing something?
> 
>  
> 
> Regards,
> 
>  
> 
> Leander 
> 
>  
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
>  
> 
>  
> 
>  
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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

[Openstack] rant on the resize API implementation

[Yun Mao]

According to 
http://docs.openstack.org/api/openstack-compute/2/content/Resize_Server-d1e3707.html

"The resize operation converts an existing server to a different
flavor, in essence, scaling the server up or down. The original server
is saved for a period of time to allow rollback if there is a problem.
All resizes should be tested and explicitly confirmed, at which time
the original server is removed. All resizes are automatically
confirmed after 24 hours if they are not explicitly confirmed or
reverted."

Whether this feature is useful in the cloud is not the scope of the
thread. I'd like to discuss the implementation. In the current
implementation, it will first cast to scheduler to decide the
destination host, then shutdown the VM, copy the disk image to the
dest, start the new VM, and wait for a user confirmation, then either
delete the old VM image as confirmation or delete the new VM as
revert.

Problem 1: the image is copied from source to destination via scp/ssh.
This probably means that you will need a password-less ssh private key
setup among all compute nodes. It seems like a security problem.

Problem 2: resize needs to boot up VMs too, once at the destination,
once at the source in case of revert. They have their own
implementation, and look slightly different from spawn which is the
default create instance call.

Problem 3: it's not clear what the semantics is when there are volumes
attached to the VM before resize. What should happen to the VM?

Without the resize API, a user can still do that by first make a
snapshot of a VM, then start a new VM with that snapshot. It's not
that much of a difference. If getting rid of resize is not an option,
I wonder if it makes more sense to implement the resize function by
calling the snapshot and create compute APIs instead of doing it in
the driver.

Thanks,

Yun

___
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] Third Party APIs

[Vishvananda Ishaya]

On May 18, 2012, at 11:00 AM, Doug Davis wrote:

> 
> Vish wrote on 05/17/2012 02:18:19 PM:
> ... 
> > 3 Feature Branch in Core 
> > 
> > We are doing some work to support Feature and Subsystem branches in 
> > our CI system. 3rd party apis could live in a feature branch so that
> > they can be tested using our CI infrastructure. This is very similar
> > to the above solution, and gives us a temporary place to do 
> > development until the internal apis are more stable. Changes to 
> > internal apis and 3rd party apis could be done concurrently in the 
> > branch and tested. 
> 
> can you elaborate on this last sentence?  When you say "changes to internal 
> apis" do you mean "in general" or only when in the context of those 
> 3rd party APIs needing a change?  I can't see the core developers wanting 
> to do internal API changes in a 3rd party api branch.  I would expect 
> 3rd party api branches to mainly include just stuff that sits on top of 
> the internal APIs and (hopefully very few) internal API tweaks. 
> Which to me means that these 3rd party API branches should be continually 
> rebased off of the trunk to catch breaking changes immediately.


I agree.  I was suggesting that initially internal api changes could be made in 
the feature branch in order to enable the new top level apis, tested, and then 
proposed for merging back into core.  This is generally easier than trying to 
make changes in two separate repositories to support a feature (as we have to 
do frequently in openstack).

> 
> If I understand it correctly, of those options, I like option 3 because 
> then the CI stuff will detect breakages in the 3rd party APIs right away 
> and not until some later date when it'll be harder to fix (or undo) those 
> internal API changes.

Well it won't automatically do so, but it should alllow for an easy way for the 
third party developers to run ci tests without setting up their own 
infrastructure.

Vish

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

[Openstack] [Openstack-qa-team] Summary of QA Weekly Status meeting held on 5/17

[Venkatesan, Ravikumar]

The QA team had its weekly IRC meeting today. Here is a summary of the progress 
 and decisions coming out of the meeting.



* Progress

  Tempest tests for Swift are in review.





* Decisions made (Jay is out, Daryl could not make it and David is on vacation)

   None



* Outstanding Items/Issues

Finalize getting smoke test branch in Gerrit

Rohit to check-in Jmeter performance tests.

Swift tests to be reviewed and merged.

Tempest concurrent runs enhancement

 limited number of core reviewers/approvers slows down the review process

Covering tests for completed Folsom blueprints

Multi-node test  environment for Folsom testing(including stability).





* Outstanding Reviews

  Community, please feel free to provide code reviews on outstanding Tempest 
merge proposals:



   Swift tests https://review.openstack.org/#/c/7465/
Refactoring of base test case classes 
https://review.openstack.org/#/c/7069/2









Meeting logs :

Summary (html 
format):http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-17-17.04.html

Summary (text format): 
http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-17-17.04.txt

Detailed logs:   
http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-17-17.04.log.html





Regards,

Ravi



--

Mailing list: https://launchpad.net/~openstack-qa-team

Post to : 
openstack-qa-t...@lists.launchpad.net

Unsubscribe : https://launchpad.net/~openstack-qa-team

More help   : https://help.launchpad.net/ListHelp



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

[Openstack] nova+quantum vm does bind ip

[Yi Sun]

All,
My issue is close to what reported by Emilien and others in
https://answers.launchpad.net/quantum/+question/197701. Only difference
is that  instead of not receiving DHCP reply, I do see the DHCP reply
from GW interface, but I still can not ping/ssh to the VM.
My server configuration is same as what Emilien has described in his
document here https://github.com/EmilienM, the only difference is that
I'm using a third interface (eth2) to connect quantum networks on two
servers. And the eth1 is used for management traffic.

My network configuration is
id   IPv4  IPv6   start address 
DNS1   DNS2   VlanID project   
uuid  
110.0.0.0/24   None   10.0.0.2  
8.8.4.4None   None  
61868ec0fd63486db3dbf1740e7111e96f765203-7fd8-425e-92b8-cf72b5c1c6cd


I launched VM in network 1 and it is running on the nova-compute server
(essex-2), I can see following tcpdump message from the tap interface
for the VM

16:19:06.183240 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from fa:16:3e:7f:f1:69 (oui Unknown), length 395
16:19:06.184146 IP 10.0.0.1.bootps > 10.0.0.4.bootpc: BOOTP/DHCP, Reply,
length 312
16:19:07.165572 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from fa:16:3e:7f:f1:69 (oui Unknown), length 395
16:19:07.165955 IP 10.0.0.1.bootps > 10.0.0.4.bootpc: BOOTP/DHCP, Reply,
length 312
16:19:08.299928 IP6 fe80::2429:e5ff:fed4:8ad5 > ip6-allrouters: ICMP6,
router solicitation, length 16
16:19:08.411921 IP6 fe80::2429:e5ff:fed4:8ad5 > ff02::16: HBH ICMP6,
multicast listener report v2, 1 group record(s), length 28
16:19:09.143041 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from fa:16:3e:7f:f1:69 (oui Unknown), length 407
16:19:09.143507 IP 10.0.0.1.bootps > 10.0.0.4.bootpc: BOOTP/DHCP, Reply,
length 312
16:19:14.143971 ARP, Request who-has 10.0.0.4 tell 10.0.0.1, length 42
16:19:15.143784 ARP, Request who-has 10.0.0.4 tell 10.0.0.1, length 42
16:19:16.143843 ARP, Request who-has 10.0.0.4 tell 10.0.0.1, length 42


No ARP response from the VM.  I tried to login to the VM console by
virsh console instance-0003 so that I can do tcpdump inside the VM.
But I got following error message:

root@openstack-2:/etc/libvirt/qemu/networks# virsh console instance-0003
Connected to domain instance-0003
Escape character is ^]
error: internal error
/var/lib/nova/instances/instance-0003/console.log: Cannot request
read and write flags together


Could some one suggest on how to debug this issue?
Thanks
Yi
PS: my nova.conf files are attached.

# Rabbit-MQ #
--rabbit_host=openstack-1

# SGBD with MySQL #
--sql_connection=mysql://root:password@openstack-1/nova

# API #
--cc_host=openstack-1
--auth_strategy=keystone
--s3_host=openstack-1
--ec2_host=openstack-1
--nova_url=http://openstack-1:8774/v1.1/
--ec2_url=http://openstack-1:8773/services/Cloud
--keystone_ec2_url=http://openstack-1:5000/v2.0/ec2tokens
--api_paste_config=/etc/nova/api-paste.ini
--allow_admin_api=true
--use_deprecated_auth=false

# Nova-Schedule #
--scheduler_driver=nova.scheduler.simple.SimpleScheduler

# Nova-Network with Quantum integration #
--network_manager=nova.network.quantum.manager.QuantumManager
--linuxnet_interface_driver=nova.network.linux_net.LinuxOVSInterfaceDriver
--quantum_use_dhcp=True
--quantum_connection_host=10.253.3.236
--public_interface=eth0
--flat_interface=eth2
--flat_network_bridge=br-int
--floating_range=10.68.5.0/24
--network_size=256
--flat_injected=False
--force_dhcp_release
--dhcpbridge_flagfile=/etc/nova/nova.conf
--dhcpbridge=/usr/bin/nova-dhcpbridge
--routing_source_ip=10.253.3.236

# Nova-Compute with KVM Hypervisor #
--libvirt_type=kvm
--libvirt_use_virtio_for_bridges=true
--start_guests_on_host_boot=true
--resume_guests_state_on_host_boot=true
--connection_type=libvirt

# Nova-Volume #
--iscsi_ip_prefix=192.168.68
--iscsi_helper=tgtadm

# Glance #
--glance_api_servers=openstack-1:9292
--image_service=nova.image.glance.GlanceImageService

# VNC #
--novnc_enable=true
--novncproxy_base_url=http://openstack-1:6080/vnc_auto.html
--vncserver_proxyclient_address=127.0.0.1
--vncserver_listen=127.0.0.1

# Misc #
--logdir=/var/log/nova
--state_path=/var/lib/nova
--lock_path=/var/lock/nova
--root_helper=sudo nova-rootwrap
--verbose
# Rabbit-MQ #
--rabbit_host=openstack-1

# SGBD with MySQL #
--sql_connection=mysql://nova:password@openstack-1/nova

# API #
--cc_host=openstack-1
--auth_strategy=keystone
--s3_host=openstack-1
--ec2_host=openstack-1
--nova_url=http://openstack-1:8774/v1.1/
--ec2_url=http://openstack-1:8773/services/Cloud
--keystone_ec2_url=http://openstack-1:5000/v2.0/ec2tokens
--api_paste_config=/etc/nova/api-paste.ini
--allow_admin_api=true
--use_deprecated_auth=false

# Nova-Schedule #
--scheduler_driver=nova.scheduler.simple.SimpleScheduler

# Nova-Network with Quantum integration #
--network_m

Re: [Openstack] [Netstack] nova+quantum vm does bind ip

[Yi Sun]

Ok, that helps.  Thanks
Now, I can tell that my issue is totally different one. For me, the dhcp
query is not sent by the Linux running by the VM. It is the ipxe in the
vm sending the query. And my VM was not really boot up at all. It can
not find a valid bootable device, I will need to find a way to fix up
the image first.
thx

Yi

On 05/18/2012 05:14 PM, Yong Sheng Gong wrote:
> Can you use virt-viewer to see vnc console?
>
>
>
> -netstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote: -
> To: openstack@lists.launchpad.net, netst...@lists.launchpad.net
> From: Yi Sun
> Sent by: netstack-bounces+gongysh=cn.ibm@lists.launchpad.net
> Date: 05/19/2012 07:52AM
> Subject: [Netstack] nova+quantum vm does bind ip
>
> All,
> My issue is close to what reported by Emilien and others in
> https://answers.launchpad.net/quantum/+question/197701. Only
> difference is that  instead of not receiving DHCP reply, I do see the
> DHCP reply from GW interface, but I still can not ping/ssh to the VM.
> My server configuration is same as what Emilien has described in his
> document here https://github.com/EmilienM, the only difference is that
> I'm using a third interface (eth2) to connect quantum networks on two
> servers. And the eth1 is used for management traffic.
>
> My network configuration is
> id   IPv4  IPv6   start address 
> DNS1   DNS2   VlanID
> projectuuid  
> 110.0.0.0/24   None   10.0.0.2  
> 8.8.4.4None   None  
> 61868ec0fd63486db3dbf1740e7111e96f765203-7fd8-425e-92b8-cf72b5c1c6cd
>
>
> I launched VM in network 1 and it is running on the nova-compute
> server (essex-2), I can see following tcpdump message from the tap
> interface for the VM
>
> 16:19:06.183240 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
> BOOTP/DHCP, Request from fa:16:3e:7f:f1:69 (oui Unknown), length 395
> 16:19:06.184146 IP 10.0.0.1.bootps > 10.0.0.4.bootpc: BOOTP/DHCP,
> Reply, length 312
> 16:19:07.165572 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
> BOOTP/DHCP, Request from fa:16:3e:7f:f1:69 (oui Unknown), length 395
> 16:19:07.165955 IP 10.0.0.1.bootps > 10.0.0.4.bootpc: BOOTP/DHCP,
> Reply, length 312
> 16:19:08.299928 IP6 fe80::2429:e5ff:fed4:8ad5 > ip6-allrouters: ICMP6,
> router solicitation, length 16
> 16:19:08.411921 IP6 fe80::2429:e5ff:fed4:8ad5 > ff02::16: HBH ICMP6,
> multicast listener report v2, 1 group record(s), length 28
> 16:19:09.143041 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
> BOOTP/DHCP, Request from fa:16:3e:7f:f1:69 (oui Unknown), length 407
> 16:19:09.143507 IP 10.0.0.1.bootps > 10.0.0.4.bootpc: BOOTP/DHCP,
> Reply, length 312
> 16:19:14.143971 ARP, Request who-has 10.0.0.4 tell 10.0.0.1, length 42
> 16:19:15.143784 ARP, Request who-has 10.0.0.4 tell 10.0.0.1, length 42
> 16:19:16.143843 ARP, Request who-has 10.0.0.4 tell 10.0.0.1, length 42
>
>
> No ARP response from the VM.  I tried to login to the VM console by
> virsh console instance-0003 so that I can do tcpdump inside the
> VM. But I got following error message:
>
> root@openstack-2:/etc/libvirt/qemu/networks# virsh console
> instance-0003
> Connected to domain instance-0003
> Escape character is ^]
> error: internal error
> /var/lib/nova/instances/instance-0003/console.log: Cannot request
> read and write flags together
>
>
> Could some one suggest on how to debug this issue?
> Thanks
> Yi
> PS: my nova.conf files are attached.
>
> -- 
> Mailing list: https://launchpad.net/~netstack
> 
> Post to : netst...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> 
> More help   : https://help.launchpad.net/ListHelp
>
>
> [attachment "nova.conf.server" removed by Yong Sheng Gong/China/IBM]
> [attachment "nova.conf.compute" removed by Yong Sheng Gong/China/IBM]

___
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] [Netstack] nova+quantum vm does bind ip

[Yong Sheng Gong]

Can you use virt-viewer to see vnc console?-netstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote: -To: openstack@lists.launchpad.net, netst...@lists.launchpad.netFrom: Yi Sun Sent by: netstack-bounces+gongysh=cn.ibm@lists.launchpad.netDate: 05/19/2012 07:52AMSubject: [Netstack] nova+quantum vm does bind ip
  


  
All, 
My issue is close to what reported by Emilien and others in
https://answers.launchpad.net/quantum/+question/197701. Only
difference is that  instead of not receiving DHCP reply, I do see
the DHCP reply from GW interface, but I still can not ping/ssh to
the VM.
My server configuration is same as what Emilien has described in his
document here

https://github.com/EmilienM,
the only difference is that I'm using a third interface (eth2) to
connect quantum networks on two servers. And the eth1 is used for
management traffic.

My network configuration is 
id       IPv4      IPv6       start address     
DNS1       DNS2       VlanID    
project        uuid   
1        10.0.0.0/24       None       10.0.0.2      
8.8.4.4        None       None      
61868ec0fd63486db3dbf1740e7111e9   
6f765203-7fd8-425e-92b8-cf72b5c1c6cd


I launched VM in network 1 and it is running on the nova-compute
server (essex-2), I can see following tcpdump message from the tap
interface for the VM

16:19:06.183240 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from fa:16:3e:7f:f1:69 (oui Unknown), length 395
16:19:06.184146 IP 10.0.0.1.bootps > 10.0.0.4.bootpc: BOOTP/DHCP,
Reply, length 312
16:19:07.165572 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from fa:16:3e:7f:f1:69 (oui Unknown), length 395
16:19:07.165955 IP 10.0.0.1.bootps > 10.0.0.4.bootpc: BOOTP/DHCP,
Reply, length 312
16:19:08.299928 IP6 fe80::2429:e5ff:fed4:8ad5 > ip6-allrouters:
ICMP6, router solicitation, length 16
16:19:08.411921 IP6 fe80::2429:e5ff:fed4:8ad5 > ff02::16: HBH
ICMP6, multicast listener report v2, 1 group record(s), length 28
16:19:09.143041 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from fa:16:3e:7f:f1:69 (oui Unknown), length 407
16:19:09.143507 IP 10.0.0.1.bootps > 10.0.0.4.bootpc: BOOTP/DHCP,
Reply, length 312
16:19:14.143971 ARP, Request who-has 10.0.0.4 tell 10.0.0.1, length
42
16:19:15.143784 ARP, Request who-has 10.0.0.4 tell 10.0.0.1, length
42
16:19:16.143843 ARP, Request who-has 10.0.0.4 tell 10.0.0.1, length
42


No ARP response from the VM.  I tried to login to the VM console by
virsh console instance-0003 so that I can do tcpdump inside the
VM. But I got following error message:

root@openstack-2:/etc/libvirt/qemu/networks# virsh console
instance-0003
Connected to domain instance-0003
Escape character is ^]
error: internal error
/var/lib/nova/instances/instance-0003/console.log: Cannot
request read and write flags together


Could some one suggest on how to debug this issue?
Thanks
Yi
PS: my nova.conf files are attached.

  -- Mailing list: https://launchpad.net/~netstackPost to     : netst...@lists.launchpad.netUnsubscribe : https://launchpad.net/~netstackMore help   : https://help.launchpad.net/ListHelp[attachment "nova.conf.server" removed by Yong Sheng Gong/China/IBM][attachment "nova.conf.compute" removed by Yong Sheng Gong/China/IBM]

___
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] Essex horizon dashboard - volume snapshot issue

[Vijay]

Hello,
On Essex Dashboard, I am able to create a snapshot of a volume successfully. 
However, when I click on the volume snapshot to look at the details, I get 
"Error: Unable to retrieve volume details". This error occurs only when 
retrieving the details of volume snapshots only. The volume details of the 
volume created from the scratch shows up correctly.

Also, on the horizon dashboard, there is no option to attach the volume 
snapshot to any running instance. I see only delete snapshot option. If it is 
by design, then, how is volume snapshot is going to be used?

Any help is appreciated.

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] Essex horizon dashboard - volume snapshot issue

[John Griffith]

On Fri, May 18, 2012 at 7:54 PM, Vijay  wrote:
> Hello,
> On Essex Dashboard, I am able to create a snapshot of a volume successfully. 
> However, when I click on the volume snapshot to look at the details, I get 
> "Error: Unable to retrieve volume details". This error occurs only when 
> retrieving the details of volume snapshots only. The volume details of the 
> volume created from the scratch shows up correctly.
>
> Also, on the horizon dashboard, there is no option to attach the volume 
> snapshot to any running instance. I see only delete snapshot option. If it is 
> by design, then, how is volume snapshot is going to be used?
>
> Any help is appreciated.
>
> 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

Hi VJ,

I believe you may have discovered a bug in the current version of
code.  Are you using the latest Folsom version (ie devstack)?  Check
your Horizon logs and you'll notice a number of errors when trying to
perform this operation.  Perhaps some Horizon folks here have some
knowledge of this, otherwise I can look into it further next week and
file a bug if necessary.

Meanwhile, you can use python-novaclient to perform a 'nova
volume-snapshot-show' which is the information that would be reported
from the Horizon details page you're trying to retrieve.

Thanks,
John

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