Re: [Gluster-infra] Switching from salt to ansible ?

[Michael Scherer]

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] Request for a Gerrit account for the CentOS CI Jenkins

[Niels de Vos]

On Tue, Jan 05, 2016 at 11:08:33AM +0530, Kaushal M wrote:
> On Tue, Jan 5, 2016 at 10:52 AM, Kaushal M  wrote:
> > On Tue, Jan 5, 2016 at 9:30 AM, Kaushal M  wrote:
> >> On Mon, Jan 4, 2016 at 9:58 PM, Michael Scherer  
> >> wrote:
> >>> Le lundi 04 janvier 2016 à 16:33 +0100, Niels de Vos a écrit :
>  On Mon, Jan 04, 2016 at 04:16:14PM +0100, Michael Scherer wrote:
>  > Le lundi 04 janvier 2016 à 09:24 +0530, Kaushal M a écrit :
>  > > On Sun, Jan 3, 2016 at 6:34 PM, Niels de Vos  
>  > > wrote:
>  > > > Hi!
>  > > >
>  > > > I would like to request a Gerrit account for the CentOS CI Jenkins
>  > > > (ci.centos.org) so that we can setup jobs based on Gerrit triggers.
>  > > > Could you please create an account with the following details?
>  > > >
>  > > >   Username: centos-ci
>  > > >   Email: (hmm, maybe a new list, or alias like 
>  > > > centos...@gluster.org?)
>  > > >   Public-key: ssh-rsa 
>  > > > B3NzaC1yc2EDAQABAAABAQDCu9qWPHYJm+s4Nq1seE82Q+m3Ilq82Z+GkK88tgy7aNMeJ5DWeHMTo+jCu+sV68uXXAGIC0IvGeQPeTae1Rk6WYyPz+l/LQUME051i/ke0wG/1SaaWkduK6KDqnC9xi4Ud/ZDF+/StIqlSKM7/FIPzcqOV3TAEU4B82MRA3NaNJrTHLgdTqqDXZc9snEp7pBsWfTu4ojeV/Nv2dcdfcdWkT9VSDIUmhfGYODAnEQACrw0P4V17gkPMYV96jgU06HIXiSz20JnA1E6PazAtHLEPOfQR4D5csJ+3DpoBek3PUB8E4kqRAouz4qIWzum4Sc2d1AE8UTkxIWBXjf5bkGd
>  > > >  centos...@review.gluster.org
>  > > >   See-also: 
>  > > > http://review.gluster.org/Documentation/access-control.html#examples_cisystem
>  > > >
>  > >
>  > > I can create the bot account, but someone else (Misc) needs to create
>  > > the mail alias/list.
>  >
>  > Well, what do we want to do with it ?
>  >
>  > And what kind of information will be sent to that email ?
> 
>  Not sure... Anything that gets sent to Gerrit users, I guess? If a
>  Gerrit account does not require an email address, that would probably be
>  easier. Email addresses need to be unique, I think, otherwise it'll be a
>  weird auto-competion in the Gerrit UI.
> >>>
> >>> But so, who need to read that, and is there some "reset password" system
> >>> using this email ? ( in which case, we shouldn't maybe push that to a
> >>> public ml)
> >>
> >> AFAIK emails are only sent if you register for alerts. Bot accounts
> >> are created under  the 'Non interactive users' group by gerrit admins.
> >> I believe you wouldn't be able to login to the account via the
> >> web-interface, so there is no way to register for alerts. I'll check
> >> if I can create  the account without providing an email address.
> >
> > Huh, our old version of gerrit doesn't have a non-interactive users group 
> > :-(
> > Another reason to update gerrit.
> >
> 
> I created the account and added it to the 'Event Streaming Users'
> group. This should allow the ci.centos.org to stream events from
> review.gluster.org. It did not require an email address to be created.
> We can add and address later if required.

Thanks! I dont think we require an email address for it if Gerrit does
not demand one. Login seems to function, and the "gerrir stream-events"
command seems to work too.

I've requested the Jenkins account here:
  https://bugs.centos.org/view.php?id=10080

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 ?

[Kaushal M]

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

[Gluster-infra] [Bug 1291537] [RFE] Provide mechanism to spin up reproducible test environment for all developers

[bugzilla]

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



--- Comment #4 from Vijay Bellur  ---
REVIEW: http://review.gluster.org/13175 (vagrant-test: Exit on critical errors)
posted (#1) for review on master by Raghavendra Talur (rta...@redhat.com)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=5qlqfcWTXC=cc_unsubscribe
___
Gluster-infra mailing list
Gluster-infra@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-infra