On 27/08/14 00:10, Matt Bruzek wrote:
First and most importantly the hpcc charm deploys according to the readme
file! I had to increase the memory constraints on the HP-cloud to 4GB per
machine (juju set-constraints mem=4GB) so all the services had enough
memory to start up. After that I was
It is a nice idea, but it should definitely fire up a warning saying
that the machine will have larger specs, as well as asking for
confirmation. I don't want to see any surprise charges in my AWS bills!
On 08/27/2014 02:34 AM, Mark Shuttleworth wrote:
On 27/08/14 00:10, Matt Bruzek wrote:
I am tentatively +1 for adding some charm metadata for minimum requirements
for the charm. We could certainly add that kind of information in the
README but having it in the metadata would make it automatic (magic).
José makes a great point about how something like this could increase the
cloud
Amir Sanjar and I have been hard at work on grinding out Hadoop bundles for
mass consumption. To those of you that have never deployed hadoop before,
it can be a long winded process that spans many days when done manually.
We've distilled the process down to dragging and dropping on the GUI, and
This is freaking sweet!
Everyday, the more and more we talk to customers on the Partner and
Enterprise side, the #1 conversation that captures their interest is :
Reference architectures.
These architectures spurn ideas, they prompt improvements in architectural
design, help to drive
Grabbing for next UWN issue!
--
José Antonio Rey
On Aug 27, 2014 8:10 PM, Antonio Rosales antonio.rosa...@canonical.com
wrote:
Chuck,
Thanks for also posting this to your blog to @
http://blog.dasroot.net/juju-3s-big-data/
Thanks Chuck and Amir for distilling your Big Data knowledge into
Hi David,
(some comments in-line)
As a user that wants to deploy a charm on a Windows machine, I want to
be able to have a local log file on that machine for the machine agent
and for the units deployed to it. I also want to be able to aggregate
all those logs the same way Ubuntu workloads do
On 27.08.2014 08:12, John Meinel wrote:
...
I may be misremembering, but at the time that was the preferred approach. But
then someone said Go's inbuilt syslog APIs were broke, so the compromise was
to
use rsyslog forwarding.
Does anyone else recall why it may have been said that Go's
That one is an easy fix in any case. We are using a forked version of the
syslog package. Removing the pid from the writeString() method should be
trivial.
Gabriel
On 27.08.2014 13:45, John Meinel wrote:
So at the very least our default logging *doesn't* include the PID, though the
rest
So I played around with manually assigning IP addresses to a machine, and
using BTRFS to make the LXC instances cheap in terms of disk space.
I had success bringing up LXC instances that I created directly, I haven't
gotten to the point where I could use Juju for the intermediate steps. See
the
On Wed, Aug 27, 2014 at 9:17 AM, John A Meinel john.mei...@canonical.com
wrote:
So I played around with manually assigning IP addresses to a machine, and
using BTRFS to make the LXC instances cheap in terms of disk space.
I had success bringing up LXC instances that I created directly, I
11 matches
Mail list logo
