[PKG-Openstack-devel] Status?

[Turbo Fredriksson]

On 15 Jul 2017, at 16:07, Thomas Goirand <zigo at debian.org> wrote:

> I do agree there was issues, but I don't agree I was (or I am) not
> interested dealing with it and fixing things.

Of all the issues I’ve reported, you’ve closed about half (give or take)
of them with “don’t care” (or at least that was my take from it).

They might have been corner-cases a lot of them, but even those
needs attending to.

> But for this, I was
> expecting people like you to communicate and contribute more.

Considering the respons I’ve gotten on most of my issues reported,
I don’t feel that there’s any point. You wanted to do this your way,
fine. Your way isn’t compatible with mine, so not much I can/could
do about it - you’re in charge.

But because our ways aren’t compatible, there’s very little point in
me filing (more) issues, since I don’t feel they’re being considered
(correctly).

>> My suspicion is that it didn’t fit into your (or your employers) “agenda”
> 
> My employer used puppet, and therefore, didn't care having the
> configuration (or even config files) right. Debian is the only
> distribution that cared for correctness of configuration files. I know
> it well because I was the only one reporting configuration file
> generation bugs to upstream, while Ubuntu and Red Hat people didn't even
> care for them.
> 
>> You made a good start and the whole Debian GNU/Linux community
>> is better for it, but I find your work a little short-sighted.
> 
> Could you expand on this, and explain what you would like to see improved?

I think I said that just fine above - your (former) employer was controlling
your work on Debian GNU/Linux. Their prerogative - their time and money.

But there (must) come a time where these are realised to be different,
possibly competing, goals. And in such case, Debian GNU/Linux must
ALWAYS win!

>> It IS needed, but an all-in setup needs to be tested as well, to iron out all
>> those communication and interoperability issues. Which there’s plenty
>> of unfortunately :(.
> 
> Could you explain more here?

I can’t even begin to remember! It’s been over a year ago since I set all this
up. Every time I found something that wasn’t “right”, I filed an issue about it.
Right or wrong, it’s all in the history of issues...

> Therefore, I am stepping down, because I don't believe I can do a
> good enough work if I am just doing this on my week-ends.

I can’t say anything about that, you’ll have to be the judge of that. But with
help (from Orlov et-all), this should be possible. At least to some extent.
Some is better than nothing, and I’m not sure Orlov will be able to do this
all by him self, especially if he to is only doing it on weekends..

A CI and more automation would probably help a lot, but that also takes time
to setup and build.

It took me six months, more than full time (and a couple of external contractors
a few days here and there), to setup a fully working CI at work to build, test
and deploy our ONE application from one Git repo! So I’m fully aware of the
time it can take. But in my opinion, this must be done, sooner rather than
later. It will save time and guarantee correctness down the line.


But I agree with Orlov, it’s not an absolute must at this specific time. It’s
very (*VERY*!) much preferred (and should really be prioritised), but nothing
hinges on it. We CAN get OS in (or continued support for) Debian GNU/Linux
without it.. It just require a lot more manual work every time..

> One thing which I though we could do was even contributing to the Debian
> installer, and have tasks to install OpenStack. One task for a controller, and
> one for a compute node. Your thoughts?

I’d say a very good idea, but almost impossible in practice :(.

The reason NO other script out there (and there’s *PLENTY*!!) would
work for me is that I need one (and a mirror) control node with EVERYTHING:

	aodh, barbican, ceilo, cinder, designate, glance, heat, manila,
	mistral, murano, neutron, nova (api, consoleauth, scheduler), swift,
	trove, zaqar

which then would leave 14 compute nodes. Those are easy - just Nova-compute
and Swift (because each node have two 148GB disks, one for the OS so the
other is for Swift).

That should be easy to setup, a compute node takes ten, twenty minutes
to setup (from initial boot to all services ready for VM start) if I’m not
misremembering. They’re easy…


But what different types of Control nodes do you setup? Or offer to setup
for users? I think OS have two or three different layouts they recommend
(neither served my purpose) and then there’s mine “everything on one node”…

So do you offer X number of (fixed) Control node options or then let the user
choose WHAT services (not packages!!) should run on that specific node?

The (HUGE!) problem with this is that there’s slightly different ways to setup
a service, depending on if you have another, optionally dependent, service
installed as well.


But figuring out a “bare-minimum” control node setup will quickly fail I think.

Keystone, for example (pretty much) MUST exists, but some might
want that on a completely separate, isolated host. Some might want to
run that on the same host as the *SQL server, some might want the SQL
server a separate host, but Keystone and Horizon on one. Some might
want to integrate it (Keystone) to an existing LDAP server, some want a
LDAP server setup at the same time, some don’t want LDAP at all… Etc,
etc, ad infinitum!

If you like, you could sit down and come up with a few reasonable
examples/templates for people to choose from (which could be extended to
more once people start offering suggestions), which might simplify everything.


You talked about dependency-hell in the source, but it’s even worse (or at
least just as horrible) in the “finished product”!

Which is why I think no one have done this before (I tried to, but I quickly
failed miserably as well).

Everyone concentrates around “this is how _I_ think OS should be setup
and if you don’t like it, don’t use OS and if you do any way, we’re not going
to help” (PS, this is pretty much word-by-word the Trove developer said to
me when I was trying to get Trove to work!!)… Kind’a rude, but trying to do
everything is probably impossible… And SUPPORTING everything is even
worse!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.alioth.debian.org/pipermail/openstack-devel/attachments/20170715/ce027992/attachment.sig>