Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

registry-next configuration enhancements #14

Closed
dmp42 opened this issue Jun 23, 2014 · 3 comments
Closed

registry-next configuration enhancements #14

dmp42 opened this issue Jun 23, 2014 · 3 comments
Assignees

Comments

@dmp42
Copy link
Contributor

dmp42 commented Jun 23, 2014

Hey there :-)

Have a look here:
docker-archive/docker-registry#444

How does this concern you?

  • myvar = cfg.get(key, DEFAULT) no longer exist - just replace these calls with myvar = cfg.key or DEFAULT for the same effect
  • values (be they default in config.yaml or sourced from ENV) are now typed properly (eg: they are YAML evaluated), so, you likely can drop the explicit casts you had to introduce earlier

This will likely get released with registry 0.8 by the end of the month.

These changes are breaking drivers, so I decided to bump the core version (2.0.0) to ease the transition (though nothing in core really changed): just up your dependency to the core and you should be done.

I encourage you to mention the change as well in your README, so that people looking for a 0.7 compatible release can pip install an old version of your driver (or you decide maintaining 0.7 compatibility is not worth it and drop it).

Hope that helps!

Cheers.

@noxiouz
Copy link
Owner

noxiouz commented Jul 4, 2014

Yeah! It would be great!

Seems in current stable (https://github.com/dotcloud/docker-registry/tree/0.7.3) list value in YAML is converted to dict by this code: https://github.com/dotcloud/docker-registry/blob/0.7.3/docker_registry/lib/config.py#L36. So getting rid of this code will solve this problem.

@dmp42
Copy link
Contributor Author

dmp42 commented Aug 13, 2014

That was fast :-)

@noxiouz
Copy link
Owner

noxiouz commented Aug 13, 2014

Yeaah! :-)

pyotr777 pushed a commit to pyotr777/docker-registry-driver-git that referenced this issue Feb 25, 2015
docker-registry has a local database which can be queried using a simple
REST API.  If you trash this database, it is supposed to be recreated
when you restart docker-registry.  This fix the recreation of the db which
happens thanks to results of the the list_directory function.  Previously
this was empty.

To test the problem and review the solution:

 1. assuming a working swift and docker registry with swift driver installed;
 2. push some images;
 3. stop docker-registry;
 4. check sqlalchemy_index_database in docker registry conf and "rm" the database (by default a sqlite file);
 5. restart docker-registry;

With the old code the database will be empty.  With the new one the db
will be filled with the already pushed images.  The main problem come
from the facts that:

    $ curl -i -X GET -H "X-Auth-Token: AUTH_token" 'http://localhost:8080/v1/AUTH_test/docker?prefix=lvl_1/&delimiter=/&format=json'

    [{"hash": "a83a7dcf68a3dd1d83584abd8e230829", "last_modified": "2014-09-17T15:26:25.585390", "bytes": 29, "name": "lvl_1/file_2", "content_type": "application/octet-stream"}, {"subdir": "lvl_1/lvl_2/"}]

and

    $ curl -i -X GET -H "X-Auth-Token: AUTH_token" 'http://localhost:8080/v1/AUTH_test/docker?path=lvl_1/&format=json'

    [{"hash": "a83a7dcf68a3dd1d83584abd8e230829", "last_modified": "2014-09-17T15:26:25.585390", "bytes": 29, "name": "lvl_1/file_2", "content_type": "application/octet-stream"}]

do not return the same thing.  The main difference being that the
subdirectories are not return when using the "path" syntax.

I tested with swift 1.8.0 and check that the Pseudo-hierarchical folders
and directories behaviour was the same on swift 2.2.0.

This would close noxiouz#14 and noxiouz#15.  The "fill it if not there" mechanism is
described in this issue  docker-archive/docker-registry#516
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants