Hello Andres, Andres Rodriguez [2014-07-21 14:20 -0400]: > - 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) > - Making MAAS easier to use by providing UI and CLI improvements. How do you ensure CLI API stability, to avoid breaking existing scripts? > 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. > 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? Thanks! Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
-- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
