Re: Specify lxd container bridge

2016-09-19 Thread Corey Bryant 
I just wanted to follow up on this thread to say I tested with a
pre-release of juju rc1 and it fixed up the issues I was hitting.

On Sat, Sep 17, 2016 at 9:04 AM, Dimiter Naydenov <
dimiter.nayde...@canonical.com> wrote:

> Hey Corey,
>
> That specific error I haven't seen at that stage - allocating container
> addresses. Can you please paste the machine-0.log as well? Are you able
> to consistently reproduce this or it's intermittent?
>
> Cheers,
> Dimiter
>
> On 09/17/2016 12:17 AM, Corey Bryant wrote:
> >
> >
> > On Thu, Sep 1, 2016 at 4:25 AM, Dimiter Naydenov
> > <dimiter.nayde...@canonical.com <mailto:dimiter.nayde...@canonical.com>>
> > wrote:
> >
> > Hello!
> >
> > When using juju 2.0 on maas 1.9 or 2.0, you should get lxd containers
> > provisioned with as many interfaces as their host machine has,
> because
> > we're creating bridges on all configured host interfaces at initial
> boot
> > (e.g. eth0 becomes br-eth0, ens4.250 - br-ens4.250 and so on).
> Nothing
> > needs configuring to get this behaviour, but there's a caveat:
> >
> > In order for the above to work, there's a limitation currently being
> > addressed - all interfaces on the host machine in MAAS need to be
> linked
> > to a subnet and have an IP address configured - either as Static or
> > Auto, but not DHCP or Unconfigured. Otherwise the process of
> allocating
> > addresses for the container (represented as a MAAS Device, visible on
> > the host node's details page in MAAS UI under Containers and VMs) can
> > fail half way through and Juju will instead fall back to a the single
> > NIC LXD default profile, using lxdbr0 on a local subnet. You can tell
> > whether this happened, because there will be a WARNING in
> > /var/log/juju/machine-0.log on the bootstrap machine, like: `failed
> to
> > prepare container "0/lxd/0" network config: ...` describing the
> > underlying error encountered.
> >
> > Please note, the above limitation will be gone very soon - likely
> > beta18, not beta17 scheduled for release this week. In that upcoming
> > beta, unlinked or unconfigured host machine interfaces won't prevent
> the
> > multi-NIC container provisioning and address allocation - Juju will
> just
> > allocate addresses where it can, leaving the rest unconfigured, and
> not
> > falling back to using LXD default profile's lxdbr0.
> >
> > HTH,
> > Dimiter
> >
> >
> > Hey Dimiter,
> >
> > I'm hitting the same issue.  I have all the interfaces linked to subnets
> > with auto but I still get the 'failed to prepare container "0/lxd/0"'
> > error message saying 'connection is shut down'.  The containers are
> > still using lxdbr0 (see http://paste.ubuntu.com/23188824/
> > <http://paste.ubuntu.com/23188824/>).  The containers show up on the
> > nodes page with juju*-lxd-*.maas names.  Do you have any other tips for
> > getting past this?
> >
> > Thanks,
> > Corey
>
>
> --
> Dimiter Naydenov <dimiter.nayde...@canonical.com>
> Juju Core Sapphire team <http://juju.ubuntu.com>
>
>


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

Re: charmers + openstack-charmers application

2016-02-22 Thread Corey Bryant 
Ryan is has made some great contributions to the OpenStack charms
particularly in the testing realm and has played a huge role in ensuring
the code remains stable.  I'm only an OpenStack charmer myself, so +1 for
openstack-charmers.

On Fri, Feb 19, 2016 at 10:24 AM, Billy Olsen 
wrote:

> I'm not a Juju Charmer, but I am an OpenStack Charmer and Ryan's
> contributions have been invaluable. A very big +1 from me.
>
> On Fri, Feb 19, 2016 at 8:23 AM, José Antonio Rey  wrote:
>
>> Hey Ryan,
>>
>> I'm glad to see your application! You've definitely made valuable
>> contributions in the past months, and I'm very familiar with all the hard
>> work you've put into the charm ecosystem.
>>
>> I'm more than happy to give you a +1 on my side. Thanks for all the work
>> you do!
>>
>>
>> On 02/19/2016 10:14 AM, Ryan Beisner wrote:
>>
>>> Happy Friday, charmers!
>>>
>>> Please consider my application for membership to ~charmers and an
>>> ~openstack-charmers.
>>>
>>> Over the past two years, I've contributed to each of the 20+ OpenStack
>>> charms (and jenkins, ubuntu, mysql, mongodb).  While most of my work has
>>> been in the field of charm testing, I've done a load of reviews, bug
>>> triage, bug fixes, charm and charm-helper contributions, partner and
>>> feature integration and validation.
>>>
>>> As a ~charm-contributors member, I've watched the broader charm review
>>> queue for the proposals where I have specific domain knowledge, and have
>>> taken some of those reviews.
>>>
>>> One of my babies is the Ubuntu OpenStack Charm Integration test
>>> automation system (aka UOSCI).  That system continuously gates our
>>> Ubuntu OpenStack development activity, charm and package SRU and release
>>> processes.  It has deployed and tested ~14,000+ OpenStack clouds in the
>>> past ~1yr, plus all of the accompanying amulet, lint, mojo and unit
>>> tests.
>>>
>>> As Juju core approaches and reaches "proposed" in each dev cycle, we
>>> flip some bits and hammer on the proposed Juju version in the UOSCI
>>> automation as a pre-release cross-validation effort.  Same for MAAS.
>>>
>>> I've delivered and participated in remote and in-person customer demos
>>> of our tool sets and charms, and have given UOS and Charmer Summit demos
>>> and talks.  I've made a point over the past year or so to chip in on
>>> AskUbuntu, generally with OpenStack-specific questions.
>>>
>>>
>>> I am:
>>>   - https://github.com/ryan-beisner
>>>   - https://launchpad.net/~1chb1n
>>>   - https://launchpad.net/~1chb1n/+karma
>>>   - http://askubuntu.com/users/382225/beisner
>>>
>>> Bugs:
>>>   - https://goo.gl/vUsGXN
>>>
>>> My alternate bot identities work while I sleep:
>>>   - https://github.com/uoscibot
>>>   - https://launchpad.net/~uosci-testing-bot
>>>
>>> Other points of interest:
>>>   -
>>> https://code.launchpad.net/~ost-maintainers/openstack-charm-testing/trunk
>>>   -
>>>
>>> https://code.launchpad.net/~ost-maintainers/openstack-mojo-specs/mojo-openstack-specs
>>>   - https://github.com/openstack-charmers
>>>   -
>>>
>>> http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/files/head:/charmhelpers/contrib/openstack/amulet/
>>>   -
>>>
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/ceilometer/next
>>>   -
>>>
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/ceilometer-agent/next
>>>   -
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/ceph/next
>>>   -
>>>
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/ceph-osd/next
>>>   -
>>>
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/ceph-radosgw/next
>>>   -
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/cinder/next
>>>   -
>>>
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/cinder-ceph/next
>>>   -
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/glance/next
>>>   -
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/heat/next
>>>   -
>>>
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/keystone/next
>>>   -
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/lxd/next
>>>   -
>>>
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/neutron-api/next
>>>   -
>>>
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/neutron-gateway/next
>>>   -
>>>
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/neutron-openvswitch/next
>>>   -
>>>
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/nova-cloud-controller/next
>>>   -
>>>
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/nova-compute/next
>>>   -
>>>
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/openstack-dashboard/next
>>>   -
>>>
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/percona-cluster/next
>>>   -
>>>
>>> https://code.launchpad.net/~openstack-charmers/charms/trusty/rabbitmq-server/next
>>>   -
>>>
>>>

Re: bind mount support for local provider

2015-01-20 Thread Corey Bryant 
On Sun, Jan 18, 2015 at 8:01 PM, Andrew Wilkins 
andrew.wilk...@canonical.com wrote:

 On Sat, Jan 17, 2015 at 11:47 PM, Corey Bryant corey.bry...@canonical.com
  wrote:

 Excellent, thanks Ian.  Do you have an estimate on when this will be
 available?


 Hi Corey,

 Not yet; we are working towards getting a single provider fully functional
 before delving too deeply into others. I'll ping you when we've got a
 better idea.


Ok, thanks Andrew.



 Cheers,
 Andrew


 On Fri, Jan 16, 2015 at 10:42 PM, Ian Booth ian.bo...@canonical.com
 wrote:

 Hi Cory

 This is part of what we are planning to deliver for this cycle as part
 of the
 storage work. We also plan on being able to provide the container with
 access to
 block devices eg loopback, either in container's filesystem or on the
 host machine.


 On 17/01/15 02:11, Corey Bryant wrote:
  Hi all,
 
  Do there happen to be any plans for juju bind mount support for the
 local
  provider?
 
  For example:  juju deploy mysql --bind /shared/mysql /shared
 
  which would bind mount the host /shared/mysql directory to /shared in
 the
  deployed container.
 
 
 




 --
 Regards,
 Corey

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





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

bind mount support for local provider

2015-01-16 Thread Corey Bryant 
Hi all,

Do there happen to be any plans for juju bind mount support for the local
provider?

For example:  juju deploy mysql --bind /shared/mysql /shared

which would bind mount the host /shared/mysql directory to /shared in the
deployed container.

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