A new development release of Juju, 2.0-beta15, is here!

[Nicholas Skaggs]

A new development release of Juju, 2.0-beta15, is here!


## What's new?


This releases addresses stability and performance issues including 29 bugs
from b14 last week. Some notable ones include:


* lxd containers not using configured proxy for downloading images

  LP 1594720 https://bugs.launchpad.net/juju-core/+bug/1594720

* juju2 beta11 unable to parse PORT during a maas bootstrap

  LP 1599972 https://bugs.launchpad.net/juju-core/+bug/1599972

* LXD no longer activates all interfaces on initial deploy when using
MAAS2rc3 and JUJU Beta13

  LP 1608105 https://bugs.launchpad.net/juju-core/+bug/1608105

* It is not possible to refer to multiple models with the same name from
the CLI

  LP 1597720 https://bugs.launchpad.net/juju-core/+bug/1597720


## How do I get it?


If you are running Ubuntu, you can get it from the Juju devel PPA:


sudo apt-add-repository ppa:juju/devel

sudo apt-get update; sudo apt-get install juju-2.0


Or install it from the snap store


snap install juju --beta --devmode


Windows, Centos, and OS X users can get a corresponding installer at:


https://launchpad.net/juju-core/+milestone/2.0-beta15



## Feedback Appreciated!


We encourage everyone to subscribe the mailing list at

juju@lists.ubuntu.com and join us on #juju on freenode. We would love to

hear your feedback and usage of juju.



## Anything else?


You can read more information about what's in this release by viewing

the release notes here:


https://jujucharms.com/docs/devel/temp-release-notes
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Default bootstrap machine sizes on public clouds

[Mark Shuttleworth]

It's been a while since we discussed the default machine sizes to use
when bootstrapping on public clouds. Now that we have multi-model
controllers I'm seeing folks stress the controller a lot harder (which
is good :)) and I wonder if we shouldn't up the defaults?


Mark

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

Re: So I wanted to update a dependency . .

[Casey Marshall]

On Thu, Aug 11, 2016 at 5:44 PM, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> This is a simple story of a man and a simple mission. Eliminate the final
> 2 dependencies that are in bazaar and launchpad. It makes juju and it's
> dependencies live completely in git. A notable goal, and one that I desired
> for getting snaps to build with launchpad.
>
> I don't feel I need to explain the pain that making a no-source change
> update to a dependency (point juju and friends to it's new location) has
> been. I've had to carefully craft a set of PR's, and land them in a certain
> order. I've encountered contention (because I have to change hundreds of
> imports), unit test issues (because juju's dependencies aren't tested when
> merged, so they can be incompatible with the latest juju without knowing
> it), and circular dependencies that require some magic and wishful thinking
> to workaround.
>
> I'm still not finished landing the change, but I hope to do so *soon*. It
> must be close now!
>
> All of this to say, I think it would be useful to have a discussion on how
> we manage dependencies within the project. From a release perspective, it
> can be quite cumbersome as dependencies are picked up and dropped. It's
> also recently made a release (And critical bugfix) really difficult at
> times. From my newly experience contributor perspective, I would really
> think twice before attempting to make an update :-) I suspect I'm not alone.
>
> I've heard ideas in the past about cleaning this up, and some things like
> circular dependencies between romulus and juju are probably best described
> as tech debt. But there also is some pain in the larger scheme of things.
> For example, we are currently hacking a patch to juju's source for the mgo
> dependency since updating the source or vendoring or any other option is
> way too painful. It's time to really fix this. Ideas?
>

My team's been chipping away at romulus and it'll be sorted out soon
enough. We've already moved the terms API client out to
github.com/juju/terms-client, and we'll be doing something similar for the
other APIs. As for the commands.. these probably need to find a better home
closer to the command base types they extend, in cmd/juju/...

One thing that occurred to me today though is most of our dependencies also
have tests (well, they should!). We don't often run *those* tests as part
of Juju CI, but you could run into some cases where some dependencies share
common dependencies, but are tested with different common dependency
versions than those specified by Juju's dependencies.tsv.


> --
> 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: Some Juju CLI usability thoughts before we close 2.0

[Ian Booth]

On 11/08/16 17:46, Ian Booth wrote:
> 
> On 11/08/16 17:03, John Meinel wrote:
>> On Thu, Aug 11, 2016 at 9:30 AM, Ian Booth  wrote:
>>
>>> A few things have been irking me with some aspects of Juju's CLI. Here's a
>>> few
>>> thoughts from a user perspective (well, me as user, YMMV).
>>>
>>> The following pain points mainly revolve around commands that operate on a
>>> controller rather than a model.
>>>
>>> eg
>>>
>>> $ juju login [-c controllername] fred
>>> $ juju logout [-c controllername]
>>>
>>
>> I would agree with 'juju login' as it really seems you have to supply the
>> controller, especially since we explicitly disallow logging into the same
>> controller twice. The only case is 'juju logout && juju login'. Or the 'I
>> have to refresh my macaroon' but in that case couldn't we just do "juju
>> login" with no args at all?
>>
>>
>>
>>>
>>> I really think the -c arg is not that natural here.
>>>
>>> $ juju login controllername fred
>>> $ juju logout controllername
>>>
>>> seem a lot more natural and also explicit, because
>>> I know without args, the "current" controller will be used...
>>> but it's not in your face what that is without running list-controllers
>>> first,
>>> and so it's too easy to logout of the wrong controller accidentally. Having
>>> positional args solves that.
>>>
>>
>> I'm fine with an optional positional arg and "juju logout" removes you from
>> the current controller. As it isn't destructive (you can always login
>> again), as long as the command lets you know *what* you just logged out of,
>> you can undo your mistake. Vs "destroy-controller" which is significantly
>> more permanent when it finishes.
>>
>>
>>
>>>
>>> The same would then apply to other controller commands, like eg add-model
>>>
>>> $ juju add-model mycontroller mymodel
>>>
>>> One thing that might be an issue for people is if they only have one
>>> controller,
>>> then
>>>
>>> $ juju logout
>>> or
>>> $ juju add-model
>>>
>>> would just work and requiring a controller name is more typing.
>>>
>>
>> I disagree on 'juju add-model', as I think we have a very good concept of
>> "current context" and adding another model to your current controller is a
>> natural event.
>>
> 
> Fair point.
> 
>>
>>>
>>> But 2 points there:
>>> 1. as we move forward, people reasonably have more than one controller on
>>> the go
>>> at any time, and being explicit about what controller you are wanting to
>>> use is
>>> a good thing
>>> 2. in the one controller case, we could simply make the controller name
>>> optional
>>> so juju logout just works
>>>
>>> We already use a positional arg for destroy-controller - it just seems
>>> natural
>>> to do it everywhere for all controller commands.
>>>
>>
>> destroy-controller was always a special case because it is an unrecoverable
>> operation. Almost everything else you can use current context and if it was
>> a mistake you can easily recover.
>>
>>
>>>
>>> Anyways, I'd like to see what others think, mine is just the perspective
>>> of one
>>> user. I'd be happy to do a snap and put it out there to get feedback.
>>>
>>> --
>>>
>>> Another issue - I would really, really like a "juju whoami" command. We
>>> used to
>>> use juju switch-user without args for that, but now it's gone.
>>>
>>> When you are staring at a command prompt and you know you have several
>>> controllers and different logins active, I really want to just go:
>>>
>>> $ juju whoami
>>> Currently active as fred@controller2
>>
>>
>> I'd say you'd want what your current user, controller and model is, as that
>> is the current 'context' for commands.
>>
> 
> Agreed, adding model would be necessary.
> 

And as Rick pointed out, this mirrors charm whoami nicely too. So we get that
level of consistency across our Juju commands.

>>
>>>
>>
>>
>>> Just to get a quick reminder of what controller I am operating on and who
>>> I am
>>> logged in as on the controller.  I know we have a way of doing that via
>>> list
>>> controllers, but if there's a few, or even if not, you still need to scan
>>> your
>>> eyes down a table and look for the one wit the * to see the current one
>>> and then
>>> scan across and get see the user etc. It's all a lot harder than just a
>>> whoami
>>> command IMO.
>>>
>>> --
>>>
>>> We will need a juju shares command to show who has access to a controller,
>>> now
>>> that we have controller permissions login, addmodel, superuser.
>>>
>>> For models, we support:
>>>
>>> $ juju shares -m model
>>> $ juju shares (for the default model)
>>>
>>> What do we want for controller shares?
>>>
>>> $ juju shares-controller  ?
>>>
>>
>> It would certainly at least be "controller-shares" (and
>> list-controller-shares) not "shares-controller".
>>
> 
> Bah, had a dyslexic moment. Yes, controller-shares
> 

Rick brought up a great suggestion - we should just add the access level to
list-users. This then fits in with the same approach below for list controllers
and list models.


>>
>>>
>>> 

So I wanted to update a dependency . .

[Nicholas Skaggs]

This is a simple story of a man and a simple mission. Eliminate the final 2
dependencies that are in bazaar and launchpad. It makes juju and it's
dependencies live completely in git. A notable goal, and one that I desired
for getting snaps to build with launchpad.

I don't feel I need to explain the pain that making a no-source change
update to a dependency (point juju and friends to it's new location) has
been. I've had to carefully craft a set of PR's, and land them in a certain
order. I've encountered contention (because I have to change hundreds of
imports), unit test issues (because juju's dependencies aren't tested when
merged, so they can be incompatible with the latest juju without knowing
it), and circular dependencies that require some magic and wishful thinking
to workaround.

I'm still not finished landing the change, but I hope to do so *soon*. It
must be close now!

All of this to say, I think it would be useful to have a discussion on how
we manage dependencies within the project. From a release perspective, it
can be quite cumbersome as dependencies are picked up and dropped. It's
also recently made a release (And critical bugfix) really difficult at
times. From my newly experience contributor perspective, I would really
think twice before attempting to make an update :-) I suspect I'm not alone.

I've heard ideas in the past about cleaning this up, and some things like
circular dependencies between romulus and juju are probably best described
as tech debt. But there also is some pain in the larger scheme of things.
For example, we are currently hacking a patch to juju's source for the mgo
dependency since updating the source or vendoring or any other option is
way too painful. It's time to really fix this. Ideas?
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: maas in a container

[Jason Hobbs]

Daniel,

Can you show the full dump of your profile and container configs?

Here's what my 'maas' profile looks like:

ubuntu@beartic:~$ lxc profile show maas
name: maas
config:
  raw.lxc: |-
lxc.cgroup.devices.allow = c 10:237 rwm
lxc.aa_profile = unconfined
lxc.cgroup.devices.allow = b 7:* rwm
  security.privileged: "true"
description: ""
devices:
  eth0:
name: eth0
nictype: bridged
parent: br1
type: nic
  loop0:
path: /dev/loop0
type: unix-block
  loop1:
path: /dev/loop1
type: unix-block
  loop2:
path: /dev/loop2
type: unix-block
  loop3:
path: /dev/loop3
type: unix-block
  loop4:
path: /dev/loop4
type: unix-block
  loop5:
path: /dev/loop5
type: unix-block
  loop6:
path: /dev/loop6
type: unix-block
  loop7:
path: /dev/loop7
type: unix-block

Here's the config for the container maas is running in:
ubuntu@beartic:~$ lxc config show maas-server
name: maas-server
profiles:
- maas
config:
  volatile.base_image:
d23ee1f4fd284aeaba6adeb67cccf7b871e96178d637fec96320aab7cc9634b1
  volatile.eth0.hwaddr: 00:16:3e:ca:9e:31
  volatile.last_state.idmap: '[]'
devices:
  root:
path: /
type: disk
ephemeral: false

Thanks,
Jason

On Wed, Aug 10, 2016 at 8:09 AM, Daniel Bidwell  wrote:

> I have followed the steps below, but still no luck.  Here is what I
> have:
>
> /var/log/syslog on my container, maastest, shows:
>
> Aug 10 12:51:05 maastest kernel: [210439.259086] audit: type=1400
> audit(14708334
> 65.435:829): apparmor="DENIED" operation="mount" info="failed flags match"
> error
> =-13 profile="lxd-maastest_" name="/tmp/maas-9bYBDZ/"
> pid=13267 co
> mm="mount" fstype="ext4" srcname="/dev/loop0" flags="ro"
>
> From the machine holding the container a "lxc profile show maastest"
> returns:
>
> lxc profile show maastest
> name: maastest
> config:
>   raw.lxc: lxc.cgroup.devices.allow = c 10:237 rwm
> lxc.cgroup.devices.allow = b 7:*
> rwm lxc.aa_profile = unconfined
>   security.privileged: "true"
> description: ""
> devices:
> ...
>
> The maastest profile has been applied to the maastest container.
>
> /etc/apparmor.d/lxc-custom-default contains:
>
> profile lxc-container-extx-mounts
> flags=(attach_disconnected,mediate_deleted) {
>   #include 
>   mount fstype=ext4 -> /**,
>   mount fstype=ext3 -> /**,
>   mount fstype=ext2 -> /**,
> }
>
> Any suggestions as to what I am missing?
>
> On Sat, 2016-08-06 at 22:50 -0500, Jason Hobbs wrote:
> > Hi Daniel,
> >
> > There is some documentation for installing MAAS in a container here:
> >
> > https://maas.ubuntu.com/docs/install.html#container-install
> >
> > It's focused on 2.0 but the same steps should work for 1.9.3 too. It
> > covers setting up the loop devices.
> >
> > Hope this helps,
> > Jason
> >
> > On Sat, Aug 6, 2016 at 10:11 PM, Daniel Bidwell 
> > wrote:
> > > I have a lxd container running on 16.04 with maas 1.9.3 running in
> > > it.
> > >
> > > The pxe boot doesn't work because the container doesn't have any
> > > /dev/loop* devices and will not allow me to create any.
> > >
> > > How do I go about creating /dev/loop* devices and allowing them to
> > > work
> > > in a container?
> > > --
> > > Daniel Bidwell 
> > >
> > >
> > > --
> > > Juju mailing list
> > > Juju@lists.ubuntu.com
> > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman
> > > /listinfo/juju
> > >
> --
> Daniel Bidwell 
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Uniter test failure from utils update

[Nicholas Skaggs]

Thanks for the insights here. I ended up reverting the offending change,
https://github.com/juju/utils/pull/203. @bogdanteleaga, my apologies for
reverting, but I'm not sure how to fix with your change so I went back to
something that worked. It's worth following up and figuring out how to
re-land it.

On Thu, Aug 11, 2016 at 8:18 AM, William Reade 
wrote:

> (or, at least, it's something like that -- the general point is that you
> shouldn't throw away values you don't know you don't need)
>
> On Thu, Aug 11, 2016 at 2:14 PM, William Reade <
> william.re...@canonical.com> wrote:
>
>> worker/uniter/operation/runcommands.go:68... uses `context.ErrReboot` to
>> indicate "there is a valid response value that should be handled, but we
>> also need to queue a reboot". The change throws away the valid response.
>>
>> On Thu, Aug 11, 2016 at 1:47 AM, Martin Packman <
>> martin.pack...@canonical.com> wrote:
>>
>>> Nicholas was struggling today to land his snapcraft pull request:
>>>
>>> 
>>>
>>> As a side effect this updates some dependencies, including a couple of
>>> changes to juju/utils, which it turns out, causes
>>> UniterSuite.TestRebootFromJujuRun to fail.
>>>
>>> Here's a run of master, which passes:
>>>
>>> 
>>>
>>> Then the failure, just with utils updated to rev 8a9dea0:
>>>
>>> 
>>>
>>> I'm not clear on how the new exec behaviour is actually causing the
>>> test failure:
>>>
>>> 
>>>
>>> So, any insights or suggestions welcome.
>>>
>>>
>>> Note, the log also includes two other errors, but they appear in both
>>> the passing and failing log, so are not actually affecting the test
>>> outcome:
>>>
>>> [LOG] 0:01.631 ERROR juju.apiserver Unable to prime
>>> /tmp/check-1447535164350529303/5/logsink.log (proceeding anyway):
>>> chown /tmp/check-1447535164350529303/5/logsink.log: operation not
>>> permitted
>>>
>>> This code should probably just not be being run under unit test, is
>>> assuming root privs?
>>>
>>> [LOG] 0:03.078 ERROR juju.worker.uniter.context updating agent status:
>>> cannot set invalid status "rebooting"
>>>
>>> The status setting code in uniter is a twisty confusion, I don't know
>>> why this is happening or where the error is being swallowed.
>>>
>>> Martin
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/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

Re: Point people to ubuntu-on-windows instead of the broken juju-on-windows?

[Jorge O. Castro]

On Thu, Aug 11, 2016 at 2:02 PM, Nate Finch  wrote:
> The linux ssh works so much better because we can simply run the OS's ssh
> and everything Just Works, but that's not possible on Windows, so it's much
> more involved to make it work (we basically have to write an entire ssh
> client).

Microsoft announced that OpenSSH will be coming to Powershell at some
point, so that's probably the client we should use when it lands.

We can track progress here since they OSSed Powershell:

https://github.com/PowerShell/Win32-OpenSSH/wiki/Win32-OpenSSH-RoadMap

Sounds like it should be ready for us to at least play with soon?

-- 
Jorge Castro
Canonical Ltd.
http://jujucharms.com/ - The fastest way to model your service

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

Re: Point people to ubuntu-on-windows instead of the broken juju-on-windows?

[Merlijn Sebrechts]

Hi Nate


Thanks for your quick reply! My colleagues will just 'upgrade' to windows
10 so this doesn't really apply to us anymore but wouldn't it be easier to
package putty with the windows juju client and use that as default? Writing
an entire ssh client seems a bit overkill.. or is there an advantage to
having a CLI ssh terminal?



Kind regards
Merlijn

2016-08-11 20:02 GMT+02:00 Nate Finch :

> Just FYI - running the juju client on Windows is 100% supported and we
> actively fix bugs on it all the time.   I hadn't seen the particular bug
> you referenced about juju ssh, but that definitely seems like something we
> should prioritize higher.  The linux ssh works so much better because we
> can simply run the OS's ssh and everything Just Works, but that's not
> possible on Windows, so it's much more involved to make it work (we
> basically have to write an entire ssh client).
>
> However, as a workaround, it would be pretty trivial to write a juju
> plugin to launch putty with the right parameters.  Then you'd just do `juju
> putty 0` rather than juju ssh 0.  Obviously, it would open putty, not a CLI
> ssh terminal, but the overall experience is probably a lot better than what
> we could provide.
>
> On Thu, Aug 11, 2016 at 11:41 AM Marco Ceppi 
> wrote:
>
>> On Thu, Aug 11, 2016 at 11:27 AM Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Hi all
>>>
>>>
>>> Juju-on-windows is pretty broken and it doesn't seem that bugs are being
>>> fixed anymore. Wouldn't it be better to point people to Juju on "Ubuntu on
>>> windows" instead? One of my colleagues started using it and it seems to
>>> work just fine.
>>>
>>> Some show-stopping bugs in Juju-on-windows:
>>>
>>>- `juju ssh` is not translating newlines correctly
>>>.
>>>- windows users can't create layered charms because the Charm tools
>>>for windows is still at 1.2.9.
>>>
>>>
>>> This is a doc mistake, I'll have an updated charm-tools msi before the
>> end of the week in the docs.
>>
>> What do you guys think?
>>>
>>
>> I think you've got a good point, however, not everyone is on Windows 10.
>> Pointing people who are on Windows 10 to WSL instead would be fruitful for
>> a good native experience.
>> --
>> 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: Point people to ubuntu-on-windows instead of the broken juju-on-windows?

[Nate Finch]

Just FYI - running the juju client on Windows is 100% supported and we
actively fix bugs on it all the time.   I hadn't seen the particular bug
you referenced about juju ssh, but that definitely seems like something we
should prioritize higher.  The linux ssh works so much better because we
can simply run the OS's ssh and everything Just Works, but that's not
possible on Windows, so it's much more involved to make it work (we
basically have to write an entire ssh client).

However, as a workaround, it would be pretty trivial to write a juju plugin
to launch putty with the right parameters.  Then you'd just do `juju putty
0` rather than juju ssh 0.  Obviously, it would open putty, not a CLI ssh
terminal, but the overall experience is probably a lot better than what we
could provide.

On Thu, Aug 11, 2016 at 11:41 AM Marco Ceppi 
wrote:

> On Thu, Aug 11, 2016 at 11:27 AM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi all
>>
>>
>> Juju-on-windows is pretty broken and it doesn't seem that bugs are being
>> fixed anymore. Wouldn't it be better to point people to Juju on "Ubuntu on
>> windows" instead? One of my colleagues started using it and it seems to
>> work just fine.
>>
>> Some show-stopping bugs in Juju-on-windows:
>>
>>- `juju ssh` is not translating newlines correctly
>>.
>>- windows users can't create layered charms because the Charm tools
>>for windows is still at 1.2.9.
>>
>>
>> This is a doc mistake, I'll have an updated charm-tools msi before the
> end of the week in the docs.
>
> What do you guys think?
>>
>
> I think you've got a good point, however, not everyone is on Windows 10.
> Pointing people who are on Windows 10 to WSL instead would be fruitful for
> a good native experience.
> --
> 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

Point people to ubuntu-on-windows instead of the broken juju-on-windows?

[Merlijn Sebrechts]

Hi all


Juju-on-windows is pretty broken and it doesn't seem that bugs are being
fixed anymore. Wouldn't it be better to point people to Juju on "Ubuntu on
windows" instead? One of my colleagues started using it and it seems to
work just fine.

Some show-stopping bugs in Juju-on-windows:

   - `juju ssh` is not translating newlines correctly
   .
   - windows users can't create layered charms because the Charm tools for
   windows is still at 1.2.9.
   




What do you guys think?

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

Re: Uniter test failure from utils update

[William Reade]

(or, at least, it's something like that -- the general point is that you
shouldn't throw away values you don't know you don't need)

On Thu, Aug 11, 2016 at 2:14 PM, William Reade 
wrote:

> worker/uniter/operation/runcommands.go:68... uses `context.ErrReboot` to
> indicate "there is a valid response value that should be handled, but we
> also need to queue a reboot". The change throws away the valid response.
>
> On Thu, Aug 11, 2016 at 1:47 AM, Martin Packman <
> martin.pack...@canonical.com> wrote:
>
>> Nicholas was struggling today to land his snapcraft pull request:
>>
>> 
>>
>> As a side effect this updates some dependencies, including a couple of
>> changes to juju/utils, which it turns out, causes
>> UniterSuite.TestRebootFromJujuRun to fail.
>>
>> Here's a run of master, which passes:
>>
>> 
>>
>> Then the failure, just with utils updated to rev 8a9dea0:
>>
>> 
>>
>> I'm not clear on how the new exec behaviour is actually causing the
>> test failure:
>>
>> 
>>
>> So, any insights or suggestions welcome.
>>
>>
>> Note, the log also includes two other errors, but they appear in both
>> the passing and failing log, so are not actually affecting the test
>> outcome:
>>
>> [LOG] 0:01.631 ERROR juju.apiserver Unable to prime
>> /tmp/check-1447535164350529303/5/logsink.log (proceeding anyway):
>> chown /tmp/check-1447535164350529303/5/logsink.log: operation not
>> permitted
>>
>> This code should probably just not be being run under unit test, is
>> assuming root privs?
>>
>> [LOG] 0:03.078 ERROR juju.worker.uniter.context updating agent status:
>> cannot set invalid status "rebooting"
>>
>> The status setting code in uniter is a twisty confusion, I don't know
>> why this is happening or where the error is being swallowed.
>>
>> Martin
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/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: Uniter test failure from utils update

[William Reade]

worker/uniter/operation/runcommands.go:68... uses `context.ErrReboot` to
indicate "there is a valid response value that should be handled, but we
also need to queue a reboot". The change throws away the valid response.

On Thu, Aug 11, 2016 at 1:47 AM, Martin Packman <
martin.pack...@canonical.com> wrote:

> Nicholas was struggling today to land his snapcraft pull request:
>
> 
>
> As a side effect this updates some dependencies, including a couple of
> changes to juju/utils, which it turns out, causes
> UniterSuite.TestRebootFromJujuRun to fail.
>
> Here's a run of master, which passes:
>
> 
>
> Then the failure, just with utils updated to rev 8a9dea0:
>
> 
>
> I'm not clear on how the new exec behaviour is actually causing the
> test failure:
>
> 
>
> So, any insights or suggestions welcome.
>
>
> Note, the log also includes two other errors, but they appear in both
> the passing and failing log, so are not actually affecting the test
> outcome:
>
> [LOG] 0:01.631 ERROR juju.apiserver Unable to prime
> /tmp/check-1447535164350529303/5/logsink.log (proceeding anyway):
> chown /tmp/check-1447535164350529303/5/logsink.log: operation not
> permitted
>
> This code should probably just not be being run under unit test, is
> assuming root privs?
>
> [LOG] 0:03.078 ERROR juju.worker.uniter.context updating agent status:
> cannot set invalid status "rebooting"
>
> The status setting code in uniter is a twisty confusion, I don't know
> why this is happening or where the error is being swallowed.
>
> Martin
>
> --
> 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: Regarding Terms

[Matthew Williams]

Just replying publicly to confirm that this was done earlier this morning

Thanks

Matty

On Thu, Aug 11, 2016 at 10:30 AM, Shruthima Almavar 
wrote:

> Hi,
> We have sent a request for terms creation through the terms link (
> https://docs.google.com/forms/d/1sOfp0a6KLY9kqnpPeGwHv_
> YQJv7LEbXH1CAV-xBaMjU/viewform?edit_requested=true
> 
> )
> for the following charms:
>
> ibm-http-server
> ibm-http-plg
> ibm-http-wct
> ibm-mobilefirstserver
> ibm-spectrum-scale
>
>
> Could you please create terms as soon as possible.
>
> Thank you..!!!
>
> Regards,
> Shruthima
>
>
>
> --
> 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

Regarding Terms

[Shruthima Almavar]

Hi,
We have sent a request for terms creation through the terms link ( 
https://docs.google.com/forms/d/1sOfp0a6KLY9kqnpPeGwHv_YQJv7LEbXH1CAV-xBaMjU/viewform?edit_requested=true
)
for the following charms:

ibm-http-server
ibm-http-plg
ibm-http-wct
ibm-mobilefirstserver
ibm-spectrum-scale 


Could you please create terms as soon as possible.

Thank you..!!!

Regards,
Shruthima



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

Re: Some Juju CLI usability thoughts before we close 2.0

[Ian Booth]

On 11/08/16 17:03, John Meinel wrote:
> On Thu, Aug 11, 2016 at 9:30 AM, Ian Booth  wrote:
>
> > A few things have been irking me with some aspects of Juju's CLI. Here's a
> > few
> > thoughts from a user perspective (well, me as user, YMMV).
> >
> > The following pain points mainly revolve around commands that operate on a
> > controller rather than a model.
> >
> > eg
> >
> > $ juju login [-c controllername] fred
> > $ juju logout [-c controllername]
> >
>
> I would agree with 'juju login' as it really seems you have to supply the
> controller, especially since we explicitly disallow logging into the same
> controller twice. The only case is 'juju logout && juju login'. Or the 'I
> have to refresh my macaroon' but in that case couldn't we just do "juju
> login" with no args at all?
>
>
>
> >
> > I really think the -c arg is not that natural here.
> >
> > $ juju login controllername fred
> > $ juju logout controllername
> >
> > seem a lot more natural and also explicit, because
> > I know without args, the "current" controller will be used...
> > but it's not in your face what that is without running list-controllers
> > first,
> > and so it's too easy to logout of the wrong controller accidentally. Having
> > positional args solves that.
> >
>
> I'm fine with an optional positional arg and "juju logout" removes you from
> the current controller. As it isn't destructive (you can always login
> again), as long as the command lets you know *what* you just logged out of,
> you can undo your mistake. Vs "destroy-controller" which is significantly
> more permanent when it finishes.
>
>
>
> >
> > The same would then apply to other controller commands, like eg add-model
> >
> > $ juju add-model mycontroller mymodel
> >
> > One thing that might be an issue for people is if they only have one
> > controller,
> > then
> >
> > $ juju logout
> > or
> > $ juju add-model
> >
> > would just work and requiring a controller name is more typing.
> >
>
> I disagree on 'juju add-model', as I think we have a very good concept of
> "current context" and adding another model to your current controller is a
> natural event.
>

Fair point.

>
> >
> > But 2 points there:
> > 1. as we move forward, people reasonably have more than one controller on
> > the go
> > at any time, and being explicit about what controller you are wanting to
> > use is
> > a good thing
> > 2. in the one controller case, we could simply make the controller name
> > optional
> > so juju logout just works
> >
> > We already use a positional arg for destroy-controller - it just seems
> > natural
> > to do it everywhere for all controller commands.
> >
>
> destroy-controller was always a special case because it is an unrecoverable
> operation. Almost everything else you can use current context and if it was
> a mistake you can easily recover.
>
>
> >
> > Anyways, I'd like to see what others think, mine is just the perspective
> > of one
> > user. I'd be happy to do a snap and put it out there to get feedback.
> >
> > --
> >
> > Another issue - I would really, really like a "juju whoami" command. We
> > used to
> > use juju switch-user without args for that, but now it's gone.
> >
> > When you are staring at a command prompt and you know you have several
> > controllers and different logins active, I really want to just go:
> >
> > $ juju whoami
> > Currently active as fred@controller2
>
>
> I'd say you'd want what your current user, controller and model is, as that
> is the current 'context' for commands.
>

Agreed, adding model would be necessary.

>
> >
>
>
> > Just to get a quick reminder of what controller I am operating on and who
> > I am
> > logged in as on the controller.  I know we have a way of doing that via
> > list
> > controllers, but if there's a few, or even if not, you still need to scan
> > your
> > eyes down a table and look for the one wit the * to see the current one
> > and then
> > scan across and get see the user etc. It's all a lot harder than just a
> > whoami
> > command IMO.
> >
> > --
> >
> > We will need a juju shares command to show who has access to a controller,
> > now
> > that we have controller permissions login, addmodel, superuser.
> >
> > For models, we support:
> >
> > $ juju shares -m model
> > $ juju shares (for the default model)
> >
> > What do we want for controller shares?
> >
> > $ juju shares-controller  ?
> >
>
> It would certainly at least be "controller-shares" (and
> list-controller-shares) not "shares-controller".
>

Bah, had a dyslexic moment. Yes, controller-shares

>
> >
> > which would support positional arg
> >
> > $ juju shares-controller mycontroller   ?
> >
>
> Again, current context is perfectly ok here. We use current context for all
> model commands (juju status doesn't require you to specify the model each
> time). And arguably you're switching controller far less often than you
> would be switching models.
>
> I wonder if we could roll controller shares just into 

Re: Some Juju CLI usability thoughts before we close 2.0

[John Meinel]

On Thu, Aug 11, 2016 at 9:30 AM, Ian Booth  wrote:

> A few things have been irking me with some aspects of Juju's CLI. Here's a
> few
> thoughts from a user perspective (well, me as user, YMMV).
>
> The following pain points mainly revolve around commands that operate on a
> controller rather than a model.
>
> eg
>
> $ juju login [-c controllername] fred
> $ juju logout [-c controllername]
>

I would agree with 'juju login' as it really seems you have to supply the
controller, especially since we explicitly disallow logging into the same
controller twice. The only case is 'juju logout && juju login'. Or the 'I
have to refresh my macaroon' but in that case couldn't we just do "juju
login" with no args at all?



>
> I really think the -c arg is not that natural here.
>
> $ juju login controllername fred
> $ juju logout controllername
>
> seem a lot more natural and also explicit, because
> I know without args, the "current" controller will be used...
> but it's not in your face what that is without running list-controllers
> first,
> and so it's too easy to logout of the wrong controller accidentally. Having
> positional args solves that.
>

I'm fine with an optional positional arg and "juju logout" removes you from
the current controller. As it isn't destructive (you can always login
again), as long as the command lets you know *what* you just logged out of,
you can undo your mistake. Vs "destroy-controller" which is significantly
more permanent when it finishes.



>
> The same would then apply to other controller commands, like eg add-model
>
> $ juju add-model mycontroller mymodel
>
> One thing that might be an issue for people is if they only have one
> controller,
> then
>
> $ juju logout
> or
> $ juju add-model
>
> would just work and requiring a controller name is more typing.
>

I disagree on 'juju add-model', as I think we have a very good concept of
"current context" and adding another model to your current controller is a
natural event.


>
> But 2 points there:
> 1. as we move forward, people reasonably have more than one controller on
> the go
> at any time, and being explicit about what controller you are wanting to
> use is
> a good thing
> 2. in the one controller case, we could simply make the controller name
> optional
> so juju logout just works
>
> We already use a positional arg for destroy-controller - it just seems
> natural
> to do it everywhere for all controller commands.
>

destroy-controller was always a special case because it is an unrecoverable
operation. Almost everything else you can use current context and if it was
a mistake you can easily recover.


>
> Anyways, I'd like to see what others think, mine is just the perspective
> of one
> user. I'd be happy to do a snap and put it out there to get feedback.
>
> --
>
> Another issue - I would really, really like a "juju whoami" command. We
> used to
> use juju switch-user without args for that, but now it's gone.
>
> When you are staring at a command prompt and you know you have several
> controllers and different logins active, I really want to just go:
>
> $ juju whoami
> Currently active as fred@controller2


I'd say you'd want what your current user, controller and model is, as that
is the current 'context' for commands.


>


> Just to get a quick reminder of what controller I am operating on and who
> I am
> logged in as on the controller.  I know we have a way of doing that via
> list
> controllers, but if there's a few, or even if not, you still need to scan
> your
> eyes down a table and look for the one wit the * to see the current one
> and then
> scan across and get see the user etc. It's all a lot harder than just a
> whoami
> command IMO.
>
> --
>
> We will need a juju shares command to show who has access to a controller,
> now
> that we have controller permissions login, addmodel, superuser.
>
> For models, we support:
>
> $ juju shares -m model
> $ juju shares (for the default model)
>
> What do we want for controller shares?
>
> $ juju shares-controller  ?
>

It would certainly at least be "controller-shares" (and
list-controller-shares) not "shares-controller".


>
> which would support positional arg
>
> $ juju shares-controller mycontroller   ?
>

Again, current context is perfectly ok here. We use current context for all
model commands (juju status doesn't require you to specify the model each
time). And arguably you're switching controller far less often than you
would be switching models.

I wonder if we could roll controller shares just into the same command.


> --
>
> On the subject of shares, the shares command shows all users with access
> to a
> model (or soon a controller as per above). That's great for admins to see
> who
> they are sharing their stuff with. What I'd like as a user is a command to
> tell
> me what level of access I have to various controllers and models. I'd like
> this
> in list-controllers and list-models.
>
> $ juju list-controllers
>
>