Re: [Gluster-infra] Switching from salt to ansible ?
Le mardi 05 janvier 2016 à 14:59 +0100, Michael Scherer a écrit : > > Another solution is to use ansible over salt > ( https://github.com/ansible/ansible/pull/12836 ), which mean we get the > benefit of both world. If we decide to switch, I would maybe start by > that until we can get a more secured network setup (ie, reuse the > existing salt setup, and migrate slowly). > So it turn out that I am not able to properly take time off, and on Sunday one week ago, I did enough commits on my ansible role[1] to support the group based model I wanted to use. It also turn out that I was able to make ansible run on salt for the transition today without much fuzz[2]. So since I didn't see much opposition, I went ahead and did started the migration from salt to ansible. I will give more details once I make sure I fixed freeipa deployment (so we can use it for LDAP and access control for the git repo, as it is planned ), and then we will see the way forward from there. [1] https://github.com/OSAS/ansible-role-ansible_bastion/commits/master [2] https://github.com/OSAS/ansible-role-salt_transport -- Michael Scherer Sysadmin, Community Infrastructure and Platform, OSAS signature.asc Description: This is a digitally signed message part ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Switching from salt to ansible ?
Le lundi 04 janvier 2016 à 17:27 +0100, Michael Scherer a écrit : > - salt in epel is still using a old version ( for dependencies reasons > ). While this is working well enough, it make contributing quite > difficult, and prevent using some new features that are needed. of course, the fun is that freebsd is shipping the new version, and it break: # salt -t 60 'freebsd0.cloud.gluster.org' test.ping freebsd0.cloud.gluster.org: 'test' __virtual__ returned False ERROR: Minions returned with non-zero exit code SO yeah, keeping minion and server at the same level if a bit annoying unless we ship our own packages. And while I could do that, I am not sure I want to become a expert in all possible packages managers... -- Michael Scherer Sysadmin, Community Infrastructure and Platform, OSAS signature.asc Description: This is a digitally signed message part ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Switching from salt to ansible ?
Le mardi 05 janvier 2016 à 10:22 +0100, Niels de Vos a écrit : > On Mon, Jan 04, 2016 at 05:27:10PM +0100, Michael Scherer wrote: > > Hi, > > > > so over the holidays, I was pondering on moving to ansible from salt. > > > > So the reasons are numerous: > > > > - I am personally much more efficient with ansible than with salt > > (despite using salt for 1 year). While the 2 tools do the same basic > > stuff, there is always some difference (like user vs owner), and there > > is a totally different philosophy when it come to multiple servers > > orchestration (one example is how I do deploy freeipa on salt vs > > ansible). > > Many of us are more familiar with Ansible than Salt. It'll be easier to > get contributions from developers when Ansible is used. Yeah, that's the point. But I also wanted to know how much people know the tools, for how long, etc, etc. > > > - Fedora is using ansible, and while we can't reuse their code that > > much, we can at least take it and adapt. > > And can ask the Fedora sysadmins for help/ideas, or discuss the general > approach of a role/task. If something in our Ansible doesn't work well > enough, they might be able to share their thoughts. Fedora Infra is > interested in Gluster and they would surely assist with some bits in > return for our help ;-) yeah, that's a issue I have with salt, not much people to discuss with ( as I converted my friends to ansible...). And while I go to the local salt meetup every time, I often ask to do stuff in a different way that the salt philosophy, or where doing things properly would requires more python code (like freeipa integration, for one) > > Now, there is a few downsides: > > > > - it mean rewriting most of the stuff we already have > > > > - it mean that we depend on sshd to be running. IE, if we screwed ssh > > config (happened in the past), we can't just use salt to fix it. > > Having ssh running, or the salt-minion, does not make much of a > difference to me. IIRC, salt-minion do not open a port, it connect to the salt-master. It can also connect in a P2P fashion, or run locally. Both tools are equally flexible on that point. But the way we use salt is the standard way, one salt-master, where each minion connect to receive order. And the point is "I deploy a new config change on openssh", who do not work on EL5, and poof, we lost the access on a server. When it did happen on salt, I just reverted the change and that's it (happened last year). In the mean time, I did add safeguard (like testing the config before a restart...), so that's less risky, but still. > > - it also mean that we will have a ssh key to connect as root on a > > server, and i am not that confortable with the idea (provided that we > > use the regular method of using ansible, ie push based) > > Or (a dedicated ansible user and) use sudo? Might make auditing a little > easier. I think its even possible to use sshd/Match on a username and > only allow certain logins from selected sources (like a management > server). yeah, making the key restricted by IP seems the best protection (it might cause some bootstrapping issues, but I guess I can fix that). About sudo, not sure what it does bring to us in term of auditing. Ansible do send everything to syslog anyway, and sshd can tell you what key was used (maybe not by default, and that's for sure less obvious to grep in log). And having ssh ansible@server + sudo without password seems the same ssh root@server regarding access granted by the key. Maybe I am missing a race condition regarding the log (ie, if someone do ssh root@server killall -9 syslog, will the connexion be logged to the remote syslog server ?) Another solution is to use ansible over salt ( https://github.com/ansible/ansible/pull/12836 ), which mean we get the benefit of both world. If we decide to switch, I would maybe start by that until we can get a more secured network setup (ie, reuse the existing salt setup, and migrate slowly). -- Michael Scherer Sysadmin, Community Infrastructure and Platform, OSAS signature.asc Description: This is a digitally signed message part ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Switching from salt to ansible ?
Le mardi 05 janvier 2016 à 10:55 +0530, Kaushal M a écrit : > On Mon, Jan 4, 2016 at 9:57 PM, Michael Scherer wrote: > > > > - having a client/server model is something that caused trouble with > > puppet when they decided to support only 1 version of ruby (around the > > ruby 2.0 time frame). And given the transition of python2 and 3 is > > happening right now in Fedora, I foresee this might be the same kind of > > issue for salt. > > I think this would be a problem with Ansible as well, as it depends on > python2. I've faced some small hiccups getting ansible to manage Arch > Linux which uses python3 by default. Most distribution will be staying with python2 as a option to be installed, so the burden is minimal, but yeah, same for ansible. Fedora atomic is shipping python2 on purpose to be manageable by ansible. Now for salt, maybe they will do the same, but in the case of puppet, there was a unwillingness of the ruby packager to offer 2 version, and a strong dependencies on agent and the puppetmaster preventing any mismatch. > > > > - Fedora is using ansible, and while we can't reuse their code that > > much, we can at least take it and adapt. > > > > Now, there is a few downsides: > > > > - it mean rewriting most of the stuff we already have > > > > - it mean that we depend on sshd to be running. IE, if we screwed ssh > > config (happened in the past), we can't just use salt to fix it. > > > > - it also mean that we will have a ssh key to connect as root on a > > server, and i am not that confortable with the idea (provided that we > > use the regular method of using ansible, ie push based) > > > > and maybe other I didn't think of. > > I've sometime had Ansible modules which failed to run on the remote > host because it lacked some python packages. This could be a problem > for Ansible. I've not faced this with Salt yet, maybe because the > remote hosts need to have salt installed which would pull in all > dependencies. Nope, same issue with salt. But that's easy to fix, just add the required packages as needing to be installed before. -- Michael Scherer Sysadmin, Community Infrastructure and Platform, OSAS signature.asc Description: This is a digitally signed message part ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Switching from salt to ansible ?
On Tue, Jan 5, 2016 at 2:52 PM, Niels de Vos wrote: > On Mon, Jan 04, 2016 at 05:27:10PM +0100, Michael Scherer wrote: >> Hi, >> >> so over the holidays, I was pondering on moving to ansible from salt. >> >> So the reasons are numerous: >> >> - I am personally much more efficient with ansible than with salt >> (despite using salt for 1 year). While the 2 tools do the same basic >> stuff, there is always some difference (like user vs owner), and there >> is a totally different philosophy when it come to multiple servers >> orchestration (one example is how I do deploy freeipa on salt vs >> ansible). > > Many of us are more familiar with Ansible than Salt. It'll be easier to > get contributions from developers when Ansible is used. > >> - Since I use ansible for most others projects, I do already have a few >> roles for most of the thing I want to deploy (freeipa, nagios, etc), and >> adding features on them and then again on salt is not very efficient. >> >> - One of the initial reasons to choose salt was a tiny margin of people >> who know it in the community, vs ansible. I suspect this is no longer >> valid. For example, the vagrant image for developper is made using >> ansible, and I know a few people in the dev community who use ansible. I >> still think no one grok salt. >> >> - Another of the reason of using salt vs ansible is that salt was much >> faster to apply configuration, especially if done on git commit. While >> that's true, I managed to make it good enough on manageiq.org using >> smart post-commit hook, and salt is getting also slower the more stuff >> we add to configuration. >> >> - salt in epel is still using a old version ( for dependencies reasons >> ). While this is working well enough, it make contributing quite >> difficult, and prevent using some new features that are needed. >> >> - having a client/server model is something that caused trouble with >> puppet when they decided to support only 1 version of ruby (around the >> ruby 2.0 time frame). And given the transition of python2 and 3 is >> happening right now in Fedora, I foresee this might be the same kind of >> issue for salt. >> >> - Fedora is using ansible, and while we can't reuse their code that >> much, we can at least take it and adapt. > > And can ask the Fedora sysadmins for help/ideas, or discuss the general > approach of a role/task. If something in our Ansible doesn't work well > enough, they might be able to share their thoughts. Fedora Infra is > interested in Gluster and they would surely assist with some bits in > return for our help ;-) > >> Now, there is a few downsides: >> >> - it mean rewriting most of the stuff we already have >> >> - it mean that we depend on sshd to be running. IE, if we screwed ssh >> config (happened in the past), we can't just use salt to fix it. > > Having ssh running, or the salt-minion, does not make much of a > difference to me. > >> - it also mean that we will have a ssh key to connect as root on a >> server, and i am not that confortable with the idea (provided that we >> use the regular method of using ansible, ie push based) > > Or (a dedicated ansible user and) use sudo? Might make auditing a little > easier. I think its even possible to use sshd/Match on a username and > only allow certain logins from selected sources (like a management > server). > >> and maybe other I didn't think of. >> >> Any opinions ? > > I prefer the move to Ansible, it would allow me to contribute changes > without learning Salt. Fixing/improving Ansible (in Python) is also > something that I can do, but I'll stay away from patching Salt (in > Ruby). Salt is also a Python based tool. You were probably thinking about Puppet or Chef. :) > > Niels > > ___ > Gluster-infra mailing list > Gluster-infra@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-infra ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Switching from salt to ansible ?
On Mon, Jan 04, 2016 at 05:27:10PM +0100, Michael Scherer wrote: > Hi, > > so over the holidays, I was pondering on moving to ansible from salt. > > So the reasons are numerous: > > - I am personally much more efficient with ansible than with salt > (despite using salt for 1 year). While the 2 tools do the same basic > stuff, there is always some difference (like user vs owner), and there > is a totally different philosophy when it come to multiple servers > orchestration (one example is how I do deploy freeipa on salt vs > ansible). Many of us are more familiar with Ansible than Salt. It'll be easier to get contributions from developers when Ansible is used. > - Since I use ansible for most others projects, I do already have a few > roles for most of the thing I want to deploy (freeipa, nagios, etc), and > adding features on them and then again on salt is not very efficient. > > - One of the initial reasons to choose salt was a tiny margin of people > who know it in the community, vs ansible. I suspect this is no longer > valid. For example, the vagrant image for developper is made using > ansible, and I know a few people in the dev community who use ansible. I > still think no one grok salt. > > - Another of the reason of using salt vs ansible is that salt was much > faster to apply configuration, especially if done on git commit. While > that's true, I managed to make it good enough on manageiq.org using > smart post-commit hook, and salt is getting also slower the more stuff > we add to configuration. > > - salt in epel is still using a old version ( for dependencies reasons > ). While this is working well enough, it make contributing quite > difficult, and prevent using some new features that are needed. > > - having a client/server model is something that caused trouble with > puppet when they decided to support only 1 version of ruby (around the > ruby 2.0 time frame). And given the transition of python2 and 3 is > happening right now in Fedora, I foresee this might be the same kind of > issue for salt. > > - Fedora is using ansible, and while we can't reuse their code that > much, we can at least take it and adapt. And can ask the Fedora sysadmins for help/ideas, or discuss the general approach of a role/task. If something in our Ansible doesn't work well enough, they might be able to share their thoughts. Fedora Infra is interested in Gluster and they would surely assist with some bits in return for our help ;-) > Now, there is a few downsides: > > - it mean rewriting most of the stuff we already have > > - it mean that we depend on sshd to be running. IE, if we screwed ssh > config (happened in the past), we can't just use salt to fix it. Having ssh running, or the salt-minion, does not make much of a difference to me. > - it also mean that we will have a ssh key to connect as root on a > server, and i am not that confortable with the idea (provided that we > use the regular method of using ansible, ie push based) Or (a dedicated ansible user and) use sudo? Might make auditing a little easier. I think its even possible to use sshd/Match on a username and only allow certain logins from selected sources (like a management server). > and maybe other I didn't think of. > > Any opinions ? I prefer the move to Ansible, it would allow me to contribute changes without learning Salt. Fixing/improving Ansible (in Python) is also something that I can do, but I'll stay away from patching Salt (in Ruby). Niels signature.asc Description: PGP signature ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Switching from salt to ansible ?
On Mon, Jan 4, 2016 at 9:57 PM, Michael Scherer wrote: > Hi, > > so over the holidays, I was pondering on moving to ansible from salt. I'd like this as well, as I'm more familiar with Ansible as well. If switching to Ansible helps reduce the burden on you, I think we should do the switch. > > So the reasons are numerous: > > - I am personally much more efficient with ansible than with salt > (despite using salt for 1 year). While the 2 tools do the same basic > stuff, there is always some difference (like user vs owner), and there > is a totally different philosophy when it come to multiple servers > orchestration (one example is how I do deploy freeipa on salt vs > ansible). > > - Since I use ansible for most others projects, I do already have a few > roles for most of the thing I want to deploy (freeipa, nagios, etc), and > adding features on them and then again on salt is not very efficient. > > - One of the initial reasons to choose salt was a tiny margin of people > who know it in the community, vs ansible. I suspect this is no longer > valid. For example, the vagrant image for developper is made using > ansible, and I know a few people in the dev community who use ansible. I > still think no one grok salt. > > - Another of the reason of using salt vs ansible is that salt was much > faster to apply configuration, especially if done on git commit. While > that's true, I managed to make it good enough on manageiq.org using > smart post-commit hook, and salt is getting also slower the more stuff > we add to configuration. > > - salt in epel is still using a old version ( for dependencies reasons > ). While this is working well enough, it make contributing quite > difficult, and prevent using some new features that are needed. > > - having a client/server model is something that caused trouble with > puppet when they decided to support only 1 version of ruby (around the > ruby 2.0 time frame). And given the transition of python2 and 3 is > happening right now in Fedora, I foresee this might be the same kind of > issue for salt. I think this would be a problem with Ansible as well, as it depends on python2. I've faced some small hiccups getting ansible to manage Arch Linux which uses python3 by default. > > - Fedora is using ansible, and while we can't reuse their code that > much, we can at least take it and adapt. > > Now, there is a few downsides: > > - it mean rewriting most of the stuff we already have > > - it mean that we depend on sshd to be running. IE, if we screwed ssh > config (happened in the past), we can't just use salt to fix it. > > - it also mean that we will have a ssh key to connect as root on a > server, and i am not that confortable with the idea (provided that we > use the regular method of using ansible, ie push based) > > and maybe other I didn't think of. I've sometime had Ansible modules which failed to run on the remote host because it lacked some python packages. This could be a problem for Ansible. I've not faced this with Salt yet, maybe because the remote hosts need to have salt installed which would pull in all dependencies. > > Any opinions ? > -- > Michael Scherer > Sysadmin, Community Infrastructure and Platform, OSAS > > > > ___ > Gluster-infra mailing list > Gluster-infra@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-infra ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Switching from salt to ansible ?
Hi, so over the holidays, I was pondering on moving to ansible from salt. So the reasons are numerous: - I am personally much more efficient with ansible than with salt (despite using salt for 1 year). While the 2 tools do the same basic stuff, there is always some difference (like user vs owner), and there is a totally different philosophy when it come to multiple servers orchestration (one example is how I do deploy freeipa on salt vs ansible). - Since I use ansible for most others projects, I do already have a few roles for most of the thing I want to deploy (freeipa, nagios, etc), and adding features on them and then again on salt is not very efficient. - One of the initial reasons to choose salt was a tiny margin of people who know it in the community, vs ansible. I suspect this is no longer valid. For example, the vagrant image for developper is made using ansible, and I know a few people in the dev community who use ansible. I still think no one grok salt. - Another of the reason of using salt vs ansible is that salt was much faster to apply configuration, especially if done on git commit. While that's true, I managed to make it good enough on manageiq.org using smart post-commit hook, and salt is getting also slower the more stuff we add to configuration. - salt in epel is still using a old version ( for dependencies reasons ). While this is working well enough, it make contributing quite difficult, and prevent using some new features that are needed. - having a client/server model is something that caused trouble with puppet when they decided to support only 1 version of ruby (around the ruby 2.0 time frame). And given the transition of python2 and 3 is happening right now in Fedora, I foresee this might be the same kind of issue for salt. - Fedora is using ansible, and while we can't reuse their code that much, we can at least take it and adapt. Now, there is a few downsides: - it mean rewriting most of the stuff we already have - it mean that we depend on sshd to be running. IE, if we screwed ssh config (happened in the past), we can't just use salt to fix it. - it also mean that we will have a ssh key to connect as root on a server, and i am not that confortable with the idea (provided that we use the regular method of using ansible, ie push based) and maybe other I didn't think of. Any opinions ? -- Michael Scherer Sysadmin, Community Infrastructure and Platform, OSAS signature.asc Description: This is a digitally signed message part ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
