On Nov 13, 2015, at 11:07 PM, Jeff Pullen <jpullen(a)redhat.com>
I'm new here... so I apologize if this has already been discussed. It seems that not
much has been done lately with the OpenStack SCAP content. So it seems like a good place
to start learning how to contribute to this project.
1. I wanted to get opinions on how to tackle the quick release cycle, and various
components used within OpenStack. I noticed that in RHEL it is broken into versions
(5/6/7), but Fedora isn't. OpenStack has a Fedora like release cycle, and it may be
difficult to maintain numerous versions. Does it make sense to just have this work with
the latest version?
You might consider githooks against the source trees for each of the components. If you
can tie a rule to source code files, or configuration files, you might be able to at least
follow when code you care about has changed. So, if a piece of code uses a TLS library
that needs configured, I would watch for changes to the code (which changed implementation
and how configuration files are parsed) and default configuration files (which may set
different defaults or new options).
I saw an article on Nova suggesting that sites run all kinds of different versions of the
various components, not necessarily sticking to a baseline. Some even pull from source.
Ball Aerospace & Technologies Corp.
2. OpenStack also has different server roles that will have different
requirements, and services. For example the controllers have databases and web servers,
where the computes will not. What is the best way to separate these?
Finally, if there are resources that can cut down on the learning curve on how all the
scap files interact with each other I would really appreciate if you could send me those
SCAP Security Guide mailing list
This message and any enclosures are intended only for the addressee. Please
notify the sender by email if you are not the intended recipient. If you are
not the intended recipient, you may not use, copy, disclose, or distribute this
message or its contents or enclosures to any other person and any such actions
may be unlawful. Ball reserves the right to monitor and review all messages
and enclosures sent to or from this email address.