Hey folks!
I would like to try and do the Fedora Hubs deployment in our Openshift instance. The thing is, I have never deployed anything in Openshift, much less using our ansible playbooks.
Do you know of a documentation I could read up on to understand what our `openshift/project`, `openshift/secret-file` and `openshift/*` roles work, and how I could use them? I'm trying to read the playbooks for the apps we already have in openshift, but there's too much magic going on for me.
Any introduction document would help. I did try to read the F docs, but did not find anything in the SOPs or on the wiki.
Thanks!
Aurélien
On 02/15/2018 11:11 AM, Aurelien Bompard wrote:
Hey folks!
I would like to try and do the Fedora Hubs deployment in our Openshift instance. The thing is, I have never deployed anything in Openshift, much less using our ansible playbooks.
Do you know of a documentation I could read up on to understand what our `openshift/project`, `openshift/secret-file` and `openshift/*` roles work, and how I could use them? I'm trying to read the playbooks for the apps we already have in openshift, but there's too much magic going on for me.
Any introduction document would help. I did try to read the F docs, but did not find anything in the SOPs or on the wiki
Hey Aurelien,
I muddled my way through deploying an app on OpenShift recently and I'm not aware of any documentation on the process. I'm happy to take some time this afternoon to write down what I learned and make a PR to the infra-docs which you can then review and provide feedback on where the docs are lacking.
On 02/15/2018 08:11 AM, Aurelien Bompard wrote:
Hey folks!
I would like to try and do the Fedora Hubs deployment in our Openshift instance. The thing is, I have never deployed anything in Openshift, much less using our ansible playbooks.
Do you know of a documentation I could read up on to understand what our `openshift/project`, `openshift/secret-file` and `openshift/*` roles work, and how I could use them? I'm trying to read the playbooks for the apps we already have in openshift, but there's too much magic going on for me.
Any introduction document would help. I did try to read the F docs, but did not find anything in the SOPs or on the wiki.
Yeah, docs aren't too great currently.
The hope is that we will have our new cloud up soon and a dev openshift on it and we can let folks play with things there and get things mostly setup, then take those templates and tweak them a little to get a staging instance, etc.
Since deploying hubs is time sensitive, perhaps we should just initially do a staging on a normal vm and look at openshift down the road? Or do you think it would be a lot better to just do the openshift deploy now?
kevin
Since deploying hubs is time sensitive, perhaps we should just initially do a staging on a normal vm and look at openshift down the road?
I would prefer the normal vm route for now. I'll look into deploying on openshift when we decide to open Hubs to a wider range of teams. Thanks!
Aurélien
In the normal vm case, I have a couple questions:
- What will my URL be? https://hubs.stg.fedoraproject.org I guess?
- What's the Ipsilon instance I should register with? I used to register on iddev.fedorainfracloud.org but I guess that's no good for staging
- I need the following passwords set in the ansible private repo (proposed ansible variable name) : - for the hubs DB user (hubs_db_pass) - for the Flask session secret key (hubs_session_secret), this can be 30-50 chars. Do we still require two DB users, one with CRUD permissions and one with full permissions? I haven't seen it used outside the hyperkitty playbook. If so, I'll need a password for the admin user too, and I'm interested in the way you give the privileges on the tables to the non-admin user. For HyperKitty I use a rather clumsy handwritten script, but there may be a better way.
I think that's all. Thanks!
Aurélien
On Fri, Feb 16, 2018 at 04:12:15PM +0100, Aurelien Bompard wrote:
In the normal vm case, I have a couple questions:
- What will my URL be? https://hubs.stg.fedoraproject.org I guess?
yes
- What's the Ipsilon instance I should register with? I used to register
on iddev.fedorainfracloud.org but I guess that's no good for staging
I'll let Patrick answer, but I believe this is going to be id.stg.fp.o for which the registration is different (ie: not self-service)
- I need the following passwords set in the ansible private repo (proposed
ansible variable name) : Â - for the hubs DB user (hubs_db_pass) Â - for the Flask session secret key (hubs_session_secret), this can be 30-50 chars.
Both created
Do we still require two DB users, one with CRUD permissions and one with full permissions? I haven't seen it used outside the hyperkitty playbook. If so, I'll need a password for the admin user too, and I'm interested in the way you give the privileges on the tables to the non-admin user. For HyperKitty I use a rather clumsy handwritten script, but there may be a better way.
I know that I started using two users at one point but I ended up going back to a single one for most use-case as managing the permissions was clumsy indeed. Updating the database schema required adjusting the permissions on table, on indexes and forgetting one, getting a permission denied error and adjusting again :s Are you sure you want two users?
I can create an user (hubs_db_user) and a database (hubs_db) and give the user full access to the db if that works for you.
Pierre
- What's the Ipsilon instance I should register with? I used to
register
on iddev.fedorainfracloud.org but I guess that's no good for staging
I'll let Patrick answer, but I believe this is going to be id.stg.fp.o for which the registration is different (ie: not self-service)
OK, is there a way to register with it from the Ansible playbook?
Do we still require two DB users, one with CRUD permissions and one
with
full permissions? I haven't seen it used outside the hyperkitty
playbook.
If so, I'll need a password for the admin user too, and I'm
interested in
the way you give the privileges on the tables to the non-admin user.
For
HyperKitty I use a rather clumsy handwritten script, but there may be
a
better way.
I know that I started using two users at one point but I ended up going back to a single one for most use-case as managing the permissions was clumsy indeed. Updating the database schema required adjusting the permissions on table, on indexes and forgetting one, getting a permission denied error and adjusting again :s Are you sure you want two users?
I would rather not, but I'll abide to any security policy we have.
I can create an user (hubs_db_user) and a database (hubs_db) and give the
user full access to the db if that works for you.
That would be the easiest.
Aurélien
On 02/16/2018 07:37 AM, Pierre-Yves Chibon wrote:
On Fri, Feb 16, 2018 at 04:12:15PM +0100, Aurelien Bompard wrote:
In the normal vm case, I have a couple questions:
...snip...
Do we still require two DB users, one with CRUD permissions and one with full permissions? I haven't seen it used outside the hyperkitty playbook. If so, I'll need a password for the admin user too, and I'm interested in the way you give the privileges on the tables to the non-admin user. For HyperKitty I use a rather clumsy handwritten script, but there may be a better way.
I know that I started using two users at one point but I ended up going back to a single one for most use-case as managing the permissions was clumsy indeed. Updating the database schema required adjusting the permissions on table, on indexes and forgetting one, getting a permission denied error and adjusting again :s Are you sure you want two users?
I can create an user (hubs_db_user) and a database (hubs_db) and give the user full access to the db if that works for you.
Well, the idea was that we have a admin user that can change schema and drop things and the like and the 'normal' user that the app runs with that cannot do those things. That way if the application is compromised, they can only do things the normal user could do, not dropping entire tables or the like.
I agree it's hard to setup perms just right for this. This would definitely be something it would be nice to have detailed docs on and I don't think we have any currently.
kevin
Well, the idea was that we have a admin user that can change schema and drop things and the like and the 'normal' user that the app runs with that cannot do those things. That way if the application is compromised, they can only do things the normal user could do, not dropping entire tables or the like.
Well, they can still run "DELETE FROM table_name" on each table, which is pretty much like dropping the entire DB, since the schema doesn't have much value in itself.
Aurélien
infrastructure@lists.fedoraproject.org
-
Aurelien Bompard -
Aurelien Bompard -
Jeremy Cline -
Kevin Fenzi -
Pierre-Yves Chibon