Standing SRU for new MAAS releases.

[Marc Deslauriers]

Hi,

On 14-09-02 09:26 AM, Marc Deslauriers wrote:
> 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?

I am still awaiting answers to my questions. Perhaps my original post got
overlooked?

Thanks,

Marc.