[Review Queue] bird, neutron-calico, openbook, plumgrid-gateway

2016-01-25 Thread Cory Johns 
Greetings,

This past Friday, Andrew, Konstantinos, and I spent some time on the review
queue.

We'd like to thank the fine folks at MetaSwitch for their work on the bird
and neutron-calico charms, which add Project Calico and its virtual
networking support to OpenStack.


   -

   bird
   -

  https://bugs.launchpad.net/charms/+bug/1431445
  -

  Suggested changes were accepted.  Re-tested, passed, and the charm
  was promulgated.
  -

   neutron-calico
   -

  https://bugs.launchpad.net/charms/+bug/1421230
  -

  Suggested changes were accepted.  Re-tested, passed, and the charm
  was promulgated.
  -

   openbook
   -


  
https://code.launchpad.net/~talligent/charms/trusty/openbook/trunk/+merge/280525
  -

  Tests all pass - this was held back due to long dashes in the README
  and non-recommended tags in the metadata, neither of which will affect
  charm functionality. Suggesting this be merged as the value of the charm
  outweighs potential README issues.
  -

   plumgrid-gateway
   -


  
https://code.launchpad.net/~bbaqar/charms/trusty/plumgrid-gateway/charmers-next
  -

  Reviewing the fix for restarting the service in a timely fashion
  yields some more questions.
  -

  The bundletester spotted some code style errors.
  -

  We will have to wait for a response from the author, before we
  proceed with this merge.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Review Queue] bird, neutron-calico, openbook, plumgrid-gateway

2016-01-25 Thread Charles Butler 
Just as a follow up, I went ahead and merged the OpenBook MP, as it LGTM
aside from a few nits that really aren't blockers. Thanks for the attention
to detail.

All the best,


Charles Butler  - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com

On Mon, Jan 25, 2016 at 9:20 AM, Cory Johns 
wrote:

> Greetings,
>
> This past Friday, Andrew, Konstantinos, and I spent some time on the
> review queue.
>
> We'd like to thank the fine folks at MetaSwitch for their work on the bird
> and neutron-calico charms, which add Project Calico and its virtual
> networking support to OpenStack.
>
>
>-
>
>bird
>-
>
>   https://bugs.launchpad.net/charms/+bug/1431445
>   -
>
>   Suggested changes were accepted.  Re-tested, passed, and the charm
>   was promulgated.
>   -
>
>neutron-calico
>-
>
>   https://bugs.launchpad.net/charms/+bug/1421230
>   -
>
>   Suggested changes were accepted.  Re-tested, passed, and the charm
>   was promulgated.
>   -
>
>openbook
>-
>
>
>   
> https://code.launchpad.net/~talligent/charms/trusty/openbook/trunk/+merge/280525
>   -
>
>   Tests all pass - this was held back due to long dashes in the
>   README and non-recommended tags in the metadata, neither of which will
>   affect charm functionality. Suggesting this be merged as the value of 
> the
>   charm outweighs potential README issues.
>   -
>
>plumgrid-gateway
>-
>
>
>   
> https://code.launchpad.net/~bbaqar/charms/trusty/plumgrid-gateway/charmers-next
>   -
>
>   Reviewing the fix for restarting the service in a timely fashion
>   yields some more questions.
>   -
>
>   The bundletester spotted some code style errors.
>   -
>
>   We will have to wait for a response from the author, before we
>   proceed with this merge.
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Regarding Juju Support for IBM SoftLayer

2016-01-25 Thread Marco Ceppi 
Hi Shilpa,

Great question! We're really excited about SoftLayer cloud too and look
forward to using it. Unfortunately, we're still working with SoftLayer to
complete this work so you can't use it directly in Juju yet. However, Juju
does have a manual provider. So you could use Juju with SoftLayer by
provisioning the machines manually and then telling Juju where those
machines are. Instructions for that are here:
https://jujucharms.com/docs/devel/config-manual

Furthermore, since charms work everywhere, once we have the SoftLayer
provider completed charms will just work on them as they do AWS, local,
OpenStack, or all the other native providers.

Thanks,
Marco Ceppi

On Mon, Jan 25, 2016 at 3:39 AM Shilpa Kaul  wrote:

> Hi Team,
>
> I have a requirement where I need to deploy a charm on IBM SoftLayer
> Cloud. Can we give IBM SoftLayer as a cloud provider in Juju similar to AWS
> , local or OpenStack ?
>
>
> Thanks and Regards,
> Shilpa Kaul
> --
> 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

Juju stable 1.25.3 is now released

2016-01-25 Thread Curtis Hovey-Canonical 
# juju-core 1.25.3

A new stable release of Juju, juju-core 1.25.3, is now available.
This release replaces version 1.25.0.


## Getting Juju

juju-core 1.25.3 is available for Xenial and backported to earlier
series in the following PPA:

https://launchpad.net/~juju/+archive/stable

Windows, Centos, and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.25.3


## Notable Changes

This releases addresses stability and performance issues.


## Resolved issues

  * Unit loses network connectivity during bootstrap: juju 1.25.2 +
maas 1.9
Lp 1534795

 * "cannot allocate memory" when running "juju run"
Lp 1382556

  * Bootstrap with the vsphere provider fails to log into the virtual
machine
Lp 1511138

  * Add-machine with vsphere triggers machine-0: panic: juju home
hasn't been initialized
Lp 1513492

  * Using maas 1.9 as provider using dhcp nic will prevent juju
bootstrap
Lp 1512371

  * Worker/storageprovisioner: machine agents attempting to attach
environ-scoped volumes
Lp 1483492

  * Restore: agent old password not found in configuration
Lp 1452082

  * "ignore-machine-addresses" broken for containers
Lp 1509292

  * Deploying a service to a space which has no subnets causes the
agent to panic
Lp 1499426

  * /var/lib/juju gone after 1.18->1.20 upgrade and manual edit of
agent.conf
Lp 1444912

  * Juju bootstrap fails to successfully configure the bridge juju-br0
when deploying with wily 4.2 kernel
Lp 1496972

  * Incompatible cookie format change
Lp 1511717

  * Error environment destruction failed: destroying storage: listing
volumes: get https://x.x.x.x:8776/v2//volumes/detail: local
error: record overflow
Lp 1512399

  * Replica set emptyconfig maas bootstrap
Lp 1412621

  * Juju can't find daily image streams from cloud-
images.ubuntu.com/daily
Lp 1513982

  * Rsyslog certificate fails when using ipv6/4 dual stack with
prefer-ipv6: true
Lp 1478943

  * Improper address:port joining
Lp 1518128

  * Juju status  broken
Lp 1516989

  * 1.25.1 with maas 1.8: devices dns allocation uses non-unique
hostname
Lp 1525280

  * Increment minimum juju version for 2.0 upgrade to 1.25.3
Lp 1533751

  * Make assignment of units to machines use a worker
Lp 1497312

  * `juju environments` fails due to missing ~/.juju/current-
environment
Lp 1506680

  * Juju 1.25 misconfigures juju-br0 when using maas 1.9 bonded
interface
Lp 1516891

  * Destroy-environment on an unbootstrapped maas environment can
release all my nodes
Lp 1490865

  * On juju upgrade the security group lost ports for the exposed
services
Lp 1506649

  * Support centos and windows image metadata
Lp 1523693

  * Upgrade-juju shows available tools and best version but did not
output what it decided to do
Lp 1403655

  * Invalid binary version, version "1.23.3--amd64" or "1.23.3--armhf"
Lp 1459033

  * Add xenial to supported series
Lp 1533262


Finally

We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.


-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui

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

Juju stable 1.25.3 is now released

2016-01-25 Thread Curtis Hovey-Canonical 
# juju-core 1.25.3

A new stable release of Juju, juju-core 1.25.3, is now available.
This release replaces version 1.25.0.


## Getting Juju

juju-core 1.25.3 is available for Xenial and backported to earlier
series in the following PPA:

https://launchpad.net/~juju/+archive/stable

Windows, Centos, and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.25.3


## Notable Changes

This releases addresses stability and performance issues.


## Resolved issues

  * Unit loses network connectivity during bootstrap: juju 1.25.2 +
maas 1.9
Lp 1534795

 * "cannot allocate memory" when running "juju run"
Lp 1382556

  * Bootstrap with the vsphere provider fails to log into the virtual
machine
Lp 1511138

  * Add-machine with vsphere triggers machine-0: panic: juju home
hasn't been initialized
Lp 1513492

  * Using maas 1.9 as provider using dhcp nic will prevent juju
bootstrap
Lp 1512371

  * Worker/storageprovisioner: machine agents attempting to attach
environ-scoped volumes
Lp 1483492

  * Restore: agent old password not found in configuration
Lp 1452082

  * "ignore-machine-addresses" broken for containers
Lp 1509292

  * Deploying a service to a space which has no subnets causes the
agent to panic
Lp 1499426

  * /var/lib/juju gone after 1.18->1.20 upgrade and manual edit of
agent.conf
Lp 1444912

  * Juju bootstrap fails to successfully configure the bridge juju-br0
when deploying with wily 4.2 kernel
Lp 1496972

  * Incompatible cookie format change
Lp 1511717

  * Error environment destruction failed: destroying storage: listing
volumes: get https://x.x.x.x:8776/v2//volumes/detail: local
error: record overflow
Lp 1512399

  * Replica set emptyconfig maas bootstrap
Lp 1412621

  * Juju can't find daily image streams from cloud-
images.ubuntu.com/daily
Lp 1513982

  * Rsyslog certificate fails when using ipv6/4 dual stack with
prefer-ipv6: true
Lp 1478943

  * Improper address:port joining
Lp 1518128

  * Juju status  broken
Lp 1516989

  * 1.25.1 with maas 1.8: devices dns allocation uses non-unique
hostname
Lp 1525280

  * Increment minimum juju version for 2.0 upgrade to 1.25.3
Lp 1533751

  * Make assignment of units to machines use a worker
Lp 1497312

  * `juju environments` fails due to missing ~/.juju/current-
environment
Lp 1506680

  * Juju 1.25 misconfigures juju-br0 when using maas 1.9 bonded
interface
Lp 1516891

  * Destroy-environment on an unbootstrapped maas environment can
release all my nodes
Lp 1490865

  * On juju upgrade the security group lost ports for the exposed
services
Lp 1506649

  * Support centos and windows image metadata
Lp 1523693

  * Upgrade-juju shows available tools and best version but did not
output what it decided to do
Lp 1403655

  * Invalid binary version, version "1.23.3--amd64" or "1.23.3--armhf"
Lp 1459033

  * Add xenial to supported series
Lp 1533262


Finally

We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.


-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui

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

Regarding Juju Support for IBM SoftLayer

2016-01-25 Thread Shilpa Kaul 
Hi Team,

I have a requirement where I need to deploy a charm on IBM SoftLayer 
Cloud. Can we give IBM SoftLayer as a cloud provider in Juju similar to 
AWS , local or OpenStack ?


Thanks and Regards,
Shilpa Kaul

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

Re: Tags and object IDs

2016-01-25 Thread William Reade 
On Mon, Jan 25, 2016 at 12:07 PM, Nate Finch 
wrote:

> I was really trying not to give too much information about this exact
> case, so we could avoid talking about a specific implementation, and focus
> on the more general question of how we identify objects.  Yes, we get the
> bytes using an HTTP request, but that is irrelevant to my question :)
>

I thought I did answer the question:

But whenever we do record the unit-X-uses-resource-Y info I assume we'll
>>> have much the same stuff available in the apiserver, in which case I think
>>> you just want to pass the *Unit back into state; without it, you just need
>>> to read the doc from the DB all over again to make appropriate
>>> liveness/existence checks [0], and why bother unless you've already hit an
>>> assertion failure in your first txn attempt?
>>>
>>
...but perhaps I misunderstood what you were looking for?

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

Re: Tags and object IDs

2016-01-25 Thread Nate Finch 
I was really trying not to give too much information about this exact case,
so we could avoid talking about a specific implementation, and focus on the
more general question of how we identify objects.  Yes, we get the bytes
using an HTTP request, but that is irrelevant to my question :)

On Mon, Jan 25, 2016 at 2:00 AM John Meinel  wrote:

> On Sat, Jan 23, 2016 at 1:28 AM, William Reade <
> william.re...@canonical.com> wrote:
>
>> On Fri, Jan 22, 2016 at 9:53 PM, Nate Finch 
>> wrote:
>>
>>> Working in the model layer on the server between the API and the DB.
>>> Specifically in my instance, an API call comes in from a unit, requesting
>>> the bytes for a resource.  We want to record that this unit is now using
>>> the bytes from that specific revision of the resource.  I have a pointer to
>>> a state.Unit, and a function that takes a Resource metadata object and some
>>> reference to the unit, and does the actual transaction to the DB to store
>>> the unit's ID and the resource information.
>>>
>>
>> I'm a bit surprised that we'd be transferring those bytes over an API
>> call in the first place (is json-over-websocket really a great way to send
>> potential gigabytes? shouldn't we be getting URL+SHA256 from the apiserver
>> as we do for charms, and downloading separately? and do we really want to
>> enforce charmstore == apiserver?); and I'd point out that merely having
>> agreed to deliver some bytes to a client is no indication that the client
>> will actually be using those bytes for anything; but we should probably
>> chat about those elsewhere, I'm evidently missing some context.
>>
>
> So I would have expected that we'd rather use a similar raw
> HTTP-to-get-content instead of a JSON request (given the intent of
> resources is that they may be GB in size), but regardless it is the intent
> that you download the bytes from the charm rather from the store directly.
> Similar to how we currently fetch the charm archive content itself.
> As for "will you be using it", the specific request from the charm is when
> it calls "resource-get" which is very specifically the time when the charm
> wants to go do something with those bytes.
>
> John
> =:->
>
>
>> But whenever we do record the unit-X-uses-resource-Y info I assume we'll
>> have much the same stuff available in the apiserver, in which case I think
>> you just want to pass the *Unit back into state; without it, you just need
>> to read the doc from the DB all over again to make appropriate
>> liveness/existence checks [0], and why bother unless you've already hit an
>> assertion failure in your first txn attempt?
>>
>> Cheers
>> William
>>
>> [0] I imagine you're not just dumping (unit, resource) pairs into the DB
>> without checking that they're sane? that's really not safe
>>
>>
>>> On Fri, Jan 22, 2016 at 3:34 PM William Reade <
>>> william.re...@canonical.com> wrote:
>>>
 Need a bit more context here. What layer are you working in?

 In general terms, entity references in the API *must* use tags; entity
 references that leak out to users *must not* use tags; otherwise it's a
 matter of judgment and convenience. In state code, it's annoying to use
 tags because we've already got the globalKey convention; in worker code
 it's often justifiable if not exactly awesome. See
 https://github.com/juju/juju/wiki/Managing-complexity#workers

 Cheers
 William

 On Fri, Jan 22, 2016 at 6:02 PM, Nate Finch 
 wrote:

> I have a function that is recording which unit is using a specific
> resource.  I wrote the function to take a UnitTag, because that's the
> closest thing we have to an ID type. However, I and others seem to 
> remember
> hearing that Tags are really only supposed to be used for the API. That
> leaves me with a problem - what can I pass to this function to indicate
> which unit I'm talking about?  I'd be fine passing a pointer to the unit
> object itself, but we're trying to avoid direct dependencies on state.
> People have suggested just passing a string (presumably
> unit.Tag().String()), but then my API is too lenient - it appears to say
> "give me any string you want for an id", but what it really means is "give
> me a serialized UnitTag".
>
> I think most places in the code just use a string for an ID, but this
> opens up the code to abuses and developer errors.
>
> Can someone explain why tags should only be used in the API? It seems
> like the perfect type to pass around to indicate the ID of a specific
> object.
>
> -Nate
>
> --
> 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:
>>

Re: Tags and object IDs

2016-01-25 Thread John Meinel 
I think to William's point, we should have already authenticated the unit
as part of the API request, thus we should have a Unit object hanging
around somewhere close to where that request is being made, and can just
pass it into state.

John
=:->

On Mon, Jan 25, 2016 at 3:07 PM, Nate Finch 
wrote:

> I was really trying not to give too much information about this exact
> case, so we could avoid talking about a specific implementation, and focus
> on the more general question of how we identify objects.  Yes, we get the
> bytes using an HTTP request, but that is irrelevant to my question :)
>
> On Mon, Jan 25, 2016 at 2:00 AM John Meinel 
> wrote:
>
>> On Sat, Jan 23, 2016 at 1:28 AM, William Reade <
>> william.re...@canonical.com> wrote:
>>
>>> On Fri, Jan 22, 2016 at 9:53 PM, Nate Finch 
>>> wrote:
>>>
 Working in the model layer on the server between the API and the DB.
 Specifically in my instance, an API call comes in from a unit, requesting
 the bytes for a resource.  We want to record that this unit is now using
 the bytes from that specific revision of the resource.  I have a pointer to
 a state.Unit, and a function that takes a Resource metadata object and some
 reference to the unit, and does the actual transaction to the DB to store
 the unit's ID and the resource information.

>>>
>>> I'm a bit surprised that we'd be transferring those bytes over an API
>>> call in the first place (is json-over-websocket really a great way to send
>>> potential gigabytes? shouldn't we be getting URL+SHA256 from the apiserver
>>> as we do for charms, and downloading separately? and do we really want to
>>> enforce charmstore == apiserver?); and I'd point out that merely having
>>> agreed to deliver some bytes to a client is no indication that the client
>>> will actually be using those bytes for anything; but we should probably
>>> chat about those elsewhere, I'm evidently missing some context.
>>>
>>
>> So I would have expected that we'd rather use a similar raw
>> HTTP-to-get-content instead of a JSON request (given the intent of
>> resources is that they may be GB in size), but regardless it is the intent
>> that you download the bytes from the charm rather from the store directly.
>> Similar to how we currently fetch the charm archive content itself.
>> As for "will you be using it", the specific request from the charm is
>> when it calls "resource-get" which is very specifically the time when the
>> charm wants to go do something with those bytes.
>>
>> John
>> =:->
>>
>>
>>> But whenever we do record the unit-X-uses-resource-Y info I assume we'll
>>> have much the same stuff available in the apiserver, in which case I think
>>> you just want to pass the *Unit back into state; without it, you just need
>>> to read the doc from the DB all over again to make appropriate
>>> liveness/existence checks [0], and why bother unless you've already hit an
>>> assertion failure in your first txn attempt?
>>>
>>> Cheers
>>> William
>>>
>>> [0] I imagine you're not just dumping (unit, resource) pairs into the DB
>>> without checking that they're sane? that's really not safe
>>>
>>>
 On Fri, Jan 22, 2016 at 3:34 PM William Reade <
 william.re...@canonical.com> wrote:

> Need a bit more context here. What layer are you working in?
>
> In general terms, entity references in the API *must* use tags; entity
> references that leak out to users *must not* use tags; otherwise it's a
> matter of judgment and convenience. In state code, it's annoying to use
> tags because we've already got the globalKey convention; in worker code
> it's often justifiable if not exactly awesome. See
> https://github.com/juju/juju/wiki/Managing-complexity#workers
>
> Cheers
> William
>
> On Fri, Jan 22, 2016 at 6:02 PM, Nate Finch 
> wrote:
>
>> I have a function that is recording which unit is using a specific
>> resource.  I wrote the function to take a UnitTag, because that's the
>> closest thing we have to an ID type. However, I and others seem to 
>> remember
>> hearing that Tags are really only supposed to be used for the API. That
>> leaves me with a problem - what can I pass to this function to indicate
>> which unit I'm talking about?  I'd be fine passing a pointer to the unit
>> object itself, but we're trying to avoid direct dependencies on state.
>> People have suggested just passing a string (presumably
>> unit.Tag().String()), but then my API is too lenient - it appears to say
>> "give me any string you want for an id", but what it really means is 
>> "give
>> me a serialized UnitTag".
>>
>> I think most places in the code just use a string for an ID, but this
>> opens up the code to abuses and developer errors.
>>
>> Can someone explain why tags should only