Constraints for Additional Units

[James Beedy]

I think I see *my* issue here. I have placed the constraints on the
machines (to which the charms are mapped) in my bundle, and not on the
actual applications themselves. I guess I shouldn't expect the constraints
to be associated with the charms in that case. Does this sound correct?

On Thu, Mar 16, 2017 at 8:13 PM, James Beedy <jamesbeedy at gmail.com> wrote:

> With the following spaces and subnets http://paste.ubuntu.com/24192913/
>
> I deploy my haproxy units to the igw subnets, and keep the rest of the
> components of my applications behind the nat gateway on the nat subnets. I
> tag the appropriate spaces on the machines in my bundle, but following a
> bundle deploy, the units don't scale out with the correct constraints (e.g.
> end up in the wrong space) if I go to add any additional units. As can be
> seen here (http://paste.ubuntu.com/24192930/) the additional unit of
> 'feed-web' obviously does not end up on one of my nat gateway subnets hence
> it has a public ip.
>
> On Thu, Mar 16, 2017 at 8:01 PM, Tim Penhey <tim.penhey at canonical.com>
> wrote:
>
>> On 17/03/17 14:23, James Beedy wrote:
>>
>>> Currently, if I scale the units of my application, the new units do not
>>> have the same constraints as the previously deployed units.
>>>
>>
>> Well, I certainly think they should be carrying over the constraints as
>> the constraints are set on the application, not the unit.
>>
>> If this isn't working, I believe it is a bug.
>>
>> Can you give an example of what is not working?
>>
>> Cheers,
>> Tim
>>
>>
>> Moreover, it
>>> doesn't seem there is anyway to specify constraints for additional
>>> units. I'm thinking the 'add-unit' command needs to be able to accept
>>> constraints, or constraints need to be carried forward for additional
>>> units of the same application.  This is a request for the 'add-unit'
>>> command to accept constraints, or for constraints to grow some sort of
>>> associativity/sensitivity to applications. Also, this is a huge blocker
>>> for me right now. Any insight as to how we might solve this issue would
>>> be greatly appreciated.
>>>
>>> Thanks
>>>
>>> https://bugs.launchpad.net/juju/+bug/1673639
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170316/680797b7/attachment.html>