maas-devel team mailing list archive

[Andres Rodriguez <andres.rodriguez@xxxxxxxxxxxxx>]

>
>
>
> The main impact, as you say, would be on packaging. Right now MAAS's
> python-* Debian-packages - python-django-maas, python-maas-client,
> python-maas-provisioningserver - are created by butchering lp:maas
> into separate pieces. The repackage branch creates explicitly separate
> Python packages: maas-apiclient, maas-client, maas-cluster,
> maas-develop, maas-region, maas-testing. Except for maas-testing, each
> of those would map to a python-* Debian-package. The existing
> non-python-* Debian-packages (maas, maas-cli, maas-cluster-controller,
> maas-common, maas-dhcp, maas-dns, maas-enlist, maas-region-controller,
> maas-region-controller-min) could be changed to use/depend on these.
> The existing python-maas-* Debian-packages would become aliases (or
> similar).
>

I don't expect binary package names to change. I would expect that even
though the separation has been done upstream, the packages will remain
installing the same files in the same places, otherwise, there's a risk of
breaking things.

>
> I don't know if a change like this would be permitted in an SRU.
>

I don't think it would at first hand. This would not only be a huge diff
for SRU team to review, but also a change that does not bring any other
benefit to Ubuntu itself. It would be a change that can affect upgrades in
a large scale and cause breakeage. Not to mention that packaging will need
to be updated and make sure things are not breaking and if they are, deal
with these changes would be a huge thing to do and I don't think it would
be a thing that it would be SRU'd easily.


> Other things the repackage branch changes a lot is running tests. Nose
> has been removed for one so that tests can be run using `python
> setup.py test`. This actually makes running selected tests harder for
> now, but it's something we can iterate on. Ultimately we may want to
> being nose back again, but I needed to get to a clean slate first
> during this migration, for consistency.
>
> >
> > I think the ideal solution is indeed to prevent the region from seeing
> > the cluster code at all.
> >
> > We could do [1] as an interim though, but limit it to registry as much
> > as possible as I think maasserver imports quite a lot stuff from
> > provisioningserver :(
>
> If we do [1] we can use it as a ratchet. We'd need something like that
> even if we landed the repackage branch, so it's not a wasted effort.
>
> --
> Mailing list: https://launchpad.net/~maas-devel
> Post to     : maas-devel@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maas-devel
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Andres Rodriguez
Engineering Manager, HWE Team
Canonical USA, Inc.