ks for server_service/0
and stop and kill client_service/0
Is this correct? As far as I can see, existing charms are no worse off
with this model but there is good chance client/server relations will
benefit; clients are shutdown before the servers cut off their access,
and servers are shutdown a
ationship to share the secret your service generated between that
service's units. If your service needs to share the secret to other
services, it will need a relation to those other services.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at
body helpme? Thanks
You are hitting Bug #1247299
(https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1247299).
I don't know a work around sorry, apart from using a different
provider.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
it
could detect that there are other units in the service (but I suspect
this would still be racy).
I think I recall a helper being suggested to allow a master unit to be
elected safely which would solve my problem properly (and also remove
a lot of complexity from my charm). Did anything like this g
can
detect changes.
If there was someway for my charm to reject config changes rather than
go into a fail state, that would be nice. I'm not sure it is possible
though, as 1) we don't want to block a config update on the hooks
successfully completing 2) if juju rolls back config changes, i
does mean that every unit has root on every other unit in the
relationship web (or perhaps every unit in the environment). Is this
going to be a problem?
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
x27; caused a few minor hiccups, in
that previously config('myitem') == "", but after the change
config('myitem') raised a KeyError. charm-helpers needs a minor
update, as at the moment relation_set('foo', None) sets foo to the
empty string, and instead
On 25 March 2014 19:47, Andreas Hasenack wrote:
> On Tue, Mar 25, 2014 at 7:51 AM, Stuart Bishop
> wrote:
>
>> The simple fix is to add a usernames or extra_usernames parameter on
>> the relation, similar to database, allowing the client to specify a
>> list of ext
On 27 March 2014 03:49, Andreas Hasenack wrote:
> On Tue, Mar 25, 2014 at 12:07 PM, Stuart Bishop
> wrote:
>>> The patch would be like: "GRANT DELETE ON TABLE person TO landscape".
>>> That "landscape" is hardcoded, so that user has to exist and be
On 27 March 2014 15:33, Mark Shuttleworth wrote:
> On 27/03/14 14:51, Stuart Bishop wrote:
>> Correct. I think you are just fine with one relation per database and
>> using the generated credentials, and using the granted roles to
>> control database permissions.
>
> A
On 27 March 2014 19:13, Andreas Hasenack wrote:
> On Thu, Mar 27, 2014 at 3:51 AM, Stuart Bishop
> wrote:
>>> In effect it looks like I don't need to share the credentials among
>>> the services?
>>
>> Correct. I think you are just fine with one relatio
Hi.
Should a charm be responsible for running 'apt-get update', 'apt-get
upgrade' etc?
If so, which hooks should invoke this behavior?
Of course, sometimes a charm has no choice about 'apt-get update', for
example when a config-changed hook needs to add a PPA.
o have "juju run sudo apt-get update" if you want to do it
> manually.
There is 'upgrade-charm'. I could argue that upgrade-charm should do a
full update, so the new version of the charm is running with all the
dependencies it was tested with. But I can argue the other way too
I still need to reap the spawned ssh
subprocesses harder (Bug #
I'm not sure if I could replace this use case with Casey's plugin. My
service-unit will refuse connections that are not coming from a
related client-unit, so my tunnel needs to go via the client-unit
rather than the control
arted hook and to
consider any units claimed by the departing peer as free mongodb
units.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
eed to. Your hooks
can just inspect the mongo relation. relation-get allows all of your
hooks to retrieve data from any of the units in any of your relations
(similarly, relation-set allows you to set your unit's data in any of
your relations).
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
ords handled in a secure fashion currently, and is there
>> an approach I'm not thinking of here?
You could make the problem go away if you have a web service that
supports an OpenID identifier or similar for administrative
authentication. If you use our SSO, you could specify a Launchpad team
name in the config who gets administrative access.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
e from a backup? If I have to do that, what is the benefit of
> having the database itself in a persistent mount?
>
> Is there someone knowledgeable on the postgres charm and AWS that can
> help me with these points?
>
> BTW, I'm very happy to blog about this whole
.
> https://code.launchpad.net/~chad.smith/charms/precise/postgresql/postgresql-using-storage-subordinate/+merge/206078
This has now landed, so what I told you before is a lie :) Now it
should just be a case of wiring together the PostgreSQL charm, the
storage subordinate, and the storage broker.
--
S
mess with this config too?
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
On 3 June 2014 12:11, Stuart Bishop wrote:
> Can I get someone to look at
> https://bugs.launchpad.net/charms/+source/rsyslog/+bug/1323627 ?
Sorry for the noise. I've got the traction I need on this now. Charm
bug in the rsyslog charms rather than juju itself.
--
Stuart Bishop
ndby interfaces (db-admin can remain, as all the operations
requiring a superuser will require the master). A single unit in a
PostgreSQL service will present connection details on the db-master
relations. All-but-one units will present their connection details on
the db-standby relations.
--
St
PostgreSQL charm is going to have to allocate the IP
addresses of the proxies as evenly as it can over the clients. But in
my case I think Azure will end up the same as any other provider, as
with databases we are dealing with private IP addresses rather than
exposing them with public IP addre
On 17 June 2014 22:58, Stuart Bishop wrote:
> On 17 June 2014 20:37, John Meinel wrote:
>
>> I don't know quite how that would work with postgres masters vs postgres
>> slaves, but it does mean that postgres charm is involved in its own proxying
>> (it knows when it
relation-get
juju relation-set
The juju-relinfo package is available in ppa:stub/juju. Source is in
bzr at lp:juju-relinfo, or
https://code.launchpad.net/~stub/juju-relinfo/trunk
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https
ble for relations (relation hooks).
I think you are describing Bug #1254766,
https://bugs.launchpad.net/juju-core/+bug/1254766
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
a ~charmer (and
feel free to just review and not land - I can handle landing when all
the dependant branches are done).
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
g?
I think you are better off using a service configuration item to hold
the version for now, at least until the dust settles. Juju is good
about incrementing the number in the revision file when it needs to,
which is probably not when you want it bumped.
--
Stuart Bishop
--
Juju mailin
ng it.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
zure and joyent IP to also ignore them.
>
> Host 10.*.*.* 172.*.*.* ec2-*.compute-*.amazonaws.com 15.125.*.*
> StrictHostKeyChecking no
> UserKnownHostsFile /dev/null
Alas StrictHostKeyChecking seems the norm, which I can't use as it
turns off port forwarding. But that UserKno
this also works with juju run.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
lti-terrabyte database dump, making it difficult to
deal with.
I imagine the MySQL and MongoDB charms would have similar issues,
pretty much anything where ownership is tracked or passwords are
stored encrypted but need to be provided in plaintext to client
charms.
--
Stuart Bishop
--
Juju mai
ble for relation_list(relids[0]) to be empty.
If you are in foo-relation-joined or foo-relation-changed, then
$JUJU_REMOTE_UNIT should certainly be set. I can imagine that
relation_list might not list that unit yet, as the other end might not
have had a chance to join the relation yet, but t
on this, rather than using tools like
the block storage broker or old-skool explicit manual mounting, could
be considered a bug for the test runners to pick up.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
e block
storage broker.
fwiw, if we needed a charm and discovered it used /mnt, we would
probably 'fix' it to use /srv/whatever. I certainly wouldn't want my
service to fail because someone plugged a USB drive into the MaaS
deployed hardware.
--
Stuart Bishop
--
Juju mailing l
relations in sync
with the actual IP address (or in future, the IP address of one of the
related proxies).
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
On 9 December 2014 at 09:53, Andrew Wilkins
wrote:
> On Tue, Dec 9, 2014 at 10:31 AM, Stuart Bishop
> wrote:
>>
>> Hi.
>>
>> Does juju handle IP address changes of units yet? If so, what hooks
>> can I expect to be invoked?
>
>
> From 1.21 onwar
orm).
I only mentioned this since triggering the relation-changed hooks
could avoid the need to update the charm entirely in some cases. I
doubt it is worth it though.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
space available but I
expect on any real deployments the tear down will fail due to a lack
of disk space.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Ooh... and that would be useful for plenty of other things too. For
example, I can avoid rebalancing the replication ring until the goal
number of units exists.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
g juju pass an option to ssh to not use the
user's known_hosts files, instead a file specific to the environment.
Extra points for having juju clean out keys when machines are
destroyed.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
sysctl
settings, but these are less common and don't cause your system to
grind to a halt when you are testing a charm locally and your desktop
gets swapped out.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
installed in the correct
places and falls back to todays behavior. juju-core would just need to
ensure the package is a dependency and installed on provisioned
machines once it gets out of the PPA.
> On 27/02/15 09:27, Stuart Bishop wrote:
>> Hi.
>>
>> I've seen several b
ally, there's a nice convention for the two non-default scenarios,
> and that convention is implemented in a lot of the glue bits which get
> reused across many different scenarios.
>
> Mark
>
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
port inside the container to the host, but docker has this
built in).
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
patch, and getting the upstream projects patched to
> support the work going on in this branch. (deployer, et-al)
I've flagged the MP as in-progress. Adam's run had picked up what I
think is a genuine and easy to fix race condition in the charm.
--
Stuart Bishop
--
Juju maili
is this just out of scope, and the operator needs to do this sort
of coordination themselves? There is plenty of other coordination that
can't be embedded in the charm as it is (eg. don't drop an old unit if
it is still being used to bootstrap a new unit into the cluster).
--
Stuart Bisho
out the week) that runs the repair on the individual node.
If would be much nicer to have a cronjob that does 'if is-leader, then
run-action repair-cluster'.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
re. lp:charms/cassandra is
lp:charms/precise/cassandra, which has no maintainer. I'm currently
maintaining lp:charms/trusty/cassandra, which already supports
Cassandra 2.x but has no upgrade path from lp:charms/precise/cassandra
and its Cassandra 1.x installs.
--
Stuart Bishop
--
Juju mail
ing a team able to maintain it
approaches zero. We have spent a lot of time rewriting Bash charms in
Python purely to fix bugs and add features, because it was easier. Not
bitter, at all.
> # Conclusion
>
> I welcome discussion, dissent, and suggestions around these topics. They are
&g
okenv and Juju. But if this was a 3rd
party library, it would never gain traction and I doubt I would get
any feedback on the design at all. I think it is helpful and
interesting, but not enough for people to go out of their way do
discover and use. And it is certainly not the sort of thing to port to
other languages - you could do something similar, but the design would
necessarily be different.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
t to tune things
anyway.
(The PG charm rewrite is currently straddling that line, by default
auto tuning shared_buffers to 25% of RAM capped at 8GB, which will
still work under lxc even if its a little overzealous while still
being 'best practice' default tuning).
--
Stuart Bishop
--
Juju
. It sets up ssh authorization in a
peer relation, but perhaps could be adapted to set up ssh authorization
between your two services.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
ual hostname
on each unit).
Can the proxy be a subordinate to save spinning up the container?
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
t comes to my
mind is git support, as IIRC charmhelpers is using an obsolete git
library and the functionality is unavailable with Py3.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
tested charmhelpers functionality supports both Py2 and Py3.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
adstatus.blocked', but if layers start using the lower level
API then state will get out of sync with the hook environment.
Or should everything under the charms namespace be reactive framework
aware, with charms.reactive just being where the engine is stored?
--
Stuart Bishop
--
Juju mailin
ample, so storage-* or install). On the
other units, it will be invoked in a hook run soon after the leader
set the setting. Perhaps the install hook if the leader ran first,
perhaps some later hook, most likely the leader-settings-changed hook
or perhaps the leader-elected hook if leadership failover occurred at
the right moment.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
s a .so file. What
happens when I deploy this charm on power8 or arm? How does the pure
python version of PyYAML appear when the only thing available is a
amd64 binary wheel?
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.co
cate -relation-broken for reactive charms, possibly even
> making it an error to try to react to it?
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
On 20 December 2015 at 02:13, Cory Johns wrote:
> On Sat, Dec 19, 2015 at 3:45 AM, Stuart Bishop
> wrote:
>>
>> Which unit name would you use? -relation-departed gets run multiple
>> times, once for each unit. -relation-broken gets run once, after all
>> the
On 17 December 2015 at 20:10, James Page wrote:
> datastax and midonet repositories and some DNS hijacking (I'll write that up
I'd be interested in knowing what would be required of the Cassandra
charm for it to be used, rather than having Cassandra embedded.
--
Stuart Bish
o be able to do more runs to
confirm that.
- I very much look forward to using a remote lxd server. Its always
surprising how many Cassandra nodes this little laptop can support,
but offloading it to a cloud vm while keeping the fast container
spinup times will be nice ;)
--
Stuart Bishop
by community opinions and automated test
results.
Now, having got the reactive rewrite of the PostgreSQL charm ready for
review, I now need to split out the three layers that will be shared
with the Cassandra charm and available for general use... all this new
stuff seems to be working :)
--
ions that matter are supposed to still be functional, and the few
being ignored done so after careful consideration of the impact.
I think there are also issues to deal with for upgrade-charm, although
Juju might have changed its behaviour since I last looked (are service
settings that no longer exist
so it would only work as transport for
small files.
I'd go ssh myself, since most of it is already setup.
charmhelpers.contrib.unison had code to setup the keys between peers
(I've used this bit and it works, but not the actual unison bit).
--
Stuart Bishop
--
Juju mailing list
Ju
ged hooks on the follower units but
no hooks on itself).
## Support
This layer is maintained on Launchpad by
Stuart Bishop (stuart.bis...@canonical.com).
Code is available using git at git+ssh://git.launchpad.net/leadership-layer.
Bug reports can be made at https://bugs.launchpad.net/leadership-
es installed by this layer.
* `purge(packages)`
Purge one or more deb packages from the system
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
ix its callsites or improve the documentation in your
config.yaml.
So you want to use it to save initial work and future maintenance :)
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
ging. Thoughts?
Sure. Its trivial to add, and if people find it useful great. It does
mean your handlers will get invoked if another layer changes
leadership settings, which I guess may be exactly what you want to
happen.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify setting
ull/20 adds a
@setup decorator to charms.reactive which I think would be better.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
a set of multiple values changing. Thoughts?
I've added this.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
made on the Juju mailing list, Juju IRC
channels, or at https://answers.launchpad.net/layer-coordinator.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
d would
instead setup tunnels and pipes to stream it into a 'juju run'
command. An abuse of Juju resources better suited to Juju blob
storage?
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
he reactive states avoids that
> completely as well as working more naturally with existing @when decorators.
Did you want to pull in the Leadership layer too? Its hard to know
when to stop :) I'd thought this would be better handled as a layer,
for no other reason than it could be done as a separ
ting your own decorator, and if it turns out to
be useful propose it as a charms.reactive update.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
solutions, the documentation for the apt layer
has been updated which states you can call charms.apt.install_queued()
yourself to install queued packages right now. It does nothing if
nothing is queued, so you could just call it at the start of your
handler instead of waiting on an apt.installe
local:postgresql
The main source layer is in the master branch at
git+ssh://git.launchpad.net/postgresql-charm. Merge proposals should
be made against this branch. This is the branch used to build the
deployable built branch.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify
seems easy enough to
implement (just a new decorator - no need to change the reactor), and
the same approach could be used to implement a fixed
@when_file_changed.
(You could even implement @after in your charm or in a layer)
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
ttps://bugs.launchpad.net/juju-core/+bug/1545686, not a huge
issue since with a local branch you can easily hack metadata.yaml).
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
ents that
can be used to build a charm. Machine readable, so the charm store
could display it and we could tell at a glance which charms need
rebuilding because they embed buggy or insecure layers.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
t;proposed" pocket (where stuff goes before it
>> gets to the updates pocket). Machines with "proposed" act as canaries
>> for incoming updates. Security tends to land hard and fast because,
>> well, security, but then it gets a lot more QA and the changes are
&
k fires, such as the leader-settings-changed hooks it
will probably trigger and the relation changes those hooks will likely
trigger). Use the juju-wait plugin, and maybe add support to
https://bugs.launchpad.net/juju-core/+bug/1488777 to get this into
core.
--
Stuart Bishop
--
Ju
nly fixed once. A big improvement over cargo culted
code, where you could end up fixing essentially the same bug or adding
the same feature several times.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
r to a new 5 unit Cassandra cluster.
(the charm doesn't actually do this yet, this is just speculation on
how it could be done). I imagine other services such as OpenStack
Swift would be in the same boat.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
involved than min-juju-version, as the data type change to the
existing setting causes old versions to fail.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
16.04. This is
>> > representative
>> > of all of the OpenStack charms.
>>
>> Bug #1545686 will cause you issues too, unless you are always testing
>> charms served from the store rather than local branches. 'series' is
>> more involved than min-juju
ng clients use that address,
only allowing https:, git+ssh: and other secure protocols for pulling
branches, and checking GPG signatures of embedded wheels are the
issues here I'm aware of)
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
vial compared to forcing users to mangle a charm
> just to get it to deploy on production systems without egress.
Yeah. And fixing it after people are using your charm in production is
a pain, which I learned the hard way :)
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.c
On 1 April 2016 at 20:50, Mark Shuttleworth wrote:
> On 19/03/16 01:02, Stuart Bishop wrote:
>> On 9 March 2016 at 10:51, Mark Shuttleworth wrote:
>>
>>> Operational concerns
>> I still want 'juju-wait' as a supported, builtin command rather than
>&
nk of it, but I haven't tripped
over that one (it limits scalability the way I'm using leadershp
settings, but I should be able to squeeze out several hundred units).
Maybe we can use the opportunity to fix quoting and encoding issues.
I suspect if you can get past command line length limit
atform dependent apart from
the obvious stuff like wrappers around apt. There might be some linux
specific imports at the top level that need to be moved to import on
demand (import apt, import distro_info etc).
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
est_postgresql.py
are the bulk of the unit tests, testing the helpers in
reactive/postgresql/postgresql.py.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
is not necessarily the install hook).
If you are clarifying this, you should also clarify how things work in
the upgrade-charm hook when new config options are added or removed.
Your proposed change does not affect my work, and will allow me to
simplify some things.
--
Stuart Bishop
--
Juju mailing lis
r notice and
cope when the unit's jujud is bounced. Not all units would be running
the same distribution release at the same time, and I'm assuming the
service is running a multi-series charm here that supports both
releases (so we don't need to worry about how to handle upgrade-c
ocked.
But I don't have a true solution. Its still difficult to avoid
handlers stomping over important messages when we are writing
decoupled code.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
the other way around. They solve
> a similar problem but depending on where you are looking are both useful.
Yes. This seems a good thing to have my proposed 'git charm-build' generate too.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
ly as Mark said. I'm still
> trying to find what is causing this failure.
The error from the bug report originates from Squid, which is probably
buffering the upload. The timeout might happen between Squid and
Apache if it takes to long to upload and there is no keep-alive
mechanism in pl
s a number of charms, but only on
the providers with the unexpected behaviour.
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
- contrib.network.ufw
- contrib.benchmark
(this is of course all superseded with charm-tools and reactive
charms, which handles dependencies better).
--
Stuart Bishop
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
1 - 100 of 152 matches
Mail list logo
