Re: Anyone working on HTTP/2 in apache2 charm?

[Andreas Hasenack]

On Wed, Aug 16, 2017 at 1:21 PM, Robin Winslow  wrote:

> Hi Robie
>
> I only noticed yesterday that HTTP/2 support graduated from experimental
> mode to "fully production ready" in Apache2 v2.4.26
> , released June 13th.
>
> Is there a likely timeline for building HTTP/2 support into the version of
> Apache2 provided with Xenial (currently at 2.4.18)?
>

https://bugs.launchpad.net/ubuntu/+source/nghttp2/+bug/1687454 is the MIR
bug to bring the nghttp2 library into main, and then apache can builddepend
on it.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju status stucking

[Andreas Hasenack]

On Sat, Aug 27, 2016 at 1:57 PM, Junaid Ali  wrote:

> Hi everyone,
>
> I'm having an issue on juju status command. It stucks when I run the
> command for a service e.g
>
> juju status nova-cloud-controller
>
> although
> $ juju status
>  and
> $ juju status --format tabular
> works fine.
>
> Version of juju that I'm using is 1.25.6. Let me know please if any
> workaround available for this issue or what logs to share if this is a bug.
>
>
Is your deployment on lxc/lxd? Then it might be this bug I filed some time
ago:

https://bugs.launchpad.net/juju-core/+bug/1462423
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Hung up post 2.0 upgrade? juju-unregister to the rescue!

[Andreas Hasenack]

On Mon, Aug 8, 2016 at 9:50 AM, Charles Butler  wrote:

> Greetings!
>
> I was in #juju riffing with some juju users, and it became apparent that
> there is a not-so-well-known feature of juju in the 2.0+ series.
>
> As 2.0 is not marked as stable, every new release is treated like an
> island. Sometimes it may be compatible with what you have deployed (eg
> beta-12 to beta-13) and won't require a re-bootstrap, everything will
> *appear* to just work. Sometimes the risk and failure is much more apparent
> than this, such as the beta-13 to beta-14 update.
>
> Traditionally you would terminate the instances via your cloud provider
> and be left with some configuration left around in your $JUJU_DATA
> directory. Less than ideal right?
>
> juju unregister to the rescue!
>
> Details:
> Removes local connection information for the specified controller.
> This command does not destroy the controller.  In order to regain
> access to an unregistered controller, it will need to be added
> again using the juju register command.
>
> I thought I would share this great discovery with others that are being
> intrepid and helping us test 2.0
>

There is this bug to make "juju unregister" a bit more prominent:

https://bugs.launchpad.net/juju-core/+bug/1607303
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju2: format of clouds.yaml for juju add-cloud

[Andreas Hasenack]

On Tue, May 3, 2016 at 10:40 AM, Ian Booth  wrote:

>
>
> On 03/05/16 23:16, Andreas Hasenack wrote:
> > Looks like juju 2b6 also doesn't know what it is:
> > $ juju-2.0 bootstrap cistack-controller cistack
> > WARNING unknown config field "domain-name"
> > ERROR authentication failed.
> > (...)
> >
>
> That WARNING above is unfortunately misleading in this case. The provider's
> config parsing needs to be updated to understand that domain-name is a new
> optional field (the field is still processed despite the warning).
>
> But it doesn't indicate the cause of the failure. Perhaps only keystone 2
> is
> supported by the openstack cloud in use. The error message would be better
> if it
> indicated the cause of failure.
>

I got the cause of the failure after using --debug:
2016-05-03 13:27:03 DEBUG juju.provider.openstack provider.go:724 authURL:
http://10.96.5.21:5000/v2.0
2016-05-03 13:27:03 DEBUG juju.provider.openstack provider.go:685
authentication failed: authentication failed
caused by: requesting token: Resource at
http://10.96.5.21:5000/v2.0/auth/tokens not found

Since I had specified domain-name when adding the credential, it was trying
to use keystone v3 authentication on a v2 url.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju2: format of clouds.yaml for juju add-cloud

[Andreas Hasenack]

On Tue, May 3, 2016 at 10:28 AM, Ian Booth  wrote:

>
> The syaml referred to above is for cloud definitions. The command being
> run is
> for adding a credential. The credential data model is different to clouds.
> The
> type of cloud though (eg openstack vs aws vs google) determine what
> credential
> attributes are valid. "domain-name" is used for keystone v3
> authentication. It
> is optional and not needed for keystone v2. Whether to enter it or not
> depends
> entirely on your openstack setup.
>
>
Thanks.

Suggestion: since I'm adding a credential for a cloud that is already
defined, maybe juju shouldn't ask me for "domain-name" if the endpoint url
is for keystone 2.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju2: format of clouds.yaml for juju add-cloud

[Andreas Hasenack]

On Tue, May 3, 2016 at 10:09 AM, Andreas Hasenack 
wrote:

> On Wed, Apr 20, 2016 at 7:07 PM, Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> On Thu, Apr 21, 2016 at 2:44 AM Andreas Hasenack 
>> wrote:
>>
>>> Hi,
>>>
>>> I was trying to add another "cloud" so that I could have multiple MAAS
>>> servers available to bootstrap on, without having to type the MAAS IP
>>> everytime in the bootstrap command line, and pass --credential.
>>>
>>> Some reading lead me to juju add-cloud, but the documentation only has
>>> examples for openstack clouds, like:
>>>
>>> clouds:
>>>   :
>>> type: 
>>> regions:
>>>   :
>>> endpoint: <https://xxx.yyy.zzz:35574/v3.0/>
>>> auth-types: <[access-key, oauth, userpass]>
>>>
>>>
>>> That does not translate immediately to a MAAS configuration. I asked for
>>> help on IRC and mgz provided me with this syntax:
>>>
>>> clouds:
>>>   some-name:
>>> type: maas
>>> auth-types: [oauth1]
>>> endpoint: 'http:///MAAS/'
>>>
>>>
>>> Are there other options that could be used here, specific to the "maas"
>>> type? What about other cloud types, what changes in this template?
>>>
>>
>> Everything that you can use is used here:
>> http://streams.canonical.com/juju/public-clouds.syaml. So the things in
>> there of note are "storage-endpoint" and "regions".
>>
>>
>
> What's "domain-name"?
> andreas@nsn7:~$ juju add-credential cistack
>   credential name: cistack
>   auth-type: userpass
>   username: andreas
>   password:
>   tenant-name: andreas
>   domain-name: ?
> credentials added for cloud cistack
>
> It's not used in http://streams.canonical.com/juju/public-clouds.syaml,
> nor is it documented in
> https://jujucharms.com/docs/devel/clouds#specifying-additional-clouds. I
> can take a guess (DNS domain name), but I don't know where and how it's
> used. juju1 didn't have that, and nor does the novarc file given to me by
> horizon.
>
>

Looks like juju 2b6 also doesn't know what it is:
$ juju-2.0 bootstrap cistack-controller cistack
WARNING unknown config field "domain-name"
ERROR authentication failed.
(...)


I'll file a bug.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju2: format of clouds.yaml for juju add-cloud

[Andreas Hasenack]

On Wed, Apr 20, 2016 at 7:07 PM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> On Thu, Apr 21, 2016 at 2:44 AM Andreas Hasenack 
> wrote:
>
>> Hi,
>>
>> I was trying to add another "cloud" so that I could have multiple MAAS
>> servers available to bootstrap on, without having to type the MAAS IP
>> everytime in the bootstrap command line, and pass --credential.
>>
>> Some reading lead me to juju add-cloud, but the documentation only has
>> examples for openstack clouds, like:
>>
>> clouds:
>>   :
>> type: 
>> regions:
>>   :
>> endpoint: <https://xxx.yyy.zzz:35574/v3.0/>
>> auth-types: <[access-key, oauth, userpass]>
>>
>>
>> That does not translate immediately to a MAAS configuration. I asked for
>> help on IRC and mgz provided me with this syntax:
>>
>> clouds:
>>   some-name:
>> type: maas
>> auth-types: [oauth1]
>> endpoint: 'http:///MAAS/'
>>
>>
>> Are there other options that could be used here, specific to the "maas"
>> type? What about other cloud types, what changes in this template?
>>
>
> Everything that you can use is used here:
> http://streams.canonical.com/juju/public-clouds.syaml. So the things in
> there of note are "storage-endpoint" and "regions".
>
>

What's "domain-name"?
andreas@nsn7:~$ juju add-credential cistack
  credential name: cistack
  auth-type: userpass
  username: andreas
  password:
  tenant-name: andreas
  domain-name: ?
credentials added for cloud cistack

It's not used in http://streams.canonical.com/juju/public-clouds.syaml, nor
is it documented in
https://jujucharms.com/docs/devel/clouds#specifying-additional-clouds. I
can take a guess (DNS domain name), but I don't know where and how it's
used. juju1 didn't have that, and nor does the novarc file given to me by
horizon.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

juju2: where to specify http proxy

[Andreas Hasenack]

Hi,

I'm trying to find out where do I specify a http proxy for clouds,
specifically MAAS.

https://jujucharms.com/docs/devel/clouds-maas has no mention of a proxy
variable. A search for "http-proxy" returns outdated references to the
environments.yaml file or juju set-env, even though I have selected "devel"
docs.

Going by trial and error, I added the setting to my clouds file yaml, like
this:
clouds:
vmwarestack:
type: maas
auth-types: [oauth1]
endpoint: 'http://10.245.200.27/MAAS/'
http-proxy: http://10.245.200.27:8000/
https-proxy: http://10.245.200.27:8000/
no-proxy: localhost,127.0.0.1,10.245.200.27,10.245.202.1


Then I added it with juju add-cloud. No errors were shown. and list-clouds
confirms the cloud is there. But show-cloud doesn't list the proxy settings
:/
$ juju show-cloud local:vmwarestack
defined: local
type: maas
auth-types: [oauth1]
endpoint: http://10.245.200.27/MAAS/


Upon bootstrapping, it hangs at the curl stage:
$ juju bootstrap vmwarestack-controller vmwarestack --config
bootstrap-timeout=1800
Creating Juju controller "local.vmwarestack-controller" on vmwarestack
Bootstrapping model "admin"
(...)
Warning: Permanently added '10.245.202.67' (ECDSA) to the list of known
hosts.
Logging to /var/log/cloud-init-output.log on remote host
Running apt-get update
Running apt-get upgrade
Installing package: curl
Installing package: cpu-checker
Installing package: bridge-utils
Installing package: cloud-utils
Installing package: cloud-image-utils
Installing package: tmux
Fetching tools: curl -sSfw 'tools from %{url_effective} downloaded: HTTP
%{http_code}; time %{time_total}s; size %{size_download} bytes; speed
%{speed_download} bytes/s ' --retry 10 -o $bin/tools.tar.gz <[
https://streams.canonical.com/juju/tools/agent/2.0-beta6/juju-2.0-beta6-xenial-amd64.tgz
]>


Logging in on the node shows that curl it stuck:

 1369 ?Ss 0:00 /usr/sbin/sshd -D
 2737 ?Ss 0:00  \_ sshd: ubuntu [priv]
 2776 ?S  0:00  |   \_ sshd: ubuntu@notty
 2777 ?Ss 0:00  |   \_ sudo /bin/bash -c /bin/bash -c  set
-e tmpfile=$(mktemp) trap "rm -f $tmpfile" EXIT cat > $tmpfile /bin/bash
$tmpfile
 2781 ?S  0:00  |   \_ /bin/bash
 2782 ?S  0:00  |   \_ /bin/bash
 3716 ?S  0:00  |   \_ curl -sSfw tools from
%{url_effective} downloaded: HTTP %{http_code}; time %{time_total}s; size
%{size_download} bytes

And netstat confirms that it is not using the proxy:
tcp0  1 10.245.202.67:49654 91.189.88.141:443
SYN_SENT3716/curl

/etc/apt/apt.conf.d/95cloud-init-proxy has the proxy defined, but that I
think comes from the maas server, which has this same proxy setting:
cat /etc/apt/apt.conf.d/95cloud-init-proxy
Acquire::HTTP::Proxy "http://10.245.200.27:8000/";;

Explains why apt worked, at least. But curl needs a system-wide proxy
setting.

/home/ubuntu has no file, hidden or otherwise, specifying the proxy, like
there used to be with juju1.

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

Re: juju2: how to edit a maas "cloud"?

[Andreas Hasenack]

On Wed, Apr 27, 2016 at 1:04 PM, John Meinel  wrote:

>
>
> On Wed, Apr 27, 2016 at 6:43 PM, Andreas Hasenack 
> wrote:
>
>> On Wed, Apr 27, 2016 at 10:59 AM, John Meinel 
>> wrote:
>>
>>> ...
>>>
>>>
>>>>
>>>>> As noted, the number of times you have to bootstrap should be going
>>>>> down, and if you are bootstrapping different-but-similar, then you again
>>>>> have a single config that can be reused.
>>>>>
>>>>
>>>> I'd love to be able to share a controller node with my colleagues. I
>>>> tried setting that up and creating a juju user, but in the end that user's
>>>> MAAS nodes were all allocated to "me" in MAAS, which was a bit unexpected.
>>>> The person running juju commands had his own MAAS credentials setup. Until
>>>> that is not setup, I can't keep a MAAS node allocated to my user 24/7, it's
>>>> an expensive resource. I need to play with this shared controller idea a
>>>> bit more.
>>>>
>>>>
>>>>
>>> Were they using the same model or had they created their own model to
>>> work in? It may be that you had given them Admin rights on the controller,
>>> which meant that "juju add-model" then uses the admin credentials by
>>> default. I've heard that users that aren't admin but can create models are
>>> being prompted for what credentials should be used for this model.
>>>
>>
>> They were not admins. This is what I did, from memory:
>> - bootstrapped on MAAS
>> - created a model for user foo
>> - created user foo, with --share for that model
>> - granted user foo write access acl to model foo
>> - sent the register line to the user
>>
>> That user already had a cloud for this MAAS server, with credentials. He
>> ran the register command, then deployed services. The MAAS nodes that got
>> these services were under my name, not his.
>>
>>
>
> Unfortunately, for the 2.0 series the credentials used to manage machines
> are tied to the model. He'll need to create a different model (juju
> add-model --credentials XXX) to create machines with different credentials.
> The problem is that generally visibility between machines/security
> groups/etc is not guaranteed between
>

Can he add another model without having to be an admin in the controller?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju2: how to edit a maas "cloud"?

[Andreas Hasenack]

On Wed, Apr 27, 2016 at 10:59 AM, John Meinel 
wrote:

> ...
>
>
>>
>>> As noted, the number of times you have to bootstrap should be going
>>> down, and if you are bootstrapping different-but-similar, then you again
>>> have a single config that can be reused.
>>>
>>
>> I'd love to be able to share a controller node with my colleagues. I
>> tried setting that up and creating a juju user, but in the end that user's
>> MAAS nodes were all allocated to "me" in MAAS, which was a bit unexpected.
>> The person running juju commands had his own MAAS credentials setup. Until
>> that is not setup, I can't keep a MAAS node allocated to my user 24/7, it's
>> an expensive resource. I need to play with this shared controller idea a
>> bit more.
>>
>>
>>
> Were they using the same model or had they created their own model to work
> in? It may be that you had given them Admin rights on the controller, which
> meant that "juju add-model" then uses the admin credentials by default.
> I've heard that users that aren't admin but can create models are being
> prompted for what credentials should be used for this model.
>

They were not admins. This is what I did, from memory:
- bootstrapped on MAAS
- created a model for user foo
- created user foo, with --share for that model
- granted user foo write access acl to model foo
- sent the register line to the user

That user already had a cloud for this MAAS server, with credentials. He
ran the register command, then deployed services. The MAAS nodes that got
these services were under my name, not his.


>
> So even if they are Admin, we do have:
>   juju create-model --credential BLAH
>
> Which he can use to override the default credentials so that machines he
> provisions show up under his account. I do believe that this is a recent
> introduction in 2.0-beta. I do believe that we are currently modeling that
> all machines in a given model are provisioned with the same credentials. We
> may come back to this, but AIUI that is the plan for 2.0-final.
>
>
Cool. I'm on beta6 now, was on beta5 or earlier when I tried the above.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju2: how to edit a maas "cloud"?

[Andreas Hasenack]

On Wed, Apr 27, 2016 at 9:55 AM, John Meinel  wrote:

>
>
> On Tue, Apr 26, 2016 at 10:41 PM, Andreas Hasenack 
> wrote:
>
>> On Tue, Apr 26, 2016 at 3:11 PM, John Meinel 
>> wrote:
>>
>>> I believe --config can take a file rather than just a 'key=value'
>>> pairing. So you can save all your config to a file and pass it in with
>>> '--config myconf.yaml'
>>>
>>> There was discussion of having a default search path for some of the
>>> config, but I'm not sure if that got implemented, nor if it is actually
>>> better since it is another magic place that you have to discover.
>>>
>>>
>> This is the experience with juju 1:
>> juju switch scapestack
>> juju bootstrap
>>
>> This is the same experience with juju 2:
>> juju bootstrap scapestack-controller scapestack --config
>> ~/juju2-configs/scapestack.yaml
>>
>>
> But where did the settings for scapestack get set up in the first place.
> You're missing some of the original "edit ~/.juju/environment.yaml" to
> insert the right information.
>
>
The scenario is starting from an already configured cloud in both juju1 and
juju2, and my use case is MAAS, not public clouds. Except in juju2 I have
to specify the configuration file everytime. If starting from scratch, the
juju2 way requires even more steps.


> If you are sharing information with someone else, being able to give them
> the file with all of the configuration becomes quite a bit easier, as you
> gave them the file, they saved it somewhere they know about, and then they
> pass that in to the bootstrap command. Rather than giving a snippet, that
> needs to be inserted into an existing file in the right place, and then it
> magically works if you named everything correctly.
>

This configuration file you mention is far from complete. It's 1/3 of the
details, as it does not have, for example, the cloud endpoint, nor the
credentials. Just bootstrap-timeout, in my case.


>
> So while for people that have everything set up already, there is a bit
> more to write, for people coming to the system I think it is quite a bit
> more obvious for them.
>

I think it's less obvious. At least it was less obvious to me, maybe
because of my juju1 experience. And changing is fine: just wanted to share
what my experience with this new process was.

It's my understanding that there are 3 elements that you have to configure
in juju2, separately, when you start from scratch: cloud definition,
credential information and remaining configuration. In juju1 all 3 are in
the same environments.yaml section. All under the "environment" (now model)
name.

You go from this one snippet (environments.yaml) to 3 files and 2 commands.
In juju2 you have to create a cloud file for MAAS, then create a
credentials file for that MAAS. Then import both (two commands), which
links the credentials to the "maas cloud". Then create a config file for
things that cannot be specified in the cloud definition file (like
bootstrap-timeout, crucial for the MAAS provider), and specify that
everytime you bootstrap.


> As noted, the number of times you have to bootstrap should be going down,
> and if you are bootstrapping different-but-similar, then you again have a
> single config that can be reused.
>

I'd love to be able to share a controller node with my colleagues. I tried
setting that up and creating a juju user, but in the end that user's MAAS
nodes were all allocated to "me" in MAAS, which was a bit unexpected. The
person running juju commands had his own MAAS credentials setup. Until that
is not setup, I can't keep a MAAS node allocated to my user 24/7, it's an
expensive resource. I need to play with this shared controller idea a bit
more.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju2: how to edit a maas "cloud"?

[Andreas Hasenack]

On Tue, Apr 26, 2016 at 3:11 PM, John Meinel  wrote:

> I believe --config can take a file rather than just a 'key=value' pairing.
> So you can save all your config to a file and pass it in with '--config
> myconf.yaml'
>
> There was discussion of having a default search path for some of the
> config, but I'm not sure if that got implemented, nor if it is actually
> better since it is another magic place that you have to discover.
>
>
This is the experience with juju 1:
juju switch scapestack
juju bootstrap

This is the same experience with juju 2:
juju bootstrap scapestack-controller scapestack --config
~/juju2-configs/scapestack.yaml
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju2: how to edit a maas "cloud"?

[Andreas Hasenack]

Forgot to include the list
On Apr 25, 2016 12:55, "Andreas Hasenack"  wrote:

> Uh, so in essence there are now three "files"? Cloud definition, config
> for that cloud and credentials? And the config has to be passed each time,
> whereas the other two are " imported"?
> On Apr 25, 2016 12:44, "Cheryl Jennings" 
> wrote:
>
>> Hi Andreas,
>>
>> The config is now separate from the cloud definition and can be passed in
>> when bootstrapping using --config:
>>
>> juju bootstrap scapestack scapestack --config bootstrap-timeout=1800
>>
>> You can also pass in a yaml file with config options if you don't want to
>> type them all out on the command line:
>>
>> $ cat scapestack-config.yaml
>> default-series: "trusty"
>> logging-config: "=DEBUG"
>> bootstrap-timeout: 1800
>>
>> $ juju bootstrap scapestack scapestack --config=scapestack-config.yaml
>>
>> Thanks!
>> -Cheryl
>>
>> On Mon, Apr 25, 2016 at 10:26 AM, Andreas Hasenack > > wrote:
>>
>>> On Mon, Apr 25, 2016 at 12:10 PM, Andreas Hasenack <
>>> andr...@canonical.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I added a couple of maas servers to my cloud list:
>>>> $ juju list-clouds
>>>> CLOUD TYPEREGIONS
>>>> aws   ec2 us-east-1, us-west-1, us-west-2,
>>>> eu-west-1, eu-central-1, ap-southeast-1, ap-southeast-2 ...
>>>> ...
>>>> local:beretstack  maas
>>>> local:scapestack  maas
>>>>
>>>> I now want to add a bootstrap-timeout parameter to each.
>>>>
>>>> How do I do that? Do I need to recreate the yaml definition for each
>>>> maas "cloud", add the parameter, and add-cloud --replace it?
>>>>
>>>
>>>
>>> That didn't work, btw:
>>>
>>> andreas@nsn7:~$ cat foo
>>> clouds:
>>> scapestack:
>>> type: maas
>>> auth-types: [oauth1]
>>> endpoint: http://10.96.0.10/MAAS/
>>> bootstrap-timeout: 1800
>>>
>>> andreas@nsn7:~$ juju add-cloud --replace scapestack foo
>>>
>>> andreas@nsn7:~$ juju show-cloud local:scapestack
>>> defined: local
>>> type: maas
>>> auth-types: [oauth1]
>>> endpoint: http://10.96.0.10/MAAS/
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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: juju2: how to edit a maas "cloud"?

[Andreas Hasenack]

On Mon, Apr 25, 2016 at 12:10 PM, Andreas Hasenack 
wrote:

> Hi,
>
> I added a couple of maas servers to my cloud list:
> $ juju list-clouds
> CLOUD TYPEREGIONS
> aws   ec2 us-east-1, us-west-1, us-west-2, eu-west-1,
> eu-central-1, ap-southeast-1, ap-southeast-2 ...
> ...
> local:beretstack  maas
> local:scapestack  maas
>
> I now want to add a bootstrap-timeout parameter to each.
>
> How do I do that? Do I need to recreate the yaml definition for each maas
> "cloud", add the parameter, and add-cloud --replace it?
>


That didn't work, btw:

andreas@nsn7:~$ cat foo
clouds:
scapestack:
type: maas
auth-types: [oauth1]
endpoint: http://10.96.0.10/MAAS/
bootstrap-timeout: 1800

andreas@nsn7:~$ juju add-cloud --replace scapestack foo

andreas@nsn7:~$ juju show-cloud local:scapestack
defined: local
type: maas
auth-types: [oauth1]
endpoint: http://10.96.0.10/MAAS/
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

juju2: how to edit a maas "cloud"?

[Andreas Hasenack]

Hi,

I added a couple of maas servers to my cloud list:
$ juju list-clouds
CLOUD TYPEREGIONS
aws   ec2 us-east-1, us-west-1, us-west-2, eu-west-1,
eu-central-1, ap-southeast-1, ap-southeast-2 ...
...
local:beretstack  maas
local:scapestack  maas

I now want to add a bootstrap-timeout parameter to each.

How do I do that? Do I need to recreate the yaml definition for each maas
"cloud", add the parameter, and add-cloud --replace it?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

juju2: format of clouds.yaml for juju add-cloud

[Andreas Hasenack]

Hi,

I was trying to add another "cloud" so that I could have multiple MAAS
servers available to bootstrap on, without having to type the MAAS IP
everytime in the bootstrap command line, and pass --credential.

Some reading lead me to juju add-cloud, but the documentation only has
examples for openstack clouds, like:

clouds:
  :
type: 
regions:
  :
endpoint: 
auth-types: <[access-key, oauth, userpass]>


That does not translate immediately to a MAAS configuration. I asked for
help on IRC and mgz provided me with this syntax:

clouds:
  some-name:
type: maas
auth-types: [oauth1]
endpoint: 'http:///MAAS/'


Are there other options that could be used here, specific to the "maas"
type? What about other cloud types, what changes in this template?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju devel 2.0-beta1 is available for testing

[Andreas Hasenack]

On Sun, Feb 21, 2016 at 11:35 AM, Rick Harding 
wrote:

> Andreas, yes that's the known bug Ian mentioned  due to an API change in
> the latest lxd beta3. We'll get that updated ASAP. It works with the lxd
> beta2.
>
>
Thanks

Is beta2 archived somewhere? All of lxd git-master and stable ppas, and
current ubuntu xenial, have beta3, and the PPAs don't have xenial builds.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju devel 2.0-beta1 is available for testing

[Andreas Hasenack]

On Sat, Feb 20, 2016 at 9:18 PM, Ian Booth  wrote:

> The lxd cloud works on Juju 2.0 beta1 out of the box.
>
> $ juju bootstrap mycontroller lxd
>
> There is no need to edit any clouds.yaml. It Just Works.
>

It does not work for me:
andreas@duo:~$ juju bootstrap mycontroller lxd
Creating Juju controller "mycontroller" on lxd/localhost
Bootstrapping model "mycontroller"
Starting new instance for initial controller
Launching instance
ERROR failed to bootstrap model: cannot start bootstrap instance: can't get
info for image 'ubuntu-trusty': json: cannot unmarshal string into Go value
of type int64

andreas@duo:~$ lxc image list
+---+--++--+--+--+--+
| ALIAS | FINGERPRINT  | PUBLIC |
DESCRIPTION  | ARCH |   SIZE   | UPLOAD DATE  |
+---+--++--+--+--+--+
| ubuntu-trusty | 78eb2260318d | no | Ubuntu 14.04 LTS server
(20160217.1) | i686 | 116.26MB | Feb 20, 2016 at 6:59pm (UTC) |
| ubuntu-xenial | a8f417c4bb95 | no | Ubuntu 16.04 LTS server
(20160125)   | i686 | 144.62MB | Feb 20, 2016 at 6:54pm (UTC) |
+---+--++--+--+--+--+

https://bugs.launchpad.net/juju-core/+bug/1547268
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju 2.0-alpha2 with lxd

[Andreas Hasenack]

I had the same issue. I then remembered the tools and bootstrapped with
--upload-tools and then it worked. Might have worked had I set the agent
stream to devel too, but I didn't you that yet.
On Feb 14, 2016 22:01, "Daniel Bidwell"  wrote:

> I am running 15.10 wiley with lxd version 0.20.
>
> Ooops. It looks like golang wasn't installed.  Getting it and trying
> again.  Thanks.
>
> On Sun, 2016-02-14 at 23:55 +, Marco Ceppi wrote:
> > What version of Ubuntu are you using? If it's anything other than
> > Xenial or Wily the LXD provider won't work. LXD bindings require a
> > golang version that's too new for Trusty.
> >
> > On Sun, Feb 14, 2016 at 6:14 PM Daniel Bidwell 
> > wrote:
> > > I am trying to bootstrap lxd.
> > >
> > > I started with 'juju init' and then 'juju -v --debug bootstrap -m
> > > lxd'
> > > It allocated a container and deployed to it and ended with the
> > > following lines of debug output:
> > >
> > > 2016-02-14 23:04:46 INFO juju.cmd supercommand.go:59 running jujud
> > > [2.0
> > > -alpha2 gc go1.2.1]
> > > 2016-02-14 23:04:46 DEBUG juju.agent agent.go:506 read agent
> > > config,
> > > format "1.18"
> > > 2016-02-14 23:04:46 INFO juju.network network.go:248 setting prefer
> > > -ipv6 to false
> > > 2016-02-14 23:04:46 ERROR cmd supercommand.go:448 no registered
> > > provider for "lxd"
> > > 2016-02-14 23:04:46 ERROR cmd supercommand.go:448 failed to
> > > bootstrap
> > > model: subprocess encountered error code 1
> > >
> > > What do I have to do to "register the lxd provider"?  Is this done
> > > before the boostrap command, during, or after?
> > >
> > > A 'juju status' command hangs for ever.  Another 'juju bootstrap'
> > > command starts out happy, but then tells me that lxd is already
> > > deployed.  I can 'ssh ubuntu@10.0.3.x' and get into the container
> > > just
> > > fine, but not 'juju ssh 0'.
> > >
> > > What am I missing?
> > > --
> > > Daniel Bidwell 
> > >
> > >
> > > --
> > > Juju-dev mailing list
> > > juju-...@lists.ubuntu.com
> > > Modify settings or unsubscribe at:
> > > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> > >
> --
> Daniel Bidwell 
>
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Deprecating charm config options: postgresql case

[Andreas Hasenack]

On Thu, Jan 14, 2016 at 9:03 PM, Stuart Bishop 
wrote:

> On 15 January 2016 at 02:00, Andreas Hasenack 
> wrote:
>
> >   max_connections:
> > default: 100
> > type: int
> > description: >
> > DEPRECATED. Use extra_pg_conf.
> > Maximum number of connections to allow to the PG database
> >
> > The option still exists and can be set, but does nothing. The service
> will
> > get whatever is set in the new extra_pg_conf option, which happens to be
> > 100.
>
> That would be a bug. It is supposed to still work, with warnings in
> your logs that you are using deprecated options.
>
> Thanks, I filed a bug about this:

 https://bugs.launchpad.net/charms/+source/postgresql/+bug/1534567

Turns out it was only max_connections that didn't work.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Deprecating charm config options: postgresql case

[Andreas Hasenack]

TL;DR
Should charms a) remove deprecated options; b) accept them but do nothing
(the case below); c) accept them for a while, log a warning, then remove;
d) ?

Hi,

Recently the postgresql charm deprecated several config options. For
example:

  max_connections:
default: 100
type: int
description: >
DEPRECATED. Use extra_pg_conf.
Maximum number of connections to allow to the PG database

The option still exists and can be set, but does nothing. The service will
get whatever is set in the new extra_pg_conf option, which happens to be
100.

I believe the intent of this behaviour was to not break the deployment of
the charm using existing configuration files. But instead it introduces a
subtle breakage: my DB can now only handle 100 connections, whereas before
it was (in my case) 500. The deployment works, but the system doesn't
behave as before and eventually breaks under use. That lead to some
debugging until this was found:

psycopg2.OperationalError: FATAL:  remaining connection slots are reserved
for non-replication superuser connections

Other deprecated options have a more explicit warning:

  performance_tuning:
default: "Mixed"
type: string
description: >
DEPRECATED AND IGNORED. The pgtune project has been abandoned
and the packages dropped from Debian and Ubuntu. The charm
still performs some basic tuning, which users can tweak using
extra_pg_config.

In this specific postgresql case, looks like all (I just tested two, btw)
deprecated options should have been marked with the extra "... AND IGNORED"
text. But then again, is it worth it to silently accept them and do
nothing, thereby introducing subtle run-time failures?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Call for Feedback: LXD local provider

[Andreas Hasenack]

On Sat, Jan 9, 2016 at 8:36 PM, Andreas Hasenack 
wrote:

> On Thu, Jan 7, 2016 at 3:48 PM, Jorge O. Castro  wrote:
>
>> Hi everyone,
>>
>> Katherine walked me through using the new LXD provider in the Juju
>> Alpha: https://linuxcontainers.org/lxd/
>>
>>
> Is this known not to work on i386 (32 bits)?
>
> I can bootstrap, but not launch new units.
>

Scratch that, it worked on the second attempt. Must be what somebody else
in the thread said about it failing sometimes.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Call for Feedback: LXD local provider

[Andreas Hasenack]

On Thu, Jan 7, 2016 at 3:48 PM, Jorge O. Castro  wrote:

> Hi everyone,
>
> Katherine walked me through using the new LXD provider in the Juju
> Alpha: https://linuxcontainers.org/lxd/
>
>
Is this known not to work on i386 (32 bits)?

I can bootstrap, but not launch new units.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Review Queue] postgresql

[Andreas Hasenack]

On Wed, Nov 11, 2015 at 8:17 PM, Antonio Rosales <
antonio.rosa...@canonical.com> wrote:

> On Wed, Nov 11, 2015 at 2:31 PM, Matt Bruzek
>  wrote:
> > I reviewed the rewrite of the postgresql charm today.  It is finally
> passing
> > tests in the automated test runner but I also ran bundletester on a local
> > KVM provider where it too a REALLY long time but all 12 tests passed!
> >
> > +1 LGTM so I merged it today.
> >
> > You can read more about the proposal here:
> >
> https://code.launchpad.net/~stub/charms/trusty/postgresql/rewrite/+merge/267646
> >
> > A big thank you to Stuart Bishop and Tim for all the cycles with our
> team to
> > get the postgresql tests to run in automation!
>
> Great to see the tests passing!
>
>
Be careful, somehow this landed in the precise postgresql charm and broke
the precise deployment, because python3 is not there by default:
2015-11-11 21:07:30 ERROR juju.worker.uniter.operation runhook.go:107 hook
"install" failed: fork/exec
/var/lib/juju/agents/unit-postgresql-0/charm/hooks/install: no such
 file or directory
2015-11-11 21:07:30 DEBUG juju.worker.uniter modes.go:31 [AGENT-STATUS]
failed: run install hook

# head -n 1 /var/lib/juju/agents/unit-postgresql-0/charm/hooks/install
#!/usr/bin/python3
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Which JUJU_DEV_FEATURE_FLAG were used?

[Andreas Hasenack]

On Tue, Sep 22, 2015 at 4:57 PM, Tim Penhey 
wrote:

> On 23/09/15 05:18, Andreas Hasenack wrote:
> > Hi,
> >
> > given an existing juju environment, is there a way to tell which
> > JUJU_DEV_FEATURE_FLAGs were used to bootstrap it?
> >
> > I'm using 1.24.6
>
> The second line of logging in every agent lists the feature flags that
> the agent is using.
>
> As the agent starts it logs first the version of juju, then the feature
> flags.
>
>

Got it there too, thanks:
machine-0: 2015-09-22 19:36:19 INFO juju.cmd.jujud machine.go:419 machine
agent machine-0 start (1.24.5-trusty-amd64 [gc])
machine-0: 2015-09-22 19:36:19 WARNING juju.cmd.jujud machine.go:421
developer feature flags enabled: "address-allocation"
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Which JUJU_DEV_FEATURE_FLAG were used?

[Andreas Hasenack]

On Tue, Sep 22, 2015 at 3:00 PM, Nate Finch 
wrote:

> The environment variables are transferred to the server, so getting them
> from /proc//environ on the server should be doable (someone better at
> bash might be able to give you a one liner).
>
>

Thanks. For completeness, the "e" flag for ps shows it:

 4194 ?Ssl0:10 /var/lib/juju/tools/machine-0/jujud machine
--data-dir /var/lib/juju --machine-id 0 --debug UPSTART_INSTANCE=
JUJU_DEV_FEATURE_FLAGS=address-allocation UPSTART_JOB=jujud-machine-0
TERM=linux
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin PWD=/
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Which JUJU_DEV_FEATURE_FLAG were used?

[Andreas Hasenack]

Hi,

given an existing juju environment, is there a way to tell which
JUJU_DEV_FEATURE_FLAGs were used to bootstrap it?

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

Re: Finding out the service name from within a hook

[Andreas Hasenack]

On Mon, Oct 20, 2014 at 9:55 AM, Christopher Glass 
wrote:

> Y's unit name should be accessible through "$JUJU_REMOTE_UNIT" from
> X's relation-joined hook.
> See
> http://juju-docs.readthedocs.org/en/latest/internals/unit-agent-hooks.html
>

I tried that, but got in the weird situation where it's possible for a
relation to exist, but no units be part of it.

In other words, if relids = relation_ids(name) and relids is not null, it's
possible for relation_list(relids[0]) to be empty.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Finding out the service name from within a hook

[Andreas Hasenack]

Hi,

let's say I have two services, called X and Y, and they established a
relation.

>From within a relation joined or changed hook, how can I find out the
service names? For example, when running -joined on X, how can I find out
Y's name?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Hook firing

[Andreas Hasenack]

On Wed, Sep 3, 2014 at 10:00 AM, Simon Davy  wrote:

> On 3 September 2014 13:42, Darryl Weaver 
> wrote:
> > Thanks the IRC logs are pretty helpful.
> > We are seeing the same issue here at Sky,
> > config-changed hook runs "At random times".
> > This is when there are no user changes to the Juju config and no reboots
> > happening.
> > It is possible the juju agent restarted, but I don't think so, but will
> have
> > to collect some evidence first.
>
> Right, this is what I expect is happening to us, but tracking it is
> tricky. We only noticed because our charm has an implementation issue
> in that it tries to reuse an authtoken that has a 24hr expiry.
>
> It might be helpful if some one on juju-core could details if there
> are specific circumstances where the juju agent may restart?
>
>
>
Look in /var/log/syslog and /var/log/upstart for evidence of this restart.
Maybe it died, and then upstart will start it again to keep it running.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Having trouble with the block-storage-broker and ec2

[Andreas Hasenack]

On Fri, Jun 6, 2014 at 7:39 AM, Tim Penhey  wrote:

> options:
> provider: ec2
> key: 
> endpoint: WHAT_GOES_HERE???
> secret: 
>


For ec2, it's like https://ec2.us-west-2.amazonaws.com (adjust for your
region).

For openstack, it's keystone.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju bootstrap hangs

[Andreas Hasenack]

Add  --debug to see what is going on in even more detail.
On May 18, 2014 1:39 AM, "boyd yang"  wrote:

> Hello,
> Sometimes bootstrap hangs here for a long time like 10 hours.
> How to fix this?
>
> root@maas:~# juju bootstrap --show-log
> 2014-05-18 04:33:52 INFO juju.cmd supercommand.go:302 running
> juju-1.18.3-trusty-amd64 [gc]
> 2014-05-18 04:33:52 WARNING juju.cmd.juju common.go:40 ignoring
> environments.yaml: using bootstrap config in file
> "/root/.juju/environments/maas.jenv"
> 2014-05-18 04:33:52 INFO juju.environs open.go:177 environment info
> already exists; using New not Prepare
> 2014-05-18 04:33:52 INFO juju.environs.bootstrap bootstrap.go:46
> bootstrapping environment "maas"
> 2014-05-18 04:33:52 INFO juju.environs.tools tools.go:186 filtering tools
> by released version
> 2014-05-18 04:33:52 INFO juju.environs.tools tools.go:86 reading tools
> with major.minor version 1.18
> 2014-05-18 04:33:52 INFO juju.environs.tools tools.go:97 filtering tools
> by series: trusty
> 2014-05-18 04:33:53 INFO juju.utils http.go:55 hostname SSL verification
> enabled
> 2014-05-18 04:33:58 INFO juju.utils http.go:55 hostname SSL verification
> enabled
> 2014-05-18 04:34:04 INFO juju.utils http.go:55 hostname SSL verification
> enabled
> 2014-05-18 04:34:11 INFO juju.utils http.go:55 hostname SSL verification
> enabled
>
> --
> 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

charm-helpers fixes, how to merge them into actual charms?

[Andreas Hasenack]

This sounds a lot like the static build problem: once a piece of shared
code is fixed/updated, how to make sure everything using it gets rebuilt?

charm-helpers is such a case. It's shared code used by a growing number of
charms.

Case in point: https://bugs.launchpad.net/charm-helpers/+bug/1317980

It makes the ceph charm fail when deploying to a machine where a PV is not
part of a VG (pardon the LVM lingo).

It was merged into charm-helpers. What's the procedure now to get it merged
into at least the ceph charm? And whatever else could be affected?

For now, I filed a bug against the ceph charm:
https://bugs.launchpad.net/charms/+source/ceph/+bug/1319032
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: containers with different ubuntu release than the host?

[Andreas Hasenack]

On Fri, Apr 4, 2014 at 5:32 PM, Andreas Hasenack  wrote:
> So it ended up creating a precise container, not trusty. Is this
> expected? If yes, shouldn't it error out instead of silently deploying

Unexpected, bug filed:
https://bugs.launchpad.net/juju-core/+bug/1302820

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

containers with different ubuntu release than the host?

[Andreas Hasenack]

juju-core-1.17.7

Hi,

should it be possible to create containers (lxc) with a different
ubuntu release than the host?

For example, I have a precise bootstrap node, and I do this:

juju deploy cs:trusty/ubuntu --to lxc:0

I logged in on that node and saw that juju called lxc-create with -r precise:

14857 ?Ssl1:37 /var/lib/juju/tools/machine-0/jujud machine
--data-dir /var/lib/juju --machine-id 0 --debug
16318 ?S  0:00  \_ lxc-create -n juju-machine-0-lxc-0 -t
ubuntu-cloud -f /var/lib/juju/containers/juju-machine-0-lxc-0/lxc.conf
-- --debug --userdata
/var/lib/juju/containers/juju-machine-0-lxc-0/cloud-init --hostid
juju-machine-0-lxc-0 -r precise

So it ended up creating a precise container, not trusty. Is this
expected? If yes, shouldn't it error out instead of silently deploying
a different ubuntu distribution than what I asked?

I suppose that with kernel differences it's not guaranteed that the
services in the container will run on the kernel of the host if they
are too different, but that's "my problem".

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

config-get: "error: settings not found"

[Andreas Hasenack]

Hi,

I have this weird error in a config-changed hook. The charm calls
config-get --format json and it fails:

2014-03-17 09:42:42 INFO juju.worker.uniter uniter.go:348 running
"config-changed" hook
2014-03-17 09:42:42 INFO worker.uniter.jujuc server.go:108 running
hook tool "config-get" ["--format" "json"]
2014-03-17 09:42:42 INFO juju.worker.uniter context.go:255 HOOK error:
settings not found

Is there a normal scenario where this could happen, or is it a bug in juju?

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

Re: Best practices for "fat" charms

[Andreas Hasenack]

On Tue, Apr 1, 2014 at 4:07 PM, Jorge O. Castro  wrote:
> Hi everyone,
>
> Matt Bruzek and I have been doing some charm testing on a machine that
> does not have general access to the internet. So charms that pull from
> PPAs, github, etc. do not work.
>
> We've been able to "fatten" the charms by doing things like creating a
> /files directory in the charm itself and putting the



There is/was a concern from #is about this because git is used to
manage the charm content on the unit. If you have a fat tarball in it,
and then upgrade the charm, it's like entropy, the total size will
just keep increasing with every charm upgrade.

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

Re: Sharing a DB user password among units of the app

[Andreas Hasenack]

On Thu, Mar 27, 2014 at 11:37 AM, Stuart Bishop
 wrote:
> I've just looked at the code, and if you are using a db-admin relation
> you can already connect to any database as any user. You can connect
> using the credentials you are given and create the additional users
> you need in the db-admin-relation-changed hook. If you use the same
> password as the generated user, you won't even have to worry about
> distributing that information between units in the relation.
>
>> Here I would need one "db" relation just to get the roles. I wouldn't
>> create the 6 databases here (how could I?), I would let the existing
>> code (not charm code: product code) do that as usual. Let's see how
>> far I get.
>
> If you need 6 databases, you could add 6 relations to the PostgreSQL
> service each specifying a different database name. Your charm wouldn't
> care if these are 6 relations to a single PostgreSQL service, 6
> relations to 6 separate PostgreSQL services, or something in between.
> If that is too mach deployment hassle, then you can do this with a

That seems too much hassle indeed.

Let me take a step back: this all started because I wanted the
deployment to use randomly generated passwords for the database users.

That seems a perfectly reasonable requirement, and not doing that
leads to a wtf moment even. I mean, exposing the internal database
user passwords in the charm config and expecting the admin to change
that with every deployment doesn't work.

> single db-admin relation and issue the CREATE DATABASE commands in
> your db-admin-relation-changed hook. Let me know if you end up
> manually creating databases - I should ensure that the backup jobs
> cope (everything else should be just fine, including replication).

We do that. The databases are created in the db-admin-relation-changed
hook, using the superuser that said relation gave us when it was
established. This hook also, today, creates the database user (role
with LOGIN), and sets a password for it. Due to all these histerical
reasons ;) from this thread, this breaks if the password is randomly
generated locally.

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

Re: Sharing a DB user password among units of the app

[Andreas Hasenack]

On Thu, Mar 27, 2014 at 3:51 AM, Stuart Bishop
 wrote:
>> In effect it looks like I don't need to share the credentials among
>> the services?
>
> Correct. I think you are just fine with one relation per database and
> using the generated credentials, and using the granted roles to
> control database permissions.

I will have to try this in more detail. We already use the db-admin
relation to do everything we need with the database, because that's
how this is installed outside the world of juju. And that case still
has to work, of course.

One nag is that the db relation only gives me back one user, and
certain versions of our product need two. These have different
permissions. But I'll cross that bridge when I get to it.

Here I would need one "db" relation just to get the roles. I wouldn't
create the 6 databases here (how could I?), I would let the existing
code (not charm code: product code) do that as usual. Let's see how
far I get.

> To actually create the tables and grant permissions to the roles, you
> can use a db-admin relation (or perhaps 'juju-run' from a subordinate
> charm on the PostgreSQL service). Try to avoid the undocumented
> 'schema_user' and 'schema_password' set of credentials on the db
> relation that has permissions - there is a security hole there that
> needs to be closed up, probably by dropping the feature entirely (Bug
> #1167249).

Good to know, thanks.

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

Re: Sharing a DB user password among units of the app

[Andreas Hasenack]

On Tue, Mar 25, 2014 at 12:07 PM, Stuart Bishop
 wrote:
>> The patch would be like: "GRANT DELETE ON TABLE person TO landscape".
>> That "landscape" is hardcoded, so that user has to exist and be the
>> user the services use. So your first paragraph above solves this
>> already, right? We give a list of users to postgresql via the
>> relation, and "landscape" is in that list.
>
> I see. If this is the issue, then the 'roles' feature already does
> what you need: 'relation-set roles=landscape' in your
> db-relation-joined hook, and the generated user will be granted the
> landscape role and inherit all its permissions (users and groups are

Interesting. So I tried with a dummy charm that joins the postgresql
db relation. I deployed it as pgsql-test and pgsql-test-second, so,
two services.

It sets database=landscape-test-main and roles=landscape,landscape_maintenance

These are the roles after both services have joined:
postgres=# \du
List of roles
   Role name|   Attributes
  | Member of
++---
 db_27_pgsql_test   |
  | {landscape,landscape_maintenance}
 db_27_pgsql_test_schema|
  | {}
 db_28_pgsql_test_second|
  | {landscape,landscape_maintenance}
 db_28_pgsql_test_second_schema |
  | {}
 landscape  | Cannot login
  | {}
 landscape_maintenance  | Cannot login
  | {}
 postgres   | Superuser, Create role, Create DB,
Replication | {}



I have two users that can login, one per service: db_27_pgsql_test and
db_28_pgsql_test_second. These are different users, with different
credentials. Yet, once they login, they both have the same roles:
landscape and landscape_maintenance, correct? So whatever the
landscape role has in terms of permissions, db_27_pgsl_test will have
too.

In effect it looks like I don't need to share the credentials among
the services?

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

Re: Sharing a DB user password among units of the app

[Andreas Hasenack]

On Tue, Mar 25, 2014 at 7:51 AM, Stuart Bishop  wrote:

> The simple fix is to add a usernames or extra_usernames parameter on
> the relation, similar to database, allowing the client to specify a
> list of extra usernames that should be allowed to connect from the
> client to this relation's database.

This works, and has the benefit of using randomly generated passwords.
But I need these to be shared among different services, like mysql's
shared-db relation.

>
> There are security issues with this approach. A malicious client can
> specify a database and user with permissions, gaining access to
> another service's data. If service_a and service_b are related to the
> same PostgreSQL service, then if service_a is compromised then all of
> service_b's data is also accessible.

This is the same as with mysql's shared-db relation, right? The same
risk exists there, as all services have access to each other's
credentials.


> For your particular use case of patching the database, we could use
> the db-admin relation. This already connects as a superuser to any
> database, and we could open that up to connecting to any database as
> any user without lowering security further.

The patch would be like: "GRANT DELETE ON TABLE person TO landscape".
That "landscape" is hardcoded, so that user has to exist and be the
user the services use. So your first paragraph above solves this
already, right? We give a list of users to postgresql via the
relation, and "landscape" is in that list.

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

Re: Sharing a DB user password among units of the app

[Andreas Hasenack]

On Mon, Nov 4, 2013 at 7:50 AM, Stuart Bishop
 wrote:
> On Tue, Oct 29, 2013 at 7:38 PM, Andreas Hasenack  
> wrote:
>
>> When the first unit of the app comes up, it creates a random password and
>> uses the DB admin user to create an unprivileged DB user with that password.
>
> Do you know why the client service needs to create the user, rather
> than using users created by the PostgreSQL charm? Database roles can

(old thread)

We need 2 database users and 6 databases. Used to be 3 database users
even. And we can have as many as 5 different juju services needing
those credentials.

But the kicker reason is we can't use a random DB username. Although
we have a configuration setting for its name for the app to use at
runtime, the hundreds of database upgrade patches we have assume a
hardcoded user all over the place. :(

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

Re: Bootstrap problem on aws, 1.16.5

[Andreas Hasenack]

On Thu, Feb 6, 2014 at 10:35 PM, David Cheney wrote:

> Even though s3 buckets are drawn from a single global namespace, each
> bucket has a home region. Switching to a different ec2 region, and changing
> the name of your control bucket, will associate this new bucket with the
> new region.
>
>
Doesn't work, even tried Tokyo, which I never used.

My credentials are drawn from some sort of corporate account that Canonical
has, maybe we hit some sort of limit. I can't even delete the buckets I can
see, I get the same conflict error (HTTP 409):

$ s3cmd rb s3://juju-
ERROR: S3 error: 409 (OperationAborted): A conflicting conditional
operation is currently in progress against this resource. Please try again.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Bootstrap problem on aws, 1.16.5

[Andreas Hasenack]

On Thu, Feb 6, 2014 at 10:31 PM, David Cheney wrote:

> oh dear, that does look like a call to Amazon is in order.
>
>
http://i.imgur.com/CbWqDD8.png


Did you try a different ec2 region ?
>
>
Not yet. I'm seeing what I can do to s3 via the api.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Bootstrap problem on aws, 1.16.5

[Andreas Hasenack]

On Thu, Feb 6, 2014 at 10:16 PM, David Cheney wrote:

> Can you try renaming your control bucket slightly. You should keep your
> control bucket name short, ideally less than 24 characters.
>
>
I'm trying some s3 operations in Amazon's console, and they are failing
with the same error. I can't create new buckets, and nothing happens when I
try to delete existing ones.

Looks like it's outside of juju's control.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Bootstrap problem on aws, 1.16.5

[Andreas Hasenack]

Hi,

I'm being hit by this bug more frequently than not:

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

Even after I trash my jenv files and caches and what not, remain just with
~/.juju/environments.yaml, and then also change the control bucket name, I
still can't bootstrap.

The only thing lingering around is the previous bootstrap instance,
terminated, but still in the output of ec2-describe-instances:

$ ec2-describe-instances
RESERVATION r-da467bd3 465288025103 juju-andreas-aws,juju-andreas-aws-0
INSTANCE i-7495aa7d ami-d0d8b8e0 terminated 0 m1.small
2014-02-06T19:28:00+ us-west-2a aki-fc37bacc monitoring-disabled ebs
paravirtual xen
0b27937a79f85931d157cc8e1804fc73dd12c22e0e68b03cb39a88a4032efd54 sg-e8dcddd8,
sg-eadcddda default false


$ juju bootstrap -v
verbose is deprecated with the current meaning, use show-log
2014-02-07 00:08:38 INFO juju.environs open.go:156 environment info already
exists; using New not Prepare
2014-02-07 00:08:38 INFO juju.provider.ec2 ec2.go:193 opening environment
"andreas-aws"
2014-02-07 00:08:39 INFO juju.environs.tools tools.go:181 filtering tools
by released version
2014-02-07 00:08:39 INFO juju.environs.tools tools.go:85 reading tools with
major.minor version 1.16
2014-02-07 00:08:39 INFO juju.environs.tools tools.go:96 filtering tools by
series: precise
2014-02-07 00:08:51 WARNING juju.environs open.go:258 failed to write
bootstrap-verify file: cannot make S3 control bucket: A conflicting
conditional operation is currently in progress against this resource.
Please try again.
2014-02-07 00:08:51 ERROR juju supercommand.go:282 provider storage is not
writable

It just won't budge :(
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: How to get private-address in juju status output?

[Andreas Hasenack]

On Wed, Nov 27, 2013 at 12:48 PM, Serge E. Hallyn  wrote:

> Quoting Andreas Hasenack (andr...@canonical.com):
> > Hi,
> >
> > I have an instance on openstack (canonistack) that got a floating ip, and
> > that address is now showing as public-address. I guess that's ok.
> >
> > Except it's not reachable via ssh anymore (nor juju ssh). For some reason
> > (bug? deployment issue?) public addresses are not routeable from within
> > that cloud itself. You have to use the private address.
> >
> > So, how do I get the private address in the juju status output?
> >
> > This is juju-core 1.16.3, btw (server and client).
>
> Well in the past I've passed the private address along by using
> relation-get private-address.  So you should be able to do
>
> PRIVADDR=`relation-get private-address`
> juju-log "private address is $PRIVADDR"
>
> unless I misunderstand what you want.
>
>
I want it from the machine coordinating the deployments, i.e., where you
run "juju deploy", "juju status", etc. Parsing logs to get that is hacky.
I'll resort to nova commands.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

How to get private-address in juju status output?

[Andreas Hasenack]

Hi,

I have an instance on openstack (canonistack) that got a floating ip, and
that address is now showing as public-address. I guess that's ok.

Except it's not reachable via ssh anymore (nor juju ssh). For some reason
(bug? deployment issue?) public addresses are not routeable from within
that cloud itself. You have to use the private address.

So, how do I get the private address in the juju status output?

This is juju-core 1.16.3, btw (server and client).
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

juju's private-address, DNS, MAAS and postgresql

[Andreas Hasenack]

Sorry for the confusing subject line.

This is the issue:
2013-11-07 13:47:02 UTC FATAL:  no pg_hba.conf entry for host "10.0.5.100",
user "landscape", database "landscape-standalone-main", SSL off
2013-11-07 13:47:02 UTC DETAIL:  Client IP address resolved to
"10-0-5-100.maaslocal", forward lookup not checked.

My landscape unit (kmkxr.maaslocal) cannot talk to postgresql.

pg_hba.conf:
host all all kmkxr.maaslocal md5

connecting machine is 10.0.5.100:
# host 10.0.5.100
100.5.0.10.in-addr.arpa domain name pointer 10-0-5-100.maaslocal.

# host kmkxr.maaslocal
kmkxr.maaslocal is an alias for 10-0-5-100.maaslocal.
10-0-5-100.maaslocal has address 10.0.5.100

Postgresql does a reverse lookup on the connecting IP, which gives it the
name "10-0-5-100.maaslocal". That doesn't match the entry in pg_hba.conf
(kmkxr.maaslocal), and the connection is rejected.

The "kmkxr.maaslocal" string came from the juju relation "private-address"
key:

postgresql/0:db-admin-relation-changed % relation-get
private-address: kmkxr.maaslocal

On that kmkxr machine /etc/hosts has this entry:
# Added by cloud-init on Thu, 07 Nov 2013 13:11:18 +
127.0.1.1 kmkxr.maaslocal kmkxr

And:
root@kmkxr:~# hostname -f
kmkxr.maaslocal

I'm guessing that's why private-address was set to kmkxr.maaslocal
(although "address" implies an IP to me, not a fqdn).

If I remove that entry from /etc/hosts:
root@kmkxr:~# hostname -f
10-0-5-100.maaslocal

As I understand it, maas pre-generates all possible A and PTR records for
the network it was given, and adds CNAMEs as machines get provisioned. In
this case, kmkxr.maaslocal is a CNAME, but at the same time it was added to
/etc/hosts.

So, I don't know where the bug is. I'm tempted to say we shouldn't add that
/etc/hosts entry since everything is in DNS handled by maas.

In any case, the postgresql charm can't get the unit's connecting IP from
the relation data unless it's explicitly set.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: package is 1.16.2, calls itself 1.17.0?

[Andreas Hasenack]

On Mon, Nov 4, 2013 at 10:29 AM, Andreas Hasenack wrote:

> Hi,
>
> $ dpkg-query -W juju-core
> juju-core 1.16.2-0ubuntu1~ubuntu13.04.1~juju1
>
>
> but
>
> $ juju version
> 1.17.0-raring-amd64
>


I'm so sorry, my mistake. The "juju" binary I was calling came from
somewhere else :(
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

package is 1.16.2, calls itself 1.17.0?

[Andreas Hasenack]

Hi,

$ dpkg-query -W juju-core
juju-core 1.16.2-0ubuntu1~ubuntu13.04.1~juju1


but

$ juju version
1.17.0-raring-amd64

$ apt-cache policy juju-core
juju-core:
  Installed: 1.16.2-0ubuntu1~ubuntu13.04.1~juju1
  Candidate: 1.16.2-0ubuntu1~ubuntu13.04.1~juju1
  Version table:
 *** 1.16.2-0ubuntu1~ubuntu13.04.1~juju1 0
500 http://ppa.launchpad.net/juju/stable/ubuntu/ raring/main amd64
Packages
100 /var/lib/dpkg/status
 1.10.0.1-0ubuntu1~ubuntu13.04.1 0
100 http://br.archive.ubuntu.com/ubuntu/ raring-backports/universe
amd64 Packages

And tools for 1.17.0 don't seem to be published to canonistack at least:

$ juju bootstrap -v --constraints mem=1500M
verbose is deprecated with the current meaning, use show-log
2013-11-04 12:24:12 INFO juju.provider.openstack provider.go:127 opening
environment "canonistack2"
2013-11-04 12:24:15 INFO juju.environs.tools tools.go:85 reading tools with
major.minor version 1.17
2013-11-04 12:24:15 INFO juju.environs.tools tools.go:96 filtering tools by
series: precise
2013-11-04 12:24:20 INFO juju.cmd.juju bootstrap.go:221 no tools found, so
attempting to build and upload new tools
(...)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Sharing a DB user password among units of the app

[Andreas Hasenack]

On Tue, Oct 29, 2013 at 11:11 AM, John Arbash Meinel  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2013-10-29 16:38, Andreas Hasenack wrote:
> > Now I run add-unit, and another unit comes up. How can it get that
> > password?
> >
> ...
> >
> > Is this a case for a peer relation?
> >
> >
>
> Yes. As I understand it, that is exactly what a peer relation is for.
>
>
Turns out a peer relation won't be good enough. It solves the add-unit
case, sure, but I also need to share this password among different
*services* (I neglected to consider that at first).

In this case the application is composed of several different services that
talk to the DB. So while I can scale out the units of a service and have
the password shared among those units, there is no way that I can see where
I can also share those credentials with the other services that make up my
application.

I'll take the config approach for now and make sure all services are
deployed with the same initially-chosen-by-the-admin password.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Sharing a DB user password among units of the app

[Andreas Hasenack]

Hi,

There is this charm with a db-admin relation to postgresql. In this
relation, the charm gets access to a super user in postgresql and can do
whatever it wants with it.

When the first unit of the app comes up, it creates a random password and
uses the DB admin user to create an unprivileged DB user with that password.

Now I run add-unit, and another unit comes up. How can it get that password?

It can find out that the DB user already exists, but not get its password
(it's hashed on the DB side).

The first unit that came up and actually created the DB user can
relation-set this data, but that is not visible to the other unit.

I could have the password has a config key, and if empty that tells the
charm to randomize it. But then it don't be available in the "juju get"
output, because the charm itself cannot "juju set" it once it has the new
value. And as such the other unit would also not see it.

Is this a case for a peer relation?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: bootstrap constraints in config file

[Andreas Hasenack]

On Thu, Sep 19, 2013 at 10:34 AM, Andreas Hasenack wrote:

> Hi,
>
> is there a way to specify constraints in the environments.yaml file?
>
>
I guess not, so I filed a bug:
https://bugs.launchpad.net/juju-core/+bug/1228311
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

bootstrap constraints in config file

[Andreas Hasenack]

Hi,

is there a way to specify constraints in the environments.yaml file?

I found out that the bootstrap node no longer works with an instance with
just 512Mb of RAM so I need to pass something like "constraints mem=1024M"
everytime. I tried the "constraints" keyword in environments.yaml file, but
I get a warning saying it's now known.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Manual provisioning - feedback wanted

[Andreas Hasenack]

On Tue, Sep 10, 2013 at 10:17 AM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> On Tue, Sep 10, 2013 at 4:18 PM, Andreas Hasenack 
> wrote:
>
>> The 10.0.3.53 "machine" is a new container I brought up manually with
>> lxc-create and lxc-start. lxc-list above shows all containers, and it was
>> the only one running.
>>
>> Right now I have this output for that ls command:
>> # ls /etc/init/juju*
>> /etc/init/juju-agent-andreas-local.conf
>>  /etc/init/juju-db-andreas-local.conf
>>
>
> As discussed on IRC: the command will be run in the target (the
> container), not the local host.
>
>
>>  juju lxc is bootstrapped, but no units are running, and lxc-list shows
>> my both containers stopped.
>>
>
> I'm creating a new container on my laptop now, using your configuration.
> I'll let you know what I find.
>
>
It's because of this ssh warning:
$ ssh 10.0.3.230 "ls /etc/init/ | grep juju.*\\.conf || exit 0"
Warning: Permanently added '10.0.3.230' (ECDSA) to the list of known hosts.
$

The code grabs both stderr and stdout and checks for len > 0:
out, err := cmd.CombinedOutput()
(...)
return len(strings.TrimSpace(string(out))) > 0, nil




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

Re: Manual provisioning - feedback wanted

[Andreas Hasenack]

On Tue, Sep 10, 2013 at 2:08 AM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

>
>> $ sudo $(which juju) bootstrap
>> $ juju status
>> environment: local
>> machines:
>>   "0":
>> agent-state: started
>> agent-version: 1.15.0.1
>> dns-name: 10.0.3.1
>> instance-id: localhost
>> series: raring
>> services: {}
>> $ sudo lxc-list
>> WARNING: lxc-list is deprecated, please use lxc-ls --fancy.
>>  This symlink will be dropped in LXC 1.0.
>>
>> NAME   STATEIPV4   IPV6  AUTOSTART
>> --
>> precise-1  RUNNING  10.0.3.53  - NO
>> saucy  STOPPED  -  - NO
>>
>> $ juju add-machine ssh:andreas@10.0.3.53 -v
>> 2013-09-09 13:35:41 INFO juju.provider.local environprovider.go:32
>> opening environment "local"
>> 2013-09-09 13:35:41 INFO juju.state open.go:68 opening state; mongo
>> addresses: ["10.0.3.1:37017"]; entity ""
>> 2013-09-09 13:35:41 INFO juju.state open.go:106 connection established
>> 2013-09-09 13:35:41 INFO juju.provider.local environprovider.go:32
>> opening environment "local"
>> 2013-09-09 13:35:41 ERROR juju supercommand.go:282 command failed:
>> machine is already provisioned
>> error: machine is already provisioned
>>
>> Was this supposed to work?
>>
>
> I take it you had an existing container? One of the first things
> "add-machine ssh:..." will do is execute "ls /etc/init/juju*". If it comes
> back non-empty, then it won't let you proceed. Is your container a leftover?
>
>
The 10.0.3.53 "machine" is a new container I brought up manually with
lxc-create and lxc-start. lxc-list above shows all containers, and it was
the only one running.

Right now I have this output for that ls command:
# ls /etc/init/juju*
/etc/init/juju-agent-andreas-local.conf
 /etc/init/juju-db-andreas-local.conf

juju lxc is bootstrapped, but no units are running, and lxc-list shows my
both containers stopped.



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

Re: Manual provisioning - feedback wanted

[Andreas Hasenack]

On Sun, Sep 8, 2013 at 10:47 PM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> Hello everyone,
>
> As was noted in the 1.13.3 release notes thread, we did not announce one
> the major features that made it into the release (manual provisioning).
> This was intentional as we have not written any documentation yet. On the
> other hand, it would be good to get some feedback so that we can make
> changes if necessary, or feed into the documentation.
>
> So, below is a bit of a run-down. If you're interested in this feature,
> try it out and let us know if you or have any issues or any thoughts for
> improvement.
>
>
Here is what I just tried with juju-core trunk (r1772):
$ sudo $(which juju) bootstrap
$ juju status
environment: local
machines:
  "0":
agent-state: started
agent-version: 1.15.0.1
dns-name: 10.0.3.1
instance-id: localhost
series: raring
services: {}
$ sudo lxc-list
WARNING: lxc-list is deprecated, please use lxc-ls --fancy.
 This symlink will be dropped in LXC 1.0.

NAME   STATEIPV4   IPV6  AUTOSTART
--
precise-1  RUNNING  10.0.3.53  - NO
saucy  STOPPED  -  - NO

$ juju add-machine ssh:andreas@10.0.3.53 -v
2013-09-09 13:35:41 INFO juju.provider.local environprovider.go:32 opening
environment "local"
2013-09-09 13:35:41 INFO juju.state open.go:68 opening state; mongo
addresses: ["10.0.3.1:37017"]; entity ""
2013-09-09 13:35:41 INFO juju.state open.go:106 connection established
2013-09-09 13:35:41 INFO juju.provider.local environprovider.go:32 opening
environment "local"
2013-09-09 13:35:41 ERROR juju supercommand.go:282 command failed: machine
is already provisioned
error: machine is already provisioned

Was this supposed to work?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: PPAs for juju api client and deployer

[Andreas Hasenack]

On Wed, Aug 21, 2013 at 5:27 PM, Mark Canonical Ramm-Christensen <
mark.ramm-christen...@canonical.com> wrote:

> *Deployer*
>
>   * We are using promoting and integrating deployer into the GUI
>   * Specific versions of juju-core have required specific versions of the
> deployer already
>   * We use it in cloud deployments
>
> I think that means we have to support it in stable.
>
> *API Client*
>
>   * We aren't yet telling anybody they have to use this and we don't
> officially support it
>
> I think this means that it gets to stay in it's own PPA for now, but that
> the above arguments would apply and we'd need to get it into devel/stable.
>
>
The deployer needs the api client, I'm not sure if that was clear.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju