Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/10/15 06:14, Haïkel wrote:
> 2015-10-14 21:59 GMT+02:00 Anne Gentle <annegentle at justwriteclick.com>:
>>
>>
>> On Wed, Oct 14, 2015 at 7:53 AM, Haïkel <hguemar at fedoraproject.org> wrote:
>>>
>>> Hi,
>>>
>>> I just registered to this list as someone just raised this topic to my
>>> attention. As one of the people maintaining RDO, I will answer some of
>>> the points raised.
>>> I'm not here to rant, but I get the feeling that you got frustrated by
>>> a bad experience with RDO so let's get on a better footing.

Thank you for raising these points.

The upstream docs contribution by Red Hat has dropped off considerably in this release, and I suspect this is what has led to some of these frustrations. We had no one from Red Hat actively involved in testing this time around. If we had, then I think we would have found the faults in these packages earlier. In previous releases, the RH docs team in Brisbane worked quite closely with the community, but their absence has been felt this time around.

>>>
>>>> The Delorean repo is a pretty hilarious combination of old, out of date
>>>> config files, and a few Mitaka packages thrown in for good measure
>>>
>>> Delorean is a continuous delivery platform, and there are multiples
>>> topics mixed up here:
>>> * old, out of date config files => RDO strategy is to rely on external
>>> installer (packstack or RDO Manager) to deploy and configure services.
>>> So yes, some out-of-date config files could be undetected, we try to
>>> fix them but AFAIK no tickets were opened.

The only one I'm aware of at this point is this one, which was raised by Tony Breeds while he was working with Brian Moss on Fedora testing:

https://bugzilla.redhat.com/show_bug.cgi?id=1271033

>>> * packages are automatically built for every commit, so when Liberty
>>> was branched, there was a delay between we fixed delorean
>>> configuration to track the stable/liberty branch rather than master.
>>> Some Mitaka commits were built as packages, but it was fixed rather
>>> quickly.
>>>
>>>
>>>> The Red Hat packages, on the other hand, are missing quite a few crucial
>>>> deps, including the PyMySQL deps.
>>>
>>> https://admin.fedoraproject.org/pkgdb/package/python-PyMySQL/
>>> Note this topic was raised in RDO list few weeks ago while we fixed
>>> this with Fedora/RHEL python MySQL package maintainers months ahead of
>>> this discussion.

Was this mentioned on any OpenStack lists?

>>> And RDO repositories should have all the dependencies available, but
>>> yes, if you use Fedora repositories it could be out-of-sync as we're
>>> dependent from the Fedora Reviewing process.
>>>
>>> Yes, our process review can be quite long and I do most of the reviews
>>> here, but it's got better since I added a tracker to track all reviews
>>> blocking RDO (only non-critical reviews are remaining)
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1243533
>>>
>>>> Right now, the Fedora testing situation is slightly better than the Red
>>>> Hat/CentOS one, thanks to Delorean being in slightly better shape, and
>>>> thanks to Brian Moss's dogged determination in getting it working.
>>>
>>> Ironically, nope, RDO is better supported on CentOS as we have
>>> slightly more control on our workflow there. And I'm not aware of
>>> Brian Moss efforts, so it's likely not to be fixed in RDO.

I wasn't clear here: I meant our testing has been slightly more successful under Fedora. 

>>>
>>>
>>> What bothers me is that some of these issues were never reported to
>>> us, so please open tickets or at least shout an angry mail at me :)
>>> Feel free to ping me in the future for RDO related topics, I'm
>>> number80 on freenode, I hang around #rdo, #openstack-stable and
>>> #openstack-rpm-packaging.


Well, at least I know who to contact now :)

>>
>>
>> Thanks for this info Haïkel. From my view point which is admittedly a bit
>> removed this release, I wonder if it's not so much the packaging itself
>> that's a concern, but people to test and document the packages? Is there an
>> RDO community test and writing person who could come in earlier in the
>> release and work with our install guide team?

Yes, I would echo Anne's comments here. I mentioned earlier that we've seen a lot less of Red Hat during this release. If we are to continue successfully publishing RH and Fedora Install Guides, we need committed people to undertake that work. Where have all the Red Hat writers gone? 

>>
> 
> I'm fine with not publishing untested documentation, which is
> different than "RDO packaging does not work".

To be fair, the reason we have untested guides is because we've had problems with the packaging (which may just be that we were looking in the wrong places), but I don't want to split hairs here. As I've said all along: as soon as we have solid packages, we can complete testing, and publish the books. Hopefully that won't take too long.

> Now, that I know that we have issues with the way documentation team
> install OpenStack with RDO packages,  I'll personally make sure that
> we test and fix all the issues encountered.
> If we could automate somehow all the steps, we could leverage delorean
> so that issues are fixed as soon as upstream projects change.
> 
> We do not have a dedicated writer for RDO, but we'll manage somehow.

We really need a solid plan here other than "we'll manage". If having RDO-specific upstream documentation is important to Red Hat, then they need to dedicate some writers to making that happen.

> 
> 
>> Sounds like we need earlier coordination, so if you're our contact person
>> that's fine, but might be nice to get you or another liaison integrated
>> sooner.

I agree, we need to know who our contacts are *before* things blow up. So, thanks for coming out of the woodwork, and I'll be sure to contact you earlier in the process now that I know who you are :)

>>
>> That said, let's find the right wording on the docs site for the people who
>> will be asking "what about RDO" starting tomorrow.

+1

>>
>> Anne
>>
> 
> Yes, goal is to collaborate more nicely in the futurenot to bicker :)
> As previously stated, I will join the cross-project documentation session.

Great!

Thank you for the updated repo information, hopefully we'll be able to get these tested and live very soon for you.

Lana

- -- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJWHtokAAoJELppzVb4+KUyxCAH/0hiyY8gsKuAHa+ALslM6oPX
5Q5XQ4NgNsPkd48ZdvabtLLCPtiwI7nUFc5fykAZxTGU8mbZbUnwmaSCg6PBr5/r
Ilc9wmjiFrhb+/nONnqJtYHXoudt5trpyxpE6aRAIIqb7gSPW5N8K1GPqzFC5B4B
95X4Z+397d23xnLTthkQ/JdrmS9Qy3Y8eONm2ITKA1BGOaMjw/VB0tS9oy35BiCX
B0qLfDZ6u1IY/YuIkMROxI7F1/O5fRqetXwnCKk9OSQklBYxcOhlGPLsAMEpFGQU
BZhG4ZGD6B+nWC9BscuMljkQn2eVIQXmzkIXYCae3rThrEtONdy1fbdYSA9TAsE=
=Pp11
-----END PGP SIGNATURE-----