[SRU] maas to Quantal and Precise

Bug #1109283 reported by Andres Rodriguez on 2013-01-29
34
This bug affects 4 people
Affects Status Importance Assigned to Milestone
maas (Ubuntu)
Undecided
Unassigned
Precise
Undecided
Unassigned
Quantal
Undecided
Unassigned

Bug Description

[Impact]
As part of the MAAS Next Steps bluepring [1], we would like to SRU a new version of MAAS to both Precise and Quantal.

For Quantal:
 - Fixes various issues
https://launchpad.net/ubuntu/+source/maas/1.2+bzr1349+dfsg-0ubuntu1

For Precise:
 - It removes cobbler (maas-provision) as a dependency and fixes various issues.
 - It removes from shipping yui3 and raphael JS libs in the MAAS source package, as these are already in the Quantal Archives. These also required SRU.

[Test Case]
1. Install the release version of maas
2. Enable -proposed and run a dist-upgrade
3. Verify that the upgrade works smoothly, and that the new conflicts added don't result in key packages being removed.
4. Run MAAS
5. Check that no WebUI issues appear.

[Regression potential]
Minimal. MAAS has been tested throughtly by the MAAS team both manually and in the automated lab. The MAAS team is committed on fixing any issues that might appear.

[1]: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-maas-next-steps

description: updated
Changed in maas (Ubuntu):
status: New → Fix Released
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in maas (Ubuntu Precise):
status: New → Confirmed
Changed in maas (Ubuntu Quantal):
status: New → Confirmed
Steve Langasek (vorlon) on 2013-03-19
description: updated

Hello Andres, or anyone else affected,

Accepted maas into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/maas/1.2+bzr1373+dfsg-0ubuntu1~12.04.1 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 Precise):
status: Confirmed → Fix Committed
tags: added: verification-needed
Steve Langasek (vorlon) wrote :

Hello Andres, or anyone else affected,

Accepted maas into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/maas/1.2+bzr1373+dfsg-0ubuntu1 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 Quantal):
status: Confirmed → Fix Committed
Julian Edwards (julian-edwards) wrote :

Please note that when this upgrade runs, it will render some existing installations unusable until they configure the cluster controller. Previously, MAAS depended on external configuration of DHCP etc via Cobbler or manually. Now that Cobbler has gone, it must be configured in MAAS where it was previously managed by Cobbler.

tags: added: verification-done
removed: verification-needed
Scott Kitterman (kitterman) wrote :

I don't think making the package broken without additional configuration is acceptable in an SRU. This should have been mentioned up front. Thanks for noticing Julian.

tags: added: verification-failed
removed: verification-done
Adam Conrad (adconrad) wrote :

Is there no way to provide sane migration here? SRUing something that breaks people's configurations seems like a non-starter.

Andres Rodriguez (andreserl) wrote :

To be clear, MAAS as its currently stands in precise has a *broken* implementation of DHCP/DNS when managed by cobbler. Most of the times it did not work well out of the box and decreases the user experience.

That being said, all of the stakeholders were aware and had been notified that when an upgrade was to be made available, it will require to update the DHCP/DNS settings for those who run MAAS in precise with cobbler managing DNS/DHCP (which is probably not the use case for most of the installations). This is why Julian committed to providing upgrading instructions to migrate cobbler existing configurations to MAAS existing configurations. At least one member of the release team was aware of this and was fine with it.

Cheers.

How are these upgrade instructions to be communicated to users?

Scott Kitterman (kitterman) wrote :

Also, it seems to me that not mentioning this in the SRU bug, well, the nicest
way I can put it, is 'substantially incomplete'. This isn't the kind of thing
that should be handles via "I talked to someone on the release team and they
said it was fine" (BTW, ubuntu-sru and ubuntu-release are not the same team).

I am largely unfamiliar with the Ubuntu SRU process so I'm contributing where I can here, please excuse my lack of understanding. I am upstream in this case so I'll write from that point of view.

The existing 12.04 package is already *broken* which is the whole reason for this SRU. It was demo-ware and never worked properly. As Andres says, "Most of the times it did not work well out of the box and decreases the user experience". Anyone who is really using it in anger on 12.04 upgraded to the PPA version ages ago.

I'll repeat that - *existing installations are already broken*. This SRU went to the techboard because it was a necessarily big change to fix the old mess (which should never have been uploaded in the first place).

Note that the quantal SRU does not have this technicality as it already works in the new way.

This should be released ASAP because otherwise new users on 12.04 will get a very bad impression of MAAS.

tags: added: verification-done
removed: verification-failed
Scott Kitterman (kitterman) wrote :

Please don't ping pong the bug status.

tags: added: verification-failed
removed: verification-done
Scott Kitterman (kitterman) wrote :

It might have been smarter not to shove MaaS into precise during release week, but we are where we are. It may be demo ware from an upstream PoV, but it's part of an Ubuntu LTS release.

I know the general topic of MaaS was addressed with the tech board, but not, I don't believe, requiring manual intervention to fix the package after upgrade. The policy is zero regressions and that would definitely be a regression.

Andres Rodriguez (andreserl) wrote :

Hi Scott,

We are in the process of drafting the upgrade instructions, and we will communicate them through normal means, ML's, blog posts, etc, unless you believe a debconf message should also be showed.

I, however, feel the need to clarify this, since I fail to see how the MAAS SRU is causing a regression in MAAS in precise.

The reason why I fail to see a regression is that MAAS in precise does *not* really provide support for DNS/DHCP configuration. The MAAS SRU *does*. In Precise, MAAS uses a code copy of cobbler that generates a file to provide DNS/DHCP. However, this file is not configured by MAAS, nor generated by MAAS. The configuration requires manual intervention in order for it to work properly, which we believe is part of it being a broken implementation of cobbler. Since we rely on cobbler, MAAS in precise makes use of a dependency that can make an *attempt* to configure DNS/DHCP, which is in fact, not recommended by us. Most people will have manually configured DHCP/DHCP as an external service from MAAS, which is the implementation that we recommended from the beginning for Precise.

This is what the SRU *fixes* rather than *regresses*. This, however, requires proper configuration in the MAAS side after upgrade.

Now, as far as Quantal, it does not have this issue because MAAS in Quantal already has support for DNS/DHCP management and we no longer use the cobbler code copy.

Thank you for your input. Hope this information helps.

Scott Kitterman (kitterman) wrote :

Right. I got it.

The point is that whatever users are using MaaS on precise now from the
archive have already done some manual configuration, so the fact that the
current package requires manual configuration isn't a concern from an SRU
perspective.

It's my understanding from reading the bug, that if users that have already
manually configured things once and have a working system install the new
package, things will stop working until they do additional manual
configuration. It's the working to not working part that is an issue.

If I understand the situation correctly (please clarify if I don't), then
that's not normally acceptable for an SRU. Debconf is not a notification
system. I think you need to find a way for package install not to regress
without manual intervention or it's not SRU material.

> Please don't ping pong the bug status

I didn't touch the bug status.

> It's my understanding from reading the bug, that if users that have already
manually configured things once and have a working system install the new
package, things will stop working until they do additional manual
configuration

This is not correct. This is the scenario that will keep on working fine after upgrading.

Given that most people will have done it this way, the SRU is going to break somewhere between no-one and a handful of people.

Andres Rodriguez (andreserl) wrote :

Hi Scott,

It is my understanding that if a user does something *unsupported*, say manually edit a file of an X python module to say hack their fixes in order for it to work the way they want it (which can break a system), then an SRU (or any new package version) will upgrade that file not caring if there has been any changes made.

So this is the same thing that is currently happening with MAAS in precise. In order for this work they have to do some manual configuration that is not standard. Since DNS/DHCP is being managed by cobbler, every time cobbler re-generates the configuration required file, it will automatically overwrite this file, regardless of the changes that the user has made. So in other words, cobbler overwrites /etc/dnsmasq.conf because it manages it. If a user wrote its own particular/additional configuration for dnsmasq, it will be lost once the file is renegerated by cobbler. This also happens when cobbler is upgraded to a newer version. So in reality, cobbler is currently and actually doing what we are arguing here. So this SRU does fix this, because newer MAAS won't affect user configured files for DNS/DHCP, as it has its own.

Hope this helps.

Scott Kitterman (kitterman) wrote :

OK, let me see if I understand now ...

If a current precise user didn't manually edit their dnsmasq.conf, then their
MaaS is certain to be not working and so there's no risk of regression.

If they did edit it and have a working system and then install the update,
what will happen? If I'm reading you right, their changes, that made the
system work, will be lost. Is that right?

Scott Kitterman (kitterman) wrote :

On Tuesday, April 23, 2013 11:11:24 PM Julian Edwards wrote:
> > Please don't ping pong the bug status
>
> I didn't touch the bug status.

Sorry, it was a tag, not a status, but a very important one for the SRU
process.

Dave Walker (davewalker) wrote :

I wanted to avoid involvement with this SRU as I am risk of being to close to this issue to safely unbiased. However, I feel i can add some value. Therefore, please consider this to a be complementing comment - rather than pushing in either direction.

My understanding is that if users used the "maas-dhcp" to allow MAAS to drive their dhcp (using embedded cobbler) then this SRU almost certainly requires manual intervention to insure uninterrupted operation.

"maas-dhcp" is a universe package, that was never designed to be a core part of MAAS. It was provided as developers were making use of it, and it seemed useful to provide for this purpose. However it was intentionally left in universe.

If the documented use of MAAS is followed, then it should be a well tested seamless upgrade.

Whilst i'd normally entirely agree that this update poses scope for concern, the positives outweigh these concerns. I understood that this was the primary reason this issue was progressed to the TB for discussion.

Scott Kitterman (kitterman) wrote :

On Wednesday, April 24, 2013 04:19:41 PM you wrote:
> Whilst i'd normally entirely agree that this update poses scope for
> concern, the positives outweigh these concerns. I understood that this
> was the primary reason this issue was progressed to the TB for
> discussion.

Would you please point me to the discussion? My recollection is that the
discussion was about handling dependencies. Perhaps I'm confusing this with
something else.

Andres Rodriguez (andreserl) wrote :

I would also like to add the following:

The non-recommend implementation of cobbler based maas-dhcp will always destroy user configuration because cobbler will always generate the file "/etc/dnsmasq.conf". When a does manual configuration for their dnsmasq service (regardless of whether they are using Cobbler MAAS DNS/DHCP), these changes will be lost because cobbler will always overwrite these file. (So if someone upgrades cobbler, these changes will be lost because cobbler will generate a new file)

This also means that cobbler does not run its own instance of dnsmasq, but it uses the default dnsmasq service, generating a file in "/etc/dnsmasq.conf" and consequently overwriting users changes. This is something that we see as bad implementation.

The SRU fixes this issue because it runs its own instance of DHCP/DNS, which doesn't change or affect any user configuration as MAAS manages its own files/instances of the service, and does not overwrite any manual configuration to services in /etc/.

Hope this helps

Scott Kitterman (kitterman) wrote :

I still don't think I have a clear answer to my question in https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1109283/comments/18

Andres Rodriguez (andreserl) wrote :

Scott,

"If they did edit it and have a working system and then install the update,
what will happen? If I'm reading you right, their changes, that made the
system work, will be lost. Is that right?"

If they were to upgrade to a cobbler based MAAS version, then yes their changes (in /etc/dnsmasq.conf) will be lost because cobbler will overwrite this file as explained above.

If they upgrade to the proposed SRU (which is cobblerless MAAS), their changes in /etc/dnsmasq.conf won't be lost because the SRU'd version of MAAS does not use dnsmasq, since it runs its own instance of isc-dhcp, and ships its own config file, leases file, etc.

Hope this answer your questions.

Scott Kitterman (kitterman) wrote :

Their changes won't be lost, but they also won't be used since (AIUI) you
aren't using dnsmasq.conf anymore. If that's right then there are two cases:

1. Made manual dnsmasq.conf changes, but the automatic magic now works, so it
doesn't matter.

2. Made manual dnsmasq.conf changes, but the default configuration doesn't
work and they have to manually reapply changes to ???

Right?

Nobuto Murata (nobuto) wrote :

2013/4/25 Dave Walker <email address hidden>:
> "maas-dhcp" is a universe package, that was never designed to be a core
> part of MAAS. It was provided as developers were making use of it, and
> it seemed useful to provide for this purpose. However it was
> intentionally left in universe.
>
> If the documented use of MAAS is followed, then it should be a well
> tested seamless upgrade.

As far as I understand, the use of "maas-dhcp" was described as a
prime way of using DHCP with MAAS until 2012-12-10, whether it was on
main or not.
https://wiki.ubuntu.com/ServerTeam/MAAS?action=recall&rev=43

Andres Rodriguez (andreserl) wrote :

@Nobuto,

Thanks for your input, but as described in the wikipage (which no longer exists) it was *a* way of configuring a DHCP server, not *the* prime way of configuring one. Either way, MAAS itself is *NOT* aware if there's a DHCP server configured or not.

@Scott,

Yes, changes won't be lost, but they would/could still be used.

So, Cobbler-MAAS is *not* aware of it having a DHCP server. Since cobbler "manages" it, MAAS doesn't really know whether the DHCP server has been configured or not. So in reality, this service is external from MAAS. In this case, if we were to upgrade to the SRU package, the DHCP should continue to work and should continue to tell MAAS nodes were they should be booting from because this still remains as a service external to MAAS.

Now, since the SRU version of MAAS can be DNS/DHCP aware, and if the user wants MAAS to manage this, then the user will have to manually migrate from using the "external" dnsmasq to using a MAAS managed DNS/DHCP service, which is what I believe Julian was trying to say.

Hope this helps.

Scott Kitterman (kitterman) wrote :

On Thursday, April 25, 2013 01:07:51 AM you wrote:
> Now, since the SRU version of MAAS can be DNS/DHCP aware, and if the
> user wants MAAS to manage this, then the user will have to manually
> migrate from using the "external" dnsmasq to using a MAAS managed
> DNS/DHCP service, which is what I believe Julian was trying to say.

OK, but ...

I thought I also read earlier in the thread that the only way a user of the
precise package is likely to have gotten it working is with the "external"
dnsmasq service, which leads us right to this will only break upgrades for
people who worked to manually set things up so it would function.

Clearly I'm still missing something.

Andres Rodriguez (andreserl) wrote :

Hi Scott,

No not really... so if people set things manually, a MAAS upgrade to the SRU package won't break configurations because MAAS does not touch /etc/dnsmasq.conf at all. So MAAS upgrade should leave /etc/dnsmasq.conf as ism and dnsmasq should continue to work as expected.

Cheers

Scott Kitterman (kitterman) wrote :

And MaaS will continue to work without manual configuration?

Andres Rodriguez (andreserl) wrote :

Yes it will continue to work without manual configuration. We've already discussed this with ScottK via the IRC channel and he had agreed that this is good to go.

tags: added: verification-done
removed: verification-failed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package maas - 1.2+bzr1373+dfsg-0ubuntu1~12.04.1

---------------
maas (1.2+bzr1373+dfsg-0ubuntu1~12.04.1) precise-proposed; urgency=low

  * MAAS Stable Release Update (LP: #1109283). See changelog entry bellow.
  * debian/maas-dhcp.maas-dhcp-server.upstart: leases file should be owned
    by user/group 'dhcpd' instead of root.
  * debian/control: Force dependency version for python-django to
    (>> 1.3.1-4ubuntu1.6).
  * Continue to ship yui3 and raphael with MAAS.
    - debian/patches/04_precise_no_yui_root.patch: Add.
    - debian/control: Drop dependencies on yui3 and raphael.
    - debian/source/include-binaries: Add to not FTBFS
    - debian/extras/jslibs: Ship JS libraries.
    - debian/copyright: Update copyright to reflect libraries license.
 -- Andres Rodriguez <email address hidden> Wed, 20 Mar 2013 14:01:48 -0400

Changed in maas (Ubuntu Precise):
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.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package maas - 1.2+bzr1373+dfsg-0ubuntu1

---------------
maas (1.2+bzr1373+dfsg-0ubuntu1) quantal-proposed; urgency=low

  * MAAS Stable Release Update (LP: #1109283):
    This SRU brings a new upstream release of MAAS that removes
    the usage of a cobbler code copy, 'maas-provision' as well as
    several bug fixes. Exception has been granted by the Technical
    Board to proceed. More information can be found in:
    https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-February/001012.html

  [ Andres Rodriguez ]
  * debian/control:
    - Change Conflicts/Replaces for Breaks/Replaces.
    - Conflicts on tftpd-hpa and dnsmasq.
    - Do not pre-depends, but Depends on ${misc:Depends} for 'maas'.

  [ Steve Langasek ]
  * postinst scripts are never called with 'reconfigure' as the script
    argument. Remove references to this (mythical) invocation.
  * always call 'set -e' from maintainer scripts instead of passing 'sh -e'
    as the interpreter, so that scripts will behave correctly when run via
    'sh -x'.
  * invoke-rc.d is never allowed to not exist - simplify scripts (and make
    them better policy-compliant) by invoking unconditionally. (The only
    possible exception is in the postrm, where it's *theoretically* possible
    for invoke-rc.d to be missing if the user has completely stripped
    down their system; that's a fairly unreasonable corner case, but we
    might as well be correct if it ever happens.)
  * db_get+db_set is a no-op; don't call db_set to push back a value we just
    got from db_get.
  * Omit superfluous calls to 'exit 0' at the end of each script.
  * Remove maas-cluster-controller prerm script, which called debconf for no
    reason.
  * Don't invoke debconf in the postrm script either, debhelper already does
    this for us.
  * Other miscellaneous maintainer script fixes
  * debian/maas-common.postinst: call adduser and addgroup unconditionally;
    the tools are already designed to DTRT, we don't need to check for the
    user/group existence before calling them nor should we worry about
    calling them only once on first install.
  * debian/maas-common.postrm: delete the maas group, not just the user,
    as the comment in the code implies we should do.
 -- Andres Rodriguez <email address hidden> Thu, 07 Mar 2013 14:22:35 -0500

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

Other bug subscribers