Re: Major Roadblocks - real life use cases

[James Beedy]

Drew,

Thanks for the response.

I've been dabbling in these areas.

Looks like I may just need to use a combination of a few different methods
here.

~James



On Tue, May 29, 2018 at 8:45 AM, Drew Freiberger <
drew.freiber...@canonical.com> wrote:

> On Mon, May 28, 2018 at 10:23:21PM -0700, James Beedy wrote:
>
>> I want to shed some light on a few blockers for me right now.
>>
>> 2) Maas needs better support for 3rd party drivers.
>>  * Getting my Mellanox drivers hooked up at commissioning so maas
>> recognizes the 40Gb interfaces is taking me a few weeks now. Supporting
>> user defined 3rd party driver should be a primary supported capability of
>> MAAS.
>>  * how are people doing Hadoop,and Ceph and Openstack without this,
>> possibly someone knows something I don’t know here?
>>
>
> Hello James,
>
> I believe that MAAS 2.x's nodes-scripts (Hardware Testing and
> Commissioning scripts) might be helpful for any custom code or
> drivers you might want to inject in the commissioning process.
>
> Here is a link to the guide for these scripts.  I might suggest
> the cript example for "Configure HPA" might provide a good template for
> how you might want to inject a Mellanox driver/config into your build.
>
> https://docs.maas.io/2.3/en/nodes-scripts
>
> The MAAS server has a web server serving out a docroot from
> /var/www/htdocs where you can drop any files you might want to curl/wget
> from your scripts.  I believe there are environment variables for the
> preseeds for the IP of the MAAS server for your URL.
>
> You might also notice that you can have the script automatically install
> packages from any of apt, snap, or URL.  You can even tag the script to
> automatically run on hardware with a specific PCI ID. with the
> for_hardware metadata field.
>
> Documentation on managing these scripts via the CLI is here:
>
> https://docs.maas.io/2.3/en/nodes-scripts-cli
>
> In MAAS 1 environments, one would have to update the curtin preseeds
> manually in /etc/maas/preseeds to inject scripts of this type.
>
> I do not know if the commissioning scripts also happen at deployment
> time (doubtful), but hopefully the install of your chosen OS will
> include the drivers needed, or you've found that you can add an Ubuntu
> package repository or PPA that contains your packages to be installed
> per https://docs.maas.io/2.3/en/manage-repos.
>
> I hope this information helps.
>
> Sincerely,
> -Drew
>
> Any feedback would be greatly appreciated.
>>
>> Thanks
>>
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Major Roadblocks - real life use cases

[James Beedy]

I want to shed some light on a few blockers for me right now.

1) I am having a hard time actually using Hadoop charms for Hadoop deploys on 
metal due to 2 reasons:
* Maas support for 3rd party drivers a pain
* Hadoop charms don’t have storage support

2) I am having difficulty deploying Ceph and Neutron due to:
* maas support for 3rd party drivers a pain

Here are my two asks, hopefully you will find them as pertinent as I do.

1) Hadoop charms need storage support
* hdfs
* cephfs

Currently without support for storage, Hadoop slaves just use a local directory 
on / for HDFS.

This is entirely illegitimate for any real batch processing use case using HDFS 
(something I’m trying to do right now but can’t use juju Hadoop to do because 
of the lack of support for storage).

2) Maas needs better support for 3rd party drivers.
  * Getting my Mellanox drivers hooked up at commissioning so maas 
recognizes the 40Gb interfaces is taking me a few weeks now. Supporting user 
defined 3rd party driver should be a primary supported capability of MAAS.
  * how are people doing Hadoop,and Ceph and Openstack without this, 
possibly someone knows something I don’t know here?

Any feedback would be greatly appreciated.

Thanks



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

SLURM Charms New Upstream

[James Beedy]

Request to have the 'slurm-node', and 'slurm-controller' charms
re-promulgated under the omnivector org namespace.

The new charm locations are

cs:~omnivector/slurm-node

cs:~omnivector/slurm-controller

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

Re: Cinder-Ceph Multi-Backend Example

[James Beedy]

Alex,

Thanks for the response, and nice work on the write up.

~James

On Mon, Apr 16, 2018 at 5:28 AM, alex barchiesi <alex.barchi...@garr.it>
wrote:

> Hi James,
> at GARR we recently tested the cinder multi backend with the following
> idea in mind:
> support 3 different backends:
>
>- a default one, for general-purpose disks like virtual machine boot
>disks: replicated pool with replica factor equal to 3
>- a reduced redundancy one: replicated pool with replica factor 2,
>which should slightly improve latency
>- a large capacity one: erasure-coded (possibly with a small frontend
>replicated pool)
>
> Premise: we have a juju deployed O~S (spanning 3 geographical data
> centers).
>
> We configured Cinder such that it allows selection between multiple
> “Volume Types”, where each Volume Type points to a distinct Ceph pool
> within the same Ceph cluster.
>
> This is the simplest configuration, as it involves Cinder configuration
> alone. Volumes which are created can be later attached to running
> instances, but all instances will have their boot disk on the default pool
> cinder-ceph.
>
> We faced some issues as reported in details here: https://docs.google.com/
> document/d/1VSS28cvZBIOEzTOmVMWZ0o9FiVFkVLvu__ZOLxneMqQ/edit#
>
> Would be interesting to find a way to be able to select the pool also for
> the boot disk of a VM
>
> Any comment, idea, "whatever" (also on the doc) is very much appreciated
>
> best Alex
>
>
>
> Dr. Alex Barchiesi
> 
> Senior cloud architect
> Art -Science relationships responsible
>
> GARR CSD department
>
> Rome GARR: +39 06 4962 2302
> Lausanne EPFL: +41 (0) 774215266
>
> linkedin: alex barchiesi
> <http://www.linkedin.com/profile/view?id=111538190=%2Enmp_*1_*1_*1_*1_*1_*1_*1_*1_*1_*1=spm_pic>
> _
> I started with nothing and I still have most of it.
>
>
>
> On Sat, Apr 14, 2018 at 3:25 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
>> Looking for examples that describe how to consume multiple ceph backends
>> using the cinder-ceph charm.
>>
>> Thanks
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Cinder-Ceph Multi-Backend Example

[James Beedy]

Looking for examples that describe how to consume multiple ceph backends
using the cinder-ceph charm.

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

Re: Openstack User Feedback

[James Beedy]

forgot one: https://bugs.launchpad.net/charms.ceph/+bug/1761230

On Wed, Apr 4, 2018 at 8:19 AM, James Beedy <jamesbe...@gmail.com> wrote:

> Here are the bugs:
>
> 1) https://bugs.launchpad.net/charms.ceph/+bug/1761214
> 2) https://bugs.launchpad.net/charms.ceph/+bug/1761208
> 3) https://bugs.launchpad.net/charm-ceph-fs/+bug/1753640
>
>
> On Wed, Apr 4, 2018 at 5:52 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
>> Hello,
>>
>> @chrismacnaughton @jamespage @beisner @openstack-charmers ceph <->
>> openstack such a broken bone right now.
>>
>> Please fix.
>>
>> Here is my bundle https://pastebin.com/gEUYaiFh
>>
>>
>> (From IRC)
>> 05:29  heres my deploy, looks great
>> 05:29  https://pastebin.com/a2iNrBxv
>> <https://pastebin.com/a2iNrBxv>
>> jamesbeedy - Pastebin.com
>> <https://pastebin.com/a2iNrBxv>
>> 05:30  following a (what appears to be successful) deploy, I only
>> see a 'glance' pool in ceph, and its in warning due to pg_num > pgp_num
>> 05:31  increasing pgp_num gets me a healthy status
>> 05:32  follow by another health warning
>> https://paste.ubuntu.com/p/zD7HxMz6s6/
>> Ubuntu Pastebin
>> <https://paste.ubuntu.com/p/zD7HxMz6s6/>
>> 05:32  running `sudo ceph osd pool application enable glance rbd`
>> got me back to healthy on my 'glance' pool
>> 05:33  these are the two first papercuts
>> 05:33  next - Manager for service cinder-volume cinder@cinder-ceph
>> is reporting problems, not sending heartbeat. Service will appear "down".
>> 05:34   the only pool I see following a deploy is 'glance'
>> https://paste.ubuntu.com/p/Gg5G3Bmhq3/
>> Ubuntu Pastebin
>> <https://paste.ubuntu.com/p/Gg5G3Bmhq3/>
>> 05:36  when I try to create an instance in openstack I get the good
>> ol' - Error: Failed to perform requested operation on instance "aset", the
>> instance has an error status: Please try again later [Error: Build of
>> instance 13e170cd-6aea-43ed-9ca1-de2ae62c3118 aborted: Volume
>> 72e36907-81df-446c-b580-78bd96134ce0 did not finish being created even
>> after we waited 0 seconds or 1 attempts. And its status is error.].
>> 05:36  possibly there is a bunch of post deploy configuration that
>> need be done here?
>>
>>
>> Thanks
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Openstack User Feedback

[James Beedy]

Here are the bugs:

1) https://bugs.launchpad.net/charms.ceph/+bug/1761214
2) https://bugs.launchpad.net/charms.ceph/+bug/1761208
3) https://bugs.launchpad.net/charm-ceph-fs/+bug/1753640


On Wed, Apr 4, 2018 at 5:52 AM, James Beedy <jamesbe...@gmail.com> wrote:

> Hello,
>
> @chrismacnaughton @jamespage @beisner @openstack-charmers ceph <->
> openstack such a broken bone right now.
>
> Please fix.
>
> Here is my bundle https://pastebin.com/gEUYaiFh
>
>
> (From IRC)
> 05:29  heres my deploy, looks great
> 05:29  https://pastebin.com/a2iNrBxv
> <https://pastebin.com/a2iNrBxv>
> jamesbeedy - Pastebin.com
> <https://pastebin.com/a2iNrBxv>
> 05:30  following a (what appears to be successful) deploy, I only
> see a 'glance' pool in ceph, and its in warning due to pg_num > pgp_num
> 05:31  increasing pgp_num gets me a healthy status
> 05:32  follow by another health warning https://paste.ubuntu.com/p/
> zD7HxMz6s6/
> Ubuntu Pastebin
> <https://paste.ubuntu.com/p/zD7HxMz6s6/>
> 05:32  running `sudo ceph osd pool application enable glance rbd`
> got me back to healthy on my 'glance' pool
> 05:33  these are the two first papercuts
> 05:33  next - Manager for service cinder-volume cinder@cinder-ceph
> is reporting problems, not sending heartbeat. Service will appear "down".
> 05:34   the only pool I see following a deploy is 'glance'
> https://paste.ubuntu.com/p/Gg5G3Bmhq3/
> Ubuntu Pastebin
> <https://paste.ubuntu.com/p/Gg5G3Bmhq3/>
> 05:36  when I try to create an instance in openstack I get the good
> ol' - Error: Failed to perform requested operation on instance "aset", the
> instance has an error status: Please try again later [Error: Build of
> instance 13e170cd-6aea-43ed-9ca1-de2ae62c3118 aborted: Volume
> 72e36907-81df-446c-b580-78bd96134ce0 did not finish being created even
> after we waited 0 seconds or 1 attempts. And its status is error.].
> 05:36  possibly there is a bunch of post deploy configuration that
> need be done here?
>
>
> Thanks
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Openstack User Feedback

[James Beedy]

Hello,

@chrismacnaughton @jamespage @beisner @openstack-charmers ceph <->
openstack such a broken bone right now.

Please fix.

Here is my bundle https://pastebin.com/gEUYaiFh


(From IRC)
05:29  heres my deploy, looks great
05:29  https://pastebin.com/a2iNrBxv

jamesbeedy - Pastebin.com

05:30  following a (what appears to be successful) deploy, I only see
a 'glance' pool in ceph, and its in warning due to pg_num > pgp_num
05:31  increasing pgp_num gets me a healthy status
05:32  follow by another health warning
https://paste.ubuntu.com/p/zD7HxMz6s6/
Ubuntu Pastebin

05:32  running `sudo ceph osd pool application enable glance rbd` got
me back to healthy on my 'glance' pool
05:33  these are the two first papercuts
05:33  next - Manager for service cinder-volume cinder@cinder-ceph is
reporting problems, not sending heartbeat. Service will appear "down".
05:34   the only pool I see following a deploy is 'glance'
https://paste.ubuntu.com/p/Gg5G3Bmhq3/
Ubuntu Pastebin

05:36  when I try to create an instance in openstack I get the good
ol' - Error: Failed to perform requested operation on instance "aset", the
instance has an error status: Please try again later [Error: Build of
instance 13e170cd-6aea-43ed-9ca1-de2ae62c3118 aborted: Volume
72e36907-81df-446c-b580-78bd96134ce0 did not finish being created even
after we waited 0 seconds or 1 attempts. And its status is error.].
05:36  possibly there is a bunch of post deploy configuration that
need be done here?


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

BigTop Phase2 - Circle the Wagons

[James Beedy]

Hello,

In no attempt to downplay the legitimacy of the BigTop charms, I want to
call to attention the need to circle the wagons back around and bring them
current.

I've been diving in lately trying to get these things deployed to a bare
metal cluster, and have found a few things that need attention in order for
the charms to better fit deploys to metal.

The BigTop charms are lacking support for:
  - spaces
  - storage
  - sensible configs exposed
  - reactive updates


Possibly there is already work going on behind the scenes somewhere
addressing these things, if not, possibly we can can get an agenda together
for what needs to be done and get to it.

I'm not entirely sure if anyone is even actively maintaining them anymore,
or if this is it?

I would be entirely willing to help with this effort, I also have a few
others that are interesting in learning the ecosystem and helping get these
Hadoop/BigTop things into tip top shape.

Either way, lets bring these charms back to life!

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

Re: Juju Openstack - Blocked

[James Beedy]

I wanted to chime back in with the solution to the issue I was
experiencing.

The source of the issue undoubtedly was me. I was trying to launch a flavor
which had insufficient root-disk for a xenial.img (2G).

The the traceback which indicated the insufficient disk error was being
obfuscated by the user facing error I was seeing, block_device_mapping
error [0].
This alongside the erroneous log error messages from service startup led me
down unwarranted rabbit holes.

I thought I was deploying the most stripped down instance with the bare
essentials from the horizon ui, in reality (thanks beisner) you can deploy
an even more stripped down instance (without a block device) from the
command line with the command `openstack server create foo --flavor
 --image `.

Deploying an instance without a block device allowed us to bypass the
block_device_mapping error and get the real underlying traceback [1].

Massive thanks to Beisner for taking the time to talk through that with me,
and pointing out the command^ that led us to the real error.


~James

[0] https://paste.ubuntu.com/p/pTPh5vhBPp/
[1] https://paste.ubuntu.com/p/3XtxTTFXHM/


On Thu, Feb 15, 2018 at 7:49 AM, James Beedy <jamesbe...@gmail.com> wrote:

> Junaid and James,
>
>
> Thanks for the response. Here are the logs.
>
>
> Nova-Cloud-Controller
>
> $ cat /var/log/nova/nova-scheduler.log | http://paste.ubuntu.com/p/TQjD
> SXQSDt/
>
> $ cat /var/log/nova/nova-conductor.log | http://paste.ubuntu.com/p/68Tc
> mMCr82/
>
> $ sudo cat /var/log/nova/nova-api-os-compute.log |
> http://paste.ubuntu.com/p/5xWpXbD5PC/
>
>
> Neutron-Gateway
>
> $ sudo cat /var/log/neutron/neutron-metadata-agent.log  |
> http://paste.ubuntu.com/p/MW3qkQqntJ/
>
>
> $ sudo cat /var/log/neutron/neutron-openvswitch-agent.log |
> http://paste.ubuntu.com/p/qz3vfzG9b9/
>
>
> Neutron-api
>
> $ sudo cat /var/log/neutron/neutron-server.log |
> http://paste.ubuntu.com/p/sCCNw4bXtW/
>
> Thanks,
>
>
> James
>
>
> On Thu, Feb 15, 2018 at 7:24 AM, James Page <james.p...@ubuntu.com> wrote:
>
>> Hi James
>>
>> On Wed, 14 Feb 2018 at 20:22 James Beedy <jamesbe...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I am experiencing some issues with a base-openstack deploy.
>>>
>>> I can get a base-openstack to deploy legitimately using MAAS with no
>>> apparent errors from Juju's perspective. Following some init ops and the
>>> launching of an instance, I find myself stuck with errors I'm unsure how to
>>> diagnose. I upload an image, create my networks, flavors, and launch an
>>> instance, and see the instance erring out with a "host not found" error
>>> when I try to launch them.
>>>
>>> My nova/ceph node and neutron node interface configuration [0] all have
>>> a single flat 1G mgmt-net interface configured via MAAS, and vlans trunked
>>> in on enp4s0f0 (untracked by maas).
>>>
>>>
>>> Looking to the nova logs, I find [1] [2]
>>>
>>
>> You can ignore most of those errors - prior to the charm being fully
>> configured the daemons will log some error messages about broken db/rmq
>> etc...  newer reactive charms tend to disable services until config is
>> complete, older classic ones do not.
>>
>> The compute node is not recording and error which would indicate some
>> sort of scheduler problem - /var/log/nova/nova-scheduler.log from the
>> nova-cloud-controller would tell us more.
>>
>> The bundle I'm using [3] is lightly modified version of the openstack
>>> base bundle [4] with modifications to match my machine tags and mac
>>> addresses for my machines.
>>>
>>
>> Seems reasonable - bundles are meant as a start point after all!
>>
>> I've gone back and forth with network and charm config trying different
>>> combinations in hope this error is caused by some misconfiguration on my
>>> end, but I am now convinced this is something outside of my scope as an
>>> operator, and am hoping for some insight from the greater community.
>>>
>>> I seem to be able to reproduce this consistently (using both Juju <
>>> 2.3.2 and 2.3.2).
>>>
>>> Not even sure if I should create a bug somewhere as I'm not 100% sure
>>> this isn't my fault. Let me know if additional info is needed.
>>>
>>
>>  Lets dig into the scheduler log and see.
>>
>> Cheers
>>
>> James
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju Openstack - Blocked

[James Beedy]

I wanted to chime back in with the solution to the issue I was
experiencing.

The source of the issue undoubtedly was me. I was trying to launch a flavor
which had insufficient root-disk for a xenial.img (2G).

The the traceback which indicated the insufficient disk error was being
obfuscated by the user facing error I was seeing, block_device_mapping
error [0].
This alongside the erroneous log error messages from service startup led me
down unwarranted rabbit holes.

I thought I was deploying the most stripped down instance with the bare
essentials from the horizon ui, in reality (thanks beisner) you can deploy
an even more stripped down instance (without a block device) from the
command line with the command `openstack server create foo --flavor
 --image `.

Deploying an instance without a block device allowed us to bypass the
block_device_mapping error and get the real underlying traceback [1].

Massive thanks to Beisner for taking the time to talk through that with me,
and pointing out the command^ that led us to the real error.


~James

[0] https://paste.ubuntu.com/p/pTPh5vhBPp/
[1] https://paste.ubuntu.com/p/3XtxTTFXHM/


On Thu, Feb 15, 2018 at 7:49 AM, James Beedy <jamesbe...@gmail.com> wrote:

> Junaid and James,
>
>
> Thanks for the response. Here are the logs.
>
>
> Nova-Cloud-Controller
>
> $ cat /var/log/nova/nova-scheduler.log | http://paste.ubuntu.com/p/TQjD
> SXQSDt/
>
> $ cat /var/log/nova/nova-conductor.log | http://paste.ubuntu.com/p/68Tc
> mMCr82/
>
> $ sudo cat /var/log/nova/nova-api-os-compute.log |
> http://paste.ubuntu.com/p/5xWpXbD5PC/
>
>
> Neutron-Gateway
>
> $ sudo cat /var/log/neutron/neutron-metadata-agent.log  |
> http://paste.ubuntu.com/p/MW3qkQqntJ/
>
>
> $ sudo cat /var/log/neutron/neutron-openvswitch-agent.log |
> http://paste.ubuntu.com/p/qz3vfzG9b9/
>
>
> Neutron-api
>
> $ sudo cat /var/log/neutron/neutron-server.log |
> http://paste.ubuntu.com/p/sCCNw4bXtW/
>
> Thanks,
>
>
> James
>
>
> On Thu, Feb 15, 2018 at 7:24 AM, James Page <james.p...@ubuntu.com> wrote:
>
>> Hi James
>>
>> On Wed, 14 Feb 2018 at 20:22 James Beedy <jamesbe...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I am experiencing some issues with a base-openstack deploy.
>>>
>>> I can get a base-openstack to deploy legitimately using MAAS with no
>>> apparent errors from Juju's perspective. Following some init ops and the
>>> launching of an instance, I find myself stuck with errors I'm unsure how to
>>> diagnose. I upload an image, create my networks, flavors, and launch an
>>> instance, and see the instance erring out with a "host not found" error
>>> when I try to launch them.
>>>
>>> My nova/ceph node and neutron node interface configuration [0] all have
>>> a single flat 1G mgmt-net interface configured via MAAS, and vlans trunked
>>> in on enp4s0f0 (untracked by maas).
>>>
>>>
>>> Looking to the nova logs, I find [1] [2]
>>>
>>
>> You can ignore most of those errors - prior to the charm being fully
>> configured the daemons will log some error messages about broken db/rmq
>> etc...  newer reactive charms tend to disable services until config is
>> complete, older classic ones do not.
>>
>> The compute node is not recording and error which would indicate some
>> sort of scheduler problem - /var/log/nova/nova-scheduler.log from the
>> nova-cloud-controller would tell us more.
>>
>> The bundle I'm using [3] is lightly modified version of the openstack
>>> base bundle [4] with modifications to match my machine tags and mac
>>> addresses for my machines.
>>>
>>
>> Seems reasonable - bundles are meant as a start point after all!
>>
>> I've gone back and forth with network and charm config trying different
>>> combinations in hope this error is caused by some misconfiguration on my
>>> end, but I am now convinced this is something outside of my scope as an
>>> operator, and am hoping for some insight from the greater community.
>>>
>>> I seem to be able to reproduce this consistently (using both Juju <
>>> 2.3.2 and 2.3.2).
>>>
>>> Not even sure if I should create a bug somewhere as I'm not 100% sure
>>> this isn't my fault. Let me know if additional info is needed.
>>>
>>
>>  Lets dig into the scheduler log and see.
>>
>> Cheers
>>
>> James
>>
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju Openstack - Blocked

[James Beedy]

Junaid and James,


Thanks for the response. Here are the logs.


Nova-Cloud-Controller

$ cat /var/log/nova/nova-scheduler.log |
http://paste.ubuntu.com/p/TQjDSXQSDt/

$ cat /var/log/nova/nova-conductor.log |
http://paste.ubuntu.com/p/68TcmMCr82/

$ sudo cat /var/log/nova/nova-api-os-compute.log |
http://paste.ubuntu.com/p/5xWpXbD5PC/


Neutron-Gateway

$ sudo cat /var/log/neutron/neutron-metadata-agent.log  |
http://paste.ubuntu.com/p/MW3qkQqntJ/


$ sudo cat /var/log/neutron/neutron-openvswitch-agent.log |
http://paste.ubuntu.com/p/qz3vfzG9b9/


Neutron-api

$ sudo cat /var/log/neutron/neutron-server.log |
http://paste.ubuntu.com/p/sCCNw4bXtW/

Thanks,


James


On Thu, Feb 15, 2018 at 7:24 AM, James Page <james.p...@ubuntu.com> wrote:

> Hi James
>
> On Wed, 14 Feb 2018 at 20:22 James Beedy <jamesbe...@gmail.com> wrote:
>
>> Hello,
>>
>> I am experiencing some issues with a base-openstack deploy.
>>
>> I can get a base-openstack to deploy legitimately using MAAS with no
>> apparent errors from Juju's perspective. Following some init ops and the
>> launching of an instance, I find myself stuck with errors I'm unsure how to
>> diagnose. I upload an image, create my networks, flavors, and launch an
>> instance, and see the instance erring out with a "host not found" error
>> when I try to launch them.
>>
>> My nova/ceph node and neutron node interface configuration [0] all have a
>> single flat 1G mgmt-net interface configured via MAAS, and vlans trunked in
>> on enp4s0f0 (untracked by maas).
>>
>>
>> Looking to the nova logs, I find [1] [2]
>>
>
> You can ignore most of those errors - prior to the charm being fully
> configured the daemons will log some error messages about broken db/rmq
> etc...  newer reactive charms tend to disable services until config is
> complete, older classic ones do not.
>
> The compute node is not recording and error which would indicate some sort
> of scheduler problem - /var/log/nova/nova-scheduler.log from the
> nova-cloud-controller would tell us more.
>
> The bundle I'm using [3] is lightly modified version of the openstack base
>> bundle [4] with modifications to match my machine tags and mac addresses
>> for my machines.
>>
>
> Seems reasonable - bundles are meant as a start point after all!
>
> I've gone back and forth with network and charm config trying different
>> combinations in hope this error is caused by some misconfiguration on my
>> end, but I am now convinced this is something outside of my scope as an
>> operator, and am hoping for some insight from the greater community.
>>
>> I seem to be able to reproduce this consistently (using both Juju < 2.3.2
>> and 2.3.2).
>>
>> Not even sure if I should create a bug somewhere as I'm not 100% sure
>> this isn't my fault. Let me know if additional info is needed.
>>
>
>  Lets dig into the scheduler log and see.
>
> Cheers
>
> James
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju Openstack - Blocked

[James Beedy]

Junaid and James,


Thanks for the response. Here are the logs.


Nova-Cloud-Controller

$ cat /var/log/nova/nova-scheduler.log |
http://paste.ubuntu.com/p/TQjDSXQSDt/

$ cat /var/log/nova/nova-conductor.log |
http://paste.ubuntu.com/p/68TcmMCr82/

$ sudo cat /var/log/nova/nova-api-os-compute.log |
http://paste.ubuntu.com/p/5xWpXbD5PC/


Neutron-Gateway

$ sudo cat /var/log/neutron/neutron-metadata-agent.log  |
http://paste.ubuntu.com/p/MW3qkQqntJ/


$ sudo cat /var/log/neutron/neutron-openvswitch-agent.log |
http://paste.ubuntu.com/p/qz3vfzG9b9/


Neutron-api

$ sudo cat /var/log/neutron/neutron-server.log |
http://paste.ubuntu.com/p/sCCNw4bXtW/

Thanks,


James


On Thu, Feb 15, 2018 at 7:24 AM, James Page <james.p...@ubuntu.com> wrote:

> Hi James
>
> On Wed, 14 Feb 2018 at 20:22 James Beedy <jamesbe...@gmail.com> wrote:
>
>> Hello,
>>
>> I am experiencing some issues with a base-openstack deploy.
>>
>> I can get a base-openstack to deploy legitimately using MAAS with no
>> apparent errors from Juju's perspective. Following some init ops and the
>> launching of an instance, I find myself stuck with errors I'm unsure how to
>> diagnose. I upload an image, create my networks, flavors, and launch an
>> instance, and see the instance erring out with a "host not found" error
>> when I try to launch them.
>>
>> My nova/ceph node and neutron node interface configuration [0] all have a
>> single flat 1G mgmt-net interface configured via MAAS, and vlans trunked in
>> on enp4s0f0 (untracked by maas).
>>
>>
>> Looking to the nova logs, I find [1] [2]
>>
>
> You can ignore most of those errors - prior to the charm being fully
> configured the daemons will log some error messages about broken db/rmq
> etc...  newer reactive charms tend to disable services until config is
> complete, older classic ones do not.
>
> The compute node is not recording and error which would indicate some sort
> of scheduler problem - /var/log/nova/nova-scheduler.log from the
> nova-cloud-controller would tell us more.
>
> The bundle I'm using [3] is lightly modified version of the openstack base
>> bundle [4] with modifications to match my machine tags and mac addresses
>> for my machines.
>>
>
> Seems reasonable - bundles are meant as a start point after all!
>
> I've gone back and forth with network and charm config trying different
>> combinations in hope this error is caused by some misconfiguration on my
>> end, but I am now convinced this is something outside of my scope as an
>> operator, and am hoping for some insight from the greater community.
>>
>> I seem to be able to reproduce this consistently (using both Juju < 2.3.2
>> and 2.3.2).
>>
>> Not even sure if I should create a bug somewhere as I'm not 100% sure
>> this isn't my fault. Let me know if additional info is needed.
>>
>
>  Lets dig into the scheduler log and see.
>
> Cheers
>
> James
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju Openstack - Blocked

[James Beedy]

Hello,

I am experiencing some issues with a base-openstack deploy.

I can get a base-openstack to deploy legitimately using MAAS with no
apparent errors from Juju's perspective. Following some init ops and the
launching of an instance, I find myself stuck with errors I'm unsure how to
diagnose. I upload an image, create my networks, flavors, and launch an
instance, and see the instance erring out with a "host not found" error
when I try to launch them.

My nova/ceph node and neutron node interface configuration [0] all have a
single flat 1G mgmt-net interface configured via MAAS, and vlans trunked in
on enp4s0f0 (untracked by maas).


Looking to the nova logs, I find [1] [2]


The bundle I'm using [3] is lightly modified version of the openstack base
bundle [4] with modifications to match my machine tags and mac addresses
for my machines.

I've gone back and forth with network and charm config trying different
combinations in hope this error is caused by some misconfiguration on my
end, but I am now convinced this is something outside of my scope as an
operator, and am hoping for some insight from the greater community.

I seem to be able to reproduce this consistently (using both Juju < 2.3.2
and 2.3.2).

Not even sure if I should create a bug somewhere as I'm not 100% sure this
isn't my fault. Let me know if additional info is needed.


Thanks,


James



[0] https://imgur.com/a/x62m9
[1] cat /var/log/nova/nova-api-metadata.log |
http://paste.ubuntu.com/p/cTSjjRnHQ8/
[2] cat /var/log/nova/nova-compute.log |
http://paste.ubuntu.com/p/YFnMs93xhG/
[3] https://paste.ubuntu.com/p/8hsQnmFYh4/
[4]
https://github.com/openstack-charmers/openstack-bundles/blob/master/stable/openstack-base/bundle.yaml
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju Openstack - Blocked

[James Beedy]

Hello,

I am experiencing some issues with a base-openstack deploy.

I can get a base-openstack to deploy legitimately using MAAS with no
apparent errors from Juju's perspective. Following some init ops and the
launching of an instance, I find myself stuck with errors I'm unsure how to
diagnose. I upload an image, create my networks, flavors, and launch an
instance, and see the instance erring out with a "host not found" error
when I try to launch them.

My nova/ceph node and neutron node interface configuration [0] all have a
single flat 1G mgmt-net interface configured via MAAS, and vlans trunked in
on enp4s0f0 (untracked by maas).


Looking to the nova logs, I find [1] [2]


The bundle I'm using [3] is lightly modified version of the openstack base
bundle [4] with modifications to match my machine tags and mac addresses
for my machines.

I've gone back and forth with network and charm config trying different
combinations in hope this error is caused by some misconfiguration on my
end, but I am now convinced this is something outside of my scope as an
operator, and am hoping for some insight from the greater community.

I seem to be able to reproduce this consistently (using both Juju < 2.3.2
and 2.3.2).

Not even sure if I should create a bug somewhere as I'm not 100% sure this
isn't my fault. Let me know if additional info is needed.


Thanks,


James



[0] https://imgur.com/a/x62m9
[1] cat /var/log/nova/nova-api-metadata.log |
http://paste.ubuntu.com/p/cTSjjRnHQ8/
[2] cat /var/log/nova/nova-compute.log |
http://paste.ubuntu.com/p/YFnMs93xhG/
[3] https://paste.ubuntu.com/p/8hsQnmFYh4/
[4]
https://github.com/openstack-charmers/openstack-bundles/blob/master/stable/openstack-base/bundle.yaml
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[charms][nova-compute] Services not running that should be: nova-api-metadata

[James Beedy]

Trying to bring up an Openstack, I keep hitting this issue where
nova-compute is giving a status "Services not running that should be:
nova-api-metadata" - are others hitting this?

juju status | https://paste.ubuntu.com/26480769/

Its possible something has changed in my infrastructure, but I feel like
when I deployed this same config last week I had a solid deploy with no
errors.

I know there are too many components and configuration to start
troubleshooting with this little detail, just thought I would check in
before diving in head first.

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

ownership and sharing of models via team namespace

[James Beedy]

Looking at the jujucharms page for my team namespace [0], I see a place
where models may be shared with the team. Is this something that is in the
works, or is there existing functionality where models can be shared
with/owned by a team?

Thanks

[0] https://imgur.com/a/7xint
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

ownership and sharing of models via team namespace

[James Beedy]

Looking at the jujucharms page for my team namespace [0], I see a place
where models may be shared with the team. Is this something that is in the
works, or is there existing functionality where models can be shared
with/owned by a team?

Thanks

[0] https://imgur.com/a/7xint
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Endpoints trials + MAAS charms

[James Beedy]

Oo  possibly I'm on to something (last item/very bottom)
https://imgur.com/a/6Wyd0

On Mon, Nov 27, 2017 at 5:53 AM, James Beedy <jamesbe...@gmail.com> wrote:

> | I can also see that it took a few attempts to get there (the last
> machine is #40 :)
>
> It was a trying process to say the least - possibly I am one of few users
> who would stick around to see it through. which is actually great
> because it creates a market for people to provide the service of providing
> MAAS!
>
> At least, with the MAAS charm, you can 1) create and add your vms, 2) juju
> deploy bundle, 3) profit.
>
> Instead of deploy #40 which is probably #100 by now + tears + 10 trips to
> the datacenter + 
>
>
> On Mon, Nov 27, 2017 at 5:31 AM, John Meinel <j...@arbash-meinel.com>
> wrote:
>
>> It does seem like Juju operating the LXD provider, but spanning multiple
>> machines would be an answer. I do believe that LXD itself is introducing
>> clustering into their API in the 18.04 cycle. Which would probably need
>> some updates on the Juju side to handle their targeted provisioning (create
>> a container for maas-postgresql on the 3rd machine in the LXD cluster).
>> But that might get you out of manual provisioning of a bunch of machines
>> and VMs to target everything.
>> We're certainly not at a point where you could just-do-that today.
>> I can also see that it took a few attempts to get there (the last machine
>> is #40 :)
>> John
>> =:->
>>
>>
>> On Mon, Nov 27, 2017 at 5:17 PM, James Beedy <jamesbe...@gmail.com>
>> wrote:
>>
>>> Dmitrii,
>>>
>>> Thanks for the response.
>>>
>>> When taking into account the overhead to get MAAS deployed as charms, it
>>> definitely makes the LXD provider method you have described seem very
>>> appealing. Some issues I've experienced trying to get MAAS HA deployed are
>>> such that it seems like just a ton of infrastructure is needed to get MAAS
>>> HA standing using the manual provider deploying the MAAS charms. You have
>>> to provision/maintain the manual Juju controller cluster underneath MAAS,
>>> just to have MAAS  ugh
>>>
>>> I found not only the sheer quantity of servers needed to get this
>>> working quite unnerving, but also the manual ops I had to undergo to get it
>>> all standing #snowflakes #custom.
>>>
>>> I iterated on this a few times to see if I could come up with something
>>> more manageable, and this is where I landed (brace yourself) [0]
>>>
>>> What's going on there?
>>>
>>> I created a model in JAAS, manually added 3 physical hosts across
>>> different racks, then bootstrapped 4 virtual machines on each physical host
>>> (1 vm for each postgresql, maas-region, maas-rack [1], juju-controller
>>> (juju controllers for maas provider, to be checked into maas)) on each host.
>>>
>>> I then also added my vms to my JAAS model so I could deploy the charms
>>> to them (just postgresql and ubuntu at the time - the MAAS stuff got
>>> manually installed and configured after the machiens had ubuntu deployed to
>>> them in the model).
>>>
>>> (ASIDE: I'm seeing I could probably do this one better by combining my
>>> region and rack controller to the same vm, and colocating the postgresql
>>> charm with the region+rack on the same vm, giving me ha of all components
>>> using single vm on each host.)
>>>
>>> I know there are probably a plethora of issues with what I've done here,
>>> but it solved a few primary issues that seemed to outweigh the misuse.
>>>
>>> The issues were:
>>>
>>> 1) Too many machines needed to get MAAS HA
>>> 2) Chicken or egg?
>>> 3) Snowflakes!!!
>>> 4) No clear path to support MAAS HA
>>>
>>> My idea behind this was such that by using JAAS I am solving the chicken
>>> or the egg issue, and reducing the machines/infra needed to get MAAS HA.
>>> Deploying the MAAS infra with Juju eliminates the snowflake/lack of
>>> tracking and chips at the "No clear path to support MAAS HA".
>>>
>>> Thanks,
>>>
>>> James
>>>
>>> [0] http://paste.ubuntu.com/25891429/
>>> [1] http://paste.ubuntu.com/26058033/
>>>
>>> On Mon, Nov 27, 2017 at 12:09 AM, Dmitrii Shcherbakov <
>>> dmitrii.shcherba...@canonical.com> wrote:
>>>
>>>> Hi James,
>>>>
>>>> This is an interesting approach, thanks for taking a

Re: Endpoints trials + MAAS charms

[James Beedy]

| I can also see that it took a few attempts to get there (the last machine
is #40 :)

It was a trying process to say the least - possibly I am one of few users
who would stick around to see it through. which is actually great
because it creates a market for people to provide the service of providing
MAAS!

At least, with the MAAS charm, you can 1) create and add your vms, 2) juju
deploy bundle, 3) profit.

Instead of deploy #40 which is probably #100 by now + tears + 10 trips to
the datacenter + 


On Mon, Nov 27, 2017 at 5:31 AM, John Meinel <j...@arbash-meinel.com> wrote:

> It does seem like Juju operating the LXD provider, but spanning multiple
> machines would be an answer. I do believe that LXD itself is introducing
> clustering into their API in the 18.04 cycle. Which would probably need
> some updates on the Juju side to handle their targeted provisioning (create
> a container for maas-postgresql on the 3rd machine in the LXD cluster).
> But that might get you out of manual provisioning of a bunch of machines
> and VMs to target everything.
> We're certainly not at a point where you could just-do-that today.
> I can also see that it took a few attempts to get there (the last machine
> is #40 :)
> John
> =:->
>
>
> On Mon, Nov 27, 2017 at 5:17 PM, James Beedy <jamesbe...@gmail.com> wrote:
>
>> Dmitrii,
>>
>> Thanks for the response.
>>
>> When taking into account the overhead to get MAAS deployed as charms, it
>> definitely makes the LXD provider method you have described seem very
>> appealing. Some issues I've experienced trying to get MAAS HA deployed are
>> such that it seems like just a ton of infrastructure is needed to get MAAS
>> HA standing using the manual provider deploying the MAAS charms. You have
>> to provision/maintain the manual Juju controller cluster underneath MAAS,
>> just to have MAAS  ugh
>>
>> I found not only the sheer quantity of servers needed to get this working
>> quite unnerving, but also the manual ops I had to undergo to get it all
>> standing #snowflakes #custom.
>>
>> I iterated on this a few times to see if I could come up with something
>> more manageable, and this is where I landed (brace yourself) [0]
>>
>> What's going on there?
>>
>> I created a model in JAAS, manually added 3 physical hosts across
>> different racks, then bootstrapped 4 virtual machines on each physical host
>> (1 vm for each postgresql, maas-region, maas-rack [1], juju-controller
>> (juju controllers for maas provider, to be checked into maas)) on each host.
>>
>> I then also added my vms to my JAAS model so I could deploy the charms to
>> them (just postgresql and ubuntu at the time - the MAAS stuff got manually
>> installed and configured after the machiens had ubuntu deployed to them in
>> the model).
>>
>> (ASIDE: I'm seeing I could probably do this one better by combining my
>> region and rack controller to the same vm, and colocating the postgresql
>> charm with the region+rack on the same vm, giving me ha of all components
>> using single vm on each host.)
>>
>> I know there are probably a plethora of issues with what I've done here,
>> but it solved a few primary issues that seemed to outweigh the misuse.
>>
>> The issues were:
>>
>> 1) Too many machines needed to get MAAS HA
>> 2) Chicken or egg?
>> 3) Snowflakes!!!
>> 4) No clear path to support MAAS HA
>>
>> My idea behind this was such that by using JAAS I am solving the chicken
>> or the egg issue, and reducing the machines/infra needed to get MAAS HA.
>> Deploying the MAAS infra with Juju eliminates the snowflake/lack of
>> tracking and chips at the "No clear path to support MAAS HA".
>>
>> Thanks,
>>
>> James
>>
>> [0] http://paste.ubuntu.com/25891429/
>> [1] http://paste.ubuntu.com/26058033/
>>
>> On Mon, Nov 27, 2017 at 12:09 AM, Dmitrii Shcherbakov <
>> dmitrii.shcherba...@canonical.com> wrote:
>>
>>> Hi James,
>>>
>>> This is an interesting approach, thanks for taking a shot at solving
>>> this problem!
>>>
>>> I thought of doing something similar a few months ago. The problematic
>>> aspect here is the assumption of having a provider/substrate already
>>> present for MAAS to be deployed - this is the chicken or the egg type of
>>> problem.
>>>
>>> If you would like to take the MAAS charm route, manual provider could be
>>> used with Juju to do that with pre-created hosts (which may be
>>> containers/VMs/hosts all in a single model with this provider, r

Re: Endpoints trials + MAAS charms

[James Beedy]

t
> up MAAS and then usage of Juju with charms for the rest of what you need.
>
>
> Best Regards,
> Dmitrii Shcherbakov
>
> Field Software Engineer
> IRC (freenode): Dmitrii-Sh
>
> On Sun, Nov 26, 2017 at 4:14 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
>> Hello all,
>>
>> I've got an HA maas setup at the datacenter, I had some trouble getting
>> the full HA bits super solid in the past, and thought it appropriate to try
>> charming up the new 2.3 MAAS snaps to see if I could make my life a bit
>> easier going forward.
>>
>> I just took a quick first swipe at this, so please excuse the lack of any
>> tests.
>>
>> I'm hoping I can kill 2 birds with 1 stone here by a) possibly getting
>> some feedback from @cory_fu on how I'm using the new Endpoints stuff
>> landing soon in reactive (and disseminate that feedback so others will be
>> in the know too), and b) possibly someone from @MAAS team might give me a
>> nod if the steps I've taken here look to be moving in the right direction?
>>
>> # Interface and layer
>> interface-maas: https://github.com/jamesbeedy/interface-maas
>> layer-maas: https://github.com/jamesbeedy/layer-maas
>>
>> # MAAS charm
>> charmstore: https://jujucharms.com/u/jamesbeedy/maas/8
>>
>> # Sample bundle
>> sample bundle: http://paste.ubuntu.com/26046016/ - (only for reference,
>> this won't actually deploy)
>>
>> # juju status
>> `juju status`: http://paste.ubuntu.com/26045880/
>>
>>
>> Thanks,
>>
>> James
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Endpoints trials + MAAS charms

[James Beedy]

Hello all,

I've got an HA maas setup at the datacenter, I had some trouble getting the
full HA bits super solid in the past, and thought it appropriate to try
charming up the new 2.3 MAAS snaps to see if I could make my life a bit
easier going forward.

I just took a quick first swipe at this, so please excuse the lack of any
tests.

I'm hoping I can kill 2 birds with 1 stone here by a) possibly getting some
feedback from @cory_fu on how I'm using the new Endpoints stuff landing
soon in reactive (and disseminate that feedback so others will be in the
know too), and b) possibly someone from @MAAS team might give me a nod if
the steps I've taken here look to be moving in the right direction?

# Interface and layer
interface-maas: https://github.com/jamesbeedy/interface-maas
layer-maas: https://github.com/jamesbeedy/layer-maas

# MAAS charm
charmstore: https://jujucharms.com/u/jamesbeedy/maas/8

# Sample bundle
sample bundle: http://paste.ubuntu.com/26046016/ - (only for reference,
this won't actually deploy)

# juju status
`juju status`: http://paste.ubuntu.com/26045880/


Thanks,

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

Re: using the juju client from jenkins

[James Beedy]

Konstantinos,

Thanks for that. I need to get CI/CD setup for my charms, that will be very
helpful to me very soon.

Possibly I didn't illuminate the issue I'm having correctly though.

1) I have a pdl-api charm, that manages the pdl-api.snap.
2) My CI/CD pipeline for the pdl-api has two steps; build, deploy.
- The build job tests the code and builds the snap, then passes the
built artifact to the deploy step.
- The deploy step basically takes the built snap and attaches it to the
pdl-api charm https://imgur.com/a/UiIg7

The issue at hand, is that my jenkins user token expires and I end up with
a failing deploy job http://paste.ubuntu.com/26019762/ .

To remedy this, I always have to `juju ssh jenkins/0; sudo -ui jenkins;
juju login`

Is this more clear?

Thanks






On Wed, Nov 22, 2017 at 2:17 AM, Konstantinos Tsakalozos <
kos.tsakalo...@canonical.com> wrote:

> Hi James,
>
> We build our charms, push them to the store on the edge channel, and
> then our tests run against what is on edge. With this approach the
> team can sync on a specific build revision instead of each one
> separately trying to rebuild the charm locally and reproduce any
> unexpected behaviour. As soon as we are happy with a build we just
> promote it to the next channel (beta,candidate or stable). You can
> find our work here:
> https://github.com/juju-solutions/kubernetes-jenkins/tree/master/charms
>
> Cheers,
> Konstantinos
>
> On Wed, Nov 22, 2017 at 2:21 AM, James Beedy <jamesbe...@gmail.com> wrote:
> > I've a feeling that the majority of the CI/CD I've left in my trails that
> > attaches a resource from jenkins via juju bash cli are probably not
> working.
> > The latest CI/CD I've setup runs `juju attach` from jenkins, and I have
> to
> > login to the jenkins shell and su to the jenkins user and login to be
> able
> > to run my deploy step in jenkins.
> >
> > Is there a way that people are doing the jenkins<->juju dance without
> > lib-juju?
> >
> > --
> > 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

using the juju client from jenkins

[James Beedy]

I've a feeling that the majority of the CI/CD I've left in my trails that
attaches a resource from jenkins via juju bash cli are probably not
working. The latest CI/CD I've setup runs `juju attach` from jenkins, and I
have to login to the jenkins shell and su to the jenkins user and login to
be able to run my deploy step in jenkins.

Is there a way that people are doing the jenkins<->juju dance without
lib-juju?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Serverless Model Type

[James Beedy]

Merlijn,

That is great insight, thank you!

The CAAS stuff incorporates some of these concepts already (I think), but
is pretty k8s specific while in the dev phase from my understanding.

Abstracting the CAAS charm and model to facilitate a more general
platform/job architecture so as it could be extended to better support
multiple platforms - this sounds like the golden ticket.


~James


On Thu, Nov 16, 2017 at 8:32 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> +1
>
> With some care, one solution could be used for both containers, serverless
> functions and more. We just need two new types of charms:
>
>  - A "platform" charm which connects to the serverless platform and
> deploys the function.
>  - A "job" charm which describes the function. This is basically a bundle
> of metadata.
>
> Connecting the `platform` to the `job` charm will cause a `job-joined`
> hook in the platform charm, which can then use `job-get` to get the
> metadata describing the function and deploy the function on the platform.
> This way, you empower the community to create new "platform" charms for
> whichever platforms they see fit: AWS lambda, Kubernetes, Heroku and even
> Apache Spark.
>
>  - Juju doesn't need to know the details of each platform because the
> connection to the platform is part of the charm.
>  - Juju doesn't need to know the details of each "job" type, because the
> "job" charm is just a bunch of metadata.
>
> Now add the ability for "job" charms to optionally include relation hooks,
> and you can seamlessly connect serverless functions to your existing
> infrastructure. Or connect Apache Spark jobs to your existing
> infrastructure.
>
> We've created a number of prototypes of this to model and deploy
> Kubernetes and Apache Storm topologies in Juju. We used normal charms and
> relations for our "platform" and "job" charms. This works really wel, the
> only issue is that deploying an entire Juju Agent is wy too much
> overhead for modeling a single Docker container, so we would be really
> happy if Juju could introduce the idea of "job" charms.
>
>
>
> Kind regards
> Merlijn
>
>
>
>
> 2017-11-16 17:04 GMT+01:00 James Beedy <jamesbe...@gmail.com>:
>
>> How do people feel about Juju supporting a serverless model type, and
>> serverless charm?
>>
>> Some innovative wrappers popping up that facilitate deploying lambda
>> functions:
>>   - `serverless deploy` - https://serverless.com/
>>   - `zappa deploy` - https://github.com/Miserlou/Zappa
>>
>> I feel like Juju has the proper constructs needed to support a SL model
>> type, and a special SL type charm.
>>
>> Just an idea, thought I would throw it out there
>>
>> Thoughts?
>>
>>
>> --
>> Juju-dev mailing list
>> juju-...@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Serverless Model Type

[James Beedy]

Merlijn,

That is great insight, thank you!

The CAAS stuff incorporates some of these concepts already (I think), but
is pretty k8s specific while in the dev phase from my understanding.

Abstracting the CAAS charm and model to facilitate a more general
platform/job architecture so as it could be extended to better support
multiple platforms - this sounds like the golden ticket.


~James


On Thu, Nov 16, 2017 at 8:32 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> +1
>
> With some care, one solution could be used for both containers, serverless
> functions and more. We just need two new types of charms:
>
>  - A "platform" charm which connects to the serverless platform and
> deploys the function.
>  - A "job" charm which describes the function. This is basically a bundle
> of metadata.
>
> Connecting the `platform` to the `job` charm will cause a `job-joined`
> hook in the platform charm, which can then use `job-get` to get the
> metadata describing the function and deploy the function on the platform.
> This way, you empower the community to create new "platform" charms for
> whichever platforms they see fit: AWS lambda, Kubernetes, Heroku and even
> Apache Spark.
>
>  - Juju doesn't need to know the details of each platform because the
> connection to the platform is part of the charm.
>  - Juju doesn't need to know the details of each "job" type, because the
> "job" charm is just a bunch of metadata.
>
> Now add the ability for "job" charms to optionally include relation hooks,
> and you can seamlessly connect serverless functions to your existing
> infrastructure. Or connect Apache Spark jobs to your existing
> infrastructure.
>
> We've created a number of prototypes of this to model and deploy
> Kubernetes and Apache Storm topologies in Juju. We used normal charms and
> relations for our "platform" and "job" charms. This works really wel, the
> only issue is that deploying an entire Juju Agent is wy too much
> overhead for modeling a single Docker container, so we would be really
> happy if Juju could introduce the idea of "job" charms.
>
>
>
> Kind regards
> Merlijn
>
>
>
>
> 2017-11-16 17:04 GMT+01:00 James Beedy <jamesbe...@gmail.com>:
>
>> How do people feel about Juju supporting a serverless model type, and
>> serverless charm?
>>
>> Some innovative wrappers popping up that facilitate deploying lambda
>> functions:
>>   - `serverless deploy` - https://serverless.com/
>>   - `zappa deploy` - https://github.com/Miserlou/Zappa
>>
>> I feel like Juju has the proper constructs needed to support a SL model
>> type, and a special SL type charm.
>>
>> Just an idea, thought I would throw it out there
>>
>> Thoughts?
>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Serverless Model Type

[James Beedy]

How do people feel about Juju supporting a serverless model type, and
serverless charm?

Some innovative wrappers popping up that facilitate deploying lambda
functions:
  - `serverless deploy` - https://serverless.com/
  - `zappa deploy` - https://github.com/Miserlou/Zappa

I feel like Juju has the proper constructs needed to support a SL model
type, and a special SL type charm.

Just an idea, thought I would throw it out there

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

Serverless Model Type

[James Beedy]

How do people feel about Juju supporting a serverless model type, and
serverless charm?

Some innovative wrappers popping up that facilitate deploying lambda
functions:
  - `serverless deploy` - https://serverless.com/
  - `zappa deploy` - https://github.com/Miserlou/Zappa

I feel like Juju has the proper constructs needed to support a SL model
type, and a special SL type charm.

Just an idea, thought I would throw it out there

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

how to bind to the default space in a bundle

[James Beedy]

Is it possible to accomplish the following using a bundle?

`juju deploy --bind "default-space db=db-space db-admin=admin-space" mysql`


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

how to bind to the default space in a bundle

[James Beedy]

Is it possible to accomplish the following using a bundle?

`juju deploy --bind "default-space db=db-space db-admin=admin-space" mysql`


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

Re: Juju Storage/MAAS

[James Beedy]

I’ve created this bug for further tracking 
https://bugs.launchpad.net/juju/+bug/1729127

> On Oct 31, 2017, at 7:59 PM, James Beedy <jamesbe...@gmail.com> wrote:
> 
> Yes, deploying without —storage results in a successful deploy. 
> 
>> On Oct 31, 2017, at 7:52 PM, Ian Booth <ian.bo...@canonical.com> wrote:
>> 
>> And just to ask the obvious: deploying without the --storage constraint 
>> results
>> in a successful deploy, albeit to a machine with maybe the wrong disk?
>> 
>> 
>>> On 01/11/17 10:51, James Beedy wrote:
>>> Ian,
>>> 
>>> So, I think I'm close here.
>>> 
>>> The filesytem/device layout on my node(s): https://imgur.com/a/Nzn2H
>>> 
>>> I have tagged the md0 device with the tag "raid0", then I have created the
>>> storage pool as you have specified.
>>> 
>>> `juju create-storage-pool ssd-disks maas tags=raid0`
>>> 
>>> Then ran the following command to deploy my charm [0], attaching storage as
>>> part of the command:
>>> 
>>> `juju deploy cs:~jamesbeedy/elasticsearch-27 --bind "cluster=vlan20
>>> public=mgmt-net" --storage data=ssd-disks,3T --constraints "tags=data"`
>>> 
>>> 
>>> The result is here: http://paste.ubuntu.com/25862190/
>>> 
>>> 
>>> Here machines 1 and 2 are deployed without the `--constraints`,
>>> http://paste.ubuntu.com/25862219/
>>> 
>>> 
>>> Am I missing something? Possibly like one more input to the `--storage` arg?
>>> 
>>> 
>>> Thanks
>>> 
>>> [0] https://jujucharms.com/u/jamesbeedy/elasticsearch/27
>>> 
>>>> On Tue, Oct 31, 2017 at 3:14 PM, Ian Booth <ian.bo...@canonical.com> wrote:
>>>> 
>>>> Thanks for raising the issue - we'll get the docs updated!
>>>> 
>>>>> On 01/11/17 07:44, James Beedy wrote:
>>>>> I knew it would be something simple and sensible :)
>>>>> 
>>>>> Thank you!
>>>>> 
>>>>> On Tue, Oct 31, 2017 at 2:38 PM, Ian Booth <ian.bo...@canonical.com>
>>>> wrote:
>>>>> 
>>>>>> Of the top of my head, you want to do something like:
>>>>>> 
>>>>>> $ juju create-storage-pool ssd-disks maas tags=ssd
>>>>>> $ juju deploy postgresql --storage pgdata=ssd-disks,32G
>>>>>> 
>>>>>> The above assumes you have tagged in MAAS any SSD disks with the "ssd"
>>>>>> tag. You
>>>>>> can select whatever criteria you want and whatever tags you want to use.
>>>>>> 
>>>>>> The deploy command above selects a MAAS node with a disk tagged "ssd"
>>>>>> which is
>>>>>> at least 32GB in size.
>>>>>> 
>>>>>> 
>>>>>>> On 01/11/17 07:04, James Beedy wrote:
>>>>>>> Trying to check out Juju storage capabilities on MAAS I found [0], but
>>>>>>> can't quite wrap my head around what the syntax might be to make it
>>>> work,
>>>>>>> and what the extent of the capability of the Juju storage features are
>>>>>> when
>>>>>>> used with MAAS.
>>>>>>> 
>>>>>>> Re-reading [0], and looking for anything else I can find on Juju
>>>> storage
>>>>>>> every day for a week now thinking it may click or I might find the
>>>> right
>>>>>>> doc,  but it hasn't, and I haven't.
>>>>>>> 
>>>>>>> I filed a bug with juju/docs here [1] .
>>>>>>> 
>>>>>>> Does anyone have an example of how to consume Juju storage using the
>>>> MAAS
>>>>>>> provider?
>>>>>>> 
>>>>>>> Thanks!
>>>>>>> 
>>>>>>> [0] https://jujucharms.com/docs/devel/charms-storage#maas-(maas)
>>>>>>> [1] https://github.com/juju/docs/issues/2251
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju Storage/MAAS

[James Beedy]

I’ve created this bug for further tracking 
https://bugs.launchpad.net/juju/+bug/1729127

> On Oct 31, 2017, at 7:59 PM, James Beedy <jamesbe...@gmail.com> wrote:
> 
> Yes, deploying without —storage results in a successful deploy. 
> 
>> On Oct 31, 2017, at 7:52 PM, Ian Booth <ian.bo...@canonical.com> wrote:
>> 
>> And just to ask the obvious: deploying without the --storage constraint 
>> results
>> in a successful deploy, albeit to a machine with maybe the wrong disk?
>> 
>> 
>>> On 01/11/17 10:51, James Beedy wrote:
>>> Ian,
>>> 
>>> So, I think I'm close here.
>>> 
>>> The filesytem/device layout on my node(s): https://imgur.com/a/Nzn2H
>>> 
>>> I have tagged the md0 device with the tag "raid0", then I have created the
>>> storage pool as you have specified.
>>> 
>>> `juju create-storage-pool ssd-disks maas tags=raid0`
>>> 
>>> Then ran the following command to deploy my charm [0], attaching storage as
>>> part of the command:
>>> 
>>> `juju deploy cs:~jamesbeedy/elasticsearch-27 --bind "cluster=vlan20
>>> public=mgmt-net" --storage data=ssd-disks,3T --constraints "tags=data"`
>>> 
>>> 
>>> The result is here: http://paste.ubuntu.com/25862190/
>>> 
>>> 
>>> Here machines 1 and 2 are deployed without the `--constraints`,
>>> http://paste.ubuntu.com/25862219/
>>> 
>>> 
>>> Am I missing something? Possibly like one more input to the `--storage` arg?
>>> 
>>> 
>>> Thanks
>>> 
>>> [0] https://jujucharms.com/u/jamesbeedy/elasticsearch/27
>>> 
>>>> On Tue, Oct 31, 2017 at 3:14 PM, Ian Booth <ian.bo...@canonical.com> wrote:
>>>> 
>>>> Thanks for raising the issue - we'll get the docs updated!
>>>> 
>>>>> On 01/11/17 07:44, James Beedy wrote:
>>>>> I knew it would be something simple and sensible :)
>>>>> 
>>>>> Thank you!
>>>>> 
>>>>> On Tue, Oct 31, 2017 at 2:38 PM, Ian Booth <ian.bo...@canonical.com>
>>>> wrote:
>>>>> 
>>>>>> Of the top of my head, you want to do something like:
>>>>>> 
>>>>>> $ juju create-storage-pool ssd-disks maas tags=ssd
>>>>>> $ juju deploy postgresql --storage pgdata=ssd-disks,32G
>>>>>> 
>>>>>> The above assumes you have tagged in MAAS any SSD disks with the "ssd"
>>>>>> tag. You
>>>>>> can select whatever criteria you want and whatever tags you want to use.
>>>>>> 
>>>>>> The deploy command above selects a MAAS node with a disk tagged "ssd"
>>>>>> which is
>>>>>> at least 32GB in size.
>>>>>> 
>>>>>> 
>>>>>>> On 01/11/17 07:04, James Beedy wrote:
>>>>>>> Trying to check out Juju storage capabilities on MAAS I found [0], but
>>>>>>> can't quite wrap my head around what the syntax might be to make it
>>>> work,
>>>>>>> and what the extent of the capability of the Juju storage features are
>>>>>> when
>>>>>>> used with MAAS.
>>>>>>> 
>>>>>>> Re-reading [0], and looking for anything else I can find on Juju
>>>> storage
>>>>>>> every day for a week now thinking it may click or I might find the
>>>> right
>>>>>>> doc,  but it hasn't, and I haven't.
>>>>>>> 
>>>>>>> I filed a bug with juju/docs here [1] .
>>>>>>> 
>>>>>>> Does anyone have an example of how to consume Juju storage using the
>>>> MAAS
>>>>>>> provider?
>>>>>>> 
>>>>>>> Thanks!
>>>>>>> 
>>>>>>> [0] https://jujucharms.com/docs/devel/charms-storage#maas-(maas)
>>>>>>> [1] https://github.com/juju/docs/issues/2251
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju Storage/MAAS

[James Beedy]

Yes, deploying without —storage results in a successful deploy. 

> On Oct 31, 2017, at 7:52 PM, Ian Booth <ian.bo...@canonical.com> wrote:
> 
> And just to ask the obvious: deploying without the --storage constraint 
> results
> in a successful deploy, albeit to a machine with maybe the wrong disk?
> 
> 
>> On 01/11/17 10:51, James Beedy wrote:
>> Ian,
>> 
>> So, I think I'm close here.
>> 
>> The filesytem/device layout on my node(s): https://imgur.com/a/Nzn2H
>> 
>> I have tagged the md0 device with the tag "raid0", then I have created the
>> storage pool as you have specified.
>> 
>> `juju create-storage-pool ssd-disks maas tags=raid0`
>> 
>> Then ran the following command to deploy my charm [0], attaching storage as
>> part of the command:
>> 
>> `juju deploy cs:~jamesbeedy/elasticsearch-27 --bind "cluster=vlan20
>> public=mgmt-net" --storage data=ssd-disks,3T --constraints "tags=data"`
>> 
>> 
>> The result is here: http://paste.ubuntu.com/25862190/
>> 
>> 
>> Here machines 1 and 2 are deployed without the `--constraints`,
>> http://paste.ubuntu.com/25862219/
>> 
>> 
>> Am I missing something? Possibly like one more input to the `--storage` arg?
>> 
>> 
>> Thanks
>> 
>> [0] https://jujucharms.com/u/jamesbeedy/elasticsearch/27
>> 
>>> On Tue, Oct 31, 2017 at 3:14 PM, Ian Booth <ian.bo...@canonical.com> wrote:
>>> 
>>> Thanks for raising the issue - we'll get the docs updated!
>>> 
>>>> On 01/11/17 07:44, James Beedy wrote:
>>>> I knew it would be something simple and sensible :)
>>>> 
>>>> Thank you!
>>>> 
>>>> On Tue, Oct 31, 2017 at 2:38 PM, Ian Booth <ian.bo...@canonical.com>
>>> wrote:
>>>> 
>>>>> Of the top of my head, you want to do something like:
>>>>> 
>>>>> $ juju create-storage-pool ssd-disks maas tags=ssd
>>>>> $ juju deploy postgresql --storage pgdata=ssd-disks,32G
>>>>> 
>>>>> The above assumes you have tagged in MAAS any SSD disks with the "ssd"
>>>>> tag. You
>>>>> can select whatever criteria you want and whatever tags you want to use.
>>>>> 
>>>>> The deploy command above selects a MAAS node with a disk tagged "ssd"
>>>>> which is
>>>>> at least 32GB in size.
>>>>> 
>>>>> 
>>>>>> On 01/11/17 07:04, James Beedy wrote:
>>>>>> Trying to check out Juju storage capabilities on MAAS I found [0], but
>>>>>> can't quite wrap my head around what the syntax might be to make it
>>> work,
>>>>>> and what the extent of the capability of the Juju storage features are
>>>>> when
>>>>>> used with MAAS.
>>>>>> 
>>>>>> Re-reading [0], and looking for anything else I can find on Juju
>>> storage
>>>>>> every day for a week now thinking it may click or I might find the
>>> right
>>>>>> doc,  but it hasn't, and I haven't.
>>>>>> 
>>>>>> I filed a bug with juju/docs here [1] .
>>>>>> 
>>>>>> Does anyone have an example of how to consume Juju storage using the
>>> MAAS
>>>>>> provider?
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> [0] https://jujucharms.com/docs/devel/charms-storage#maas-(maas)
>>>>>> [1] https://github.com/juju/docs/issues/2251
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 

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

Re: Juju Storage/MAAS

[James Beedy]

Yes, deploying without —storage results in a successful deploy. 

> On Oct 31, 2017, at 7:52 PM, Ian Booth <ian.bo...@canonical.com> wrote:
> 
> And just to ask the obvious: deploying without the --storage constraint 
> results
> in a successful deploy, albeit to a machine with maybe the wrong disk?
> 
> 
>> On 01/11/17 10:51, James Beedy wrote:
>> Ian,
>> 
>> So, I think I'm close here.
>> 
>> The filesytem/device layout on my node(s): https://imgur.com/a/Nzn2H
>> 
>> I have tagged the md0 device with the tag "raid0", then I have created the
>> storage pool as you have specified.
>> 
>> `juju create-storage-pool ssd-disks maas tags=raid0`
>> 
>> Then ran the following command to deploy my charm [0], attaching storage as
>> part of the command:
>> 
>> `juju deploy cs:~jamesbeedy/elasticsearch-27 --bind "cluster=vlan20
>> public=mgmt-net" --storage data=ssd-disks,3T --constraints "tags=data"`
>> 
>> 
>> The result is here: http://paste.ubuntu.com/25862190/
>> 
>> 
>> Here machines 1 and 2 are deployed without the `--constraints`,
>> http://paste.ubuntu.com/25862219/
>> 
>> 
>> Am I missing something? Possibly like one more input to the `--storage` arg?
>> 
>> 
>> Thanks
>> 
>> [0] https://jujucharms.com/u/jamesbeedy/elasticsearch/27
>> 
>>> On Tue, Oct 31, 2017 at 3:14 PM, Ian Booth <ian.bo...@canonical.com> wrote:
>>> 
>>> Thanks for raising the issue - we'll get the docs updated!
>>> 
>>>> On 01/11/17 07:44, James Beedy wrote:
>>>> I knew it would be something simple and sensible :)
>>>> 
>>>> Thank you!
>>>> 
>>>> On Tue, Oct 31, 2017 at 2:38 PM, Ian Booth <ian.bo...@canonical.com>
>>> wrote:
>>>> 
>>>>> Of the top of my head, you want to do something like:
>>>>> 
>>>>> $ juju create-storage-pool ssd-disks maas tags=ssd
>>>>> $ juju deploy postgresql --storage pgdata=ssd-disks,32G
>>>>> 
>>>>> The above assumes you have tagged in MAAS any SSD disks with the "ssd"
>>>>> tag. You
>>>>> can select whatever criteria you want and whatever tags you want to use.
>>>>> 
>>>>> The deploy command above selects a MAAS node with a disk tagged "ssd"
>>>>> which is
>>>>> at least 32GB in size.
>>>>> 
>>>>> 
>>>>>> On 01/11/17 07:04, James Beedy wrote:
>>>>>> Trying to check out Juju storage capabilities on MAAS I found [0], but
>>>>>> can't quite wrap my head around what the syntax might be to make it
>>> work,
>>>>>> and what the extent of the capability of the Juju storage features are
>>>>> when
>>>>>> used with MAAS.
>>>>>> 
>>>>>> Re-reading [0], and looking for anything else I can find on Juju
>>> storage
>>>>>> every day for a week now thinking it may click or I might find the
>>> right
>>>>>> doc,  but it hasn't, and I haven't.
>>>>>> 
>>>>>> I filed a bug with juju/docs here [1] .
>>>>>> 
>>>>>> Does anyone have an example of how to consume Juju storage using the
>>> MAAS
>>>>>> provider?
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> [0] https://jujucharms.com/docs/devel/charms-storage#maas-(maas)
>>>>>> [1] https://github.com/juju/docs/issues/2251
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 

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

Re: Juju Storage/MAAS

[James Beedy]

Ian,

So, I think I'm close here.

The filesytem/device layout on my node(s): https://imgur.com/a/Nzn2H

I have tagged the md0 device with the tag "raid0", then I have created the
storage pool as you have specified.

`juju create-storage-pool ssd-disks maas tags=raid0`

Then ran the following command to deploy my charm [0], attaching storage as
part of the command:

`juju deploy cs:~jamesbeedy/elasticsearch-27 --bind "cluster=vlan20
public=mgmt-net" --storage data=ssd-disks,3T --constraints "tags=data"`


The result is here: http://paste.ubuntu.com/25862190/


Here machines 1 and 2 are deployed without the `--constraints`,
http://paste.ubuntu.com/25862219/


Am I missing something? Possibly like one more input to the `--storage` arg?


Thanks

[0] https://jujucharms.com/u/jamesbeedy/elasticsearch/27

On Tue, Oct 31, 2017 at 3:14 PM, Ian Booth <ian.bo...@canonical.com> wrote:

> Thanks for raising the issue - we'll get the docs updated!
>
> On 01/11/17 07:44, James Beedy wrote:
> > I knew it would be something simple and sensible :)
> >
> > Thank you!
> >
> > On Tue, Oct 31, 2017 at 2:38 PM, Ian Booth <ian.bo...@canonical.com>
> wrote:
> >
> >> Of the top of my head, you want to do something like:
> >>
> >> $ juju create-storage-pool ssd-disks maas tags=ssd
> >> $ juju deploy postgresql --storage pgdata=ssd-disks,32G
> >>
> >> The above assumes you have tagged in MAAS any SSD disks with the "ssd"
> >> tag. You
> >> can select whatever criteria you want and whatever tags you want to use.
> >>
> >> The deploy command above selects a MAAS node with a disk tagged "ssd"
> >> which is
> >> at least 32GB in size.
> >>
> >>
> >> On 01/11/17 07:04, James Beedy wrote:
> >>> Trying to check out Juju storage capabilities on MAAS I found [0], but
> >>> can't quite wrap my head around what the syntax might be to make it
> work,
> >>> and what the extent of the capability of the Juju storage features are
> >> when
> >>> used with MAAS.
> >>>
> >>> Re-reading [0], and looking for anything else I can find on Juju
> storage
> >>> every day for a week now thinking it may click or I might find the
> right
> >>> doc,  but it hasn't, and I haven't.
> >>>
> >>> I filed a bug with juju/docs here [1] .
> >>>
> >>> Does anyone have an example of how to consume Juju storage using the
> MAAS
> >>> provider?
> >>>
> >>> Thanks!
> >>>
> >>> [0] https://jujucharms.com/docs/devel/charms-storage#maas-(maas)
> >>> [1] https://github.com/juju/docs/issues/2251
> >>>
> >>>
> >>>
> >>
> >
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju Storage/MAAS

[James Beedy]

I knew it would be something simple and sensible :)

Thank you!

On Tue, Oct 31, 2017 at 2:38 PM, Ian Booth <ian.bo...@canonical.com> wrote:

> Of the top of my head, you want to do something like:
>
> $ juju create-storage-pool ssd-disks maas tags=ssd
> $ juju deploy postgresql --storage pgdata=ssd-disks,32G
>
> The above assumes you have tagged in MAAS any SSD disks with the "ssd"
> tag. You
> can select whatever criteria you want and whatever tags you want to use.
>
> The deploy command above selects a MAAS node with a disk tagged "ssd"
> which is
> at least 32GB in size.
>
>
> On 01/11/17 07:04, James Beedy wrote:
> > Trying to check out Juju storage capabilities on MAAS I found [0], but
> > can't quite wrap my head around what the syntax might be to make it work,
> > and what the extent of the capability of the Juju storage features are
> when
> > used with MAAS.
> >
> > Re-reading [0], and looking for anything else I can find on Juju storage
> > every day for a week now thinking it may click or I might find the right
> > doc,  but it hasn't, and I haven't.
> >
> > I filed a bug with juju/docs here [1] .
> >
> > Does anyone have an example of how to consume Juju storage using the MAAS
> > provider?
> >
> > Thanks!
> >
> > [0] https://jujucharms.com/docs/devel/charms-storage#maas-(maas)
> > [1] https://github.com/juju/docs/issues/2251
> >
> >
> >
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju Storage/MAAS

[James Beedy]

I knew it would be something simple and sensible :)

Thank you!

On Tue, Oct 31, 2017 at 2:38 PM, Ian Booth <ian.bo...@canonical.com> wrote:

> Of the top of my head, you want to do something like:
>
> $ juju create-storage-pool ssd-disks maas tags=ssd
> $ juju deploy postgresql --storage pgdata=ssd-disks,32G
>
> The above assumes you have tagged in MAAS any SSD disks with the "ssd"
> tag. You
> can select whatever criteria you want and whatever tags you want to use.
>
> The deploy command above selects a MAAS node with a disk tagged "ssd"
> which is
> at least 32GB in size.
>
>
> On 01/11/17 07:04, James Beedy wrote:
> > Trying to check out Juju storage capabilities on MAAS I found [0], but
> > can't quite wrap my head around what the syntax might be to make it work,
> > and what the extent of the capability of the Juju storage features are
> when
> > used with MAAS.
> >
> > Re-reading [0], and looking for anything else I can find on Juju storage
> > every day for a week now thinking it may click or I might find the right
> > doc,  but it hasn't, and I haven't.
> >
> > I filed a bug with juju/docs here [1] .
> >
> > Does anyone have an example of how to consume Juju storage using the MAAS
> > provider?
> >
> > Thanks!
> >
> > [0] https://jujucharms.com/docs/devel/charms-storage#maas-(maas)
> > [1] https://github.com/juju/docs/issues/2251
> >
> >
> >
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju Storage/MAAS

[James Beedy]

Trying to check out Juju storage capabilities on MAAS I found [0], but
can't quite wrap my head around what the syntax might be to make it work,
and what the extent of the capability of the Juju storage features are when
used with MAAS.

Re-reading [0], and looking for anything else I can find on Juju storage
every day for a week now thinking it may click or I might find the right
doc,  but it hasn't, and I haven't.

I filed a bug with juju/docs here [1] .

Does anyone have an example of how to consume Juju storage using the MAAS
provider?

Thanks!

[0] https://jujucharms.com/docs/devel/charms-storage#maas-(maas)
[1] https://github.com/juju/docs/issues/2251
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Juju Storage/MAAS

[James Beedy]

Trying to check out Juju storage capabilities on MAAS I found [0], but
can't quite wrap my head around what the syntax might be to make it work,
and what the extent of the capability of the Juju storage features are when
used with MAAS.

Re-reading [0], and looking for anything else I can find on Juju storage
every day for a week now thinking it may click or I might find the right
doc,  but it hasn't, and I haven't.

I filed a bug with juju/docs here [1] .

Does anyone have an example of how to consume Juju storage using the MAAS
provider?

Thanks!

[0] https://jujucharms.com/docs/devel/charms-storage#maas-(maas)
[1] https://github.com/juju/docs/issues/2251
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New Endpoints Implementation/New Elasticsearch Charm

[James Beedy]

Whoops srry 
> Nice work on this @cory!
 - s/cory/everyone involved/
> On Oct 29, 2017, at 4:30 PM, James Beedy <jamesbe...@gmail.com> wrote:
> 
> I carved out what seems to be some solid ground on the new Elasticsearch 
> rewrite using the new endpoints implementation. 
> 
> Assuming I'm using this correctly, I found the new endpoints implementation 
> to give for a really smooth experience. Nice work on this @cory!
> 
> Wondering if I could get some feedback on whether I'm actually using it 
> correctly, or screwing anything up.
> 
> Here are the components 
> * Charm github repo - https://github.com/jamesbeedy/layer-elasticsearch
> * host-port interface - https://github.com/jamesbeedy/interface-host-port
> * Elasticsearch charm - https://jujucharms.com/u/jamesbeedy/elasticsearch/18
> * Charmstore Bundle - 
> https://jujucharms.com/u/jamesbeedy/elasticsearch-non-uniform/2
> 
> Deploying ^ bundle should give you http://paste.ubuntu.com/25848402/
> 
> Thanks!
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

New Endpoints Implementation/New Elasticsearch Charm

[James Beedy]

I carved out what seems to be some solid ground on the new Elasticsearch
rewrite using the new endpoints implementation.

Assuming I'm using this correctly, I found the new endpoints implementation
to give for a really smooth experience. Nice work on this @cory!

Wondering if I could get some feedback on whether I'm actually using it
correctly, or screwing anything up.

Here are the components
* Charm github repo - https://github.com/jamesbeedy/layer-elasticsearch
* host-port interface - https://github.com/jamesbeedy/interface-host-port
* Elasticsearch charm - https://jujucharms.com/u/jamesbeedy/elasticsearch/18
* Charmstore Bundle -
https://jujucharms.com/u/jamesbeedy/elasticsearch-non-uniform/2

Deploying ^ bundle should give you http://paste.ubuntu.com/25848402/

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

Re: default network space

[James Beedy]

I can give a high level of what I feel is a reasonably common use case.

I have infrastructure in two primary locations; AWS, and MAAS (at the local
datacenter). The nodes at the datacenter have a direct fiber route via
virtual private gateway in us-west-2, and the instances in AWS/us-west-2
have a direct route  via the VPG to the private MAAS networks at the
datacenter. There is no charge for data transfer from the datacenter in and
out of us-west-2 via the fiber VPG hot route, so it behooves me to use this
and have the AWS instances and MAAS instances talk to each other via
private address.

At the application level, the component/config goes something like this:

The MAAS nodes at the data center have mgmt-net, cluster-net, and
access-net, interfaces defined, all of which get ips from their respective
address spaces from the datacenter MAAS.

I need my elasticsearch charm to configure elasticsearch such that
elasticsearch <-> elasticsearch talk on cluster-net, web server (AWS
instance) -> elasticsearch to talk across the correct space for the AWS
instance, and the access-net space for the MAAS instance (I'm thinking this
is where bindings and '--via' might come in handy).

(I know the openstack charms have to make similar network mitigation, for
which they use the bindings, I must just be looking at it backwards, or not
looking into network bindings which are the key here I think)

For example, my web server charm in AWS will be deployed to a NAT
space/subnet, and will only get a private ip from the AWS subnet. It needs
to give the ip to elasticsearch (deployed in MAAS), and to a loadbalancer
(deploy to different model and space in the same AWS VPC) - this all seems
like there should be no issues with getting it to happen because the web
server charm only has a single ip address to be handing out, but what I'm
after here is a consistent way to be able to retrieve this information at
the charm level - but I think what you are telling me is that if I use the
functionality correctly, then I won't have to do any mitigating at the
charm/network-get level.

Looks like I need to take a deeper dive into the network bindings at the
charm level and see how that functionality fits into the bigger picture to
make the whole picture make sense.

Thanks



> I'd like to understand the use case you have in mind a little better. The
> premise of the network-get output is that charms should not think about
> public
> vs private addresses in terms of what to put into relation data - the other
> remote unit should not be exposed to things in those terms.
>
> There's some doc here to explain things in more detail
>
> https://jujucharms.com/docs/master/developer-network-primitives
>
> The TL;DR: is that charms need to care about:
> - what address do I bind to (listen on)
> - what address do external actors use to connect to me (ingress)
>
> Depending on how the charm has been deployed, and more specifically
> whether it
> is in a cross model relation, the ingress address might be either the
> public or
> private address. Juju will decide based on a number of factors (whether
> models
> are deployed to same region, vpc, other provider specific aspects) and
> populate
> the network-get data accordingly. NOTE: for now Juju will always pick the
> public
> address (if there is one) for the ingress value for cross model relations
> - the
> algorithm to short circuit to a cloud local address is not yet finished.
>
> The content of the bind-addresses block is space aware in that these are
> filtered based on the space with which the specified endpoint is
> associated. The
> network-get output though should not include any space information
> explicitly -
> this is a concern which a charm should not care about.
>
>
> On 12/10/17 13:35, James Beedy wrote:
> > Hello all,
> >
> > In case you haven't noticed, we now have a network_get() function
> available
> > in charmhelpers.core.hookenv (in master, not stable).
> >
> > Just wanted to have a little discussion about how we are going to be
> > parsing network_get().
> >
> > I first want to address the output of network_get() for an instance
> > deployed to the default vpc, no spaces constraint, and related to another
> > instance in another model also default vpc, no spaces constraint.
> >
> > {'ingress-addresses': ['107.22.129.65'], 'bind-addresses': [{'addresses':
> > [{'cidr': '172.31.48.0/20', 'address': '172.31.51.59'}],
> 'interfacename':
> > 'eth0', 'macaddress': '12:ba:53:58:9c:52'}, {'addresses': [{'cidr': '
> > 252.48.0.0/12', 'address': '252.51.59.1'}], 'interfacename': 'fan-252',
> > 'macaddress': '1e:a2:1e:96:ec:a2'}]}
> >
> >
> > The use case I have in mind here is such that I want to provide the
> private
> > ne

Re: default network space

[James Beedy]

I can give a high level of what I feel is a reasonably common use case.

I have infrastructure in two primary locations; AWS, and MAAS (at the local
datacenter). The nodes at the datacenter have a direct fiber route via
virtual private gateway in us-west-2, and the instances in AWS/us-west-2
have a direct route  via the VPG to the private MAAS networks at the
datacenter. There is no charge for data transfer from the datacenter in and
out of us-west-2 via the fiber VPG hot route, so it behooves me to use this
and have the AWS instances and MAAS instances talk to each other via
private address.

At the application level, the component/config goes something like this:

The MAAS nodes at the data center have mgmt-net, cluster-net, and
access-net, interfaces defined, all of which get ips from their respective
address spaces from the datacenter MAAS.

I need my elasticsearch charm to configure elasticsearch such that
elasticsearch <-> elasticsearch talk on cluster-net, web server (AWS
instance) -> elasticsearch to talk across the correct space for the AWS
instance, and the access-net space for the MAAS instance (I'm thinking this
is where bindings and '--via' might come in handy).

(I know the openstack charms have to make similar network mitigation, for
which they use the bindings, I must just be looking at it backwards, or not
looking into network bindings which are the key here I think)

For example, my web server charm in AWS will be deployed to a NAT
space/subnet, and will only get a private ip from the AWS subnet. It needs
to give the ip to elasticsearch (deployed in MAAS), and to a loadbalancer
(deploy to different model and space in the same AWS VPC) - this all seems
like there should be no issues with getting it to happen because the web
server charm only has a single ip address to be handing out, but what I'm
after here is a consistent way to be able to retrieve this information at
the charm level - but I think what you are telling me is that if I use the
functionality correctly, then I won't have to do any mitigating at the
charm/network-get level.

Looks like I need to take a deeper dive into the network bindings at the
charm level and see how that functionality fits into the bigger picture to
make the whole picture make sense.

Thanks



> I'd like to understand the use case you have in mind a little better. The
> premise of the network-get output is that charms should not think about
> public
> vs private addresses in terms of what to put into relation data - the other
> remote unit should not be exposed to things in those terms.
>
> There's some doc here to explain things in more detail
>
> https://jujucharms.com/docs/master/developer-network-primitives
>
> The TL;DR: is that charms need to care about:
> - what address do I bind to (listen on)
> - what address do external actors use to connect to me (ingress)
>
> Depending on how the charm has been deployed, and more specifically
> whether it
> is in a cross model relation, the ingress address might be either the
> public or
> private address. Juju will decide based on a number of factors (whether
> models
> are deployed to same region, vpc, other provider specific aspects) and
> populate
> the network-get data accordingly. NOTE: for now Juju will always pick the
> public
> address (if there is one) for the ingress value for cross model relations
> - the
> algorithm to short circuit to a cloud local address is not yet finished.
>
> The content of the bind-addresses block is space aware in that these are
> filtered based on the space with which the specified endpoint is
> associated. The
> network-get output though should not include any space information
> explicitly -
> this is a concern which a charm should not care about.
>
>
> On 12/10/17 13:35, James Beedy wrote:
> > Hello all,
> >
> > In case you haven't noticed, we now have a network_get() function
> available
> > in charmhelpers.core.hookenv (in master, not stable).
> >
> > Just wanted to have a little discussion about how we are going to be
> > parsing network_get().
> >
> > I first want to address the output of network_get() for an instance
> > deployed to the default vpc, no spaces constraint, and related to another
> > instance in another model also default vpc, no spaces constraint.
> >
> > {'ingress-addresses': ['107.22.129.65'], 'bind-addresses': [{'addresses':
> > [{'cidr': '172.31.48.0/20', 'address': '172.31.51.59'}],
> 'interfacename':
> > 'eth0', 'macaddress': '12:ba:53:58:9c:52'}, {'addresses': [{'cidr': '
> > 252.48.0.0/12', 'address': '252.51.59.1'}], 'interfacename': 'fan-252',
> > 'macaddress': '1e:a2:1e:96:ec:a2'}]}
> >
> >
> > The use case I have in mind here is such that I want to provide the
> private
> > ne

default network space

[James Beedy]

Hello all,

In case you haven't noticed, we now have a network_get() function available
in charmhelpers.core.hookenv (in master, not stable).

Just wanted to have a little discussion about how we are going to be
parsing network_get().

I first want to address the output of network_get() for an instance
deployed to the default vpc, no spaces constraint, and related to another
instance in another model also default vpc, no spaces constraint.

{'ingress-addresses': ['107.22.129.65'], 'bind-addresses': [{'addresses':
[{'cidr': '172.31.48.0/20', 'address': '172.31.51.59'}], 'interfacename':
'eth0', 'macaddress': '12:ba:53:58:9c:52'}, {'addresses': [{'cidr': '
252.48.0.0/12', 'address': '252.51.59.1'}], 'interfacename': 'fan-252',
'macaddress': '1e:a2:1e:96:ec:a2'}]}


The use case I have in mind here is such that I want to provide the private
network interface address via relation data in the provides.py of my
interface to the relating appliication.

This will be able to happen by calling
hookenv.network_get('') in the layer that provides the
interface in my charm, and passing the output to get the private interface
ip data, to then set that in the provides side of the relation.

Tracking?

The problem:

The problem is such that its not so straight forward to just get the
private address from the output of network_get().

As you can see above, I could filter for network interface name, but thats
about the least best way one could go about this.

Initially, I assumed the network_get() output would look different if you
had specified a spaces constraint when deploying your application, but the
output was similar to no spaces, e.g. spaces aren't listed in the output of
network_get().


All in all, what I'm after is a consistent way to grep either the space an
interface is bound to, or to get the public vs private address from the
output of network_get(), I think this is true for every provider just about
(ones that use spaces at least).

Instead of the dict above, I was thinking we might namespace the interfaces
inside of what type of interface they are to make it easier to decipher
when parsing the network_get().

My idea is a schema like the following:

{
'private-networks': {
'my-admin-space': {
'addresses': [
{
'cidr': '172.31.48.0/20',
'address': '172.31.51.59'
}
],
'interfacename': 'eth0',
'macaddress': '12:ba:53:58:9c:52'
}
'public-networks': {
'default': {
'addresses': [
{
'cidr': 'publicipaddress/32',
'address': 'publicipaddress'
}
],
}
'fan-networks': {
'fan-252': {


}
}

Where all interfaces bound to spaces are considered private addresses, and
with the assumption that if you don't specify a space constraint, your
private network interface is bound to the "default" space.

The key thing here is the schema structure grouping the interfaces bound to
spaces inside a private-networks level in the dict, and the introduction of
the fact that if you don't specify a space, you get an address bound to an
artificial "default" space.

I feel this would make things easier to consume, and interface to from a
developer standpoint.

Is this making sense? How do others feel?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

default network space

[James Beedy]

Hello all,

In case you haven't noticed, we now have a network_get() function available
in charmhelpers.core.hookenv (in master, not stable).

Just wanted to have a little discussion about how we are going to be
parsing network_get().

I first want to address the output of network_get() for an instance
deployed to the default vpc, no spaces constraint, and related to another
instance in another model also default vpc, no spaces constraint.

{'ingress-addresses': ['107.22.129.65'], 'bind-addresses': [{'addresses':
[{'cidr': '172.31.48.0/20', 'address': '172.31.51.59'}], 'interfacename':
'eth0', 'macaddress': '12:ba:53:58:9c:52'}, {'addresses': [{'cidr': '
252.48.0.0/12', 'address': '252.51.59.1'}], 'interfacename': 'fan-252',
'macaddress': '1e:a2:1e:96:ec:a2'}]}


The use case I have in mind here is such that I want to provide the private
network interface address via relation data in the provides.py of my
interface to the relating appliication.

This will be able to happen by calling
hookenv.network_get('') in the layer that provides the
interface in my charm, and passing the output to get the private interface
ip data, to then set that in the provides side of the relation.

Tracking?

The problem:

The problem is such that its not so straight forward to just get the
private address from the output of network_get().

As you can see above, I could filter for network interface name, but thats
about the least best way one could go about this.

Initially, I assumed the network_get() output would look different if you
had specified a spaces constraint when deploying your application, but the
output was similar to no spaces, e.g. spaces aren't listed in the output of
network_get().


All in all, what I'm after is a consistent way to grep either the space an
interface is bound to, or to get the public vs private address from the
output of network_get(), I think this is true for every provider just about
(ones that use spaces at least).

Instead of the dict above, I was thinking we might namespace the interfaces
inside of what type of interface they are to make it easier to decipher
when parsing the network_get().

My idea is a schema like the following:

{
'private-networks': {
'my-admin-space': {
'addresses': [
{
'cidr': '172.31.48.0/20',
'address': '172.31.51.59'
}
],
'interfacename': 'eth0',
'macaddress': '12:ba:53:58:9c:52'
}
'public-networks': {
'default': {
'addresses': [
{
'cidr': 'publicipaddress/32',
'address': 'publicipaddress'
}
],
}
'fan-networks': {
'fan-252': {


}
}

Where all interfaces bound to spaces are considered private addresses, and
with the assumption that if you don't specify a space constraint, your
private network interface is bound to the "default" space.

The key thing here is the schema structure grouping the interfaces bound to
spaces inside a private-networks level in the dict, and the introduction of
the fact that if you don't specify a space, you get an address bound to an
artificial "default" space.

I feel this would make things easier to consume, and interface to from a
developer standpoint.

Is this making sense? How do others feel?
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

THE FAN - what providers support "provider" type

[James Beedy]

@wpk very exciting stuff here, and nice work!

One question, which providers support "provider" type FAN container
networking?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

THE FAN - what providers support "provider" type

[James Beedy]

@wpk very exciting stuff here, and nice work!

One question, which providers support "provider" type FAN container
networking?
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: upgrade-charm hook

[James Beedy]

That totally does! This sounds like a great path forward that would allow
us to eventually migrate away from having 'upgrade-charm' fire when a
resource is attached, while maintaining backward compat for the charms that
use it until its deprecated.

Well  I didn't mean to just imply that things should change to this ^
way, but it seems sensible. Possibly we could have more of a conversation
around this?

~James



On Tue, Sep 26, 2017 at 12:41 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Does a `resource.changed` flag address your needs? That should be possible
> to implement in charms.reactive, I think.
>
> 2017-09-24 17:53 GMT+02:00 James Beedy <jamesbe...@gmail.com>:
>
>> How do people feel about splitting the upgrade-charm hook into multiple
>> hooks to facilitate better resource management?
>>
>> What I'm thinking would be super helpful would be to have the
>> upgrade-charm hook still active for charm upgrades, and have separate hooks
>> or flags that would indicate resource upgrades.
>>
>> I'm thinking something like:
>>
>> 'juju attach myapp myresource=myresource.file'
>>
>> Would cause the 'upgrade-resource-myresource'  hook to become active on
>> instances of 'myapp'.
>>
>> I feel that having this affinity from resource ->
>> resource-upgrade- hook would be a huge win for resource
>> management.
>>
>> Thoughts?
>>
>>
>>
>>
>> --
>> Juju-dev mailing list
>> juju-...@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: upgrade-charm hook

[James Beedy]

That totally does! This sounds like a great path forward that would allow
us to eventually migrate away from having 'upgrade-charm' fire when a
resource is attached, while maintaining backward compat for the charms that
use it until its deprecated.

Well  I didn't mean to just imply that things should change to this ^
way, but it seems sensible. Possibly we could have more of a conversation
around this?

~James



On Tue, Sep 26, 2017 at 12:41 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Does a `resource.changed` flag address your needs? That should be possible
> to implement in charms.reactive, I think.
>
> 2017-09-24 17:53 GMT+02:00 James Beedy <jamesbe...@gmail.com>:
>
>> How do people feel about splitting the upgrade-charm hook into multiple
>> hooks to facilitate better resource management?
>>
>> What I'm thinking would be super helpful would be to have the
>> upgrade-charm hook still active for charm upgrades, and have separate hooks
>> or flags that would indicate resource upgrades.
>>
>> I'm thinking something like:
>>
>> 'juju attach myapp myresource=myresource.file'
>>
>> Would cause the 'upgrade-resource-myresource'  hook to become active on
>> instances of 'myapp'.
>>
>> I feel that having this affinity from resource ->
>> resource-upgrade- hook would be a huge win for resource
>> management.
>>
>> Thoughts?
>>
>>
>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

upgrade-charm hook

[James Beedy]

How do people feel about splitting the upgrade-charm hook into multiple hooks 
to facilitate better resource management?

What I'm thinking would be super helpful would be to have the upgrade-charm 
hook still active for charm upgrades, and have separate hooks or flags that 
would indicate resource upgrades. 

I'm thinking something like:

'juju attach myapp myresource=myresource.file'

Would cause the 'upgrade-resource-myresource'  hook to become active on 
instances of 'myapp'.

I feel that having this affinity from resource -> 
resource-upgrade- hook would be a huge win for resource 
management.

Thoughts?




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

upgrade-charm hook

[James Beedy]

How do people feel about splitting the upgrade-charm hook into multiple hooks 
to facilitate better resource management?

What I'm thinking would be super helpful would be to have the upgrade-charm 
hook still active for charm upgrades, and have separate hooks or flags that 
would indicate resource upgrades. 

I'm thinking something like:

'juju attach myapp myresource=myresource.file'

Would cause the 'upgrade-resource-myresource'  hook to become active on 
instances of 'myapp'.

I feel that having this affinity from resource -> 
resource-upgrade- hook would be a huge win for resource 
management.

Thoughts?




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

Re: charmhelpers migration to github

[James Beedy]

HAHAHA - we all have to learn sometime.
Truth be told, I use to do this back in the day too. Ask @adamstokes or 
@mikemccracken I'm sure to have tested their patience with this many times - 
forking the openstack-installer and reving their hard coded charms 

> On Sep 21, 2017, at 8:43 AM, Merlijn Sebrechts <merlijn.sebrec...@gmail.com> 
> wrote:
> 
> Now I feel stupid about my "delete fork and refork" approach to make sure I 
> get a clean master for each new PR.. :)
> 
> 2017-09-21 17:38 GMT+02:00 Alex Kavanagh <alex.kavan...@canonical.com>:
>> 
>> 
>>> On Thu, Sep 21, 2017 at 4:32 PM, James Beedy <jamesbe...@gmail.com> wrote:
>>> Tracking many upstream projects, I find it most clean to just fetch the the 
>>> upstream master once my feature branch PR has landed, such that I don't 
>>> push or merge anything to my own master branch. (Ideally) I only use master 
>>> branch to sync with upstream and to make new branches from. But that's just 
>>> me :)
>> 
>> I too, use this approach.  I treat the master as 'pristine' and do all work 
>> in branches, and if there's an upstream (and there usually is), sync that to 
>> my master, etc.
>>  
>>> 
>>> 
>>> > What's the reasoning behind feature branches in private repositories? Why
>>> > not just develop on the master of your private repo?
>>> >
>>> > 2017-09-21 12:12 GMT+02:00 James Hebden <james.heb...@canonical.com>:
>>> >
>>> >> Just lending my support for Dmitrii's guidance here.
>>> >> Clean history is important, especially to those reviewing changes - but
>>> >> having a clean history isn't as simple as having a single commit in
>>> >> place when merging code from a private branch into upstream - it's
>>> >> more important to isolate logical changes into individual branches and
>>> >> MP those regularly and without remorse.
>>> >> It's a fairly comfortable and obvious distinction - but an important
>>> >> one I think when working with MPs.
>>> >>
>>> >> Reviewing these two commits in one MP -
>>> >> "Updated bundled dependencies"
>>> >> "Corrected PEP8 errors"
>>> >>
>>> >> Or one commit
>>> >> "Updated bundled dependencies and corrected PEP8 errors"
>>> >>
>>> >> ...both are going to be a nightmare for the reviewer, especially given
>>> >> the GitHub UI's inability to sensibly show changes to a single file when
>>> >> a lot of files have changed, especially over multiple commits. Keeping
>>> >> MPs short, sweet and logical will make everyone's lives easier when
>>> >> working with MPs.
>>> >>
>>> >> So, If I'm just agreeing with everyone, why am I replying? Well,
>>> >> primarily just to point everyone at
>>> >> https://github.com/juju/juju/blob/develop/CONTRIBUTING.md#workflow
>>> >>
>>> >> The existing Juju docs seem to get it right and meet everyone's
>>> >> expectation here. Seems like a good candidate for improving the current
>>> >> charmhelpers contributing documentation.
>>> >>
>>> >> Also, thanks for all the hard work to make this happen!
>>> >>
>>> >>> On Thu, Sep 21, 2017 at 12:35:56PM +0300, Dmitrii Shcherbakov wrote:
>>> >>> I think that following the clean history approach is generally good as 
>>> >>> it
>>> >>> makes your life easier during debugging and commit message grepping.
>>> >>>
>>> >>> Linus' point about
>>> >>>
>>> >>> https://www.mail-archive.com/dri-devel@lists.sourceforge.
>>> >> net/msg39091.html
>>> >>> "I want clean history, but that really means (a) clean and (b) history."
>>> >>>
>>> >>> having both history and keeping it clean is something that we should
>>> >>> consider but not enforce too much (subjectively) to avoid making it too
>>> >>> hard to commit changes. In the end, this transition to github is about
>>> >>> making it easier to contribute, not requiring a person to read a 
>>> >>> 100-page
>>> >>> manual on how to annotate and prepare a commit to push a one-liner.
>>> >>>
>>> >>> Given that charm-helpers changes are general

Re: charmhelpers migration to github

[James Beedy]

Tracking many upstream projects, I find it most clean to just fetch the the 
upstream master once my feature branch PR has landed, such that I don't push or 
merge anything to my own master branch. (Ideally) I only use master branch to 
sync with upstream and to make new branches from. But that's just me :)


> What's the reasoning behind feature branches in private repositories? Why
> not just develop on the master of your private repo?
> 
> 2017-09-21 12:12 GMT+02:00 James Hebden :
> 
>> Just lending my support for Dmitrii's guidance here.
>> Clean history is important, especially to those reviewing changes - but
>> having a clean history isn't as simple as having a single commit in
>> place when merging code from a private branch into upstream - it's
>> more important to isolate logical changes into individual branches and
>> MP those regularly and without remorse.
>> It's a fairly comfortable and obvious distinction - but an important
>> one I think when working with MPs.
>> 
>> Reviewing these two commits in one MP -
>> "Updated bundled dependencies"
>> "Corrected PEP8 errors"
>> 
>> Or one commit
>> "Updated bundled dependencies and corrected PEP8 errors"
>> 
>> ...both are going to be a nightmare for the reviewer, especially given
>> the GitHub UI's inability to sensibly show changes to a single file when
>> a lot of files have changed, especially over multiple commits. Keeping
>> MPs short, sweet and logical will make everyone's lives easier when
>> working with MPs.
>> 
>> So, If I'm just agreeing with everyone, why am I replying? Well,
>> primarily just to point everyone at
>> https://github.com/juju/juju/blob/develop/CONTRIBUTING.md#workflow
>> 
>> The existing Juju docs seem to get it right and meet everyone's
>> expectation here. Seems like a good candidate for improving the current
>> charmhelpers contributing documentation.
>> 
>> Also, thanks for all the hard work to make this happen!
>> 
>>> On Thu, Sep 21, 2017 at 12:35:56PM +0300, Dmitrii Shcherbakov wrote:
>>> I think that following the clean history approach is generally good as it
>>> makes your life easier during debugging and commit message grepping.
>>> 
>>> Linus' point about
>>> 
>>> https://www.mail-archive.com/dri-devel@lists.sourceforge.
>> net/msg39091.html
>>> "I want clean history, but that really means (a) clean and (b) history."
>>> 
>>> having both history and keeping it clean is something that we should
>>> consider but not enforce too much (subjectively) to avoid making it too
>>> hard to commit changes. In the end, this transition to github is about
>>> making it easier to contribute, not requiring a person to read a 100-page
>>> manual on how to annotate and prepare a commit to push a one-liner.
>>> 
>>> Given that charm-helpers changes are generally small, I think squashing
>> is
>>> OK even using github's mechanism.
>>> 
>>> For large commits, on the other hand, it makes sense to recreate a pull
>>> request (close a PR, update and push to a fork, create a new PR) or
>> update
>>> an existing PR by doing a complex rebase + force push. When there are
>>> several logical changes per commit it is quite important to keep them
>>> separate and squashing everything into a single change is essentially
>>> hiding history.
>>> 
>>> An analogy would be file compression: yes, you can squeeze files to a
>>> single compressed blob and make it a bit smaller but then you have to
>> waste
>>> CPU cycles to decode it. In the same way, when you are trying to quickly
>>> grep through a git log you don't want to waste brain cycles on decoding
>>> unstructured information.
>>> 
>>> Best Regards,
>>> Dmitrii Shcherbakov
>>> 
>>> Field Software Engineer
>>> IRC (freenode): Dmitrii-Sh
>>> 
>>> On Thu, Sep 21, 2017 at 12:02 PM, Merlijn Sebrechts <
>>> merlijn.sebrec...@gmail.com> wrote:
>>> 
 It depends on what you want to optimize the development workflow for. I
 think we need to optimize for easiness because a lot of contributors
>> will
 be ops people who generally have a lot less experience with git and
>> github.
 I for example have rebased once in my life, and this was only possible
>> with
 Alex walking me through the process.
 
 *"Fork to private + PR + dirty fix commits" *is an easy workflow that a
 lot of people are familiar with and that works well with Github. If you
 want a cleaner commit history, you can always rebase or squash the PR
 during merge using the Github UI: https://pasteboard.co/GLmTHnf.png.
 
 It's not ideal but it's a small price to pay for more contributors..
 
 
 
 
 
 
 2017-09-20 22:10 GMT+02:00 Alex Kavanagh >> :
 
> There's some interesting ideas in there, Dmitrii. Whatever workflow we
> end up with needs to be consistent with the other workflow on the juju
> namespace on github.com, which I'm guessing is a simple fork to
>> private
> + PR.
> 
> 

Re: Prometheus + Collectd (collectd_exporter)

[James Beedy]

Disregard the previous email. Here is what I came up with -
http://paste.ubuntu.com/25475631/

On Tue, Sep 5, 2017 at 6:12 PM, James Beedy <jamesbe...@gmail.com> wrote:

> @canonical-is-sa https://jujucharms.com/u/canonical-is-sa/collectd/
> xenial/0#charm-config-prometheus_export - wtf
>
> Could someone give an example of how the collectd charm can be configured
> to use the collectd_exporter? The docs for the prometheus_export config are
> slightly confusing :)
>
> Thanks
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Prometheus + Collectd (collectd_exporter)

[James Beedy]

@canonical-is-sa
https://jujucharms.com/u/canonical-is-sa/collectd/xenial/0#charm-config-prometheus_export
- wtf

Could someone give an example of how the collectd charm can be configured
to use the collectd_exporter? The docs for the prometheus_export config are
slightly confusing :)

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

[charms][ceph-radosgw] radosgw-admin?

[James Beedy]

Hello,

Just wondering if the ceph-radosgw charm provides a method of
configuring/accessing the radosgw-admin utility, or if there is a suggested
way to get radosgw-admin working in conjunction with ceph/ceph-radosgw
charms?

In the ceph-radosgw charm, I see the radosgw-admin bin ends up in
/usr/bin/radosgw-admin, but I'm guessing there would need to be some
stanzas in the ceph.conf pertaining to radosgw.admin, and a keyring file
specifically for the radosgw-admin client (and probably more, I'm not
really to sure) to get the radosgw-admin working from locally from the
ceph-radosgw charm (or is there a better way?).

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

Re: Elasticseach Charm Promulgation - things to keep in mind

[James Beedy]

Also - https://bugs.launchpad.net/elasticsearch-charm/+bug/1714126

On Wed, Aug 30, 2017 at 6:47 PM, James Beedy <jamesbe...@gmail.com> wrote:

> Elasticsearch >= 5.x is non-compat with kibana <= 5.x. The current default
> configs for https://jujucharms.com/u/elasticsearch-charmers/elasticsearch
> may break any bundles that have elasticsearch + kibana not pinned to a
> specific charm store uri/rev upon promulgation.
>
> This probably won't affect many, just thought I would put it out there.
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Elasticseach Charm Promulgation - things to keep in mind

[James Beedy]

Elasticsearch >= 5.x is non-compat with kibana <= 5.x. The current default
configs for https://jujucharms.com/u/elasticsearch-charmers/elasticsearch
may break any bundles that have elasticsearch + kibana not pinned to a
specific charm store uri/rev upon promulgation.

This probably won't affect many, just thought I would put it out there.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Elasticseach Charm Promulgation

[James Beedy]

@tom Do you guys have something in place to support 5.x yet? I don't mind if 
you pull my bits forward for the 5.x stuff (mainly in the elasticsearch.yml 
template), either way, will you make sure whatever you decide to push upstream 
supports 5.x please?

Thanks


> On Aug 22, 2017, at 5:00 AM, juju-requ...@lists.ubuntu.com wrote:
> 
> Send Juju mailing list submissions to
>juju@lists.ubuntu.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.ubuntu.com/mailman/listinfo/juju
> or, via email, send a message with subject or body 'help' to
>juju-requ...@lists.ubuntu.com
> 
> You can reach the person managing the list at
>juju-ow...@lists.ubuntu.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Juju digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Elasticsearch Charm Promulgation (Tom Haddon)
>   2. Re: Elasticsearch Charm Promulgation (Tom Haddon)
> 
> 
> --
> 
> Message: 1
> Date: Mon, 21 Aug 2017 14:53:10 +0100
> From: Tom Haddon <tom.had...@canonical.com>
> To: Kevin Monroe <kevin.mon...@canonical.com>
> Cc: James Beedy <jamesbe...@gmail.com>, Juju email list
><juju@lists.ubuntu.com>
> Subject: Re: Elasticsearch Charm Promulgation
> Message-ID: <20170821135310.GB7478@tenaya>
> Content-Type: text/plain; charset=us-ascii
> 
>> On Fri, Aug 18, 2017 at 01:35:11PM -0500, Kevin Monroe wrote:
>> Hey James!
>> 
>> First up, thanks so much for bringing the ES charm up to v5.x!  Can you
>> tell me if the source for cs:~jamesbeedy/elasticsearch-7 is the same as
>> what we've got here:
>> 
>> https://github.com/charms/charm-elasticsearch
>> 
>> Or is that source waiting on this PR to bring it in line with your es-7
>> charm:
>> 
>> https://github.com/charms/charm-elasticsearch/pull/2
>> 
>> The PR LGTM, so I'll merge it on your ack.  Let me know if there are other
>> outstanding bits that need to go into this repo.  Once that's done, I
>> propose we push this to the ~elastic-ops namespace of which you're a member:
>> 
>> https://launchpad.net/~elastic-ops
>> 
>> And then promulgate the ~elastic-ops charm rev.  As Rick and others have
>> mentioned, teams help distribute ongoing maintenance to people that have a
>> vested interest in certain charms.
> 
> We've been working off https://code.launchpad.net/elasticsearch-charm which
> we've pushed to the charmstore here
> https://jujucharms.com/u/elasticsearch-charmers/elasticsearch/
> 
> This seems to be based off a similar version to the one James has on github,
> and the ~elastic-ops team you mention above is already a member of the
> elasticsearch-charm project.
> 
> We're using this charm on xenial successfully, so maybe it'd be worth trying
> to work together to get
> https://jujucharms.com/u/elasticsearch-charmers/elasticsearch/ as the
> promulgated upstream charm.
> 
>> @Simon / Bret:  you are on the ~onlineservices-charmers team that owns the
>> current promulgated ES charm.  Would you be willing to relinquish
>> maintainership to ~elastic-ops (and would you like to be members of that
>> team)?
> 
> I checked with some of the ~onlineservices-charmers team and they were happy
> for https://jujucharms.com/u/elasticsearch-charmers/elasticsearch/ to replace
> the current promulgated charm (which only supports precise and trusty). We
> should test that you can successfully charm upgrade from theirs to this charm
> (on trusty) - I'm happy to take that on, and will update here once we've done
> so.
> 
>> Thanks!
>> -Kevin Monroe
>> 
>> On Mon, Aug 14, 2017 at 12:12 PM, Rick Harding <rick.hard...@canonical.com>
>> wrote:
>> 
>>> I'd also encourage you to test an upgrade path from the current charm to
>>> yours to help comfort any current users of the charm that if there's a
>>> change it'll go smoothly for users.
>>> 
>>> On Mon, Aug 14, 2017 at 1:00 PM Tim Van Steenburgh <
>>> tim.van.steenbu...@canonical.com> wrote:
>>> 
>>>> Hey James, my point was that if you want to replace the existing
>>>> top-level ES charm with your own, we would need agreement from the
>>>> maintainers of the existing charm.
>>>> 
>>>> On Mon, Aug 14, 2017 at 12:45 PM, James Beedy <jamesbe...@gmail.com>
>>>> wrote:
>>>> 
>>>>> @tim yeah ... possibly I'm not looking for promulgation then, and just
>>>>> need to push it and grant eve

Re: Elasticsearch Charm Promulgation

[James Beedy]

Kevin,

"Or is that source waiting on this PR to bring it in line with your es-7
charm"
- This is the case

If we merge the xenial support PR, it will be even with the
cs:~jamesbeedy/elasticsearch-7.

~James

On Fri, Aug 18, 2017 at 11:35 AM, Kevin Monroe <kevin.mon...@canonical.com>
wrote:

> Hey James!
>
> First up, thanks so much for bringing the ES charm up to v5.x!  Can you
> tell me if the source for cs:~jamesbeedy/elasticsearch-7 is the same as
> what we've got here:
>
> https://github.com/charms/charm-elasticsearch
>
> Or is that source waiting on this PR to bring it in line with your es-7
> charm:
>
> https://github.com/charms/charm-elasticsearch/pull/2
>
> The PR LGTM, so I'll merge it on your ack.  Let me know if there are other
> outstanding bits that need to go into this repo.  Once that's done, I
> propose we push this to the ~elastic-ops namespace of which you're a member:
>
> https://launchpad.net/~elastic-ops
>
> And then promulgate the ~elastic-ops charm rev.  As Rick and others have
> mentioned, teams help distribute ongoing maintenance to people that have a
> vested interest in certain charms.
>
> @Simon / Bret:  you are on the ~onlineservices-charmers team that owns the
> current promulgated ES charm.  Would you be willing to relinquish
> maintainership to ~elastic-ops (and would you like to be members of that
> team)?
>
> Thanks!
> -Kevin Monroe
>
> On Mon, Aug 14, 2017 at 12:12 PM, Rick Harding <rick.hard...@canonical.com
> > wrote:
>
>> I'd also encourage you to test an upgrade path from the current charm to
>> yours to help comfort any current users of the charm that if there's a
>> change it'll go smoothly for users.
>>
>> On Mon, Aug 14, 2017 at 1:00 PM Tim Van Steenburgh <
>> tim.van.steenbu...@canonical.com> wrote:
>>
>>> Hey James, my point was that if you want to replace the existing
>>> top-level ES charm with your own, we would need agreement from the
>>> maintainers of the existing charm.
>>>
>>> On Mon, Aug 14, 2017 at 12:45 PM, James Beedy <jamesbe...@gmail.com>
>>> wrote:
>>>
>>>> @tim yeah ... possibly I'm not looking for promulgation then, and just
>>>> need to push it and grant everyone because its already promulgated?
>>>>
>>>> On Mon, Aug 14, 2017 at 9:29 AM, Tim Van Steenburgh <
>>>> tim.van.steenbu...@canonical.com> wrote:
>>>>
>>>>> There's already a top-level elasticsearch charm.
>>>>> https://jujucharms.com/elasticsearch/
>>>>>
>>>>> On Mon, Aug 14, 2017 at 12:13 PM, James Beedy <jamesbe...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Request for promulgation of Elasticsearch. The Elasticsearch charm
>>>>>> can be found at cs:~jamesbeedy/elasticsearch-7.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> James
>>>>>>
>>>>>> --
>>>>>> Juju mailing list
>>>>>> Juju@lists.ubuntu.com
>>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>>>> an/listinfo/juju
>>>>>>
>>>>>>
>>>>>
>>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Elasticsearch Charm Promulgation

[James Beedy]

@tim yeah ... possibly I'm not looking for promulgation then, and just need
to push it and grant everyone because its already promulgated?

On Mon, Aug 14, 2017 at 9:29 AM, Tim Van Steenburgh <
tim.van.steenbu...@canonical.com> wrote:

> There's already a top-level elasticsearch charm. https://jujucharms.com/
> elasticsearch/
>
> On Mon, Aug 14, 2017 at 12:13 PM, James Beedy <jamesbe...@gmail.com>
> wrote:
>
>> Request for promulgation of Elasticsearch. The Elasticsearch charm can be
>> found at cs:~jamesbeedy/elasticsearch-7.
>>
>> Thanks,
>>
>> James
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Elasticsearch Charm Promulgation

[James Beedy]

Request for promulgation of Elasticsearch. The Elasticsearch charm can be
found at cs:~jamesbeedy/elasticsearch-7.

Thanks,

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

Re: CephFS Backend for Hadoop

[James Beedy]

Dmitrii,

Many thanks for your insight here.

~James

On Wed, Jul 26, 2017 at 11:34 PM, Patrizio Bassi 
wrote:

>
> 2017-07-26 9:17 GMT+02:00 Mark Shuttleworth :
>
>> On 26/07/17 07:14, Patrizio Bassi wrote:
>>
>> Deploying hadoop via juju in an openstack tenant requires a separate
>> model (as far as i could design it).
>> So we may use the new juju 2.2 cross model relation to relate the hadoop
>> charms to the openstack ceph units.
>>
>> does it sound feasible?
>>
>>
>> Yes, that sounds feasible. I'm not sure how Ceph identity / permissions
>> will work in that case (i.e. who has access to which data, how Ceph will
>> correlate tenants in OpenStack both through Cinder and through a direct
>> relationship). In principle though, as long as the networking is arranged
>> so that IP addresses and routes enable traffic to flow between your tenant
>> network and your Ceph network, and as long as both sets of machines can see
>> the Juju controller, they can exchange messages and traffic.
>>
>> Mark
>>
>
>
> Dear Mark,
>
> On relation join event we may create a new ceph storage pool dedicated to
> the incoming unit (i.e. prefixed with the controller/model/unit/charm name
> by default). Can cephx proto
>
> Regarding networking openstack neutron by default block traffic from
> tenant VM to the admin network which it required to access the same ceph
> mon/osd. It requires changing neutron or implement an external nat for
> instance (our solution at the moment)
>
> Patrizio
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

CephFS Backend for Hadoop

[James Beedy]

Hello all,

I will be evaluating CephFS as a backend for Hadoop over the next few
weeks, probably start investigating how this can be delivered via the
charms in the morning. If anyone has ventured to this realm, or has an idea
on what the best way to deliver this might be, I would love to hear from
you.

Thanks,

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

Re: docker -> lxdbr0

[James Beedy]

It really does ... don't know why I didn't just add the extra file. I've fixed 
this. Thanks!

> On Jun 21, 2017, at 6:32 AM, John Meinel <j...@arbash-meinel.com> wrote:
> 
> Gotcha. Though I will say that looks more like its a bogus comment about a 
> file that this isn't. But I see what you're doing.
> 
> John
> =:->
> 
> 
>> On Wed, Jun 21, 2017 at 5:29 PM, James Beedy <jamesbe...@gmail.com> wrote:
>> It's in the comments at the top of the gist.
>> 
>>> On Jun 20, 2017, at 10:31 PM, John Meinel <j...@arbash-meinel.com> wrote:
>>> 
>>> This definitely sounds interesting.
>>> 
>>> You included the layer python code, but not the "daemon.json.j2" file. 
>>> Isn't that part of getting the networking config in place?
>>> 
>>> John
>>> =:->
>>> 
>>> 
>>>> On Wed, Jun 21, 2017 at 6:16 AM, James Beedy <jamesbe...@gmail.com> wrote:
>>>> On integrating docker and lxd deployed apps ...
>>>> 
>>>> My charm includes layer-docker, and exposes a simple api wrapping 
>>>> docker-py to allow the charm to login to dockerhub, pull and run docker 
>>>> images, and a few other standard docker ops. My dockerized apps talk to 
>>>> elasticsearch, mysql, and redis, all of which get deployed via Juju in 
>>>> production, but the developer envs don't have an easy time getting the 
>>>> whole bunch up on their laptops due to some lxd <-> docker integration. 
>>>> Today, I thought to deploy the mysql, elasticsearch, and redis to lxd 
>>>> aside the docker containers on the same host for local development - I was 
>>>> hitting a bump in the road getting the docker containers to talk to the 
>>>> lxd, so I looked into how to set the default docker bridge, and came up 
>>>> with this 
>>>> https://gist.github.com/jamesbeedy/39829a14fdc64583dfda4a6be1812aea
>>>> 
>>>> ~James
>>>> 
>>>> --
>>>> 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: docker -> lxdbr0

[James Beedy]

It really does ... don't know why I didn't just add the extra file. I've fixed 
this. Thanks!

> On Jun 21, 2017, at 6:32 AM, John Meinel <j...@arbash-meinel.com> wrote:
> 
> Gotcha. Though I will say that looks more like its a bogus comment about a 
> file that this isn't. But I see what you're doing.
> 
> John
> =:->
> 
> 
>> On Wed, Jun 21, 2017 at 5:29 PM, James Beedy <jamesbe...@gmail.com> wrote:
>> It's in the comments at the top of the gist.
>> 
>>> On Jun 20, 2017, at 10:31 PM, John Meinel <j...@arbash-meinel.com> wrote:
>>> 
>>> This definitely sounds interesting.
>>> 
>>> You included the layer python code, but not the "daemon.json.j2" file. 
>>> Isn't that part of getting the networking config in place?
>>> 
>>> John
>>> =:->
>>> 
>>> 
>>>> On Wed, Jun 21, 2017 at 6:16 AM, James Beedy <jamesbe...@gmail.com> wrote:
>>>> On integrating docker and lxd deployed apps ...
>>>> 
>>>> My charm includes layer-docker, and exposes a simple api wrapping 
>>>> docker-py to allow the charm to login to dockerhub, pull and run docker 
>>>> images, and a few other standard docker ops. My dockerized apps talk to 
>>>> elasticsearch, mysql, and redis, all of which get deployed via Juju in 
>>>> production, but the developer envs don't have an easy time getting the 
>>>> whole bunch up on their laptops due to some lxd <-> docker integration. 
>>>> Today, I thought to deploy the mysql, elasticsearch, and redis to lxd 
>>>> aside the docker containers on the same host for local development - I was 
>>>> hitting a bump in the road getting the docker containers to talk to the 
>>>> lxd, so I looked into how to set the default docker bridge, and came up 
>>>> with this 
>>>> https://gist.github.com/jamesbeedy/39829a14fdc64583dfda4a6be1812aea
>>>> 
>>>> ~James
>>>> 
>>>> --
>>>> 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: docker -> lxdbr0

[James Beedy]

It's in the comments at the top of the gist.

> On Jun 20, 2017, at 10:31 PM, John Meinel <j...@arbash-meinel.com> wrote:
> 
> This definitely sounds interesting.
> 
> You included the layer python code, but not the "daemon.json.j2" file. Isn't 
> that part of getting the networking config in place?
> 
> John
> =:->
> 
> 
>> On Wed, Jun 21, 2017 at 6:16 AM, James Beedy <jamesbe...@gmail.com> wrote:
>> On integrating docker and lxd deployed apps ...
>> 
>> My charm includes layer-docker, and exposes a simple api wrapping docker-py 
>> to allow the charm to login to dockerhub, pull and run docker images, and a 
>> few other standard docker ops. My dockerized apps talk to elasticsearch, 
>> mysql, and redis, all of which get deployed via Juju in production, but the 
>> developer envs don't have an easy time getting the whole bunch up on their 
>> laptops due to some lxd <-> docker integration. Today, I thought to deploy 
>> the mysql, elasticsearch, and redis to lxd aside the docker containers on 
>> the same host for local development - I was hitting a bump in the road 
>> getting the docker containers to talk to the lxd, so I looked into how to 
>> set the default docker bridge, and came up with this 
>> https://gist.github.com/jamesbeedy/39829a14fdc64583dfda4a6be1812aea
>> 
>> ~James
>> 
>> --
>> 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: docker -> lxdbr0

[James Beedy]

It's in the comments at the top of the gist.

> On Jun 20, 2017, at 10:31 PM, John Meinel <j...@arbash-meinel.com> wrote:
> 
> This definitely sounds interesting.
> 
> You included the layer python code, but not the "daemon.json.j2" file. Isn't 
> that part of getting the networking config in place?
> 
> John
> =:->
> 
> 
>> On Wed, Jun 21, 2017 at 6:16 AM, James Beedy <jamesbe...@gmail.com> wrote:
>> On integrating docker and lxd deployed apps ...
>> 
>> My charm includes layer-docker, and exposes a simple api wrapping docker-py 
>> to allow the charm to login to dockerhub, pull and run docker images, and a 
>> few other standard docker ops. My dockerized apps talk to elasticsearch, 
>> mysql, and redis, all of which get deployed via Juju in production, but the 
>> developer envs don't have an easy time getting the whole bunch up on their 
>> laptops due to some lxd <-> docker integration. Today, I thought to deploy 
>> the mysql, elasticsearch, and redis to lxd aside the docker containers on 
>> the same host for local development - I was hitting a bump in the road 
>> getting the docker containers to talk to the lxd, so I looked into how to 
>> set the default docker bridge, and came up with this 
>> https://gist.github.com/jamesbeedy/39829a14fdc64583dfda4a6be1812aea
>> 
>> ~James
>> 
>> --
>> 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

docker -> lxdbr0

[James Beedy]

On integrating docker and lxd deployed apps ...

My charm includes layer-docker, and exposes a simple api wrapping docker-py
to allow the charm to login to dockerhub, pull and run docker images, and a
few other standard docker ops. My dockerized apps talk to elasticsearch,
mysql, and redis, all of which get deployed via Juju in production, but the
developer envs don't have an easy time getting the whole bunch up on their
laptops due to some lxd <-> docker integration. Today, I thought to deploy
the mysql, elasticsearch, and redis to lxd aside the docker containers on
the same host for local development - I was hitting a bump in the road
getting the docker containers to talk to the lxd, so I looked into how to
set the default docker bridge, and came up with this
https://gist.github.com/jamesbeedy/39829a14fdc64583dfda4a6be1812aea

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

docker -> lxdbr0

[James Beedy]

On integrating docker and lxd deployed apps ...

My charm includes layer-docker, and exposes a simple api wrapping docker-py
to allow the charm to login to dockerhub, pull and run docker images, and a
few other standard docker ops. My dockerized apps talk to elasticsearch,
mysql, and redis, all of which get deployed via Juju in production, but the
developer envs don't have an easy time getting the whole bunch up on their
laptops due to some lxd <-> docker integration. Today, I thought to deploy
the mysql, elasticsearch, and redis to lxd aside the docker containers on
the same host for local development - I was hitting a bump in the road
getting the docker containers to talk to the lxd, so I looked into how to
set the default docker bridge, and came up with this
https://gist.github.com/jamesbeedy/39829a14fdc64583dfda4a6be1812aea

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

Re: Juju-dev Digest, Vol 61, Issue 10

[James Beedy]

Menno - Nice!

On performance monitoring, I always thought it would be interesting to see
what insight an APM might give. I've tried building Juju with the newrelic
APM agent a few times and had no luck (novice GO programmer here). I have
been playing around with the newrelic APM quite a bit with a few of our own
application stacks internally, and it has been producing great information
to our teams on how our apps perform in various areas.

* High level service map (part of the APM) that shows a few of our apps and
their external dependencies http://imgur.com/a/vmj2n

* Snip of digging into db query time http://imgur.com/a/HczPX

* Snip of web transaction tab http://imgur.com/a/Vp05q

I think it would be really cool to see a service map, and transaction
metrics similar to ^, for a juju controller and agents.

~James

On Mon, Jun 12, 2017 at 5:00 AM,  wrote:

> Send Juju-dev mailing list submissions to
> juju-dev@lists.ubuntu.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> or, via email, send a message with subject or body 'help' to
> juju-dev-requ...@lists.ubuntu.com
>
> You can reach the person managing the list at
> juju-dev-ow...@lists.ubuntu.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Juju-dev digest..."
>
>
> Today's Topics:
>
>1. Debugging MongoDB performance issues (Menno Smits)
>
>
> --
>
> Message: 1
> Date: Mon, 12 Jun 2017 15:39:16 +1200
> From: Menno Smits 
> To: juju-dev 
> Subject: Debugging MongoDB performance issues
> Message-ID:
>  mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi everyone,
>
> I started writing an email to a few Juju developers with tips on diagnosing
> MongoDB performance issues but then realised that this would be more useful
> as a wiki page.
>
> https://github.com/juju/juju/wiki/Diagnosing-MongoDB-Performance
>
> Feel free to expand and add your own techniques.
>
> - Menno
> -- next part --
> An HTML attachment was scrubbed...
> URL:  20170612/59c96e86/attachment-0001.html>
>
> --
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
> End of Juju-dev Digest, Vol 61, Issue 10
> 
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: OS X VMS on JAAS

[James Beedy]

This raises the question: why do we need a provider -> controller affinity
at all?

On Mon, Jun 5, 2017 at 12:23 PM, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> On 06/03/2017 02:56 AM, John Meinel wrote:
>
>> You can add a manually provisioned machine to any model, as long as there
>> is connectivity from the machine to the controller. Now, I would have
>> thought initial setup was initiated by the Controller, but its possible
>> that initial setup is actually initiated from the client.
>>
>> Once initial setup is complete, then it is definitely true that all
>> connections are initiated from the agent running on the controlled machine
>> to the controller. The controller no longer tries to socket.connect to the
>> machine. (In 1.X 'actions' were initiated via ssh from the controller, but
>> in 2.X the agents listen to see if there are any actions to run like they
>> do for all other changes.)
>>
>> Now, given that he added a model into "us-east-1" if he ever did just a
>> plain "juju add-machine" or "juju deploy" (without --to) it would
>> definitely create a new instance in AWS and start configuring it, rather
>> than from your VM.
>>
> Is it possible for us to convey the model's proper location, even when
> using jaas? He's in effect lying to the controller which does have the
> knock-on affect of weird behavior.
>
>>
>> Which is why using something like the "lxd provider" would be a more
>> natural use case, but according to James the sticking point is having to
>> set up a controller in the first place. So "--to lxd:0" is easier for them
>> to think about than setting up a provider and letting it decide how to
>> allocate machines.
>>
>> Note, it probably wouldn't be possible to use JAAS to drive an LXD
>> provider, because *that* would have JAAS be trying to make a direct
>> connection to your LXD agent in order to provision the next machine.
>> However "--to lxd:0" has the local juju agent (running for 'machine 0')
>> talking to the local LXD agent in order to create a container.
>>
> If this is a useful case, could we define it as a mode of operation and
> have juju just work in such a scenario? It's an interesting mix of allowing
> the benefits of jaas for manually provisioned machines and environments.
> Just eliminating the weird behaviors and having to pretend it's a known
> cloud / provider could be useful. An assume nothing mode if you will.
>
> Nicholas
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: OS X VMS on JAAS

[James Beedy]

This raises the question: why do we need a provider -> controller affinity
at all?

On Mon, Jun 5, 2017 at 12:23 PM, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> On 06/03/2017 02:56 AM, John Meinel wrote:
>
>> You can add a manually provisioned machine to any model, as long as there
>> is connectivity from the machine to the controller. Now, I would have
>> thought initial setup was initiated by the Controller, but its possible
>> that initial setup is actually initiated from the client.
>>
>> Once initial setup is complete, then it is definitely true that all
>> connections are initiated from the agent running on the controlled machine
>> to the controller. The controller no longer tries to socket.connect to the
>> machine. (In 1.X 'actions' were initiated via ssh from the controller, but
>> in 2.X the agents listen to see if there are any actions to run like they
>> do for all other changes.)
>>
>> Now, given that he added a model into "us-east-1" if he ever did just a
>> plain "juju add-machine" or "juju deploy" (without --to) it would
>> definitely create a new instance in AWS and start configuring it, rather
>> than from your VM.
>>
> Is it possible for us to convey the model's proper location, even when
> using jaas? He's in effect lying to the controller which does have the
> knock-on affect of weird behavior.
>
>>
>> Which is why using something like the "lxd provider" would be a more
>> natural use case, but according to James the sticking point is having to
>> set up a controller in the first place. So "--to lxd:0" is easier for them
>> to think about than setting up a provider and letting it decide how to
>> allocate machines.
>>
>> Note, it probably wouldn't be possible to use JAAS to drive an LXD
>> provider, because *that* would have JAAS be trying to make a direct
>> connection to your LXD agent in order to provision the next machine.
>> However "--to lxd:0" has the local juju agent (running for 'machine 0')
>> talking to the local LXD agent in order to create a container.
>>
> If this is a useful case, could we define it as a mode of operation and
> have juju just work in such a scenario? It's an interesting mix of allowing
> the benefits of jaas for manually provisioned machines and environments.
> Just eliminating the weird behaviors and having to pretend it's a known
> cloud / provider could be useful. An assume nothing mode if you will.
>
> Nicholas
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: OS X VMS on JAAS

[James Beedy]

One big reason this has been such a gem for me, is because once a user adds
his vm to a model, I can deploy/manage/admin the application for them
remotely on their local vm. This is huge when on-boarding new users,
because it helps negate all the things someone foreign to Juju might
encounter when deploying my custom bundles that need proxy actions and the
like ran to get them initialized. ALSO, now I don't have to screen share
and deal with all the remote assistance mumbo jumbo deploying and
configuring their local lxd envs on a per user basis just to get them going
(this has been a huge time munch for me previously).

~James

On Sun, Jun 4, 2017 at 8:31 AM, James Beedy <jamesbe...@gmail.com> wrote:

> @john, @andrew thanks for the details here
>
> On Sat, Jun 3, 2017 at 10:21 PM, Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> On Sat, Jun 3, 2017 at 2:56 PM John Meinel <j...@arbash-meinel.com>
>> wrote:
>>
>>> You can add a manually provisioned machine to any model, as long as
>>> there is connectivity from the machine to the controller. Now, I would have
>>> thought initial setup was initiated by the Controller, but its possible
>>> that initial setup is actually initiated from the client.
>>>
>>
>> Given the command:
>>
>> $ juju add-machine ssh:
>>
>> it goes something like this:
>>
>> 1. client connects to  via SSH, and performs basic hardware/OS
>> discovery
>> 2. client asks controller to add a machine entry, and controller returns
>> a script to be executed on the target machine, using the discovered
>> details, in order to fetch and install jujud
>> 3. client executes that script over the SSH connection
>>
>> Once initial setup is complete, then it is definitely true that all
>>> connections are initiated from the agent running on the controlled machine
>>> to the controller. The controller no longer tries to socket.connect to the
>>> machine. (In 1.X 'actions' were initiated via ssh from the controller, but
>>> in 2.X the agents listen to see if there are any actions to run like they
>>> do for all other changes.)
>>>
>>> Now, given that he added a model into "us-east-1" if he ever did just a
>>> plain "juju add-machine" or "juju deploy" (without --to) it would
>>> definitely create a new instance in AWS and start configuring it, rather
>>> than from your VM.
>>>
>>> Which is why using something like the "lxd provider" would be a more
>>> natural use case, but according to James the sticking point is having to
>>> set up a controller in the first place. So "--to lxd:0" is easier for them
>>> to think about than setting up a provider and letting it decide how to
>>> allocate machines.
>>>
>>> Note, it probably wouldn't be possible to use JAAS to drive an LXD
>>> provider, because *that* would have JAAS be trying to make a direct
>>> connection to your LXD agent in order to provision the next machine.
>>> However "--to lxd:0" has the local juju agent (running for 'machine 0')
>>> talking to the local LXD agent in order to create a container.
>>>
>>> John
>>> =:->
>>>
>>>
>>> On Fri, Jun 2, 2017 at 6:28 PM, Jay Wren <jay.w...@canonical.com> wrote:
>>>
>>>> I do not understand how this works. Could someone with knowledge of how
>>>> jujud on a  controller communicates with jujud agents on units describe how
>>>> that is done?
>>>>
>>>> My limited understanding must be wrong give that James has this working.
>>>>
>>>> This is what I thought:
>>>>
>>>> On most cloud providers: add-machine instructs the cloud provider to
>>>> start a new instance and the cloud-config passed to cloud-init includes how
>>>> to download jujud agent and run it and configure it with public key trust
>>>> of the juju controller.
>>>>
>>>> On manually added machine: same thing only instead of cloud-init and
>>>> cloud-config an ssh connection is used to perform the same commands.
>>>>
>>>> I had thought the juju controller was initiating the ssh-connection to
>>>> the address given in the add-machine command and that a non-internet
>>>> routable address would simply not work as the controller cannot open any
>>>> TCP connection to it. This is where my understanding stops.
>>>>
>>>> Please, anyone, describe how this works?
>>>> --

Re: OS X VMS on JAAS

[James Beedy]

One big reason this has been such a gem for me, is because once a user adds
his vm to a model, I can deploy/manage/admin the application for them
remotely on their local vm. This is huge when on-boarding new users,
because it helps negate all the things someone foreign to Juju might
encounter when deploying my custom bundles that need proxy actions and the
like ran to get them initialized. ALSO, now I don't have to screen share
and deal with all the remote assistance mumbo jumbo deploying and
configuring their local lxd envs on a per user basis just to get them going
(this has been a huge time munch for me previously).

~James

On Sun, Jun 4, 2017 at 8:31 AM, James Beedy <jamesbe...@gmail.com> wrote:

> @john, @andrew thanks for the details here
>
> On Sat, Jun 3, 2017 at 10:21 PM, Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> On Sat, Jun 3, 2017 at 2:56 PM John Meinel <j...@arbash-meinel.com>
>> wrote:
>>
>>> You can add a manually provisioned machine to any model, as long as
>>> there is connectivity from the machine to the controller. Now, I would have
>>> thought initial setup was initiated by the Controller, but its possible
>>> that initial setup is actually initiated from the client.
>>>
>>
>> Given the command:
>>
>> $ juju add-machine ssh:
>>
>> it goes something like this:
>>
>> 1. client connects to  via SSH, and performs basic hardware/OS
>> discovery
>> 2. client asks controller to add a machine entry, and controller returns
>> a script to be executed on the target machine, using the discovered
>> details, in order to fetch and install jujud
>> 3. client executes that script over the SSH connection
>>
>> Once initial setup is complete, then it is definitely true that all
>>> connections are initiated from the agent running on the controlled machine
>>> to the controller. The controller no longer tries to socket.connect to the
>>> machine. (In 1.X 'actions' were initiated via ssh from the controller, but
>>> in 2.X the agents listen to see if there are any actions to run like they
>>> do for all other changes.)
>>>
>>> Now, given that he added a model into "us-east-1" if he ever did just a
>>> plain "juju add-machine" or "juju deploy" (without --to) it would
>>> definitely create a new instance in AWS and start configuring it, rather
>>> than from your VM.
>>>
>>> Which is why using something like the "lxd provider" would be a more
>>> natural use case, but according to James the sticking point is having to
>>> set up a controller in the first place. So "--to lxd:0" is easier for them
>>> to think about than setting up a provider and letting it decide how to
>>> allocate machines.
>>>
>>> Note, it probably wouldn't be possible to use JAAS to drive an LXD
>>> provider, because *that* would have JAAS be trying to make a direct
>>> connection to your LXD agent in order to provision the next machine.
>>> However "--to lxd:0" has the local juju agent (running for 'machine 0')
>>> talking to the local LXD agent in order to create a container.
>>>
>>> John
>>> =:->
>>>
>>>
>>> On Fri, Jun 2, 2017 at 6:28 PM, Jay Wren <jay.w...@canonical.com> wrote:
>>>
>>>> I do not understand how this works. Could someone with knowledge of how
>>>> jujud on a  controller communicates with jujud agents on units describe how
>>>> that is done?
>>>>
>>>> My limited understanding must be wrong give that James has this working.
>>>>
>>>> This is what I thought:
>>>>
>>>> On most cloud providers: add-machine instructs the cloud provider to
>>>> start a new instance and the cloud-config passed to cloud-init includes how
>>>> to download jujud agent and run it and configure it with public key trust
>>>> of the juju controller.
>>>>
>>>> On manually added machine: same thing only instead of cloud-init and
>>>> cloud-config an ssh connection is used to perform the same commands.
>>>>
>>>> I had thought the juju controller was initiating the ssh-connection to
>>>> the address given in the add-machine command and that a non-internet
>>>> routable address would simply not work as the controller cannot open any
>>>> TCP connection to it. This is where my understanding stops.
>>>>
>>>> Please, anyone, describe how this works?
>>>> --

Re: OS X VMS on JAAS

[James Beedy]

@john, @andrew thanks for the details here

On Sat, Jun 3, 2017 at 10:21 PM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> On Sat, Jun 3, 2017 at 2:56 PM John Meinel <j...@arbash-meinel.com> wrote:
>
>> You can add a manually provisioned machine to any model, as long as there
>> is connectivity from the machine to the controller. Now, I would have
>> thought initial setup was initiated by the Controller, but its possible
>> that initial setup is actually initiated from the client.
>>
>
> Given the command:
>
> $ juju add-machine ssh:
>
> it goes something like this:
>
> 1. client connects to  via SSH, and performs basic hardware/OS
> discovery
> 2. client asks controller to add a machine entry, and controller returns a
> script to be executed on the target machine, using the discovered details,
> in order to fetch and install jujud
> 3. client executes that script over the SSH connection
>
> Once initial setup is complete, then it is definitely true that all
>> connections are initiated from the agent running on the controlled machine
>> to the controller. The controller no longer tries to socket.connect to the
>> machine. (In 1.X 'actions' were initiated via ssh from the controller, but
>> in 2.X the agents listen to see if there are any actions to run like they
>> do for all other changes.)
>>
>> Now, given that he added a model into "us-east-1" if he ever did just a
>> plain "juju add-machine" or "juju deploy" (without --to) it would
>> definitely create a new instance in AWS and start configuring it, rather
>> than from your VM.
>>
>> Which is why using something like the "lxd provider" would be a more
>> natural use case, but according to James the sticking point is having to
>> set up a controller in the first place. So "--to lxd:0" is easier for them
>> to think about than setting up a provider and letting it decide how to
>> allocate machines.
>>
>> Note, it probably wouldn't be possible to use JAAS to drive an LXD
>> provider, because *that* would have JAAS be trying to make a direct
>> connection to your LXD agent in order to provision the next machine.
>> However "--to lxd:0" has the local juju agent (running for 'machine 0')
>> talking to the local LXD agent in order to create a container.
>>
>> John
>> =:->
>>
>>
>> On Fri, Jun 2, 2017 at 6:28 PM, Jay Wren <jay.w...@canonical.com> wrote:
>>
>>> I do not understand how this works. Could someone with knowledge of how
>>> jujud on a  controller communicates with jujud agents on units describe how
>>> that is done?
>>>
>>> My limited understanding must be wrong give that James has this working.
>>>
>>> This is what I thought:
>>>
>>> On most cloud providers: add-machine instructs the cloud provider to
>>> start a new instance and the cloud-config passed to cloud-init includes how
>>> to download jujud agent and run it and configure it with public key trust
>>> of the juju controller.
>>>
>>> On manually added machine: same thing only instead of cloud-init and
>>> cloud-config an ssh connection is used to perform the same commands.
>>>
>>> I had thought the juju controller was initiating the ssh-connection to
>>> the address given in the add-machine command and that a non-internet
>>> routable address would simply not work as the controller cannot open any
>>> TCP connection to it. This is where my understanding stops.
>>>
>>> Please, anyone, describe how this works?
>>> --
>>> Jay
>>>
>>>
>>> On Fri, Jun 2, 2017 at 9:42 AM, James Beedy <jamesbe...@gmail.com>
>>> wrote:
>>>
>>>> I think the primary advantage being less clutter to the end user. The
>>>> difference between the end user have to bootstrap and control things from
>>>> inside the vm vs from their host. For some reason this small change made
>>>> some of my users who were previously not really catching on, far more apt
>>>> to jump in. I personally like it because these little vms go further when
>>>> they don't have the controller on them as well. @jameinel totally, possibly
>>>> I'll add the bridge bits in place of the lxd-proxy in that write up, or
>>>> possibly in another.
>>>>
>>>> ~James
>>>>
>>>> On Jun 2, 2017, at 12:56 AM, John Meinel <j...@arbash-meinel.com>
>>>> wrote:
>>>>
>>>> Interesti

Re: OS X VMS on JAAS

[James Beedy]

@john, @andrew thanks for the details here

On Sat, Jun 3, 2017 at 10:21 PM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> On Sat, Jun 3, 2017 at 2:56 PM John Meinel <j...@arbash-meinel.com> wrote:
>
>> You can add a manually provisioned machine to any model, as long as there
>> is connectivity from the machine to the controller. Now, I would have
>> thought initial setup was initiated by the Controller, but its possible
>> that initial setup is actually initiated from the client.
>>
>
> Given the command:
>
> $ juju add-machine ssh:
>
> it goes something like this:
>
> 1. client connects to  via SSH, and performs basic hardware/OS
> discovery
> 2. client asks controller to add a machine entry, and controller returns a
> script to be executed on the target machine, using the discovered details,
> in order to fetch and install jujud
> 3. client executes that script over the SSH connection
>
> Once initial setup is complete, then it is definitely true that all
>> connections are initiated from the agent running on the controlled machine
>> to the controller. The controller no longer tries to socket.connect to the
>> machine. (In 1.X 'actions' were initiated via ssh from the controller, but
>> in 2.X the agents listen to see if there are any actions to run like they
>> do for all other changes.)
>>
>> Now, given that he added a model into "us-east-1" if he ever did just a
>> plain "juju add-machine" or "juju deploy" (without --to) it would
>> definitely create a new instance in AWS and start configuring it, rather
>> than from your VM.
>>
>> Which is why using something like the "lxd provider" would be a more
>> natural use case, but according to James the sticking point is having to
>> set up a controller in the first place. So "--to lxd:0" is easier for them
>> to think about than setting up a provider and letting it decide how to
>> allocate machines.
>>
>> Note, it probably wouldn't be possible to use JAAS to drive an LXD
>> provider, because *that* would have JAAS be trying to make a direct
>> connection to your LXD agent in order to provision the next machine.
>> However "--to lxd:0" has the local juju agent (running for 'machine 0')
>> talking to the local LXD agent in order to create a container.
>>
>> John
>> =:->
>>
>>
>> On Fri, Jun 2, 2017 at 6:28 PM, Jay Wren <jay.w...@canonical.com> wrote:
>>
>>> I do not understand how this works. Could someone with knowledge of how
>>> jujud on a  controller communicates with jujud agents on units describe how
>>> that is done?
>>>
>>> My limited understanding must be wrong give that James has this working.
>>>
>>> This is what I thought:
>>>
>>> On most cloud providers: add-machine instructs the cloud provider to
>>> start a new instance and the cloud-config passed to cloud-init includes how
>>> to download jujud agent and run it and configure it with public key trust
>>> of the juju controller.
>>>
>>> On manually added machine: same thing only instead of cloud-init and
>>> cloud-config an ssh connection is used to perform the same commands.
>>>
>>> I had thought the juju controller was initiating the ssh-connection to
>>> the address given in the add-machine command and that a non-internet
>>> routable address would simply not work as the controller cannot open any
>>> TCP connection to it. This is where my understanding stops.
>>>
>>> Please, anyone, describe how this works?
>>> --
>>> Jay
>>>
>>>
>>> On Fri, Jun 2, 2017 at 9:42 AM, James Beedy <jamesbe...@gmail.com>
>>> wrote:
>>>
>>>> I think the primary advantage being less clutter to the end user. The
>>>> difference between the end user have to bootstrap and control things from
>>>> inside the vm vs from their host. For some reason this small change made
>>>> some of my users who were previously not really catching on, far more apt
>>>> to jump in. I personally like it because these little vms go further when
>>>> they don't have the controller on them as well. @jameinel totally, possibly
>>>> I'll add the bridge bits in place of the lxd-proxy in that write up, or
>>>> possibly in another.
>>>>
>>>> ~James
>>>>
>>>> On Jun 2, 2017, at 12:56 AM, John Meinel <j...@arbash-meinel.com>
>>>> wrote:
>>>>
>>>> Interesti

Re: OS X VMS on JAAS

[James Beedy]

The communication is from the agent to controller only from my
understanding. This is what allows a user to provision juju deployed
infrastructure behind any nat gateway, and for lxd deploys to work on
providers without juju networking support for containers (where the
containers get the lxdbr0 nat). Here is a good example of both scenarios in
one model http://paste.ubuntu.com/24749128/

On Fri, Jun 2, 2017 at 7:28 AM, Jay Wren <jay.w...@canonical.com> wrote:

> I do not understand how this works. Could someone with knowledge of how
> jujud on a  controller communicates with jujud agents on units describe how
> that is done?
>
> My limited understanding must be wrong give that James has this working.
>
> This is what I thought:
>
> On most cloud providers: add-machine instructs the cloud provider to start
> a new instance and the cloud-config passed to cloud-init includes how to
> download jujud agent and run it and configure it with public key trust of
> the juju controller.
>
> On manually added machine: same thing only instead of cloud-init and
> cloud-config an ssh connection is used to perform the same commands.
>
> I had thought the juju controller was initiating the ssh-connection to the
> address given in the add-machine command and that a non-internet routable
> address would simply not work as the controller cannot open any TCP
> connection to it. This is where my understanding stops.
>
> Please, anyone, describe how this works?
> --
> Jay
>
>
> On Fri, Jun 2, 2017 at 9:42 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
>> I think the primary advantage being less clutter to the end user. The
>> difference between the end user have to bootstrap and control things from
>> inside the vm vs from their host. For some reason this small change made
>> some of my users who were previously not really catching on, far more apt
>> to jump in. I personally like it because these little vms go further when
>> they don't have the controller on them as well. @jameinel totally, possibly
>> I'll add the bridge bits in place of the lxd-proxy in that write up, or
>> possibly in another.
>>
>> ~James
>>
>> On Jun 2, 2017, at 12:56 AM, John Meinel <j...@arbash-meinel.com> wrote:
>>
>> Interesting. I wouldn't have thought to use a manually added machine to
>> use JAAS to deploy applications to your local virtualbox. Is there a reason
>> this is easier than just "juju bootstrap lxd" from inside the VM?
>>
>> I suppose our default lxd provider puts the new containers on a NAT
>> bridge, though you can reconfigure 'lxdbr0' to bridge your 'eth0' as well.
>>
>> John
>> =:->
>>
>>
>> On Fri, Jun 2, 2017 at 8:33 AM, James Beedy <jamesbe...@gmail.com> wrote:
>>
>>> https://medium.com/@jamesbeedy/using-jaas-to-deploy-lxd-cont
>>> ainers-to-virtualbox-vms-on-os-x-a06a8046756a
>>>
>>> --
>>> Juju-dev mailing list
>>> juju-...@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>>>
>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: OS X VMS on JAAS

[James Beedy]

The communication is from the agent to controller only from my
understanding. This is what allows a user to provision juju deployed
infrastructure behind any nat gateway, and for lxd deploys to work on
providers without juju networking support for containers (where the
containers get the lxdbr0 nat). Here is a good example of both scenarios in
one model http://paste.ubuntu.com/24749128/

On Fri, Jun 2, 2017 at 7:28 AM, Jay Wren <jay.w...@canonical.com> wrote:

> I do not understand how this works. Could someone with knowledge of how
> jujud on a  controller communicates with jujud agents on units describe how
> that is done?
>
> My limited understanding must be wrong give that James has this working.
>
> This is what I thought:
>
> On most cloud providers: add-machine instructs the cloud provider to start
> a new instance and the cloud-config passed to cloud-init includes how to
> download jujud agent and run it and configure it with public key trust of
> the juju controller.
>
> On manually added machine: same thing only instead of cloud-init and
> cloud-config an ssh connection is used to perform the same commands.
>
> I had thought the juju controller was initiating the ssh-connection to the
> address given in the add-machine command and that a non-internet routable
> address would simply not work as the controller cannot open any TCP
> connection to it. This is where my understanding stops.
>
> Please, anyone, describe how this works?
> --
> Jay
>
>
> On Fri, Jun 2, 2017 at 9:42 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
>> I think the primary advantage being less clutter to the end user. The
>> difference between the end user have to bootstrap and control things from
>> inside the vm vs from their host. For some reason this small change made
>> some of my users who were previously not really catching on, far more apt
>> to jump in. I personally like it because these little vms go further when
>> they don't have the controller on them as well. @jameinel totally, possibly
>> I'll add the bridge bits in place of the lxd-proxy in that write up, or
>> possibly in another.
>>
>> ~James
>>
>> On Jun 2, 2017, at 12:56 AM, John Meinel <j...@arbash-meinel.com> wrote:
>>
>> Interesting. I wouldn't have thought to use a manually added machine to
>> use JAAS to deploy applications to your local virtualbox. Is there a reason
>> this is easier than just "juju bootstrap lxd" from inside the VM?
>>
>> I suppose our default lxd provider puts the new containers on a NAT
>> bridge, though you can reconfigure 'lxdbr0' to bridge your 'eth0' as well.
>>
>> John
>> =:->
>>
>>
>> On Fri, Jun 2, 2017 at 8:33 AM, James Beedy <jamesbe...@gmail.com> wrote:
>>
>>> https://medium.com/@jamesbeedy/using-jaas-to-deploy-lxd-cont
>>> ainers-to-virtualbox-vms-on-os-x-a06a8046756a
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>>>
>>>
>>
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: OS X VMS on JAAS

[James Beedy]

I think the primary advantage being less clutter to the end user. The 
difference between the end user have to bootstrap and control things from 
inside the vm vs from their host. For some reason this small change made some 
of my users who were previously not really catching on, far more apt to jump 
in. I personally like it because these little vms go further when they don't 
have the controller on them as well. @jameinel totally, possibly I'll add the 
bridge bits in place of the lxd-proxy in that write up, or possibly in another.

~James

> On Jun 2, 2017, at 12:56 AM, John Meinel <j...@arbash-meinel.com> wrote:
> 
> Interesting. I wouldn't have thought to use a manually added machine to use 
> JAAS to deploy applications to your local virtualbox. Is there a reason this 
> is easier than just "juju bootstrap lxd" from inside the VM?
> 
> I suppose our default lxd provider puts the new containers on a NAT bridge, 
> though you can reconfigure 'lxdbr0' to bridge your 'eth0' as well.
> 
> John
> =:->
> 
> 
>> On Fri, Jun 2, 2017 at 8:33 AM, James Beedy <jamesbe...@gmail.com> wrote:
>> https://medium.com/@jamesbeedy/using-jaas-to-deploy-lxd-containers-to-virtualbox-vms-on-os-x-a06a8046756a
>> 
>> --
>> 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

OS X VMS on JAAS

[James Beedy]

https://medium.com/@jamesbeedy/using-jaas-to-deploy-lxd-containers-to-virtualbox-vms-on-os-x-a06a8046756a
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

OS X VMS on JAAS

[James Beedy]

https://medium.com/@jamesbeedy/using-jaas-to-deploy-lxd-containers-to-virtualbox-vms-on-os-x-a06a8046756a
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

GUI Props

[James Beedy]

The latest Juju GUI release is a huge step in the right direction! Amongst
the great improvements, the account page is really the start to something
great! Massive props and many thanks to all who have put in hard work and
long hours to bring the GUI to where it is today.

Looking forward, I'm wondering if the account page would be a good place to
manage ssh keys too?

Either way, nice work here!
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

GUI Props

[James Beedy]

The latest Juju GUI release is a huge step in the right direction! Amongst
the great improvements, the account page is really the start to something
great! Massive props and many thanks to all who have put in hard work and
long hours to bring the GUI to where it is today.

Looking forward, I'm wondering if the account page would be a good place to
manage ssh keys too?

Either way, nice work here!
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

JUJU_UNIT_NAME no longer set in env

[James Beedy]

Juju 2.1.2

I'm getting this "JUJU_UNIT_NAME not in env" error on legacy-non-reactive
xenial charm using service_name() from hookenv.

http://paste.ubuntu.com/24626263/

Did we remove this?

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

JUJU_UNIT_NAME no longer set in env

[James Beedy]

Juju 2.1.2

I'm getting this "JUJU_UNIT_NAME not in env" error on legacy-non-reactive
xenial charm using service_name() from hookenv.

http://paste.ubuntu.com/24626263/

Did we remove this?

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

Re: Python-Django

[James Beedy]

The python-Django charm is largely outdated in many respects. I have been 
meaning to do a deep dive on it and turn it into something usable (there have 
been a few attempts at this over the years we can also look at). I can apply 
some of the goodies I've developed for my rails-layer in the Django charm too, 
see https://github.com/jamesbeedy/layer-rails-base.

@Lonroth I'll create a new layer for Django and share it when I get something 
up there. Should be sometime this week.

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

Re: Deploy Windows - What are my options?

[James Beedy]

Gabriel,

Thanks for looking into this.

~James

On Sat, May 13, 2017 at 4:55 PM, Gabriel Samfira <
gsamf...@cloudbasesolutions.com> wrote:

> So there seem to be 2 problems here:
>
> * No windows image in simplestreams
> * Windows userdata has grown beyond 16KB
>
> For the first issue, a custom simplestreams should work. I will send a PR
> for the second issue. I am surprised the CI did not catch this. Will also
> ping the CI team about doing a windows workload test on ec2.
>
> Apologies for this. Please try deploying on top of azure.
>
> On May 13, 2017 12:50 PM, James Beedy <jamesbe...@gmail.com> wrote:
>
> Thanks, Mark. Those were my expectations (but http://paste.ubuntu.com/
> 24568556/ says otherwise). Working with Gabriel on this now.
>
> On Sat, May 13, 2017 at 9:43 AM, Mark Shuttleworth <m...@ubuntu.com>
> wrote:
>
> On 13/05/17 09:58, James Beedy wrote:
> > I'm having a hard time determining what my options are for deploying
> > Windows via Juju. Are there docs for deploying Windows anywhere?
>
> I *think* you just need a Windows with cloudbase-init installed, and to
> tell Juju to use that image. On the standard public clouds it should
> Just Work, on your own cloud you will need to provide the image and tell
> Juju which one it is per series.
>
> Mark
>
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Deploy Windows - What are my options?

[James Beedy]

Thanks, Mark. Those were my expectations (but
http://paste.ubuntu.com/24568556/ says otherwise). Working with Gabriel on
this now.

On Sat, May 13, 2017 at 9:43 AM, Mark Shuttleworth <m...@ubuntu.com> wrote:

> On 13/05/17 09:58, James Beedy wrote:
> > I'm having a hard time determining what my options are for deploying
> > Windows via Juju. Are there docs for deploying Windows anywhere?
>
> I *think* you just need a Windows with cloudbase-init installed, and to
> tell Juju to use that image. On the standard public clouds it should
> Just Work, on your own cloud you will need to provide the image and tell
> Juju which one it is per series.
>
> Mark
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Deploy Windows - What are my options?

[James Beedy]

Tried win2012 and win2016 ... same thing. http://paste.ubuntu.com/24568511/

On Sat, May 13, 2017 at 9:37 AM, Gabriel Samfira <
gsamf...@cloudbasesolutions.com> wrote:

> Looking into it. Please also try:
>
> win2012
> win2016
>
> As well, while I investigate.
>
>
>
> On May 13, 2017 12:35 PM, James Beedy <jamesbe...@gmail.com> wrote:
>
> `juju status --format yaml`  http://paste.ubuntu.com/24568493/
>
> Possibly I need to pass an 'arch` flag?
>
> On Sat, May 13, 2017 at 9:32 AM, Gabriel Samfira <
> gsamf...@cloudbasesolutions.com> wrote:
>
> Could you paste the output of:
>
> juju status --format yaml
>
> ?
>
> On May 13, 2017 12:31 PM, James Beedy <jamesbe...@gmail.com> wrote:
>
> `juju add-machine --series win2012r2` leaves me with
> http://paste.ubuntu.com/24568478/ :(
>
>
> On Sat, May 13, 2017 at 9:25 AM, Gabriel Samfira <
> gsamf...@cloudbasesolutions.com> wrote:
>
> No need. Azure and aws should work out of the box. Let me know if it does
> not.
>
> Just bootstrap and try to deploy.
>
> On May 13, 2017 12:24 PM, James Beedy <jamesbe...@gmail.com> wrote:
>
> I was thinking there is a possibility of manually deploying the windows
> box and then adding it via `juju add-machine`. Is this a possibility?
>
>
> On Sat, May 13, 2017 at 9:16 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
> Gabriel,
>
> I have some upcoming projects that need be deployed on Windows, hence I am
> trying to gather my options so I can make an educated decision.  Not really
> locked into a specific cloud, but the Windows box will be talking to
> database(s) that live in AWS, so I was hoping to be able to deploy the
> Windows box into the private address space alongside the db on AWS so I
> won't have to expose it cross the wan and get reamed for the egress. So AWS
> would be preferable, but I'm open to entertaining any other options that
> may exist.
>
> ~James
>
> On Sat, May 13, 2017 at 7:01 AM, Gabriel Samfira <
> gsamf...@cloudbasesolutions.com> wrote:
>
> Hi James,
>
>
> It depends a little bit on the cloud and whether or not they have the
> necessary images.
>
> It would help to know which cloud you are targeting.
>
> Gabriel
>
> On May 13, 2017 9:59 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
> I'm having a hard time determining what my options are for deploying
> Windows via Juju. Are there docs for deploying Windows anywhere?
>
> ~James
>
>
>
>
>
>
>
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Deploy Windows - What are my options?

[James Beedy]

`juju status --format yaml`  http://paste.ubuntu.com/24568493/

Possibly I need to pass an 'arch` flag?

On Sat, May 13, 2017 at 9:32 AM, Gabriel Samfira <
gsamf...@cloudbasesolutions.com> wrote:

> Could you paste the output of:
>
> juju status --format yaml
>
> ?
>
> On May 13, 2017 12:31 PM, James Beedy <jamesbe...@gmail.com> wrote:
>
> `juju add-machine --series win2012r2` leaves me with
> http://paste.ubuntu.com/24568478/ :(
>
>
> On Sat, May 13, 2017 at 9:25 AM, Gabriel Samfira <
> gsamf...@cloudbasesolutions.com> wrote:
>
> No need. Azure and aws should work out of the box. Let me know if it does
> not.
>
> Just bootstrap and try to deploy.
>
> On May 13, 2017 12:24 PM, James Beedy <jamesbe...@gmail.com> wrote:
>
> I was thinking there is a possibility of manually deploying the windows
> box and then adding it via `juju add-machine`. Is this a possibility?
>
>
> On Sat, May 13, 2017 at 9:16 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
> Gabriel,
>
> I have some upcoming projects that need be deployed on Windows, hence I am
> trying to gather my options so I can make an educated decision.  Not really
> locked into a specific cloud, but the Windows box will be talking to
> database(s) that live in AWS, so I was hoping to be able to deploy the
> Windows box into the private address space alongside the db on AWS so I
> won't have to expose it cross the wan and get reamed for the egress. So AWS
> would be preferable, but I'm open to entertaining any other options that
> may exist.
>
> ~James
>
> On Sat, May 13, 2017 at 7:01 AM, Gabriel Samfira <
> gsamf...@cloudbasesolutions.com> wrote:
>
> Hi James,
>
>
> It depends a little bit on the cloud and whether or not they have the
> necessary images.
>
> It would help to know which cloud you are targeting.
>
> Gabriel
>
> On May 13, 2017 9:59 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
> I'm having a hard time determining what my options are for deploying
> Windows via Juju. Are there docs for deploying Windows anywhere?
>
> ~James
>
>
>
>
>
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Deploy Windows - What are my options?

[James Beedy]

`juju add-machine --series win2012r2` leaves me with
http://paste.ubuntu.com/24568478/ :(


On Sat, May 13, 2017 at 9:25 AM, Gabriel Samfira <
gsamf...@cloudbasesolutions.com> wrote:

> No need. Azure and aws should work out of the box. Let me know if it does
> not.
>
> Just bootstrap and try to deploy.
>
> On May 13, 2017 12:24 PM, James Beedy <jamesbe...@gmail.com> wrote:
>
> I was thinking there is a possibility of manually deploying the windows
> box and then adding it via `juju add-machine`. Is this a possibility?
>
>
> On Sat, May 13, 2017 at 9:16 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
> Gabriel,
>
> I have some upcoming projects that need be deployed on Windows, hence I am
> trying to gather my options so I can make an educated decision.  Not really
> locked into a specific cloud, but the Windows box will be talking to
> database(s) that live in AWS, so I was hoping to be able to deploy the
> Windows box into the private address space alongside the db on AWS so I
> won't have to expose it cross the wan and get reamed for the egress. So AWS
> would be preferable, but I'm open to entertaining any other options that
> may exist.
>
> ~James
>
> On Sat, May 13, 2017 at 7:01 AM, Gabriel Samfira <
> gsamf...@cloudbasesolutions.com> wrote:
>
> Hi James,
>
>
> It depends a little bit on the cloud and whether or not they have the
> necessary images.
>
> It would help to know which cloud you are targeting.
>
> Gabriel
>
> On May 13, 2017 9:59 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
> I'm having a hard time determining what my options are for deploying
> Windows via Juju. Are there docs for deploying Windows anywhere?
>
> ~James
>
>
>
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Deploy Windows - What are my options?

[James Beedy]

I was thinking there is a possibility of manually deploying the windows box
and then adding it via `juju add-machine`. Is this a possibility?


On Sat, May 13, 2017 at 9:16 AM, James Beedy <jamesbe...@gmail.com> wrote:

> Gabriel,
>
> I have some upcoming projects that need be deployed on Windows, hence I am
> trying to gather my options so I can make an educated decision.  Not really
> locked into a specific cloud, but the Windows box will be talking to
> database(s) that live in AWS, so I was hoping to be able to deploy the
> Windows box into the private address space alongside the db on AWS so I
> won't have to expose it cross the wan and get reamed for the egress. So AWS
> would be preferable, but I'm open to entertaining any other options that
> may exist.
>
> ~James
>
> On Sat, May 13, 2017 at 7:01 AM, Gabriel Samfira <
> gsamf...@cloudbasesolutions.com> wrote:
>
>> Hi James,
>>
>>
>> It depends a little bit on the cloud and whether or not they have the
>> necessary images.
>>
>> It would help to know which cloud you are targeting.
>>
>> Gabriel
>>
>> On May 13, 2017 9:59 AM, James Beedy <jamesbe...@gmail.com> wrote:
>>
>> I'm having a hard time determining what my options are for deploying
>> Windows via Juju. Are there docs for deploying Windows anywhere?
>>
>> ~James
>>
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Deploy Windows - What are my options?

[James Beedy]

Gabriel,

I have some upcoming projects that need be deployed on Windows, hence I am
trying to gather my options so I can make an educated decision.  Not really
locked into a specific cloud, but the Windows box will be talking to
database(s) that live in AWS, so I was hoping to be able to deploy the
Windows box into the private address space alongside the db on AWS so I
won't have to expose it cross the wan and get reamed for the egress. So AWS
would be preferable, but I'm open to entertaining any other options that
may exist.

~James

On Sat, May 13, 2017 at 7:01 AM, Gabriel Samfira <
gsamf...@cloudbasesolutions.com> wrote:

> Hi James,
>
>
> It depends a little bit on the cloud and whether or not they have the
> necessary images.
>
> It would help to know which cloud you are targeting.
>
> Gabriel
>
> On May 13, 2017 9:59 AM, James Beedy <jamesbe...@gmail.com> wrote:
>
> I'm having a hard time determining what my options are for deploying
> Windows via Juju. Are there docs for deploying Windows anywhere?
>
> ~James
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Deploy Windows - What are my options?

[James Beedy]

I'm having a hard time determining what my options are for deploying
Windows via Juju. Are there docs for deploying Windows anywhere?

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

Inherited Constraints Causing LXD to Fail

[James Beedy]

It looks like any LXD I deploy to an instance on AWS is now inheriting the
constraints from the host, this is causing my LXD to fail across the board.

This is slightly difficult to reproduce, as you must have spaces and
subnets defined on AWS.

This bug does not show do not add any 'spaces' constraints.

The following will succeed:

$ juju deploy ubuntu # gets machine id 0
$ juju deploy ubuntu ubuntu-lxd --to lxd:0


The following will cause the lxd deploy to fail:

$ juju deploy ubuntu --constraints "spaces=myspace" # gets machine id 0
$ juju deploy ubuntu ubuntu-lxd --to lxd:0


The odd thing about this is, that it didn't start happening until this
week. I've been harping on this use case for a while now with no such
problems, then Monday morning rolls around, I go to spin up some new lxd
envs, and nothing  I've been blocked all week from sending any deploys.

This is a critical issue for me, any help would be greatly appreciated.

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

Inherited Constraints Causing LXD to Fail

[James Beedy]

It looks like any LXD I deploy to an instance on AWS is now inheriting the
constraints from the host, this is causing my LXD to fail across the board.

This is slightly difficult to reproduce, as you must have spaces and
subnets defined on AWS.

This bug does not show do not add any 'spaces' constraints.

The following will succeed:

$ juju deploy ubuntu # gets machine id 0
$ juju deploy ubuntu ubuntu-lxd --to lxd:0


The following will cause the lxd deploy to fail:

$ juju deploy ubuntu --constraints "spaces=myspace" # gets machine id 0
$ juju deploy ubuntu ubuntu-lxd --to lxd:0


The odd thing about this is, that it didn't start happening until this
week. I've been harping on this use case for a while now with no such
problems, then Monday morning rolls around, I go to spin up some new lxd
envs, and nothing  I've been blocked all week from sending any deploys.

This is a critical issue for me, any help would be greatly appreciated.

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

CDK + Deis

[James Beedy]

Wondering if there is any interest out in running Deis on top of CDK?

I was able to get Deis working atop CDK with some elbow grease and some
inside info from @lazyPower a while back, but it was a bit rough.

One of the departments in my company insists on running/deploying their
apps using Deis, so I will be putting a bit more effort into finding a path
forward for here in hopes we can get CDK running underneath.

If anyone is interested in, or has done work with Deis + CDK give me a
shout and lets match notes.

I'm going to be giving it another go with the latest CDK and the latest
Deis here this weekend/next week, hopefully I can come up with some solid
docs at least.

I'll report back with my findings~
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Goodbye Opsworks

[James Beedy]

Sam & MerIijn,

I'll be working on a blog post for it this week, I'll ping the list when it's 
ready.

> On Apr 3, 2017, at 7:11 AM, Merlijn Sebrechts <merlijn.sebrec...@gmail.com> 
> wrote:
> 
> Any ideas to write a blogpost about it? I'm curious about what problems Juju 
> solves that were hard with opswork and your experience in making the switch.
> 
> 2017-04-01 3:06 GMT+02:00 James Beedy <jamesbe...@gmail.com>:
>> The day has finally come for me to turn down the last of our Opsworks 
>> instances for our PRM application. This marks the completion of one of many 
>> Opsworks -> Juju conversion projects I've taken on. Thanks everyone for your 
>> help along the way!
>> 
>> Goodbye Opsworks - http://imgur.com/a/4pkgP
>> 
>> Hello Juju PRM!
>> 
>> Staging - http://paste.ubuntu.com/24291143/ 
>> Demo - http://paste.ubuntu.com/24291156/
>> Production - http://paste.ubuntu.com/24291133/
>> Walmart - http://paste.ubuntu.com/24291173/
>> 
>> W00T!
>> 
>> --
>> 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

Goodbye Opsworks

[James Beedy]

The day has finally come for me to turn down the last of our Opsworks
instances for our PRM application. This marks the completion of one of many
Opsworks -> Juju conversion projects I've taken on. Thanks everyone for
your help along the way!

Goodbye Opsworks - http://imgur.com/a/4pkgP

Hello Juju PRM!

Staging - http://paste.ubuntu.com/24291143/
Demo - http://paste.ubuntu.com/24291156/
Production - http://paste.ubuntu.com/24291133/
Walmart - http://paste.ubuntu.com/24291173/

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