On Nov 16 2016, Randy Rue <[email protected]> wrote:
> Should I be working on getting the pytest to complete without errors?

Probably. But so far you haven't actually reported any errors (just
skipped tests, which are fine), so I'm not sure why the question is
relevant.

> If I can't make it finish with a test backend configured, does that
> indicate problems that would stop me in real use or is it testing for
> things I don't necessarily need to worry about?

Depends on what you mean with "can't make it finish" and what error
message (if any) you get.

> Should I be concerned that pytest often fails at different points,

Yes, very much so. But to get help, you'd need to provide the full error
messages.


> And back to the actual config issues:
>
> My current .authinfo2:
> [swift-test]
> test-fs: swift://cluster.domain.com/container/test_prefix
> backend-login: bar
> backend-password: foo
>
> [cluster]
> storage-url: swift://cluster.domain.com/
> backend-login: bar
> backend-password: foo
>
> questions:
> * does the "[cluster]" line need to match anything or is it just a marker 
> for that entry?

That's just a label. From http://www.rath.org/s3ql-docs/authinfo.html:

| The authentication file consists of sections, led by a [section]
| header and followed by name: value entries. The section headers
| themselves are not used by S3QL but have to be unique within the file.

> Or when the app looks for authinfo, is it looking for the 
> storage-url and finding the credentials that match?

Yes. From the same link:

| storage-url: Specifies the storage url to which this section
|   applies. If a storage url starts with the value of this entry, the
|   section is considered applicable.

> * Can I also put a prefix in the "prod" storage-url? Your docs suggest so 
> but you don't show it in your example.

Yes. The docs are authoritative.

> ----------------------------------------------------------------------- 
> Captured stderr call 
> ------------------------------------------------------------------------
> WARNING: Maximum object sizes less than 1 MiB will degrade performance.
> ERROR: Uncaught top-level exception:
> Traceback (most recent call last):
>   File "/root/s3ql-2.21/bin/mount.s3ql", line 26, in <module>
>     s3ql.mount.main(sys.argv[1:])
>   File "/root/s3ql-2.21/src/s3ql/mount.py", line 204, in main
>     sd_notify('READY=1')
>   File "systemd/daemon.pyx", line 41, in systemd.daemon.notify 
> (systemd/daemon.c:41)
> TypeError: state must be an instance of Notigication

Hmm. Apparently systemd changed the calling convention in a backwards
incompatible way. I suspect this may be a bug in systemd, but I'll have
to check. As a workaround, replace

try:
    from systemd.daemon import notify as sd_notify
except ImportError:
    sd_notify = None

with just

sd_notify = None

at the beginning of src/s3ql/mount.py


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

-- 
You received this message because you are subscribed to the Google Groups 
"s3ql" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to