Stefano Maffulli wrote:
Leaving aside naming the tools, what would be the most important
features to have? Here is my personal list, in no particular order:
* good search engine
* ability to promote question and best answer to FAQ
* good looking and nice to use
* custom domain (like
Hello everyone,
Our general meeting will take place at 21:00 UTC this Tuesday in
#openstack-meeting on IRC. PTLs, if you can't make it, please name a
substitute on [2].
We will look at general progress towards essex-2, improving visibility
over the global Essex plans and the status of the client
Hi, guys.
Gosh, this turned out to be long. Sorry about that.
I'm adding some tests for the DB api, and I've stumbled across something
that we should probably discuss.
First of all, most (if not all) of the various *_create methods we have,
return quite amputated objects. Any attempt to access
On Tue, 2011-11-29 at 16:20 +0100, Soren Hansen wrote:
It seems I've talked myself into preferring option e). It's too much
work to do on my own, though, and it's going to be disruptive, so we
need to do it real soon. I think it'll be worth it, though.
I agree. This will also make it easier
I think option e is our best bet. It's the *only* option if we want to
efficiently separate our services (as Jason has pointed out).
Waldon
On Nov 29, 2011, at 10:52 AM, Devin Carlen wrote:
Hey Soren,
On Nov 29, 2011, at 7:20 AM, Soren Hansen wrote:
SQLAlchemy does support looking
On Tue, 2011-11-29 at 16:20 +0100, Soren Hansen wrote:
It seems I've talked myself into preferring option e). It's too much
work to do on my own, though, and it's going to be disruptive, so we
need to do it real soon. I think it'll be worth it, though.
(e) sounds right to me. But hopefully
For this I think we need to separate the models from the queries. A query
method should be able to populate as many of the models as needed to return the
data collected. I also think separating the queries from the models themselves
will help us make the storage engine replaceable, and will
e) is the right solution imho. The only reason joinedloads slipped in is for
efficiency reasons.
In an ideal world the solution would be:
1) (explicitness) Every object or list of related objects is retrieved with an
explicit call:
instance = db.instance_get(id)
ifaces =
Lorin has been a great contributor to Nova for a long time and has been
participating heavily in reviews over the past couple of months. I think he
would be a great addition to nova-core.
Vish
___
Mailing list: https://launchpad.net/~openstack
Post
+1. This sounds like a bug. FYI there are some issues related to adding source
group rules that specify ports that need to be fixed. We have also discussed
whether or not the same group should be allow all by default. In ec2 it does.
I personally like having it explicit like this, but I
On Tue, Nov 29, 2011 at 2:35 AM, Thierry Carrez thie...@openstack.org wrote:
Stefano Maffulli wrote:
Leaving aside naming the tools, what would be the most important
features to have? Here is my personal list, in no particular order:
* good search engine
* ability to promote question and
Hi Donal, hi all,
I'm trying to test the Boot From ISO feature. So I've set a XenServer
host and installed a Ubuntu 11.10 PV DomU in it.
Then I used the following commands but, as you can see in the attached
nova-compute log excerpt, there was a problem.
glance add name=fedora_iso
On Tue, Nov 29, 2011 at 10:49 AM, Jason Kölker jkoel...@rackspace.com wrote:
On Tue, 2011-11-29 at 16:20 +0100, Soren Hansen wrote:
It seems I've talked myself into preferring option e). It's too much
work to do on my own, though, and it's going to be disruptive, so we
need to do it real
+10
On Tue, Nov 29, 2011 at 12:55 PM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
e) is the right solution imho. The only reason joinedloads slipped in is for
efficiency reasons.
In an ideal world the solution would be:
1) (explicitness) Every object or list of related objects is
On 29 Nov 2011 - 17:54, Aaron Lee wrote:
For this I think we need to separate the models from the queries.
+1
A query method should be able to populate as many of the models as
needed to return the data collected. I also think separating the
queries from the models themselves will help us
I like e).
I know it's heresy in some circles, but this approach can also support
the use of SqlAlchemy core, without the use of the SQLAlchemy ORM.
It's more work in some respects, but does allow writing very efficient
queries.
mike
On Tue, Nov 29, 2011 at 9:55 AM, Vishvananda Ishaya
+1
On Nov 29, 2011, at 1:03 PM, Vishvananda Ishaya wrote:
Lorin has been a great contributor to Nova for a long time and has been
participating heavily in reviews over the past couple of months. I think he
would be a great addition to nova-core.
Vish
+1
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Nov 29, 2011, at 1:03 PM, Vishvananda Ishaya wrote:
Lorin has been a great contributor to Nova for a long time and has been
+1 on the thoughts here. Exactly what I meant by my reply. Not sure what the
interface should look like for #2, but we must be able to do it somehow.
- Chris
On Nov 29, 2011, at 11:55 AM, Vishvananda Ishaya wrote:
e) is the right solution imho. The only reason joinedloads slipped in is for
I had a good call with Anne Gentle a few hours ago, 08:00 PT, and got
a first introduction to the fantastic documentation work, and
infrastructure to support it.
There is a lot for me to get up to speed on, and Anne has generously
agreed to continue to mentor me. We'll have another one-on-one
2011/11/29 Vishvananda Ishaya vishvana...@gmail.com:
e) is the right solution imho. The only reason joinedloads slipped in is for
efficiency reasons.
In an ideal world the solution would be:
1) (explicitness) Every object or list of related objects is retrieved with
an explicit call:
On Tue, 2011-11-29 at 10:10 -0800, Lloyd Dewolf wrote:
Where do I find this previous discussion?
around here:
https://lists.launchpad.net/openstack/msg02169.html
What do you think of the requirements we're gathering for the QA
system? I'd like your opinion on that as we move on.
thanks
stef
Inline
On Nov 29, 2011, at 11:16 AM, Soren Hansen wrote:
2011/11/29 Vishvananda Ishaya vishvana...@gmail.com:
e) is the right solution imho. The only reason joinedloads slipped in is
for efficiency reasons.
In an ideal world the solution would be:
1) (explicitness) Every object or
It was here:
http://area51.stackexchange.com/proposals/31788
It was rejected on the grounds of being able to be covered on StackOverflow and
ServerFault.
Vish
On Nov 29, 2011, at 10:10 AM, Lloyd Dewolf wrote:
On Fri, Nov 18, 2011 at 10:38 AM, Anne Gentle a...@openstack.org
wrote: We had
Great, thanks for your contribution! I am guessing that you did not
translate but wrote an independent one, that's fine with us. I've
worked with FLOSS Manuals, an open source documentation community,
where we would encourage new content in another language and not
consider English to be the only
Hi all,
As a follow-up to the interest in simplified Chinese manuals, I would
also like to experiment with English-as-source translations. I had
been delaying a frozen set of English source files but I think we
could just pick a date and start translating if there is enough
interest and we
On 29 Nov 2011 - 13:15, Jay Pipes wrote:
On Tue, Nov 29, 2011 at 10:49 AM, Jason K??lker jkoel...@rackspace.com
wrote:
On Tue, 2011-11-29 at 16:20 +0100, Soren Hansen wrote:
It seems I've talked myself into preferring option e). It's too much
work to do on my own, though, and it's going
On Tue, 2011-11-29 at 10:14 -0800, Michael Pittaro wrote:
* a method or process for flagging topics which should migrate into
documentation and/or the wiki
Sounds interesting. If I understand you correctly, you want to have a
way to mark questions about topics that may be improved in the
2011/11/29 Jay Pipes jaypi...@gmail.com:
There's a very good reason this hasn't happened so far: handling
highly relational datasets with a non-relational data store is a bad
idea. In fact, I seem to remember that is exactly how Nova's data
store started out life (*cough* Redis *cough*)
To be
On Tue, Nov 29, 2011 at 2:58 PM, Soren Hansen so...@linux2go.dk wrote:
2011/11/29 Jay Pipes jaypi...@gmail.com:
There's a very good reason this hasn't happened so far: handling
highly relational datasets with a non-relational data store is a bad
idea. In fact, I seem to remember that is
On Nov 29, 2011, at 11:55 AM, Vishvananda Ishaya wrote:
… some stuff I agree with, then...
something like db.interfaces_get_by_instance(id, hint='fixed_ip'),
This is very similar to ActiveRecord. In a case like this you would say
Instance.find(id, :include = :fixed_ip)
If you are including
It's been a bit over a week since I started this thread. So far we've
agreed that running the test suite is too slow, mostly because there
are too many things in there that aren't unit tests.
We've also discussed my fake db implementation at length. I think
we've generally agreed that it isn't
+1
On Tue, Nov 29, 2011 at 1:03 PM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
Lorin has been a great contributor to Nova for a long time and has been
participating heavily in reviews over the past couple of months. I think he
would be a great addition to nova-core.
Vish
2011/11/29 Jay Pipes jaypi...@gmail.com:
On Tue, Nov 29, 2011 at 2:58 PM, Soren Hansen so...@linux2go.dk wrote:
2011/11/29 Jay Pipes jaypi...@gmail.com:
There's a very good reason this hasn't happened so far: handling
highly relational datasets with a non-relational data store is a bad
idea.
Thanks Vish. Now my failed search makes more sense. Awesome how they
delete it -- invitation to resubmit every month, jokes.
On Tue, Nov 29, 2011 at 11:35 AM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
It was here:
http://area51.stackexchange.com/proposals/31788
It was rejected on the
On Tue, Nov 29, 2011 at 3:43 PM, Soren Hansen so...@linux2go.dk wrote:
2011/11/29 Jay Pipes jaypi...@gmail.com:
Besides, we don't really use transactions. I could easily read the
same data from two separate nodes, make different (irreconcilable)
changes on both nodes, and write them back, and
2011/11/29 Jay Pipes jaypi...@gmail.com:
On Tue, Nov 29, 2011 at 3:43 PM, Soren Hansen so...@linux2go.dk wrote:
2011/11/29 Jay Pipes jaypi...@gmail.com:
Besides, we don't really use transactions. I could easily read the
same data from two separate nodes, make different (irreconcilable)
Off the top of my head, I'd look to see if the compute node can see that ISO SR.
DL
From: Michaël Van de Borne [mailto:michael.vandebo...@cetic.be]
Sent: 29 November 2011 18:15
To: Donal Lafferty; openstack@lists.launchpad.net
Subject: Re: [Openstack] boot from ISO
Hi Donal, hi all,
I'm
+1
-Original Message-
From: Vishvananda Ishaya vishvana...@gmail.com
Sent: Tuesday, November 29, 2011 1:05pm
To: openstack (openstack@lists.launchpad.net) openstack@lists.launchpad.net
Subject: [Openstack] Proposal for Mark McLoughlin to join nova-core
Mark is maintaining openstack
On Mon, 2011-11-28 at 20:57 +, Mark McLoughlin wrote:
Hi Jason,
On Mon, 2011-11-28 at 10:24 -0600, Jason Kölker wrote:
On Mon, 2011-11-28 at 08:06 -0800, Monty Taylor wrote:
The idea is to unify option handling across projects with this new API.
The module would eventually
http://wiki.openstack.org/development/swift/filter
it's not perfect but i think this can help some people at the beginning.
if someone can help me to move this document to Swift Developer
Documentation http://swift.openstack.org/
i will say thank you.
1。 当 proxy 传输成功节点数量 只有 2 的时候， 谁去补全第三个节点？ 怎么补的？
when there is just 2 object server transfer success, who will fill up the
failed one?how?
如果只有三个节点， 两个挂了， 写入失败
if there are 3 object server, 2 node failed, upload fail.
如果只有三个节点， 一个挂了， 三次写入都成功， 另一次失败的写入会被 proxy 转写到 另外的两个节点中的一个， 由于 partition 不同，
On Tue, Nov 29, 2011 at 11:54 AM, Stefano Maffulli
stef...@openstack.org wrote:
On Tue, 2011-11-29 at 10:14 -0800, Michael Pittaro wrote:
* a method or process for flagging topics which should migrate into
documentation and/or the wiki
Sounds interesting. If I understand you correctly, you
On Tue, 2011-11-29 at 16:06 -0800, Michael Pittaro wrote:
A lot of knowledge discovery happens on a QA site, as well as lists
and forums. However, a common problem with those tools is where
the all the knowledge ends up being scattered in those locations
(and often replicated), and the real
On Tue, Nov 29, 2011 at 11:16 AM, Stefano Maffulli
stef...@openstack.org wrote:
On Tue, 2011-11-29 at 10:10 -0800, Lloyd Dewolf wrote:
Where do I find this previous discussion?
around here:
https://lists.launchpad.net/openstack/msg02169.html
What do you think of the requirements we're
Seattle Area Stackers,
We're having an informal meetup at the Opscode HQ
(http://www.opscode.com/about/#contact) tomorrow.
Rob
__
Rob Hirschfeld
Principal Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
blog robhirschfeld.com, twitter @zehicle
Hi folks
Jay
Thank you for your pointing this!:)
Hey OpenStackers,please help forward-porting :P
Soren
Anything else around unit testing anyone wants to get into The Great
Big Plan[tm]?
And also, we should have a policy for unit test.
Something like this
- New code should have a concrete
+1
On 11/29/2011 02:12 PM, Dan Prince wrote:
+1
-Original Message-
From: Vishvananda Ishaya vishvana...@gmail.com
Sent: Tuesday, November 29, 2011 1:05pm
To: openstack (openstack@lists.launchpad.net)
openstack@lists.launchpad.net
Subject: [Openstack] Proposal for Mark
Anyone have anything you'd like to discuss today?
Jonathan
___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help :
49 matches
Mail list logo
