Hello Parth, That is nice to hear! We indeed need some work in CloudStack's documentation page. To contribute to the docs you can do via a PR to either [1] or [2]. If you have any feature clarification requirement or discussion that you think will improve the documentation, you can reach us all via us...@cloudstack.apache.org or dev@cloudstack.apache.org.
[1] https://github.com/apache/cloudstack-docs-admin [2] https://github.com/apache/cloudstack-docs On Mon, Apr 16, 2018 at 8:02 AM, Parth Patel <parthpatel2...@gmail.com> wrote: > Hi CloudStack dev team, > > How do I contribute to the docs? Can any PMC (i don't know the full form) > committee member help me and Ron with these issues? We would require > someone who knows the internal working of cloudstack so that we can prepare > accurate and precise docs which work and helps new users understand > cloudstack better. > > Thanks and regards, > Parth Patel > > On Sun, 15 Apr 2018 at 19:14 Ron Wheeler <rwhee...@artifact-software.com> > wrote: > > > 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 <rwheeler@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> <(866)%20970-2435> > > >> > > >> > > > > -- > > Ron Wheeler > > President > > Artifact Software Inc > > email: rwhee...@artifact-software.com > > skype: ronaldmwheeler > > phone: 866-970-2435, ext 102 <(866)%20970-2435> > > > > > -- Rafael Weingärtner
