On Tue, 26 May 2015, Andrew Wilkins wrote:
On Tue, May 26, 2015 at 4:05 AM, Mark Shuttleworth m...@ubuntu.com wrote:
On 25/05/15 18:57, Kapil Thangavelu wrote:
That's super awesome, and very helpful for real world usage. A few
suggestions, For users with multiple environments, seeing a
Thanks for the update. I've closed the bug for now and we'll reopen an
issue to update to the latest api version once that's changed.
On Sun, 03 May 2015, John Meinel wrote:
Just to follow up one small point, Rick. The reason Juju has to fix the API
and restore the old behavior is because even
users.
AFAIK we don't have a great way to respond to clients that behavior is
deprecated, but we can bump the Version of the API and change the behavior.
We definitely should have done that here rather than just remove the
behavior.
John
=:-
On Sun, May 3, 2015 at 3:59 PM, Richard Harding
On Thu, 30 Apr 2015, Nate Finch wrote:
If someone needs 1.18 CLI compatibility, they can use 1.18. It's that
simple. We're maintaining API compatibility for just this reason. If they
don't want the binary to change, they shouldn't update it (or should just
rename it to juju-1.18 or
On Fri, 06 Mar 2015, John George wrote:
To support testing of the latest charm store API, Juju needs to connect to
api.jujucharms.com. However, BaseURL is set to https://store.juju.ubuntu.com
in https://github.com/juju/charm/blob/v4/repo.go
One approach might be to simply add an entry to
Any time there's an API I'd rather we help own and build the community by
providing the client vs relying on others to manage and control the
experience there. Can't +1 it enough.
Rick
On Sat, 20 Dec 2014, David Cheney wrote:
There is no reason for the 130 (at last count) packages that
+1 here, the GUI is already making the other env calls to get state servers
and the like. Adding another api call just means the GUI has to make 2, 3,
etc api requests before it can function which has an overhead we have to
pay in user experience. Making a single info endpoint, even if you have to
Doh, and I completely misread this in my early morning fog and none of this
is an api call and in no way relates to anything so please ignore it and
carry on.
Rick
On Mon, 29 Sep 2014, Richard Harding wrote:
+1 here, the GUI is already making the other env calls to get state servers
On Fri, 19 Sep 2014, Nate Finch wrote:
There's one thing that hasn't been mentioned - reviewboard gives us a
unified review queue.
Can I ask how kanban doesn't do this job for you? I've heard this said a
couple of times but I realized the way I find out what needs to be looked
at is to go to
On Tue, 09 Sep 2014, John Weldon wrote:
Hi;
We're looking for use cases for Juju Actions, mostly to make sure we expose
the right API.
I'm hoping for a few different use cases from the Juju Web UI folks, but
I'd appreciate input from anyone wanting to use Juju Actions in their
charms too.
On Wed, 10 Sep 2014, Stuart Bishop wrote:
On 10 September 2014 19:49, Richard Harding rick.hard...@canonical.com
wrote:
I think most of the use cases presented so far line up with ours. One I
want to call out as interesting and I hadn't thought about is killing a
long running action
For our work on Machine View in the Juju GUI the team needs to help the
user know what can and cannot be done with machines and containers. One of
those things is determining if lxc or kvm containers work on various
providers so the UX will not show users an option we know doesn't work.
Jay wrote
On Tue, 19 Aug 2014, Richard Harding wrote:
Right now I'm hesitant to enable creating containers in Machine View for
anything but MAAS.
Just to clarify, after having some more coffee we can warn users that
expose services that have units in containers in the GUI and it should help
raise
.
At this point only MaaS has route able containers.
John
=:-
On Aug 19, 2014 4:56 PM, Richard Harding rick.hard...@canonical.com
wrote:
On Tue, 19 Aug 2014, Richard Harding wrote:
Right now I'm hesitant to enable creating containers in Machine View for
anything but MAAS.
Just to clarify
On Wed, 23 Jul 2014, Gustavo Niemeyer wrote:
Going back to bundles, not having to update a bundle when a new,
entirely different, release of Ubuntu comes out, is of course much
more expressive, and people love expression, but carries with it a
relevant semantic load. It also means neither we
On Tue, 15 Jul 2014, Aaron Bentley wrote:
On 14-07-15 10:17 AM, roger peppe wrote:
The most significant change is that all endpoints refer just to a
single charm or bundle, rather than being bulk calls as they were
before.
That sounds like the opposite of what juju-reports wants. Does
On Tue, 15 Jul 2014, Aaron Bentley wrote:
I am surprised that juju-reports was not considered a known client. I
certainly made many comments on the first draft of the original proposal.
It is listed under known clients in the spec, and we mentioned your request
down below. What we lack is
Thanks Aaron, can you add the information and arguments you'd like to make
to the doc. Perhaps add a Missing to the doc and provide the information
you'd like to see returned and such there. Does this need both charms and
bundles? As two calls, in one call, etc.
Rick
On Tue, 08 Jul 2014, Aaron
The idea is that the charm store is growing a lot since the original api
was done. It's gaining a first class entity in bundles, it'll be growing
identity support, search functionality, and other metadata. The api space
is growing and needs to be able to be consistent with other tools as they're
We've tried to encourage what we call 'reviewer comments' that are intended
to be to help the reviewer follow the code. There are definitely two chunks
of things that tend to get written. It's quite often to find a reviewer
comment that the reviewer then suggests is put into the code itself.
On Fri, 20 Jun 2014, Cory Johns wrote:
I think that is what Ben is talking about, that as we move bundles
into the core as first-order entities, that is the correct time to
address expanding their scope to include the additional functionality
we have realized they should cover.
This is a
On Thu, 19 Jun 2014, Benjamin Saller wrote:
Some of my recent work with charming Cloud Foundry has led us towards a
slightly different understanding of bundles. In the case of something like
cloud foundry the topology will change between releases of their code, in
version 'b' they might add a
We try to put a main comment on the review. Having inline comments does not
complete the review. So after going through the diff, we go back to the
main pull request and leave a comment there.
This looks good but I had a few concerns about how it's tested. Please
don't forget to update the docs
I've been wanting to get a few minutes of spare time to try out
reviewboard. It's python based, has a charm (though it's outdated) and is
supposed to be nice to use, though I've not used it in any anger yet.
http://www.reviewboard.org/
Rick
On Fri, 06 Jun 2014, Menno Smits wrote:
If we're
On Tue, 20 May 2014, David Cheney wrote:
A possible plan is as follow:
1) Migrate juju-core/thirdparty to juju/thirdparty (Github).
Since there are no dependencies here, this seems to be a good first
candidate.
nac, these are out horrors. The code we forked should either be pushed
On Mon, 10 Mar 2014, Jonathan Aquilina wrote:
I have two suggestions that might help, but first let me tell you a bit
about myself.
I am project manager for LMMS (Linux Multimedia Studio) and we recently
started using github for our version control hosting.
With this we started using
On Fri, 07 Mar 2014, Nate Finch wrote:
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
27 matches
Mail list logo
