search

sonata-nfv / son-cli

SONATA SDK command line interface tools
http://www.sonata-nfv.eu/
Apache License 2.0
3 stars 11 forks source link

New son-access component #129

Closed dang03 closed 7 years ago

dang03 commented 7 years ago

Due to the removal of the SDK Catalogue component, a new component should arise as a extension of son-push: son-access. This new component would include son-push/son-pull and act as interface to the SP Gatekeeper/Catalogue. On SDK side, descriptors and packages should be kept/stored locally on the file system.

lconceicao commented 7 years ago

I'm beginning to structure the son-access tool. What I have in mind for the most basic command arguments is something like this:

son-access --push descriptor XPTO to upload a descriptor son-access --push package XPTO to upload a service package son-access --pull descriptor XPTO to download a descriptor

What do you think? Is it user friendly/feasible enough or should we do this in a different way?

jbonnet commented 7 years ago

Hi, Luís,

Currently we do not support descriptor upload/download, but only packages. Does this new develpment imply that we need to support it in the future? If so, can you please elaborate a bit more? E.g., if you upload only a descriptor, will it leave alone, with no package? Should we accept descriptor updates? Or does any change (like it is now, for packages) implies a new version, and therefore a new record in the catalogue?

José Bonnet AlticeLabs.comhttp://alticelabs.com [cid:B4A60A90-BEB9-4456-862B-BEAC27C6B95D@ptin.corpPT.com]

On 19 Oct 2016, at 15:18, Luís Conceição notifications@github.com<mailto:notifications@github.com> wrote:

I'm beginning to structure the son-access tool. What I have in mind for the most basic command arguments is something like this:

son-access --push descriptor XPTO to upload a descriptor son-access --push package XPTO to upload a service package son-access --pull descriptor XPTO to download a descriptor

What do you think? Is it user friendly/feasible enough or should we do this in a different way?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/sonata-nfv/son-cli/issues/129#issuecomment-254826609, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAAuQw5lkmDSFKmLey6sNTirVMz-FLKNks5q1iaxgaJpZM4KZlnZ.

lconceicao commented 7 years ago

Hello José,

It is my understanding that the functionalities of the old SDK catalogue must be assured by the Catalogue residing inside the SP. This raises one question: will the son-cli tool be able to communicate directly with the SP Catalogue or is the gatekeeper required to mediate/proxy messages?

I assumed (perhaps wrongly?) that the second case was going to be implemented because of user/developer authentication.. But if the son-cli tools are meant to have direct access to the SP catalogue, the purposed command arguments do not make sense.

jbonnet commented 7 years ago

…and you’ve assumed well: communication with the catalogue will go through the Gatekeeper.

José Bonnet AlticeLabs.comhttp://alticelabs.com [cid:B4A60A90-BEB9-4456-862B-BEAC27C6B95D@ptin.corpPT.com]

On 19 Oct 2016, at 16:05, Luís Conceição notifications@github.com<mailto:notifications@github.com> wrote:

Hello José,

It is my understanding that the functionalities of the old SDK catalogue must be assured by the Catalogue residing inside the SP. This raises one question: will the son-cli tool be able to communicate directly with the SP Catalogue or is the gatekeeper required to mediate/proxy messages?

I assumed (perhaps wrongly?) that the second case was going to be implemented because of user/developer authentication.. But if the son-cli tools are meant to have direct access to the SP catalogue, the purposed command arguments do not make sense.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/sonata-nfv/son-cli/issues/129#issuecomment-254841060, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAAuQw_KZKASsrSsgLfUknQqUizre2V6ks5q1jGqgaJpZM4KZlnZ.

dang03 commented 7 years ago

Hi @lconceicao, As José said, Gatekeeper currently allows to submit/request packages. Without SDK Catalogues, son-access (think it as son-push and "son-pull" together) should have to submit and request only packages as it is now, and then on the SDK side, unpack the package to obtain the descriptors. However this might change, I don't know.. because SP Catalogue implements methods to obtain descriptors. We (Dani and @shuaibsiddiqui) would like to collaborate on this task.

lconceicao commented 7 years ago

I think that in the future Gatekeeper should allow the SDK to retrieve service and function descriptors independently, otherwise the SDK would have to "know" which packages contain the required descriptors. This will also raise other issues, e.g. imagine that a developer is only is authorized to access a particular VNF, which is part of a NS containing other VNFs to which he does not have authorization. In this case the developer wouldn't have access to that particular VNF as it would imply to download the whole service package. On top of all, the complexity and overhead of retrieving and unpacking a whole service package just to use a VNF, seems to me, illogical.

jbonnet commented 7 years ago

Luís,

your reasoning makes sense, and that was the initial idea. The packaging conceot emerged later, and if we’re going to change that, we’d better think a bit about it. My suggestion id to include this in one of our WP2 (Architectural) discussions

José Bonnet AlticeLabs.comhttp://alticelabs.com [cid:B4A60A90-BEB9-4456-862B-BEAC27C6B95D@ptin.corpPT.com]

On 20 Oct 2016, at 10:50, Luís Conceição notifications@github.com<mailto:notifications@github.com> wrote:

I think that in the future Gatekeeper should allow the SDK to retrieve service and function descriptors independently, otherwise the SDK would have to "know" which packages contain the required descriptors. This will also raise other issues, e.g. imagine that a developer is only is authorized to access a particular VNF, which is part of a NS containing other VNFs to which he does not have authorization. In this case the developer wouldn't have access to that particular VNF as it would imply to download the whole service package. On top of all, the complexity and overhead of retrieving and unpacking a whole service package just to use a VNF, seems to me, illogical.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/sonata-nfv/son-cli/issues/129#issuecomment-255061046, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAAuQ5RhMpTKewMSSDinGJbjGvO1EwMGks5q1zlRgaJpZM4KZlnZ.

dang03 commented 7 years ago

son-access component released in version 2.0