maas-devel team mailing list archive

[Gavin Panella <gavin.panella@xxxxxxxxxxxxx>]

On 30 April 2014 04:07, Julian Edwards <julian.edwards@xxxxxxxxxxxxx> wrote:
> On 29/04/14 21:27, Gavin Panella wrote:
>> On 29 April 2014 02:06, Julian Edwards <julian.edwards@xxxxxxxxxxxxx> wrote:
>>> Hi,
>>>
>>> I was just reviewing a branch that was trying to import a
>>> provisioningserver registry directly into maasserver.  This is Obviously
>>> Bad™ because it should be using RPC to retrieve the items.
>>>
>>> My question is, can anyone think of an elegant way to prevent this
>>> import from happening in the future?
>>
>> One way would be to create a custom finder/loader for sys.path_hooks
>> [1] that checks the stack for maasserver and rejects the import if
>> found.
>>
>> Another would be to land my repackage branch [2] and prevent the
>> maas-region package from using maas-cluster. This is a big change
>> though, and would have lots of other side-effects.
>>
>>
>> [1] https://docs.python.org/2.7/library/sys.html#sys.path_hooks
>> [2] lp:~allenap/maas/repackage
>>
>
> I am not against big changes if they are beneficial.  Remind me of the
> risks/side-effects again?  I expect at least the Ubuntu packaging would
> be screwed over.

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 know if a change like this would be permitted in an SRU.

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.