Re: [openstack-dev] [TripleO][Tuskar] JSON output values from Tuskar API

2014-03-05 Thread Petr Blaho 
On Mon, Mar 03, 2014 at 09:19:34AM +0100, Radomir Dopieralski wrote:
 On 27/02/14 11:52, Petr Blaho wrote:
 
  I agree with you w/r/t to indirection when accessing data but I like the
  idea that when I look at json repsonse I see what type of resource it
  is. That wrapper element describes it. And I do not need to know what
  request (url, service, GET or POST...) triggered that output.
 
 That's data denormalization. What do you then do when the two sources of
 information don't agree? Also, do you actually need the json at all
 without knowing where it came from (not just from which api call, but
 which system and at what time)? I can't imagine such a situation.

Yeah, I agree with you that not wrapped json data is better solution.
I just liked how wrapped data looks.
 
 Finally, when you need to save a whole lot of json outputs and need to
 know where they come from, you traditionally put that information in the
 file name, no?
 
 -- 
 Radomir Dopieralski
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

My concern is that it looks like OpenStack does not have a proper way
how to format output json in APIs and it is on behalf of each project.

-- 
Petr Blaho, pbl...@redhat.com
Software Engineer

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][Tuskar] JSON output values from Tuskar API

2014-02-27 Thread Dougal Matthews 

On 26/02/14 18:38, Petr Blaho wrote:

I am wondering what is the OpenStack way of returning json from
apiclient.


Good question, I think its important for us to be as consistent as
possible.


By looking at API docs at http://api.openstack.org/ I can say that
projects use both ways, altought what I would describe as nicer API
uses namespaced variant.


Can you explain why you prefer it? I'm curious as I would tend to vote
for no namespaces. They add an extra level of nesting but don't actually
provide any benefits that I can see.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][Tuskar] JSON output values from Tuskar API

2014-02-27 Thread Dougal Matthews 

On 26/02/14 19:17, Jay Dobies wrote:

This is a new concept to me in JSON, I've never heard of a wrapper
element like that being called a namespace.


It's certainly not in the spec AFAIK, but I've seen this approach before
in various places.



My first impression is that is looks like cruft. If there's nothing else
at the root of the JSON document besides the namespace, all it means is
that every time I go to access relevant data I have an extra layer of
indirection.


+1



If we ever forsee an aggregate API, I can see some value in it. For
instance, a single call that aggregates a volume with some relevant
metrics from ceilometer. In that case, I could see leaving both distinct
data sets separate at the root with some form of namespace rather than
attempting to merge the data.


I can see this working well - return a set of raw API responses and
aggregate information under the tuskar namespace. However, I don't
think any other OpenStack services return multiple top level
namespaces. Do we have examples of this?


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][Tuskar] JSON output values from Tuskar API

2014-02-27 Thread Petr Blaho 
On Wed, Feb 26, 2014 at 02:17:53PM -0500, Jay Dobies wrote:
 This is a new concept to me in JSON, I've never heard of a wrapper 
 element like that being called a namespace.

I named it namespace in my email. It is not any kind of formal or
standard naming. Wrapper element is better name for this... wrapper
element :-)
 
 My first impression is that is looks like cruft. If there's nothing else 
 at the root of the JSON document besides the namespace, all it means is 
 that every time I go to access relevant data I have an extra layer of 
 indirection. Something like:
 
 volume_wrapper = get_volume(url)
 volume = volume_wrapper['volume']
 
 or
 
 volume = get_volume(url)
 name = volume['volume']['name']

I agree with you w/r/t to indirection when accessing data but I like the
idea that when I look at json repsonse I see what type of resource it
is. That wrapper element describes it. And I do not need to know what
request (url, service, GET or POST...) triggered that output.

 
 If we ever forsee an aggregate API, I can see some value in it. For 
 instance, a single call that aggregates a volume with some relevant 
 metrics from ceilometer. In that case, I could see leaving both distinct 
 data sets separate at the root with some form of namespace rather than 
 attempting to merge the data.
 
 Even in that case, I think it'd be up to the aggregate API to introduce 
 that.
 
 Looking at api.openstack.org, there doesn't appear to be any high level 
 resource get that would aggregate the different subcollections.
 
 For instance, {tenant_id}/volumes stuffs everything inside of an element 
 called volumes. {tenant_id}/types stuffs everything inside of an 
 element called volume_types. If a call to {tenant_id} aggregated both of 
 those, then I can see leaving the namespace in on the single ID look ups 
 for consistency (even if it's redundant). However, the API doesn't 
 appear to support that, so just looking at the examples given it looks 
 like an added layer of depth that carries no extra information and makes 
 using the returned result a bit awkward IMO.
 

I did not think about aggregate APIs before... interesting idea...
 
 On 02/26/2014 01:38 PM, Petr Blaho wrote:
  Hi,
 
  I am wondering what is the OpenStack way of returning json from
  apiclient.
 
  I have got 2 different JSON response examples from 
  http://api.openstack.org/:
 
  json output with namespace:
  {
 volume:
 {
   status:available,
   availability_zone:nova,
   id:5aa119a8-d25b-45a7-8d1b-88e127885635,
   name:vol-002,
   volume_type:None,
   metadata:{
 contents:not junk
   }
 }
  }
  (example for GET 'v2/{tenant_id}/volumes/{volume_id}' of Block Storage API 
  v2.0 taken from
  http://api.openstack.org/api-ref-blockstorage.html [most values ommited])
 
  json output without namespace:
  {
 alarm_actions: [
 http://site:8000/alarm;
   ],
   alarm_id: null,
   combination_rule: null,
   description: An alarm,
   enabled: true,
   type: threshold,
   user_id: c96c887c216949acbdfbd8b494863567
  }
  (example for GET 'v2/alarms/{alarm_id}' of Telemetry API v2.0 taken from
  http://api.openstack.org/api-ref-telemetry.html [most values ommited])
 
  Tuskar API now uses without namespace variant.
 
  By looking at API docs at http://api.openstack.org/ I can say that
  projects use both ways, altought what I would describe as nicer API
  uses namespaced variant.
 
  So, returning to my question, does OpenStack have some rules what
  format of JSON (namespaced or not) should APIs return?
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Petr Blaho, pbl...@redhat.com
Software Engineer

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO][Tuskar] JSON output values from Tuskar API

2014-02-26 Thread Petr Blaho 
Hi,

I am wondering what is the OpenStack way of returning json from
apiclient.

I have got 2 different JSON response examples from http://api.openstack.org/:

json output with namespace:
{
  volume:
  {
status:available,
availability_zone:nova,
id:5aa119a8-d25b-45a7-8d1b-88e127885635,
name:vol-002,
volume_type:None,
metadata:{
  contents:not junk
}
  }
}
(example for GET 'v2/{tenant_id}/volumes/{volume_id}' of Block Storage API v2.0 
taken from
http://api.openstack.org/api-ref-blockstorage.html [most values ommited])

json output without namespace:
{
  alarm_actions: [
  http://site:8000/alarm;
],
alarm_id: null,
combination_rule: null,
description: An alarm,
enabled: true,
type: threshold,
user_id: c96c887c216949acbdfbd8b494863567
}
(example for GET 'v2/alarms/{alarm_id}' of Telemetry API v2.0 taken from
http://api.openstack.org/api-ref-telemetry.html [most values ommited])

Tuskar API now uses without namespace variant.

By looking at API docs at http://api.openstack.org/ I can say that
projects use both ways, altought what I would describe as nicer API
uses namespaced variant.

So, returning to my question, does OpenStack have some rules what
format of JSON (namespaced or not) should APIs return?

-- 
Petr Blaho, pbl...@redhat.com
Software Engineer

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][Tuskar] JSON output values from Tuskar API

2014-02-26 Thread Jay Dobies 
This is a new concept to me in JSON, I've never heard of a wrapper 
element like that being called a namespace.


My first impression is that is looks like cruft. If there's nothing else 
at the root of the JSON document besides the namespace, all it means is 
that every time I go to access relevant data I have an extra layer of 
indirection. Something like:


volume_wrapper = get_volume(url)
volume = volume_wrapper['volume']

or

volume = get_volume(url)
name = volume['volume']['name']

If we ever forsee an aggregate API, I can see some value in it. For 
instance, a single call that aggregates a volume with some relevant 
metrics from ceilometer. In that case, I could see leaving both distinct 
data sets separate at the root with some form of namespace rather than 
attempting to merge the data.


Even in that case, I think it'd be up to the aggregate API to introduce 
that.


Looking at api.openstack.org, there doesn't appear to be any high level 
resource get that would aggregate the different subcollections.


For instance, {tenant_id}/volumes stuffs everything inside of an element 
called volumes. {tenant_id}/types stuffs everything inside of an 
element called volume_types. If a call to {tenant_id} aggregated both of 
those, then I can see leaving the namespace in on the single ID look ups 
for consistency (even if it's redundant). However, the API doesn't 
appear to support that, so just looking at the examples given it looks 
like an added layer of depth that carries no extra information and makes 
using the returned result a bit awkward IMO.



On 02/26/2014 01:38 PM, Petr Blaho wrote:

Hi,

I am wondering what is the OpenStack way of returning json from
apiclient.

I have got 2 different JSON response examples from http://api.openstack.org/:

json output with namespace:
{
   volume:
   {
 status:available,
 availability_zone:nova,
 id:5aa119a8-d25b-45a7-8d1b-88e127885635,
 name:vol-002,
 volume_type:None,
 metadata:{
   contents:not junk
 }
   }
}
(example for GET 'v2/{tenant_id}/volumes/{volume_id}' of Block Storage API v2.0 
taken from
http://api.openstack.org/api-ref-blockstorage.html [most values ommited])

json output without namespace:
{
   alarm_actions: [
   http://site:8000/alarm;
 ],
 alarm_id: null,
 combination_rule: null,
 description: An alarm,
 enabled: true,
 type: threshold,
 user_id: c96c887c216949acbdfbd8b494863567
}
(example for GET 'v2/alarms/{alarm_id}' of Telemetry API v2.0 taken from
http://api.openstack.org/api-ref-telemetry.html [most values ommited])

Tuskar API now uses without namespace variant.

By looking at API docs at http://api.openstack.org/ I can say that
projects use both ways, altought what I would describe as nicer API
uses namespaced variant.

So, returning to my question, does OpenStack have some rules what
format of JSON (namespaced or not) should APIs return?



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev