Re: juju-br0

[Merlijn Sebrechts]

This Charm

is a horrible hack that creates the lxcbr0 interface on a host and bridges
it to the given network. You can use this to crudely change networking of
lxc containers by first deploying the charm to the host itself and then
deploying charms to lxc containers. In the future I'll also be looking into
changing default routes on the lxc container. Let me know if you can use
this. I could put it in its own repository, put it in the Charm store and
accept pull requests if there is interest for it.

@Andrew: I'm using lxc containers in the manual provider and manage their
networks using the above Charm. I'm very interested in more "official"
support for this.

2015-12-02 8:48 GMT+01:00 Andrew McDermott :

> The short answer is not at the moment. However, we were discussing this
> only yesterday (by chance!) and we plan to create a bridge per NIC.
>
> On 2 December 2015 at 00:38, Pshem Kowalczyk  wrote:
>
>> Hi,
>>
>> Currently all my LXC containers are joined to juju-br0, which also
>> contains first physical interface (in my case eth0). Is there a way to
>> deploy those LXC with more complicated networking setup (for example
>> bridging with eth1, or having access to multiple bridges)? If so - how can
>> that be achieved?
>>
>> kind regards
>> Pshem
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
>
> --
> Andrew McDermott 
> Juju Core Sapphire team 
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

apiserver authorizers

[William Reade]

I just noticed that the unitassigner facade-constructor drops the
authorizer on the floor; and I caught a similar case in a review yesterday
(that had already been LGTMed by someone else).

Doing that means that *any* api connection can use the thus-unprotected
facade -- clients, agents, and malicious code running in a compromised
machine and using the agent credentials. I don't think we have any APIs
where this is actually a good idea; the best I could say about any such
case is that it's not *actively* harmful *right now*. But big exploits are
made of little holes, let's make an effort not to open them in the first
place.

Moonstone, please fix the unitassigner facade ASAP; everyone else, be told,
and keep an extra eye out for this issue in reviews :).

Cheers
William
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: juju-br0

[Merlijn Sebrechts]

You specify the network it is supposed to bridge to using the `network`
config option of the lxc-networking charm. It searches the interface that
is on that network and bridges to that interface. I do it this way because
interfaces are different from node to node in our cloud.

2015-12-02 21:54 GMT+01:00 Pshem Kowalczyk :

>
> Is there a way to specify the interface it's going to bridge lxcbr0 to?
>
> kind regards
> Pshem
>
>
>
>
> On Thu, 3 Dec 2015 at 09:49 Merlijn Sebrechts 
> wrote:
>
>> This Charm
>> 
>> is a horrible hack that creates the lxcbr0 interface on a host and bridges
>> it to the given network. You can use this to crudely change networking of
>> lxc containers by first deploying the charm to the host itself and then
>> deploying charms to lxc containers. In the future I'll also be looking into
>> changing default routes on the lxc container. Let me know if you can use
>> this. I could put it in its own repository, put it in the Charm store and
>> accept pull requests if there is interest for it.
>>
>> @Andrew: I'm using lxc containers in the manual provider and manage their
>> networks using the above Charm. I'm very interested in more "official"
>> support for this.
>>
>> 2015-12-02 8:48 GMT+01:00 Andrew McDermott <
>> andrew.mcderm...@canonical.com>:
>>
>>> The short answer is not at the moment. However, we were discussing this
>>> only yesterday (by chance!) and we plan to create a bridge per NIC.
>>>
>>> On 2 December 2015 at 00:38, Pshem Kowalczyk  wrote:
>>>
 Hi,

 Currently all my LXC containers are joined to juju-br0, which also
 contains first physical interface (in my case eth0). Is there a way to
 deploy those LXC with more complicated networking setup (for example
 bridging with eth1, or having access to multiple bridges)? If so - how can
 that be achieved?

 kind regards
 Pshem


 --
 Juju mailing list
 Juju@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju


>>>
>>>
>>> --
>>> Andrew McDermott 
>>> Juju Core Sapphire team 
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: After deploying openstack,I can't create vm instance

[Narinder Gupta]

Yuanyou ZHANG,

Looks like you are having the similar issue which I find during my testing
with kilo in OPNFV and logged  bug under rabbitmq-server
https://bugs.launchpad.net/charms/+source/rabbitmq-server/+bug/1506642 .

Only workaround is to restart the rabbitmq, nova-conductor and nova-compute
services.  But after some time we observed the same issue again.

After moving to Liberty Openstack we are not observing this behavior.


Thanks and Regards,
Narinder Gupta (PMP)   narinder.gu...@canonical.com
Canonical, Ltd.narindergupta [irc.freenode.net]
+1.281.736.5150narindergupta2007[skype]

Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com


On Wed, Dec 2, 2015 at 9:04 PM, zhangyuanyou 
wrote:

> Hi Artur Tyloch,
>   I'm working on deploying openstack-kilo using Juju,now I can deploy
> openstack successfully and create network in openstack-dashboard.
>
> But when I create a vm instance, I find the nova-compute shutdown.
> I login the controller node and show the nova service-list,I find there is
> not nova-consoleauth.
> So I do this: apt-get install nova-consoleauth,but how can I reboot the
> nova-compute? Any assistance is greatly appreciated.
>
> ++++--+-+---++-+
> | Id | Binary | Host   | Zone | Status  |
> State | Updated_at | Disabled Reason |
>
> ++++--+-+---++-+
> | 1  | nova-cert  | onos-local-machine-1-lxc-3 | internal | enabled |
> up| 2015-12-02T09:56:38.00 | -   |
> | 2  | nova-conductor | onos-local-machine-1-lxc-3 | internal | enabled |
> up| 2015-12-02T09:56:39.00 | -   |
> | 3  | nova-scheduler | onos-local-machine-1-lxc-3 | internal | enabled |
> up| 2015-12-02T09:56:39.00 | -   |
> | 4  | nova-compute   | onos-local-machine-3   | nova | enabled |
> down  | 2015-12-02T09:47:43.00 | -   |
>
> ++++--+-+---++-+
>
> nova-conductor.log:
> 2015-12-02 08:59:00.341 11084 INFO nova.openstack.common.service
> [req-6d38fc33-712f-4b12-83d0-d4399e870a5e - - - - -] Started child 11249
> 2015-12-02 08:59:00.348 11084 INFO nova.openstack.common.service
> [req-6d38fc33-712f-4b12-83d0-d4399e870a5e - - - - -] Started child 11250
> 2015-12-02 08:59:00.358 11248 INFO nova.service [-] Starting conductor
> node (version 2015.1.2)
> 2015-12-02 08:59:00.358 11084 INFO nova.openstack.common.service
> [req-6d38fc33-712f-4b12-83d0-d4399e870a5e - - - - -] Started child 11251
> 2015-12-02 08:59:00.367 11250 INFO nova.service [-] Starting conductor
> node (version 2015.1.2)
> 2015-12-02 08:59:00.367 11249 INFO nova.service [-] Starting conductor
> node (version 2015.1.2)
> 2015-12-02 08:59:00.372 11251 INFO nova.service [-] Starting conductor
> node (version 2015.1.2)
> 2015-12-02 08:59:00.413 11084 WARNING oslo_config.cfg
> [req-6d38fc33-712f-4b12-83d0-d4399e870a5e - - - - -] Option "lock_path"
> from group "DEFAULT" is deprecated. Use option "lock_path" from group
> "oslo_concurrency".
> 2015-12-02 08:59:00.734 11244 INFO oslo_messaging._drivers.impl_rabbit
> [req-70fa0b3e-71d8-4171-9d63-83757938f02d - - - - -] Connecting to AMQP
> server on localhost:5672
> 2015-12-02 08:59:00.753 11244 ERROR oslo_messaging._drivers.impl_rabbit
> [req-70fa0b3e-71d8-4171-9d63-83757938f02d - - - - -] AMQP server on
> 127.0.0.1:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in
> 1 seconds.
> 2015-12-02 08:59:00.774 11247 INFO oslo_messaging._drivers.impl_rabbit
> [req-2447759d-c90b-41d0-90a0-ec7a23551b86 - - - - -] Connecting to AMQP
> server on localhost:5672
> 2015-12-02 08:59:00.778 11245 INFO oslo_messaging._drivers.impl_rabbit
> [req-7db8bff8-46ae-4f14-ad0a-11506c858369 - - - - -] Connecting to AMQP
> server on localhost:5672
> 2015-12-02 08:59:00.783 11247 ERROR oslo_messaging._drivers.impl_rabbit
> [req-2447759d-c90b-41d0-90a0-ec7a23551b86 - - - - -] AMQP server on
> 127.0.0.1:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in
> 1 seconds.
> 2015-12-02 08:59:00.783 11242 INFO oslo_messaging._drivers.impl_rabbit
> [req-a0bab9d4-e8c4-4674-9fd9-d355a7137a1a - - - - -] Connecting to AMQP
> server on localhost:5672
> 2015-12-02 08:59:00.787 11245 ERROR oslo_messaging._drivers.impl_rabbit
> [req-7db8bff8-46ae-4f14-ad0a-11506c858369 - - - - -] AMQP server on
> 127.0.0.1:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in
> 1 seconds.
> 2015-12-02 08:59:00.791 11242 ERROR oslo_messaging._drivers.impl_rabbit
> [req-a0bab9d4-e8c4-4674-9fd9-d355a7137a1a - - - - -] AMQP server on
> 127.0.0.1:5672 is unreachable: [Errno 111] ECONNREFUSED. 

Re: utils/fslock needs to DIAF

[John Meinel]

Note that the NFS case means that we may be wanting to lock a file we are
about to write *across machines*. We can decide we won't support that case,
but if the point is that we don't want 2 processes concurrently writing to
~./juju/server-cache.yaml, then we need something that works when people
have $HOME as an NFS partition. (Or we just claim it is unsupported.)

If we can do locking within a single machine, there are lots of solutions
that work well and are easy (its true that flock doesn't block multiple
threads from grabbing the OS lock, but you can just write your own
in-memory mutex for the in-process stuff, and use flock to coordinate
between processes), NFS meant that flock didn't always work, but if
new-enough instances work, then we can go with it. (IIRC, flock was an
option on NFS mounts, so we can't actually guarantee that we'll have
something like flock between machines.)

Bazaar went with "create a directory, put a file in that directory, and
rename the directory into place", because it was the only FS primitive that
actually worked across lots of filesystem implementations (renaming an
empty dir can just replace the dir on some systems), and there was a bug in
some implementations of SFTP where "rename a => b" was turned into "mv a =>
b/a" if b existed. You can detect the latter by writing a nonce and then
reading it back.

However, we certainly aren't trying to do the level of "you can access the
lock via SFTP, NFS, local path and ...". So we don't have to go as
lowest-common-denominator.

But we do need to consider if we are supporting multi-machine access. I
don't think we need cross-machine support for Agent locking, but it seems
likely that we do need it for $HOME handling.

John
=:->

On Tue, Dec 1, 2015 at 11:23 PM, Nate Finch 
wrote:

> Certainly using Windows' file system lock is appropriate for locking its
> files.  I thought the case we were talking about was just abusing that
> ability as a generic cross-process lock.
>
> I wasn't aware of how configstore was using fslock.
>
> On Tue, Dec 1, 2015 at 11:58 AM roger peppe 
> wrote:
>
>> On 1 December 2015 at 16:43, Nate Finch  wrote:
>> > I think half the problem is that someone named the package fslock and
>> not
>> > oslock, so we're stuck asking the wrong question.
>> >
>> > If the question is "How do I acquire an OS-level lock for a process?"
>> The
>> > answer on Windows is "Use a named mutex".
>>
>> That's not the question we need to answer here, for the configstore case
>> anyway. In that case, we really do want to protect access to a shared data
>> store in the filesystem, so the term "fslock" is appropriate I think.
>>
>> >  Dave seems to be saying that the
>> > only problem with unix domain sockets is if you try to think about them
>> like
>> > files... which may be a result of us thinking too much about the
>> solution
>> > and not the problem. (again, I'm not an expert, you guys can duke out
>> what
>> > the best solution is)  I think using hackery with the filesystem
>> locking on
>> > Windows is a mistake.
>>
>> Is there something wrong with using the Windows file-exclusive-open
>> semantics to implement a lock associated with a entity in the file system?
>> Isn't that what it's for?
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

After deploying openstack,I can't create vm instance

[zhangyuanyou]

Hi Artur Tyloch,
  I'm working on deploying openstack-kilo using Juju,now I can deploy openstack 
successfully and create network in openstack-dashboard.
But when I create a vm instance, I find the nova-compute shutdown.
I login the controller node and show the nova service-list,I find there is not 
nova-consoleauth.
So I do this: apt-get install nova-consoleauth,but how can I reboot the 
nova-compute? Any assistance is greatly appreciated.
++++--+-+---++-+
| Id | Binary | Host   | Zone | Status  | State 
| Updated_at | Disabled Reason |
++++--+-+---++-+
| 1  | nova-cert  | onos-local-machine-1-lxc-3 | internal | enabled | up
| 2015-12-02T09:56:38.00 | -   |
| 2  | nova-conductor | onos-local-machine-1-lxc-3 | internal | enabled | up
| 2015-12-02T09:56:39.00 | -   |
| 3  | nova-scheduler | onos-local-machine-1-lxc-3 | internal | enabled | up
| 2015-12-02T09:56:39.00 | -   |
| 4  | nova-compute   | onos-local-machine-3   | nova | enabled | down  
| 2015-12-02T09:47:43.00 | -   |
++++--+-+---++-+

nova-conductor.log:
2015-12-02 08:59:00.341 11084 INFO nova.openstack.common.service 
[req-6d38fc33-712f-4b12-83d0-d4399e870a5e - - - - -] Started child 11249
2015-12-02 08:59:00.348 11084 INFO nova.openstack.common.service 
[req-6d38fc33-712f-4b12-83d0-d4399e870a5e - - - - -] Started child 11250
2015-12-02 08:59:00.358 11248 INFO nova.service [-] Starting conductor node 
(version 2015.1.2)
2015-12-02 08:59:00.358 11084 INFO nova.openstack.common.service 
[req-6d38fc33-712f-4b12-83d0-d4399e870a5e - - - - -] Started child 11251
2015-12-02 08:59:00.367 11250 INFO nova.service [-] Starting conductor node 
(version 2015.1.2)
2015-12-02 08:59:00.367 11249 INFO nova.service [-] Starting conductor node 
(version 2015.1.2)
2015-12-02 08:59:00.372 11251 INFO nova.service [-] Starting conductor node 
(version 2015.1.2)
2015-12-02 08:59:00.413 11084 WARNING oslo_config.cfg 
[req-6d38fc33-712f-4b12-83d0-d4399e870a5e - - - - -] Option "lock_path" from 
group "DEFAULT" is deprecated. Use option "lock_path" from group 
"oslo_concurrency".
2015-12-02 08:59:00.734 11244 INFO oslo_messaging._drivers.impl_rabbit 
[req-70fa0b3e-71d8-4171-9d63-83757938f02d - - - - -] Connecting to AMQP server 
on localhost:5672
2015-12-02 08:59:00.753 11244 ERROR oslo_messaging._drivers.impl_rabbit 
[req-70fa0b3e-71d8-4171-9d63-83757938f02d - - - - -] AMQP server on 
127.0.0.1:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 1 
seconds.
2015-12-02 08:59:00.774 11247 INFO oslo_messaging._drivers.impl_rabbit 
[req-2447759d-c90b-41d0-90a0-ec7a23551b86 - - - - -] Connecting to AMQP server 
on localhost:5672
2015-12-02 08:59:00.778 11245 INFO oslo_messaging._drivers.impl_rabbit 
[req-7db8bff8-46ae-4f14-ad0a-11506c858369 - - - - -] Connecting to AMQP server 
on localhost:5672
2015-12-02 08:59:00.783 11247 ERROR oslo_messaging._drivers.impl_rabbit 
[req-2447759d-c90b-41d0-90a0-ec7a23551b86 - - - - -] AMQP server on 
127.0.0.1:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 1 
seconds.
2015-12-02 08:59:00.783 11242 INFO oslo_messaging._drivers.impl_rabbit 
[req-a0bab9d4-e8c4-4674-9fd9-d355a7137a1a - - - - -] Connecting to AMQP server 
on localhost:5672
2015-12-02 08:59:00.787 11245 ERROR oslo_messaging._drivers.impl_rabbit 
[req-7db8bff8-46ae-4f14-ad0a-11506c858369 - - - - -] AMQP server on 
127.0.0.1:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 1 
seconds.
2015-12-02 08:59:00.791 11242 ERROR oslo_messaging._drivers.impl_rabbit 
[req-a0bab9d4-e8c4-4674-9fd9-d355a7137a1a - - - - -] AMQP server on 
127.0.0.1:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 1 
seconds.
2015-12-02 08:59:00.801 11251 INFO oslo_messaging._drivers.impl_rabbit 
[req-5af923e7-722a-4552-a788-f426c43dc916 - - - - -] Connecting to AMQP server 
on localhost:5672
2015-12-02 08:59:00.806 11249 INFO oslo_messaging._drivers.impl_rabbit 
[req-1b0fa84e-c4fa-4a83-8398-25280ec1386c - - - - -] Connecting to AMQP server 
on localhost:5672
2015-12-02 08:59:00.813 11243 INFO oslo_messaging._drivers.impl_rabbit 
[req-eb6fcf93-070a-4380-b3f3-2016ca4cc626 - - - - -] Connecting to AMQP server 
on localhost:5672
2015-12-02 08:59:00.816 11251 ERROR oslo_messaging._drivers.impl_rabbit 
[req-5af923e7-722a-4552-a788-f426c43dc916 - - - - -] AMQP server on 
127.0.0.1:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 1 
seconds.
2015-12-02 08:59:00.821 11250 INFO oslo_messaging._drivers.impl_rabbit 
[req-8b512b83-6475-47b6-8090-3ee4c3889216 - - - - -] Connecting to AMQP server 

Re: apiserver authorizers

[William Reade]

The case I spotted yesterday was here:
http://reviews.vapour.ws/r/3243/diff/1/?file=167369#file167369line41

and in general:

  * seeing `_ common.Authorizer` in a parameter list is a sign you're DIW.
  * failing to check some auth property when creating the facade is a sign
you're DIW.
  * failing to pass the auth on to the facade type itself *might* be OK,
but should be viewed with some suspicion -- for example:
  * an environ provisioner may have wide-ranging powers, but that's no
reason to let it see or modify container machines that are not its direct
responsibility
  * right now, many user-facing facades don't need further
authorization once they know it's an authenticated client, but that won't
last forever

helpful?

Cheers
William

On Wed, Dec 2, 2015 at 12:26 PM, roger peppe 
wrote:

> Could you link to the offending change(s) please, so we
> can see what doing it wrong looks like?
>
> On 2 December 2015 at 09:28, William Reade 
> wrote:
> > I just noticed that the unitassigner facade-constructor drops the
> authorizer
> > on the floor; and I caught a similar case in a review yesterday (that had
> > already been LGTMed by someone else).
> >
> > Doing that means that *any* api connection can use the thus-unprotected
> > facade -- clients, agents, and malicious code running in a compromised
> > machine and using the agent credentials. I don't think we have any APIs
> > where this is actually a good idea; the best I could say about any such
> case
> > is that it's not *actively* harmful *right now*. But big exploits are
> made
> > of little holes, let's make an effort not to open them in the first
> place.
> >
> > Moonstone, please fix the unitassigner facade ASAP; everyone else, be
> told,
> > and keep an extra eye out for this issue in reviews :).
> >
> > Cheers
> > William
> >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: apiserver authorizers

[roger peppe]

Could you link to the offending change(s) please, so we
can see what doing it wrong looks like?

On 2 December 2015 at 09:28, William Reade  wrote:
> I just noticed that the unitassigner facade-constructor drops the authorizer
> on the floor; and I caught a similar case in a review yesterday (that had
> already been LGTMed by someone else).
>
> Doing that means that *any* api connection can use the thus-unprotected
> facade -- clients, agents, and malicious code running in a compromised
> machine and using the agent credentials. I don't think we have any APIs
> where this is actually a good idea; the best I could say about any such case
> is that it's not *actively* harmful *right now*. But big exploits are made
> of little holes, let's make an effort not to open them in the first place.
>
> Moonstone, please fix the unitassigner facade ASAP; everyone else, be told,
> and keep an extra eye out for this issue in reviews :).
>
> Cheers
> William
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: apiserver authorizers

[Nate Finch]

Auth on the api is a big mystery to me. Is there a document on the expected
behavior and the functions and types that back it up?

For example, you said "an environ provisioner may have wide-ranging powers,
but that's no reason to let it see or modify container machines that are
not its direct responsibility" ... I don't really know what that means.
This sounds like authorization, but how do you know who is calling your api
or what they're supposed to be allowed to do?

On Wed, Dec 2, 2015, 6:36 AM William Reade 
wrote:

> The case I spotted yesterday was here:
> http://reviews.vapour.ws/r/3243/diff/1/?file=167369#file167369line41
>
> and in general:
>
>   * seeing `_ common.Authorizer` in a parameter list is a sign you're DIW.
>   * failing to check some auth property when creating the facade is a sign
> you're DIW.
>   * failing to pass the auth on to the facade type itself *might* be OK,
> but should be viewed with some suspicion -- for example:
>   * an environ provisioner may have wide-ranging powers, but that's no
> reason to let it see or modify container machines that are not its direct
> responsibility
>   * right now, many user-facing facades don't need further
> authorization once they know it's an authenticated client, but that won't
> last forever
>
> helpful?
>
> Cheers
> William
>
> On Wed, Dec 2, 2015 at 12:26 PM, roger peppe 
> wrote:
>
>> Could you link to the offending change(s) please, so we
>> can see what doing it wrong looks like?
>>
>> On 2 December 2015 at 09:28, William Reade 
>> wrote:
>> > I just noticed that the unitassigner facade-constructor drops the
>> authorizer
>> > on the floor; and I caught a similar case in a review yesterday (that
>> had
>> > already been LGTMed by someone else).
>> >
>> > Doing that means that *any* api connection can use the thus-unprotected
>> > facade -- clients, agents, and malicious code running in a compromised
>> > machine and using the agent credentials. I don't think we have any APIs
>> > where this is actually a good idea; the best I could say about any such
>> case
>> > is that it's not *actively* harmful *right now*. But big exploits are
>> made
>> > of little holes, let's make an effort not to open them in the first
>> place.
>> >
>> > Moonstone, please fix the unitassigner facade ASAP; everyone else, be
>> told,
>> > and keep an extra eye out for this issue in reviews :).
>> >
>> > Cheers
>> > William
>> >
>> > --
>> > Juju-dev mailing list
>> > Juju-dev@lists.ubuntu.com
>> > Modify settings or unsubscribe at:
>> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
>> >
>>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev