Re: [Openstack] Monitoring / Billing Architecture proposed
Hello Luis, I presented a blueprint last week [1] which proposes to clearly differentiate metering from the overall billing process. It is my understanding that billing is too complex a beast to be solved for each requirement in a satisfactory way and have therefore proposed that we should first concentrate on collecting the informations necessary for billing systems to pull their information from. The blueprint, and the discussion we had at the summit last week, outlines a proposed architecture but has, so far, left open the component choices to implement it. It is our proposal to start a a weekly meeting from that week to start selecting the components to deliver this. You are more than welcome to join the project if you want. [1] http://wiki.openstack.org/EfficientMetering Best regards, Nick On 04/22/2012 08:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ mailto:luis.gerv...@gmail.comwoorea.es http://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp 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] Using Nova APIs from Javascript: possible?
Hi Nick,
I did some work with CORS a few months back [1].
At the time I couldn't get any browser to work properly with CORS so I
just parked the code. The problem was lack of support for the
Access-Control-Expose-Headers header.
According to the Chrome bug report [2] this issue may well be fixed
now so I need to retest.
Adrian
[1] http://www.mail-archive.com/openstack@lists.launchpad.net/msg07219.html
[2] http://code.google.com/p/chromium/issues/detail?id=87338
On 23 April 2012 06:19, Nick Lothian nick.loth...@gmail.com wrote:
Hi,
I've been playing with the Nova APIs from Javascript, and I've run into a
problem.
The very first thing one needs to do to use the APIs is to get a token.
That requires a POST to the API endpoint. Using curl trystack that looks
like this:
$ curl -k -X 'POST' -v https://nova-api.trystack.org:5443/v2.0/tokens -d
'{auth:{passwordCredentials:{username: username,
password:password}}}' -H 'Content-type: application/json'
The Javascript equivalent (using JQuery) is:
$.ajax({
url: https://nova-api.trystack.org:5443/v2.0/tokens;,
type: 'POST',
headers: {Content-Type: application/json},
data: {auth:{passwordCredentials:{username:username,
password:password}}},
success: function(data) { alert(data); }
});
That fails because the call is cross-domain, and Nova doesn't support CORS
(http://en.wikipedia.org/wiki/Cross-origin_resource_sharing). script based
cross-domain requests only supports GET requests, so that doesn't work
either.
I have raised a bug: https://bugs.launchpad.net/nova/+bug/987044, but I'm
really hoping someone can point out something obvious I'm missing here.
Regards
Nick Lothian
___
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] Monitoring / Billing Architecture proposed
Hi, Although metering and billing always comes together for the deployment, for the sake of clarity, I also think metering should be a separate project from the billing, especially in openstack. (As you mentioned it, billing is complex and has too many different requirements per provider) Anyway, I am really interested in weekly meeting you mentioned in the email. How can I join the meeting? Is it irc-meeting?, mailing-list?, or else? -- Jaesuk Ahn, Ph.D. Team Leader | Cloud OS Dev. Team Cloud Infrastructure Department KT (Korea Telecom) T. +82-10-9888-0328 | F. +82-303-0993-5340 Active member on OpenStack Korea Community Apr 23, 2012, 4:09 PM, Nick Barcet 작성: Hello Luis, I presented a blueprint last week [1] which proposes to clearly differentiate metering from the overall billing process. It is my understanding that billing is too complex a beast to be solved for each requirement in a satisfactory way and have therefore proposed that we should first concentrate on collecting the informations necessary for billing systems to pull their information from. The blueprint, and the discussion we had at the summit last week, outlines a proposed architecture but has, so far, left open the component choices to implement it. It is our proposal to start a a weekly meeting from that week to start selecting the components to deliver this. You are more than welcome to join the project if you want. [1] http://wiki.openstack.org/EfficientMetering Best regards, Nick On 04/22/2012 08:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ mailto:luis.gerv...@gmail.comwoorea.es http://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] Using Nova APIs from Javascript: possible?
Hi Adrian,
Good to know this is a known issue.
Why does the client need to see custom headers from the server anyway?
I know the client needs to pass the authorisation header to the server, but
I haven't seen any of the APIs yet that return custom headers. (It's likely
I'm missing them though)
Nick
On Apr 23, 2012 5:40 PM, Adrian Smith adr...@17od.com wrote:
Hi Nick,
I did some work with CORS a few months back [1].
At the time I couldn't get any browser to work properly with CORS so I
just parked the code. The problem was lack of support for the
Access-Control-Expose-Headers header.
According to the Chrome bug report [2] this issue may well be fixed
now so I need to retest.
Adrian
[1]
http://www.mail-archive.com/openstack@lists.launchpad.net/msg07219.html
[2] http://code.google.com/p/chromium/issues/detail?id=87338
On 23 April 2012 06:19, Nick Lothian nick.loth...@gmail.com wrote:
Hi,
I've been playing with the Nova APIs from Javascript, and I've run into a
problem.
The very first thing one needs to do to use the APIs is to get a token.
That requires a POST to the API endpoint. Using curl trystack that
looks
like this:
$ curl -k -X 'POST' -v https://nova-api.trystack.org:5443/v2.0/tokens -d
'{auth:{passwordCredentials:{username: username,
password:password}}}' -H 'Content-type: application/json'
The Javascript equivalent (using JQuery) is:
$.ajax({
url: https://nova-api.trystack.org:5443/v2.0/tokens;,
type: 'POST',
headers: {Content-Type: application/json},
data: {auth:{passwordCredentials:{username:username,
password:password}}},
success: function(data) { alert(data); }
});
That fails because the call is cross-domain, and Nova doesn't support
CORS
(http://en.wikipedia.org/wiki/Cross-origin_resource_sharing). script
based
cross-domain requests only supports GET requests, so that doesn't work
either.
I have raised a bug: https://bugs.launchpad.net/nova/+bug/987044, but
I'm
really hoping someone can point out something obvious I'm missing here.
Regards
Nick Lothian
___
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] Monitoring / Billing Architecture proposed
On 04/23/2012 11:17 AM, Ahn, Jaesuk wrote: Hi, Although metering and billing always comes together for the deployment, for the sake of clarity, I also think metering should be a separate project from the billing, especially in openstack. (As you mentioned it, billing is complex and has too many different requirements per provider) Anyway, I am really interested in weekly meeting you mentioned in the email. How can I join the meeting? Is it irc-meeting?, mailing-list?, or else? Of course you can join. It will be a weekly irc meeting and I am about to send a doodle with multiple time choices to everyone that mentioned being interested in joining this project at the summit, and have included your email now. The first meeting will have for objective to finalize a project name and validate a road-map of decisions that need to be made. Thanks a lot, Nick -- *Jaesuk Ahn*, Ph.D. Team Leader | Cloud OS Dev. Team Cloud Infrastructure Department KT (Korea Telecom) *T. +82-10-9888-0328 | F. +82-303-0993-5340* *Active member on **OpenStack Korea Community* http://www.openstack.or.kr/ Apr 23, 2012, 4:09 PM, Nick Barcet 작성: Hello Luis, I presented a blueprint last week [1] which proposes to clearly differentiate metering from the overall billing process. It is my understanding that billing is too complex a beast to be solved for each requirement in a satisfactory way and have therefore proposed that we should first concentrate on collecting the informations necessary for billing systems to pull their information from. The blueprint, and the discussion we had at the summit last week, outlines a proposed architecture but has, so far, left open the component choices to implement it. It is our proposal to start a a weekly meeting from that week to start selecting the components to deliver this. You are more than welcome to join the project if you want. [1] http://wiki.openstack.org/EfficientMetering Best regards, Nick On 04/22/2012 08:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ mailto:luis.gerv...@gmail.comwoorea.es http://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto: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 mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp 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] Using Nova APIs from Javascript: possible?
The authentication request returns X-Storage-Url and X-Auth-Token
headers. For the JS client to see them they need to be referenced in
Access-Control-Expose-Headers. As of the last time checked, both these
headers were being stripped from the response before being presented
to JS.
Adrian
On 23 April 2012 10:35, Nick Lothian nick.loth...@gmail.com wrote:
Hi Adrian,
Good to know this is a known issue.
Why does the client need to see custom headers from the server anyway?
I know the client needs to pass the authorisation header to the server, but
I haven't seen any of the APIs yet that return custom headers. (It's likely
I'm missing them though)
Nick
On Apr 23, 2012 5:40 PM, Adrian Smith adr...@17od.com wrote:
Hi Nick,
I did some work with CORS a few months back [1].
At the time I couldn't get any browser to work properly with CORS so I
just parked the code. The problem was lack of support for the
Access-Control-Expose-Headers header.
According to the Chrome bug report [2] this issue may well be fixed
now so I need to retest.
Adrian
[1]
http://www.mail-archive.com/openstack@lists.launchpad.net/msg07219.html
[2] http://code.google.com/p/chromium/issues/detail?id=87338
On 23 April 2012 06:19, Nick Lothian nick.loth...@gmail.com wrote:
Hi,
I've been playing with the Nova APIs from Javascript, and I've run into
a
problem.
The very first thing one needs to do to use the APIs is to get a token.
That requires a POST to the API endpoint. Using curl trystack that
looks
like this:
$ curl -k -X 'POST' -v https://nova-api.trystack.org:5443/v2.0/tokens -d
'{auth:{passwordCredentials:{username: username,
password:password}}}' -H 'Content-type: application/json'
The Javascript equivalent (using JQuery) is:
$.ajax({
url: https://nova-api.trystack.org:5443/v2.0/tokens;,
type: 'POST',
headers: {Content-Type: application/json},
data: {auth:{passwordCredentials:{username:username,
password:password}}},
success: function(data) { alert(data); }
});
That fails because the call is cross-domain, and Nova doesn't support
CORS
(http://en.wikipedia.org/wiki/Cross-origin_resource_sharing). script
based
cross-domain requests only supports GET requests, so that doesn't work
either.
I have raised a bug: https://bugs.launchpad.net/nova/+bug/987044, but
I'm
really hoping someone can point out something obvious I'm missing here.
Regards
Nick Lothian
___
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] Using Nova APIs from Javascript: possible?
This is for Swift of course. But I guess there are similar headers for Nova.
On 23 April 2012 11:09, Adrian Smith adr...@17od.com wrote:
The authentication request returns X-Storage-Url and X-Auth-Token
headers. For the JS client to see them they need to be referenced in
Access-Control-Expose-Headers. As of the last time checked, both these
headers were being stripped from the response before being presented
to JS.
Adrian
On 23 April 2012 10:35, Nick Lothian nick.loth...@gmail.com wrote:
Hi Adrian,
Good to know this is a known issue.
Why does the client need to see custom headers from the server anyway?
I know the client needs to pass the authorisation header to the server, but
I haven't seen any of the APIs yet that return custom headers. (It's likely
I'm missing them though)
Nick
On Apr 23, 2012 5:40 PM, Adrian Smith adr...@17od.com wrote:
Hi Nick,
I did some work with CORS a few months back [1].
At the time I couldn't get any browser to work properly with CORS so I
just parked the code. The problem was lack of support for the
Access-Control-Expose-Headers header.
According to the Chrome bug report [2] this issue may well be fixed
now so I need to retest.
Adrian
[1]
http://www.mail-archive.com/openstack@lists.launchpad.net/msg07219.html
[2] http://code.google.com/p/chromium/issues/detail?id=87338
On 23 April 2012 06:19, Nick Lothian nick.loth...@gmail.com wrote:
Hi,
I've been playing with the Nova APIs from Javascript, and I've run into
a
problem.
The very first thing one needs to do to use the APIs is to get a token.
That requires a POST to the API endpoint. Using curl trystack that
looks
like this:
$ curl -k -X 'POST' -v https://nova-api.trystack.org:5443/v2.0/tokens -d
'{auth:{passwordCredentials:{username: username,
password:password}}}' -H 'Content-type: application/json'
The Javascript equivalent (using JQuery) is:
$.ajax({
url: https://nova-api.trystack.org:5443/v2.0/tokens;,
type: 'POST',
headers: {Content-Type: application/json},
data: {auth:{passwordCredentials:{username:username,
password:password}}},
success: function(data) { alert(data); }
});
That fails because the call is cross-domain, and Nova doesn't support
CORS
(http://en.wikipedia.org/wiki/Cross-origin_resource_sharing). script
based
cross-domain requests only supports GET requests, so that doesn't work
either.
I have raised a bug: https://bugs.launchpad.net/nova/+bug/987044, but
I'm
really hoping someone can point out something obvious I'm missing here.
Regards
Nick Lothian
___
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] what's wrong with novnc package in Ubuntu precise ?
Alexander Gordeev wrote: the current novnc package from universe is not workable with Essex release I filled a bug against this, but with no response at all https://bugs.launchpad.net/ubuntu/+source/novnc/+bug/956949 Fixed now. -- Thierry ___ 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] Canonical AWSOME
Philipp Wollermann wrote: What's the advantage of replacing the native EC2 compatibility layer with AWSOME from a user / operator point of view? One thing that was mentioned is that the proxy could be run on top of a public cloud that chose to only deploy OpenStack API support. -- 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] Using Nova APIs from Javascript: possible?
I see this as a feature, not a drawback.The inability to access
portions of the HTTP protocol is there to defend against attacks such as
cross site request forgeries. If we suppress that mechanism, we open up
a lot of security holes.
On 04/23/2012 06:09 AM, Adrian Smith wrote:
The authentication request returns X-Storage-Url and X-Auth-Token
headers. For the JS client to see them they need to be referenced in
Access-Control-Expose-Headers. As of the last time checked, both these
headers were being stripped from the response before being presented
to JS.
Adrian
On 23 April 2012 10:35, Nick Lothiannick.loth...@gmail.com wrote:
Hi Adrian,
Good to know this is a known issue.
Why does the client need to see custom headers from the server anyway?
I know the client needs to pass the authorisation header to the server, but
I haven't seen any of the APIs yet that return custom headers. (It's likely
I'm missing them though)
Nick
On Apr 23, 2012 5:40 PM, Adrian Smithadr...@17od.com wrote:
Hi Nick,
I did some work with CORS a few months back [1].
At the time I couldn't get any browser to work properly with CORS so I
just parked the code. The problem was lack of support for the
Access-Control-Expose-Headers header.
According to the Chrome bug report [2] this issue may well be fixed
now so I need to retest.
Adrian
[1]
http://www.mail-archive.com/openstack@lists.launchpad.net/msg07219.html
[2] http://code.google.com/p/chromium/issues/detail?id=87338
On 23 April 2012 06:19, Nick Lothiannick.loth...@gmail.com wrote:
Hi,
I've been playing with the Nova APIs from Javascript, and I've run into
a
problem.
The very first thing one needs to do to use the APIs is to get a token.
That requires a POST to the API endpoint. Using curl trystack that
looks
like this:
$ curl -k -X 'POST' -v https://nova-api.trystack.org:5443/v2.0/tokens -d
'{auth:{passwordCredentials:{username: username,
password:password}}}' -H 'Content-type: application/json'
The Javascript equivalent (using JQuery) is:
$.ajax({
url: https://nova-api.trystack.org:5443/v2.0/tokens;,
type: 'POST',
headers: {Content-Type: application/json},
data: {auth:{passwordCredentials:{username:username,
password:password}}},
success: function(data) { alert(data); }
});
That fails because the call is cross-domain, and Nova doesn't support
CORS
(http://en.wikipedia.org/wiki/Cross-origin_resource_sharing).script
based
cross-domain requests only supports GET requests, so that doesn't work
either.
I have raised a bug: https://bugs.launchpad.net/nova/+bug/987044, but
I'm
really hoping someone can point out something obvious I'm missing here.
Regards
Nick Lothian
___
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] Instances can't access eachother via external (floating) ips?
Hi Calvin, show us iptables -nL -t nat | grep NAT on the node with nova-network. Could it be that your fixed_range flag in nova.conf covers both subnets, like 192.168.0.0/16 ? Second reason - I presume that the traffic from VM will go via your router if you access another VM via floating IP, so router should know the route to 192.168.0.x (static/ospf?) Regards, On Fri, Apr 20, 2012 at 7:03 AM, Calvin Walton calvin.wal...@kepstin.cawrote: Hi, I have instances running in Openstack using FlatDHCP networking mode. Each one has an IP address in the internal subnet (192.168.22.x) and a floating IP from the external subnet (192.168.0.x). I've found that from one instance, I cannot connect to another instance (or, in fact, even the same instance) via the external floating address (I have some monitoring tools that attempt to do this to verify that a server is running). Connections from external computers work fine. My best guess is that there is an issue with the NAT on my nova-network node not allowing loopback connections. Is this intentional, or a bug? Is there a workaround available? For reference, I'm currently using OpenStack from the 'latest-milestone-test' OpenStack PPA on Ubuntu 12.04 Precise. -- Calvin Walton calvin.wal...@kepstin.ca Blindside Networks http://www.blindsidenetworks.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 -- Mike Scherbakov ___ 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] Coverage report generation crashes with UnicodeDecodeError (#987077)
Hello, Anyone experiencing a UnicodeDecodeError crash when running the nova tests with coverage reporting turned on (i.e. run_tests.sh -c)? Might this be a common environment misconfiguration problem on my side? More details at: https://bugs.lanchpad.net/nova/+bug/987077 Thanks, --Renier ___ 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] Glance Test Dependencies
I have a Jenkins job setup to execute the Glance tests. It will run on my master, but not a slave. Obviously there is a dependency missing on the slave. What is the best way to get a dependency list? I need to get this slave working for all OpenStack tests so that I can clone it... FAIL: test_add_clear (glance.tests.functional.test_bin_glance.TestBinGlance) -- Traceback (most recent call last): File /var/lib/jenkins/workspace/compute.review.glance/glance/glance/tests/functional/__init__.py, line 61, in wrapped func(*a, **kwargs) File /var/lib/jenkins/workspace/compute.review.glance/glance/glance/tests/functional/test_bin_glance.py, line 721, in test_add_clear self.start_servers(**self.__dict__.copy()) File /var/lib/jenkins/workspace/compute.review.glance/glance/glance/tests/functional/__init__.py, line 550, in start_servers self.wait_for_servers([self.api_port, self.registry_port]) File /var/lib/jenkins/workspace/compute.review.glance/glance/glance/tests/functional/__init__.py, line 592, in wait_for_servers self.assertFalse(expect_launch, Unexpected server launch status) AssertionError: Unexpected server launch status -- *Scott Lavender | Cloud Release Engineer _ ___ Phone 678.554.3403 • Cell 770.361.5940 slaven...@internap.com • www.internap.com http://www.internap.com/ INTERNAP ® connectivity | colocation | managed hosting | cloud One Ravinia Drive • Suite 1300 • Atlanta • GA • 30346* ___ 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] Shutoff Status
Hello Alyssa, the status is the one reported when you supend your instance Nuage Co - Razique Mahrouarazique.mahr...@gmail.com Le 16 avr. 2012 à 18:15, Alyssa Hurtgen a écrit : Hi all, I work at Rackspace and noticed a new Nova server status of "shutoff". What does this status mean?How does the server get into this status?Should the user be able to perform any actions against the server? Thanks, Alyssa Hurtgen ___Mailing list: https://launchpad.net/~openstackPost to : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore 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] Python UUID and SELinux AVC denials
On Sun, Apr 22, 2012 at 1:49 PM, Adam Young ayo...@redhat.com wrote:
On 04/20/2012 11:51 AM, Doug Hellmann wrote:
Have you tried changing Dashboard to monkey patch the uuid module to blank
out the functions being loaded from ctypes? If the _uuid_generate_*
functions are not set, the existing python implementation is used instead
and it looks like that just uses urandom() inline.
Good idea. I will test that out this upcoming week. The issue is that
just importing ctypes causes the ACV Denial, so I am not sure how that
will work when integrating with a Monkey Patch solution. Have you tried
it? Do you see anything in /var/log/audit/audit.log?
No, I haven't, but I can try in the next day or two. Are the steps to
reproduce the problem documented somewhere?
If you need to hide ctypes, the dashboard code can also insert a None
value into sys.modules to prevent it from being imported. Something like
this should do the trick:
import sys
sys.modules['ctypes'] = None
On Thu, Apr 19, 2012 at 11:53 AM, Adam Young ayo...@redhat.com wrote:
Did a little digging into an audit log message we've been seeing
specifically on Dashboard.
They look like this in audit.log
type=AVC msg=audit(1334860567.213:5184): avc: denied { execute } for
pid=1910
3 comm=httpd
path=2F6465762F73686D2F694F337A6B4972202864656C6574656429 dev
=tmpfs ino=1281359 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined
_u:object_r:httpd_tmpfs_t:s0 tclass=file
And are a little clearer if you use
sudo ausearch -i | grep denied
type=AVC msg=audit(04/19/2012 14:36:07.213:5184) : avc: denied {
execute } for pid=19103 comm=httpd path=/dev/shm/ffiO3zkIr (deleted)
dev=tmpfs ino=1281359 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:httpd_tmpfs_t:s0 tclass=file
Something in HTTPD is trying to generate code and then execute it by
writing to a file. We've traced that something down to the UUID generation
code. The standard UUID module makes a ctypes call, which does run time
generation of Native stubs in order to call into libuuid to actually
generate the UUID.
While we are working with the Python maintainers to come up with long
term fixes, we probably want to come up with something short term. We are
going to generate an alternative UUID module, probably named something
along the lines of uuid_no_ctypes, that will call into libuuid via
pregenerated function stubs. This module will be a copy of the uuid.py
file from The upstream, with the absolute minimum of changes to avoid
ctypes.
Once we've got this working, all of the projects that use UUID should
switch over...this is a good argument for putting that code into
Openstack-common. Keystone, Nova, and Quantum all import uuid.
None of the projects seem to be using ctypes directly. However, it is
possible that we are using other third party libraries that, in turn, use
ctypes.
___
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] Monitoring / Billing Architecture proposed
Hi! We have developed Nova Billing v2. Its documentation is currently available at http://aababilov.github.com/nova-billing-doc.github.com/. The documentation includes a glossary and architecture and API descriptions. Nova Billing v2 is a totally new solution. Its API and architecture were rewritten from scratch. The new Nova Billing introduces extensible modularized system with separate components. Nova Billing v2 can charge arbitrary resources according to custom billing schemas and, naturally, with different tariffs. Nova Billing v2 does not depend on any UI for OpenStack Cloud (neither OpenStack Dashboard nor any other solution). It does not require a particular OpenStack release. Provided components allow integration with diablo and essex and this list can be extended. Nova Billing v2 is event-driven and does not consumes system resources for periodical polling. Nova Billing v2 uses a RESTful protocol, so it is easy to integrate it with miscellaneous user clients and to add third-party components notifying about arbitrary events. Alessio Ababilov, Software Engineer Grid Dynamics ___ 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] Canonical AWSOME
On Mon, Apr 23, 2012 at 8:39 AM, Thierry Carrez thie...@openstack.orgwrote: Philipp Wollermann wrote: What's the advantage of replacing the native EC2 compatibility layer with AWSOME from a user / operator point of view? One thing that was mentioned is that the proxy could be run on top of a public cloud that chose to only deploy OpenStack API support. It also makes project management easier, as the people interested in maintaining it can focus on the separate repository. 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] Glance Test Dependencies
I typically run 'pip install -r tools/pip-requires -r tools/test-requires' from the root directory. You could also manually translate those lists to a list of ubuntu packages if you prefer not to use pip. Brian On Apr 17, 2012, at 5:49 AM, Scott Lavender wrote: I have a Jenkins job setup to execute the Glance tests. It will run on my master, but not a slave. Obviously there is a dependency missing on the slave. What is the best way to get a dependency list? I need to get this slave working for all OpenStack tests so that I can clone it... FAIL: test_add_clear (glance.tests.functional.test_bin_glance.TestBinGlance) -- Traceback (most recent call last): File /var/lib/jenkins/workspace/compute.review.glance/glance/glance/tests/functional/__init__.py, line 61, in wrapped func(*a, **kwargs) File /var/lib/jenkins/workspace/compute.review.glance/glance/glance/tests/functional/test_bin_glance.py, line 721, in test_add_clear self.start_servers(**self.__dict__.copy()) File /var/lib/jenkins/workspace/compute.review.glance/glance/glance/tests/functional/__init__.py, line 550, in start_servers self.wait_for_servers([self.api_port, self.registry_port]) File /var/lib/jenkins/workspace/compute.review.glance/glance/glance/tests/functional/__init__.py, line 592, in wait_for_servers self.assertFalse(expect_launch, Unexpected server launch status) AssertionError: Unexpected server launch status -- Scott Lavender | Cloud Release Engineer _ ___ Phone 678.554.3403 • Cell 770.361.5940 slaven...@internap.com • www.internap.com INTERNAP ® connectivity | colocation | managed hosting | cloud One Ravinia Drive • Suite 1300 • Atlanta • GA • 30346 ___ 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] Monitoring / Billing Architecture proposed
On 04/23/2012 04:39 PM, Alexey Ababilov wrote: Hi! We have developed Nova Billing v2. Its documentation is currently available at http://aababilov.github.com/nova-billing-doc.github.com/. The documentation includes a glossary and architecture and API descriptions. Nova Billing v2 is a totally new solution. Its API and architecture were rewritten from scratch. The new Nova Billing introduces extensible modularized system with separate components. Nova Billing v2 can charge arbitrary resources according to custom billing schemas and, naturally, with different tariffs. Nova Billing v2 does not depend on any UI for OpenStack Cloud (neither OpenStack Dashboard nor any other solution). It does not require a particular OpenStack release. Provided components allow integration with diablo and essex and this list can be extended. Nova Billing v2 is event-driven and does not consumes system resources for periodical polling. Nova Billing v2 uses a RESTful protocol, so it is easy to integrate it with miscellaneous user clients and to add third-party components notifying about arbitrary events. Alessio Ababilov, Software Engineer Grid Dynamics Excellent! It sounds from the architecture that your work will easily be integrated into a the generic OpenStack metering solution that we are currently defining. The main goal of our design is to dissociate the metering from the billing part and to offer extensibility to all current and future components of OpenStack. Would you care to help us define this architecture? Thanks, 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] Monitoring / Billing Architecture proposed
On Sun, 2012-04-22 at 20:50 +0200, Luis Gervaso wrote: I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) Except for the use of MongoDB, the above seems to me to be almost identical to the notifications system already in Nova, which Yagi consumes. Have you looked at our existing notifications? Yagi? One or both might solve at least parts of your problem… -- Kevin L. Mitchell kevin.mitch...@rackspace.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] Canonical AWSOME
On 04/23/2012 02:39 PM, Thierry Carrez wrote: Philipp Wollermann wrote: What's the advantage of replacing the native EC2 compatibility layer with AWSOME from a user / operator point of view? One thing that was mentioned is that the proxy could be run on top of a public cloud that chose to only deploy OpenStack API support. Another reason why we started this project is that we believe this architecture would be easier to use and maintain than what currently exists in Nova. This is why we are proposing this work as a longer term solution for EC2 compatibility. 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
[Openstack] New OpenStack Releases in Ubuntu 12.04LTS
For those of you who may have missed this announcement. Canonical has created the Ubuntu Cloud archive. Starting with the Folsum release, users will be able to elect to enable this archive, and install newer releases of OpenStack (and the dependencies) as they become available up through the next Ubuntu LTS release (presumably 14.04). Bug processing and patch contributions will follow standard Ubuntu practice and policy where applicable. Canonical commits to maintaining and supporting new OpenStack releases for Ubuntu Server 12.04 LTS in our Ubuntu Cloud archive for at least 18 months after they release. Canonical will stop introducing new releases of OpenStack for Ubuntu Server 12.04 LTS into the Ubuntu Cloud archive with the version shipped in the next Ubuntu Server LTS release (presumably 14.04). We will maintain and support this last updated release of OpenStack in the Ubuntu Cloud archive for 3 years, i.e. until the end of the Ubuntu 12.04 LTS lifecycle. In order to allow for a relatively easy upgrade, and still adhere to Ubuntu processes and policy, we have elected to have archive.canonical.com be the home of the Ubuntu Cloud archive. We will enable update paths for each OpenStack release. e.g. Enabling “precise-folsum” in the archive will provide access to all OpenStack Folsum packages built for Ubuntu Server 12.04 LTS (binary and source), any updated dependencies required, and bug/security fixes made after release. More information on this can be found here: https://wiki.ubuntu.com/ServerTeam/CloudArchive -- Robbie Williamson rob...@ubuntu.com robbiew[irc.freenode.net] Don't make me angry...you wouldn't like me when I'm angry. -Bruce Banner ___ 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] Canonical AWSOME
What's the advantage of replacing the native EC2 compatibility layer with AWSOME from a user / operator point of view? Although I wasn't able to attend the design summit session, right now we have two native APIs, which means we have two paths into the system. That is poor software engineering, because we must code and debug everything twice. Some developers will naturally favor one API over the other, and so disparities happen. Today, both APIs are effectively using an undocumented private API, which is problematic. We also can't really extend the EC2 API, so it is holding us back as we extend OpenStack's capabilities past those of the legacy clouds. With one native API, we can focus all our energies on making sure that API works. Then, knowing that the native API works, we can build other APIs on top through simple translation layers, and they will work also. Other APIs can be built on top in the same way (e.g. OCCI) Which is a long way of saying the external approach will result in _all_ APIs (OpenStack, EC2, OCCI etc) becoming more reliable, more secure and just more AWSOME. Justin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Quantum and multi-nic
Hi Mandar, If a question is quantum-specific, best to associated it with the quantum project, not the nova project. Associating it with the Quantum project will make sure that Quantum developers are notified. Most quantum developers are not notified for each question asked about nova. I've responded with a request for more info, and changed the project of the question to 'quantum'. dan On Sun, Apr 22, 2012 at 10:36 PM, Vaze, Mandar mandar.v...@nttdata.comwrote: Dan, ** ** Can you help with this ? https://answers.launchpad.net/nova/+question/194111 ** ** Thanks, -Mandar ** ** __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Coverage report generation crashes with UnicodeDecodeError (#987077)
On 04/23/2012 10:01 AM, Renier Morales wrote: Hello, Anyone experiencing a UnicodeDecodeError crash when running the nova tests with coverage reporting turned on (i.e. run_tests.sh -c)? Might this be a common environment misconfiguration problem on my side? More details at: https://bugs.lanchpad.net/nova/+bug/987077 Any chance you've just got a stale .venv in the repo? Coverage seems to be running fine for me this morning. -Sean -- Sean Dague IBM Linux Technology Center email: slda...@us.ibm.com alt-email: sda...@linux.vnet.ibm.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] orphaned floating_ips if you terminate before disassociating?
Hi, We are running Essex on 12.04 b2. Has anyone else noticed that, using the dashboard, if you terminate an instance before disassociating a floating ip, the result is that the floating_ips record is orphaned (refers to deleted instance). In this state, accessing the tenant using the dashboard, results in errors do to the orphaned floating_ips record. I have not found anyone else reporting this issue. I'm trying to figure out if it is specific to our configuration or not. Or maybe I just don't know how to search effectively ... In the meantime, let me see if I can reproduce with devstack. Thanks! Brian ___ 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] Monitoring / Billing Architecture proposed
This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi (https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ 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] HTTP status value naming normalization
This sounds like a good candidate to live in openstack-common, rather than being limited to Swift. On Sat, Apr 21, 2012 at 12:22 PM, John Dickinson m...@not.mn wrote: I like what you are trying to do here. Can you please submit this as a patch through gerrit so we can get the rest of the core devs to look at it? --John On Apr 20, 2012, at 12:14 PM, Victor Rodionov wrote: There are many place in Swift code where used hard coded values, such as response statuses (200, 201, 404, ...) which can replaced with constants HTTP_OK, HTTP_CREATED, HTTP_NOT_FOUND. Also there is widlly used idiom 200 = status 300, that can be replaced as well with something like this is_success(status). I want add modules for defining all required constants (Swift, HTTP). So I think this changes will improve Swift code readability. PS: this is an initial changes in github https://github.com/vitoordaz/swift/commit/7163d5df13ceaf8fc7b53ba812fe16bd7dd31131 ___ 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] [quantum] summit slides for clearpath service insertion
During the summit, there was an API proposal for service insertion, present by folks from Clear path. Does anyone have links? a. ___ 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] Coverage report generation crashes with UnicodeDecodeError (#987077)
On Apr 23, 2012, at 11:59 AM, Sean Dague wrote: On 04/23/2012 10:01 AM, Renier Morales wrote: Hello, Anyone experiencing a UnicodeDecodeError crash when running the nova tests with coverage reporting turned on (i.e. run_tests.sh -c)? Might this be a common environment misconfiguration problem on my side? More details at: https://bugs.lanchpad.net/nova/+bug/987077 Any chance you've just got a stale .venv in the repo? Coverage seems to be running fine for me this morning. I removed my .venv and covhtml dirs, but I still get the UnicodeDecodeError. Seems to be related to this: https://bitbucket.org/ned/coveragepy/issue/157/chokes-on-source-files-with-non-utf-8 --Renier ___ 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] Monitoring / Billing Architecture proposed
Nick, I want contribute in the discussion group. I have seen yagi implementation, and i like it. I like the protocol. But I think that it's a protocol that fits very well when no sensible data is involved (content feeds). When money, resources, companies are involved i think we need to use a more elaborated schema. I don't like the 3rd parties have to pull, my proporsal here is that 3rd parties can be entities externalized outside of the datacenter. 1. i don't want to make the accounting public accessible for security reasons. 2. 3rd parties can't be coupled to openstack, i want to feed them. I think this is the key. What i realized is that the listener needs to feed the billing system following the rules/api of the selected billing system. Scenario: 1. A company has an account on a billing provider 2. A company should define the pricing model in the billing system, outside openstack (i.e: inside zuora, jbilling, recurly, dough) 3. When a message arrives to the listener the listener has to perform the following actions: 3a: transform and store the message in a accounting system (restful api) 3b (optional): transform and store the message in a billing system (restful api) example: [ http://knowledgecenter.zuora.com/C_Zuora_User_Guides/A_Billing_and_Payments/A_Z-Billing ] 3c (optional): perform monitoring (currently evaluating sigar functionality) 3a: is openstack related 3b, 3c, ...: are hooks 4a. A company can query the billing system to gather the bills (no openstack dependencies) 4b. A company can query the monitoring system (no openstack dependencies) Regarding MongoDB, I recommend a document oriented database where we can query with criteria. Redis is key-value oriented. Cheers! On Mon, Apr 23, 2012 at 4:51 PM, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: On Sun, 2012-04-22 at 20:50 +0200, Luis Gervaso wrote: I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) Except for the use of MongoDB, the above seems to me to be almost identical to the notifications system already in Nova, which Yagi consumes. Have you looked at our existing notifications? Yagi? One or both might solve at least parts of your problem… -- Kevin L. Mitchell kevin.mitch...@rackspace.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 -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
On Sun, Apr 22, 2012 at 5:29 PM, Brian Schott brian.sch...@nimbisservices.com wrote: Dough is a proposed billing service. There was a session at Folsom design summit. This is a practical project for an OpenStack provider with test code on github. http://summit.openstack.org/sessions/view/37 The billing system consists of three components. 1) API Server, which receives subscribe/unsubscribe and usage query requests. 2) Farmer, which periodically checks all subscriptions and requests billing to the collector. 3) Collector, gets work from the farmer and uses python-novaclient, kanyun-client, swift-client to retrieve usage information of a product the tenant has subscribed and charges money to the accordingly. Kanyun is an OpenStack monitoring tool, but I don't see documentation in the code tree (but I've just pulled it to see). https://github.com/lzyeval Dough had mixed reviews during the session, but that I think was because it came across as a billing system triggered solely by Horizon requests and was a polled architecture. I also had some reservations about Dough because it seemed brittle. For example, it was my impression that if an instance creation operation failed for some reason, the operator had to manually correct the billing data. Given what we have today, I'd implement my own billing/metering system exactly the same way. In fact, I have. Our own e-commerce system at Nimbis works this way with EC2 and OpenStack presently because the only option available is polling periodically and logging the usage data. The fact that it only worked through Horizon was the biggest issue for us. That means if we expose the API to our users, instances created via the API but not the Horizon dashboard would not be billed. I understood the decision to be a proof-of-concept, but an event-based model for collecting the data seems much more robust and flexible. Where I'd like to see OpenStack go is metering service that is fully asynchronous and event driven so that I only need to hit the API service when I'm generating an invoice, rather than once per minute because I don't know when an instance was terminated by the user or just crashed. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 4:57 PM, Endre Karlson wrote: What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.comwrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.com What about using the Dough project ? Endre. 2012/4/22 Luis Gervaso l...@woorea.es Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34)
Re: [Openstack] Using Nova APIs from Javascript: possible?
Adam, in what way should the OS API support server-less clients? AFAIK the
options are CORS or JSONP, no?
On Apr 23, 2012, at 5:50 AM, Adam Young wrote:
I see this as a feature, not a drawback.The inability to access portions
of the HTTP protocol is there to defend against attacks such as cross site
request forgeries. If we suppress that mechanism, we open up a lot of
security holes.
On 04/23/2012 06:09 AM, Adrian Smith wrote:
The authentication request returns X-Storage-Url and X-Auth-Token
headers. For the JS client to see them they need to be referenced in
Access-Control-Expose-Headers. As of the last time checked, both these
headers were being stripped from the response before being presented
to JS.
Adrian
On 23 April 2012 10:35, Nick Lothiannick.loth...@gmail.com wrote:
Hi Adrian,
Good to know this is a known issue.
Why does the client need to see custom headers from the server anyway?
I know the client needs to pass the authorisation header to the server, but
I haven't seen any of the APIs yet that return custom headers. (It's likely
I'm missing them though)
Nick
On Apr 23, 2012 5:40 PM, Adrian Smithadr...@17od.com wrote:
Hi Nick,
I did some work with CORS a few months back [1].
At the time I couldn't get any browser to work properly with CORS so I
just parked the code. The problem was lack of support for the
Access-Control-Expose-Headers header.
According to the Chrome bug report [2] this issue may well be fixed
now so I need to retest.
Adrian
[1]
http://www.mail-archive.com/openstack@lists.launchpad.net/msg07219.html
[2] http://code.google.com/p/chromium/issues/detail?id=87338
On 23 April 2012 06:19, Nick Lothiannick.loth...@gmail.com wrote:
Hi,
I've been playing with the Nova APIs from Javascript, and I've run into
a
problem.
The very first thing one needs to do to use the APIs is to get a token.
That requires a POST to the API endpoint. Using curl trystack that
looks
like this:
$ curl -k -X 'POST' -v https://nova-api.trystack.org:5443/v2.0/tokens -d
'{auth:{passwordCredentials:{username: username,
password:password}}}' -H 'Content-type: application/json'
The Javascript equivalent (using JQuery) is:
$.ajax({
url: https://nova-api.trystack.org:5443/v2.0/tokens;,
type: 'POST',
headers: {Content-Type: application/json},
data: {auth:{passwordCredentials:{username:username,
password:password}}},
success: function(data) { alert(data); }
});
That fails because the call is cross-domain, and Nova doesn't support
CORS
(http://en.wikipedia.org/wiki/Cross-origin_resource_sharing).script
based
cross-domain requests only supports GET requests, so that doesn't work
either.
I have raised a bug: https://bugs.launchpad.net/nova/+bug/987044, but
I'm
really hoping someone can point out something obvious I'm missing here.
Regards
Nick Lothian
___
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
___
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] Regular XenAPI Meeting
Hi, Are people keen for a XenAPI virt layer meetup on IRC every month? I have added a suggested time to the wiki, as a starting point: Monthly, second Wednesday at 17:00 UTC Does that seem a reasonable time for those that want to attend? It can be more frequent if we find that useful. I don't want to detract from the other meetings, but it would be good to keep all of us working on the XenAPI layer in regular contact. Cheers, 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
Re: [Openstack] Monitoring / Billing Architecture proposed
Is there a document somewhere on what events the services emit? - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 23, 2012, at 12:39 PM, Monsyne Dragon wrote: This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi (https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Canonical AWSOME
We just have to be careful here to make sure that lots and lots of tests are done to ensure that the EC2 response is valid as well as to ensure the performance is not de-graded by having this proxy layer. If it does get de-graded then there needs to be some work done to ensure that this does not happen (ie new features in the openstack-api). Hopefully this proxy layer can also remain stateless, for as long as possible (for everyone's sanity). On 4/23/12 7:57 AM, Nick Barcet nick.bar...@canonical.com wrote: On 04/23/2012 02:39 PM, Thierry Carrez wrote: Philipp Wollermann wrote: What's the advantage of replacing the native EC2 compatibility layer with AWSOME from a user / operator point of view? One thing that was mentioned is that the proxy could be run on top of a public cloud that chose to only deploy OpenStack API support. Another reason why we started this project is that we believe this architecture would be easier to use and maintain than what currently exists in Nova. This is why we are proposing this work as a longer term solution for EC2 compatibility. Nick ___ 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] Monitoring / Billing Architecture proposed
I have been looking at : http://wiki.openstack.org/SystemUsageData On Mon, Apr 23, 2012 at 7:35 PM, Brian Schott brian.sch...@nimbisservices.com wrote: Is there a document somewhere on what events the services emit? - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 23, 2012, at 12:39 PM, Monsyne Dragon wrote: This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi ( https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
If you wanted to use Yagi, it would be trivial to add a JSON only notifier to Yagi. If you're interested and need a hand, feel free to hit Dragon or I for assistance. From: Monsyne Dragon mdra...@rackspace.commailto:mdra...@rackspace.com Date: Mon, 23 Apr 2012 16:39:08 + To: Luis Gervaso l...@woorea.esmailto:l...@woorea.es Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Monitoring / Billing Architecture proposed This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi (https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@mailto:luis.gerv...@gmail.comwoorea.eshttp://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: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] Monitoring / Billing Architecture proposed
So, we could build on this. No reason to reinvent, but we might want to expand the number of events. I'm concerned about things like what happens when flavors change over time. Maybe the answer is, always append to the flavor/instance-type table. The code I remember and the admin interface that Ken wrote allowed you to modify flavors. That would break billing unless you also track flavor modifications. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 23, 2012, at 1:40 PM, Luis Gervaso wrote: I have been looking at : http://wiki.openstack.org/SystemUsageData On Mon, Apr 23, 2012 at 7:35 PM, Brian Schott brian.sch...@nimbisservices.com wrote: Is there a document somewhere on what events the services emit? - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 23, 2012, at 12:39 PM, Monsyne Dragon wrote: This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi (https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [quantum] summit slides for clearpath service insertion
Adding Peter, who gave that presentation. To all Quantum team members: if you haven't already, please post slides to the main etherpad page: http://etherpad.openstack.org/quantum-folsom Thanks! Dan On Mon, Apr 23, 2012 at 9:58 AM, andi abes andi.a...@gmail.com wrote: During the summit, there was an API proposal for service insertion, present by folks from Clear path. Does anyone have links? a. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Canonical AWSOME
Creating a contract on the private API will allow the external APIs to be created and tested without needing a translation layer, even if contributory APIs were developed outside of the project (such as in AWSOME). It is clearly better, architecturally, if the EC2/OCCI apis can access the internal apis directly. The RPC and database can be made to scale in Nova, but a REST endpoint won't be as reliable or scale as well. -- Eric Windisch On Monday, April 23, 2012 at 11:15 AM, Justin Santa Barbara wrote: What's the advantage of replacing the native EC2 compatibility layer with AWSOME from a user / operator point of view? Although I wasn't able to attend the design summit session, right now we have two native APIs, which means we have two paths into the system. That is poor software engineering, because we must code and debug everything twice. Some developers will naturally favor one API over the other, and so disparities happen. Today, both APIs are effectively using an undocumented private API, which is problematic. We also can't really extend the EC2 API, so it is holding us back as we extend OpenStack's capabilities past those of the legacy clouds. With one native API, we can focus all our energies on making sure that API works. Then, knowing that the native API works, we can build other APIs on top through simple translation layers, and they will work also. Other APIs can be built on top in the same way (e.g. OCCI) Which is a long way of saying the external approach will result in _all_ APIs (OpenStack, EC2, OCCI etc) becoming more reliable, more secure and just more AWSOME. Justin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net (mailto: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] Monitoring / Billing Architecture proposed
On 04/23/2012 07:06 PM, Luis Gervaso wrote: Nick, I want contribute in the discussion group. Luis, I just sent your an invite to the doodle to pick the best time for this irc meeting. Once the date will have been finalized (I'll close the poll tomorrow EOD), I'll announce the date, time and place on this list as well as to everyone that entered the poll. Anyone else wanting to participate in the poll for the meeting time may follow this link: http://doodle.com/zi6b6vxxkiuxyuqk Thanks, 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] Canonical AWSOME
On 04/23/2012 10:42 AM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 8:39 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Philipp Wollermann wrote: What's the advantage of replacing the native EC2 compatibility layer with AWSOME from a user / operator point of view? One thing that was mentioned is that the proxy could be run on top of a public cloud that chose to only deploy OpenStack API support. This makes sense. It also makes project management easier, as the people interested in maintaining it can focus on the separate repository. I'm not sure I buy into this, though. Why is it harder for people that are interested in EC2 support to work in the existing nova repo? If people want to collaborate before pushing into mainline, that can be done via feature branches, too. It risks making EC2 development harder, as well. Pulling it out of nova completely risks allowing the people that don't care about EC2 to care even less. It could make it easier for people to make changes that make EC2 compatibility harder to maintain. -- Russell Bryant ___ 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] Monitoring / Billing Architecture proposed
Brian, Dough isn't dependent on Horizon. Dough has a client that can be inserted anywhere to notify the start/end of using a resource. We inserted the client in horizon just to try out the many ways our billing system could be integrated with our existing deployment. We are planning to make a Nova notifier to listen on the AMQP to automate the subscription process. However, we still have to devise a way to integrate Swift that would be symmetric with the things done in Nova. Also fail recovery is a feature we are working on right now. Separate the log and execution to cross-reference the logs and DB periodically. We plan to finish the first release this month and use it on our deployment. Let me know if you have other suggestions. Cheers, LZY On Tue, Apr 24, 2012 at 1:06 AM, Doug Hellmann doug.hellm...@dreamhost.comwrote: On Sun, Apr 22, 2012 at 5:29 PM, Brian Schott brian.sch...@nimbisservices.com wrote: Dough is a proposed billing service. There was a session at Folsom design summit. This is a practical project for an OpenStack provider with test code on github. http://summit.openstack.org/sessions/view/37 The billing system consists of three components. 1) API Server, which receives subscribe/unsubscribe and usage query requests. 2) Farmer, which periodically checks all subscriptions and requests billing to the collector. 3) Collector, gets work from the farmer and uses python-novaclient, kanyun-client, swift-client to retrieve usage information of a product the tenant has subscribed and charges money to the accordingly. Kanyun is an OpenStack monitoring tool, but I don't see documentation in the code tree (but I've just pulled it to see). https://github.com/lzyeval Dough had mixed reviews during the session, but that I think was because it came across as a billing system triggered solely by Horizon requests and was a polled architecture. I also had some reservations about Dough because it seemed brittle. For example, it was my impression that if an instance creation operation failed for some reason, the operator had to manually correct the billing data. Given what we have today, I'd implement my own billing/metering system exactly the same way. In fact, I have. Our own e-commerce system at Nimbis works this way with EC2 and OpenStack presently because the only option available is polling periodically and logging the usage data. The fact that it only worked through Horizon was the biggest issue for us. That means if we expose the API to our users, instances created via the API but not the Horizon dashboard would not be billed. I understood the decision to be a proof-of-concept, but an event-based model for collecting the data seems much more robust and flexible. Where I'd like to see OpenStack go is metering service that is fully asynchronous and event driven so that I only need to hit the API service when I'm generating an invoice, rather than once per minute because I don't know when an instance was terminated by the user or just crashed. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 4:57 PM, Endre Karlson wrote: What is Dough then compared to what you want to do ? 2012/4/22 Endre Karlson endre.karl...@gmail.com What is Dough then ? 2012/4/22 Brian Schott brian.sch...@nimbisservices.com I see this blueprint for metering, but none for Dough currently. http://wiki.openstack.org/EfficientMetering Here are the Dough slides, however: http://www.slideshare.net/lzyeval/dough-openstack-billing-project We collectively need to talk more about the user scenarios, because I don't think you can just put a decorator around the API rpc calls and get an accurate picture of what to bill for later. There are metered things like bandwidth or IOPS, events that happen outside of the API (shutdown -h), and it is hard to predict what a reseller will want to charge for. It is better to put a metering system in that can handle many billing configurations. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 22, 2012, at 3:36 PM, Luis Gervaso wrote: Dough is the proposed billing platform/product (where the billing rules live), isn't it? I don't know Dough enough, so please me correct me if i'm wrong. I'm trying to define a generic/agnostic integration process, obviously where Dough can fit perfectly. I would like it become part to the reference architecture. Option 1) [3b in the arch proposed] Dough should pull NoSQL Option 2) A Mediator can feed Dough On Sun, Apr 22, 2012 at 9:13 PM, Endre Karlson endre.karl...@gmail.com wrote: What about using the Dough project? Endre. 2012/4/22 Endre Karlson endre.karl...@gmail.com What about using the Dough
Re: [Openstack] Canonical AWSOME
Martin Packman mentioned that there are some other groups interested in creating a separate AWS validation test suite, and that AWSOME would probably be using that. I think Joshua Harlow from Yahoo! was working in that area, too. On Mon, Apr 23, 2012 at 1:38 PM, Joshua Harlow harlo...@yahoo-inc.comwrote: We just have to be careful here to make sure that lots and lots of tests are done to ensure that the EC2 response is valid as well as to ensure the performance is not de-graded by having this proxy layer. If it does get de-graded then there needs to be some work done to ensure that this does not happen (ie new features in the openstack-api). Hopefully this proxy layer can also remain stateless, for as long as possible (for everyone's sanity). On 4/23/12 7:57 AM, Nick Barcet nick.bar...@canonical.com wrote: On 04/23/2012 02:39 PM, Thierry Carrez wrote: Philipp Wollermann wrote: What's the advantage of replacing the native EC2 compatibility layer with AWSOME from a user / operator point of view? One thing that was mentioned is that the proxy could be run on top of a public cloud that chose to only deploy OpenStack API support. Another reason why we started this project is that we believe this architecture would be easier to use and maintain than what currently exists in Nova. This is why we are proposing this work as a longer term solution for EC2 compatibility. Nick ___ 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] Canonical AWSOME
Ya, we should figure out how to organize to make this happen. It seems to provide many benefits (not just for openstack). Maybe setup a little working group around this... On 4/23/12 12:01 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: Martin Packman mentioned that there are some other groups interested in creating a separate AWS validation test suite, and that AWSOME would probably be using that. I think Joshua Harlow from Yahoo! was working in that area, too. On Mon, Apr 23, 2012 at 1:38 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: We just have to be careful here to make sure that lots and lots of tests are done to ensure that the EC2 response is valid as well as to ensure the performance is not de-graded by having this proxy layer. If it does get de-graded then there needs to be some work done to ensure that this does not happen (ie new features in the openstack-api). Hopefully this proxy layer can also remain stateless, for as long as possible (for everyone's sanity). On 4/23/12 7:57 AM, Nick Barcet nick.bar...@canonical.com http://nick.bar...@canonical.com wrote: On 04/23/2012 02:39 PM, Thierry Carrez wrote: Philipp Wollermann wrote: What's the advantage of replacing the native EC2 compatibility layer with AWSOME from a user / operator point of view? One thing that was mentioned is that the proxy could be run on top of a public cloud that chose to only deploy OpenStack API support. Another reason why we started this project is that we believe this architecture would be easier to use and maintain than what currently exists in Nova. This is why we are proposing this work as a longer term solution for EC2 compatibility. Nick ___ 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] Monitoring / Billing Architecture proposed
I like http://wiki.openstack.org/SystemUsageData I just wonder if there should be offical formats for the data sent across the wire. Or at least high level formats that define the data, maybe in a simple python map style layout. With examples would be awesome. On 4/23/12 10:40 AM, Luis Gervaso l...@woorea.es wrote: I have been looking at : http://wiki.openstack.org/SystemUsageData On Mon, Apr 23, 2012 at 7:35 PM, Brian Schott brian.sch...@nimbisservices.com wrote: Is there a document somewhere on what events the services emit? - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 tel:443-274-6064 fx: 443-274-6060 tel:443-274-6060 On Apr 23, 2012, at 12:39 PM, Monsyne Dragon wrote: This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi (https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! ___ 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] Monitoring / Billing Architecture proposed
Joshua,
I have performed a create instance operation and here is an example data
obtained from stable/essex rabbitmq nova catch all exchange.
[*] Waiting for messages. To exit press CTRL+C
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin:
true, _context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
a1cb1cf61e5441c2a772b29d3cd54202, _context_read_deleted: no,
_context_request_id: req-db34ba32-8bd9-4cd5-b7b5-43705a9e258e, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin:
true, _context_project_id: null, _context_timestamp:
2012-03-24T01:37:50.463586, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
ebb0b1c340de4024a22eafec9d0a2d66, _context_read_deleted: no,
_context_request_id: req-ddb51b2b-a29f-4aad-909d-3f7f79f053c4, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin:
true, _context_project_id: null, _context_timestamp:
2012-03-24T01:38:59.217333, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [Member], _msg_id:
729535c00d224414a98286e9ce3475a9, _context_read_deleted: no,
_context_request_id: req-b056a8cc-3542-41a9-9e58-8fb592086264,
_context_auth_token: deb477655fba448e85199f7e559da77a,
_context_is_admin: false, _context_project_id:
df3827f76f714b1e8f31675caf84ae9d, _context_timestamp:
2012-03-24T01:39:19.813393, _context_user_id:
abe21eb7e6884547810f0a43c216e6a6, method:
get_floating_ips_by_project, _context_remote_address: 192.168.1.41}'
[x] Received '{_context_roles: [Member, admin],
_context_request_id: req-45e6c2af-52c7-4de3-af6c-6b2f7520cfd5,
_context_read_deleted: no, args: {request_spec: {num_instances:
1, block_device_mapping: [], image: {status: active, name:
cirros-0.3.0-x86_64-uec, deleted: false, container_format: ami,
created_at: 2012-03-20 17:37:08, disk_format: ami, updated_at:
2012-03-20 17:37:08, properties: {kernel_id:
6b700d25-3293-420a-82e4-8247d4b0da2a, ramdisk_id:
22b10c35-c868-4470-84ef-54ae9f17a977}, min_ram: 0, checksum:
2f81976cae15c16ef0010c51e3a6c163, min_disk: 0, is_public: true,
deleted_at: null, id: f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525, size:
25165824}, instance_type: {root_gb: 0, name: m1.tiny, deleted:
false, created_at: null, ephemeral_gb: 0, updated_at: null,
memory_mb: 512, vcpus: 1, flavorid: 1, swap: 0, rxtx_factor:
1.0, extra_specs: {}, deleted_at: null, vcpu_weight: null, id: 2},
instance_properties: {vm_state: building, ephemeral_gb: 0,
access_ip_v6: null, access_ip_v4: null, kernel_id:
6b700d25-3293-420a-82e4-8247d4b0da2a, key_name: testssh,
ramdisk_id: 22b10c35-c868-4470-84ef-54ae9f17a977, instance_type_id:
2, user_data: dGhpcyBpcyBteSB1c2VyIGRhdGE=, vm_mode: null,
display_name: eureka, config_drive_id: , reservation_id:
r-xtzjx50j, key_data: ssh-rsa
B3NzaC1yc2EDAQABgQDJ31tdayh1xnAY+JO/ZVdg5L83CsIU7qaOmFubdH7zlg2jjS9JmkPNANj99zx+UHg5F5JKGMef9M8VP/V89D5g0oIjIJtBdFpKOScBo3yJ1vteW5ItImH8h9TldymHf+CWNVY1oNNqzXqAb41xwUUDNvgeXHRZNnE6tmwZO0oC1Q==
stack@ubuntu\n, root_gb: 0, user_id:
abe21eb7e6884547810f0a43c216e6a6, uuid:
40b5a1c5-bd4f-40ee-ae0a-73e0bc927431, root_device_name: null,
availability_zone: null, launch_time: 2012-03-24T01:39:52Z,
metadata: {}, display_description: eureka, memory_mb: 512,
launch_index: 0, vcpus: 1, locked: false, image_ref:
f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525, architecture: null,
power_state: 0, auto_disk_config: null, progress: 0, os_type: null,
project_id: df3827f76f714b1e8f31675caf84ae9d, config_drive: },
security_group: [default]}, is_first_time: true, filter_properties:
{scheduler_hints: {}}, topic: compute, admin_password:
SKohh79r956J, injected_files: [], requested_networks: null},
_context_auth_token: deb477655fba448e85199f7e559da77a,
_context_is_admin: false, _context_project_id:
df3827f76f714b1e8f31675caf84ae9d, _context_timestamp:
2012-03-24T01:39:52.089383, _context_user_id:
abe21eb7e6884547810f0a43c216e6a6, method: run_instance,
_context_remote_address: 192.168.1.41}'
[x] Received '{_context_roles: [Member, admin],
_context_request_id: req-45e6c2af-52c7-4de3-af6c-6b2f7520cfd5,
_context_read_deleted: no, args: {instance_uuid:
40b5a1c5-bd4f-40ee-ae0a-73e0bc927431, requested_networks:
Re: [Openstack] Monitoring / Billing Architecture proposed
The following links to work from OGF in the usage accounting and tracking area might be useful. First of all, we have the UsageRecord format (UR), which has been used in a variety of distributed computing environments for tracking usage. It defines an XML-based format for exchange of usage records. The format is general enough to describe a variety of distributed computing environments, but specific enough to allow practical usage and has served as the basis for usage accounting in grids, for example, for some time. http://ogf.org/documents/GFD.98.pdf We also have the following storage accounting work in process and nearly complete: https://forge.gridforum.org/sf/go/artf6532?nav=1 and http://www.ogf.org/Public_Comment_Docs/Documents/2012-02/EMI-StAR-OGF-info-doc-v2.pdf This document has just come out of public comment and is moving toward publication shortly. Between the UR work on traditional cpu accounting and the above storage accounting publication, I hope this provides some input into this topic from OGF. Alan On Apr 23, 2012, at 12:50 PM, Brian Schott wrote: So, we could build on this. No reason to reinvent, but we might want to expand the number of events. I'm concerned about things like what happens when flavors change over time. Maybe the answer is, always append to the flavor/instance-type table. The code I remember and the admin interface that Ken wrote allowed you to modify flavors. That would break billing unless you also track flavor modifications. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 23, 2012, at 1:40 PM, Luis Gervaso wrote: I have been looking at : http://wiki.openstack.org/SystemUsageData On Mon, Apr 23, 2012 at 7:35 PM, Brian Schott brian.sch...@nimbisservices.com wrote: Is there a document somewhere on what events the services emit? - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 23, 2012, at 12:39 PM, Monsyne Dragon wrote: This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi (https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 l...@woorea.es
Re: [Openstack] Canonical AWSOME
On Monday, April 23, 2012 at 3:42 PM, Justin Santa Barbara wrote: I didn't realize people were willing to do so. Ah yes, well, that problem might still remain. There are certainly seem to be volunteers to work on the versioning code, but defining, tagging, and adhering to API contracts are another matter... -- 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] Canonical AWSOME
How are REST endpoints not reliable or scalable ;-) I'd like to know, seeing as the web is built on them :-) It is clearly better to access the internal API's if performance is an issue, from an abstraction point of view if the EC2 apis are a view on top of the OS apis then that seems to make sense (if it can be done). Although a counter-point I will accept is that if u have 2 apis that openstack supports internally, ie the EC2/OS apis this does force u to think more about the APIs that u are building (to ensure it will work with the 2 external apis), which does help force better thinking as to how your API's will be designed. When u have 2+ entrypoints using an API, then u know that 3+ will be pretty easy, but if u only have 1 entrypoint using your API, then u might just have screwed yourself. On 4/23/12 11:01 AM, Eric Windisch e...@cloudscaling.com wrote: Creating a contract on the private API will allow the external APIs to be created and tested without needing a translation layer, even if contributory APIs were developed outside of the project (such as in AWSOME). It is clearly better, architecturally, if the EC2/OCCI apis can access the internal apis directly. The RPC and database can be made to scale in Nova, but a REST endpoint won't be as reliable or scale as well. ___ 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] Monitoring / Billing Architecture proposed
Flavor information is copied to the Instance table on creation so the Flavors can change and still be tracked in the Instance. It may just need to be sent in the notification payload. The current events in the system are documented here: http://wiki.openstack.org/SystemUsageData -Sandy On 04/23/2012 02:50 PM, Brian Schott wrote: So, we could build on this. No reason to reinvent, but we might want to expand the number of events. I'm concerned about things like what happens when flavors change over time. Maybe the answer is, always append to the flavor/instance-type table. The code I remember and the admin interface that Ken wrote allowed you to modify flavors. That would break billing unless you also track flavor modifications. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 23, 2012, at 1:40 PM, Luis Gervaso wrote: I have been looking at : http://wiki.openstack.org/SystemUsageData On Mon, Apr 23, 2012 at 7:35 PM, Brian Schott brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com wrote: Is there a document somewhere on what events the services emit? - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com ph: 443-274-6064 tel:443-274-6064 fx: 443-274-6060 tel:443-274-6060 On Apr 23, 2012, at 12:39 PM, Monsyne Dragon wrote: This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi (https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 tel:%28%2B34%29%20627983344 luis@ mailto:luis.gerv...@gmail.comwoorea.es http://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 tel:210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ mailto:luis.gerv...@gmail.comwoorea.es http://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe :
Re: [Openstack] Using Nova APIs from Javascript: possible?
Sorry, meant to say server-less client applications. The OP is trying to
create a client-side JS application that communicates directly to an OS
endpoint (specifically trystack). I believe his problem is same origin policy,
not authentication.
On Apr 23, 2012, at 12:33 PM, Adam Young wrote:
On 04/23/2012 01:13 PM, Tres Henry wrote:
Adam, in what way should the OS API support server-less clients? AFAIK the
options are CORS or JSONP, no?
I am not quite sure what you mean by serverless clients, but I think the
answer to this is getting a real Single Sign On solution, which is based on:
1. Kerberos,
2. X509
Kerberos is likely a non starter for Web applications due to some current
issues with handling multiple TGTs and also cross firewalls (Kerberso tickets
must get served out on port 88 without jumping through considerable hoops.)
I've written up about X509 support here:
http://wiki.openstack.org/PKI
I think that X509 Client Authentication is the right long-term approach for
what we are doing. Specifically, short term X509 certificates replacing the
Keystone tokens as the mechanism for SSO.
On Apr 23, 2012, at 5:50 AM, Adam Young wrote:
I see this as a feature, not a drawback.The inability to access
portions of the HTTP protocol is there to defend against attacks such as
cross site request forgeries. If we suppress that mechanism, we open up a
lot of security holes.
On 04/23/2012 06:09 AM, Adrian Smith wrote:
The authentication request returns X-Storage-Url and X-Auth-Token
headers. For the JS client to see them they need to be referenced in
Access-Control-Expose-Headers. As of the last time checked, both these
headers were being stripped from the response before being presented
to JS.
Adrian
On 23 April 2012 10:35, Nick Lothiannick.loth...@gmail.com wrote:
Hi Adrian,
Good to know this is a known issue.
Why does the client need to see custom headers from the server anyway?
I know the client needs to pass the authorisation header to the server,
but
I haven't seen any of the APIs yet that return custom headers. (It's
likely
I'm missing them though)
Nick
On Apr 23, 2012 5:40 PM, Adrian Smithadr...@17od.com wrote:
Hi Nick,
I did some work with CORS a few months back [1].
At the time I couldn't get any browser to work properly with CORS so I
just parked the code. The problem was lack of support for the
Access-Control-Expose-Headers header.
According to the Chrome bug report [2] this issue may well be fixed
now so I need to retest.
Adrian
[1]
http://www.mail-archive.com/openstack@lists.launchpad.net/msg07219.html
[2] http://code.google.com/p/chromium/issues/detail?id=87338
On 23 April 2012 06:19, Nick Lothiannick.loth...@gmail.com wrote:
Hi,
I've been playing with the Nova APIs from Javascript, and I've run into
a
problem.
The very first thing one needs to do to use the APIs is to get a token.
That requires a POST to the API endpoint. Using curl trystack that
looks
like this:
$ curl -k -X 'POST' -v https://nova-api.trystack.org:5443/v2.0/tokens -d
'{auth:{passwordCredentials:{username: username,
password:password}}}' -H 'Content-type: application/json'
The Javascript equivalent (using JQuery) is:
$.ajax({
url: https://nova-api.trystack.org:5443/v2.0/tokens;,
type: 'POST',
headers: {Content-Type: application/json},
data: {auth:{passwordCredentials:{username:username,
password:password}}},
success: function(data) { alert(data); }
});
That fails because the call is cross-domain, and Nova doesn't support
CORS
(http://en.wikipedia.org/wiki/Cross-origin_resource_sharing).script
based
cross-domain requests only supports GET requests, so that doesn't work
either.
I have raised a bug: https://bugs.launchpad.net/nova/+bug/987044, but
I'm
really hoping someone can point out something obvious I'm missing here.
Regards
Nick Lothian
___
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] Canonical AWSOME
+1 if you want people to care about something then it should be part of the main repo and part of the regular regression testing. thanks -Doug __ STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | d...@us.ibm.com The more I'm around some people, the more I like my dog. Russell Bryant rbry...@redhat.com Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net 04/23/2012 02:16 PM To openstack@lists.launchpad.net cc Subject Re: [Openstack] Canonical AWSOME On 04/23/2012 10:42 AM, Doug Hellmann wrote: On Mon, Apr 23, 2012 at 8:39 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Philipp Wollermann wrote: What's the advantage of replacing the native EC2 compatibility layer with AWSOME from a user / operator point of view? One thing that was mentioned is that the proxy could be run on top of a public cloud that chose to only deploy OpenStack API support. This makes sense. It also makes project management easier, as the people interested in maintaining it can focus on the separate repository. I'm not sure I buy into this, though. Why is it harder for people that are interested in EC2 support to work in the existing nova repo? If people want to collaborate before pushing into mainline, that can be done via feature branches, too. It risks making EC2 development harder, as well. Pulling it out of nova completely risks allowing the people that don't care about EC2 to care even less. It could make it easier for people to make changes that make EC2 compatibility harder to maintain. -- Russell Bryant ___ 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] Canonical AWSOME
On Monday, April 23, 2012 at 4:00 PM, Joshua Harlow wrote: Re: [Openstack] Canonical AWSOME How are REST endpoints not reliable or scalable ;-) I’d like to know, seeing as the web is built on them :-) The resiliency of the internet is actually built on BGP. REST endpoints fall over constantly. Look no further than Google 500 errors, the fail-whale, etc. Even the EC2 API has been known to fall-over. Making HTTP services reliable is not as trivial as it should be. The reason is because they are single points. It is possible, through running many services and doing intelligent load balancing and failover, to make REST reasonably reliable. However, I'd rather not broker my requests through a questionably reliable REST broker, and send messages directly to their destinations to RPC consumers which are already running (and required) on those machines. If the destination is offline, it doesn't need my message. If the REST broker is offline, the recipient on the other end of that broker should still be guaranteed delivery… The problem can be simplified as: * How many REST endpoints do you need to service 100 compute machines? How many REST endpoints do you need to service 100 compute machines? How many points of failure exist? * How many compute machines do you need to service 100 compute machines? How many compute machines do you need to service 100 compute machines? How many points of failure exist? It is unclear how many REST endpoints you'll need. The compute machines scale as they scale, they're not dependent on a REST broker. Every compute machine itself can fail, although this failure is likely trivial (messages to a dead machine are generally vain). Meanwhile, the REST service has to deal with dead compute machines *and* the death of REST services supporting the architecture. -- 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] [quantum] summit slides for clearpath service insertion
It would also be helpful for us newbies if you add your (full) name as session leader. I have first names and faces for a lot of people, but there are quite a few duplicate first names on the lists. Thanks! Doug On Mon, Apr 23, 2012 at 1:58 PM, Dan Wendlandt d...@nicira.com wrote: Adding Peter, who gave that presentation. To all Quantum team members: if you haven't already, please post slides to the main etherpad page: http://etherpad.openstack.org/quantum-folsom Thanks! Dan On Mon, Apr 23, 2012 at 9:58 AM, andi abes andi.a...@gmail.com wrote: During the summit, there was an API proposal for service insertion, present by folks from Clear path. Does anyone have links? a. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] New OpenStack Releases in Ubuntu 12.04LTS
Great job, congratulations to the crew :) Nuage Co - Razique Mahrouarazique.mahr...@gmail.com Le 23 avr. 2012 à 17:02, Robbie Williamson a écrit :For those of you who may have missed this announcement. Canonical hascreated the Ubuntu Cloud archive. Starting with the Folsum release,users will be able to elect to enable this archive, and install newerreleases of OpenStack (and the dependencies) as they become available upthrough the next Ubuntu LTS release (presumably 14.04). Bug processingand patch contributions will follow standard Ubuntu practice and policywhere applicable. Canonical commits to maintaining and supporting newOpenStack releases for Ubuntu Server 12.04 LTS in our Ubuntu Cloudarchive for at least 18 months after they release. Canonical will stopintroducing new releases of OpenStack for Ubuntu Server 12.04 LTS intothe Ubuntu Cloud archive with the version shipped in the next UbuntuServer LTS release (presumably 14.04). We will maintain and supportthis last updated release of OpenStack in the Ubuntu Cloud archive for 3years, i.e. until the end of the Ubuntu 12.04 LTS lifecycle. In order toallow for a relatively easy upgrade, and still adhere to Ubuntuprocesses and policy, we have elected to have archive.canonical.com bethe home of the Ubuntu Cloud archive. We will enable update paths foreach OpenStack release. e.g. Enabling “precise-folsum” in the archive will provide access to all OpenStack Folsum packages built for Ubuntu Server 12.04 LTS (binary and source), any updated dependencies required, and bug/security fixes made after release.More information on this can be found here: https://wiki.ubuntu.com/ServerTeam/CloudArchive-- Robbie Williamson rob...@ubuntu.comrobbiew[irc.freenode.net]"Don't make me angry...you wouldn't like me when I'm angry." -Bruce Banner___Mailing list: https://launchpad.net/~openstackPost to : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore 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] Canonical AWSOME
+1 on this. Implementing adapter style code may also introduce additional state maintenance within the proxy/adapter to the eventual target API and if not at a minimum more complexity. Also care would be needed to avoid leaky abstractions [1]. However, I don't necessarily agree that a REST endpoint (esp. stateless ones like OSAPI) can't be scaled easily. Justin makes a very interesting point with regard to the non-extensible nature of the EC2 API (unlike that of OSAPI or OCCI). Perhaps it is an 'API parity' challenge ( i.e. where API X is functionally equivalent to OSAPI) and solution (having the ability and maintaining parity) that is key to the discussion? .2c Andy andy.edmonds.be [1] http://www.joelonsoftware.com/articles/LeakyAbstractions.html On Mon, Apr 23, 2012 at 19:01, Eric Windisch e...@cloudscaling.com wrote: Creating a contract on the private API will allow the external APIs to be created and tested without needing a translation layer, even if contributory APIs were developed outside of the project (such as in AWSOME). It is clearly better, architecturally, if the EC2/OCCI apis can access the internal apis directly. The RPC and database can be made to scale in Nova, but a REST endpoint won't be as reliable or scale as well. -- Eric Windisch On Monday, April 23, 2012 at 11:15 AM, Justin Santa Barbara wrote: What's the advantage of replacing the native EC2 compatibility layer with AWSOME from a user / operator point of view? Although I wasn't able to attend the design summit session, right now we have two native APIs, which means we have two paths into the system. That is poor software engineering, because we must code and debug everything twice. Some developers will naturally favor one API over the other, and so disparities happen. Today, both APIs are effectively using an undocumented private API, which is problematic. We also can't really extend the EC2 API, so it is holding us back as we extend OpenStack's capabilities past those of the legacy clouds. With one native API, we can focus all our energies on making sure that API works. Then, knowing that the native API works, we can build other APIs on top through simple translation layers, and they will work also. Other APIs can be built on top in the same way (e.g. OCCI) Which is a long way of saying the external approach will result in _all_ APIs (OpenStack, EC2, OCCI etc) becoming more reliable, more secure and just more AWSOME. Justin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] Monitoring / Billing Architecture proposed
Great,
Now we just need to officialize those as a first step to making a real
interchange format that can be versioned, documented... and all the other
goodies u would normally expect.
On 4/23/12 12:26 PM, Luis Gervaso l...@woorea.es wrote:
Joshua,
I have performed a create instance operation and here is an example data
obtained from stable/essex rabbitmq nova catch all exchange.
[*] Waiting for messages. To exit press CTRL+C
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
a1cb1cf61e5441c2a772b29d3cd54202, _context_read_deleted: no,
_context_request_id: req-db34ba32-8bd9-4cd5-b7b5-43705a9e258e, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:37:50.463586, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
ebb0b1c340de4024a22eafec9d0a2d66, _context_read_deleted: no,
_context_request_id: req-ddb51b2b-a29f-4aad-909d-3f7f79f053c4, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:38:59.217333, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [Member], _msg_id:
729535c00d224414a98286e9ce3475a9, _context_read_deleted: no,
_context_request_id: req-b056a8cc-3542-41a9-9e58-8fb592086264,
_context_auth_token: deb477655fba448e85199f7e559da77a, _context_is_admin:
false, _context_project_id: df3827f76f714b1e8f31675caf84ae9d,
_context_timestamp: 2012-03-24T01:39:19.813393, _context_user_id:
abe21eb7e6884547810f0a43c216e6a6, method: get_floating_ips_by_project,
_context_remote_address: 192.168.1.41}'
[x] Received '{_context_roles: [Member, admin], _context_request_id:
req-45e6c2af-52c7-4de3-af6c-6b2f7520cfd5, _context_read_deleted: no,
args: {request_spec: {num_instances: 1, block_device_mapping: [],
image: {status: active, name: cirros-0.3.0-x86_64-uec, deleted:
false, container_format: ami, created_at: 2012-03-20 17:37:08,
disk_format: ami, updated_at: 2012-03-20 17:37:08, properties:
{kernel_id: 6b700d25-3293-420a-82e4-8247d4b0da2a, ramdisk_id:
22b10c35-c868-4470-84ef-54ae9f17a977}, min_ram: 0, checksum:
2f81976cae15c16ef0010c51e3a6c163, min_disk: 0, is_public: true,
deleted_at: null, id: f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525, size:
25165824}, instance_type: {root_gb: 0, name: m1.tiny, deleted: false,
created_at: null, ephemeral_gb: 0, updated_at: null, memory_mb: 512,
vcpus: 1, flavorid: 1, swap: 0, rxtx_factor: 1.0, extra_specs: {},
deleted_at: null, vcpu_weight: null, id: 2}, instance_properties:
{vm_state: building, ephemeral_gb: 0, access_ip_v6: null,
access_ip_v4: null, kernel_id: 6b700d25-3293-420a-82e4-8247d4b0da2a,
key_name: testssh, ramdisk_id: 22b10c35-c868-4470-84ef-54ae9f17a977,
instance_type_id: 2, user_data: dGhpcyBpcyBteSB1c2VyIGRhdGE=, vm_mode:
null, display_name: eureka, config_drive_id: , reservation_id:
r-xtzjx50j, key_data: ssh-rsa
B3NzaC1yc2EDAQABgQDJ31tdayh1xnAY+JO/ZVdg5L83CsIU7qaOmFubdH7zlg2jjS9JmkPNANj99zx+UHg5F5JKGMef9M8VP/V89D5g0oIjIJtBdFpKOScBo3yJ1vteW5ItImH8h9TldymHf+CWNVY1oNNqzXqAb41xwUUDNvgeXHRZNnE6tmwZO0oC1Q==
stack@ubuntu\n, root_gb: 0, user_id: abe21eb7e6884547810f0a43c216e6a6,
uuid: 40b5a1c5-bd4f-40ee-ae0a-73e0bc927431, root_device_name: null,
availability_zone: null, launch_time: 2012-03-24T01:39:52Z, metadata:
{}, display_description: eureka, memory_mb: 512, launch_index: 0,
vcpus: 1, locked: false, image_ref:
f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525, architecture: null, power_state: 0,
auto_disk_config: null, progress: 0, os_type: null, project_id:
df3827f76f714b1e8f31675caf84ae9d, config_drive: }, security_group:
[default]}, is_first_time: true, filter_properties: {scheduler_hints:
{}}, topic: compute, admin_password: SKohh79r956J, injected_files:
[], requested_networks: null}, _context_auth_token:
deb477655fba448e85199f7e559da77a, _context_is_admin: false,
_context_project_id: df3827f76f714b1e8f31675caf84ae9d,
_context_timestamp: 2012-03-24T01:39:52.089383, _context_user_id:
Re: [Openstack] [quantum] summit slides for clearpath service insertion
Hi folks, I've posted the presentation here: http://www.slideshare.net/saintkepha/quantum-virtual-network-service Also, the etherpad for quantum-folsom has been updated with the slides and a brief description. Thanks, -Peter Peter K. Lee V.P. Software Infrastructure Engineering ClearPath Networks, Inc. Office: 310-955-5060 www.clearpathnet.com From: Dan Wendlandt [mailto:d...@nicira.com] Sent: Monday, April 23, 2012 10:58 AM To: andi abes Cc: openstack@lists.launchpad.net; Peter Lee Subject: Re: [Openstack] [quantum] summit slides for clearpath service insertion Adding Peter, who gave that presentation. To all Quantum team members: if you haven't already, please post slides to the main etherpad page: http://etherpad.openstack.org/quantum-folsom Thanks! Dan On Mon, Apr 23, 2012 at 9:58 AM, andi abes andi.a...@gmail.commailto:andi.a...@gmail.com wrote: During the summit, there was an API proposal for service insertion, present by folks from Clear path. Does anyone have links? a. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.comhttp://www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Monitoring / Billing Architecture proposed
StackTach is a Django-based web interface for capturing, displaying and
navigating OpenStack notifications
https://github.com/rackspace/stacktach
-S
On 04/23/2012 04:26 PM, Luis Gervaso wrote:
Joshua,
I have performed a create instance operation and here is an example data
obtained from stable/essex rabbitmq nova catch all exchange.
[*] Waiting for messages. To exit press CTRL+C
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe,
args: {instance_id: 6, instance_uuid:
e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7, host: ubuntu, project_id:
c290118b14564257be26a2cb901721a2, rxtx_factor: 1.0},
_context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
a1cb1cf61e5441c2a772b29d3cd54202, _context_read_deleted: no,
_context_request_id: req-db34ba32-8bd9-4cd5-b7b5-43705a9e258e,
args: {instance_id: 6, instance_uuid:
e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7, host: ubuntu, project_id:
c290118b14564257be26a2cb901721a2, rxtx_factor: 1.0},
_context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:37:50.463586, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
ebb0b1c340de4024a22eafec9d0a2d66, _context_read_deleted: no,
_context_request_id: req-ddb51b2b-a29f-4aad-909d-3f7f79f053c4,
args: {instance_id: 6, instance_uuid:
e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7, host: ubuntu, project_id:
c290118b14564257be26a2cb901721a2, rxtx_factor: 1.0},
_context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:38:59.217333, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [Member], _msg_id:
729535c00d224414a98286e9ce3475a9, _context_read_deleted: no,
_context_request_id: req-b056a8cc-3542-41a9-9e58-8fb592086264,
_context_auth_token: deb477655fba448e85199f7e559da77a,
_context_is_admin: false, _context_project_id:
df3827f76f714b1e8f31675caf84ae9d, _context_timestamp:
2012-03-24T01:39:19.813393, _context_user_id:
abe21eb7e6884547810f0a43c216e6a6, method:
get_floating_ips_by_project, _context_remote_address: 192.168.1.41}'
[x] Received '{_context_roles: [Member, admin],
_context_request_id: req-45e6c2af-52c7-4de3-af6c-6b2f7520cfd5,
_context_read_deleted: no, args: {request_spec:
{num_instances: 1, block_device_mapping: [], image: {status:
active, name: cirros-0.3.0-x86_64-uec, deleted: false,
container_format: ami, created_at: 2012-03-20 17:37:08,
disk_format: ami, updated_at: 2012-03-20 17:37:08, properties:
{kernel_id: 6b700d25-3293-420a-82e4-8247d4b0da2a, ramdisk_id:
22b10c35-c868-4470-84ef-54ae9f17a977}, min_ram: 0, checksum:
2f81976cae15c16ef0010c51e3a6c163, min_disk: 0, is_public: true,
deleted_at: null, id: f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525,
size: 25165824}, instance_type: {root_gb: 0, name: m1.tiny,
deleted: false, created_at: null, ephemeral_gb: 0, updated_at:
null, memory_mb: 512, vcpus: 1, flavorid: 1, swap: 0,
rxtx_factor: 1.0, extra_specs: {}, deleted_at: null,
vcpu_weight: null, id: 2}, instance_properties: {vm_state:
building, ephemeral_gb: 0, access_ip_v6: null, access_ip_v4:
null, kernel_id: 6b700d25-3293-420a-82e4-8247d4b0da2a, key_name:
testssh, ramdisk_id: 22b10c35-c868-4470-84ef-54ae9f17a977,
instance_type_id: 2, user_data: dGhpcyBpcyBteSB1c2VyIGRhdGE=,
vm_mode: null, display_name: eureka, config_drive_id: ,
reservation_id: r-xtzjx50j, key_data: ssh-rsa
B3NzaC1yc2EDAQABgQDJ31tdayh1xnAY+JO/ZVdg5L83CsIU7qaOmFubdH7zlg2jjS9JmkPNANj99zx+UHg5F5JKGMef9M8VP/V89D5g0oIjIJtBdFpKOScBo3yJ1vteW5ItImH8h9TldymHf+CWNVY1oNNqzXqAb41xwUUDNvgeXHRZNnE6tmwZO0oC1Q==
stack@ubuntu\n, root_gb: 0, user_id:
abe21eb7e6884547810f0a43c216e6a6, uuid:
40b5a1c5-bd4f-40ee-ae0a-73e0bc927431, root_device_name: null,
availability_zone: null, launch_time: 2012-03-24T01:39:52Z,
metadata: {}, display_description: eureka, memory_mb: 512,
launch_index: 0, vcpus: 1, locked: false, image_ref:
f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525, architecture: null,
power_state: 0, auto_disk_config: null, progress: 0, os_type:
null, project_id: df3827f76f714b1e8f31675caf84ae9d, config_drive:
}, security_group: [default]}, is_first_time: true,
filter_properties: {scheduler_hints: {}}, topic: compute,
admin_password: SKohh79r956J, injected_files: [],
requested_networks: null}, _context_auth_token:
deb477655fba448e85199f7e559da77a, _context_is_admin: false,
_context_project_id: df3827f76f714b1e8f31675caf84ae9d,
_context_timestamp: 2012-03-24T01:39:52.089383, _context_user_id:
Re: [Openstack] Monitoring / Billing Architecture proposed
This looks like just the standard RPC traffic.
You need to turn notifications on
(set:
notification_driver=nova.notifier.rabbit_notifier
in nova's config file)
and listen on the notification.* queues
On Apr 23, 2012, at 2:26 PM, Luis Gervaso wrote:
Joshua,
I have performed a create instance operation and here is an example data
obtained from stable/essex rabbitmq nova catch all exchange.
[*] Waiting for messages. To exit press CTRL+C
[x] Received '{_context_roles: [admin], _msg_id:
a2d13735baad4613b89c6132e0fa8302, _context_read_deleted: no,
_context_request_id: req-d7ffbe78-7a9c-4d20-9ac5-3e56951526fe, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:36:48.774891, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
a1cb1cf61e5441c2a772b29d3cd54202, _context_read_deleted: no,
_context_request_id: req-db34ba32-8bd9-4cd5-b7b5-43705a9e258e, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:37:50.463586, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [admin], _msg_id:
ebb0b1c340de4024a22eafec9d0a2d66, _context_read_deleted: no,
_context_request_id: req-ddb51b2b-a29f-4aad-909d-3f7f79f053c4, args:
{instance_id: 6, instance_uuid: e3ad17e6-dd59-4b67-a7d0-e3812f96c2d7,
host: ubuntu, project_id: c290118b14564257be26a2cb901721a2,
rxtx_factor: 1.0}, _context_auth_token: null, _context_is_admin: true,
_context_project_id: null, _context_timestamp:
2012-03-24T01:38:59.217333, _context_user_id: null, method:
get_instance_nw_info, _context_remote_address: null}'
[x] Received '{_context_roles: [Member], _msg_id:
729535c00d224414a98286e9ce3475a9, _context_read_deleted: no,
_context_request_id: req-b056a8cc-3542-41a9-9e58-8fb592086264,
_context_auth_token: deb477655fba448e85199f7e559da77a, _context_is_admin:
false, _context_project_id: df3827f76f714b1e8f31675caf84ae9d,
_context_timestamp: 2012-03-24T01:39:19.813393, _context_user_id:
abe21eb7e6884547810f0a43c216e6a6, method: get_floating_ips_by_project,
_context_remote_address: 192.168.1.41}'
[x] Received '{_context_roles: [Member, admin], _context_request_id:
req-45e6c2af-52c7-4de3-af6c-6b2f7520cfd5, _context_read_deleted: no,
args: {request_spec: {num_instances: 1, block_device_mapping: [],
image: {status: active, name: cirros-0.3.0-x86_64-uec, deleted:
false, container_format: ami, created_at: 2012-03-20 17:37:08,
disk_format: ami, updated_at: 2012-03-20 17:37:08, properties:
{kernel_id: 6b700d25-3293-420a-82e4-8247d4b0da2a, ramdisk_id:
22b10c35-c868-4470-84ef-54ae9f17a977}, min_ram: 0, checksum:
2f81976cae15c16ef0010c51e3a6c163, min_disk: 0, is_public: true,
deleted_at: null, id: f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525, size:
25165824}, instance_type: {root_gb: 0, name: m1.tiny, deleted: false,
created_at: null, ephemeral_gb: 0, updated_at: null, memory_mb: 512,
vcpus: 1, flavorid: 1, swap: 0, rxtx_factor: 1.0, extra_specs: {},
deleted_at: null, vcpu_weight: null, id: 2}, instance_properties:
{vm_state: building, ephemeral_gb: 0, access_ip_v6: null,
access_ip_v4: null, kernel_id: 6b700d25-3293-420a-82e4-8247d4b0da2a,
key_name: testssh, ramdisk_id: 22b10c35-c868-4470-84ef-54ae9f17a977,
instance_type_id: 2, user_data: dGhpcyBpcyBteSB1c2VyIGRhdGE=, vm_mode:
null, display_name: eureka, config_drive_id: , reservation_id:
r-xtzjx50j, key_data: ssh-rsa
B3NzaC1yc2EDAQABgQDJ31tdayh1xnAY+JO/ZVdg5L83CsIU7qaOmFubdH7zlg2jjS9JmkPNANj99zx+UHg5F5JKGMef9M8VP/V89D5g0oIjIJtBdFpKOScBo3yJ1vteW5ItImH8h9TldymHf+CWNVY1oNNqzXqAb41xwUUDNvgeXHRZNnE6tmwZO0oC1Q==
stack@ubuntu\n, root_gb: 0, user_id: abe21eb7e6884547810f0a43c216e6a6,
uuid: 40b5a1c5-bd4f-40ee-ae0a-73e0bc927431, root_device_name: null,
availability_zone: null, launch_time: 2012-03-24T01:39:52Z, metadata:
{}, display_description: eureka, memory_mb: 512, launch_index: 0,
vcpus: 1, locked: false, image_ref:
f7d4bea2-2aed-4bf3-a5cb-db6a34c4a525, architecture: null, power_state: 0,
auto_disk_config: null, progress: 0, os_type: null, project_id:
df3827f76f714b1e8f31675caf84ae9d, config_drive: }, security_group:
[default]}, is_first_time: true, filter_properties: {scheduler_hints:
{}}, topic: compute, admin_password: SKohh79r956J, injected_files:
[], requested_networks: null}, _context_auth_token:
deb477655fba448e85199f7e559da77a, _context_is_admin: false,
_context_project_id: df3827f76f714b1e8f31675caf84ae9d,
_context_timestamp: 2012-03-24T01:39:52.089383,
Re: [Openstack] New OpenStack Releases in Ubuntu 12.04LTS
Robbie, this is just as awesome as AWESOME and has as much mass as MAAS. With this support, you may have solved one of DreamHost's long-standing logistical issues around our cloud efforts. Thanks, Ubuntu and Canonical! d On Mon, Apr 23, 2012 at 11:02 AM, Robbie Williamson rob...@ubuntu.com wrote: For those of you who may have missed this announcement. Canonical has created the Ubuntu Cloud archive. Starting with the Folsum release, users will be able to elect to enable this archive, and install newer releases of OpenStack (and the dependencies) as they become available up through the next Ubuntu LTS release (presumably 14.04). Bug processing and patch contributions will follow standard Ubuntu practice and policy where applicable. Canonical commits to maintaining and supporting new OpenStack releases for Ubuntu Server 12.04 LTS in our Ubuntu Cloud archive for at least 18 months after they release. Canonical will stop introducing new releases of OpenStack for Ubuntu Server 12.04 LTS into the Ubuntu Cloud archive with the version shipped in the next Ubuntu Server LTS release (presumably 14.04). We will maintain and support this last updated release of OpenStack in the Ubuntu Cloud archive for 3 years, i.e. until the end of the Ubuntu 12.04 LTS lifecycle. In order to allow for a relatively easy upgrade, and still adhere to Ubuntu processes and policy, we have elected to have archive.canonical.com be the home of the Ubuntu Cloud archive. We will enable update paths for each OpenStack release. e.g. Enabling “precise-folsum” in the archive will provide access to all OpenStack Folsum packages built for Ubuntu Server 12.04 LTS (binary and source), any updated dependencies required, and bug/security fixes made after release. More information on this can be found here: https://wiki.ubuntu.com/ServerTeam/CloudArchive -- Robbie Williamson rob...@ubuntu.com robbiew[irc.freenode.net] Don't make me angry...you wouldn't like me when I'm angry. -Bruce Banner ___ 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] New OpenStack Releases in Ubuntu 12.04LTS
+1 this is HUGE! Duncan McGreggor dun...@dreamhost.com wrote: Robbie, this is just as awesome as AWESOME and has as much mass as MAAS. With this support, you may have solved one of DreamHost's long-standing logistical issues around our cloud efforts. Thanks, Ubuntu and Canonical! d On Mon, Apr 23, 2012 at 11:02 AM, Robbie Williamson rob...@ubuntu.com wrote: For those of you who may have missed this announcement. Canonical has created the Ubuntu Cloud archive. Starting with the Folsum release, users will be able to elect to enable this archive, and install newer releases of OpenStack (and the dependencies) as they become available up through the next Ubuntu LTS release (presumably 14.04). Bug processing and patch contributions will follow standard Ubuntu practice and policy where applicable. Canonical commits to maintaining and supporting new OpenStack releases for Ubuntu Server 12.04 LTS in our Ubuntu Cloud archive for at least 18 months after they release. Canonical will stop introducing new releases of OpenStack for Ubuntu Server 12.04 LTS into the Ubuntu Cloud archive with the version shipped in the next Ubuntu Server LTS release (presumably 14.04). We will maintain and support this last updated release of OpenStack in the Ubuntu Cloud archive for 3 years, i.e. until the end of the Ubuntu 12.04 LTS lifecycle. In order to allow for a relatively easy upgrade, and still adhere to Ubuntu processes and policy, we have elected to have archive.canonical.com be the home of the Ubuntu Cloud archive. We will enable update paths for each OpenStack release. e.g. Enabling “precise-folsum” in the archive will provide access to all OpenStack Folsum packages built for Ubuntu Server 12.04 LTS (binary and source), any updated dependencies required, and bug/security fixes made after release. More information on this can be found here: https://wiki.ubuntu.com/ServerTeam/CloudArchive -- Robbie Williamson rob...@ubuntu.com robbiew[irc.freenode.net] Don't make me angry...you wouldn't like me when I'm angry. -Bruce Banner ___ 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] Shutoff Status
Hi all -
We just added descriptions of each of the statuses to this page, but
SUSPENDED is not one of them:
http://docs.openstack.org/api/openstack-compute/2/content/List_Servers-d1e2078.html
Who has more information about this server status? By grepping the code I
get this additional info which may mean it only applies to bare metal
deploy and/or xenapi?
./nova/api/ec2/cloud.py:vm_states.SUSPENDED: inst_state.SUSPEND,
./nova/api/openstack/common.py:vm_states.SUSPENDED: {
./nova/api/openstack/common.py:'default': 'SUSPENDED',
./nova/compute/api.py:
@check_instance_state(vm_state=[vm_states.SUSPENDED])
./nova/compute/api.py:vm_state=vm_states.SUSPENDED,
./nova/compute/manager.py:
vm_state=vm_states.SUSPENDED,
./nova/compute/power_state.py:SUSPENDED = 0x07
./nova/compute/power_state.py:SUSPENDED: 'suspended',
./nova/compute/vm_states.py:SUSPENDED = 'suspended'
./nova/tests/baremetal/test_proxy_bare_metal.py:
dict(node_id=8, name='i-0008', status=power_state.SUSPENDED),
./nova/tests/test_compute.py: {'vm_state':
vm_states.SUSPENDED})
./nova/tests/test_compute.py:search_opts={'power_state':
power_state.SUSPENDED})
./nova/virt/baremetal/proxy.py:'power_state':
power_state.SUSPENDED})
./nova/virt/xenapi/vm_utils.py:'Suspended': power_state.SUSPENDED,
Thanks,
Anne
On Mon, Apr 23, 2012 at 9:24 AM, Razique Mahroua
razique.mahr...@gmail.comwrote:
Hello Alyssa, the status is the one reported when you suspend your instance
*Nuage Co - Razique Mahroua** *
razique.mahr...@gmail.com
Le 16 avr. 2012 à 18:15, Alyssa Hurtgen a écrit :
Hi all,
I work at Rackspace and noticed a new Nova server status of shutoff.
- What does this status mean?
- How does the server get into this status?
- Should the user be able to perform any actions against the server?
Thanks,
Alyssa Hurtgen
___
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] Canonical AWSOME
+1 - this is important for both incubated projects and vendor implementations. I seem to recall one of the sessions talking about gating commits to passing an upgrade test from the previous stable release and these interfaces are an obvious candidate. Identifying the specific interfaces will take some work, but the plugin points (e.g. scheduler, rpc, etc) are a good starting point. Michael - Michael Fork Cloud Architect, Emerging Solutions IBM Systems Technology Group From: Justin Santa Barbara jus...@fathomdb.com To: Eric Windisch e...@cloudscaling.com, Cc: openstack openstack@lists.launchpad.net Date: 04/23/2012 05:43 PM Subject:Re: [Openstack] Canonical AWSOME Sent by:openstack-bounces+mjfork=us.ibm@lists.launchpad.net On Mon, Apr 23, 2012 at 12:31 PM, Eric Windisch e...@cloudscaling.com wrote: There seemed to be a strong agreement at the summit regarding the need for contracts on those private apis. This is because those APIs are no longer really private, they're shared amongst incubated projects. Furthermore, it seems this may be required to support version heterogeneity during upgrades with versioned RPC calls. The incubated projects could use REST APIs, but we're talking of introducing artificial scaling and reliability constraints to do that. It seems far better to me, if we can have contracts on those internal APIs and use them between the incubated projects. There is a strong enough push to maintain these versions *anyway*. Ah - thanks for explaining that. I'm all for locking down these internal interfaces. I didn't realize people were willing to do so. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp inline: graycol.gif___ 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] Monitoring / Billing Architecture proposed
On 04/23/2012 10:09 PM, Sandy Walsh wrote: Flavor information is copied to the Instance table on creation so the Flavors can change and still be tracked in the Instance. It may just need to be sent in the notification payload. The current events in the system are documented here: http://wiki.openstack.org/SystemUsageData Hi, Metering needs to account for the volume of data sent to external network destinations ( i.e. n4 in http://wiki.openstack.org/EfficientMetering ) or the disk I/O etc. This kind of resource is billable. The information described at http://wiki.openstack.org/SystemUsageData will be used by metering but other data sources need to be harvested as well. Cheers -Sandy On 04/23/2012 02:50 PM, Brian Schott wrote: So, we could build on this. No reason to reinvent, but we might want to expand the number of events. I'm concerned about things like what happens when flavors change over time. Maybe the answer is, always append to the flavor/instance-type table. The code I remember and the admin interface that Ken wrote allowed you to modify flavors. That would break billing unless you also track flavor modifications. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Apr 23, 2012, at 1:40 PM, Luis Gervaso wrote: I have been looking at : http://wiki.openstack.org/SystemUsageData On Mon, Apr 23, 2012 at 7:35 PM, Brian Schott brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com wrote: Is there a document somewhere on what events the services emit? - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com mailto:brian.sch...@nimbisservices.com ph: 443-274-6064 tel:443-274-6064 fx: 443-274-6060 tel:443-274-6060 On Apr 23, 2012, at 12:39 PM, Monsyne Dragon wrote: This already exists in trunk. The Notification system was designed specifically to feed billing and monitoring systems. Basically, we don't want Nova/Glance/etc to be in the business of trying to determine billing logic, since it is different for pretty much everyone, so we just emit notifications to a queue and the interested pull what they want, and aggregate according to their own rules. On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote: Hi, I want to share the architecture i am developing in order to perform the monitorig / billing OpenStack support: 1. AMQP Client which listen to RabbitMQ / QPid (this should be interchangeable) (Own Stuff or ServiceMix / Camel) 2. Events should be stored on a NoSQL document oriented database (I think mongodb is perfect, since we can query in a super easy fashion) We have an existing system called Yagi (https://github.com/Cerberus98/yagi/) that listens to the notification queues and persists events to a Redis database. It then provides feeds as ATOM formatted documents that a billing system can pull to aggregate data, It also can support PubSub notification of clients thru the pubsubhubub protocol, and push events to a long-term archiving store thru the AtomPub protocol. That said, the notification system outputs its events as JSON, so it should be easy to pipe into a json document-oriented db if that's what you need. (we only use ATOM because we have a atom-based archiving/search/aggregation engine (it's open source: http://atomhopper.org/ ) our in-house systems already plug into. ) 3a. The monitoring system can pull/push MongoDB 3b. The billing system can pull to create invoices 4. A mediation EIP should be necessary to integrate a billing/monitoring product. (ServiceMix / Camel) This is to receive your feedback. So please, critics are welcome! Cheers! -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 tel:%28%2B34%29%20627983344 luis@ mailto:luis.gerv...@gmail.comwoorea.es http://woorea.es/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Monsyne M. Dragon OpenStack/Nova cell 210-441-0965 tel:210-441-0965 work x 5014190 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help :
