-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 08/03/2015 02:24 PM, Jesse Cook wrote:
Performance tests against 1000 node clusters being setup by OSIC?
Sounds like you have a playground for your tests.
Unfortunately, the consensus of the nova cores during the mid-cycle
meetup was that
Rally? Something else? What can we do to measure this?
Of cause, if you looking for instrument for measure performance - Rally is
the best choice!
On Tue, Aug 4, 2015 at 5:38 PM, Ed Leafe e...@leafe.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 08/03/2015 02:24 PM, Jesse Cook
Jesse J. CookCompute Team Lead
jesse.c...@rackspace.com
irc: #compute-eng (gimchi)
mobile: 618-530-0659
https://rackspacemarketing.com/signatyourEmail/
https://www.linkedin.com/pub/jesse-cook/8/292/620
https://plus.google.com/u/0/+JesseCooks/posts/p/pub
On 7/20/15, 12:40 PM, Clint Byrum
On 7/15/15, 9:18 AM, Ed Leafe e...@leafe.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Changing the architecture of a complex system such as Nova is never
easy, even when we know that the design isn't working as well as we
need it to. And it's even more frustrating because when the
Excerpts from Jesse Cook's message of 2015-07-20 07:48:46 -0700:
On 7/15/15, 9:18 AM, Ed Leafe e...@leafe.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Changing the architecture of a complex system such as Nova is never
easy, even when we know that the design isn't working
On 07/20/2015 02:04 PM, Clint Byrum wrote:
Excerpts from Chris Friesen's message of 2015-07-20 12:17:29 -0700:
Some questions:
1) Could you elaborate a bit on how this would work? I don't quite understand
how you would handle a request for booting an instance with a certain set of
I have a feeling that we really need to make whatever this selection
process has clearly defined API boundaries, so that various
'implementation experiments' can be used (and researched on).
Those API boundaries will be what scheduling entities must provide but
the implementations could be
On 07/20/2015 11:40 AM, Clint Byrum wrote:
To your earlier point about state being abused in the system, I
totally 100% agree. In the past I've wondered a lot if there can be a
worker model, where compute hosts all try to grab work off queues if
they have available resources. So API requests
Excerpts from Chris Friesen's message of 2015-07-20 12:17:29 -0700:
On 07/20/2015 11:40 AM, Clint Byrum wrote:
To your earlier point about state being abused in the system, I
totally 100% agree. In the past I've wondered a lot if there can be a
worker model, where compute hosts all try to
Excerpts from Chris Friesen's message of 2015-07-20 14:30:53 -0700:
On 07/20/2015 02:04 PM, Clint Byrum wrote:
Excerpts from Chris Friesen's message of 2015-07-20 12:17:29 -0700:
Some questions:
1) Could you elaborate a bit on how this would work? I don't quite
understand
how you
Excerpts from Joshua Harlow's message of 2015-07-20 14:57:48 -0700:
I have a feeling that we really need to make whatever this selection
process has clearly defined API boundaries, so that various
'implementation experiments' can be used (and researched on).
Those API boundaries will be
Clint Byrum wrote:
Excerpts from Chris Friesen's message of 2015-07-20 14:30:53 -0700:
On 07/20/2015 02:04 PM, Clint Byrum wrote:
Excerpts from Chris Friesen's message of 2015-07-20 12:17:29 -0700:
Some questions:
1) Could you elaborate a bit on how this would work? I don't quite understand
On 15 July 2015 at 19:25, Robert Collins robe...@robertcollins.net wrote:
On 16 July 2015 at 02:18, Ed Leafe e...@leafe.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
...
What I'd like to investigate is replacing the current design of having
the compute nodes communicating with
Chris Friesen wrote:
On 07/15/2015 09:31 AM, Joshua Harlow wrote:
I do like experiments!
What about going even farther and trying to integrate somehow into mesos?
https://mesos.apache.org/documentation/latest/mesos-architecture/
Replace the hadooop executor, MPI executor with a 'VM executor'
On 16 July 2015 at 02:18, Ed Leafe e...@leafe.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
...
What I'd like to investigate is replacing the current design of having
the compute nodes communicating with the scheduler via message queues.
This design is overly complex and has
What you describe is a spike. It's a grand plan, and you don't need
anyone's permission, so huzzah for the spike!
As far as what should be improved, I hear a lot that having multiple
schedulers does not scale well, so I'd suggest that as a primary target
(maybe measure the _current_ problem, and
On Jul 15, 2015, at 1:08 PM, Maish Saidel-Keesing mais...@maishsk.com wrote:
* Consider the cost of introducing a brand new technology into the
deployer space. If there _is_ a way to get the desired improvement with,
say, just MySQL and some clever sharding, then that might be a smaller
pill
On 16 July 2015 at 07:27, Ed Leafe e...@leafe.com wrote:
On Jul 15, 2015, at 1:08 PM, Maish Saidel-Keesing mais...@maishsk.com wrote:
* Consider the cost of introducing a brand new technology into the
deployer space. If there _is_ a way to get the desired improvement with,
say, just MySQL and
On 07/15/15 20:40, Clint Byrum wrote:
What you describe is a spike. It's a grand plan, and you don't need
anyone's permission, so huzzah for the spike!
As far as what should be improved, I hear a lot that having multiple
schedulers does not scale well, so I'd suggest that as a primary target
On 07/15/2015 09:31 AM, Joshua Harlow wrote:
I do like experiments!
What about going even farther and trying to integrate somehow into mesos?
https://mesos.apache.org/documentation/latest/mesos-architecture/
Replace the hadooop executor, MPI executor with a 'VM executor' and perhaps we
could
Chris Friesen wrote:
On 07/15/2015 09:31 AM, Joshua Harlow wrote:
I do like experiments!
What about going even farther and trying to integrate somehow into mesos?
https://mesos.apache.org/documentation/latest/mesos-architecture/
Replace the hadooop executor, MPI executor with a 'VM executor'
On 07/15/2015 08:18 AM, Ed Leafe wrote:
What I'd like to investigate is replacing the current design of having
the compute nodes communicating with the scheduler via message queues.
This design is overly complex and has several known scalability
issues. My thought is to replace this with a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Changing the architecture of a complex system such as Nova is never
easy, even when we know that the design isn't working as well as we
need it to. And it's even more frustrating because when the change is
complete, it's hard to know if the
I do like experiments!
What about going even farther and trying to integrate somehow into mesos?
https://mesos.apache.org/documentation/latest/mesos-architecture/
Replace the hadooop executor, MPI executor with a 'VM executor' and
perhaps we could eliminate a large part of the scheduler code
On 7/15/2015 9:18 AM, Ed Leafe wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Changing the architecture of a complex system such as Nova is never
easy, even when we know that the design isn't working as well as we
need it to. And it's even more frustrating because when the change is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/15/2015 09:49 AM, Matt Riedemann wrote:
Without reading the whole thread, couldn't you just do a feature
branch (but that would require reviews in gerrit which we don't
want), or fork the repo in github and just hack on it there without
26 matches
Mail list logo
