[SRU] Juju api client cannot distinguish between environments

Bug #1239488 reported by Julian Edwards on 2013-10-14
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
MAAS
Critical
Julian Edwards
maas (Ubuntu)
High
Unassigned
Saucy
High
Unassigned

Bug Description

In the maas user prefs page it says "You'll need a separate MAAS key for each Juju environment" but this is not of the slightest use since the API for returning owned nodes filters only on the user.

One thing we could do is also take into account the API key used to access the API and only return nodes based on the owner/key combo.

Related bugs:
 * bug 1237398: "You'll need a separate MAAS key for each Juju environment" is wrong.
 * bug 1081247: maas provider releases all nodes it did not allocate [does not play well with others]
 * bug 1229275: juju destroy-environment also destroys nodes that are not controlled by juju

[Impact]
This causes that 2 admin users cannot have their own separate environment, causing them to conflict between environments, and also destroy machines that are not controller by a one environment, but rather, all machines being deployed.

[Test Case]
1. Install maas
2. Create to admin users
3. Try to use both to deploy different juju environments.

[Regression Potential]
Minimal. The provided fix allows multiple juju environments to work, without affecting current single juju environments.

Related branches

Julian Edwards (julian-edwards) wrote :

This is critical, it's hurting a lot of users.

Changed in maas:
status: New → Triaged
importance: Undecided → Critical
Raphaël Badin (rvb) wrote :

AFAIK, the only information stored on the node is the owner, the key itself is not stored anywhere, it's only used when authenticating the user.

On 14/10/13 16:26, Raphaël Badin wrote:
> AFAIK, the only information stored on the node is the owner, the key
> itself is not stored anywhere, it's only used when authenticating the
> user.
>

That's irrelevant - MAAS knows which API key was used so it can make use
of that.

>That's irrelevant - MAAS knows which API key was used so it can make use of that.

Maybe I'm wrong but I don't think this is an information that is stored anywhere right now. Sure, when the API is used, MAAS knows which API key is being used, but after the request is performed and the node allocated, that information is lost, only which user took ownership of the node remains in the DB. So a subsequent request won't be able to tell with which API key this node was allocated. Unless we change the database that is.

Yes, that's what I am implying we would do if deciding to go this route.

Didn't we decide at one point that every Juju environment had to have its own MAAS user?

On 14/10/13 20:05, Jeroen T. Vermeulen wrote:
> Didn't we decide at one point that every Juju environment had to have
> its own MAAS user?
>

We did, but that has not been documented properly.

Scott Moser (smoser) on 2013-10-15
description: updated
description: updated
Changed in maas:
status: Triaged → In Progress
assignee: nobody → Julian Edwards (julian-edwards)
milestone: none → 13.10
Changed in maas:
status: In Progress → Fix Committed
James Page (james-page) on 2013-10-16
Changed in maas (Ubuntu Saucy):
importance: Undecided → High
status: New → Triaged
summary: - Juju api client cannot distinguish between environments
+ [SRU] Juju api client cannot distinguish between environments
description: updated
Changed in maas:
status: Fix Committed → Fix Released

Hello Julian, or anyone else affected,

Accepted maas into saucy-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/maas/1.4+bzr1693+dfsg-0ubuntu2.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in maas (Ubuntu Saucy):
status: Triaged → Fix Committed
tags: added: verification-needed
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package maas - 1.4+bzr1693+dfsg-0ubuntu2.2

---------------
maas (1.4+bzr1693+dfsg-0ubuntu2.2) saucy-proposed; urgency=low

  * debian/patches:
    - 99_fix_dhcp_template_lp1240972.patch: Do not prevent the MAAS DHCP
      template from adding ignore-client-uids on precise, which causes
      issues with DNS for MAAS in the Cloud Archive. (LP: #1240972)
    - 99_arm_generic_kernel_lp1166994.patch: Re-enable armhf generic as it
      is supported starting from raring. (LP: #1166994)

maas (1.4+bzr1693+dfsg-0ubuntu2.1) saucy-proposed; urgency=low

  * debian/patches/99_fix_juju_multienv_lp1239488: Allows juju to distinguish
    between different environments, actually fixing the MAAS side of multiple
    juju environment support. (LP: #1239488)
 -- Andres Rodriguez <email address hidden> Thu, 24 Oct 2013 13:35:00 -0700

Changed in maas (Ubuntu Saucy):
status: Fix Committed → Fix Released

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Changed in maas (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers