I don't have time to properly respond, but I'm pretty sure no one on this
team is using single letter variables to save keystrokes.
Is is a good point that abbreviations may be more common in one area than
another. I find both ctx and txn to be completely self explanatory even
with zero context
It was just brought to my attention on IRC that, due to a change to gwacl
after 1.14 was cut, 1.14 doesn't actually build right now (if you just use
the most recent version of gwacl).
The error is
provider/azure/storage.go:96: multiple-value context.GetAnonymousFileURL()
in single-value context
There was an update to support block device mapping that is used by a
branch that got merged to trunk yesterday.
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
On Wed, Oct 30, 2013 at 9:23 AM, John Arbash Meinel
j...@arbash-meinel.comwrote:
2) Agents seem to consume about 17MB resident according to 'top'. That
should mean we can run ~450 agents on an m1.large. Though in my
testing I was running ~450 and still had free memory, so I'm guessing
there
+1
On Thu, Oct 31, 2013 at 8:57 AM, John Arbash Meinel
j...@arbash-meinel.comwrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-10-31 16:21, Andrew Wilkins wrote:
Does anybody object to converting the public entity structs in
state to interfaces? i.e. State, Machine, Unit,
New instance type, high GPU: g2.2xlarge: 15 GiB memory, 26 EC2 Compute
Units, 1 x NVIDIA GRID GPU (Kepler GK104), 60 GB of local instance storage,
64-bit platform
http://phx.corporate-ir.net/phoenix.zhtml?c=176060p=irol-newsArticleID=1872208highlight=
Also, m3 instances dropped in price:
The answer to how does the user know how to X? is the same as it always
has been. Documentation. Now, that's not to say that we still don't need
to do some work to make it intuitive... but I think that for something that
is complicated like HA, leaning on documentation a little more is ok.
More
life. That's kind of the whole point of Juju, right?
On Wed, Nov 6, 2013 at 2:56 PM, Nate Finch nate.fi...@canonical.com wrote:
The answer to how does the user know how to X? is the same as it always
has been. Documentation. Now, that's not to say that we still don't need
to do some work
On Fri, Nov 8, 2013 at 6:34 AM, Gustavo Niemeyer gust...@niemeyer.netwrote:
On Fri, Nov 8, 2013 at 8:31 AM, John Arbash Meinel
j...@arbash-meinel.com wrote:
I would probably avoid putting such an emphasis on any machine can be
a manager machine. But that is my personal opinion. (If you want
Reminds me of one of my favorite quotes:
Knobs are distracting, confusing and annoying. Personally, I'd rather
things be 90% good 100% of the time than see 90 knobs. - Brad Fitzpatrick
on having more than one Go scheduler.
Scaling jobs independently doesn't really get you much. If you need 7
machines of redundancy for mongo... why would you not just also want the
API on all 7 machines? It's 100% upside... now your API is that much more
redundant/scaled, and we already know the API and mongo run just fine
together
...@canonical.comwrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-01-08 03:25 PM, Nate Finch wrote:
It turns out there's a really easy way to avoid this: set up a
billing alert in AWS to email you if your estimated monthly bill
goes over a certain amount for a long enough time.
Note
Actually, after some digging, it looks like billing alerts are only in a
single region. I can't see a way to set billing alerts anywhere except
US-East.
On Wed, Jan 8, 2014 at 4:42 PM, Nate Finch nate.fi...@canonical.com wrote:
Wow, I totally didn't realize you needed one per region. Wish
, 2014 9:07 PM, John Meinel j...@arbash-meinel.com wrote:
Which was sort of the whole point, right? If you had started the
instance in your normal region, you would have seen it and stopped it.
John
=:-
On Jan 9, 2014 2:16 AM, Nate Finch nate.fi...@canonical.com wrote:
Actually, after some
That sounds awesome.
On Wed, Jan 22, 2014 at 6:12 PM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
Hi folks,
I'm working on changing the local provider so that sudo is not needed from
outside Juju; juju bootstrap and juju destroy-environment will prompt
as necessary.
I would like
Penhey tim.pen...@canonical.com wrote:
On 06/02/14 14:14, Nate Finch wrote:
One thing I noticed was that it looked like it wasn't generating an
actual stack trace ever. I think that's pretty critical to knowing how
you got to the spot where you got the error.
I made the default behaviour
On Fri, Feb 7, 2014 at 5:24 AM, roger peppe rogpe...@gmail.com wrote:
http://play.golang.org/p/Ze_YTCcfzm
Note that, even ignoring the doc comment, it is easy to tell by
looking at the high
level function, ReadPacketFromNetwork, what classifiable errors might
be returned from
it. This
I propose we make a small sample program that exercises error returns in
several typical ways, including the non-trivial scenarios, and then make
one implementation for each competing error package, so we can see how they
work out in real code.
The code can be very terse, since there's no need
In some places, we have exposed constants that should not normally be
public as public variables, purely for the purpose of testing. The reason
we need to do that, is because packages can't use code that is only exposed
in _test files for other packages (i.e. package foo has a export_test.go
think this is a pretty good point, so I'll try to come up with a third
way that isn't too cumbersome.
On Mon, Mar 3, 2014 at 12:35 PM, Nate Finch nate.fi...@canonical.comwrote:
In some places, we have exposed constants that should not normally be
public as public variables, purely for the purpose
, Mar 4, 2014 at 7:30 AM, John Meinel j...@arbash-meinel.com wrote:
honestly, http.DefaultClient is a case of global state that too many
people touch, and I'd be happier to avoid them.
On Tue, Mar 4, 2014 at 1:58 PM, roger peppe rogpe...@gmail.com wrote:
On 3 March 2014 17:49, Nate Finch nate.fi
For the record, I'm not a fan of duplicating the package name of anything
in the standard library. Obviously, sometimes collisions will happen if a
new package is added to the standard library, but it seems like a bad idea
to do it on purpose. When you're deep in the middle of a file, and you
I like github. I don't like in-line diffs and one email per code review
comment, which is all github provides. So I did a quick google, and this
came up:
https://review.gerrithub.io/#/c/2160/2/roles/packstack/rdo/tasks/main.yml
it looks pretty good. http://gerrithub.io/
--
Juju-dev mailing
I know some people were working on gwacl, but it seems there were some
breaking changes made (possibly for 1.17.5?) The provider/azure tests are
failing... I took a look but couldn't immediately figure out what was going
wrong...
Looked like Andrew was the last one to change gwacl, maybe you'd
+1
Markdown is great. It's basically the only way to write HTML that is
actually legible outside of a browser (like in diffs, code reviews, as
you're actually writing it, etc).
On Fri, Mar 21, 2014 at 1:47 PM, Marco Ceppi marco.ce...@canonical.comwrote:
Hi everyone,
I'm spreading this
wrote:
Alternatively you can run the tests with -juju.log ERROR (sent from my
phone so unable to double check the extact syntax)
On 26 Mar 2014 19:00, Z. Nate Finch nate.fi...@canonical.com wrote:
So, I often get failed tests that are so obscured by our log output that
I can't even tell what's
What's the difference between Actions and Set? If I do juju set mysql
admins=nate,bill the mysql charm sees the updated admins, and performs
some action (updating permissions in this case). How is that different
from something like juju do setadmins mysql nate,bill ?
On Thu, Mar 27, 2014 at
If anyone has some time to do a very quick review, this change lets us
upgrade from 1.18 to 1.19.
The problem was that trunk was replacing the mongo upstart script of
existing environments to start mongo with --replSet, but we can't actually
support that just yet. So the fix is just to not
My preference would be to convert the scripts into Go executables that do
the exact same thing (to start), which can then start to be refactored to
leverage all the rest of the knowledge embedded in our codebase to do
things like figure out the path to the correct mongo executable, for
example.
We have a bug where Juju is no longer defaulting to the arch of the local
machine, but instead always choosing 386.
Bug #1304407: juju bootstrap defaults to i386 amd64 apport-bug
ec2-images metadata trusty juju-core:Triaged juju-core
1.18:Triaged juju-core (Ubuntu):Triaged
Actually, init is the main command, generate-config is an alias for init
(see juju help commands).
On Wed, May 7, 2014 at 1:55 PM, Nick Veitch nick.vei...@canonical.comwrote:
Nice work, when it is ready we can add it to the getting started
section of the docs too.
Small point - 'juju
Deploying wordpress to the local provider on trusty deploys the precise
version of wordpress (the only version available), which hits this bug
during the install hook:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/969299
The key line is this error from the install hook's code:
failed to
the fstat issue?
All the best,
Charles
On Thu, May 8, 2014 at 2:40 PM, Nate Finch nate.fi...@canonical.comwrote:
Deploying wordpress to the local provider on trusty deploys the precise
version of wordpress (the only version available), which hits this bug
during the install hook:
https
FYI: https://bugs.launchpad.net/charms/+source/wordpress/+bug/1317644
On Thu, May 8, 2014 at 3:20 PM, Charles Butler charles.but...@canonical.com
wrote:
Much Appreciated!
On Thu, May 8, 2014 at 3:19 PM, Nate Finch nate.fi...@canonical.comwrote:
No, but I will. Wanted to make sure I
Personally, I find #3 to be very hard to read. It's very difficult for me
to look at the signature and find the return values, and it's hard for me
to determine where code starts.
My preference is for #1 - let it wrap, and just try to use short names and
few arguments so as to avoid it most of
I was twiddling with gofmt, and I stumbled on this format, which is a lot
more readable for me, if we want to wrap long lines:
func (c *CustomCaller) MethodCaller(
rootName string,
version int,
methodName string,
) (rpcreflect.MethodCaller, error) {
}
On Tue, May 13, 2014 at 12:03 PM, Nate
+1
On May 16, 2014 3:53 AM, William Reade william.re...@canonical.com
wrote:
+1
On Fri, May 16, 2014 at 9:18 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Fri, May 16, 2014 at 3:08 PM, David Cheney david.che...@canonical.com
wrote:
Hello,
This is a proposal that we raise
.
On Tue, May 20, 2014 at 7:24 AM, Nate Finch nate.fi...@canonical.comwrote:
I just noticed that errgo uses loggo for one single debug statement. I
think this is a mistake if we want errgo to be reusable by the community.
We should strive to make our independent packages actually independent
Although using DeepEquals on sorted lists does make for
easier-to-understand test failure messages, the burden on the developer to
sort the slices when they write the test doesn't seem worth it to me. We
write tests a lot more often than we need to debug failing tests. If it
was just slices of
I agree with Roger, I don't think a wrapper around Errgo is the right way
to go. If we don't like the way errgo behaves, we should change it. It's
our package, let's have it work the way we want it to work.
On Thu, May 22, 2014 at 10:47 AM, roger peppe rogpe...@gmail.com wrote:
On 14 May 2014
...@canonical.comwrote:
On 28/05/14 13:31, Nate Finch wrote:
If you're talking about errgo, if all we care about is transition, but
not what the actual types are, we could just record in the list when we
mask the type.
We could, but that would mean walking the list every time you want to
check the cause
I propose we change the name of the package to something other than errgo,
so that Roger can keep his name, and we can make the behavior whatever fits
best for Juju. Yes, we should make it a general-use package, but it should
be designed for Juju, meeting our needs. Roger can post errgo wherever
Today I learned CI isn't running with --debug because they don't want to
expose sensitive data in their jenv... which gets logged when you run with
--debug. However, it also means that we don't get all our really useful
debug log messages when something breaks in CI.
I made a fix for this
What Roger is talking about, is when an error is implementation-specific
and may change if the implementation changes.
For example, if you have a black box service that saves data, it might
write to the network or it might write to a filesystem, but where it saves
is an implementation detail.
a good thing).
On Thu, May 29, 2014 at 3:16 PM, Nate Finch nate.fi...@canonical.com
wrote:
What Roger is talking about, is when an error is implementation-specific
and may change if the implementation changes.
For example, if you have a black box service that saves data, it might
write
Talked with John etc. Sorting is really just a lazy man's out. There's no
reason we can just search through the list and if localhost is there, dial
that one first (actually we decided it should probably *only* dial
localhost if it exists).
On Sun, Jun 1, 2014 at 8:21 AM, Andrew Wilkins
in the import statement of even a large
number of files is not really a huge deal, especially since it can be done
programmatically.
-Nate
On Tue, Jun 3, 2014 at 4:07 AM, roger peppe rogpe...@gmail.com wrote:
On 3 June 2014 00:13, Nate Finch nate.fi...@canonical.com wrote:
Right now, we change tip
There's an option to pass -copy=false which won't copy over the sourcecode.
I don't think we need to keep the external sourcecode in our repo, given
that all our external dependencies are controlled by canonicalers (and we
have N copies of the dependencies where N = the number of people who have
I'm not sure I understand the distinction, Curtis. Backing up the state
data in an HA environment is what I was talking about for large
environments.
On Wed, Jun 4, 2014 at 4:12 PM, Curtis Hovey-Canonical cur...@canonical.com
wrote:
On Wed, Jun 4, 2014 at 3:58 PM, Nate Finch nate.fi
We're making a lot of standalone repos on github so that teams external to
core can reuse core's code.
I think we need to disambiguate between repos that are generally only of
use when working with juju, and repos that are more general purpose. For
example, errgo is a general use package that
I guess what I don't understand is, why does it matter which mongo DB you
back up? They should all be identical, right?
On Thu, Jun 5, 2014 at 12:58 PM, Curtis Hovey-Canonical
cur...@canonical.com wrote:
On Wed, Jun 4, 2014 at 4:36 PM, Nate Finch nate.fi...@canonical.com
wrote:
I'm
+1
On Thu, Jun 5, 2014 at 6:16 PM, Tim Penhey tim.pen...@canonical.com wrote:
On 06/06/14 09:55, Jesse Meek wrote:
I have a branch proposed that displays extra environment information
when the --format flag is used with switch e.g:
$ juju switch local --format yaml
environ-name:
I like Rog's suggestions about switch being all about environment names,
and nothing else, and juju env being about only printing local info about
an environment. Keeping it away from the network is a good thing. If they
want status, they can run status.
On Fri, Jun 6, 2014 at 5:34 AM, roger
That is awesome. I presume that means we can re-re-re-enable HA on local
provider? At least Michael has all the code to do so now, so it should be
quick this time.
Very nice work, Andrew. I'm not sure it ever would have occurred to me
that the storage type would matter.
On Fri, Jun 6, 2014
(Resending since the list didn't like my screenshots)
https://twitter.com/beyang/statuses/474979306112704512
https://github.com/juju/juju/issues/43
Any tooling that exists for go projects is going to default to doing go
get. Developers at all familiar with go, are going to use go get.
People
Ha, that's cute. Honestly, that's still difficult enough to type that I
can't see people typing that every time by hand. Generally you *know* what
environment you want to destroy anyway, and whatever name you picked has to
be easier than typing $(juju env). But it's a useful tip for scripts.
That's awesome, thanks for doing that. I'm interested to see what comes
out of it.
On Mon, Jun 23, 2014 at 5:45 PM, Matthew Williams
matthew.willi...@canonical.com wrote:
Hi Folks,
As some of you will be aware the latest version of go includes some static
analysis tools in godoc:
BTW, Gabirel, the Cloudbase guy I am working with, mentioned that gerritt
allows for dependent reviews I thought some on this list might find
that worth any other objections they might have with gerritt.
I don't know any more about the feature than that, but I figured it was
worth looking
I think these are the results we are looking to get out of this exercise:
1. Have a well-defined and well-documented API that third parties may
consume.
2. Have a clean and well-documented Go implementation of an API wrapper
which third parties may reuse.
3. Make both of these easy
+1 for stable APIs and versioned import statements. If we're worried about
the fact that gopkg.in is run by some random guy* then we're more than
capable of running our own redirector on Canonical's infrastructure.
Gopkg.in is open source, so we can easily get ours up and running with
just a
I noticed that, too. Their code is unfortunately pretty dropbox-specific,
but it is interesting that pretty much everyone doing big projects makes an
error package.
On Mon, Jul 7, 2014 at 8:04 PM, Menno Smits menno.sm...@canonical.com
wrote:
Hey look - another errors package! */me ducks*
I don't think we need to stop the world to get these things fixed. It is
the responsibility of the team leads to make sure someone's actively
working on fixes for regressions. If they're not getting fixed, it's our
fault. We should have one of the team leads pick up the regression and
assign
we've got
enough evidence that the alternative really doesn't fly effectively).
Cheers
William
On Tue, Jul 15, 2014 at 9:37 AM, Nate Finch nate.fi...@canonical.com
wrote:
I don't think we need to stop the world to get these things fixed. It
is the responsibility of the team leads
).
This is then handled by our upstart scripts and redirected into a file.
I *think* there are upstart hooks for log rotation as well, but I may
well be wrong on that.
Tim
On 18/07/14 08:27, Nate Finch wrote:
So, as below, there is a request (again) to do log rotation. For
all-machines.log
With the recent addition of npipe (a windows named pipe package), godeps
can no longer be relied upon to report the full list of dependencies for
juju. Godeps is currently platform-specific, so it'll generate the
dependencies for the current platform, but it won't generate dependencies
included
I'll fix 1342725 https://bugs.launchpad.net/juju-core/+bug/1342725.
Sorry that one hasn't gotten in earlier.
On Tue, Jul 29, 2014 at 2:09 PM, Horacio Duran horacio.du...@canonical.com
wrote:
Since $$fixes-1342937$$ is already committed I changed the state by hand
in the bug report sorry I
It's even easier than that. After doing go get and godeps -u, do a godeps
-t and ensure the output matches dependencies.tsv.
that will ensure that the actual dependencies that exist are the same as
the ones we expect to exist. If they're different, something's wrong.
This will require that
=:-
On Wed, Aug 6, 2014 at 4:13 PM, Tim Penhey tim.pen...@canonical.com
wrote:
On 06/08/14 16:11, Nate Finch wrote:
all-machines.log seems both redundant and a ticking time bomb of disk
space usage. Do we really need it? Can we drop it and maybe later
schedule some time to use something like
log.
Gabriel
On 08.08.2014 12:41, jaquilina wrote:
there is an rsyslog for windows but obviously it requires a license
http://www.rsyslog.com/windows-agent/
On 2014-08-06 16:42, Nate Finch wrote:
Fair enough, I forgot about debug-log. Do we have an idea of how
well aggregate logs
, Aug 08, 2014 at 12:03:21PM -0400, Nate Finch wrote:
[...]
remote syslog and to the local file log, we wouldn't need to worry about
log rotation of the local log screwing up what gets sent to the remote
Do the standard rsyslog log rotation mechanisms not function well?
On Windows, what about
I made a label on github.com/juju/juju (and coincidentally
github.com/juju/utils) called Ready For Review. The reason for the label is
that it is often difficult to figure out what branches are actually ready
to be reviewed and which ones are really WIP and therefore aren't waiting
to be reviewed.
Some of our repos have multiple branches specifically for versioning via
gopkg.in... it would be nice if the default branch in github were the
current version, so when you go to look at the repo online, you're
looking at the version that should be currently used. That way the
activity etc will
I made this pull request: https://github.com/juju/juju/pull/495
It adds a test to run godeps in the root juju directory and ensures that
the output matches dependencies.tsv. This will ensure there's a failing
test if you're trying to run the tests and haven't run godeps -u to make
your
Hmm, that's a good point. This whole only owners can label stuff is
annoying.
I wonder if we should just make everyone owners.
On Aug 11, 2014 5:59 PM, David Cheney david.che...@canonical.com wrote:
What if the review needs the author to rework ?
On Tue, Aug 12, 2014 at 7:55 AM, Nate Finch
I hear this reviewboard thing is pretty cool...
On Aug 12, 2014 5:05 PM, Tim Penhey tim.pen...@canonical.com wrote:
On 12/08/14 10:30, Nate Finch wrote:
Hmm, that's a good point. This whole only owners can label stuff is
annoying.
I wonder if we should just make everyone owners
What's the status on this? I think this could really help our workflow.
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Godeps should pull down new revisions, as of a month or so ago. You just
need to do go get -u launchpad.net/godeps and you'll get the new revision.
I don't believe it go-gets packages you don't already have, though.
On Thu, Aug 14, 2014 at 11:27 AM, Dimiter Naydenov
be +50 -150 than +75 -0. I don't know how to state it any
simpler than that.
On Thu, Aug 14, 2014 at 1:35 PM, Gustavo Niemeyer
gustavo.nieme...@canonical.com wrote:
On Thu, Aug 14, 2014 at 1:35 PM, Nate Finch nate.fi...@canonical.com
wrote:
On Thu, Aug 14, 2014 at 12:24 PM, Gustavo
Just wanted to let people know that Moonstone is ramping up on the customer
pain points, even ahead of the full spec and prioritization. I had talked
to Jorge and Marco about what they thought was important, and they pointed
out a couple of low hanging fruit. This was one of them.
Many charms
on every possible hook (which is how charm writers will
be implementing default-hook, IMO).
John
=:-
On Sat, Aug 16, 2014 at 1:02 AM, Aaron Bentley
aaron.bent...@canonical.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-08-15 04:36 PM, Nate Finch wrote:
There's new hook
On Wed, Aug 20, 2014 at 11:46 AM, Gustavo Niemeyer gust...@niemeyer.net
wrote:
People must be aware that there
is a multitude of events dispatched to that one executable,
potentially with events they do not expect, and they must be aware
that by creating a different hook they will prevent
In an effort to make sure that dependencies.tsv is actually correct, the
tests in github.com/juju/juju now run godeps -t ./... and compare its
output to dependencies.tsv. The test looks for godeps first in the $PATH,
and then in the first $GOPATH/bin. If it is not found, it currently skips
the
/src/pkg/errors
godeps: no version control system found for /usr/lib/go/src/pkg/io
godeps: no version control system found for /usr/lib/go/src/pkg/sync
godeps: no version control system found for
/usr/lib/go/src/pkg/sync/atomic
...
...
On 21/08/14 05:18, Nate Finch wrote:
In an effort
. It Just
Works.
On 21/08/14 10:12, Nate Finch wrote:
What happens when you run godeps normally?
It should ignore the std lib stuff, but I don't actually know how that's
implemented.
On Aug 20, 2014 8:02 PM, Ian Booth ian.bo...@canonical.com wrote:
H. The test fails for me
/juju/go/bin/godeps
On 21/08/14 10:20, Nate Finch wrote:
All the test does is run godeps -t ./... It looks for godeps in the path
first and then looks in gopath/bin. Do you maybe have a version in your
path that is old?
On Aug 20, 2014 8:15 PM, Ian Booth ian.bo...@canonical.com wrote
The point of the test is that developers *don't* run godeps. That's the
problem. The original email noted that our dependencies.tsv in master was
wrong. It's not the first time this has happened. I've also seen many
developers wonder why things were broken when it was just godeps needing to
be
Simplestreams generates files with names like this:
http://maas.ubuntu.com/images/ephemeral-v2/daily/streams/v1/com.ubuntu.maas:daily:v2:download.sjson
Unfortunately, the colons in the filename are illegal on Windows, which
complicates getting tests running on Juju, and getting a
I have a pull request https://github.com/juju/juju/pull/512 for using
Lumberjack https://github.com/natefinch/lumberjack, the log rolling
package I wrote, but the package itself hasn't been reviewed itself. I'd
like to get it reviewed just like any other code we use in Juju. It's
fairly simple
https://github.com/juju/juju/pull/512
Recently rebased and some minor updates. Now that the team leads have
decided to use this, I'd like to get it re-reviewed.
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
Roger was kind enough to review it. If others would like to, that's great,
but it has at least had a good review by someone other than the author now
:)
On Thu, Aug 28, 2014 at 12:35 PM, Nate Finch nate.fi...@canonical.com
wrote:
I have a pull request https://github.com/juju/juju/pull/512
Git blame says ask Roger ;)
100% agree... don't leave in commented out code.
If you feel you must, because you expect it to get uncommented very soon,
then leave a very clear comment about why it was commented out and when it
should get uncommented.
But mostly just don't.
On Fri, Aug 29, 2014
Someone who is allowed to give LGTMs please review PR 512
https://github.com/juju/juju/pull/512
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
I am working on writing a Juju charm to deploy the Discourse discussion
forum software using their new docker image install process. This was my
first charm, and I'm writing it in Go, because I like Go. This means I
can't use the python charm helpers, but since I don't actually know what
they
given that we currently use the path, you can't have one charm for multiple
series anyway. This would at least be better than what we have right now,
and would be backwards compatible (older jujus would just require the old
style local deploy and would ignore the extra series specification in the
On Thu, Sep 4, 2014 at 3:26 AM, John Meinel j...@arbash-meinel.com wrote:
...
Have I mentioned how much I hate YAML? Is it possible to write the
config in JSON or something instead? JSON's no picnic either, but at least
it doesn't care about white space. I'd recommend TOML, but I doubt
https://github.com/blog/1884-introducing-split-diffs
Works a lot better than octosplit, too.
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
A user just complained that he can't bootstrap because Juju is parsing
stderr text from flock, and his server isn't in English, so the error
message isn't matching.
https://github.com/juju/juju/blob/master/environs/sshstorage/storage.go#L254
Now, I think we all know that parsing error text is a
https://bugs.launchpad.net/juju-core/+bug/1367431
Someone from the down under crew, please take a look at this, since the US
is currently at EOD or nearly so.
-Nate
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
...@canonical.com
wrote:
On Wed, Sep 10, 2014 at 4:45 AM, Nate Finch nate.fi...@canonical.com
wrote:
A user just complained that he can't bootstrap because Juju is parsing
stderr text from flock, and his server isn't in English, so the error
message isn't matching.
https://github.com/juju/juju/blob
How much do we care about charm development on Windows (both windows charms
and development on windows machines)?
The reason I ask is that Horacio is starting on the charm-sync task from
the pain points spreadsheet (syncing the charm files local - unit during
charm development debugging).
1 - 100 of 246 matches
Mail list logo
