On 2 November 2017 at 07:16, Mark Shuttleworth wrote:
> On 11/02/2017 04:56 AM, Chris Lee wrote:
>
> A new development release of Juju is here, 2.3-beta2.
>
>
> 2.3 is looking great, and is worth a test run for those of you with larger
> models and an interest in cross-model relations.
>
>
> ## Ne
On 6 November 2017 at 17:24, roger peppe wrote:
> juju deploy --to 3=0,4=3
Also, looking further forward, I'd like to see more informative
machine names in bundles, because with a command line like the above,
it's not clear what the purpose of the assigned machines might be.
It&
I still like the idea of overloading the --to flag rather than having
a new --map-machines flag. It's concise and fits well, I think - we
want the machines in this bundle to mapped *to* the machines we're
specifying here.
I like the thrust of Tim's suggestion for "existing" but I'm not
entirely su
On 9 November 2017 at 22:49, Tim Penhey wrote:
> No we aren't going to reuse --to.
>
> The --to directive is just for placement directives. Trying to use that
> to overload machine mappings for bundles adds complexity for no real value.
As I see it, machine mapping *is* placement, as applied to a
On 10 November 2017 at 10:40, Dmitrii Shcherbakov
wrote:
> This might not be an ideal example after all. However, I encountered
> something else in this case - final model machine IDs are not the same as I
> would expect while looking at the bundle.
I'd've thought that --use-existing-machines mig
I agree wholeheartedly about splitting up the utils package.
We talked about this potential issue when it was initially created
(and named "trivial", for trivial functionality with no better place
and no dependencies).
The dependency graph is crucial - one of the main reasons that utils
is proble
On 29 August 2013 11:09, John Arbash Meinel wrote:
> Namely, "go test -gocheck.v ./..." doesn't *actually* run the tests in
> any subdirectories.
>
> The specific problem is how the arguments get evaluated, but we don't
> have any workarounds for it that I know of. (You just don't pass
> - -gochec
On 29 August 2013 17:28, Gavin Panella wrote:
> On 29 August 2013 15:45, roger peppe wrote:
>> On 29 August 2013 11:09, John Arbash Meinel wrote:
>>> Namely, "go test -gocheck.v ./..." doesn't *actually* run the tests in
>>> any subdirectories.
>>
On 29 August 2013 17:08, Gary Poster wrote:
> Hey everyone.
>
> We have not had bandwidth to switch the GUI's CI from PyJuju to Juju
> Core yet. I'll see if we can carve that out in September. Meanwhile,
> we are in particular risk from API changes in core.
>
> Even trivial things, like changing
On 29 Aug 2013 19:29, "Kapil Thangavelu" wrote:
>
> Can't speak to the particular change, but fwiw i've got an extant bug re
> event order from the allwatcher.
> https://bugs.launchpad.net/juju-core/+bug/1210035
I discussed that possibility with the GUI folks when I was implementing
the allwatch
I mentioned in the standup that I had an idea how
the environment storage stuff might be structured,
so here's my sketch of some types and functions
that might work.
This decouples the configuration storage from
any necessary association with $HOME (or
local files for that matter) enabling us to f
Interesting. It has pretty much the same objectives as mu godeps
tool, but executed slightly differently.
Some thoughts:
- the "save/restore" syntax is nice.
- it doesn't currently support bzr.
- the json Godeps file is nice but currently lacks some information
(it would be nice if it included th
Quick reminder to all:
when you do this, please update the dependencies.tsv
file in the project root directory accordingly.
On 12 September 2013 02:41, Ian Booth wrote:
> If you grab the latest juju-core trunk, please note that you'll need to update
> gwacl to rev 224 or later.
>
> That is all.
>
r. If nothing
> consumes the file [*] then it is a distraction, and an incorrect one
> at that.
>
> Cheers
>
> Dave
>
> * if the bot does in fact use this file, disregard the entirety of this
> message.
>
> On Fri, Sep 13, 2013 at 10:29 PM, roger peppe wrote:
>
On 11 October 2013 06:18, Andrew Wilkins wrote:
> So I'd like to see what people think of this:
> - Keep "juju bootstrap --upload-tools", but make that the only time we
> attempt to upload during "juju bootstrap". There will not be any automatic
> upload if tools aren't found and syncing fails.
>
On 31 October 2013 05:21, Andrew Wilkins wrote:
> Does anybody object to converting the public entity structs in state to
> interfaces? i.e. State, Machine, Unit, etc.
>
> I'd like to write some tests for new code that depends on state. Setting up
> mongo and so on is overkill. and should be releg
On 31 October 2013 18:42, Andrew Wilkins wrote:
> type State interface {
> AllMachines() ([]Machine, error)
> }
>
> // another name would be needed, as this clashes with state.Entity; just for
> demonstration
> type Entity interface {
> Tag() string
> Destroy() error
> Refresh() er
On 1 November 2013 05:07, John Arbash Meinel wrote:
> I'm still skeptical that we need pbkdf2 for Agent logins, though I do
> like it for user logins. (We are generating 18 character passwords
> because originally they were used by Mongo which "only" md5sum'd them.
> We could use sha512 and 64-byt
There's no point in salting the agent passwords, and we can't easily
change things to salt the user passwords until none of the command
line tools talk directly to mongo, so I'm +1 on john's patch for now.
On 4 November 2013 13:26, William Reade wrote:
> On Fri, Nov 1,
On 6 November 2013 01:23, Andrew Wilkins wrote:
> On Tue, Nov 5, 2013 at 6:22 PM, William Reade
> wrote:
>>
>> On Tue, Nov 5, 2013 at 10:25 AM, Andrew Wilkins
>> wrote:
>>>
>>> As I've been looking for things to bite off, here's some comments from me
>>> (excluding things others are already look
On 6 November 2013 13:30, William Reade wrote:
> On Wed, Nov 6, 2013 at 1:49 PM, roger peppe wrote:
>>
>> FWIW I'm strongly in favour of *not* sending charms through
>> the RPC interface - it is likely not incur a significant performance
>> hit over a high la
On 6 November 2013 13:59, John Arbash Meinel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> ...
>>
>> Long term, I'd like to deprecate the root as a way of talking to
>> the API and mandate (for instance) /api as a URL path. Short term,
>> we can't do that, but we *can* treat, for in
On 6 November 2013 14:29, John Arbash Meinel wrote:
>>> I would be perfectly happy with PUT if we were already a RESTful
>>> API, but it seems a bit strange to just tack that on, and will be
>>> a one-more-special case that we run into when trying to debug,
>>> etc. (logs will likely be different,
le
that streams the bytes into Mongo (probably using mgo.GridFile),
and a corresponding GET request to enable agents to get the charm
bundle from the state.
On 6 November 2013 15:27, roger peppe wrote:
> On 6 November 2013 14:29, John Arbash Meinel wrote:
>>>> I would be perfe
The current plan is to have a single "juju ensure-ha-state" juju
command. This would create new state server machines if there are less
than the required number (currently 3).
Taking that as given, I'm wondering what we should do
in the future, when users require more than a single
big On switch f
On 6 November 2013 20:07, Kapil Thangavelu
wrote:
> instead of adding more complexity and concepts, it would be ideal if we
> could reuse the primitives we already have. ie juju environments have three
> user exposed services, that users can add-unit / remove-unit etc. they have
> a juju prefix a
On 7 November 2013 19:44, roger peppe wrote:
> On 7 November 2013 13:18, John Arbash Meinel wrote:
>> There is still the issue of what the process was doing when it hit 0%
>> CPU. I uploaded the traceback (xz compressed) to Ubuntu One, and it
>> should be here:
>&g
[reposted without the big attachment]
On 7 November 2013 13:18, John Arbash Meinel wrote:
> There is still the issue of what the process was doing when it hit 0%
> CPU. I uploaded the traceback (xz compressed) to Ubuntu One, and it
> should be here:
> * sigquit.log.xz (2.7 MB) hosted on Ubuntu On
On 8 November 2013 08:47, Mark Canonical Ramm-Christensen
wrote:
> I have a few high level thoughts on all of this, but the key thing I want to
> say is that we need to get a meeting setup next week for the solution to get
> hammered out.
>
> First, conceptually, I don't believe the user model nee
On 8 November 2013 11:31, Gustavo Niemeyer wrote:
> These are *very* good points, Mark. Taking them to heart will
> definitely lead into a good direction for the overall feature
> development.
>
> It sounds like we should avoid using a "management" command for
> anything in juju, though. Most thin
On 8 November 2013 10:31, John Arbash Meinel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2013-11-08 14:15, roger peppe wrote:
>> On 8 November 2013 08:47, Mark Canonical Ramm-Christensen
>> wrote:
>>> I have a few high level thoughts on all
On 8 November 2013 12:03, Gustavo Niemeyer wrote:
> Splitting API and db at some point sounds sensible, but it may be easy and
> convenient to think about a state server as API+db for the time being.
I'd prefer to start with a command name that implies that possibility;
otherwise we'll end up eit
On 8 November 2013 13:33, Gustavo Niemeyer wrote:
> We'll end up with a command that adds a state server, with a replica
> of the database and an API server. That's the notion of state server
> we've been using all along, and sounds quite reasonable, easy to
> explain and understand.
And when we
On 8 November 2013 13:51, Gustavo Niemeyer wrote:
> juju add-state-server --api-only-please-thanks
And if we want to allow a machine that runs the environment-manager
workers but not the api server or mongo server (not actually an unlikely thing
given certain future possibilities) then add-state-
eople on the
> ground, using this tool.
It would have been great to have had feedback from the CTS folks (possibly
the biggest current operational users of Juju?) for their views.
cheers,
rog.
On 11 November 2013 03:50, Tim Penhey wrote:
> On 09/11/13 03:04, roger peppe wrote:
>>
On 2 December 2013 11:40, Ian Booth wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>>
>> I don't fully understand the difference from mongoexport vs mongodump
>> (it looks like dump generates a binary snapshot compatible with
>> restore, while export/import generate text representation
On 2 December 2013 12:48, John Arbash Meinel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2013-12-02 16:39, roger peppe wrote:
>> On 2 December 2013 11:40, Ian Booth
>> wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>&
On 9 December 2013 10:41, John Arbash Meinel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> ...
>
>
>>> http://blog.mongolab.com/2013/06/new-features-in-mongodb-2-4-2/#V8_JavaScript_Engine
>>
>>>
>> It affects mapReduce, group, eval and $where. And I'm pretty sure
>> I've seen both e
Thank you! Let's get rid of every chown in the code base.
On 22 January 2014 23:12, Andrew Wilkins 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 wo
Thank you! Let's get rid of every chown in the code base.
On 22 January 2014 23:12, Andrew Wilkins 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 wo
On 24 January 2014 01:14, Andrew Wilkins wrote:
> I removed this bits that chown to the user from the local provider. I can't,
> unfortunately, easily remove the only other remaining part: chowning the
> ~/.juju/ssh dir and keys. Suggestions welcome.
There's also a Chown in environs/configstore t
On 24 January 2014 10:59, Andrew Wilkins wrote:
> On Fri, Jan 24, 2014 at 11:38 PM, roger peppe
> wrote:
>>
>> On 24 January 2014 01:14, Andrew Wilkins
>> wrote:
>> > I removed this bits that chown to the user from the local provider. I
>> > can
On 25 January 2014 01:58, Andrew Wilkins wrote:
> On Sat, Jan 25, 2014 at 1:24 AM, roger peppe
> wrote:
>>
>> On 24 January 2014 10:59, Andrew Wilkins
>> wrote:
>> > On Fri, Jan 24, 2014 at 11:38 PM, roger peppe
>> >
>> > wrote:
>> >&
On 6 February 2014 09:31, Mike Sam wrote:
> I have a hypothetical question. Imagine somehow a hacker gets into one of
> the machines in a juju env. There are credentials on the machine used by the
> machine and unit agents to talk to the state sever. are these credentials
> good enough for the hac
On 6 February 2014 09:31, Mike Sam wrote:
> I have a hypothetical question. Imagine somehow a hacker gets into one of
> the machines in a juju env. There are credentials on the machine used by the
> machine and unit agents to talk to the state sever. are these credentials
> good enough for the hac
On 6 February 2014 22:00, Nate Finch wrote:
> So, I took a deeper dive into Tim's newly renamed arrar package, and
> compared it to Roger's errgo package.
>
> Before I go into the implementations, I want to write down some goals:
>
> 1: Make it easy to wrap errors from deeper in the code with cont
On 7 February 2014 12:14, Nate Finch wrote:
>
> On Fri, Feb 7, 2014 at 5:24 AM, roger peppe 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 fu
On 10 February 2014 12:16, Nate Finch wrote:
> 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.
eems reasonable I could move it forward.
(that would probably involve splitting it up into 5 or 6
separate, but still large, MPs)
cheers,
rog.
On 11 February 2014 10:41, roger peppe wrote:
> On 10 February 2014 12:16, Nate Finch wrote:
>> I propose we make a small sample prog
On 18 February 2014 16:03, John Meinel wrote:
> Can we make the API /uuid/api ?
> That makes them all peer paths.
That's actually something that I was going to suggest too,
and have been meaning to change for a while.
It's actually a bug that currently the API is served at every
url except the ot
On 18 February 2014 17:48, William Reade wrote:
> I'd prefer to drop --include entirely, and make positional args automatic
> includes; and never to mention "environment" at the CLI level; but that then
> makes it hard to distinguish between an entity name and a regex to apply to
> the whole envir
That was rather the point of my reply above. I think that in the common
case it is useful to be able to address the API given a server name only.
On 18 Feb 2014 19:17, "Kapil Thangavelu"
wrote:
> how does the api client know the uuid prior to connection? jenv parsing on
> cli where applicable?
>
On 3 March 2014 17:49, Nate Finch wrote:
> John talked to me on a hangout and suggested that, often times, when you
> need to expose something like this for tests, it ends up being something
> that production code needs to tweak as well. He'd like to see something
> better than a public variable,
On 5 March 2014 20:14, Gustavo Niemeyer wrote:
> On Wed, Mar 5, 2014 at 5:12 PM, Nate Finch wrote:
>> 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 li
If anyone, like me, has been frustrated when debugging
bootstrap failures and having the bootstrap
machine torn down immediately on failure,
a quick and relatively easy workaround for that
is to "kill -STOP" the juju bootstrap process
while it's doing the ssh commands.
You'll continue to see the s
On 24 March 2014 18:07, Gustavo Niemeyer wrote:
> How about --keep-on-error?
Several of us have thought about that, but it's not on the
critical path right now...
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juj
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" wrote:
> So, I often get failed tests that are so obscured by our log output that I
> can't even tell what's failing. So I made a little
I have updated the HA-related tickets on the Kanban
to list them in rough order of implementation.
Specifically, I have moved them all into the same
section in the Kanban board and sorted them so that tickets
with least dependencies are first, and tickets which
we don't need for the minimum viable
I've just landed some changes on juju tip that enable "highly available"
juju environments. In a HA environment, there are several state servers -
if one dies, one of the others should take over.
To make a HA environment, run the "ensure-availability" command. For
example to make a HA environment
That's great! Thanks Andrew.
On 21 April 2014 21:43, Andrew Wilkins wrote:
> On Fri, Apr 18, 2014 at 3:02 AM, roger peppe wrote:
>>
>> I've just landed some changes on juju tip that enable "highly available"
>> juju environments. In a HA environment, th
On 14 May 2014 10:24, Tim Penhey wrote:
> Hi all,
>
> I took it upon myself to get Rog's errgo library used inside juju-core.
Thanks for doing this.
> Dimiter recently did a hunk of work in the juju-core/errors package to
> have functions to add context to some core error types while keeping
> t
On 27 May 2014 04:02, Tim Penhey wrote:
> On 23/05/14 02:47, roger peppe wrote:
>> Any particular reason to wrap the errgo functions rather than using errgo
>> directly? Personally, I see the role of the errors package to be about
>> specific error classifications (something
On 27 May 2014 04:02, Tim Penhey wrote:
> On 23/05/14 02:47, roger peppe wrote:
>> Any particular reason to wrap the errgo functions rather than using errgo
>> directly? Personally, I see the role of the errors package to be about
>> specific error classifications (something
On 27 May 2014 07:55, John Meinel wrote:
> I just proposed this branch:
> http://code.launchpad.net/~jameinel/juju-core/login-returns-env-tag/+merge/221021
>
> This will make it so that we end up caching the environment UUID into our
> ENV.jenv file, and passing it up when we try to connect, and h
On 28 May 2014 00:46, William Reade wrote:
> Roger
>
> We have had many long discussions, and you have provided much valuable
> input: in particular, explaining to us that we were completely off-base re:
> the attempts to use a slice vs a linked list in the error stacks. And we did
> indeed agree
I just saw this thread after replying to the other one.
Fundamentally, I think comparing errors for equality
is misguided. That said, a simple approach that
doesn't use DeepEquals is possible:
func sameError(e1, e2 error) bool {
defer func() { recover() }()
return e1 == e2
}
On 28 May 201
On 29 May 2014 04:03, Tim Penhey wrote:
> On 29/05/14 01:11, roger peppe wrote:
>> Writing code to explicitly declare function return types is also
>> a perpetual drag on refactoring, but it's also incredibly useful.
>>
>> The set of possible returned errors *shoul
On 28 May 2014 19:40, Nate Finch wrote:
> I think the main problem with errgo as it exists, is that it is very awkward
> to allow error type information to pass through:
>
> return errgo.Mask(err, errgo.Any)
>
> This line is very misleading. It's saying - mask the error type, except
> wait,
[This discussion originated on juju-dev@lists.ubuntu.com - I'm replying
to juju-...@lists.canonical.com because it touches on JAAS issues]
On 29 May 2014 06:46, Tim Penhey wrote:
> Hi folks,
>
> The onyx team is dealing with sharing environments between multiple
> people. Currently how this is h
On 30 May 2014 06:50, John Meinel wrote:
> ...
>
>>
>> > PROBLEM: right now all connections to the api server are secured with
>> > TLS and the client-cert.
>>
>> As John says, this isn't actually true - connections are secured with
>> a server cert and a password.
>>
>> Unfortunately I believe it
On 29 May 2014 21:48, William Reade wrote:
> Masking is often necessary, and information hiding is valuable, and
> depending on spooky action at a distance is generally foolish. But the
> granularity with which we want to track the propagation of a given error is
> *much* finer than the granularit
(Of course, this is actually a potential issue even now).
A better way of structuring things, perhaps, might be
to index local environment information by environment UUID,
keeping names as aliases only.
cheers,
rog.
>
>
> On Fri, May 30, 2014 at 9:32 AM, roger peppe
> w
On 29 May 2014 20:00, Jeroen Vermeulen wrote:
> On 2014-05-29 09:50, roger peppe wrote:
>>
>> On 29 May 2014 04:03, Tim Penhey wrote:
>
>
>> Errors are worth treating specially here because they're
>> they pass up through multiple layers, so it's very
On 30 May 2014 17:24, Jeroen Vermeulen wrote:
> On 2014-05-30 15:08, roger peppe wrote:
>
>>> Two: a caller can deal better with some errors, given more detailed
>>> information. You can help by attaching more information to the error
>>> (tags,
>>>
On 2 June 2014 11:19, Ian Booth wrote:
> Hi folks
>
> As per previous communications, we'll be migrating the juju-core codebase off
> Launchpad and across to Github at 10:00 UTC Tuesday 3 June.
>
> Here's a link to the new Contributing document which describes the new landing
> workflow:
>
> https
On 2 June 2014 12:44, John Meinel wrote:
> Well the linked doc said to rebase before propose:
>
> When ready for feedback, push your feature branch to github, optionally
> after
> collapsing multiple commits into discrete changes:
>
> $ git rebase -i --autosquash master
> $ git push origin new_fea
On 3 June 2014 00:13, Nate Finch wrote:
> Right now, we change tip on our repos outside of Juju-core with breaking API
> changes. This is not the way to make packages that others can use and
> depend on. Since we are in the process of moving many/most/all of these
> dependencies to github, I thi
On 2 June 2014 19:11, Nate Finch wrote:
> (resending to the right thread)
>
> This may be a bit late... can we make the repo named juju?
>
> github.com/juju/juju
>
> The first Juju is the team, the second Juju is the project. Core is not a
> thing. This is pretty much standard operating procedur
On 3 June 2014 09:19, Andrew Wilkins wrote:
> On Tue, Jun 3, 2014 at 4:11 PM, roger peppe wrote:
>>
>> On 2 June 2014 19:11, Nate Finch wrote:
>> > (resending to the right thread)
>> >
>> > This may be a bit late... can we make the repo named juju?
&g
On 4 June 2014 11:02, Nate Finch wrote:
> There's an option to pass -copy=false which won't copy over the sourcecode.
This *should* work, but currently doesn't because godep doesn't support
some of its functionality (the sandbox box) for bzr dependencies.
That should not stop it working when usi
On 5 June 2014 05:07, Menno Smits wrote:
> One nice feature is that old comments are hidden
> if the area of the code they reference is changed by a later diff.
I consider this a serious shortcoming. I generally want to see all the
conversation for a given code review. Is it possible to reveal
th
On 5 June 2014 14:22, Andrew Wilkins wrote:
> On Thu, Jun 5, 2014 at 9:02 PM, roger peppe wrote:
>>
>> On 5 June 2014 05:07, Menno Smits wrote:
>> > One nice feature is that old comments are hidden
>> > if the area of the code they reference is changed by a la
On 5 June 2014 14:20, Nate Finch wrote:
> 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
Unfortunately that means that the import identifier isn't intuitive,
but perhaps that's ok.
On 5 June 2014 14:27, roger peppe wrote:
> On 5 June 2014 14:20, Nate Finch wrote:
>> We're making a lot of standalone repos on github so that teams external to
>> core can
I'd love to ditch rebasing if it was reasonable to do so.
It just adds overhead to an already tiresome procedure.
On 5 June 2014 16:22, Nate Finch wrote:
> I am far from a git expert, but it sounds like we can get a bzr-like
> overview of merges to trunk if we give git the right command. This is
On 5 June 2014 23:16, Tim Penhey 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: local
>> previous-environ-name: ec2
>>
On 6 June 2014 14:20, William Reade wrote:
Thanks for these very useful and constructive remarks. I now
understand better where the original proposal was coming from.
> On Fri, Jun 6, 2014 at 11:34 AM, roger peppe wrote:
>>
>> On 5 June 2014 23:16, Tim Penhey wrote:
>&
I am working on,
hence my interest here.
cheers,
rog.
>
> Tim
>
> On 09/06/14 22:07, roger peppe wrote:
>> On 6 June 2014 14:20, William Reade wrote:
>>
>> Thanks for these very useful and constructive remarks. I now
>> understand better where the origina
On 16 June 2014 09:25, William Reade wrote:
> On Sun, Jun 15, 2014 at 2:58 PM, John Meinel wrote:
>>
>> I feel like we should consolidate these fields. And if we need "authTag"
>> to match Login then we should be setting "tag" there instead. (That will be
>> better for any case where we Login lat
On 16 June 2014 09:25, William Reade wrote:
> On Sun, Jun 15, 2014 at 2:58 PM, John Meinel wrote:
>>
>> I feel like we should consolidate these fields. And if we need "authTag"
>> to match Login then we should be setting "tag" there instead. (That will be
>> better for any case where we Login lat
On 17 June 2014 09:27, William Reade wrote:
> On Tue, Jun 17, 2014 at 10:04 AM, roger peppe wrote:
>>
>> On 16 June 2014 09:25, William Reade wrote:
>> > On Sun, Jun 15, 2014 at 2:58 PM, John Meinel
>> > wrote:
>> >>
>> >> I fee
On 17 June 2014 10:02, John Meinel wrote:
> Also, I do think we want to follow our old Rietveld behavior, where for each
> comment a reviewer made, the submitter can respond (even if just with
> "Done"). I realize this generates a lot of email noise, but it means that
> any reviewer can come along
We (mostly myself and Francesco Banconi, with some useful
input from Brad Crittenden) have put together a proposal for moving
towards making bundles a first-class citizen in Juju.
Please let us know what you think.
https://docs.google.com/a/canonical.com/document/d/1SF8hTBi6oVbki8V__beNij6wnQU-5c
We (mostly myself and Francesco Banconi, with some useful
input from Brad Crittenden) have put together a proposal for moving
towards making bundles a first-class citizen in Juju.
Please let us know what you think.
https://docs.google.com/a/canonical.com/document/d/1SF8hTBi6oVbki8V__beNij6wnQU-5c
at specifies
a topology, but does not state how that topology should be
mapped to an existing environment (that aspect is left deliberately
unspecified for now).
cheers,
rog,
> Thanks,
> -Ben
>
>
> On Thu, Jun 19, 2014 at 6:28 AM, roger peppe wrote:
>>
>> We (most
I would consider it extremely unlikely that either of those workers have
anything to do with the agent config. The only places in the entire system
that should be rewriting the agent.conf file are machine.go and unit.go in
cmd/jujud.
On 21 Jun 2014 06:29, "Wayne Witzel" wrote:
> I was not able to
That's very interesting; thanks for the link.
One part that jumps out at me:
: ... many teams that review code don't have a good way of tracking
defects found
: during review and ensuring that bugs are actually fixed before the
review is complete
We don't have this, and with github reviews it's
This looks great, with one or two remarks below.
On 26 June 2014 05:47, Tim Penhey wrote:
> On reading the spec[1] and looking at the state documents as they are in
> trunk now, I was quickly coming to the conclusion that the documents
> need to change.
>
> I think these should be combined, and t
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
[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
1 - 100 of 351 matches
Mail list logo
