Re: admin is dead, long live $USER

[John Meinel]

We ssh into the machine to finish setting it up. I don't think we use
cloud-init much for the initial machine. That way we can set up secret
passwords, etc.

John
=:->
On Mar 4, 2016 11:09 AM, "Ian Booth"  wrote:

> Hey Tim
>
> The new bootstrap UX has not removed any --admin-user flag.
> I can see that the server jujud bootstrap command has an --admin-user
> argument
> but it appears this is never set anywhere in the cloud init scripts. Or
> not that
> I can see. I've checked older version of the relevant files and can't see
> where
> we've ever used this.
>
> So maybe we have a capability to bootstrap the controller agent with a
> specified
> admin-user but have not hooked it up yet?
>
> On 04/03/16 08:11, Tim Penhey wrote:
> > Ah... it used to be there :-) At least it is on my feature branch, but I
> > don't think I have merged the most recent master updates that has the
> > work to re-work bootstrap for the new cloud credentials stuff.
> >
> > Tim
> >
> > On 04/03/16 10:09, Rick Harding wrote:
> >> If we do that we need to also make it configurable on bootstrap as an
> >> option.
> >>
> >> +1 overall
> >>
> >>
> >> On Thu, Mar 3, 2016, 4:07 PM Tim Penhey  >> > wrote:
> >>
> >> Hi folks,
> >>
> >> I was thinking that with the upcoming big changes with 2.0, we
> should
> >> tackle a long held issue where we have the initial user called
> "admin".
> >>
> >> There was a request some time back that we should use the current
> user's
> >> name. The reason it wasn't implemented at that time was due to
> logging
> >> into the GUI issues. These have been resolved some time back with
> the
> >> multiple user support that was added.
> >>
> >> All the server side code handles the ability to define the initial
> user
> >> for the controller model, and we do this in all the tests, so the
> >> default test user is actually called "test-admin".
> >>
> >> I *think* that all we need to do is change the default value we use
> in
> >> the bootstrap command for the AdminUserName (--admin-user flag) from
> >> "admin" to something we derive from the current user.
> >>
> >> Probably worth doing now.
> >>
> >> Thoughts?
> >>
> >> Tim
> >>
> >> --
> >> 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

Re: admin is dead, long live $USER

[Ian Booth]

Hey Tim

The new bootstrap UX has not removed any --admin-user flag.
I can see that the server jujud bootstrap command has an --admin-user argument
but it appears this is never set anywhere in the cloud init scripts. Or not that
I can see. I've checked older version of the relevant files and can't see where
we've ever used this.

So maybe we have a capability to bootstrap the controller agent with a specified
admin-user but have not hooked it up yet?

On 04/03/16 08:11, Tim Penhey wrote:
> Ah... it used to be there :-) At least it is on my feature branch, but I
> don't think I have merged the most recent master updates that has the
> work to re-work bootstrap for the new cloud credentials stuff.
> 
> Tim
> 
> On 04/03/16 10:09, Rick Harding wrote:
>> If we do that we need to also make it configurable on bootstrap as an
>> option.
>>
>> +1 overall
>>
>>
>> On Thu, Mar 3, 2016, 4:07 PM Tim Penhey > > wrote:
>>
>> Hi folks,
>>
>> I was thinking that with the upcoming big changes with 2.0, we should
>> tackle a long held issue where we have the initial user called "admin".
>>
>> There was a request some time back that we should use the current user's
>> name. The reason it wasn't implemented at that time was due to logging
>> into the GUI issues. These have been resolved some time back with the
>> multiple user support that was added.
>>
>> All the server side code handles the ability to define the initial user
>> for the controller model, and we do this in all the tests, so the
>> default test user is actually called "test-admin".
>>
>> I *think* that all we need to do is change the default value we use in
>> the bootstrap command for the AdminUserName (--admin-user flag) from
>> "admin" to something we derive from the current user.
>>
>> Probably worth doing now.
>>
>> Thoughts?
>>
>> Tim
>>
>> --
>> 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 2.0 and local charm deployment

[Ian Booth]

Hi folks

TL;DR we want to remove support for old style local charm repositories in Juju 
2.0

Hopefully everyone is aware that Juju 2.0 and the charm store will support
multi-series charms. To recap, a multi-series charm is one which can declare
that it supports more than just the one series; you no longer need to have a
separate copy of the charm for precise vs trusty vs xenial. Note that all series
must be for the same OS so you'll still need separate charm sources for Windows
vs Ubuntu vs Centos.

Here's a link to the release notes
https://jujucharms.com/docs/devel/temp-release-notes#multi-series-charms

Juju 2.0 will also support deploying bundles natively
https://jujucharms.com/docs/devel/temp-release-notes#native-support-for-charm-bundles

So, with multi-series charm support, local charm deployment is now also a lot
easier. Back in Juju 1.x, to deploy local charms you needed to set up a
so-called charm repository, with a proscribed directory layout. The directory
layout has one directory per series.

_ mycharms
 |_precise
  |_mysql
 |_trusty
  |_mysql
 |_bundle
  |_openstack

You deployed using a local URL syntax:

$ juju deploy --repository ~/mycharms local:trusty/mysql

$ juju deploy --repository ~/mycharms local:bundle/openstack

The above structure was fine for when charms were duplicated for each series.
But one of the limitations is that you can't easily git checkout mycharm and
deploy straight from the vcs source on disk.

Juju 2.0 supports deploying charms and bundles straight from any directory,
including where you've checked out your launchpad/github charm source.

$ juju deploy ~/mygithubstuff/mysql

$ juju deploy ~/mygithubstuff/openstack/bundle.yaml

So the above combined with the consolidation of charms for many series into the
one source tree means that the old local repo support is not needed.

Will anyone complain if we drop local repos in Juju 2.0? Is there a use case
where it's absolutely required to retain this?






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

Re: Fwd: AWS Cross Account Roles

[John Meinel]

At the moment I don't believe we do. We just use your access key and secret
key to identify you to EC2 when we make requests. We don't support using
temporary credentials via Assume role
For those of us wanting to know more here is AWS page
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html

The big internal technical limitation is that AssumeRole based access needs
to be refreshed periodically (the temporary keys are good for at most 1
hour).

John
=:->
On Mar 3, 2016 10:46 PM, "Paul Eipper"  wrote:

> Hello,
>
> Does Juju work with AWS Cross Account Roles? Specifically, IAM users
> that need to set the "External ID" string to assume the role?
>
> AWS Cli support is enabled by configuring a profile:
>
> https://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html#cli-roles-xaccount
>
> and then specifying it on the command line:
> ```
> aws s3 ls --profile marketingadmin
> ```
>
> Is something like that supported in the Juju EC2 environment config?
>
> att,
> --
> Paul Eipper
>
> --
> 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: Issues with missing positional arguments....

[Cory Johns]

As long as the state is only set by the interface layer, the handler will
always get the relation instance passed in for that state, no matter what
Juju hook it's currently running.  As before, I don't see anything obvious
that would cause that error, so it will require some debugging.

On Thu, Mar 3, 2016 at 5:28 PM, Tom Barber  wrote:

> Evening all here's one that someone with more brains than me can answer:
>
> https://github.com/OSBI/layer-pdi/blob/master/reactive/pdi.py
>
> I'm having issues with this with the config-change and upgrade-charm hooks
>
> Both have a nasty habit of returning:
>
> 2016-03-03 22:25:44 INFO config-changed TypeError: check_running() missing
> 1 required positional argument: 'java'
> 2016-03-03 22:25:44 ERROR juju.worker.uniter.operation runhook.go:107 hook
> "config-changed" failed: exit status 1
>
> Me and Cory mulled it over without any great resolution last night, but
> can someone explain why check_runnnig baulks. Is it because the Java layer
> passes the java object but the config-changed and upgrade-hook don't and so
> I need to split them out? or is there a nicer solution?
>
> Thanks
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> --
> 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

Issues with missing positional arguments....

[Tom Barber]

Evening all here's one that someone with more brains than me can answer:

https://github.com/OSBI/layer-pdi/blob/master/reactive/pdi.py

I'm having issues with this with the config-change and upgrade-charm hooks

Both have a nasty habit of returning:

2016-03-03 22:25:44 INFO config-changed TypeError: check_running() missing
1 required positional argument: 'java'
2016-03-03 22:25:44 ERROR juju.worker.uniter.operation runhook.go:107 hook
"config-changed" failed: exit status 1

Me and Cory mulled it over without any great resolution last night, but can
someone explain why check_runnnig baulks. Is it because the Java layer
passes the java object but the config-changed and upgrade-hook don't and so
I need to split them out? or is there a nicer solution?

Thanks

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: admin is dead, long live $USER

[Tim Penhey]

Ah... it used to be there :-) At least it is on my feature branch, but I
don't think I have merged the most recent master updates that has the
work to re-work bootstrap for the new cloud credentials stuff.

Tim

On 04/03/16 10:09, Rick Harding wrote:
> If we do that we need to also make it configurable on bootstrap as an
> option.
> 
> +1 overall
> 
> 
> On Thu, Mar 3, 2016, 4:07 PM Tim Penhey  > wrote:
> 
> Hi folks,
> 
> I was thinking that with the upcoming big changes with 2.0, we should
> tackle a long held issue where we have the initial user called "admin".
> 
> There was a request some time back that we should use the current user's
> name. The reason it wasn't implemented at that time was due to logging
> into the GUI issues. These have been resolved some time back with the
> multiple user support that was added.
> 
> All the server side code handles the ability to define the initial user
> for the controller model, and we do this in all the tests, so the
> default test user is actually called "test-admin".
> 
> I *think* that all we need to do is change the default value we use in
> the bootstrap command for the AdminUserName (--admin-user flag) from
> "admin" to something we derive from the current user.
> 
> Probably worth doing now.
> 
> Thoughts?
> 
> Tim
> 
> --
> 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: admin is dead, long live $USER

[Rick Harding]

If we do that we need to also make it configurable on bootstrap as an
option.

+1 overall

On Thu, Mar 3, 2016, 4:07 PM Tim Penhey  wrote:

> Hi folks,
>
> I was thinking that with the upcoming big changes with 2.0, we should
> tackle a long held issue where we have the initial user called "admin".
>
> There was a request some time back that we should use the current user's
> name. The reason it wasn't implemented at that time was due to logging
> into the GUI issues. These have been resolved some time back with the
> multiple user support that was added.
>
> All the server side code handles the ability to define the initial user
> for the controller model, and we do this in all the tests, so the
> default test user is actually called "test-admin".
>
> I *think* that all we need to do is change the default value we use in
> the bootstrap command for the AdminUserName (--admin-user flag) from
> "admin" to something we derive from the current user.
>
> Probably worth doing now.
>
> Thoughts?
>
> Tim
>
> --
> 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

admin is dead, long live $USER

[Tim Penhey]

Hi folks,

I was thinking that with the upcoming big changes with 2.0, we should
tackle a long held issue where we have the initial user called "admin".

There was a request some time back that we should use the current user's
name. The reason it wasn't implemented at that time was due to logging
into the GUI issues. These have been resolved some time back with the
multiple user support that was added.

All the server side code handles the ability to define the initial user
for the controller model, and we do this in all the tests, so the
default test user is actually called "test-admin".

I *think* that all we need to do is change the default value we use in
the bootstrap command for the AdminUserName (--admin-user flag) from
"admin" to something we derive from the current user.

Probably worth doing now.

Thoughts?

Tim

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

charms.reactive 0.4.0 release

[Cory Johns]

A new version of charms.reactive (0.4.0) has been released
.  As it is backwards
compatible, it will automatically be updated whenever you rebuild a layered
charm.

It includes the following changes:

  * New @when_any

and @when_not_all

decorators
  * Fix for some files in interface layers being mistakenly treated as
reactive handlers

The @when_any decorator works particularly well with the
config.changed.{varname}
 and
leadership.changed.{varname}
 states
provided by the base and leadership layers, respectively.  Note that, like
@when_none, it never passes in an argument.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Fwd: AWS Cross Account Roles

[Paul Eipper]

Hello,

Does Juju work with AWS Cross Account Roles? Specifically, IAM users
that need to set the "External ID" string to assume the role?

AWS Cli support is enabled by configuring a profile:
https://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html#cli-roles-xaccount

and then specifying it on the command line:
```
aws s3 ls --profile marketingadmin
```

Is something like that supported in the Juju EC2 environment config?

att,
--
Paul Eipper

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

Re: Neo4J Charm

[Rick Harding]

Hi Merlijn, that was Steven Baker

The charm looks like it's in his github repo here:
https://github.com/srbaker/neo4j-charm

I don't know what state it's in, but I'm sure it'll be fun to try out.

On Thu, Mar 3, 2016 at 9:26 AM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi all
>
>
> During the summit I saw some guys working on a Neo4J Charm. What's the
> update on that? Is there a beta version somewhere? We'd like to try it out..
>
>
>
> Kind regards
> Merlijn Sebrechts
> --
> 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: Correction: Juju Office Hours, 4 March, 1500UTC

[Jorge O. Castro]

A quick correction everyone, we're going to start alternating the time
slots of the Office Hours. It's tough to get both the West Coast and
Europe in one go so we'll be alternating timeslots. Here are the
corrected hours for tomorrow:

Date: Friday, 4 March
Time: 1500 (3pm) UTC, 1000 (10am) EST, 0700(7am) PST
Where: ubuntuonair.com for the stream
Participate: #juju on freenode

https://insights.ubuntu.com/event/juju-office-hours-for-march-2016/

And from now on we'll just be listing them on the events page:
https://insights.ubuntu.com/category/events


-- 
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

Neo4J Charm

[Merlijn Sebrechts]

Hi all


During the summit I saw some guys working on a Neo4J Charm. What's the
update on that? Is there a beta version somewhere? We'd like to try it out..



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

jujucharms.com updated

[Brad Crittenden]

Hello,

Yesterday the Juju UI Engineering team updated jujucharms.com with some 
improvements we hope you find interesting and useful.  The highlights are:

* Improved getting started page (https://jujucharms.com/get-started)

The Juju installation instructions have been re-written to be more 
straightforward and the page is more welcoming.

* Community cards (https://jujucharms.com/community/cards)

In order to allow charm and bundle authors an engaging way to promote their 
work, we’ve introduced cards, a slug of Javascript and HTML that can be 
embedded into a web site which will then serve a visual representation of the 
charm or bundle. The details are fetched from our servers so the data will 
always be up-to-date.  Change your bundle and the representation of it on your 
blog will be updated for future visitors.

Madison has written a blog post demonstrating their use at 
http://writing.drab-makyo.com/posts/tech/2016/03/02/cards/

Note that this first implementation is Javascript-based and therefore will not 
work in every environment, specifically platforms that block the use of 
embedded Javascript.

* Improved topic pages (e.g. https://jujucharms.com/big-data)

A cleaner design utilizing the cards for each bundle presented.

* Charm labeling on bundle visualisations.

Previously the rendered image for a bundle only showed the service icons which 
could be confusing as there was no way to intuit the role each service played. 
Now we are labeling each service with the custom name so you can easily 
identify master/slave relationships, for example.

If you have questions or comments on these changes, you can find us in 
#juju-gui on Freenode or respond here.

If you find a bug please file it at 
https://github.com/CanonicalLtd/jujucharms.com/issues

Best,

Brad Crittenden
Juju UI Engineering


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju