Here’s your digest for today!
#ariatosca
undefined: [UPDATE] A lot of progress on the instantiation module refractory ,
all tests are passing. It still remains to do some more cleaning up before it's
ready for review.
undefined: <@U546PEP9S> did you see the comment i added to the JIRA?
<https://issues.apache.org/jira/browse/ARIA-174>
undefined: I have seen the issue. I think I may have encountered this issue and
already fixed it, though haven't checked it yet. Will test if this behavior was
fixed
undefined: great, you can use the template i provided for a test
<@U53NR8XFF> after all our work on API documentation, we still don't have it
up. how can we get it on the main website?
undefined: <@U53P75YTD> can you point me to the latest?
undefined: you need to build it via `make docs`. ideally there should be a
trigger to do this automatically... <http://readthedocs.org|readthedocs.org>
does this.
alternatively, if you have a script that updates the site, it could be done as
part of the script everytime you update the site.
undefined: <https://github.com/apache/incubator-ariatosca/tree/master/docs>
Looking into this
Talk it looks like this in includes Python classes lists
What am I missing?
<@U53P75YTD> *
undefined: when you run `make docs` it will create an `html` directory there.
that's what you want to include in the site.
undefined: Okay, really cool, I'l add this to the website build process
few comments
it shows as version 0.2.0
which probably should be 0.1.1
Additionally, this is a project reference doc, we should probably have a
developer guidance doc, that shows examples of how to use the the different
functions we support.
But we can add this on a later stage, I thing that at this point it's
important to have a reference examples for the integration methods we proposed
to ONAP (Python lib|REST|CLI Execution|Storage)
undefined: <@U53P75YTD>
undefined: in that case you don't want the latest -- you want to do a git
checkout by the tag of the version
we are missing REST for now, it is being worked on in a separate repo, but
hopefully it will become a PR for our main repo at some point, in which case of
course we will add that documentation
as for developer guidance -- at this point it's on the wiki. there's
definitely room to discuss unifying it all in one place.
undefined: That is what Dewayne is working on under his repo, right?
undefined: Correct
undefined: Cool
undefined: I'm looking now into gRPC, and this makes me think, would that be a
good idea to use gRPC as an integration method for non-python languages like
Java? To implement this we would need to implement a gRPC server within ARIA,
and have Java code reference example of how to interact with ARIA, the server
would probably expose similar calls as the REST API in first phase, so clients
could build native object from ARIA parsed templates. <!channel> thoughts?
undefined: u can use gRPC or Jython or Thrift or Google Protocol buffers
undefined: yes, thrift is probably more common in the python world for such
things
but it would be INCREDIBLY hard to implement in any useful way, imo
undefined: u may have to account for the additional overhead of having to
convert to an intermediate format
and take a performance hit there
undefined: yeah, though i doubt performance would be the issue here for ARIA's
use cases
i think http/json (what we annoyingly and mistakingly call "REST" here) is the
most portable for us
undefined: _hate python anyways from my recent exp dealing with python’s crap
incompatibilities with python 2 and python3_
undefined: That's right, performance is not a major issue, but easy native
integration with Java is critical as ONAP is Java
undefined: there can be a special java client for our "rest" api
that's not a problem. there are many libs for that, that could automatically
create the client via the swagger doc
undefined: A Rest api client in java can be done with Jersey, Swagger or many
other libs
we don’t need thrift for that
undefined: yes, "rest" is the right solution in our case
undefined: and that shuld be easier to do
undefined: right, rest is the simplest way, but that would mean we would
probably have to develop a Java binding client, which I think we should try to
avoid as it's not
not a main focues
undefined: let me guess, <@U53NR8XFF> is now in USA somewhere on west coast
undefined: Nah, I'm a night owl, this is my research time, peace and quite next
to armed duckdockgo window (because those searches are not going to hunt me
tomorrow! )
:smile:
undefined: i shuld switch to duckduckgo
fuck google
undefined: super easy, just change your default search for Chrome
undefined: yeah i know
undefined: the similar UX makes you feel right at home :slightly_smiling_face:
undefined: but how relevant r the search results
and the ranking of the results based on user prefs and behavior ??
google does that well at the cost of being hunted
undefined: the main reason I switch was because I discovered Google was hiding
super relevant new search results just because of previous clicks. Super
annoying
*switched
Now looking into Thrift, this could be a good solution as well
undefined: heh interesting, i can see why they do it
well the ethics r questionable here
but yeah i shuld switch though nevertheless
undefined: and reuse of an Apache project which I believe is a good thing
:slightly_smiling_face:
undefined: arrhur, really no need for thrift. rest-based apis would work fine,
and it would mean no need to maintain multiple api implementations.
undefined: no need of thrift if using Rest - agreed
+1 <@U53P75YTD>
undefined: btw, thrift was created by an acquaintance of mine in chicago...
undefined: cool
switching topics and reviving the discussion about moving to gitbox
r folks here now ok with starting that convo
undefined: <@U53P75YTD> the main feedback I got from AT&T is that it would
mean that they would have to parse and handle the output
undefined: if the REST transfer is in JSON
undefined: they are wrong. there are clients that do that for you in java. we
will make sure that they do not have to deal with parsing of anything.
undefined: then Java has number of json libraries -some of them r apache
projects
the libraries i mentioned earlier like Jersey, swagger etc r all REST api
libraries for java
_there’s also Apache Wink which is nearly dead now_
undefined: It would we awesome to have an example that showcases that
undefined: showcases what?
Java Rest api client ?
yeah i have shit load of those
undefined: using Java locally to handle the REST API, and could easely replace
their current solution
undefined: arthur, talk to dewayne about this, he is working on that whole
connect. and i don't think he's on this slack.
undefined: They fear that they would have to implement some of the logic, which
could make aria redundant, @DeWayne is working on the java+rest code, but I'm
not sure that would fit for ONAP SDC
undefined: why are you not believing what myself and smarthi are telling you?
the client libraries for java involve no work
there is no essential difference between using them and using thrift or others
undefined: so ONAP is in java
and Aria is python
does ONAP not have a RESt api ?
undefined: I'm proposing to test this for SDC as well to find deltas for their
needs. SO does only execution, it delegates all the work to ARIA. SDC requires
passing node templates, relationships and other "internal" stuff, their concern
is reconstructing all of this from REST would require implementing sole logic
on top of what ARIA does in Python.
undefined: it's not exactly true that "onap is in java". most components
developed specifically for onap are in java. but they use a huge range of 3rd
party components, many of which were likely written in C/C++, ruby, etc.
undefined: offline guys - dinner time , lemme know if i can help on java stuff
undefined: <@U4SCXA5DL> Enjoy :slightly_smiling_face:
