Hello,
I have just finished updating the all-new exciting and more comprehensible
commands reference page in the docs for 1.21.1:
https://juju.ubuntu.com/docs/commands.html
The more observant of you will notice that the content has almost all been
autogenerated directly from juju help. This is
I have recently worked on blocking juju commands. If you are creating
new commands, you may find this helpful :-)
PROBLEM
Customers and stakeholders want to be able to prevent accidental damage
to their Juju deployments.
SOLUTION
To prevent running some commands, we have introduced a concept of
updating the all-new exciting and more comprehensible
> commands reference page in the docs for 1.21.1:
>
> https://juju.ubuntu.com/docs/commands.html
>
> The more observant of you will notice that the content has almost all been
> autogenerated directly from juju help. This is
capitalized or not
> and stick with it. I don't really care which.
> On Feb 3, 2015 7:08 AM, "Nick Veitch" wrote:
>
>> Hello,
>>
>> I have just finished updating the all-new exciting and more comprehensible
>> commands reference page in the doc
all other consistant ways are good too.
thx mue
On Tue, Feb 3, 2015 at 1:08 PM, Nick Veitch
wrote:
> Hello,
>
> I have just finished updating the all-new exciting and more comprehensible
> commands reference page in the docs for 1.21.1:
>
> https://juju.ubuntu.com/docs/commands
On 02/03/2015 01:08 PM, Nick Veitch wrote:
> Hello,
>
> I have just finished updating the all-new exciting and more comprehensible
> commands reference page in the docs for 1.21.1:
>
> https://juju.ubuntu.com/docs/commands.html
I love this! A good reference manual of some so
n Tue, Feb 3, 2015 at 2:08 PM, Nick Veitch
wrote:
> Hello,
>
> I have just finished updating the all-new exciting and more comprehensible
> commands reference page in the docs for 1.21.1:
>
> https://juju.ubuntu.com/docs/commands.html
>
> The more observant of you w
On Wed, Feb 4, 2015 at 6:40 AM, John Meinel wrote:
> I'd hope that you'd have a well informed opinion of
> what makes the most sense in an online documentation. (I'm slightly leaning
> towards Title case, but not much).
Oh, I *do* have a passionate opinion about it :)
Title case, 'Usage:', make
Looks great, Nick! Cheers for the good work, and I love that it's
automatically synchronized! This should drive quality up in both places!
On Tue, Feb 3, 2015 at 6:08 AM, Nick Veitch
wrote:
> Hello,
>
> I have just finished updating the all-new exciting and more comprehensi
Hi
Just a quick note for developers that use developer commands.
'juju dump-model' and 'juju dump-db' are changing on develop tip [1],
from 2.3.x.
These commands are now fully-fledged model commands as they were
originally designed.
This means that they will now accept mod
06:52, Anastasia Macmood <
anastasia.macm...@canonical.com> wrote:
>
> I have recently worked on blocking juju commands. If you are creating
> new commands, you may find this helpful :-)
>
> PROBLEM
> Customers and stakeholders want to be able to prevent accidental damag
Thank you, Roger!
This sounds like an interesting use case :-)
At this stage, we can block commands not so much commands based on their
parameters . So, if you switch REMOVE_BLOCK on, any attempt to remove
services will be blocked regardless of the individual service :-)
However, blocking a
binMOC2fYDKR9.bin
Description: PGP/MIME version identification
encrypted.asc
Description: OpenPGP encrypted message
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
I don't think you intended to send the email as PGP encrypted.
John
=:->
2017-08-28 12:06 GMT+04:00 Tim Penhey :
> -BEGIN PGP MESSAGE-
> Version: GnuPG v2
>
> hQIMA233D38ktbXXAQ/+P+Wl6YvVE3PVo1tsN/ynVPSeR5Xu3SfKLoRmXvxM0om/
> /LXYkelYeD5xuJCuLP87gNqiDqJnDZi4I0kOWkLjeG9xvAAJY/57tZLbv29qu
-- Here is un-encrypted version \o/ --
Hi
Just a quick note for developers that use developer commands.
'juju dump-model' and 'juju dump-db' are changing on develop tip [1],
from 2.3.x.
These commands are now fully-fledged model commands as they were
originally designed.
FYI, the developer commands were originally designed like the controller
commands.
You don't say "juju destroy-model -m foo".
Tim
On 28/08/17 19:48, Anastasia Macmood wrote:
> Hi
>
> Just a quick note for developers that use developer commands.
>
> 'juju
Tim,
Completely agree :)
By changing where these commands fit within command infrastructure, they
gained access to some useful methods. Thus, eliminating code duplication
and inconsistencies.
The versions of command, acting as "controller" type commands, that take
no arguments, in
Furthermore, if you are seeing any problems with these commands or if
you *think* that they no longer behave as per your expectations, let me
know :D
On 28/08/17 21:18, Anastasia Macmood wrote:
> Tim,
>
> Completely agree :)
>
> By changing where these commands fit within command
On Mon, Aug 28, 2017 at 5:17 PM Tim Penhey wrote:
> FYI, the developer commands were originally designed like the controller
> commands.
>
> You don't say "juju destroy-model -m foo".
>
I think that holds for "dump-model", but I'm not so sure abou
very dev focused, and both only usable by admins.
Tim
On 29/08/17 13:11, Andrew Wilkins wrote:
> On Mon, Aug 28, 2017 at 5:17 PM Tim Penhey <mailto:tim.pen...@canonical.com>> wrote:
>
> FYI, the developer commands were originally designed like the controller
> comman
2017 at 5:17 PM Tim Penhey > <mailto:tim.pen...@canonical.com>> wrote:
> >
> > FYI, the developer commands were originally designed like the
> controller
> > commands.
> >
> > You don't say "juju destroy-model -m foo".
> >
Hi folks,
More from the "let's fix the output" school of thought.
One thing that has bugged me about 'juju help commands' was the repeated
mentions of "alias for ".
I propose that we don't show aliases by default, and allow the user to
task for
Tim
If you are adding the ability to specify commands as "hidden", we may
greatly benefit from specifying commands as "blockable" too
Sincerely Yours,
Anastasia
On 24/05/16 14:19, Tim Penhey wrote:
> Hi folks,
>
> More from the "let's fix the output
Hidden would be a primitive defined in the github.com/juju/cmd package,
whereas the "blockable" consideration is an implementation detail of
juju commands.
I don't think we should specify them the same way.
However, that doesn't mean that Juju shouldn't have a base
On Tue, May 24, 2016, 12:19 AM Tim Penhey wrote:
> Hi folks,
>
> More from the "let's fix the output" school of thought.
>
> One thing that has bugged me about 'juju help commands' was the repeated
> mentions of "alias for ".
>
> I p
If there are things we really don't want uses to run, they should probably
just not exist in production builds. If they're just less-used commands,
then I don't think it's a big deal to have them in juju help commands.
If we want to remove them from production builds,
the "hidden" commands instead of the ability to hide commands.
If you set the feature flag, you get the additional commands, and they
show up in help etc. That way a way to get users to run them could be
something like:
JUJU_FEATURE_FLAGS=dev-debug juju dump-model
or something
I think this has come up before on this list, but: isn't having 2 sets of
commands in the first place a design smell? If we need aliases because users
aren't using the originals, then shouldn't we fix the original commands?
Tim Penhey writes:
> On 25/05/16 00:12, Marco Ce
-bu...@canonical.com> wrote:
>
> I think this has come up before on this list, but: isn't having 2 sets of
> commands in the first place a design smell? If we need aliases because
> users aren't using the originals, then shouldn't we fix the original
> commands?
>
> T
Some feedback
If we have a debug command we should just show the debug commands. If we
don't want users to have them ootb they should be plugins then I would
think. This assumes the commands can't do anything destructive or
otherwise harm a running model/etc by being run.
The ge
e a debug command we should just show the debug commands. If we
> don't want users to have them ootb they should be plugins then I would
> think. This assumes the commands can't do anything destructive or
> otherwise harm a running model/etc by being run.
>
> The get is the
On Thu, May 26, 2016 at 6:47 AM Rick Harding
wrote:
> One more chunk of feedback, I think conversations like this can/should
> happen on the main juju list. I know folks dump to dev a lot, but this is
> something very public facing and has an impact on users.
>
+1000
--
Juju-dev mailing list
Ju
Noticed some intermittent test failures today when running tests on master
branch (@a2ea824) on my laptop under heavy load. Tests seem to pass when
the system is otherwise idle, leading me to suspect a
timing/scheduling-related issue. Here's an example I captured:
http://paste.ubuntu.com/12058748/
On 25/05/16 01:49, Nate Finch wrote:
While we're on the subject... we have list-foos, show-foos, and
get-foo... and I honestly cannot remember when to use which. Can we just
standardize on one, so no one has to remember if it's list-models or
show-models or show-model-config or get-model-config?
I can understand list-clouds vs show-cloud, for plural vs singular (even
though I don't think we actually have commands like that, with a plural and
a singular). But show-config vs get-config seems really pedantic. You're
still showing one thing. One is a foo, one is a foo-config. They
50ff27a3b642ae5a5621c
> apiserver/params/internal.go b3f281f2f3f0ac2791d18f4dda30defb8821d235
> apiserver/client/run.go c39e8f9e185a2562bf8be7537d0e2c3930cd13c3
>
> Diff: http://reviews.vapour.ws/r/15/diff/
>
>
> Testing
> ---
>
> All tests passing.
> Ma
36 matches
Mail list logo
