Re: [ovirt-devel] Requiring Java 8 during runtime

2015-10-27 Thread Allon Mureinik 
I think it's a really bad practice to have different modules in the same
project with different language versions.

For GWT it seems to be required, but for the rest of the backend, I think
we should have one patch that moves the entire project in one go.
We can have the various maintainers ack it to show their consent.

On Mon, Oct 26, 2015 at 1:17 PM, Juan Hernández  wrote:

> On 10/26/2015 12:05 PM, Martin Mucha wrote:
> > not strictly related question: are we going to raise language level as
> well? So we can start using JDK8 features like lambdas etc?
> >
> > M.
> >
>
> Shortly after merging that patch I'll merge another one to raise the
> language level in the RESTAPI:
>
>   restapi: Use Java 8 as source and target
>   https://gerrit.ovirt.org/46288
>
> Doing the same in other components is up to their maintainers. I think
> that should be done everywhere, except where the use of GWT doesn't
> allow to do it.
>
> > - Original Message -
> >> Hello,
> >>
> >> As you probably know oVirt Engine 4 will use WildFly 10, and that
> >> requires Java 8. The version of WildFly that we currently use is 8.2.1,
> >> and it can work with both Java 7 and Java 8. In order to ease the
> >> transition I'm about to merge the following patch, that will require
> >> Java 8 during runtime:
> >>
> >>   core: Require Java 8 during runtime
> >>   https://gerrit.ovirt.org/46872
> >>
> >> The implication of this for you is that you must make sure that you have
> >> Java 8 installed in the machine where you run your the engine. Fedora 22
> >> only supports Java 8, so that isn't a problem. EL6 supports both Java 7
> >> and Java 8, so make sure that you have Java 8 installed:
> >>
> >>   yum -y install java-1.8.0-openjdk-devel
> >>
> >> If you have objections please speak now, otherwise I will merge the
> >> patch tomorrow.
> >>
> >> Regards,
> >> Juan Hernandez
> >>
> >> --
> >> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> >> 3ºD, 28016 Madrid, Spain
> >> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat
> S.L.
> >> ___
> >> Devel mailing list
> >> Devel@ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/devel
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
>
>
> --
> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3ºD, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

2015-10-27 Thread Roman Mohr 
On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández  wrote:

> On 10/26/2015 04:56 PM, Roman Mohr wrote:
> > Hi Juan,
> >
> > The way to specify the contract look pretty clean and nice.
> > I would love to read a few words about the big picture. What is the
> > final scenario?
> >
>
> The motivation for this change is that currently we don't have a central
> place where the RESTAPI is specified, rather we have several different
> places, using several different technologies:
>
> * XML schema for the data model.
> * JAX-RS for part of the operational model (without the parameters).
> * rsdl_metadata.yaml for the parameters of the operational model.
>
> This makes it difficult to infer information about the model. For
> example, the generators of the SDKs have to download the XML schema, and
> the RSDL (which is generated from the JAX-RS interfaces using reflection
> and combining it with the information from the rsdl_metadata.yaml file)
> and then they have to do their own computations to extract what they need.
>
> Same happens with the CLI: it has to extract the information it needs
> from the Python code generated for the Python SDK, yet another level of
> indirection.
>

You are right, that definitely needs to be cleaned up. I just want to
discuss a few points below with you.


>
> We are also lacking a comprehensive reference documentation of the
> RESTAPI. What we currently have has been written by hand, and gets out
> of sync very quickly, and we don't even notice.
>

Did you also consider swagger? It is made for exactly that purpose.
I created a demo in [1] which uses resteasy, weld, hibernate-validator and
swagger to demonstrate how to do DRY with jaxrs.
Would be great to hear you thoughts on that.

And there is the great swagger-ui [8] to display the documentation in a
more human readable way.


>
> To solve these issues I intend to have the specification of the RESTAPI
> only in one place, and using only one technology. I decided to use Java
> interfaces for that. Note however that they are just the support for the
> information, like paper is the support for ink. I decided to use Java
> because it is easy to create, modify and re-factor using tools familiar
> to most of us.
>
> These source of these interfaces is analysed (using QDox, currently) and
> a "model" of the RESTAPI is generated in memory. This model is
> independent of the supporting Java source, and easy to consume. For
> example, imagine that you want to list all the types available in the
> model and for each one display its documentation:
>
>   Model model = ...;
>   for (Type type : model.getTypes()) {
> Name name = type.getName();
> String doc = type.getDoc();
> System.out.println(name + ": " + doc);
>   }
>
> Something like this, but more elaborate, will be part of a web
> application that provides comprehensive reference documentation,
> assuming that we dedicate the time to write documentation comments in
> the specification.
>
> I intend to use this model also to do simplify the generators of the
> SDKs and the CLI.
>
> In addition these are some of the things that I would like to change in
> the near future (for 4.0):
>
> * Move the specification of the parameters of operations out of the
> rsdl_metadata.yaml file and into the model. For example:
>
>   @Service
>   public VmService {
> /**
>  * The operation to add a virtual machine.
>  */
> interface Add {
>   /**
>* The representation of the virtual machine is received
>* as parameter, and the representation of the created
>* virtual machine is returned as result.
>*/
>@In @Out Vm vm();
>
>/**
> * In the future, we will be able to specify other
> * parameters here.
> */
>@In Boolean force();
>
>/**
> * Even with default values.
> */
>@In default Boolean force() { return true; }
>
>/**
> * And we will be able to specify constraints, which
> * will replace the rsdl_metadata.yaml file.
> */
>@Constraint
>default boolean vmNameMustNotBeNull() {
>  return vm().name() != null;
>}
>  }
>   }
>
> * Enforce the constraints automatically. If the constraints are in the
> model, then we can just check them and reject requests before delivering
> them to the application. Currently we do this manually (and often
> forget) with calls to "validate(...)" methods.
>


Did you consider just annotating the DTOs with JSR-303 annotations and
integrate a validator with jax-rs?
See [2] for an example.


>
> * Generate the Java classes directly from the model. Instead of Model ->
> XML Schema -> Java, we can do Model -> Java. This will allow us to solve
> some of the XJC compiler limitations, like the horrible way we handle
> arrays today.
>

Swagger [3] is a rest documentation specification. There is also a maven
plugin [4] and you can create clients for example with

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

2015-10-27 Thread Juan Hernández 
On 10/27/2015 10:16 AM, Roman Mohr wrote:
> 
> 
> On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández  > wrote:
> 
> On 10/26/2015 04:56 PM, Roman Mohr wrote:
> > Hi Juan,
> >
> > The way to specify the contract look pretty clean and nice.
> > I would love to read a few words about the big picture. What is the
> > final scenario?
> >
> 
> The motivation for this change is that currently we don't have a central
> place where the RESTAPI is specified, rather we have several different
> places, using several different technologies:
> 
> * XML schema for the data model.
> * JAX-RS for part of the operational model (without the parameters).
> * rsdl_metadata.yaml for the parameters of the operational model.
> 
> This makes it difficult to infer information about the model. For
> example, the generators of the SDKs have to download the XML schema, and
> the RSDL (which is generated from the JAX-RS interfaces using reflection
> and combining it with the information from the rsdl_metadata.yaml file)
> and then they have to do their own computations to extract what they
> need.
> 
> Same happens with the CLI: it has to extract the information it needs
> from the Python code generated for the Python SDK, yet another level of
> indirection.
> 
> 
> You are right, that definitely needs to be cleaned up. I just want to
> discuss a few points below with you.
>  
> 
> 
> We are also lacking a comprehensive reference documentation of the
> RESTAPI. What we currently have has been written by hand, and gets out
> of sync very quickly, and we don't even notice.
> 
> 
> Did you also consider swagger? It is made for exactly that purpose.
> I created a demo in [1] which uses resteasy, weld, hibernate-validator
> and swagger to demonstrate how to do DRY with jaxrs.
> Would be great to hear you thoughts on that.
> 
> And there is the great swagger-ui [8] to display the documentation in a
> more human readable way.
>  

Yes, I considered Swagger, and rejected it because it is JSON centric,
and I think JSON isn't as good as Java to represent the contracts of our
RESTAPI.

In addition we need to do these changes in a smooth way, without causing
big changes in the middle. For example, in the first step we need to
preserve the JAX-RS interfaces as they are today, to avoid massive
changes to all the resource implementations. This could be done with
Swagger, but would require custom code generators. With less effort we
can do our own.

Swagger UI is certainly great. I did test it and it is really good. We
may be able to copy some concepts.

> 
> 
> To solve these issues I intend to have the specification of the RESTAPI
> only in one place, and using only one technology. I decided to use Java
> interfaces for that. Note however that they are just the support for the
> information, like paper is the support for ink. I decided to use Java
> because it is easy to create, modify and re-factor using tools familiar
> to most of us.
> 
> These source of these interfaces is analysed (using QDox, currently) and
> a "model" of the RESTAPI is generated in memory. This model is
> independent of the supporting Java source, and easy to consume. For
> example, imagine that you want to list all the types available in the
> model and for each one display its documentation:
> 
>   Model model = ...;
>   for (Type type : model.getTypes()) {
> Name name = type.getName();
> String doc = type.getDoc();
> System.out.println(name + ": " + doc);
>   }
> 
> Something like this, but more elaborate, will be part of a web
> application that provides comprehensive reference documentation,
> assuming that we dedicate the time to write documentation comments in
> the specification.
> 
> I intend to use this model also to do simplify the generators of the
> SDKs and the CLI.
> 
> In addition these are some of the things that I would like to change in
> the near future (for 4.0):
> 
> * Move the specification of the parameters of operations out of the
> rsdl_metadata.yaml file and into the model. For example:
> 
>   @Service
>   public VmService {
> /**
>  * The operation to add a virtual machine.
>  */
> interface Add {
>   /**
>* The representation of the virtual machine is received
>* as parameter, and the representation of the created
>* virtual machine is returned as result.
>*/
>@In @Out Vm vm();
> 
>/**
> * In the future, we will be able to specify other
> * parameters here.
> */
>@In Boolean force();
> 
>/**
> * Even with default values.
> */
>@In default Boolean force() { return true; }
>

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

2015-10-27 Thread Roman Mohr 
On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández 
wrote:

> On 10/27/2015 10:16 AM, Roman Mohr wrote:
> >
> >
> > On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández  > > wrote:
> >
> > On 10/26/2015 04:56 PM, Roman Mohr wrote:
> > > Hi Juan,
> > >
> > > The way to specify the contract look pretty clean and nice.
> > > I would love to read a few words about the big picture. What is the
> > > final scenario?
> > >
> >
> > The motivation for this change is that currently we don't have a
> central
> > place where the RESTAPI is specified, rather we have several
> different
> > places, using several different technologies:
> >
> > * XML schema for the data model.
> > * JAX-RS for part of the operational model (without the parameters).
> > * rsdl_metadata.yaml for the parameters of the operational model.
> >
> > This makes it difficult to infer information about the model. For
> > example, the generators of the SDKs have to download the XML schema,
> and
> > the RSDL (which is generated from the JAX-RS interfaces using
> reflection
> > and combining it with the information from the rsdl_metadata.yaml
> file)
> > and then they have to do their own computations to extract what they
> > need.
> >
> > Same happens with the CLI: it has to extract the information it needs
> > from the Python code generated for the Python SDK, yet another level
> of
> > indirection.
> >
> >
> > You are right, that definitely needs to be cleaned up. I just want to
> > discuss a few points below with you.
> >
> >
> >
> > We are also lacking a comprehensive reference documentation of the
> > RESTAPI. What we currently have has been written by hand, and gets
> out
> > of sync very quickly, and we don't even notice.
> >
> >
> > Did you also consider swagger? It is made for exactly that purpose.
> > I created a demo in [1] which uses resteasy, weld, hibernate-validator
> > and swagger to demonstrate how to do DRY with jaxrs.
> > Would be great to hear you thoughts on that.
> >
> > And there is the great swagger-ui [8] to display the documentation in a
> > more human readable way.
> >
>
> Yes, I considered Swagger, and rejected it because it is JSON centric,
> and I think JSON isn't as good as Java to represent the contracts of our
> RESTAPI.
>

You just write plain jax-rs, swagger just creates a description out of it.
So  the source defining the contract is pure java (jax-rs with some swagger
annotations for description, etc.).
Or am I missing the point here?


>
> In addition we need to do these changes in a smooth way, without causing
> big changes in the middle. For example, in the first step we need to
> preserve the JAX-RS interfaces as they are today, to avoid massive
> changes to all the resource implementations. This could be done with
>
Swagger, but would require custom code generators. With less effort we
> can do our own.
>

This is of course generally a difficult task. But I do not know why it
would be more difficult to write a custom swagger reader (if we even have
to, it can read the interfaces as well) .
They are pretty streight forward. Just look at [9], this contains the wole
jax-rs specific code to generate the swagger documentation.

But yes, I don't know every detail here of the engine and can't clearly say
that integrating that would just streight forward (my feeling tells me that
it would not be too hard). I am just under the impression that we would
benefit from that. Just reduces custom magic to a minimum.


>
> Swagger UI is certainly great. I did test it and it is really good. We
> may be able to copy some concepts.
>
> >
> >
> > To solve these issues I intend to have the specification of the
> RESTAPI
> > only in one place, and using only one technology. I decided to use
> Java
> > interfaces for that. Note however that they are just the support for
> the
> > information, like paper is the support for ink. I decided to use Java
> > because it is easy to create, modify and re-factor using tools
> familiar
> > to most of us.
> >
> > These source of these interfaces is analysed (using QDox, currently)
> and
> > a "model" of the RESTAPI is generated in memory. This model is
> > independent of the supporting Java source, and easy to consume. For
> > example, imagine that you want to list all the types available in the
> > model and for each one display its documentation:
> >
> >   Model model = ...;
> >   for (Type type : model.getTypes()) {
> > Name name = type.getName();
> > String doc = type.getDoc();
> > System.out.println(name + ": " + doc);
> >   }
> >
> > Something like this, but more elaborate, will be part of a web
> > application that provides comprehensive reference documentation,
> > assuming that we dedicate the time to write documentation comments in

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

2015-10-27 Thread Roman Mohr 
On Tue, Oct 27, 2015 at 1:45 PM, Juan Hernández  wrote:

> On 10/27/2015 12:55 PM, Roman Mohr wrote:
> >
> >
> > On Tue, Oct 27, 2015 at 12:16 PM, Juan Hernández  > > wrote:
> >
> > On 10/27/2015 11:28 AM, Roman Mohr wrote:
> > >
> > >
> > > On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández <
> jhern...@redhat.com 
> > > >> wrote:
> > >
> > > On 10/27/2015 10:16 AM, Roman Mohr wrote:
> > > >
> > > >
> > > > On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández <
> jhern...@redhat.com 
> > >
> > > > 
> >  > > >
> > > > On 10/26/2015 04:56 PM, Roman Mohr wrote:
> > > > > Hi Juan,
> > > > >
> > > > > The way to specify the contract look pretty clean and
> > nice.
> > > > > I would love to read a few words about the big
> > picture. What
> > > is the
> > > > > final scenario?
> > > > >
> > > >
> > > > The motivation for this change is that currently we
> > don't have
> > > a central
> > > > place where the RESTAPI is specified, rather we have
> several
> > > different
> > > > places, using several different technologies:
> > > >
> > > > * XML schema for the data model.
> > > > * JAX-RS for part of the operational model (without the
> > > parameters).
> > > > * rsdl_metadata.yaml for the parameters of the
> > operational model.
> > > >
> > > > This makes it difficult to infer information about the
> > model. For
> > > > example, the generators of the SDKs have to download the
> XML
> > > schema, and
> > > > the RSDL (which is generated from the JAX-RS interfaces
> > using
> > > reflection
> > > > and combining it with the information from the
> > > rsdl_metadata.yaml file)
> > > > and then they have to do their own computations to
> extract
> > > what they
> > > > need.
> > > >
> > > > Same happens with the CLI: it has to extract the
> information
> > > it needs
> > > > from the Python code generated for the Python SDK, yet
> > another
> > > level of
> > > > indirection.
> > > >
> > > >
> > > > You are right, that definitely needs to be cleaned up. I
> > just want to
> > > > discuss a few points below with you.
> > > >
> > > >
> > > >
> > > > We are also lacking a comprehensive reference
> > documentation of the
> > > > RESTAPI. What we currently have has been written by
> > hand, and
> > > gets out
> > > > of sync very quickly, and we don't even notice.
> > > >
> > > >
> > > > Did you also consider swagger? It is made for exactly that
> > purpose.
> > > > I created a demo in [1] which uses resteasy, weld,
> > hibernate-validator
> > > > and swagger to demonstrate how to do DRY with jaxrs.
> > > > Would be great to hear you thoughts on that.
> > > >
> > > > And there is the great swagger-ui [8] to display the
> > documentation
> > > in a
> > > > more human readable way.
> > > >
> > >
> > > Yes, I considered Swagger, and rejected it because it is JSON
> > centric,
> > > and I think JSON isn't as good as Java to represent the
> > contracts of our
> > > RESTAPI.
> > >
> > >
> > > You just write plain jax-rs, swagger just creates a description
> out of
> > > it. So  the source defining the contract is pure java (jax-rs with
> > some
> > > swagger annotations for description, etc.).
> > > Or am I missing the point here?
> > >
> >
> > If I understand correctly the Swagger core is a JSON (or YAML)
> > specification of the API. From that you can generate JAX-RS annotated
> > code, not the other way around. So the specification document that
> you
> > write is a JSON document.
> >
> >
> > You are right, my terminology here was not clear. Swagger is just a
> > specification. Swagger-core and swagger-jaxrs are the ones which can
> > create the documnetation out of JAX-RS resources.
> >
> >
> > Alternatively, you can use the Swagger annotations to decorate your
> > implementation, both the entity classes and the JAX-RS resource
> > implementations, and then extract the model from that. But this

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

2015-10-27 Thread Juan Hernández 
On 10/27/2015 01:59 PM, Martin Betak wrote:
> 
> 
> 
> 
> - Original Message -
>> From: "Juan Hernández" 
>> To: "Roman Mohr" 
>> Cc: devel@ovirt.org
>> Sent: Tuesday, October 27, 2015 1:45:58 PM
>> Subject: Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel
>>
>> On 10/27/2015 12:55 PM, Roman Mohr wrote:
>>>
>>>
>>> On Tue, Oct 27, 2015 at 12:16 PM, Juan Hernández >> > wrote:
>>>
>>> On 10/27/2015 11:28 AM, Roman Mohr wrote:
>>> >
>>> >
>>> > On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández >> > 
>>> > >> wrote:
>>> >
>>> > On 10/27/2015 10:16 AM, Roman Mohr wrote:
>>> > >
>>> > >
>>> > > On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández
>>> > > 
>>> >
>>> > > 
>>> >> > >
>>> > > On 10/26/2015 04:56 PM, Roman Mohr wrote:
>>> > > > Hi Juan,
>>> > > >
>>> > > > The way to specify the contract look pretty clean and
>>> nice.
>>> > > > I would love to read a few words about the big
>>> picture. What
>>> > is the
>>> > > > final scenario?
>>> > > >
>>> > >
>>> > > The motivation for this change is that currently we
>>> don't have
>>> > a central
>>> > > place where the RESTAPI is specified, rather we have
>>> > > several
>>> > different
>>> > > places, using several different technologies:
>>> > >
>>> > > * XML schema for the data model.
>>> > > * JAX-RS for part of the operational model (without the
>>> > parameters).
>>> > > * rsdl_metadata.yaml for the parameters of the
>>> operational model.
>>> > >
>>> > > This makes it difficult to infer information about the
>>> model. For
>>> > > example, the generators of the SDKs have to download the
>>> > > XML
>>> > schema, and
>>> > > the RSDL (which is generated from the JAX-RS interfaces
>>> using
>>> > reflection
>>> > > and combining it with the information from the
>>> > rsdl_metadata.yaml file)
>>> > > and then they have to do their own computations to extract
>>> > what they
>>> > > need.
>>> > >
>>> > > Same happens with the CLI: it has to extract the
>>> > > information
>>> > it needs
>>> > > from the Python code generated for the Python SDK, yet
>>> another
>>> > level of
>>> > > indirection.
>>> > >
>>> > >
>>> > > You are right, that definitely needs to be cleaned up. I
>>> just want to
>>> > > discuss a few points below with you.
>>> > >
>>> > >
>>> > >
>>> > > We are also lacking a comprehensive reference
>>> documentation of the
>>> > > RESTAPI. What we currently have has been written by
>>> hand, and
>>> > gets out
>>> > > of sync very quickly, and we don't even notice.
>>> > >
>>> > >
>>> > > Did you also consider swagger? It is made for exactly that
>>> purpose.
>>> > > I created a demo in [1] which uses resteasy, weld,
>>> hibernate-validator
>>> > > and swagger to demonstrate how to do DRY with jaxrs.
>>> > > Would be great to hear you thoughts on that.
>>> > >
>>> > > And there is the great swagger-ui [8] to display the
>>> documentation
>>> > in a
>>> > > more human readable way.
>>> > >
>>> >
>>> > Yes, I considered Swagger, and rejected it because it is JSON
>>> centric,
>>> > and I think JSON isn't as good as Java to represent the
>>> contracts of our
>>> > RESTAPI.
>>> >
>>> >
>>> > You just write plain jax-rs, swagger just creates a description out
>>> > of
>>> > it. So  the source defining the contract is pure java (jax-rs with
>>> some
>>> > swagger annotations for description, etc.).
>>> > Or am I missing the point here?
>>> >
>>>
>>> If I understand correctly the Swagger core is a JSON (or YAML)
>>> specification of the API. From that you can generate JAX-RS annotated
>>> code, not the other way around. So the specification document that you
>>> write is a JSON document.
>>>
>>>
>>> You are right, my terminology here was not clear. Swagger is just a
>>> specification. Swagger-core and

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

2015-10-27 Thread Martin Betak 




- Original Message -
> From: "Juan Hernández" 
> To: "Roman Mohr" 
> Cc: devel@ovirt.org
> Sent: Tuesday, October 27, 2015 1:45:58 PM
> Subject: Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel
> 
> On 10/27/2015 12:55 PM, Roman Mohr wrote:
> > 
> > 
> > On Tue, Oct 27, 2015 at 12:16 PM, Juan Hernández  > > wrote:
> > 
> > On 10/27/2015 11:28 AM, Roman Mohr wrote:
> > >
> > >
> > > On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández  > > 
> > > >> wrote:
> > >
> > > On 10/27/2015 10:16 AM, Roman Mohr wrote:
> > > >
> > > >
> > > > On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández
> > > > 
> > >
> > > > 
> >  > > >
> > > > On 10/26/2015 04:56 PM, Roman Mohr wrote:
> > > > > Hi Juan,
> > > > >
> > > > > The way to specify the contract look pretty clean and
> > nice.
> > > > > I would love to read a few words about the big
> > picture. What
> > > is the
> > > > > final scenario?
> > > > >
> > > >
> > > > The motivation for this change is that currently we
> > don't have
> > > a central
> > > > place where the RESTAPI is specified, rather we have
> > > > several
> > > different
> > > > places, using several different technologies:
> > > >
> > > > * XML schema for the data model.
> > > > * JAX-RS for part of the operational model (without the
> > > parameters).
> > > > * rsdl_metadata.yaml for the parameters of the
> > operational model.
> > > >
> > > > This makes it difficult to infer information about the
> > model. For
> > > > example, the generators of the SDKs have to download the
> > > > XML
> > > schema, and
> > > > the RSDL (which is generated from the JAX-RS interfaces
> > using
> > > reflection
> > > > and combining it with the information from the
> > > rsdl_metadata.yaml file)
> > > > and then they have to do their own computations to extract
> > > what they
> > > > need.
> > > >
> > > > Same happens with the CLI: it has to extract the
> > > > information
> > > it needs
> > > > from the Python code generated for the Python SDK, yet
> > another
> > > level of
> > > > indirection.
> > > >
> > > >
> > > > You are right, that definitely needs to be cleaned up. I
> > just want to
> > > > discuss a few points below with you.
> > > >
> > > >
> > > >
> > > > We are also lacking a comprehensive reference
> > documentation of the
> > > > RESTAPI. What we currently have has been written by
> > hand, and
> > > gets out
> > > > of sync very quickly, and we don't even notice.
> > > >
> > > >
> > > > Did you also consider swagger? It is made for exactly that
> > purpose.
> > > > I created a demo in [1] which uses resteasy, weld,
> > hibernate-validator
> > > > and swagger to demonstrate how to do DRY with jaxrs.
> > > > Would be great to hear you thoughts on that.
> > > >
> > > > And there is the great swagger-ui [8] to display the
> > documentation
> > > in a
> > > > more human readable way.
> > > >
> > >
> > > Yes, I considered Swagger, and rejected it because it is JSON
> > centric,
> > > and I think JSON isn't as good as Java to represent the
> > contracts of our
> > > RESTAPI.
> > >
> > >
> > > You just write plain jax-rs, swagger just creates a description out
> > > of
> > > it. So  the source defining the contract is pure java (jax-rs with
> > some
> > > swagger annotations for description, etc.).
> > > Or am I missing the point here?
> > >
> > 
> > If I understand correctly the Swagger core is a JSON (or YAML)
> > specification of the API. From that you can generate JAX-RS annotated
> > code, not the other way around. So the specification document that you
> > write is a JSON document.
> > 
> > 
> > You are right, my terminology here was not clear. Swagger is just a
> > specification. Swagger-core and swagger-jaxrs are the ones which can
> > create the

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

2015-10-27 Thread Juan Hernández 
On 10/27/2015 11:28 AM, Roman Mohr wrote:
> 
> 
> On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández  > wrote:
> 
> On 10/27/2015 10:16 AM, Roman Mohr wrote:
> >
> >
> > On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández  
> > >> wrote:
> >
> > On 10/26/2015 04:56 PM, Roman Mohr wrote:
> > > Hi Juan,
> > >
> > > The way to specify the contract look pretty clean and nice.
> > > I would love to read a few words about the big picture. What
> is the
> > > final scenario?
> > >
> >
> > The motivation for this change is that currently we don't have
> a central
> > place where the RESTAPI is specified, rather we have several
> different
> > places, using several different technologies:
> >
> > * XML schema for the data model.
> > * JAX-RS for part of the operational model (without the
> parameters).
> > * rsdl_metadata.yaml for the parameters of the operational model.
> >
> > This makes it difficult to infer information about the model. For
> > example, the generators of the SDKs have to download the XML
> schema, and
> > the RSDL (which is generated from the JAX-RS interfaces using
> reflection
> > and combining it with the information from the
> rsdl_metadata.yaml file)
> > and then they have to do their own computations to extract
> what they
> > need.
> >
> > Same happens with the CLI: it has to extract the information
> it needs
> > from the Python code generated for the Python SDK, yet another
> level of
> > indirection.
> >
> >
> > You are right, that definitely needs to be cleaned up. I just want to
> > discuss a few points below with you.
> >
> >
> >
> > We are also lacking a comprehensive reference documentation of the
> > RESTAPI. What we currently have has been written by hand, and
> gets out
> > of sync very quickly, and we don't even notice.
> >
> >
> > Did you also consider swagger? It is made for exactly that purpose.
> > I created a demo in [1] which uses resteasy, weld, hibernate-validator
> > and swagger to demonstrate how to do DRY with jaxrs.
> > Would be great to hear you thoughts on that.
> >
> > And there is the great swagger-ui [8] to display the documentation
> in a
> > more human readable way.
> >
> 
> Yes, I considered Swagger, and rejected it because it is JSON centric,
> and I think JSON isn't as good as Java to represent the contracts of our
> RESTAPI.
> 
> 
> You just write plain jax-rs, swagger just creates a description out of
> it. So  the source defining the contract is pure java (jax-rs with some
> swagger annotations for description, etc.).
> Or am I missing the point here?
>  

If I understand correctly the Swagger core is a JSON (or YAML)
specification of the API. From that you can generate JAX-RS annotated
code, not the other way around. So the specification document that you
write is a JSON document.

Alternatively, you can use the Swagger annotations to decorate your
implementation, both the entity classes and the JAX-RS resource
implementations, and then extract the model from that. But this is
putting the implementation before the specification. That is where we
are today, and it causes multiple problems. I think it is better to have
the specification and the implementation separate. Swagger does that
well when using JSON directly, our metamodel also does it well, but
using a better language.

> 
> 
> In addition we need to do these changes in a smooth way, without causing
> big changes in the middle. For example, in the first step we need to
> preserve the JAX-RS interfaces as they are today, to avoid massive
> changes to all the resource implementations. This could be done with
> 
> Swagger, but would require custom code generators. With less effort we
> can do our own.
> 
> 
> This is of course generally a difficult task. But I do not know why it
> would be more difficult to write a custom swagger reader (if we even
> have to, it can read the interfaces as well) .
> They are pretty streight forward. Just look at [9], this contains the
> wole jax-rs specific code to generate the swagger documentation.
> 
> But yes, I don't know every detail here of the engine and can't clearly
> say that integrating that would just streight forward (my feeling tells
> me that it would not be too hard). I am just under the impression that
> we would benefit from that. Just reduces custom magic to a minimum.
>  

Using something like Swagger would be certainly possible, and not that
hard, but it requires an effort. For example, say that we decide to

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

2015-10-27 Thread Roman Mohr 
On Tue, Oct 27, 2015 at 12:16 PM, Juan Hernández 
wrote:

> On 10/27/2015 11:28 AM, Roman Mohr wrote:
> >
> >
> > On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández  > > wrote:
> >
> > On 10/27/2015 10:16 AM, Roman Mohr wrote:
> > >
> > >
> > > On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández <
> jhern...@redhat.com 
> > > >> wrote:
> > >
> > > On 10/26/2015 04:56 PM, Roman Mohr wrote:
> > > > Hi Juan,
> > > >
> > > > The way to specify the contract look pretty clean and nice.
> > > > I would love to read a few words about the big picture. What
> > is the
> > > > final scenario?
> > > >
> > >
> > > The motivation for this change is that currently we don't have
> > a central
> > > place where the RESTAPI is specified, rather we have several
> > different
> > > places, using several different technologies:
> > >
> > > * XML schema for the data model.
> > > * JAX-RS for part of the operational model (without the
> > parameters).
> > > * rsdl_metadata.yaml for the parameters of the operational
> model.
> > >
> > > This makes it difficult to infer information about the model.
> For
> > > example, the generators of the SDKs have to download the XML
> > schema, and
> > > the RSDL (which is generated from the JAX-RS interfaces using
> > reflection
> > > and combining it with the information from the
> > rsdl_metadata.yaml file)
> > > and then they have to do their own computations to extract
> > what they
> > > need.
> > >
> > > Same happens with the CLI: it has to extract the information
> > it needs
> > > from the Python code generated for the Python SDK, yet another
> > level of
> > > indirection.
> > >
> > >
> > > You are right, that definitely needs to be cleaned up. I just want
> to
> > > discuss a few points below with you.
> > >
> > >
> > >
> > > We are also lacking a comprehensive reference documentation of
> the
> > > RESTAPI. What we currently have has been written by hand, and
> > gets out
> > > of sync very quickly, and we don't even notice.
> > >
> > >
> > > Did you also consider swagger? It is made for exactly that purpose.
> > > I created a demo in [1] which uses resteasy, weld,
> hibernate-validator
> > > and swagger to demonstrate how to do DRY with jaxrs.
> > > Would be great to hear you thoughts on that.
> > >
> > > And there is the great swagger-ui [8] to display the documentation
> > in a
> > > more human readable way.
> > >
> >
> > Yes, I considered Swagger, and rejected it because it is JSON
> centric,
> > and I think JSON isn't as good as Java to represent the contracts of
> our
> > RESTAPI.
> >
> >
> > You just write plain jax-rs, swagger just creates a description out of
> > it. So  the source defining the contract is pure java (jax-rs with some
> > swagger annotations for description, etc.).
> > Or am I missing the point here?
> >
>
> If I understand correctly the Swagger core is a JSON (or YAML)
> specification of the API. From that you can generate JAX-RS annotated
> code, not the other way around. So the specification document that you
> write is a JSON document.
>

You are right, my terminology here was not clear. Swagger is just a
specification. Swagger-core and swagger-jaxrs are the ones which can create
the documnetation out of JAX-RS resources.


> Alternatively, you can use the Swagger annotations to decorate your
> implementation, both the entity classes and the JAX-RS resource
> implementations, and then extract the model from that. But this is
> putting the implementation before the specification. That is where we
> are today, and it causes multiple problems. I think it is better to have
> the specification and the implementation separate. Swagger does that
> well when using JSON directly, our metamodel also does it well, but
> using a better language.
>


Isn't our problem that we have everything scattered arount the place and
not that we are using JAX-RS? I don't think that this has anything to do
with specification before implementation or implementation before
specification.


> >
> >
> > In addition we need to do these changes in a smooth way, without
> causing
> > big changes in the middle. For example, in the first step we need to
> > preserve the JAX-RS interfaces as they are today, to avoid massive
> > changes to all the resource implementations. This could be done with
> >
> > Swagger, but would require custom code generators. With less effort
> we
> > can do our own.
> >
> >
> > This is of course generally a difficult task. But I

Re: [ovirt-devel] rethinking fake-kvm and faqemu

2015-10-27 Thread Martin Polednik 

On 26/10/15 15:24 +0200, Dan Kenigsberg wrote:

On Mon, Oct 26, 2015 at 11:17:10AM +0100, Michal Skrivanek wrote:


> On 26 Oct 2015, at 09:41, Dan Kenigsberg  wrote:
>
> On Mon, Oct 05, 2015 at 02:53:00PM +0200, Martin Polednik wrote:
>> On 05/10/15 11:31 +0200, Michal Skrivanek wrote:
>>>
>>> On Oct 3, 2015, at 20:48 , Martin Polednik  wrote:
>>>
 Hello everyone,

 I've been reworking the fake_kvm and faqemu VDSM hook to make them
 somewhat more usable and mostly to allow testing of ppc64le on x86_64
 based hosts.

 TL;DR version: checkout [1], enable fake_kvm and happy ppc64le hacking :)
>
> I like the initiative and the approach. Dropping faqemu bits out of
> mainline caps.py was an old task of mine. Moving code into lib/vdsm is a
> big task for our next release anyway.

one more unrelated note
current faqemu is broken on 3.6 as it removes the whole cpu tag which is needed 
when hotplug memory is enabled, which in turn enables numa, libvirt checks for 
cpu-numa mapping and fails to find any
please fix it along the way:-)


Better fix it on its own, since we'd need to have the fix backported.
(unless you plan to backport the whole cpuinfo branch)


It is fixed in the chain, but the fix can be backported without
cpuinfo with a bit of code redundancy. The bad thing is, fake_kvm
is also broken in 3.6 and fixing that becomes quite ugly (e.g. machine
types).
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

2015-10-27 Thread Juan Hernández 
On 10/27/2015 03:05 PM, Roman Mohr wrote:
> 
> 
> On Tue, Oct 27, 2015 at 2:41 PM, Juan Hernández  > wrote:
> 
> On 10/27/2015 02:10 PM, Roman Mohr wrote:
> >
> >
> > On Tue, Oct 27, 2015 at 1:45 PM, Juan Hernández  
> > >> wrote:
> >
> > On 10/27/2015 12:55 PM, Roman Mohr wrote:
> > >
> > >
> > > On Tue, Oct 27, 2015 at 12:16 PM, Juan Hernández 
> 
> >
> > > 
>  > >
> > > On 10/27/2015 11:28 AM, Roman Mohr wrote:
> > > >
> > > >
> > > > On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández 
> 
> >
> > 
> >>
> > > > 
> >
> > 
>  wrote:
> > > >
> > > > On 10/27/2015 10:16 AM, Roman Mohr wrote:
> > > > >
> > > > >
> > > > > On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández 
> 
> >
> > 
> >>
> > > 
> >
> > 
>  > > > >  
> >
> > 
> >>
> > > 
> >
> > 
> > wrote:
> > > > >
> > > > > On 10/26/2015 04:56 PM, Roman Mohr wrote:
> > > > > > Hi Juan,
> > > > > >
> > > > > > The way to specify the contract look pretty
> > clean and
> > > nice.
> > > > > > I would love to read a few words about the big
> > > picture. What
> > > > is the
> > > > > > final scenario?
> > > > > >
> > > > >
> > > > > The motivation for this change is that
> currently we
> > > don't have
> > > > a central
> > > > > place where the RESTAPI is specified, rather we
> > have several
> > > > different
> > > > > places, using several different technologies:
> > > > >
> > > > > * XML schema for the data model.
> > > > > * JAX-RS for part of the operational model
> > (without the
> > > > parameters).
> > > > > * rsdl_metadata.yaml for the parameters of the
> > > operational model.
> > > > >
> > > > > This makes it difficult to infer information
> about the
> > > model. For
> > > > > example, the generators of the SDKs have to
> > download the XML
> > > > schema, and
> > > > > the RSDL (which is generated from the JAX-RS
> > interfaces
> > > using
> > > > reflection
> > > > > and combining it with the information from the
> > > > rsdl_metadata.yaml file)
> > > > > and then they have to do their own
> computations to
> > extract
> > > > what they
> > > > > need.
> > > > >
> > > > > Same happens with the CLI: it has to extract the
> > information
> > > > it needs
>

Re: [ovirt-devel] Requiring Java 8 during runtime

2015-10-27 Thread Tal Nisan 
I agree with Allon, there's no reason to have different version throughout
the modules (again, not including GWT for obvious reasons), there is
practically no harm I can think of in raising the version for all modules
at once

On Tue, Oct 27, 2015 at 10:36 AM, Allon Mureinik 
wrote:

> I think it's a really bad practice to have different modules in the same
> project with different language versions.
>
> For GWT it seems to be required, but for the rest of the backend, I think
> we should have one patch that moves the entire project in one go.
> We can have the various maintainers ack it to show their consent.
>
> On Mon, Oct 26, 2015 at 1:17 PM, Juan Hernández 
> wrote:
>
>> On 10/26/2015 12:05 PM, Martin Mucha wrote:
>> > not strictly related question: are we going to raise language level as
>> well? So we can start using JDK8 features like lambdas etc?
>> >
>> > M.
>> >
>>
>> Shortly after merging that patch I'll merge another one to raise the
>> language level in the RESTAPI:
>>
>>   restapi: Use Java 8 as source and target
>>   https://gerrit.ovirt.org/46288
>>
>> Doing the same in other components is up to their maintainers. I think
>> that should be done everywhere, except where the use of GWT doesn't
>> allow to do it.
>>
>> > - Original Message -
>> >> Hello,
>> >>
>> >> As you probably know oVirt Engine 4 will use WildFly 10, and that
>> >> requires Java 8. The version of WildFly that we currently use is 8.2.1,
>> >> and it can work with both Java 7 and Java 8. In order to ease the
>> >> transition I'm about to merge the following patch, that will require
>> >> Java 8 during runtime:
>> >>
>> >>   core: Require Java 8 during runtime
>> >>   https://gerrit.ovirt.org/46872
>> >>
>> >> The implication of this for you is that you must make sure that you
>> have
>> >> Java 8 installed in the machine where you run your the engine. Fedora
>> 22
>> >> only supports Java 8, so that isn't a problem. EL6 supports both Java 7
>> >> and Java 8, so make sure that you have Java 8 installed:
>> >>
>> >>   yum -y install java-1.8.0-openjdk-devel
>> >>
>> >> If you have objections please speak now, otherwise I will merge the
>> >> patch tomorrow.
>> >>
>> >> Regards,
>> >> Juan Hernandez
>> >>
>> >> --
>> >> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
>> >> 3ºD, 28016 Madrid, Spain
>> >> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat
>> S.L.
>> >> ___
>> >> Devel mailing list
>> >> Devel@ovirt.org
>> >> http://lists.ovirt.org/mailman/listinfo/devel
>> > ___
>> > Devel mailing list
>> > Devel@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>> >
>>
>>
>> --
>> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
>> 3ºD, 28016 Madrid, Spain
>> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

2015-10-27 Thread Martin Betak 




- Original Message -
> From: "Juan Hernández" 
> To: "Roman Mohr" 
> Cc: devel@ovirt.org
> Sent: Tuesday, October 27, 2015 2:41:38 PM
> Subject: Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel
> 
> On 10/27/2015 02:10 PM, Roman Mohr wrote:
> > 
> > 
> > On Tue, Oct 27, 2015 at 1:45 PM, Juan Hernández  > > wrote:
> > 
> > On 10/27/2015 12:55 PM, Roman Mohr wrote:
> > >
> > >
> > > On Tue, Oct 27, 2015 at 12:16 PM, Juan Hernández  > > 
> > > >> wrote:
> > >
> > > On 10/27/2015 11:28 AM, Roman Mohr wrote:
> > > >
> > > >
> > > > On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández
> > > > 
> > >
> > > > 
> >  > > >
> > > > On 10/27/2015 10:16 AM, Roman Mohr wrote:
> > > > >
> > > > >
> > > > > On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández
> > > > > 
> > >
> > > 
> > >>
> > > > > 
> > >
> > > 
> >  wrote:
> > > > >
> > > > > On 10/26/2015 04:56 PM, Roman Mohr wrote:
> > > > > > Hi Juan,
> > > > > >
> > > > > > The way to specify the contract look pretty
> > clean and
> > > nice.
> > > > > > I would love to read a few words about the big
> > > picture. What
> > > > is the
> > > > > > final scenario?
> > > > > >
> > > > >
> > > > > The motivation for this change is that currently we
> > > don't have
> > > > a central
> > > > > place where the RESTAPI is specified, rather we
> > have several
> > > > different
> > > > > places, using several different technologies:
> > > > >
> > > > > * XML schema for the data model.
> > > > > * JAX-RS for part of the operational model
> > (without the
> > > > parameters).
> > > > > * rsdl_metadata.yaml for the parameters of the
> > > operational model.
> > > > >
> > > > > This makes it difficult to infer information about
> > > > > the
> > > model. For
> > > > > example, the generators of the SDKs have to
> > download the XML
> > > > schema, and
> > > > > the RSDL (which is generated from the JAX-RS
> > interfaces
> > > using
> > > > reflection
> > > > > and combining it with the information from the
> > > > rsdl_metadata.yaml file)
> > > > > and then they have to do their own computations to
> > extract
> > > > what they
> > > > > need.
> > > > >
> > > > > Same happens with the CLI: it has to extract the
> > information
> > > > it needs
> > > > > from the Python code generated for the Python SDK,
> > > > > yet
> > > another
> > > > level of
> > > > > indirection.
> > > > >
> > > > >
> > > > > You are right, that definitely needs to be cleaned up. I
> > > just want to
> > > > > discuss a few points below with you.
> > > > >
> > > > >
> > > > >
> > > > > We are also lacking a comprehensive reference
> > > documentation of the
> > > > > RESTAPI. What we currently have has been written by
> > > hand, and
> > > > gets out
> > > > > of sync very quickly, and we don't even notice.
> > > > >
> > > > >
> > > > > Did you also consider swagger? It is made for exactly
> > > > > that
> > > purpose.
> > > > > I created a demo in [1] which uses resteasy, weld,
> > > hibernate-validator
> > > > > and swagger to demonstrate how to do DRY with

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

2015-10-27 Thread Juan Hernández 
On 10/27/2015 02:10 PM, Roman Mohr wrote:
> 
> 
> On Tue, Oct 27, 2015 at 1:45 PM, Juan Hernández  > wrote:
> 
> On 10/27/2015 12:55 PM, Roman Mohr wrote:
> >
> >
> > On Tue, Oct 27, 2015 at 12:16 PM, Juan Hernández  
> > >> wrote:
> >
> > On 10/27/2015 11:28 AM, Roman Mohr wrote:
> > >
> > >
> > > On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández 
> 
> >
> > > 
>  > >
> > > On 10/27/2015 10:16 AM, Roman Mohr wrote:
> > > >
> > > >
> > > > On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández 
> 
> >
> > 
> >>
> > > > 
> >
> > 
>  wrote:
> > > >
> > > > On 10/26/2015 04:56 PM, Roman Mohr wrote:
> > > > > Hi Juan,
> > > > >
> > > > > The way to specify the contract look pretty
> clean and
> > nice.
> > > > > I would love to read a few words about the big
> > picture. What
> > > is the
> > > > > final scenario?
> > > > >
> > > >
> > > > The motivation for this change is that currently we
> > don't have
> > > a central
> > > > place where the RESTAPI is specified, rather we
> have several
> > > different
> > > > places, using several different technologies:
> > > >
> > > > * XML schema for the data model.
> > > > * JAX-RS for part of the operational model
> (without the
> > > parameters).
> > > > * rsdl_metadata.yaml for the parameters of the
> > operational model.
> > > >
> > > > This makes it difficult to infer information about the
> > model. For
> > > > example, the generators of the SDKs have to
> download the XML
> > > schema, and
> > > > the RSDL (which is generated from the JAX-RS
> interfaces
> > using
> > > reflection
> > > > and combining it with the information from the
> > > rsdl_metadata.yaml file)
> > > > and then they have to do their own computations to
> extract
> > > what they
> > > > need.
> > > >
> > > > Same happens with the CLI: it has to extract the
> information
> > > it needs
> > > > from the Python code generated for the Python SDK, yet
> > another
> > > level of
> > > > indirection.
> > > >
> > > >
> > > > You are right, that definitely needs to be cleaned up. I
> > just want to
> > > > discuss a few points below with you.
> > > >
> > > >
> > > >
> > > > We are also lacking a comprehensive reference
> > documentation of the
> > > > RESTAPI. What we currently have has been written by
> > hand, and
> > > gets out
> > > > of sync very quickly, and we don't even notice.
> > > >
> > > >
> > > > Did you also consider swagger? It is made for exactly that
> > purpose.
> > > > I created a demo in [1] which uses resteasy, weld,
> > hibernate-validator
> > > > and swagger to demonstrate how to do DRY with jaxrs.
> > > > Would be great to hear you thoughts on that.
> > > >
> > > > And there is the great swagger-ui [8] to display the
> > documentation
> > > in a
> > > > more human readable way.
> > > >
> > >
> > > Yes, I considered Swagger, and rejected it because it is
> JSON
> > centric,
> > > and I think JSON isn't as good as Java to represent the
> > contracts of our
> > > RESTAPI.
> > >
> > >
> > > You

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

2015-10-27 Thread Roman Mohr 
On Tue, Oct 27, 2015 at 2:41 PM, Juan Hernández  wrote:

> On 10/27/2015 02:10 PM, Roman Mohr wrote:
> >
> >
> > On Tue, Oct 27, 2015 at 1:45 PM, Juan Hernández  > > wrote:
> >
> > On 10/27/2015 12:55 PM, Roman Mohr wrote:
> > >
> > >
> > > On Tue, Oct 27, 2015 at 12:16 PM, Juan Hernández <
> jhern...@redhat.com 
> > > >> wrote:
> > >
> > > On 10/27/2015 11:28 AM, Roman Mohr wrote:
> > > >
> > > >
> > > > On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández <
> jhern...@redhat.com 
> > >
> > > > 
> >  > > >
> > > > On 10/27/2015 10:16 AM, Roman Mohr wrote:
> > > > >
> > > > >
> > > > > On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández <
> jhern...@redhat.com 
> > >
> > > 
> > >>
> > > > > 
> > >
> > > 
> >  wrote:
> > > > >
> > > > > On 10/26/2015 04:56 PM, Roman Mohr wrote:
> > > > > > Hi Juan,
> > > > > >
> > > > > > The way to specify the contract look pretty
> > clean and
> > > nice.
> > > > > > I would love to read a few words about the big
> > > picture. What
> > > > is the
> > > > > > final scenario?
> > > > > >
> > > > >
> > > > > The motivation for this change is that currently we
> > > don't have
> > > > a central
> > > > > place where the RESTAPI is specified, rather we
> > have several
> > > > different
> > > > > places, using several different technologies:
> > > > >
> > > > > * XML schema for the data model.
> > > > > * JAX-RS for part of the operational model
> > (without the
> > > > parameters).
> > > > > * rsdl_metadata.yaml for the parameters of the
> > > operational model.
> > > > >
> > > > > This makes it difficult to infer information about
> the
> > > model. For
> > > > > example, the generators of the SDKs have to
> > download the XML
> > > > schema, and
> > > > > the RSDL (which is generated from the JAX-RS
> > interfaces
> > > using
> > > > reflection
> > > > > and combining it with the information from the
> > > > rsdl_metadata.yaml file)
> > > > > and then they have to do their own computations to
> > extract
> > > > what they
> > > > > need.
> > > > >
> > > > > Same happens with the CLI: it has to extract the
> > information
> > > > it needs
> > > > > from the Python code generated for the Python SDK,
> yet
> > > another
> > > > level of
> > > > > indirection.
> > > > >
> > > > >
> > > > > You are right, that definitely needs to be cleaned up.
> I
> > > just want to
> > > > > discuss a few points below with you.
> > > > >
> > > > >
> > > > >
> > > > > We are also lacking a comprehensive reference
> > > documentation of the
> > > > > RESTAPI. What we currently have has been written by
> > > hand, and
> > > > gets out
> > > > > of sync very quickly, and we don't even notice.
> > > > >
> > > > >
> > > > > Did you also consider swagger? It is made for exactly
> that
> > > purpose.
> > > > > I created a demo in [1] which uses resteasy, weld,
> > > hibernate-validator
> > > > > and swagger to demonstrate how to do DRY with jaxrs.
> > > > > Would be great to hear you thoughts on that.
> > > > >
> > > > > And there is the great swagger-ui [8] to display the
> > > documentation
> > > > in a
> > > > > more human readable way.
> > > > >
>

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

2015-10-27 Thread Roman Mohr 
On Tue, Oct 27, 2015 at 2:41 PM, Juan Hernández  wrote:

> On 10/27/2015 02:10 PM, Roman Mohr wrote:
> >
> >
> > On Tue, Oct 27, 2015 at 1:45 PM, Juan Hernández  > > wrote:
> >
> > On 10/27/2015 12:55 PM, Roman Mohr wrote:
> > >
> > >
> > > On Tue, Oct 27, 2015 at 12:16 PM, Juan Hernández <
> jhern...@redhat.com 
> > > >> wrote:
> > >
> > > On 10/27/2015 11:28 AM, Roman Mohr wrote:
> > > >
> > > >
> > > > On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández <
> jhern...@redhat.com 
> > >
> > > > 
> >  > > >
> > > > On 10/27/2015 10:16 AM, Roman Mohr wrote:
> > > > >
> > > > >
> > > > > On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández <
> jhern...@redhat.com 
> > >
> > > 
> > >>
> > > > > 
> > >
> > > 
> >  wrote:
> > > > >
> > > > > On 10/26/2015 04:56 PM, Roman Mohr wrote:
> > > > > > Hi Juan,
> > > > > >
> > > > > > The way to specify the contract look pretty
> > clean and
> > > nice.
> > > > > > I would love to read a few words about the big
> > > picture. What
> > > > is the
> > > > > > final scenario?
> > > > > >
> > > > >
> > > > > The motivation for this change is that currently we
> > > don't have
> > > > a central
> > > > > place where the RESTAPI is specified, rather we
> > have several
> > > > different
> > > > > places, using several different technologies:
> > > > >
> > > > > * XML schema for the data model.
> > > > > * JAX-RS for part of the operational model
> > (without the
> > > > parameters).
> > > > > * rsdl_metadata.yaml for the parameters of the
> > > operational model.
> > > > >
> > > > > This makes it difficult to infer information about
> the
> > > model. For
> > > > > example, the generators of the SDKs have to
> > download the XML
> > > > schema, and
> > > > > the RSDL (which is generated from the JAX-RS
> > interfaces
> > > using
> > > > reflection
> > > > > and combining it with the information from the
> > > > rsdl_metadata.yaml file)
> > > > > and then they have to do their own computations to
> > extract
> > > > what they
> > > > > need.
> > > > >
> > > > > Same happens with the CLI: it has to extract the
> > information
> > > > it needs
> > > > > from the Python code generated for the Python SDK,
> yet
> > > another
> > > > level of
> > > > > indirection.
> > > > >
> > > > >
> > > > > You are right, that definitely needs to be cleaned up.
> I
> > > just want to
> > > > > discuss a few points below with you.
> > > > >
> > > > >
> > > > >
> > > > > We are also lacking a comprehensive reference
> > > documentation of the
> > > > > RESTAPI. What we currently have has been written by
> > > hand, and
> > > > gets out
> > > > > of sync very quickly, and we don't even notice.
> > > > >
> > > > >
> > > > > Did you also consider swagger? It is made for exactly
> that
> > > purpose.
> > > > > I created a demo in [1] which uses resteasy, weld,
> > > hibernate-validator
> > > > > and swagger to demonstrate how to do DRY with jaxrs.
> > > > > Would be great to hear you thoughts on that.
> > > > >
> > > > > And there is the great swagger-ui [8] to display the
> > > documentation
> > > > in a
> > > > > more human readable way.
> > > > >
>