Juju,
The note I got from Nate on Azure is below (after wasting a day trying
to get it working...)
At OSCON, I worked with Jorge and even he couldn't get my local VM
working, but I'm willing to give it a try again. I'd be willing to
schedule a meeting (please email me off the list to
I think we need to make sure that we do the best error reporting we can, so
if Juju isn't working because of Azure issues, we should find some way to
let users know that so that they can try another cloud, contact microsoft,
or otherwise find another way forward.
--Mark Ramm
On Mon, Sep 22, 2014
Agreed. There is only one page on Azure, so it would be nice if there
was a note that said
Don't waste your time... Azure isn't working today.
- Mike
On 2014-09-22 09:06, Mark Ramm-Christensen (Canonical.com) wrote:
I think we need to make sure that we do the best error reporting we
can,
http://blog.dasroot.net/juju-digital-ocean-awesome/
Juju on Digital Ocean, WOW! That's all I have to say. Digital Ocean is one
of the fastest cloud hosts around with their SSD backed virtual machines.
To top it off their billing is a no-nonsense straight forward model. $5/mo
for their lowest end
Nice! Digital Ocean really is super fast my Discourse charm takes
21(!) minutes to deploy on an AWS m1.small and 7 minutes on a DO 2GB
droplet, which is 2/3rds the price of the amazon instance.
Kapil's digital ocean plugin really makes it all (relatively) seamless,
too. I look forward to
Michael,
I read the title of this email and my heart sank a little. This reminds me
that we are still moving forward at break neck speed and what ground we've
covered and stepped into the next chapter may not be completely solid for
someone without the experiences that I have myself. When you
Yeah! DO rocks, and like Nate said, can't wait for the real provider !!!
Here's a quote about that from Kapil:
Its possible *(although unscheduled atm) *a real provider could be done for
DO when the provider object storage requirements are dropped from juju
which is work that's scheduled. The
Just a quick note:
Basin has seen we were #1 and sent people over to vote, so we're now in a
tie for the #1 spot on the DO api integration page. If you've used Juju on
DO, please dont hesitate to head over to their community listing and vote
for us!
There is also this:
https://bugs.launchpad.net/juju-core/+bug/1372543
On Mon, Sep 22, 2014 at 12:25 PM, Charles Butler
charles.but...@canonical.com wrote:
Just a quick note:
Basin has seen we were #1 and sent people over to vote, so we're now in a
tie for the #1 spot on the DO api
Something else that would be cool is to submit your blog posts as a
tutorial on DO
On Mon, Sep 22, 2014 at 12:26 PM, Adam Stokes adam.sto...@ubuntu.com wrote:
There is also this:
https://bugs.launchpad.net/juju-core/+bug/1372543
On Mon, Sep 22, 2014 at 12:25 PM, Charles Butler
andrew has almost finished the work on getting providers by default not
using object storage (already quite functional).. The other missing piece
is getting DO to install cloud-init into their default ubuntu images, and
supporting their variation on ec2 metadata api for retrieving userdata
within
It may be still in the ingest-o-tron, pending ~ 20 minutes from posting,
but I've just landed 3 new big data bundles for our data scientists out
there to consume for our new Hortonworks Hadoop stack.
Deploy the base Hadoop Map/Reduce engine:
juju quickstart
Hi Chris!
Awesome work on the charm, I'm not sure I'll ever need to mirror the entire
Ubuntu repository, but if I ever did I'm happy there's a charm for it! I do
like that it leverages the storage charm and is scaleout safe (safe for
bandwidth + wallet too).
Marco
On Sat, Sep 20, 2014 at 10:55
Yes, I realize the use case is pretty narrow :)
You can mirror single components as well (just the apt archives, just cloud
images, etc...), so maybe you can use it as offline helper as well (juju
deploy on the plane?)
Chris
On Sep 23, 2014 6:01 AM, Marco Ceppi marco.ce...@canonical.com wrote:
So Bogdan Teleaga was kind enough to put in the effort to move all of our
source trees to start importing from gopkg.in/check.v1 rather than
depending on labix.org/gocheck.
However, this means that if we land those changes, code that depends on the
testing infrastructure provided by those
That's an interesting observation and I think I agree.
The general rule is probably something like this:
- If a type is part of the exported API of a versioned package and the
package is changed to import that type from somewhere
else, the package's version must be incremented.
Given that
John, Roger,
This situation right here is why I am strongly opposed to the gopkg.in
versioning model. I recommend reverting to the original launchpad
location.
Dave
On Mon, Sep 22, 2014 at 9:56 PM, roger peppe roger.pe...@canonical.com wrote:
That's an interesting observation and I think I
On 22 September 2014 12:59, David Cheney david.che...@canonical.com wrote:
John, Roger,
This situation right here is why I am strongly opposed to the gopkg.in
versioning model. I recommend reverting to the original launchpad
location.
Dave
I understand your concern - having multiple
On Sat, Sep 20, 2014 at 12:01 AM, Jesse Meek jesse.m...@canonical.com wrote:
On 20/09/14 02:34, Eric Snow wrote:
I was not seriously suggesting we return to lp. Using ReviewBoard
reintroduces what we gave up with lp: both the good (tooling that addresses
pain points) and the bad (not a well
So, the automation between github and reviewboard seems necessary, so we
should do that. It shouldn't be hard at all. Then the steps for submitting
code will be:
1.) Submit a PR
2.) Get it reviewed on the automatically-created review.
3.) With a LGTM on the review, mark as $$merge$$ and the bot
Just in case we're counting, another pro:
You are able to seperate pushing branches to github and creating a new
version of code for review
Matty
On Fri, Sep 19, 2014 at 4:37 PM, Eric Snow eric.s...@canonical.com wrote:
Given that I've in some part driven the switch to ReviewBoard, I want
to
21 matches
Mail list logo
