Re: A cautionary tale - mgo asserts

r > can change because unmarshaling unmarshals as bson.M > which does not preserve key order. > > https://play.golang.org/p/_1ZPl7iMyn > > On 8 June 2016 at 15:55, Gustavo Niemeyer > <gustavo.nieme...@canonical.com> wrote: > > Is it mgo itself that is

Re: A cautionary tale - mgo asserts

Is it mgo itself that is changing the order internally? It should not do that. On Wed, Jun 8, 2016 at 8:00 AM, roger peppe wrote: > OK, I understand now, I think. > > The underlying problem is that subdocument searches in MongoDB > are order-sensitive. > > For example, I

Re: Juju and TOSCA

complex, with the Openstack Telemetry (19 Charms) as an example: https://jujucharms.com/openstack-telemetry/31 I'm looking forward to reading your thoughts on this. Merlijn 2015-08-06 18:05 GMT+02:00 Gustavo Niemeyer gustavo.nieme...@canonical.com: Hi Merlijn, On Thu, Aug 6, 2015 at 12:00

Re: fork/exec ... unable to allocate memory

interestingly we are already fairly heavily overcommitted. We have 4GB of RAM and 4GB of swap available. And cat /proc/meminfo is saying: CommitLimit: 6214344 kB Committed_AS:9764580 kB John =:- On Wed, Jun 3, 2015 at 9:28 AM, Gustavo Niemeyer gust...@niemeyer.net wrote: Ah, and you

Re: fork/exec ... unable to allocate memory

Hey John, It's probably an overcommit issue. Even if you don't have the memory in use, cloning it would mean the new process would have a chance to change that memory and thus require real memory pages, which the system obviously cannot give it. You can workaround that by explicitly enabling

Re: fork/exec ... unable to allocate memory

Ah, and you can also suggest increasing the swap. It would not actually be used, but the system would be able to commit to the amount of memory required, if it really had to. On Jun 3, 2015 1:24 AM, Gustavo Niemeyer gust...@niemeyer.net wrote: Hey John, It's probably an overcommit issue. Even

Re: Pruning the txns collection

Hey Menno, I'm copying the list to ensure we have this documented somewhere for future reference. You are right that it's not that simple, but it's not that complex either once you understand the background. Transactions are applied by the txn package by tagging each one of the documents that

Re: Coordinating actions in a service

On Fri, May 8, 2015 at 10:24 AM, John Weldon johnweld...@gmail.com wrote: Hi Stuart; I think this is addressed in the proposed work for Actions 2.0 In the current model you'd have to manage all of this yourself. Actions can only be targeted to specific units in the current implementation,

Re: Coordinating actions in a service

Hi Stuart, I see two ways to fix this issue, and both are probably worth implementing for their own good: - We should be able to have an action that lives past the execution of the action hook, upon request. This would enable the leader unit to communicate with all peer units to do anything it

Re: Please, no more types called State

When I was new to juju myself, we only had one State, I believe. That one golden state was supposed to represent the state of the whole deployment, so it was indeed The State of the system. Having tons of these indeed sounds awkward. On Thu, Mar 12, 2015 at 8:08 AM, Michael Foord

Re: adding placement directives for ensure-availability

Hi Nate, On Tue, Feb 24, 2015 at 2:24 PM, Nate Finch nate.fi...@canonical.com wrote: (...) To support this, we need a way to say use the default placement policy. For this, we propose the keyword default. Thus, to fix the above example, Bill would type this: $ juju ensure-availability --to

Re: Feedback on a base fake type in the testing repo

On Fri, Feb 13, 2015 at 2:05 PM, Eric Snow eric.s...@canonical.com wrote: As for me, by fake I mean a struct that implements an interface with essentially no logic other than to keep track of method calls and facilitate controlling their return values explicitly. For examples see the

Re: Feedback on a base fake type in the testing repo

On Fri, Feb 13, 2015 at 3:25 PM, Eric Snow eric.s...@canonical.com wrote: This is a mock object under some well known people's terminology [1]. With all due respect to Fowler, the terminology in this space is fairly muddled still. :) Sure, I'm happy to use any terminology, but I'd prefer to

Re: Feedback on a base fake type in the testing repo

On Fri, Feb 13, 2015 at 6:50 PM, Eric Snow eric.s...@canonical.com wrote: Using a fake for that input means you don't have to encode the low-level business logic in each test (just any setup of the fake's state). You can be confident about the low-level behavior during tests as matching

Re: Juju Resources (a tool / library)

Hi Cory, While it's fine and welcome to have such test bed features, it feels like the proposal and implementation have quite different goals from the actual resources feature we've been talking about for a while, so as a very early suggestion and request, I would strongly recommend renaming the

Re: Juju Resources (a tool / library)

also intend to update the interface to match the feature as closely as possible as the proposal becomes more concrete. On Wed, Feb 11, 2015 at 2:33 PM, Gustavo Niemeyer gust...@niemeyer.net wrote: Hi Cory, While it's fine and welcome to have such test bed features, it feels like the proposal

Re: Juju Resources (a tool / library)

also intend to update the interface to match the feature as closely as possible as the proposal becomes more concrete. On Wed, Feb 11, 2015 at 2:33 PM, Gustavo Niemeyer gust...@niemeyer.net wrote: Hi Cory, While it's fine and welcome to have such test bed features, it feels like the proposal

Re: supplement open--port/close-port with ensure-these-and-only-these-ports?

Reminding people of everything they should *not be doing *to get a feature to be listed in the release notes is very ineffective. What should they *be doing* instead, and why will the process work in the future when it clearly has failed before, despite the assumed good intention we should assume

Re: how to update dependencies.tsv

I have never used upstream as an actual remote name. I see people commonly using the term as a wildcard to refer to the upstream branch whatever it is. The term is also used widely in git itself with the same meaning, including in the command line interface. For example, you set the upstream

Re: Actions :: UUID vs. Tag on command line

The tag (which might be better named internal id) looks like an implementation detail which doesn't seem right to expose. I'd suggest either giving it a proper representation that the user can understand (a sequential action number, for example), or use a hash. I'd also not use a UUID, btw, but

Re: Actions :: UUID vs. Tag on command line

to generate and translate the hash are welcome too. Cheers, -- John Weldon On Fri, Oct 24, 2014 at 10:41 AM, Gustavo Niemeyer gustavo.nieme...@canonical.com wrote: The tag (which might be better named internal id) looks like an implementation detail which doesn't seem right to expose. I'd

Re: Actions :: UUID vs. Tag on command line

On Fri, Oct 24, 2014 at 11:07 AM, Gustavo Niemeyer gustavo.nieme...@canonical.com wrote: That might be okay, but is the sequence really respected? In other words, what happens if two independent clients attempt to submit an action for the same service? Will the two generated sequences reflect

Re: Actions :: UUID vs. Tag on command line

in some respects, and I certainly won't complain about that. Cheers William -- John Weldon On Fri, Oct 24, 2014 at 10:58 AM, Gustavo Niemeyer gustavo.nieme...@canonical.com wrote: It was my mistake to call it a hash.. it may be just a random id, in hex form. Alternatively, use

Re: Actions :: UUID vs. Tag on command line

by the numbers. On Fri Oct 24 2014 at 4:21:30 PM John Weldon johnweld...@gmail.com wrote: Forgot to reply-all -- Forwarded message -- From: John Weldon johnweld...@gmail.com Date: Fri, Oct 24, 2014 at 11:19 AM Subject: Re: Actions :: UUID vs. Tag on command line To: Gustavo Niemeyer

Re: Actions :: UUID vs. Tag on command line

On Fri Oct 24 2014 at 4:30:38 PM John Weldon johnweld...@gmail.com wrote: Ordered execution wasn't addressed in the spec, and we haven't had much discussion about it. I'm not even sure how to enforce ordered execution unless we rely on the creation timestamp. Specifications are guidelines.

Re: Actions :: UUID vs. Tag on command line

not mislead users by implying sequence that does not exist. 4. ergo Action id's will probably be reflected back to the user in some sort of a manageable hash or hex format -- John Weldon On Fri, Oct 24, 2014 at 11:38 AM, Gustavo Niemeyer gust...@niemeyer.net wrote: On Fri Oct 24 2014

Re: Unit Tests Integration Tests

On Thu, Sep 11, 2014 at 4:06 PM, Mark Ramm-Christensen (Canonical.com) mark.ramm-christen...@canonical.com wrote: But they are not the ONLY reasons why they are valuable. There are plenty of others -- performance, test-code cleanliness/re-use, result granularity, etc. Performance is the second

Re: Unit Tests Integration Tests

On Thu, Sep 11, 2014 at 10:42 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: I basically agree with everything below, but strongly disagree that mocking implies you know exactly what the code is doing internally. A good interface I'm also in agreement about your points. But just so you

Re: Please don't use bash when there are syscalls available

Worth keeping in mind the usual gotcha: the API of syscall is different for different OSes. On Tue, Sep 9, 2014 at 5:45 PM, 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,

Re: Commented-out tests?

On Fri, Aug 29, 2014 at 4:28 PM, Katherine Cox-Buday katherine.cox-bu...@canonical.com wrote: Hey all, I ran into some commented out tests while making a change: https://github.com/juju/juju/pull/630/files#r16874739 I deleted them since keeping things around that we might need later is the

Re: First customer pain point pull request - default-hook

On Wed, Aug 20, 2014 at 5:46 AM, Matthew Williams matthew.willi...@canonical.com wrote: if JUJU_HOOK_NAME == start //run start else if JUJU_HOOK_NAME == config-changed //run config-changed else if JUJU_HOOK_NAME == stop //run stop else //unknown hook exit 1 fi I'd expect the else

Re: First customer pain point pull request - default-hook

On Wed, Aug 20, 2014 at 11:08 AM, William Reade william.re...@canonical.com wrote: On Wed, Aug 20, 2014 at 10:46 AM, Matthew Williams matthew.willi...@canonical.com wrote: Gustavo's observation about hooks that the charm might no know about yet means that the else clause is absolutely

Re: First customer pain point pull request - default-hook

On Wed, Aug 20, 2014 at 11:16 AM, Nate Finch nate.fi...@canonical.com wrote: Anyone who has ever written a switch statement should be used to putting in a default clause for something I don't expect... I don't think it should be a big deal. Some charms mentioned in this thread miss the switch

Re: First customer pain point pull request - default-hook

On Wed, Aug 20, 2014 at 3:45 PM, Nate Finch nate.fi...@canonical.com wrote: Here's a proposal that is much simpler: we add a flag to the charm metadata, called something like single_hook. When single_hook is true, all hook events run a file called default-hook (or whatever we want to call it,

Re: First customer pain point pull request - default-hook

On Wed, Aug 20, 2014 at 5:05 PM, Nate Finch nate.fi...@canonical.com wrote: I think to answer most of these questions, we need more information about what the existing charms do, and input from the charmers themselves. Here's the info from Marco: http://pastebin.ubuntu.com/8100649/ Thanks.

Re: First customer pain point pull request - default-hook

On Tue, Aug 19, 2014 at 9:07 AM, William Reade william.re...@canonical.com wrote: On Mon, Aug 18, 2014 at 9:33 PM, Gustavo Niemeyer gust...@niemeyer.net wrote: I don't think I fully understand the proposal there. To have such a something-changed hook, we ought to have a better mechanism

Re: First customer pain point pull request - default-hook

On Tue, Aug 19, 2014 at 12:41 PM, William Reade william.re...@canonical.com wrote: (out of interest, if started/stopped state were communicated to you any other way, would you still need these?) If you communicate events in a different way, you obviously won't need your previous way of

Re: First customer pain point pull request - default-hook

On Tue, Aug 19, 2014 at 1:10 PM, Aaron Bentley aaron.bent...@canonical.com wrote: True. At that point, the pattern is not a win, but it's not much of a loss. Changing the web site relation is extremely uncommon, but operations which do require server restarts are quite common. So making an

Re: First customer pain point pull request - default-hook

On Tue, Aug 19, 2014 at 6:58 PM, Matthew Williams matthew.willi...@canonical.com wrote: Something to be mindful of is that we will shortly be implementing a new hook for metering (likely called collect-metrics). This hook differs slightly to the others in that it will be called periodically

Re: First customer pain point pull request - default-hook

Rather than passing it as the first argument, I suggest introducing an environment variable: $JUJU_HOOK_NAME. This would be set irrespective of how the hook is being called, so that the same hook can be used both as a symlink and as a default-hook, unchanged. It also means further spawned

Re: First customer pain point pull request - default-hook

I don't think I fully understand the proposal there. To have such a something-changed hook, we ought to have a better mechanism to tell *what* actually changed. In other words, we have a number of hooks that imply a state transition or a specific notification (install, start, config-changed,

Re: getting rid of all-machines.log

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 Niemeyer gustavo.nieme...@canonical.com wrote: Why support two things when you can support just one? Just to be clear, you really mean why support two existing and well

Re: getting rid of all-machines.log

On Thu, Aug 14, 2014 at 3:14 PM, Nate Finch nate.fi...@canonical.com wrote: I didn't bring up 12 factor, it's irrelevant to my argument. Is there someone else sending messages under your name? On Thu, Aug 14, 2014 at 12:23 PM, Nate Finch nate.fi...@canonical.com wrote: The front page of

Re: Intentionally introducing failures into Juju

the system would know how to retry properly. Killing or slowing down just sometimes, or perhaps the first 2 times out of every 3, for example, would enable the system to recover itself, and an external agent to ensure it continues to work properly. On Wed, Aug 13, 2014 at 11:25 AM, Gustavo Niemeyer

Re: Port ranges - restricting opening and closing ranges

kapil.thangav...@canonical.com wrote: agreed. to be clear .. imo, close-port shouldn't error unless there's a type mismatch on inputs. ie none of the posited scenarios in this thread should result in an error. -k On Tue, Aug 5, 2014 at 8:34 PM, Gustavo Niemeyer gust...@niemeyer.net wrote: On Tue

Re: Port ranges - restricting opening and closing ranges

, 2014 9:41 AM, roger peppe roger.pe...@canonical.com wrote: On 5 August 2014 19:34, Gustavo Niemeyer gust...@niemeyer.net wrote: On Tue, Aug 5, 2014 at 4:18 PM, roger peppe rogpe...@gmail.com wrote: close ports 80-110 - error (mismatched port range?) I'd expect ports to be closed here

Re: Port ranges - restricting opening and closing ranges

presents undefined behavior. gustavo @ http://niemeyer.net On Aug 6, 2014 2:53 PM, roger peppe roger.pe...@canonical.com wrote: On 6 August 2014 10:32, Gustavo Niemeyer gust...@niemeyer.net wrote: How many port ranges are typically made available? One.. Two? Sounds like a trivial problem

Re: Port ranges - restricting opening and closing ranges

gustavo @ http://niemeyer.net On Aug 6, 2014 3:03 PM, roger peppe roger.pe...@canonical.com wrote: On 6 August 2014 13:57, Gustavo Niemeyer gust...@niemeyer.net wrote: Why would any application well designed open thousands of ports individually rather than a range? Sounds like

Re: Port ranges - restricting opening and closing ranges

On Tue, Aug 5, 2014 at 4:18 PM, roger peppe rogpe...@gmail.com wrote: close ports 80-110 - error (mismatched port range?) I'd expect ports to be closed here, and also on 0-65536. gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe

Re: help please: mongo/mgo panic

completely independent runners, in different goroutines (might as well be different machines), collaborating towards the completion of a single transaction. So, I believe this is sorted. Please let me know how it goes there. On Wed, Jul 30, 2014 at 4:14 AM, Gustavo Niemeyer gustavo.nieme

Re: help please: mongo/mgo panic

We've got a database dump yesterday, which gives me something to investigate. I'll spend some time on this tomorrow (today) and report back. On Wed, Jul 30, 2014 at 1:34 AM, Menno Smits menno.sm...@canonical.com wrote: All, Various people have been seeing the machine agents panic with the

Re: Mongo experts - help need please

On Fri, Jul 25, 2014 at 2:37 AM, Ian Booth ian.bo...@canonical.com wrote: The tests passed for me every time also, with and without independent sessions. If I loaded my machine to max out CPU usage to 100%, then the tests (different ones each run) would fail intermittently but reproducibly

Re: Mongo experts - help need please

On Fri, Jul 25, 2014 at 5:29 AM, Stuart Bishop stuart.bis...@canonical.com wrote: On 25 July 2014 12:05, Gustavo Niemeyer gustavo.nieme...@canonical.com wrote: The bug Ian cites and is trying to work around has sessions failing with an i/o error after some time (I'm guessing resource

Re: Mongo experts - help need please

On Fri, Jul 25, 2014 at 1:02 AM, Ian Booth ian.bo...@canonical.com wrote: We've transitioned to using Session.Copy() to address the situation whereby Juju would create a mongo collection instance and then continue to make db calls against that collection without realising the underlying

Re: series-agnostic charm URLs

On Wed, Jul 23, 2014 at 7:35 AM, roger peppe rogpe...@gmail.com wrote: We want to store charm URLs in mongo-db that are agnostic whether the series is specified or not. For example, in a bundle, a service is free to specify a series in the charm name or not. That sounds slightly surprising.

Re: series-agnostic charm URLs

On Wed, Jul 23, 2014 at 9:13 AM, Richard Harding rick.hard...@canonical.com wrote: This is driven by requirements from ecosystem and users where bundles define a 'solution'. A mongodb-cluster bundle doesn't need to be updated every time a new revision comes out, or even if a new series comes

Re: series-agnostic charm URLs

On Wed, Jul 23, 2014 at 9:59 AM, roger peppe roger.pe...@canonical.com wrote: The charm URL in a bundle means exactly what it would mean if you typed it in a juju deploy command. That is, it is dependent on the charms available at bundle deploy time. I would fix that instead. I do believe

Re: Enhancing our IRC bot?

Great timing, Kate. I was recently asked to take care of mup's deployment again, and I'm about to put live its third incarnation, reviving a hack I started back in 2011 to port the ancient Erlang bot I wrote too many years ago into a Go version. My goal, among other things, is to make plugin

Re: Charm store API proposal, new version

On Tue, Jul 15, 2014 at 7:05 PM, Richard Harding rick.hard...@canonical.com wrote: It is listed under known clients in the spec, and we mentioned your request down below. What we lack is your specific use cases as no one working on the spec is knowledgeable about how you're using the api.

Re: RFC: mongo _id fields in the multi-environment juju server world

On Mon, Jul 7, 2014 at 10:09 AM, roger peppe roger.pe...@canonical.com wrote: I had assumed that because every client needs to see every transaction there would likely be no benefit to sharding the log, although technically you could shard on transaction id. I'd be Clients don't need to see

Re: RFC: mongo _id fields in the multi-environment juju server world

On Mon, Jul 7, 2014 at 2:03 PM, roger peppe roger.pe...@canonical.com wrote: The latter might turn out to be quite awkward, though there's probably a nice solution I don't see. Suppose we've got three environments, A, B and C. We have transactions that span {A, B}, {B, C} and {C, A}. How

Re: move towards using gopkg.in

On Mon, Jul 7, 2014 at 6:00 PM, Ian Booth ian.bo...@canonical.com wrote: I'm somewhat wary of depending on an another unknown third party website being That's hilarious. I haven't been pushing for its usage on juju, and I'm still not the one actively pushing it, but that's a pretty bad

Re: move towards using gopkg.in

On Mon, Jul 7, 2014 at 7:18 PM, Ian Booth ian.bo...@canonical.com wrote: It wasn't mean to be funny. I'm unsure why it's a bad argument. It's quite prudent to ensure that critical infrastructure on which our development depends meets expectations with regard to uptime, reliability etc (a case

Re: move towards using gopkg.in

On Mon, Jul 7, 2014 at 8:49 PM, David Cheney david.che...@canonical.com wrote: I don't want to introduce another thing to break CI, we already pull from github which is bad enough, but going via gopkg.in introduces an additional point of failure which can further reduce the already bullet

Re: RFC: mongo _id fields in the multi-environment juju server world

On Fri, Jul 4, 2014 at 6:01 AM, roger peppe roger.pe...@canonical.com wrote: There is another possiblity: we could just use a different collection name prefix for each environment. There is no hard limit on the number of collections in mongo (see

Re: RFC: mongo _id fields in the multi-environment juju server world

On Fri, Jul 4, 2014 at 10:32 AM, roger peppe roger.pe...@canonical.com wrote: It won't be possible to shard the transaction log. Why not? The thing I'm trying to get across is: until we know one way or another, I believe it would be better to choose the (much) simpler option and use the

Re: Port ranges - restricting opening and closing ranges

+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) mark.ramm-christen...@canonical.com wrote: My belief is that as long as the error messages are

Re: Thoughts to keep in mind for Code Review

Agreed, but for a slightly different reason. The suggestion is to annotate the patch with the reason for the change, rather than the code itself, which might indeed lead to a different kind of comment. While this might be useful, one of the interesting outcomes of code reviewing is that it forces

Re: Thoughts to keep in mind for Code Review

Thanks, John. Several nice ideas there. I especially like the data backing the first few points.. it provides evidence to something we intuitively understand. I also wrote some points about this same topic, but from a slightly different perspective, last year:

Re: This is why we should make go get work on trunk

go is the default build tool, and the vast majority of go projects work out of the box with go get. If we cannot make it work, that's fine, but looking at other projects that cannot get it to work is no excuse. If you guys can make it work, even if we continue to support godep(s), by all means do

Re: GitHub issues

. This was meant to be done when the repo was set up. On 05/06/14 00:23, Gustavo Niemeyer wrote: I would keep them around for a while and try to observe how the community reacts to the availability. If people don't care, then just closing it sounds fine. If you start to get engagement there, might

Re: not rebasing after PR?

FWIW, I pretty much never rebase in my usual development workflow. I'm surprised to hear it became a norm somehow. On Thu, Jun 5, 2014 at 2:06 PM, roger peppe rogpe...@gmail.com wrote: I'd love to ditch rebasing if it was reasonable to do so. It just adds overhead to an already tiresome

Re: GitHub issues

I would keep them around for a while and try to observe how the community reacts to the availability. If people don't care, then just closing it sounds fine. If you start to get engagement there, might be worth going over the trouble of supporting users that live in that ecosystem. My experience

Re: Juju, mongo 2.6 and labix.org/v2/mgo issue

It's indeed being updated. The frequent sprints haven't been helping, but I'm hoping to have a new release out next week. gustavo @ http://niemeyer.net On May 28, 2014 8:19 AM, Ian Booth ian.bo...@canonical.com wrote: Hi all I'm testing Juju with Mongo 2.6 to evaluate how that affects our

Re: Ensuring tests pass on gccgo

On Wed, May 21, 2014 at 10:43 PM, Ian Booth ian.bo...@canonical.com wrote: We are working to make all juju-core unit tests pass using gccgo. In case you didn't already know, there's a common issue which has caused a lot of the failures to date. Here's a quick heads up on how to deal with it.

Re: arch constraint default changed?

Why isn't the default tweaked by --upload-tools itself then? We should be optimizing these options for users, rather than for developers, and it sounds sensible to assume that the vast majority of users do want to deploy on amd64 rather than i386 or arm. On Mon, May 12, 2014 at 2:53 PM, Nate

Re: goamz API stability

Whatever is done we should not break the API like that, as this would instantly break every single application out there that uses goamz's s3 package. A better way to handle that is to panic if the S3 endpoint is unset and s3.New is called on such a region, and document that this will be the case

Re: Implementing Juju Actions

On Thu, Mar 27, 2014 at 12:05 PM, James Solomon binary...@gmail.com wrote: I'd like to clarify what I'm understanding here: we are to implement the new commands alongside deploy and set as verbs belonging to the Charm code. And these commands are implemented separately from the /cmd code tree

Re: arresting bootstrap teardown

How about --keep-on-error? On Mon, Mar 24, 2014 at 3:00 PM, roger peppe rogpe...@gmail.com wrote: 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

Re: Upcoming import change for loggo

On Wed, Mar 5, 2014 at 5:12 PM, Nate Finch nate.fi...@canonical.com 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 library, but it seems like a bad

Re: Go Style Guide

On Thu, Feb 20, 2014 at 5:31 PM, Nate Finch nate.fi...@canonical.com wrote: One thing that I thought was very interesting was using import dot to get around circular references for tests. I actually hit this exact problem just yesterday.

Re: Go Style Guide

On Thu, Feb 20, 2014 at 6:00 PM, Nate Finch nate.fi...@canonical.com wrote: Well, nevermind. That's just terrible. It's just black box testing the same as any external tests, except obfuscated because you're not using the package name. I don't know why you'd ever want to do that. Right,

Re: New juju-mongodb package

Thanks for pushing this, James. It would be good to have the mongo binary available and working as well, also under that juju-specific namespace. This is the console client, and will be useful to connect to the local juju database when debugging issues. On Thu, Nov 28, 2013 at 11:46 AM, James

Deleting code from goyaml

davecheney wallyworld_: i fixed the bug, tests all pass davecheney by deleting code davecheney i'm not sure how gustavo will like that :) wallyworld_ davecheney: ah, ok. good luck :-) For the record, please don't delete apparently unused logic from the *c.go files in goyaml, unless you went deep

Re: Deleting code from goyaml

/195162 Dave may have been referring on irc to an earlier iteration of his work. His approach was also discussed at the Juju team meeting, and unless I mis-remember, there was broad approval of the approach taken. On 14/11/13 21:33, Gustavo Niemeyer wrote: davecheney wallyworld_: i fixed the bug

Re: High Availability command line interface - future plans.

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 HA you probably want it on dedicated nodes.) Resource waste holds juju back

Re: High Availability command line interface - future plans.

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 things in juju are about management one way or the other, so juju

Re: High Availability command line interface - future plans.

On Fri, Nov 8, 2013 at 9:39 AM, Nate Finch nate.fi...@canonical.com wrote: If you only have 3 machines, do you really need HA from juju? You don't have HA from your machines that are actually running your service. Why not? I have three machines.. Yeah, same here. I still think we need a turn

Re: High Availability command line interface - future plans.

wrote: On 8 November 2013 12:03, Gustavo Niemeyer gust...@niemeyer.net 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

Re: High Availability command line interface - future plans.

juju add-state-server --api-only-please-thanks On Fri, Nov 8, 2013 at 11:43 AM, roger peppe roger.pe...@canonical.com wrote: On 8 November 2013 13:33, Gustavo Niemeyer gust...@niemeyer.net wrote: We'll end up with a command that adds a state server, with a replica of the database and an API

Re: High Availability command line interface - future plans.

On Fri, Nov 8, 2013 at 12:04 PM, roger peppe roger.pe...@canonical.com wrote: On 8 November 2013 13:51, Gustavo Niemeyer gust...@niemeyer.net 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

Re: High Availability command line interface - future plans.

It doesn't feel like the difference between juju ensure-ha --prefer-machines 11,37 and juju add-state-server --to 11,37 is worth the amount of reasoning there. I'm clearly in favor of the latter, but I wouldn't argue so much for it. On Fri, Nov 8, 2013 at 2:00 PM, William Reade

Re: Inactive charmers and charmers

It's not the first time that the inactive bit there creates confusion. One idea would be to rename charmers to be more descriptive, rather than having a negative team (a team that does NOT do something). For example: ~charmers = all charmers ~charm-reviewers = only those who review; this team is

Re: Scale Testing: Now with profiling!

On Mon, Nov 4, 2013 at 12:04 PM, John Arbash Meinel j...@arbash-meinel.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-11-04 17:52, roger peppe wrote: There's no point in salting the agent passwords, and we can't easily change things to salt the user passwords until none of

Re: Notes from Scale testing

On Wed, Oct 30, 2013 at 6:23 AM, John Arbash Meinel j...@arbash-meinel.com wrote: I'm trying to put together a quick summary of what I've found out so far with testing juju in an environment with thousands (5000+) agents. Great testing, John. 2) Agents seem to consume about 17MB resident

Re: Control different relation sequence

around the file. On Wed, Sep 4, 2013 at 12:01 AM, Mike Sam mikesam...@gmail.com wrote: Thanks. Does this mean that the charm should cache the relation id's in a text file or something? On Tue, Sep 3, 2013 at 7:33 PM, Gustavo Niemeyer gustavo.nieme...@canonical.com wrote: The relation-set

Re: Control different relation sequence

around the file. On Wed, Sep 4, 2013 at 12:01 AM, Mike Sam mikesam...@gmail.com wrote: Thanks. Does this mean that the charm should cache the relation id's in a text file or something? On Tue, Sep 3, 2013 at 7:33 PM, Gustavo Niemeyer gustavo.nieme...@canonical.com wrote: The relation-set

Re: Control different relation sequence

Hi Mike, You cannot control the sequence in which the hooks are executed, but you have full control of what you do when the hooks do execute. You can choose to send nothing to the other side of the relation until its time to report that a connection may now be established, and when you do change