Re: December status update for Fedora Infrastructure Apprentices

2015-12-03 Thread Ladislav Novák 
Hi,

0. ladisone
1. I went trough Ansible roles, playbooks and login to machine I have in
plan
2. In general me interests everythig what i can not :D
3. Yes. On one task yust I  working...
4. Yes
5. No.
6. Probably finding tickets in your interest area
7. Yes, Yes it is interesting
8. No.
9. No. Yes.

L.

Dne 3.12.2015 v 21:03 Kevin Fenzi napsal(a):
> Greetings.
> 
> You are getting this email because you are in the 'fi-apprentice' group
> in the fedora account system (or are reading this on the
> infrastructure list). 
> 
> Feel free to reply just directly to me, or cc the infrastructure list
> for everyone to see and comment on. 
> 
> https://fedoraproject.org/wiki/Infrastructure_Apprentice
> 
> At the first of every month(or so), I am going to be sending out an
> email like this one. I would like feedback on how things are going for
> you.
> 
> I'd like to ask for everyone to send me a quick reply with the
> following data or anything related you can think of that might help us
> make the apprentice program more useful. 
> 
> 0. Whats your fedora account system login?
> 
> 1. Have you logged in and used your fi-apprentice membership to look at
> our machines/setup in the last month? Do you plan to?
> 
> 2. Has it helped you decide any area you wish to focus on or contribute
> to more?
> 
> 3. Have you looked at or been able to work on any of the fi-apprentice
> 'easyfix' tickets?
> https://fedorahosted.org/fedora-infrastructure/report/14
> 
> 4. Do you still wish to be a member of the group? If not (for whatever
> reason) could you provide any hints to help others down the road?
> 
> 5. Is there any help or communication or ideas you have that would help
> you do any of the above?
> 
> 6. What do you find to be the hardest part of getting involved?
> Finding things to work on? Getting attention from others to help you?
> Finding tickets in your interest area? 
> 
> 7. Have you been able to make any weekly irc meetings? Do you find them
> helpful or interesting? 
> 
> 8. Have you logged into our Gobby instance and read/seen/added to our
> meeting agenda? https://fedoraproject.org/wiki/Gobby
> 
> 9. Did you know that we are going to be doing a 'technical debt
> cleanup' week on 2016-01-06 to 2016-01-09? See:
> https://fedoraproject.org/wiki/Infrastructure/Debt
> and come join us.
> 
> Any other general feedback is also quite welcome, including
> improvements to this email, the wiki page, etc.
> 
> Any folks I do not hear from in the next week will be removed from the
> group. (Note that it's easy to be readded when you have time or
> whatever and it's nothing at all personal, we just want to keep the
> group up to date with active folks).
> 
> Thanks, and looking forward to your feedback!
> 
> kevin
> 
> 
> 
> ___
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
> 
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

[PATCH] Add defaults var for fas_client

2015-12-03 Thread Nicolas Chauvet 
v3: avoid to use env == "staging"
v2: fix inverted fas_staging_url/fas_url
---
 inventory/group_vars/all   |3 +++
 inventory/group_vars/staging   |2 ++
 roles/fas_client/defaults/main.yml |7 +++
 roles/fas_client/templates/fas.conf.j2 |   10 +++---
 4 files changed, 15 insertions(+), 7 deletions(-)
 create mode 100644 roles/fas_client/defaults/main.yml

diff --git a/inventory/group_vars/all b/inventory/group_vars/all
index feff99f..6855f3f 100644
--- a/inventory/group_vars/all
+++ b/inventory/group_vars/all
@@ -49,6 +49,9 @@ virt_install_command: virt-install -n {{ inventory_hostname 
}} -r {{ mem_size }}
 # the staging group and is used in the proxies.yml playbook.
 wildcard_cert_name: wildcard-2014.fedoraproject.org
 
+# Default fas url
+fas_url: https://admin.fedoraproject.org/accounts/
+
 # By default, nodes get no fedmsg certs.  They need to declare them explicitly.
 fedmsg_certs: []
 
diff --git a/inventory/group_vars/staging b/inventory/group_vars/staging
index f083e2b..76e4790 100644
--- a/inventory/group_vars/staging
+++ b/inventory/group_vars/staging
@@ -10,6 +10,8 @@ wildcard_cert_name: wildcard-2014.stg.fedoraproject.org
 # This only does anything if the host is not RHEL6
 collectd_graphite: True
 
+fas_url: https://admin.stg.fedoraproject.org/accounts/
+
 fedmsg_prefix: org.fedoraproject
 fedmsg_env: stg
 
diff --git a/roles/fas_client/defaults/main.yml 
b/roles/fas_client/defaults/main.yml
new file mode 100644
index 000..345e1e4
--- /dev/null
+++ b/roles/fas_client/defaults/main.yml
@@ -0,0 +1,7 @@
+---
+# defaults file for fas_client
+#
+
+fas_url: https://admin.fedoraproject.org/accounts/
+fas_home: /home/fedora
+fas_home_backup_dir: "{{ fas_home }}.bak"
diff --git a/roles/fas_client/templates/fas.conf.j2 
b/roles/fas_client/templates/fas.conf.j2
index a27f0ef..3e6f8f3 100644
--- a/roles/fas_client/templates/fas.conf.j2
+++ b/roles/fas_client/templates/fas.conf.j2
@@ -1,10 +1,6 @@
 [global]
 ; url - Location to fas server
-{% if env == "staging" %}
-url = https://admin.stg.fedoraproject.org/accounts/
-{% else %}
-url = https://admin.fedoraproject.org/accounts/
-{% endif %}
+url = {{  fas_url  }}
 
 ; temp - Location to generate files while user creation process is happening
 temp = /var/db
@@ -59,11 +55,11 @@ aliases_template = /etc/aliases.template
 shell = /bin/bash
 
 ; home - the location for fas user home dirs
-home = /home/fedora
+home = {{ fas_home  }}
 
 ; home_backup_dir - Location home dirs should get moved to when a user is
 ; deleted this location should be tmpwatched
-home_backup_dir = /home/fedora.bak
+home_backup_dir = {{ fas_home_backup_dir  }}
 
 ; ssh_restricted_app - This is the path to the restricted shell script.  It
 ; will not work automatically for most people though through alterations it
-- 
1.7.2.1
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: [PATCH] Add defaults var for fas_client

2015-12-03 Thread Nicolas Chauvet 
2015-12-03 10:31 GMT+01:00 SmootherFrOgZ :

> On Thu, Dec 3, 2015 at 10:09 AM Nicolas Chauvet  wrote:
>
>> ---
>>  roles/fas_client/defaults/main.yml |8 
>>  roles/fas_client/templates/fas.conf.j2 |8 
>>  2 files changed, 12 insertions(+), 4 deletions(-)
>>  create mode 100644 roles/fas_client/defaults/main.yml
>>
>> diff --git a/roles/fas_client/defaults/main.yml
>> b/roles/fas_client/defaults/main.yml
>> new file mode 100644
>> index 000..f0983d2
>> --- /dev/null
>> +++ b/roles/fas_client/defaults/main.yml
>> @@ -0,0 +1,8 @@
>> +---
>> +# defaults file for fas_client
>> +#
>> +
>> +fas_url: https://admin.fedoraproject.org/accounts/
>> +fas_staging_url: https://admin.stg.fedoraproject.org/accounts/
>> +fas_home: /home/fedora
>> +fas_home_backup_dir: "{{ fas_home }}.bak"
>> diff --git a/roles/fas_client/templates/fas.conf.j2
>> b/roles/fas_client/templates/fas.conf.j2
>> index a27f0ef..995c8e1 100644
>> --- a/roles/fas_client/templates/fas.conf.j2
>> +++ b/roles/fas_client/templates/fas.conf.j2
>> @@ -1,9 +1,9 @@
>>  [global]
>>  ; url - Location to fas server
>>  {% if env == "staging" %}
>> -url = https://admin.stg.fedoraproject.org/accounts/
>> +url = {{  fas_url  }}
>>  {% else %}
>> -url = https://admin.fedoraproject.org/accounts/
>> +url = {{  fas_staging_url  }}
>>  {% endif %}
>>
>> The role should be as generic as possible and not try to deal with system
> environment if there's no clear/specific behavior tied to this defined
> environment.
> Thus, here we should just have:
> ```url = {{ fas_url }}```
>
> and deal with the env in the playbook, groups_host or hosts.
>
Fixing to follow your suggestion with v3.


>
>>  ; temp - Location to generate files while user creation process is
>> happening
>> @@ -59,11 +59,11 @@ aliases_template = /etc/aliases.template
>>  shell = /bin/bash
>>
>>  ; home - the location for fas user home dirs
>> -home = /home/fedora
>> +home = {{ fas_home  }}
>>
>>
> How about: {{ fas_home_dir }} - which is more explicit?
>
There is various way to forge arbitrary variable names. I expect that using
fas_home constructed after the home variable of the fas.conf file would
make it less arbitrary.


>
>>  ; home_backup_dir - Location home dirs should get moved to when a user is
>>  ; deleted this location should be tmpwatched
>> -home_backup_dir = /home/fedora.bak
>> +home_backup_dir = {{ fas_home_backup_dir  }}
>>
>
> +1
>
> --
>
> Xavier
>
> ___
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
>
> http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
>
>


-- 
-

Nicolas (kwizart)
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Meeting Agenda Item: Introduction Matthew McCleary

2015-12-03 Thread Matthew S. McCleary 
Greetings, Infrastructure folks.

I'm interested in contributing time to the effort. Family and work are both
okay with the idea.

My IRC nick is flainn.

I'm a (well, really "the") Linux sysadmin for the US Bureau of Indian
Affairs (contractor, not a Fed), doing almost exclusively CentOS work, but
running Fedora on my own systems. I'm a fairly strong Linux admin, and not
much of a programmer. I do a lot of patch management work (mostly with
Spacewalk), monitoring (Zabbix), provisioning new VMs, and other stuff as
needed here at BIA.

I'd be interested in storage work, patching, virtualization, or really
wherever I can help out.

Looking forward to helping.

Thanks,
Matthew

-- 
Matthew McCleary KF5VUD
voice 505.886.1732
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: December status update for Fedora Infrastructure Apprentices

2015-12-03 Thread David Shier 

Kevin,

Comments are in line.

On 12/03/2015 03:03 PM, Kevin Fenzi wrote:

Greetings.

You are getting this email because you are in the 'fi-apprentice' group
in the fedora account system (or are reading this on the
infrastructure list).

Feel free to reply just directly to me, or cc the infrastructure list
for everyone to see and comment on.

https://fedoraproject.org/wiki/Infrastructure_Apprentice

At the first of every month(or so), I am going to be sending out an
email like this one. I would like feedback on how things are going for
you.

I'd like to ask for everyone to send me a quick reply with the
following data or anything related you can think of that might help us
make the apprentice program more useful.

0. Whats your fedora account system login?

odin2016


1. Have you logged in and used your fi-apprentice membership to look at
our machines/setup in the last month? Do you plan to?

Yes

2. Has it helped you decide any area you wish to focus on or contribute
to more?

I think so.

3. Have you looked at or been able to work on any of the fi-apprentice
'easyfix' tickets?
https://fedorahosted.org/fedora-infrastructure/report/14
I've looked at the easyfix tickets, but it appears they are mostly 
waiting on internal tickets, or other decisions. Instead I added a 
requirement in the meetbot plug-in to require a meeting topic to 
#startmeeting per a ticket from Remy and have been working on csi 
group_vars.



4. Do you still wish to be a member of the group? If not (for whatever
reason) could you provide any hints to help others down the road?

Yes.


5. Is there any help or communication or ideas you have that would help
you do any of the above?
I do not believe so, but I am also able to make the weekly meetings 
regularly, so I may be better communicated to that some.



6. What do you find to be the hardest part of getting involved?
Finding things to work on? Getting attention from others to help you?
Finding tickets in your interest area?
Probably finding things that I can do as a lot of the tickets at this 
point require a little but more than I have as most are in the bigger 
queue and a lot of the things I have found in the larger queue are taken 
care of at this time. Out side of that the remaining is just a learning 
curve thing, which will sort itself out.




7. Have you been able to make any weekly irc meetings? Do you find them
helpful or interesting?

Yes, I have, and I find them helpful, insightful and interesting.



8. Have you logged into our Gobby instance and read/seen/added to our
meeting agenda? https://fedoraproject.org/wiki/Gobby


Yes.


9. Did you know that we are going to be doing a 'technical debt
cleanup' week on 2016-01-06 to 2016-01-09? See:
https://fedoraproject.org/wiki/Infrastructure/Debt
and come join us.
I do. I am looking forward to these starting as it will help me in the 
learning curve area and I should be able to be more useful as the people 
I need to do things will be right there at the time I need them and 
likely will not need to wait on them to check their email for something 
I've sent to the list as much. :)



Any other general feedback is also quite welcome, including
improvements to this email, the wiki page, etc.


No additional feedback at this time. If I come across something I will 
mention it on the list or in #fedora-admin.

Any folks I do not hear from in the next week will be removed from the
group. (Note that it's easy to be readded when you have time or
whatever and it's nothing at all personal, we just want to keep the
group up to date with active folks).

Thanks, and looking forward to your feedback!

kevin


___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org



Thanks,

Dave Shier / Odin

___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

December status update for Fedora Infrastructure Apprentices

2015-12-03 Thread Kevin Fenzi 
Greetings.

You are getting this email because you are in the 'fi-apprentice' group
in the fedora account system (or are reading this on the
infrastructure list). 

Feel free to reply just directly to me, or cc the infrastructure list
for everyone to see and comment on. 

https://fedoraproject.org/wiki/Infrastructure_Apprentice

At the first of every month(or so), I am going to be sending out an
email like this one. I would like feedback on how things are going for
you.

I'd like to ask for everyone to send me a quick reply with the
following data or anything related you can think of that might help us
make the apprentice program more useful. 

0. Whats your fedora account system login?

1. Have you logged in and used your fi-apprentice membership to look at
our machines/setup in the last month? Do you plan to?

2. Has it helped you decide any area you wish to focus on or contribute
to more?

3. Have you looked at or been able to work on any of the fi-apprentice
'easyfix' tickets?
https://fedorahosted.org/fedora-infrastructure/report/14

4. Do you still wish to be a member of the group? If not (for whatever
reason) could you provide any hints to help others down the road?

5. Is there any help or communication or ideas you have that would help
you do any of the above?

6. What do you find to be the hardest part of getting involved?
Finding things to work on? Getting attention from others to help you?
Finding tickets in your interest area? 

7. Have you been able to make any weekly irc meetings? Do you find them
helpful or interesting? 

8. Have you logged into our Gobby instance and read/seen/added to our
meeting agenda? https://fedoraproject.org/wiki/Gobby

9. Did you know that we are going to be doing a 'technical debt
cleanup' week on 2016-01-06 to 2016-01-09? See:
https://fedoraproject.org/wiki/Infrastructure/Debt
and come join us.

Any other general feedback is also quite welcome, including
improvements to this email, the wiki page, etc.

Any folks I do not hear from in the next week will be removed from the
group. (Note that it's easy to be readded when you have time or
whatever and it's nothing at all personal, we just want to keep the
group up to date with active folks).

Thanks, and looking forward to your feedback!

kevin


pgp0qRseSc1q8.pgp
Description: OpenPGP digital signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

[release] bodhi: 2.1.4

2015-12-03 Thread Luke Macken 
Hi folks,

I pushed a new version of Bodhi to production yesterday. This contains a few
small bug fixes, additional {submitted,modified,approved,pushed}_before query
parameters, as well as a masher enhancement to fix a tagging bug that can
happen when 2 builds for the same package get pushed at the same time.

Happy hacking,

luke


2.1.4
-

Pull Requests

- (@AdamWill)   #716, query: add _before params matching the _since params
  https://github.com/fedora-infra/bodhi/pull/716
- (@ralphbean)  #719, client - handle case where "total" not in the 
response.
  https://github.com/fedora-infra/bodhi/pull/719
- (@lmacken)#720, masher: Iterate over the status results generator
  https://github.com/fedora-infra/bodhi/pull/720
- (@lmacken)#721, models: Don't reset the `pushed` and `date_pushed` 
flags upon request.
  https://github.com/fedora-infra/bodhi/pull/721
- (@lmacken)#722, Tag multiple builds for the same package 
synchronously.
  https://github.com/fedora-infra/bodhi/pull/722

Commits

- bc322093b query: add _before params matching the _since params
  https://github.com/fedora-infra/bodhi/commit/bc322093b
- bc8a4220a No longer need the old createrepo system lib.
  https://github.com/fedora-infra/bodhi/commit/bc8a4220a
- 0ffa0de05 client - handle case where "total" not in the response.
  https://github.com/fedora-infra/bodhi/commit/0ffa0de05
- 64d71354d masher: Iterate over the status results generator
  https://github.com/fedora-infra/bodhi/commit/64d71354d
- 9d8d79afc models: Don't reset the `pushed` and `date_pushed` flags upon 
request.
  https://github.com/fedora-infra/bodhi/commit/9d8d79afc
- 9e6e825a3 models: Don't reset the `pushed` and `date_pushed` flags upon 
request.
  https://github.com/fedora-infra/bodhi/commit/9e6e825a3
- b65514bde Merge branch 'develop' of github.com:fedora-infra/bodhi into develop
  https://github.com/fedora-infra/bodhi/commit/b65514bde
- 9b6996981 masher: Tag multiple builds for the same package synchronously.
  https://github.com/fedora-infra/bodhi/commit/9b6996981
- 21a49ef32 bootstrap: Try linking in the system PIL, which might fix our 
Jenkins builds?
  https://github.com/fedora-infra/bodhi/commit/21a49ef32


signature.asc
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: State of python3 in our infrastructure

2015-12-03 Thread Toshio Kuratomi 
On Dec 3, 2015 1:44 AM, "Miroslav Suchý"  wrote:
>
> Dne 2.12.2015 v 12:14 Pierre-Yves Chibon napsal(a):
> > So what do you folks think?
>
> Copr is already migrated to python3 (in upstream) and I'm getting ready
to use python3 on production servers soon.
> But Copr (frontend and backend) is using Fedora it is no big deal anyway.
> Well we will migrate frontend to python3, backend have to be postponed
since it is using ansible modules, which are
> python2 only.

That shouldn't matter.  You just need to have both python 2 and python 3
installed on the box.  Ansible doesn't run under mod_wsgi so there is no
conflict at runtime.

Unless you mean you have been using the ansible python module (rather than
the python scripts ansible runs on the remote machines)?  If so, two
things.. (1) warning: 2.0 will be out soon and the python module api will
be very different.  We don't really support a stable api upstream in that
sense just the apis for writing plugins and modules (and some plugin
apis have changed in 2.0 as well.  Ansible module api should be almost the
same though.) (2) there's been some work on getting the controller code to
be python 3 compatible but we're a ways off from that (ansible modules much
further than that even).  There's some issues about maintaining python 2.4
compat in the controller code we still know needs porting(because that code
also runs on the remote hosts). Help welcomed upstream although we're
currently in the talking phase about that code (I'm planning some
improvements for 2.1 that will make this easier to manage).

> Anything new we recently wrote (e.g. keygen) is python3 only. And if
possible run on RHEL7 (again case of keygen).
>
Sounds like you jumped the gun here since this discussion will lead to
infra deciding if they want mixed python 3 and python 2 web application
environments :-)  but eventually this is inevitable.  If not or own
upstream, eventually third party upstream will start to support python 3
only. (As is the current case for maggit).

> Conclusion for me - use common sense. Write code python2/3 compatible.
Migrate if possible. If libraries are python2
> only (openstack, ansible) notify they owners and wait until there is
python3 version or if those authors refuse, choose
> other alternative.

Here we're talking about the case of upstream that only support python 3
and whether we want to take on the maintenance burden (separate systems for
running python2 and python 3 mod_wsgi apps, packaging work) that implies.

-Toshio

-Toshio
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Request for resources: Bugyou

2015-12-03 Thread Sayan Chowdhury 
Hi,

I have filed a RFR[0] for Bugyou

Bugyou files issues for failed tests from autocloud. Bugyou is part of
Fedora Project. It listens to autocloud messages from fedmsg and files
bug for images which have failed the tests. Bugyou keeps updating the
status of the images in the bug and closes the issue once the tests
are successful. The documentation can seen here[1]

[0] https://fedorahosted.org/fedora-infrastructure/ticket/5012
[1] http://bugyou.readthedocs.org/en/latest/
-- 
Sayan Chowdhury
sayanchowdhury.dgplug.org | sayan.chowdhury2...@gmail.com
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: State of python3 in our infrastructure

2015-12-03 Thread Miroslav Suchý 
Dne 2.12.2015 v 12:14 Pierre-Yves Chibon napsal(a):
> So what do you folks think?

Copr is already migrated to python3 (in upstream) and I'm getting ready to use 
python3 on production servers soon.
But Copr (frontend and backend) is using Fedora it is no big deal anyway.
Well we will migrate frontend to python3, backend have to be postponed since it 
is using ansible modules, which are
python2 only.
Anything new we recently wrote (e.g. keygen) is python3 only. And if possible 
run on RHEL7 (again case of keygen).

Conclusion for me - use common sense. Write code python2/3 compatible. Migrate 
if possible. If libraries are python2
only (openstack, ansible) notify they owners and wait until there is python3 
version or if those authors refuse, choose
other alternative.

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: [PATCH] Add defaults var for fas_client

2015-12-03 Thread SmootherFrOgZ 
On Thu, Dec 3, 2015 at 10:09 AM Nicolas Chauvet  wrote:

> ---
>  roles/fas_client/defaults/main.yml |8 
>  roles/fas_client/templates/fas.conf.j2 |8 
>  2 files changed, 12 insertions(+), 4 deletions(-)
>  create mode 100644 roles/fas_client/defaults/main.yml
>
> diff --git a/roles/fas_client/defaults/main.yml
> b/roles/fas_client/defaults/main.yml
> new file mode 100644
> index 000..f0983d2
> --- /dev/null
> +++ b/roles/fas_client/defaults/main.yml
> @@ -0,0 +1,8 @@
> +---
> +# defaults file for fas_client
> +#
> +
> +fas_url: https://admin.fedoraproject.org/accounts/
> +fas_staging_url: https://admin.stg.fedoraproject.org/accounts/
> +fas_home: /home/fedora
> +fas_home_backup_dir: "{{ fas_home }}.bak"
> diff --git a/roles/fas_client/templates/fas.conf.j2
> b/roles/fas_client/templates/fas.conf.j2
> index a27f0ef..995c8e1 100644
> --- a/roles/fas_client/templates/fas.conf.j2
> +++ b/roles/fas_client/templates/fas.conf.j2
> @@ -1,9 +1,9 @@
>  [global]
>  ; url - Location to fas server
>  {% if env == "staging" %}
> -url = https://admin.stg.fedoraproject.org/accounts/
> +url = {{  fas_url  }}
>  {% else %}
> -url = https://admin.fedoraproject.org/accounts/
> +url = {{  fas_staging_url  }}
>  {% endif %}
>
> The role should be as generic as possible and not try to deal with system
environment if there's no clear/specific behavior tied to this defined
environment.
Thus, here we should just have:
```url = {{ fas_url }}```

and deal with the env in the playbook, groups_host or hosts.



>  ; temp - Location to generate files while user creation process is
> happening
> @@ -59,11 +59,11 @@ aliases_template = /etc/aliases.template
>  shell = /bin/bash
>
>  ; home - the location for fas user home dirs
> -home = /home/fedora
> +home = {{ fas_home  }}
>
>
How about: {{ fas_home_dir }} - which is more explicit?


>  ; home_backup_dir - Location home dirs should get moved to when a user is
>  ; deleted this location should be tmpwatched
> -home_backup_dir = /home/fedora.bak
> +home_backup_dir = {{ fas_home_backup_dir  }}
>

+1

-- 

Xavier
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

[PATCH] Add defaults var for fas_client

2015-12-03 Thread Nicolas Chauvet 
v2: fix inverted fas_staging_url/fas_url
---
 roles/fas_client/defaults/main.yml |8 
 roles/fas_client/templates/fas.conf.j2 |8 
 2 files changed, 12 insertions(+), 4 deletions(-)
 create mode 100644 roles/fas_client/defaults/main.yml

diff --git a/roles/fas_client/defaults/main.yml 
b/roles/fas_client/defaults/main.yml
new file mode 100644
index 000..f0983d2
--- /dev/null
+++ b/roles/fas_client/defaults/main.yml
@@ -0,0 +1,8 @@
+---
+# defaults file for fas_client
+#
+
+fas_url: https://admin.fedoraproject.org/accounts/
+fas_staging_url: https://admin.stg.fedoraproject.org/accounts/
+fas_home: /home/fedora
+fas_home_backup_dir: "{{ fas_home }}.bak"
diff --git a/roles/fas_client/templates/fas.conf.j2 
b/roles/fas_client/templates/fas.conf.j2
index a27f0ef..2824339 100644
--- a/roles/fas_client/templates/fas.conf.j2
+++ b/roles/fas_client/templates/fas.conf.j2
@@ -1,9 +1,9 @@
 [global]
 ; url - Location to fas server
 {% if env == "staging" %}
-url = https://admin.stg.fedoraproject.org/accounts/
+url = {{  fas_staging_url  }}
 {% else %}
-url = https://admin.fedoraproject.org/accounts/
+url = {{  fas_url  }}
 {% endif %}
 
 ; temp - Location to generate files while user creation process is happening
@@ -59,11 +59,11 @@ aliases_template = /etc/aliases.template
 shell = /bin/bash
 
 ; home - the location for fas user home dirs
-home = /home/fedora
+home = {{ fas_home  }}
 
 ; home_backup_dir - Location home dirs should get moved to when a user is
 ; deleted this location should be tmpwatched
-home_backup_dir = /home/fedora.bak
+home_backup_dir = {{ fas_home_backup_dir  }}
 
 ; ssh_restricted_app - This is the path to the restricted shell script.  It
 ; will not work automatically for most people though through alterations it
-- 
1.7.2.1
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

[PATCH] Add defaults var for fas_client

2015-12-03 Thread Nicolas Chauvet 
---
 roles/fas_client/defaults/main.yml |8 
 roles/fas_client/templates/fas.conf.j2 |8 
 2 files changed, 12 insertions(+), 4 deletions(-)
 create mode 100644 roles/fas_client/defaults/main.yml

diff --git a/roles/fas_client/defaults/main.yml 
b/roles/fas_client/defaults/main.yml
new file mode 100644
index 000..f0983d2
--- /dev/null
+++ b/roles/fas_client/defaults/main.yml
@@ -0,0 +1,8 @@
+---
+# defaults file for fas_client
+#
+
+fas_url: https://admin.fedoraproject.org/accounts/
+fas_staging_url: https://admin.stg.fedoraproject.org/accounts/
+fas_home: /home/fedora
+fas_home_backup_dir: "{{ fas_home }}.bak"
diff --git a/roles/fas_client/templates/fas.conf.j2 
b/roles/fas_client/templates/fas.conf.j2
index a27f0ef..995c8e1 100644
--- a/roles/fas_client/templates/fas.conf.j2
+++ b/roles/fas_client/templates/fas.conf.j2
@@ -1,9 +1,9 @@
 [global]
 ; url - Location to fas server
 {% if env == "staging" %}
-url = https://admin.stg.fedoraproject.org/accounts/
+url = {{  fas_url  }}
 {% else %}
-url = https://admin.fedoraproject.org/accounts/
+url = {{  fas_staging_url  }}
 {% endif %}
 
 ; temp - Location to generate files while user creation process is happening
@@ -59,11 +59,11 @@ aliases_template = /etc/aliases.template
 shell = /bin/bash
 
 ; home - the location for fas user home dirs
-home = /home/fedora
+home = {{ fas_home  }}
 
 ; home_backup_dir - Location home dirs should get moved to when a user is
 ; deleted this location should be tmpwatched
-home_backup_dir = /home/fedora.bak
+home_backup_dir = {{ fas_home_backup_dir  }}
 
 ; ssh_restricted_app - This is the path to the restricted shell script.  It
 ; will not work automatically for most people though through alterations it
-- 
1.7.2.1
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: State of python3 in our infrastructure

2015-12-03 Thread Pierre-Yves Chibon 
On Wed, Dec 02, 2015 at 01:24:45PM -0700, Luke Macken wrote:
> On Wed, Dec 02, 2015 at 12:14:42PM +0100, Pierre-Yves Chibon wrote:
> > Good morning everyone,
> > 
> > I would like to start gathering our thoughts about python3 in our apps.
> > 
> > To my knowledge, we currently have two applications that are python3 (only):
> > - Mailman3 core (as in hyperkitty is still py2)
> > - mdapi
> > 
> > Both are *not* running via apache/mod_wsgi. MM3 runs on RHEL7 while mdapi 
> > runs
> > on a Fedora node for the moment.
> 
> What are they using instead of apache/mod_wsgi?

In both cases (Aurélien correct me if I'm wrong), they are just exposing an API,
REST for MM3, JSON for mdapi.
I don't know for MM3, but mdapi is async, which cannot be handled by apache
afaik, we would need nginx or something if we wanted some sort of proxy.
So at the moment mdapi runs with the web-server provided by aiohttp and is
started via `systemctl start mdapi`.

What I wanted to highlight with this section is that despite having already 2
apps running python3, neither are "classic" nor following the traditional scheme
of web-app/apache/mod_wsgi, which means when we deploy our first py3 apps under
this scheme, we'll need to figure these things out, we can't rely on existing
implementation.


Pierre


pgpkiwC84dGRp.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: Badges for translations contribution

2015-12-03 Thread Pierre-Yves Chibon 
On Thu, Dec 03, 2015 at 04:36:32AM -, Ralph Bean wrote:
> > Deployment of 3.8 is in progress now. Hopefully before Christmas.
> 
> Awesome!
>  
> > - zanata currently only sends events when translations for a document 
> > 
> > Agree. Let me follow up for this.
> > 
> > - The message payload only indicates which document reached 100%.  We
> > 
> > 
> > I think we should have separate event for documents translation reaching a
> > milestone and contribution badges.
> 
> Sounds good!
> 
> > For contribution badges, perhaps we can send out webhook event after each
> > translation being saved (not sure if the zanata2fedmsg bridge can handle
> > the load),
> > or queue it up in Zanata and send out every X minutes for that user. Will
> > need you input on this.
> 
> I feel sure we can handle the load of receiving them as soon as they're 
> available.  Still, it would make sense for zanata to queue them on the side 
> and send them from a separate asynchronous process.  If the main 
> zanata-server web process sends the webhook POSTs, an attacker could maybe 
> create a receiving webapp that accepts part of the POST but then misbehaves 
> and intentionally stalls (which could cause zanata-server to stall out?).  
> Sending asynchronously but rapidly sounds good here.

Or simply times-out. I had the problem with pagure where the app was waiting for
the request to end (ranging from very quickly to waiting for it to time out)
before returning. Needless to say that if the web-hook server was to time-out,
pagure was going for it as well.
So async++ :)

Pierre
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org