<div dir="ltr">Humm this doesn't have to be complicated, for a start.<div><br></div><div>><span style="font-size:12.8000001907349px">- Figuring out the http method the server expects (POST/PUT)</span></div>Yeah, I agree. There"s no definitive answer to this but I think PUT makes sense here. I googled 'post vs put' and I found that the "idempotent" and "who is in charge of the actual resource location choice" (the client vs the server), favors PUT. <div><br></div><div>><span style="font-size:12.8000001907349px">- Adding support for at least few HTTP auth methods</span></div>Why should the "write" path be more secured/more flexible than the read path ? If I take a look at the current HTTP store, only basic auth is supported (ie http://user:pass@server1/myLinuxImage). I suggest the write path (ie the add() method) should support the same auth mecanism. The cloud admin could also add some firewall rules to make sure the HTTP backend server can only be accessed by the Glance-api servers.<div><br></div><div>><span style="font-size:12.8000001907349px">- Having a sufixed URL where we're sure glance will have proper</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">> permissions to upload data.</span></div><div><span style="font-size:12.8000001907349px">That's up the the cloud admin/operator to make it work. The HTTP glance_store could have 2 config flags :</span></div><div><span style="font-size:12.8000001907349px">a) "http_server", a string with the scheme (http vs https) and the hostname of the HTTP server, ie '<a href="http://server1">http://server1</a>' </span></div><div><span style="font-size:12.8000001907349px">b) "path_prefix". A string that will prefix the "path" part of the image URL. This config flag could be left empty/is optional. </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">></span><span style="font-size:12.8000001907349px">Handling HTTP responses from the server</span></div><div><span style="font-size:12.8000001907349px">That's of course to be discussed. But, IMO, this should be as simple as "if response.code is 200 or 202 then OKAY else raise GlanceStoreException". I am not sure any other glance store is more "granular" than this. </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">></span><span style="font-size:12.8000001907349px">How can we handle quota?</span></div><div><span style="font-size:12.8000001907349px">I am new to glance_store, is there a notion of quotas in glance stores ? I though Glance (API) was handling this. What kind of quotas are we talking about here ?</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Frankly, it shouldn't add that much code. I feel we can make it clean if we leverage the different Python modules (httplib etc.) </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Regards,</span></div><div><span style="font-size:12.8000001907349px">Jordan</span></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 13, 2015 at 4:20 PM, Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 13/02/15 16:01 +0100, Jordan Pittier wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What is the difference between just calling the Glance API to upload an image,<br>
</blockquote>
versus adding add() functionality to the HTTP image store?<br>
You mean using "glance image-create --location <a href="http://server1/myLinuxImage" target="_blank">http://server1/<u></u>myLinuxImage</a> [..]<br>
" ? If so, I guess adding the add() functionality will save the user from<br>
having to find the right POST curl/wget command to properly upload his image.<br>
</blockquote>
<br></span>
I believe it's more complex than this. Having an `add` method for the<br>
HTTP store implies:<br>
<br>
- Figuring out the http method the server expects (POST/PUT)<br>
- Adding support for at least few HTTP auth methods<br>
- Having a sufixed URL where we're sure glance will have proper<br>
 permissions to upload data.<br>
- Handling HTTP responses from the server w.r.t the status of the data<br>
 upload. For example: What happens if the remote http server runs out<br>
 of space? What's the response status going to be like? How can we<br>
 make glance agnostic to these discrepancies across HTTP servers so<br>
 that it's consistent in its responses to glance users?<br>
- How can we handle quota?<br>
<br>
I'm not fully opposed, although it sounds like not worth it code-wise,<br>
maintenance-wise and performance-wise. The user will have to run just<br>
1 command but at the cost of all of the above.<br>
<br>
Do the points listed above make sense to you?<br>
<br>
Cheers,<br>
Flavio<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Fri, Feb 13, 2015 at 3:55 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote:<br>
<br>
   On 02/13/2015 09:47 AM, Jordan Pittier wrote:<br>
         Hi list,<br>
<br>
       I would like to add the 'add' capability to the HTTP glance store.<br>
<br>
       Let's say I (as an operator or cloud admin) provide an HTTP server<br>
       where<br>
       (authenticated/trusted) users/clients can make the following HTTP<br>
       request :<br>
<br>
       POST <a href="http://server1/myLinuxImage" target="_blank">http://server1/myLinuxImage</a> HTTP/1.1<br>
       Host: server1<br>
       Content-Length: 256000000<br>
       Content-Type: application/octet-stream<br>
<br>
       mybinarydata[..]<br>
<br>
       Then the HTTP server will store the binary data, somewhere (for<br>
       instance<br>
       locally), some how (for instance in a plain file), so that the data is<br>
       later on accessible by a simple GET <a href="http://server1/myLinuxImage" target="_blank">http://server1/myLinuxImage</a><br>
<br>
       In that case, this HTTP server could easily be a full fleshed Glance<br>
       store.<br>
<br>
       Questions :<br>
       1) Has this been already discussed/proposed ? If so, could someone give<br>
       me a pointer to this work ?<br>
       2) Can I start working on this ? (the 2 main work items are : 'add an<br>
       add method to glance_store._drivers.http.__<u></u>Store' and 'add a delete<br>
       method to glance_store._drivers.http.__<u></u>Store (HTTP DELETE method)'<br>
<br>
<br>
   What is the difference between just calling the Glance API to upload an<br>
   image, versus adding add() functionality to the HTTP image store?<br>
<br>
   Best,<br>
   -jay<br>
<br>
   ______________________________<u></u>______________________________<u></u>______________<br>
   OpenStack Development Mailing List (not for usage questions)<br>
   Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
   <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br></div></div><span class="HOEnZb"><font color="#888888">
-- <br>
@flaper87<br>
Flavio Percoco<br>
</font></span><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>