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. -- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
