Standing SRU for new MAAS releases.

Marc Deslauriers marc.deslauriers at canonical.com
Tue Sep 30 16:14:14 UTC 2014


Hi Andres,

On 14-09-25 03:45 PM, Andres Rodriguez wrote:
> 
> 
> On Thu, Sep 25, 2014 at 2:39 PM, Andres Rodriguez <andreserl at ubuntu.com
> <mailto:andreserl at ubuntu.com>> wrote:
> 
>     Hi Marc,
> 
>     Sorry for a late reply, I missed your email.
> 
>         It's still unclear to me how you are going to make sure a mi x of
>         different major
>         versions on controllers and nodes will be handled properly.
> 
>         How far back will you maintain backward and forward compatibility?
> 
> 
>     The MAAS API is fully backward and forward compatible. We have ensured that
>     all API calls have not changed with the new upstream changes. This ensures
>     that users of the MAAS API are not affected with the new features. We have
>     put this in practice on deployments that use the MAAS API.
> 
>          
> 
>         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?
> 
> 
> There will be restrictions in mixing different versions when:
> 
> We are using an older version of Curtin. Newer version of MAAS has added support
> for different Hardware Architectures, that require its counterpart in Curtin.
> This is why curtin has been added to this request.
> 
> Fortunately, a newer version of MAAS with and older version of MAAS remains
> fully backward compatible in the sense that already enabled and certified
> architectures (in MAAS) wont be affected. 

Thanks for your answer. How are you ensuring that the ABI isn't changing? Is
that done in an automated way? Will that be part of the testing that will be put
in place?

Thanks,

Marc.




More information about the technical-board mailing list