[2.3, wishlist] Support tag filtering (via tag/no_tag) in pods.

Because of the way juju tries to round-robin across availability zones, this means that even if a physical machine is available in another zone, juju will end up with a KVM instead of a physical machine like it wants if it asks for a node from the wrong availability zone first.

FWIW, 'pods' do not support 'tags' in any form, as such this is a Feature Request. This should not be tagged 'cdo-qa-blocker'.

I'm not asking for generic tag/non tag constraints on pods, please don't misinterpret this bug.

Pod created VMs definitely can be tagged, just like any other machine. All of the vms we make via pods end up tagged 'virtual'.

MAAS already doesn't create a VM if a tag is specified as a constraint. It is a bug that it does not do the same specifically when the 'virtual' tag is specified, since all VMs, including pod created VMs, are tagged 'virtual' by MAAS.

cdo-qa-blocker means this causes test failures in cdo-qa tests. This does, and we will have to implement a workaround to get around it. Our workaround will be to stop using not_tag, since MAAS does not support using not_tag when a pod has been added to MAAS, and instead add additional tags to all of our machines and use those as tag constraints, since MAAS doesn't ever allocate pod KVMs when a tag constraint is specified.

@Jason,

As you described in the bug report, you were hoping to use a 'no_tag' constraint to prevent allocating machines from a pod. A pod has no knowledge whatsoever of the concept of tags, so you can't really use 'tags' or 'no_tags' to constraint allocation. The fact that MAAS tags machines coming from a pod a specific way is completely irrelevant and unrelated to /allocation/ from pods. As per your use case and expectation, it then means that you have a use case that's currently not supported, and to do so, MAAS would need to gain such feature.

That said, I agree with you; cdo-qa-blocker means this causes tests failures when a /supported/ use case results in failures. In this particular case, the expected use case is /not/ supported, and the output is expected.

As such, the tag doesn't apply because you are using it in an unsupported way. If you were to be using it in a supported way and it would be failing, then the tag does apply.

That said, I think we both agree that gaining such support would be nice!

FWIW,

This is now part of 2.4 pod improvements among other requested features.

On Mon, Feb 26, 2018 at 8:10 PM Andres Rodriguez <email address hidden>
wrote:

> @Jason,
>
> As you described in the bug report, you were hoping to use a 'no_tag'
> constraint to prevent allocating machines from a pod. A pod has no
> knowledge whatsoever of the concept of tags, so you can't really use
> 'tags' or 'no_tags' to constraint allocation. The fact that MAAS tags
> machines coming from a pod a specific way is completely irrelevant and
> unrelated to /allocation/ from pods. As per your use case and
> expectation, it then means that you have a use case that's currently not
> supported, and to do so, MAAS would need to gain such feature.
>
> That said, I agree with you; cdo-qa-blocker means this causes tests
> failures when a /supported/ use case results in failures. In this
> particular case, the expected use case is /not/ supported, and the
> output is expected.
>
> As such, the tag doesn't apply because you are using it in an
> unsupported way. If you were to be using it in a supported way and it
> would be failing, then the tag does apply.
>
> That said, I think we both agree that gaining such support would be
> nice!
>
> --
> You received this bug notification because you are subscribed to MAAS.
> https://bugs.launchpad.net/bugs/1751907
>
> Title:
> [2.3, wishlist] Support tag filtering (via tag/no_tag) in pods.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/maas/+bug/1751907/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: product=maas; milestone=2.4.x; status=Triaged;
> importance=Medium; assignee=None;
> Launchpad-Bug-Tags: cdo-qa cdo-qa-blocker foundations-engine kvm pod
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: andreserl jason-hobbs
> Launchpad-Bug-Reporter: Jason Hobbs (jason-hobbs)
> Launchpad-Bug-Modifier: Andres Rodriguez (andreserl)
> Launchpad-Message-Rationale: Subscriber (MAAS)
> Launchpad-Message-For: andreserl
>
--
Andres Rodriguez (RoAkSoAx)
Ubuntu Server Developer
MSc. Telecom & Networking
Systems Engineer

Great - my point is that I'm not asking for generic pod filtering by tag/not_tag, so please don't make this bug about that.

Just to make sure we're talking about the same thing, when I ask maas
for a machine without the 'virtual' tag, it gives me a machine with
the 'virtual' tag.

I wasn't asking for a pod machine at all - that would be filtering on
pods and I agree that would be a feature request. I was specifically
trying to get a non virtual machine, and as a side effect of having a
pod on the same MAAS, it didn't work.

I consider that a bug, but feel free to consider it a missing feature
- I don't really care about that part ;).

On Mon, Feb 26, 2018 at 7:37 PM, Andres Rodriguez
<email address hidden> wrote:
> FWIW,
>
> This is now part of 2.4 pod improvements among other requested features.
>
> On Mon, Feb 26, 2018 at 8:10 PM Andres Rodriguez <email address hidden>
> wrote:
>
>> @Jason,
>>
>> As you described in the bug report, you were hoping to use a 'no_tag'
>> constraint to prevent allocating machines from a pod. A pod has no
>> knowledge whatsoever of the concept of tags, so you can't really use
>> 'tags' or 'no_tags' to constraint allocation. The fact that MAAS tags
>> machines coming from a pod a specific way is completely irrelevant and
>> unrelated to /allocation/ from pods. As per your use case and
>> expectation, it then means that you have a use case that's currently not
>> supported, and to do so, MAAS would need to gain such feature.
>>
>> That said, I agree with you; cdo-qa-blocker means this causes tests
>> failures when a /supported/ use case results in failures. In this
>> particular case, the expected use case is /not/ supported, and the
>> output is expected.
>>
>> As such, the tag doesn't apply because you are using it in an
>> unsupported way. If you were to be using it in a supported way and it
>> would be failing, then the tag does apply.
>>
>> That said, I think we both agree that gaining such support would be
>> nice!
>>
>> --
>> You received this bug notification because you are subscribed to MAAS.
>> https://bugs.launchpad.net/bugs/1751907
>>
>> Title:
>> [2.3, wishlist] Support tag filtering (via tag/no_tag) in pods.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/maas/+bug/1751907/+subscriptions
>>
>> Launchpad-Notification-Type: bug
>> Launchpad-Bug: product=maas; milestone=2.4.x; status=Triaged;
>> importance=Medium; assignee=None;
>> Launchpad-Bug-Tags: cdo-qa cdo-qa-blocker foundations-engine kvm pod
>> Launchpad-Bug-Information-Type: Public
>> Launchpad-Bug-Private: no
>> Launchpad-Bug-Security-Vulnerability: no
>> Launchpad-Bug-Commenters: andreserl jason-hobbs
>> Launchpad-Bug-Reporter: Jason Hobbs (jason-hobbs)
>> Launchpad-Bug-Modifier: Andres Rodriguez (andreserl)
>> Launchpad-Message-Rationale: Subscriber (MAAS)
>> Launchpad-Message-For: andreserl
>>
> --
> Andres Rodriguez (RoAkSoAx)
> Ubuntu Server Developer
> MSc. Telecom & Networking
> Systems Engineer
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1751907
>
> Title:
> [2.3, wishlist] Support tag filtering (via tag/no_tag) in pods.
>
> Status in MAAS:
> Triaged
>
> Bug description:
> To reproduce:
> 1) Setup a maas and add a KVM pod to i...