Need some help writing gitlab and gitlab-shell specs

[Axilleas Pipinellis]

On 09/23/2013 02:11 PM, Vít Ondruch wrote:
> Dne 19.9.2013 20:42, Axilleas Pipinellis napsal(a):
>>
>> I have asked in #fedora-infra what FHS they use with the git repos in
>> fedorahosted and we concluded that the rails apps would go to
>> /usr/share/ and git repos and satellites to /usr/lib/.
>
> Git repos in /usr/lib? That does not sound right. Later, you mention on
> same places /var/lib, that is more appropriate IMO. You might want to
> link to specific section of FHS and elaborate on such decision.
>

/usr/lib/ was the outcome of a brief discussion in #fedora-admin (sorry, 
in my previous message I wrote #fedora-infra). I then changed it to 
/var/lib/ as it seemed more appropriate.

>> So the current structure is:
>>
>> |-- /usr/share/gitlab/
>> |     |-- gitlab/
>> |     |-- gitlab-shell/
>> |
>> |-- /var/lib/gitlab/
>> |     |-- satellites/
>> |     |-- repositories/
>> |     |-- .ssh/authorized_keys
>> |
>> |-- /etc/gitlab/
>> |    |-- gitlab.yml
>> |    |-- shell.yml
>> |    |-- database.yml
>> |    |-- unicorn.rb
>>
>> In /etc there will be configuration files with symlinks in the rails
>> app dirs. What are your thoughts on the directory locations? Do you
>> agree?
>
> That looks good. However, I am not sure about the /etc/gitlab. Why there
> should be linked all the configuration? Current trend (which I support)
> is keep default configuration somewhere by the application, e.g. in
> /usr/{lib,share} and into /etc/gitlab place just configuration
> overrides, i.e. if you need to differ, you place configuration file into
> /etc/gitlab, otherwise the defaults are taken.
>

I'm not sure how "configuration overrides" could be supported. In 
/etc/gitlab/ all configs are symlinked to the relevant app dir so an 
admin can change them easily.

>>
>> - rake tasks
>>
>> Many jobs, like the backup, initial database seed, etc. are done with
>> rake tasks. How do we invoke them without getting in the app root dir
>> every time? Is there some sort of mechanism for that?
>
> You can call "rake -f /path/to/your/Rakefile", but it depends how the
> task is written.
>

Since the app will be owned by a separate user, I was thinking something 
like that could pull it off:

su - gitlab -s /bin/sh -c \"cd gitlab; /usr/bin/rake db:migrate 
RAILS_ENV=production\"

Or we could build a script that would take rake's commands as arguments.

>>
>> ## Generic
>>
>> - symlink logs to /var/log/gitlab/
>>
>> Not all logs' directory is configurable.
>
> They should be. Logging somewhere into /usr/share makes no sense.
>

I will talk about this with the devs.

>>
>> - pids: move to /var/run/gitlab/ (?)
>>
>> GitLab is practically running using unicorn and sidekiq. These two
>> create each its own pid file in app_dir/tmp/pids/ by default. Luckily
>> this is configurable via their configs or systemd services. Also
>> unicorn creates a gitlab.socket which uses to speak with the app. If
>> we use apache this isn't needed, but with nginx we can use it. I was
>> thinking it could go under /var/run/gitlab/ too.
>
> Sounds right.
>

Done.

>>
>> - how to support both databases. Is it feasible?
>>
>> GitLab supports mysql(mariadb for us) and postgres. How do we deal
>> with these cases inside a spec file? For now, I have added a comment
>> about the postgres config and made mariadb the default one.
>
> I would go with something like 'gitlab-mariadb' and 'gitlab-postgres',
> which would provide appropriate configurations, but some could argue,
> that configuring system by installation of package is wrong.
>

I was thinking that we just require both rubygem-mysql and rubygem-pg in 
spec. Then one could just change the /etc/gitlab/database.yml to his/her 
liking (although one of them will be the default).

>>
>> - ownership of directories
>>
>> In upstream installation guide, gitlab and gitlab-shell reside in the
>> same location that's why I decided to have them both under
>> /usr/share/gitlab/. And my question is, which package owns
>> /usr/share/gitlab/? Both?
>
> Both, if they are independent. Or you can create some -filesystem
> package, which would own the directory.
>

And by independent you mean they reside in separate dirs, right? If so 
then yes, they are independent.


-- 
FAS : axilleas
GPG : 0xABF99BE5
Blog: http://axilleas.me