Standing SRU for new MAAS releases.

Andres Rodriguez andreserl at ubuntu.com
Wed Aug 13 23:58:22 UTC 2014


Hi Martin,

Sorry for the late reply.


> >    - Change DHCP Management in MAAS to make it robust.
> >    - Getting rid of moving parts (Getting rid of the usage of Celery,
> >    RabbitMQ, others)
>
> So none of those are considered "public API", it's all through MAAS
> specific projects? (I. e. it's not supported to inject AMQP requests
> into the queues from scripts or so, only through MAAS)
>

Correct. This is not at all public API, as this is all internal to MAAS.

>
> >    - Making MAAS easier to use by providing UI and CLI improvements.
>
> How do you ensure CLI API stability, to avoid breaking existing
> scripts?
>

We maintain backwards compatibility.


>
> >    No new dependencies will be introduced into MAAS that are not already
> in
> >    the “main” component of the Ubuntu archive (Question: what about
> >    dependencies in universe, can we do a MIR?)
>
> As discussed in today's TB meeting, we really don't want to include
> that into a provisional MRE. This should be avoided at all cost, and
> if such an exceptional case happens I'd rather have the options be
> discussed individually in a TB meeting than giving a blanket exception.
>

The goal is to not introduce any new dependencies. Rather, we would like to
reduce the number of dependencies by removing moving parts (such as celery
and rabbitmq eventually). However, if new dependencies are seen to be
required, we will discuss this with the TB before we move forward with it.

>
> >    Extensive QA / Automated Testing of new MAAS releases, including
> upgrade
> >    testing.
> >    We will provide an upgrade path that "just works".
>
> Can you please expand that? I. e. how do you make sure that existing
> MAAS deployments that were done with earlier versions continue to work
> with proposed new versions? How much do protocol changes affect
> particular hardware, i. e. up to which degree can this be tested
> automatically with e. g. a bunch of commodity hardware or even QEMU,
> and which parts would need the actual supported set of hardware,
> things like ppc64el or ARM servers, or other hardware which is hard to
> get into a CI environment?
>

We currently maintain backwards compatibility with all of the components,
so every upgrade will yield a working MAAS that continues to work as
expected. We currently do manual testing for upgrades, but we are in the
process of adding automated upgrade testing to our CI.

As far of the hardware, our CI has a few different types of hardware that
we test against, including QEMU VM's. Protocol changes are tested against
each different type to ensure that different type of hardware is not
affected (specially when it comes to BMC controllers, that include IPMI,
AMT and virsh).

For other type of hardware, such as ppc64el or ARM we do double manual
testing. We test the newer version of MAAS against this hardware manually,
and then once again when a new MAAS version hits -proposed (which has been
the case for 1.5.1 / 1.5.2). Furthermore, we also test the latest MAAS
releases and MAAS trunk in other Lab, where we do have more variety of
hardware that is far more extensive than the one on our CI. In this lab we
test the latest available MAAS on daily bases against every single type of
hardware we have enabled to ensure that everything works as expected. This
is to ensure that new MAAS releases don't introduce any regressions that
affect the enabled hardware.

Hope this answers your questions.

Thanks



>
> Thanks!
>
> Martin
>
> --
> Martin Pitt                        | http://www.piware.de
> Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
>



-- 
Andres Rodriguez (RoAkSoAx)
Ubuntu Server Developer
Systems Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20140813/3f202eb4/attachment.html>


More information about the technical-board mailing list