On Mon, May 9, 2016 at 10:50 AM, Eric Snow <eric.s...@canonical.com> wrote:
> I'll check it with 1.25 too, though I expect that the result will be the same.
Under 1.25, using the local provider, I was able to reproduce the
behavior. On the and even got the same confusing log entry:
On Mon, May 9, 2016 at 1:56 AM, Andrew Wilkins
wrote:
> But... I've just looked at the 1.25 branch again, and the fix *was* made
> there. And from Jorge's comment
> https://bugs.launchpad.net/juju-core/+bug/1514874/comments/4, we can see
> that the uninstall logic
On Fri, May 6, 2016 at 11:37 AM, William Reade
<william.re...@canonical.com> wrote:
> On Fri, May 6, 2016 at 5:50 PM, Eric Snow <eric.s...@canonical.com> wrote:
>>
>> See https://bugs.launchpad.net/juju-core/+bug/1514874.
>
>
> Mainly, we just shouldn't do it. T
See https://bugs.launchpad.net/juju-core/+bug/1514874.
When starting, the machine agent starts up several workers in a runner
(more or less the same in 1.25 and 2.0). Then it waits for the runner
to stop. If one of the workers has a "fatal" error then the runner
stops and the machine agent
On Wed, Apr 27, 2016 at 9:14 PM, Nate Finch wrote:
> So, I don't really think the method of testing should determine where a test
> lives or how it is run. I could test the exact same things with a more
> common unit test - check the tls config we use when dialing the
On Mon, Apr 25, 2016 at 5:24 PM, Menno Smits wrote:
> A per-model flag which indicates that the model should automatically upgrade
> when the controller does might be nice too (this what #7 means I think?).
I meant a CLI flag for "juju upgrade-juju". If I understood
On Mon, Apr 25, 2016 at 6:38 PM, Andrew Wilkins
wrote:
> Whatever we do, #2 should never be optional.
Agreed.
>
> I would like us to have all of #2, #3, #4, #7.
This is my opinion too. Menno suggested another option (call it #8):
a model config setting equivalent
In a recent bug I was working on the issue of auto-upgrading models
came up. I also ran into this personally not too long ago.
Currently, running "juju upgrade-juju -m admin --upload-tools"[1]
upgrades the admin model to a new version. To set the version of any
other model to the uploaded one,
Perhaps we should move the implementation of some providers over to
the repos for the projects with which the providers interact (and then
just import them in providers/all). Then those providers would be
more likely to stay up-to-date in the face of changes in the project,
particularly
On Fri, Mar 18, 2016 at 8:57 AM, Tom Barber wrote:
> c) upload files with actions. Currently for some things I need to pass in
> some files then trigger an action on the unit upon that file. It would be
> good to say path=/tmp/myfile.xyz and have the action upload that
On Fri, Mar 18, 2016 at 8:57 AM, Tom Barber wrote:
> c) upload files with actions. Currently for some things I need to pass in
> some files then trigger an action on the unit upon that file. It would be
> good to say path=/tmp/myfile.xyz and have the action upload that
I also left a review. Mostly LGTM. I just wanted a bit of feedback
before giving it a ship-it. :)
-eric
On Thu, Feb 25, 2016 at 8:11 AM, Andrew McDermott
wrote:
> I took a quick look through it as I was OCR - comments in RB.
>
> On 25 February 2016 at 15:00,
On Fri, Nov 27, 2015 at 9:00 AM, Marco Ceppi wrote:
> On Fri, Nov 27, 2015 at 9:37 AM Aaron Bentley
> wrote:
>> Requirements
>>
>> - Running Wily (LXD is installed by default)
>>
>
> For the LXD provider, I have the latest LXD
On Fri, Nov 27, 2015 at 9:00 AM, Marco Ceppi wrote:
> On Fri, Nov 27, 2015 at 9:37 AM Aaron Bentley
> wrote:
>> Requirements
>>
>> - Running Wily (LXD is installed by default)
>>
>
> For the LXD provider, I have the latest LXD
On Mon, Nov 23, 2015 at 9:32 PM, Nate Finch wrote:
> Last week, I had trouble landing code in gopkg.in/juju/charm.v6-unstable,
I had a similar experience last week with backward-incompatible
changes in the utils repo. :(
> and using that code from master of
On Sun, Nov 22, 2015 at 8:50 PM, Tim Penhey wrote:
> Hi all,
>
> I noticed that the lxd provider was now in master and attempted to use
> it to help debug an HA problem.
>
> In environments.yaml file I added a very simple clause:
>
>lxd:
> type: lxd
This is
On Fri, Nov 6, 2015 at 8:41 AM, Aaron Bentley
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> That may be true, but the LXD provider branch has a stale version
> number. Once the version number is updated to 1.26-alpha2, I imagine
> the lxd provider
@Sergey, do you know how this works out?
-eric
On Thu, Oct 1, 2015 at 2:06 PM, Trond Viggo Håpnes
wrote:
> Hi all
>
> The documentation for the vmware provider [1] states that "you will need to
> have an existing vSphere
> installation, which supports VMWare's Hardware
All,
After posting a review request (i.e. a PR), please be sure to add a
link to the review request/PR (as a comment) to the lp issue the patch
addresses. Otherwise it's a pain trying to track down which commits
actually relate to the issue.
Similarly, be sure to include a link to the related
On Tue, Jun 2, 2015 at 5:57 AM, Katherine Cox-Buday
katherine.cox-bu...@canonical.com wrote:
I think there was an effort to remove this from our code, but I thought I'd
send out a reminder to check and for personal projects. May the source be
with you...
code.google.com/p/winsvc is the only
On Wed, May 13, 2015 at 9:59 PM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
Main thing that concerns me is that it's all opt-in.
Same here.
I guess it doesn't
matter
too much, as long as CI continues to run all the tests. There's nothing
stopping
people from skipping running the
We've had discussions here a couple of times (since I joined the team)
about classifying tests in our suite so they could be run more
flexibly. We've also already added explicit handling for a specific
kind of test along those same lines: featuretests. Additionally you
can think of the CI tests
We have info in the release notes [1], but looks like we have a gap in
the docs (I'll follow up on that). Also, it looks like the release
notes did not get updated with the auth-file config option that
Andrew mentioned.
Feel free to ping me if Andrew's and Curtis' comments don't take care
of it
On Thu, Mar 26, 2015 at 7:53 PM, Nate Finch nate.fi...@canonical.com wrote:
tl;dr: godeps overrides gopkg.in, so you can have godeps pin a commit from a
different branch than gopkg.in is retrieving (i.e. make a release-number
branch, like 1.22 and use godeps to pin commits from there, even if
On Fri, Mar 27, 2015 at 9:59 AM, Nate Finch nate.fi...@canonical.com wrote:
Just an FYI:
As you've probably heard, code.google.com is going away. It'll be read-only
for a year IIRC and then poof.
Most of the packages from the go authors lived there (crypto, etc), but now
will be maintained
On Thu, Mar 26, 2015 at 11:07 AM, Vahric Muhtaryan vah...@doruk.net.tr wrote:
Hello ,
I saw that google cloud engine is added as an supported provider , still
there is no any date about integration of vmware ?
I'm not sure of specific release plans, Alexis can fill you in more
specifically.
On Tue, Mar 24, 2015 at 9:25 PM, Tim Penhey tim.pen...@canonical.com wrote:
I'm seriously not in favour of calling it recover, and not just
because it has a particular meaning in Go.
I'm glad you said so then. :)
Perhaps rebuild or recreate, but recover feels wrong.
Got it. I'm not married
On Wed, Mar 25, 2015 at 1:04 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
Hey folks,
I just signed up for a GCE trial, and tested out the provider on master.
Found a couple of issues.
I've filed https://bugs.launchpad.net/juju-core/+bug/1436191. I suspect the
same issue would
On Wed, Mar 25, 2015 at 4:14 AM, roger peppe roger.pe...@canonical.com wrote:
Ooh, a proper bikeshed!
:)
If this command is still doing the same thing it was when
I first wrote the original hack version, then it's more like
On Wed, Mar 25, 2015 at 8:00 PM, Dimiter Naydenov
dimiter.nayde...@canonical.com wrote:
One thing to bear in mind. It seems the europe-west1-a AZ is
considered deprecated and will be shut down soon (end of this month
I believe).
It will be nice to skip this AZ when trying to place instances.
juju 1.23 adds the new restore, all written in Go and integrated into
core. This is a great thing and the result of a lot of effort by
Horacio. In discussions with him about it, there are two things that
came up that I wanted to bring up here.
First, the name restore is misleading. It gives
I've opened https://bugs.launchpad.net/juju-core/+bug/1435413 for
renaming restore to recover.
-eric
On Mon, Mar 23, 2015 at 10:00 AM, Horacio Duran
horacio.du...@canonical.com wrote:
Nope this is not very accurate I believe that you got some parts wrong out
of our conversation. I am currently
.
From: Eric Snow [eric.s...@canonical.com]
Sent: Thursday, March 19, 2015 4:33 PM
To: Gabriel Samfira
Cc: juju-dev@lists.ubuntu.com
Subject: Re: Testing on windows
Thanks for bringing this up. And thanks to Bogdan (and anyone else
involved) for writing up that great walkthrough! I had
Thanks for bringing this up. And thanks to Bogdan (and anyone else
involved) for writing up that great walkthrough! I had expected it to
be more complicated. I'm going to be running the unit tests on
windows from now on. :) I'm sure I've broken then a bunch in the last
couple weeks.
What
I realized today that some folks may not be aware of some of the
helpful columns in the reviewboard dashboard. You can see the full
list of available columns by clicking on the pencil icon on the right.
There are a handful of columns that I've found really helpful to me as
a reviewer. Most
On Wed, Feb 11, 2015 at 6:43 PM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
Looks okay in principal, though I'm not sure how much benefit it would
add to the existing, tailored fakes in the codebase. It seems a little bit
weird that error results are encapsulated, but not non-error
On Sun, Jan 11, 2015 at 8:17 PM, Tim Penhey tim.pen...@canonical.com wrote:
This is because the EC2 provider tags the machines with the environment
name, and not environment UUID. I think we should change this ASAP.
Tim, I'm glad you brought this up. We have followed the lead of the
EC2
Thanks for writing this up, Katherine!
On Thu, Dec 11, 2014 at 9:21 AM, Katherine Cox-Buday
katherine.cox-bu...@canonical.com wrote:
go generate
https://golang.org/doc/go1.4#gogenerate
This is *very* powerful and could reduce the number of copy/paste snippets,
or unsafe reflection code we
On Wed, Dec 10, 2014 at 8:23 AM, Kapil Thangavelu
kapil.thangav...@canonical.com wrote:
On Wed, Dec 10, 2014 at 10:16 AM, Eric Snow eric.s...@canonical.com wrote:
It would be great if we could leverage what you've done to be
more visible to customers. Having similar support for Puppet, Chef
The reaction I get most often from folks that aren't familiar with
juju and skim through the juju site is that it looks like a competitor
to the various configuration management tools out there like Puppet or
Salt. However, my experience is that while they have some overlap,
they sit at different
On Tue, Nov 18, 2014 at 5:13 PM, David Cheney
david.che...@canonical.com wrote:
To quote Butterick's
http://practicaltypography.com/one-space-between-sentences.html
And to quote that same page:
If you have to use a typewriter-style font, you can use two spaces
after sentences. Otherwise,
On Mon, Nov 17, 2014 at 5:10 AM, Dimiter Naydenov
dimiter.nayde...@canonical.com wrote:
I can confirm RB diffs for backports to 1.21 get generated correctly
now, and the PR description is updated to include a link to the RB diff.
Thanks for reporting on this.
There's one issue however -- the
FYI, I was able to solve 3 reviewboard-github integration issues today:
1. pull requests for branches other than master now work (e.g. 1.21 backports)
2. no more hitting rate limits (5000 requests/hour limit instead of 60)
3. pull request bodies now get updated with a link to the new review
On Thu, Nov 13, 2014 at 4:05 PM, David Cheney
david.che...@canonical.com wrote:
Hello,
Please stop adding dependencies to the state package.
The dependency tree for state must go
mgo - state - things that depend on state
At the moment state depends on things like backups, multiwatchers,
On Tue, Nov 11, 2014 at 12:28 PM, Jesse Meek jesse.m...@canonical.com wrote:
The latest three reviews on GitHub (#1103,#1102,#1101) I cannot see in
Review Board. Do we have a loose wire?
For 1101 at least, it's in reviewboard (402).
I'll look into it. I'm pretty sure the github integration
On Fri, Oct 31, 2014 at 8:35 AM, Curtis Hovey-Canonical
cur...@canonical.com wrote:
On Thu, Oct 30, 2014 at 2:10 PM, Eric Snow eric.s...@canonical.com wrote:
What would be the best approach for deprecating the old backup plugin?
I was going to simply gut it (it's a bash script) and stick
The new juju backups create can be used instead of juju backup (a
CLI plugin). So you would think we could deprecate and later remove
the old plugin. Unfortunately, juju backups create won't work with
1.20 or earlier API servers. So it's not quite as simple as I'd hoped
as long as newer clients
On Wed, Oct 29, 2014 at 7:13 PM, Tim Penhey tim.pen...@canonical.com wrote:
Hey there fellow Juju developers,
I'd like to announce Menno's reviewer graduation. I have been very
happy with the quality and understanding shown in Menno's reviews.
Congratulations.
Good job!
-eric
--
On Mon, Oct 27, 2014 at 9:05 PM, Jesse Meek jesse.m...@canonical.com wrote:
Is possible and preferable to show the most recent diff by default?
If you mean instead of showing the reviews page by default,
ReviewBoard doesn't support that out of the box. Certainly we could
customize RB to do so,
with fresh eyes, option 2 seems much more feasible and
palatable. My only concern is that it relies on what amount to
implementation details of mongodump (and mongorestore).
-eric
John
=:-
On Tue, Oct 28, 2014 at 3:07 AM, Eric Snow eric.s...@canonical.com wrote:
For backup we currently
On Tue, Oct 21, 2014 at 11:40 AM, Michael Foord
michael.fo...@canonical.com wrote:
On 20/10/14 22:38, Eric Snow wrote:
This should be resolved now. I've verified it works for me. If it
still impacts anyone, just let me know.
I still have the issue I'm afraid. No reviewer set, no diff
On Tue, Oct 21, 2014 at 3:40 AM, Michael Foord
michael.fo...@canonical.com wrote:
On 20/10/14 22:38, Eric Snow wrote:
This should be resolved now. I've verified it works for me. If it
still impacts anyone, just let me know.
I still have the issue I'm afraid. No reviewer set, no diff
On Tue, Oct 21, 2014 at 10:12 AM, Eric Snow eric.s...@canonical.com wrote:
For now I've hard-coded adding juju-team. If anyone still has trouble
with this please let me know.
The issue with not finding files in the repo should be fixed now.
This means that auto-generated review requests should
to the RB issue page and manually uploaded the generated
diff and published it.
So most definitely the hook generating RB issues have to upload the
diff as well :)
It's coming together, keep up the good work!
Cheers,
Dimiter
On 20.10.2014 16:53, Eric Snow wrote:
On Mon, Oct 20, 2014 at 6
This should be resolved now. I've verified it works for me. If it
still impacts anyone, just let me know.
-eric
On Mon, Oct 20, 2014 at 7:34 PM, Eric Snow eric.s...@canonical.com wrote:
Yeah, this is the same issue that Ian brought up. I'm looking into
it. Sorry for the pain.
-eric
And of course if you see any problems please let me know. :)
-eric
On Sat, Oct 18, 2014 at 7:38 AM, Eric Snow eric.s...@canonical.com wrote:
With the switch to Reviewboard we introduced extra steps to our
workflow (mostly involving rbt). This in turn made things more
difficult for new
With the switch to Reviewboard we introduced extra steps to our
workflow (mostly involving rbt). This in turn made things more
difficult for new/existing contributors. I've been able to take some
time in the last couple weeks to improve the situation by adding some
integration between github and
Also, I did this as a reviewboard extension. All the code is online
(BSD license): https://bitbucket.org/ericsnowcurrently/rb_webhooks_extension.
I haven't charmed it up, but it should be pretty easy to adapt the
charm I wrote for rb_oauth.
-eric
On Sat, Oct 18, 2014 at 7:38 AM, Eric Snow
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
On Fri, Sep 19, 2014 at 7:55 AM, Dimiter Naydenov
dimiter.nayde...@canonical.com wrote:
+1, In addition you can always check
https://github.com/juju/juju/pulls to see what's in the queue. For
sub-repositories it's the same, like
https://github.com/juju/names/pulls. While I agree it's not all
On Fri, Sep 19, 2014 at 8:34 AM, Eric Snow eric.s...@canonical.com wrote:
I agree that reviewboard as we currently have it now adds extra work
to our workflow. Not only does this impact the juju team, but it does
add a stumbling block to more community involvement. However, my firm
belief
On Fri, Sep 19, 2014 at 6:11 AM, Gabriel Samfira
gsamf...@cloudbasesolutions.com wrote:
Just a suggestion:
A git plugin similar to what Gerrit has would simplify things. For example,
Gerrit has a nice little plugin called Review. Simply doing:
git review
In your current branch would push
On Thu, Sep 18, 2014 at 6:32 PM, David Cheney
david.che...@canonical.com wrote:
There were three problem reviewboard was supposed to address, review
comments are sent immediately, no side by side diffs, and no way to to
chained proposals.
It will be worth being extra clear on ReviewBoard's
Given that I've in some part driven the switch to ReviewBoard, I want
to make sure we are all on the same page and any decision on its
future can be made objectively. This is an outgrowth of the current
discussion on whether or not we should ditch reviewboard.
Let's look at the pros and cons of
On Fri, Sep 19, 2014 at 9:37 AM, Eric Snow eric.s...@canonical.com wrote:
Given that I've in some part driven the switch to ReviewBoard, I want
to make sure we are all on the same page and any decision on its
future can be made objectively. This is an outgrowth of the current
discussion
On Sun, Sep 14, 2014 at 10:28 PM, Menno Smits menno.sm...@canonical.com wrote:
Eric,
Thanks for setting this up.
Firstly, in your email you mention rbt pull several times. I think you
mean rbt post right? I don't see a pull command documented anywhere.
Correct. I meant rbt post. :)
I've
On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow eric.s...@canonical.com wrote:
Yeah, those steps are a lot, though keep in mind that effectively it's
only 2 steps more than before if you use the -p flag to rbt post and
were already keeping your local master up to date.
Just to be clear, here
On Mon, Sep 15, 2014 at 11:05 AM, Katherine Cox-Buday
katherine.cox-bu...@canonical.com wrote:
Let me preface this by saying I like the Reviewboard style of reviewing
changes.
It's somewhat concerning to me that our reviews are now disconnected from
what will actually be landed into trunk. In
On Mon, Sep 15, 2014 at 12:54 PM, Dimiter Naydenov
dimiter.nayde...@canonical.com wrote:
- From my meager experience with writing git plugins (any executable in
$PATH with git- prefix), what are you describing can be easily
achieved. If you write a git plugin, named e.g. git-rbpropose, using
Which of the repositories listed at https://github.com/juju should be
set up in reviewboard? I'm pretty sure on most of them, but a more
authoritative list would help me out. In the meantime I'm adding the
ones I'm sure on.
-eric
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify
On Thu, Sep 11, 2014 at 1:34 AM, Frank Mueller
frank.muel...@canonical.com wrote:
For switching to a new tool and a new workflow I would like to not simply
discuss it in a somehow undefined way together with subjunctive terms
(Everybody should now ...) here via mail. Please lets fix the
On Wed, Sep 10, 2014 at 3:34 PM, Menno Smits menno.sm...@canonical.com wrote:
Thanks Eric! I've used Reviewboard at a previous job and I'm fairly sure
that it aligns better with the way the Juju Core team likes to work than
Github's review features.
Two questions:
1. Is this what we're
On Mon, Sep 8, 2014 at 8:05 PM, Tim Penhey tim.pen...@canonical.com wrote:
On 09/09/14 04:32, Eric Snow wrote:
To install rbt:
sudo pip install --allow-unverified rbtools --allow-external rbtools rbtools
Ah... no.
Perhaps in a virtual env.
Is it the sudo or the flags to which you object
been done yet. I'll roll
those out when I can. Also note that for some of the config settings
I'm using values other than what I've listed in the spreadsheet. Each
of those will be changed to the correct value before we switch over.
-eric
On Fri, Sep 5, 2014 at 7:09 PM, Eric Snow eric.s
On Mon, Sep 8, 2014 at 4:37 AM, Ian Booth ian.bo...@canonical.com wrote:
Hi Eric
Fantastic, thank you.
Quick question - can we set up a Juju team group and have that group
automatically be assigned as a reviewer for newly created review requests? I
tried to create a new request using the
On Mon, Sep 8, 2014 at 10:21 AM, Eric Snow eric.s...@canonical.com wrote:
In the meantime I recommend using rbt (as echoed by Adam). I know
As a bonus, rbt allows you to create review requests relative to a
parent revision (ergo branch), so you can chain patches.
Wayne just pointed out to me
On Mon, Sep 8, 2014 at 10:21 AM, Eric Snow eric.s...@canonical.com wrote:
In the meantime I recommend using rbt (as echoed by Adam). I know
As a bonus, rbt allows you to create review requests relative to a
parent revision (ergo branch), so you can chain patches.
To install rbt:
sudo pip
On Mon, Sep 8, 2014 at 10:23 AM, Eric Snow eric.s...@canonical.com wrote:
Wayne just pointed out to me that rbt + our OAuth-based users aren't a
great mix. This is because the auto-registered reviewboard users are
not set up with passwords. I'll figure out a solution for us.
The OAuth stuff
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.vapour.ws/r/15/#review4
---
A general comment.
- ericsnowcurrently
On None, wwitzel3 wrote:
On Wed, Sep 3, 2014 at 11:37 PM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Thu, Sep 4, 2014 at 3:46 AM, Eric Snow eric.s...@canonical.com wrote:
Here's a write-up on my experience writing a charm for the first time.
Thanks for writing this up.
Blame Nate! He had the sense to ask
On Tue, Sep 2, 2014 at 5:07 AM, David Cheney david.che...@canonical.com wrote:
I wonder if there is a better way to handle this default case of the
name of the logger follows the package path), ie
var logger = loggo.Logger() // or something, it could be a new
method, logger.Default(), or
On Mon, Sep 1, 2014 at 12:03 AM, John Meinel j...@arbash-meinel.com wrote:
FWIW I'd favor 3 layers, though it does mean you have to do copying between
structs that would likely otherwise be almost identical. A State layer for
saving in the DB, an API layer for communication, and a Model layer
On Wed, Jul 30, 2014 at 12:25 AM, John Meinel j...@arbash-meinel.com wrote:
So as discussed, I think we still want to support a HTTP GET based API for
actually downloading the content to the client. And the CLI can do steps
like:
RPC to a request to create a backup (either this is synchronous
The API server side of backup made it into 1.20 (the client-side and
CLI did not). However, the API is exposed via HTTP POST rather than
through websockets RPC. We are correcting this right now. The
question is, are there any objections to removing backup from the
state API in 1.20 (or, less
there.
John
=:-
On Tue, Jul 22, 2014 at 7:10 PM, Eric Snow eric.s...@canonical.com wrote:
On Tue, Jul 22, 2014 at 8:17 AM, Eric Snow eric.s...@canonical.com
wrote:
Yep. For my case (backup/restore) we have a good enough solution
already.
Incidentally, do we have documentation somewhere on CI
On Tue, Jul 22, 2014 at 8:17 AM, Eric Snow eric.s...@canonical.com wrote:
Yep. For my case (backup/restore) we have a good enough solution already.
Incidentally, do we have documentation somewhere on CI tests (e.g.
backup/restore)? Specifically, where are they, how do they work, and
how do you
On Fri, Jun 27, 2014 at 3:05 AM, William Reade
william.re...@canonical.com wrote:
I think one of the biggest problems is the naming: state/api is a hackish
and minimal api client implementation, while state/apiserver is where the
actual api is defined... except the params package, which for
On Fri, Jun 27, 2014 at 5:36 AM, Nate Finch nate.fi...@canonical.com wrote:
have the code somewhere easily accessible in some repo, preferably without
needing to download the entire juju codebase.
Good point.
-eric
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or
On Thu, Jun 26, 2014 at 11:04 AM, Gustavo Niemeyer gust...@niemeyer.net wrote:
Hey Eric,
Some comments below, offering a slightly different perspective to be
used as a data point in your quest.
That was totally helpful. And with the further discussion (thanks
everyone!), I'm still hopeful
Thanks to all the responses thus far. While the discussion has been
insightful, I'm also hopeful that it will still be fruitful. :)
Understandably the responses have been focused on the main point of my
original post, splitting out the API client into its own repo.
However, there were a few
(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. wink Most of what I've focused on is relative to the
juju tools and the remote
Here's a link to a nice git tutorial:
https://www.atlassian.com/git/tutorial/
Another nice resource:
http://git-scm.com/doc
...particularly the getting-started section in the book:
http://git-scm.com/book/en/Getting-Started-Git-Basics
-eric
--
Juju-dev mailing list
92 matches
Mail list logo