Standing SRU for new MAAS releases.

[Marc Deslauriers]

Hi,

On 14-08-13 07:58 PM, Andres Rodriguez wrote:
> 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.
> 

It's still unclear to me how you are going to make sure a mix of different major
versions on controllers and nodes will be handled properly.

How far back will you maintain backward and forward compatibility?
How will you automate testing of all the different combinations of versions?

Are there any scenarios that will not be handled? For example, will there be any
restrictions in mixing different versions where, for example, controllers need
to be a higher version than the nodes, or that all controllers need to run the
same version, etc?

Marc.