'ad:traffic_in' and 'ad:traffic_out' json dicts are changed/rubyfied

[gwarf]

Hello,
Following some debugging for EGI-Federation/cloud-info-provider#149 it seems that information about ad:traffic_our and ad:traffin_in image attributes is rubyfied.
In https://vmcaster.appdb.egi.eu/store/vappliance/scipion.v1.0/image.list it's expressed as a JSON dict:

"ad:traffic_in": [
  {
    "ad:net_protocol": "tcp",
    "ad:net_port": "8000:8000",
    "ad:net_range": "0.0.0.0/0"
  }
],

And once it went through cloudkeeper and cloudkeeper-os it's recorded like this in OpenStack, as a string of a somewhat rubyfied hash (with weird : before the keys):

[{:“ad:net_protocol”=>“tcp”, :“ad:net_port”=>“8000:8000", :“ad:net_range”=>“0.0.0.0/0"}]

Looking at https://github.com/the-cloudkeeper-project/cloudkeeper-os/blob/master/cloudkeeper_os/utils.py#L90 it seems that it more something that may be done by cloudkeeper itself.

Could you please have a look?

[gwarf]

Pinging @Pansanel, @mhaggel and @enolfc.

[amarthadan]

Cloudkeeper < 2.x sends all the attributes of an appliance as a map String -> String. It doesn't take into consideration that some values might have additional structure. This won't happen with Cloudkeeper > 2.x since it's not sending all the attributes like before.

Is this something worth fixing in 1.x branch?

[enolfc]

Cloudkeeper < 2.x sends all the attributes of an appliance as a map String -> String. It doesn't take into consideration that some values might have additional structure. This won't happen with Cloudkeeper > 2.x since it's not sending all the attributes like before.

but still the attributes will be available to the backend, no?

Is this something worth fixing in 1.x branch?

Really depends on the timeline of the cloukeeper-os I believe. For the time being we are adding a fix at the cloud-info-provider so not really urgent

[amarthadan]

but still the attributes will be available to the backend, no?

No, not all of them. But if some attribute is needed on the backend I can extend the proto definition and add it. Just let me know what you need.

[gwarf]

Is it possible to know what is not planned to be made available? What is the reason behind it, potential security-related problem?

[amarthadan]

These are the attributes available for appliance:

• dc:description
• dc:identifier
• dc:date:expires
• ad:appid
• ad:mpuri
• ad:base_mpuri
• dc:title
• ad:group
• hv:size
• hv:uri
• hv:version
• sl:arch
• sl:checksum:sha512
• sl:os
• sl:osname
• sl:osversion
• hv:ram_minimum
• hv:core_minimum

and these two from image list section:

• dc:identifier
• ad:vo

The reason was restrictions on image tags in OpenNebula (character restrictions) and AWS (length resctriction). In order to use Cloudkeeper on all cloud platforms in the same way this is the compromise we had to make.

[enolfc]

I would expect the restrictions to be handled by the backends and keep the core as flexible as possible.

[amarthadan]

I figured that having a protocol with only clearly specified values is better then pushing all values from image list as a non-transparent map. The protocol can be easily extended (with backward compatibility) if some values are missing.

But if you insist on pushing all the values it can be brought back.

Anyway, that's a different issue. Can I close this issue as #wontfix?