On 18 April 2013 18:09, Scott Moser <email address hidden> wrote:
...
> "doing it properly in python" is a general problem that maas has.
> Maas knows too much.  The installer (xinstall) is not maas.  The
> proper way to do this is to not have the xinstall code in maas at
> all, and have maas know an interface to it.  We've pushed xinstall
> here as a temporary landing location.

I say more later, but if it's not MAAS then it shouldn't land in MAAS;
it should exist as a patch in the packaging.

...
>> It is extremely fragile and it is likely to break, horribly, in
>> many ways, as soon as someone changes anything elsewhere.
>
> We have 2 components.  yes, one component can break another
> component.  A change to python can break maas.  A change to glibc
> can break python. a change to the kernel can break glibc.  Thats
> *good* design.

It's a nitpick, but that's not good design, that's just a property of
interrelating systems.

...
> Its an installer. It should be separate.  Please just review this as
> if that code was not there.  We'll replace or move it at a later
> date.

There's no one actively driving MAAS development at this very moment,
but I guess we - the Red Squad - still feel the most responsible, and
we still care about the thing we've created. Our criteria for landing
a change to any product that we're working on is: does this improve
the product? This change does not.

It satisfies a short-term goal, that of getting something to work for
Raring, but it's a horrible change: it contains a moderately complex
program written in shell-script (meaning it's now highly complex); the
script has been cargo-culted from somewhere else, and so can diverge
unchecked; paths have been hard-coded into the template; there are no
tests; and so on.

If MAAS's limitations have meant that this was all that was possible
in the time available, then more time needs to be made available:
changing MAAS *needs* to be part of the engineering effort.

This change should *not* land on trunk. Previous changes to trunk in
the same vein as this - especially those without tests - should
probably not have landed either. This change should be carried as a
patch in the packaging.

>
>> I realise that you need to get *something* in raring before FF
>> tomorrow.  Last-minute rushed changes are never good, but if you
>> can at least add tests and make the change to the preseed template
>> as I suggested then this could land with a view to improving more
>> later.
>
> I really prefer to use user-editable and modifable template files
> than maas python files for the interface between 'xinstall' and
> maas.

Fwiw, the template files are user-editable. There's meant to be an
inheritance/override mechanism so that the templates can be installed
by the package but selectively customised in, say, /etc/maas. I'm not
sure if that's effective in practice right now, but that's the
intention. Throwing that away instead of improving it - especially by
replacing it with untested shell-script! - is not doing anyone any
favours.

If you really, definitely want to land large amounts of shell-script
to MAAS, it needs to be tested. We can help by integratiing, say,
ShUnit <http://shunit.sourceforge.net> into the test environment for
MAAS. If this is something you want, talk to Deryck and/or Julian
about it soon so that we get time to do it well before Slimy Slug.