[PKG-Openstack-devel] Status?

[Thomas Goirand]

On 07/14/2017 07:15 PM, Turbo Fredriksson wrote:
> On 14 Jul 2017, at 17:28, Thomas Goirand <zigo at debian.org> wrote:
> 
>> - PXE booted live system with a custom public ssh key to get in [1]
>> - Reset on demand (through IPMI?)
>> - Enough RAM (16, maybe 32 GB of RAM)
>> - A small scratch disk for swift (100 GB should be enough)
>>
>> [1] I do have the scripts to generate this PXE image, it's somewhere on
>> Alioth in /git/openstack …
> 
> I have one to, if that’s of  any interest. It uses a pre-seed file which in
> turn calls an initial install-setup script which in turn uses another bunch
> of scripts to do the actually install of OS.

The point of using Debian live is:
- No need to spend time installing an OS, you just boot it, it takes 1.5
minute to do the provisioning
- No need to run complicated preseed stuff that may (or may not) depend
on the hardware (ie: HDD layout, etc.)
- Everything stays in RAM, no need to write in the HDD, it is available
fully for the swift test scratch disk.

> It sets up either a all-in control node OR a compute node (depending on
> the hostname my DHCP server is providing to the host), using pre-seeding
> to debconf, but also manual installations and modifications of files etc.

Oh! So you have written a layer on top of the Debian installer that
installs OpenStack thanks to preseed? This seems great. Indeed, please
do share. I'd love to make this available in some way or another for
final Debian users (even though my Debian live method maybe has better
performance for tempest test provisioning).

> It takes less than an hour (from initial boot to finished “product”), and that’s
> by copying/downloading packages from the official repos…

The initial install of Debian doesn't even exist in the case of Debian
live, it just boots in 1 minute 30 seconds. Then installing OpenStack
takes about 20 minutes from the local repository.

> Using Puppet would have been much better, but because I’m replacing ALL
> my infrastructure at home with a 16 node OS cluster, I’m facing a
> chicken-and-egg problem :).

Please do share! :)

> If we’re going to do automated testing (which in my opinion is an absolute
> MUST before even uploading ANYTHING to the repos), we should have at
> least two nodes to test this on - one control and one compute.

Yeah, I agree. Though it has been a resource issue on my side, otherwise
I would probably used a 2 nodes setup.

> And my control node, running almost EVERYTHING, have 48GB memory,
> which almost all of it is in use...

That's probably because you're not setting-up the number of thread,
which by default depends on the number of core. In a 8 cores/16 threads
machine, you end up with really too many daemons, which takes too much
RAM for no reason (at least no reason for such tempest validation).

>>>    I do not think that there's my way vs your way. I don't think anyone can
>>>    even remotely contest the advantage of functional testing. The only
>>>    issue is how, and if there's enough resources to do it.
>>>
>>> As i sad: functional testing is nice, but not must-have.
>>
>> Let's agree to not agree on the urgency, and just attempt to fix the
>> current situation! :)
> 
> Personally, as a user, I rather have NO OS in Debian GNU/Linux than one
> that can’t be guaranteed to work! OS is way, WAY to difficult and complicated
> as it is to get working in it self, than to have to worry about “stuff” not being
> tested or maybe not working [correctly].

Right, that's exactly my thinking as well. And if we didn't perform the
tests, we would have lost users like yourself, because of too many
issues that we wouldn't have foresee. I absolutely don't want to loose
someone like you (your bug reports are too valuable).

Thanks again for your contributions to this group,
Cheers,

Thomas Goirand (zigo)