targetd is up to version 0.2.2 from 0.1, just five weeks later.
- Added manpage
- Added API specification. API support for multiple storage pools.
- Deferred completion for long-running operations
- Volume copy
- Config file format changed to YAML
- Saves configuration across reboots
- Packaged, submitted for inclusion, and accepted for Fedora 18
If you are interested in contributing to targetd, there are two things you could help with. First, now that we have an API specification, please review it and give feedback or submit a bug.
Second, I’m having trouble implementing SSL support. I searched around and found some pages that talked about easily adding SSL support to Python’s HTTPServer, but after spending a day on it, it still didn’t work. I’m sure this is easy for someone, but that someone is not me 🙂 Anyone care to take a look?
I always configure apache to connect SSL to various mini HTTP servers. There can be only one app listening on 443, and it is annoying to have to connect to weird ports like 8443 for SSL.
In /etc/httpd/conf.d/ssl.conf add for instance:
ProxyPass /stormgr http://localhost:8080/stormgr
An rpm can depend on httpd and drop files in /etc/httpd/conf.d, but you need to insert lines in the virtual host defined in ssl.conf.
Hmm, I’m somewhat reluctant to go this route. Adding a huge dependency just because I can’t figure out how to do SSL seems excessive. 🙂
w.r.t. weird ports – yes targetd is on its own port. Just because it uses HTTP for auth, it’s not a “web” service, so it shouldn’t be on 80 or 443, I think.
Feedback on the API, I hope you don’t mind too much if I don’t
send to the list or bugzilla there as i don’t have account on
kernel.org nor github:
– size in byte: how can you be sure you won’t reach a limit
in the JSON encoding/decoding or Python level, especially for
a storage size the API need to cope with huge values. Maybe
adding a size unit would avoid problems in the future.
– All names must only contain characters in ‘[a-z][A-Z][0-9]_-‘:
why such a limitation ? I would assume JSON is UTF-8 ready
and while python is a disaster from an I18n perspective user
friendly names should be possible too. Or is that a limitation
of the underlying storage libraries ? if yes they probably ought
to be fixed 🙂
– async support still requires to poll for completion on the
client, I guess that with JSON over HTTP it’s unavoidable,
providing a precomputed expected time to completion for each
pending commands is something which could be added on the
server making the client work/report easier and possibly more
accurate as the client would have to ask multiple time to
start guessing a time.
hope this helps,
Daniel
Hi Daniel, thanks for the feedback.
– Everybody knows what size in bytes means. Once you start talking kibibytes versus kilobytes, it’s just an added point of confusion imho. The API needs to cope with huge values but for many cases like JSON, Python, other HLLs, this isn’t a problem. If an API consumer has issues with large values then they can convert when parsing, if needs be.
– Yes, very hesitant to allow arbitrary characters, maybe too hesitant, due to worries about underlying libraries. I’ll look to broaden this, after all we should be able to have a storage volume called 🙂
– Having async calls return an estimated time to completion is a great idea.
Thanks again for your feedback! I’ll update the API spec (and the code) and plan for a 0.3 release sometime soon.
Thanks for listening 🙂 sorry for the late reply
I would still be tempted to make the size default to KBytes
(i.e. 1024 bytes) as it sounds unlikely you need a finer level
of granularity for storage allocation, while limiting the risks
of integer value overflow in various layers. That would be a
simpler path than prefixes,
Daniel