COmanage Developers List

[Scott Koranda <>]

Hi,

> I guess what I was trying to ask on today's dev call was, is it worth
> it to use Docker for testing ?

I think so, yes.

> I've found comanage-registry-docker helpful, and as a next step in
> working on an issue I was going to create a Docker image from which to
> start my reproduce + trial-and-error troubleshooting cycle. 

How specifically will that image differ from the current images that you
can create using the Docker files in the GitHub repository, or the
images that are in DockerHub at

https://hub.docker.com/u/sphericalcowgroup/dashboard/

?

Put another way, how will your "starting point" differ specifically from
what you get if you spin up one of the containers now?

> And I was
> going to create the Docker image to save me time instead of wiping the
> database and initializing the app, etc. 

You can use docker commit to essentially snapshot a running container
into a distributable image.

But both the MariaDB and PostgreSQL official images (the COmanage
PostgreSQL image is a thin wrapper around the PostgreSQL official image)
support auto-loading of SQL at first boot if it is put inside the image
in a known place. That would probably lead to a more manageable process
since you could put the SQL under version control.

But there might be issues with that approach too (see more below).

> My next thought was that I
> could see myself creating a number of these images used for tests, and
> it might be a good idea to store them somewhere and use them as part
> of CI.

I think that makes sense.

> Does it make any sense to create Docker images of pre-initialized
> COmanage instances ? I think you mentioned pushing images to docker
> Hub for the code, but would we do that for the database ? like a demo
> ?

Maybe.

Note that this is NOT how the containers currently work--the COmanage
Registry container has an entry point script that checks for the current
status of the database and if necessary runs "./Console/cake setup" and
the like.

In other words, the container only does what COmanage Registry
officially supports. I have been careful about that.

If you are going to do something differently to bootstrap the state
of COmanage Registry you will want to think about how the mechanism you
create does or does not fit into the vision for how COmanage Registry
will evolve.

For example, the CILogon2 project has some interest in funding a way to
"script" a batch of actions when a new CO is created. If that comes to
pass it might be a better way of putting the database into some known
state rather than just loading up SQL, especially since the project is
free to add/delete/change SQL tables at any point.

> I know on the call we said that we didn't want to spend effort
> building stuff which eventually would be thrown away, like during a
> framework upgrade. But it seems Docker images of COmanage would be a
> level above the framework, and would make testing such an upgrade
> possible.

I think using the COmanage Registry Docker images to facilitate testing
is a good idea and worthwhile investing in. I am just not sure how best
to do it. We would have to invest some time thinking about it in detail.

Thanks,

Scott