(I've put a more structured proposal below, but here's some context.)
Over the last couple weeks I've been spinning up on the juju code
base, which is large enough to dissipate any hope of understanding it
all quickly. Most of what I've focused on is relative to the
juju tools and the remote API,
Hey Eric,
Some comments below, offering a slightly different perspective to be
used as a data point in your quest.
On Thu, Jun 26, 2014 at 1:41 PM, Eric Snow wrote:
> In the interest of understanding juju better and of making the API
> more accessible, I took a little time to investigate possibl
I have a slightly different proposal, inspired by the recent
Go proposal for internal imports (http://golang.org/s/go14internal),
which currently looks like it will actually be implemented.
We move all public facing APIs into top level packages within
the juju repo, and move everything else under
juju-core 1.19.4
A new development release of Juju, juju-core 1.19.4, is now available.
Getting Juju
juju-core 1.19.4 is available for trusty and backported to earlier
series in the following PPA:
https://launchpad.net/~juju/+archive/devel
Upgrading from stable releases to development rele
We are tracking a list of critical bugs that must be fixed to release 1.20.
https://launchpad.net/juju-core/+milestone/1.20.0
I intend to create a 1.20 branch in
https://github.com/juju/juju
that we can merge fixes into. Actually I have done that, but github
doesn't want me to merge by ver
Hi,
me and Matthew Williams are working on support for port ranges in juju.
There is one question that the networking model document does not answer
explicitly and the simplicity (or complexity) of the implementation depends
greatly on that.
Should we only allow units to close exactly the same por
My belief is that as long as the error messages are clear, and it is easy
to close 8000-9000 and then open 8000-8499 and 8600-9000, we are fine.
Of course it is "nicer" if we can do that automatically for you, but I
don't see why we can't add that later, and I think there is a value in
keeping a p
+1 to Mark's point. Handling exact matches is much easier, and does
not prevent a fancier feature later, if there's ever the need.
On Thu, Jun 26, 2014 at 3:38 PM, Mark Ramm-Christensen (Canonical.com)
wrote:
> My belief is that as long as the error messages are clear, and it is easy to
> close 8
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 into
Hi folks
The Juju 1.19.4 release will serve as a release candidate for Juju 1.20, the
next stable release. There are still a couple of known bugs to fix before 1.20
goes out the door. To allow trunk development to continue unabated, a 1.20
branch has been forked off the rev used to cut 1.19.4:
ht
I'm currently taking a look at #1334273. It could be related to the
"restricted API logins during upgrades" change I made.
On 27 June 2014 06:00, Curtis Hovey-Canonical wrote:
> We are tracking a list of critical bugs that must be fixed to release 1.20.
> https://launchpad.net/juju-core/+mi
Just my quick thought, I think moving it out from "state/api" into just a
top level "api" would be reasonable and a lot less clumsy than trying to
pull it out into an entirely separate repository.
I'm not sure if Gustavo realized that "state/apiserver" is the HTTP(-ish,
its really just JSON rpc o
[Hmm, I'm not sure this got through originally, as I sent it from
my non-work gmail account]
I have a slightly different proposal, inspired by the recent
Go proposal for internal imports (http://golang.org/s/go14internal),
which currently looks like it will actually be implemented.
We move all pu
On Fri, Jun 27, 2014 at 4:21 PM, John Meinel wrote:
> Just my quick thought, I think moving it out from "state/api" into just a
> top level "api" would be reasonable and a lot less clumsy than trying to
> pull it out into an entirely separate repository.
+1
I don't think the api package is usef
14 matches
Mail list logo
