These are awesome!
How did you make them?
On Mar 4, 2012, at 6:51 PM, Armaan wrote:
>
> Hello,
>
> I have created few videos visualising the development history of various
> OpenStack projects. Links for the videos are given below:
>
> (1)Nova: http://www.youtube.com/watch?gl=IN&v=l5Prjqez
Seriously awesome!
On Sunday, March 4, 2012 at 6:51 PM, Armaan wrote:
>
> Hello,
>
> I have created few videos visualising the development history of various
> OpenStack projects. Links for the videos are given below:
>
> (1)Nova: http://www.youtube.com/watch?gl=IN&v=l5PrjqezhgI
> (2)Swif
No kidding... that was amazing to watch :-)
Thanks for doing it and sharing it!!
d
On Sun, Mar 4, 2012 at 10:21 PM, Devin Carlen wrote:
> Seriously awesome!
>
> On Sunday, March 4, 2012 at 6:51 PM, Armaan wrote:
>
>
> Hello,
>
> I have created few videos visualising the development history of v
Awesome, Thanks!
On Mon, Mar 5, 2012 at 10:51 AM, Armaan wrote:
>
> Hello,
>
> I have created few videos visualising the development history of various
> OpenStack projects. Links for the videos are given below:
>
> (1)Nova: http://www.youtube.com/watch?gl=IN&v=l5PrjqezhgI
> (2)Swift: http:/
While we are on the topic of api performance and the database, I have a
few thoughts I'd like to share.
TL;DR:
- we should consider refactoring our wsgi server to leverage multiple
processors
- we could leverage compute-cell database responsibility separataion
to speedup our api database perfo
> Beyond refactoring the way we add in data for response extensions, I think
> the right way to get this database performance is make the compute-cells
> approach the "normal". In this approach, there are at least two nova
> databases, one which lives along with the nova-api nodes, and one that liv
Pretty much +1 to all of that. The other problem I see that a separate 'view'
for the API solves...is state tracking. I feel API should be keeping its own
state on things. What the API allows per the spec should be completely
separated from the services state tracking. As you mention, comput
On Mar 4, 2012, at 8:56 PM, Gabe Westmaas
> I agree with this paragraph whole heartedly! I would definitely like to see
> this separation not only for the reasons you list above (performance, all
> installations behaving the same way) but also because I think it gives us a
> lot more power
when I use "sg libvirtd /data/stack/nova/bin/nova-compute &"
it show:
stack@n-cpu-1:~/nova$ 2012-03-05 13:47:56 CRITICAL nova [-] Unknown
connection type "None"
(nova): TRACE: Traceback (most recent call last):
(nova): TRACE: File "/data/stack/nova/bin/nova-compute", line 47, in
(nova): TRACE: s
What is the environment that you used to deploy this? Did you specify
the connection_type in the nova.conf file?
On 12-03-05 01:53 PM, DeadSun wrote:
when I use "sg libvirtd /data/stack/nova/bin/nova-compute &"
it show:
stack@n-cpu-1:~/nova$ 2012-03-05 13:47:56 CRITICAL nova [-] Unknown
con
10 matches
Mail list logo
