I would like to work with someone who knows the truth about these issues.
Having someone who is not a committer working on the doc team helps a lot so that insider knowledge is not assumed to be widely known.

The accuracy of the documentation is not that bad but in programming, you can not have an "almost correct" product.
The documentation is one of the big barriers to entry.

Besides being wrong or outdated which makes it hard to use, it also projects an image of low quality and sloppy craftsmanship.

Using iptables in a CentOS7 environment just says that your product is dated and not keeping up with modern thinking.

$ iptables -I INPUT -p tcp -m tcp --dport 22 -j ACCEPT
should be
firewall-cmd --zone=public --add-port=22 --permanent
or, even better,
firewalld-cmd --zone=public --add-service=sshd --permanent

Much clearer that the rather obscure iptables statement which is cryptic to say the least.

It is not hard to fix the docs to use Firewalld.

The current installation does not suggest removing Firewalld so I gather that Cloudstack runs just fine with Firewalld.
The problem appears to just exist in the docs.

Ron

On 15/04/2018 7:12 AM, Parth Patel wrote:
Hi Ron,

Thanks for identifying this pressing issues. Many of my friends to whom I
have recommended to use Cloudstack (at UG level) say that it the docs are
mostly using CentOS 6's commands for RHEL/CentOS and that many a times they
have ran into issues with the documentation. What I do for host KVM
installation is stop and disable the firewalld, and then install
iptables-services package in CentOS 7. I think Cloudstack regulates the
firewall using iptables, so firewalld support would have to change the way
ACS manages network. I have personally prepared a host KVM installation
document (almost like quick install guide) which includes the changes or
deviations you need to do from the official documentation. If ACS community
needs help in documentation work, I can help as I have few months until the
start of my masters.

Your all other mails too, are relevant. I had a tough time figuring out and
explaining each concept to my colleagues during my internship at a company
as most of the ACS documentation is dated and is no longer relevant. I was
thinking to implement a ACS plugin, but as there were no sufficient docs
available I gave up on it. I don't want anyone to feel the same despair I
experienced if they wanted to extend ACS and add to the ACS community. I
have by far loved ACS more than OpenStack and would certainly love to
contribute to it.

Regards,
Parth Patel

On Sun, 15 Apr 2018 at 10:09 Ron Wheeler <rwhee...@artifact-software.com>
wrote:

http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/4.11/hypervisor/kvm.html

I am surprised to see that RedHat is not supported/recommended.

What about Atomic? CoreOS?

*Homogeneous CPUs*

"All hosts within a cluster must be homogenous. The CPUs must be of the
same type, count, and feature flags"
This appears to be an attempt to add some flesh to the definition of
homogeneous.
   What does type mean - AMD vs Intel? Can you really not use an Athlon
in the same cluster as a Phenom?

Count of what? CPUs?

Surely not all feature flags matter?

What is the real restriction?

When you deploy CloudStack, the hypervisor host must not have any VMs
already running. These will be destroy by CloudStack

Might be better expressed as
When you deploy CloudStack, any VMs already running on the hypervisor
host will be destroyed by CloudStack.

*Configure CPU model for KVM guest (Optional)*

By default, the CPU model of KVM instance is likely QEMU Virtual CPU
version x.x.x with least CPU features exposed.

likely??? What does this mean?

*CentOS 7 uses Firewalld**
*

The section on opening ports in the firewall uses iptables which is no
longer used in CentOS 7*
*

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102 <(866)%20970-2435>



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Reply via email to