Re: [openstack-dev] [Horizon] Core Reviewer Update

2015-04-29 Thread Tihomir Trifonov
Great news!!! Welcome.

On Wed, Apr 29, 2015 at 11:54 AM, Matthias Runge mru...@redhat.com wrote:

 On 29/04/15 00:57, David Lyle wrote:


 Thank you all for your contributions and welcome to the team!

 David


 Yes! Thanks a lot. You'll all make a great addition to the team.

 Matthias


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Regards,
Tihomir Trifonov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [horizon] static files handling, bower/

2015-01-15 Thread Tihomir Trifonov
All we need is to have someone spend some time to make it possible to have
a common meta files(configs, package descriptions, etc.) so that they can
be interchangeable and used by both Bower and pip, e.g. some tool to sync
changes made in one config and adding it to another. Then - whoever prefers
Bower - will use Bower, that's mostly for development, and whoever prefers
pip - will use pip. Ideally, it seems fine to have the static files into
separate git repo(s), as it is now in XStatic.

I'll try to make an (incomplete or maybe not so correct) list of the stages
a static file goes through:

1. Development - all we need is versions of uncompressed js and css files.
We can

On Thu, Jan 15, 2015 at 12:05 AM, david.co...@oracle.com wrote:

 I won't stop to comment on this statement other than to say Javascript is
 quite relevant to Oracle, Oracle's customers, and Oracle's partners.

 Your argument is a boondoggle. Refusing to use node because your favorite
 platform doesn't support it is not the fault of node.js, it's the fault of
 the platform.


 Not to belabor the thread, but yes, of course JavaScript is very
 relevant to Oracle, Solaris, our customers/partners, etc. And that
 includes both client and server-side. As Drew stated, as of this moment
 we haven't yet made Node.js available on SPARC but I expect that to
 change in the future. But the question or potential concern remains as
 to whether adding a non-Python/pip build dependency makes sense.

 I'm not particularly well-versed in the Horizon build process so
 perhaps I'm way off base. But given that a distribution's Horizon build
 package embeds various JavaScript libraries to be used by the browser,
 how those libraries are obtained during the build process is an
 interesting build detail. I thought the intent of the XStatic work was
 to provide Python wrappers around the various JavaScript libraries so
 they could be pulled down via pip. Since there's already a Python
 requirements.txt file for versioning information, that seemed to be a
 nice way of indicating which versions of the JavaScript libraries could
 be used by Horizon and Python was used all the way through the build.

 I realize that it takes work to build the XStatic packages but given
 the Python packages are basically wrappers, it seems creating those and
 uploading them to pypi could be automated by using Bower and setup.py
 but perhaps translating the metadata isn't straightforward.


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Regards,
Tihomir Trifonov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [horizon] static files handling, bower/

2015-01-15 Thread Tihomir Trifonov
Ops, sent the prev mail before finishing it...

1. Development - all we need is versions of uncompressed js and css files.
We can use bower or pip requirements to get specific versions.
2. Testing - we need to do first some 'uglify'-ing tasks, using pyscss or
grunt and to run tests on that. Is is possible to have both configurations
for grunt and pyscss ?
3. Packaging - again - 'uglifyng' some scripts and css to make packages
contain ready for production static files.


This seems like quite work to prepare the whole environment, but will it
work for the needs we have?


On Thu, Jan 15, 2015 at 10:12 AM, Tihomir Trifonov t.trifo...@gmail.com
wrote:

 All we need is to have someone spend some time to make it possible to have
 a common meta files(configs, package descriptions, etc.) so that they can
 be interchangeable and used by both Bower and pip, e.g. some tool to sync
 changes made in one config and adding it to another. Then - whoever prefers
 Bower - will use Bower, that's mostly for development, and whoever prefers
 pip - will use pip. Ideally, it seems fine to have the static files into
 separate git repo(s), as it is now in XStatic.

 I'll try to make an (incomplete or maybe not so correct) list of the
 stages a static file goes through:

 1. Development - all we need is versions of uncompressed js and css files.
 We can

 On Thu, Jan 15, 2015 at 12:05 AM, david.co...@oracle.com wrote:

 I won't stop to comment on this statement other than to say Javascript is
 quite relevant to Oracle, Oracle's customers, and Oracle's partners.

 Your argument is a boondoggle. Refusing to use node because your favorite
 platform doesn't support it is not the fault of node.js, it's the fault
 of
 the platform.


 Not to belabor the thread, but yes, of course JavaScript is very
 relevant to Oracle, Solaris, our customers/partners, etc. And that
 includes both client and server-side. As Drew stated, as of this moment
 we haven't yet made Node.js available on SPARC but I expect that to
 change in the future. But the question or potential concern remains as
 to whether adding a non-Python/pip build dependency makes sense.

 I'm not particularly well-versed in the Horizon build process so
 perhaps I'm way off base. But given that a distribution's Horizon build
 package embeds various JavaScript libraries to be used by the browser,
 how those libraries are obtained during the build process is an
 interesting build detail. I thought the intent of the XStatic work was
 to provide Python wrappers around the various JavaScript libraries so
 they could be pulled down via pip. Since there's already a Python
 requirements.txt file for versioning information, that seemed to be a
 nice way of indicating which versions of the JavaScript libraries could
 be used by Horizon and Python was used all the way through the build.

 I realize that it takes work to build the XStatic packages but given
 the Python packages are basically wrappers, it seems creating those and
 uploading them to pypi could be automated by using Bower and setup.py
 but perhaps translating the metadata isn't straightforward.


 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
 unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Regards,
 Tihomir Trifonov




-- 
Regards,
Tihomir Trifonov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [horizon] REST and Django

2014-12-15 Thread Tihomir Trifonov
 for today, so can’t actually try that out
 at the moment.

 Thanks,
 Travis

 From: Thai Q Tran tqt...@us.ibm.commailto:tqt...@us.ibm.com
 Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:
 openstack-dev@lists.openstack.org
 Date: Friday, December 12, 2014 at 11:05 AM
 To: OpenStack List openstack-dev@lists.openstack.orgmailto:
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [horizon] REST and Django


 In your previous example, you are posting to a certain URL (i.e.
 /keystone/{ver:=x.0}/{method:=update}).
 client: POST /keystone/{ver:=x.0}/{method:=update} = middleware: just
 forward to clients[ver].getattr(method)(**kwargs) = keystone: update

 Correct me if I'm wrong, but it looks like you have a unique URL for each
 /service/version/method.
 I fail to see how that is different than what we have today? Is there a
 view for each service? each version?

 Let's say for argument sake that you have a single view that takes care of
 all URL routing. All requests pass through this view and contain a JSON
 that contains instruction on which API to invoke and what parameters to
 pass.
 And lets also say that you wrote some code that uses reflection to map the
 JSON to an action. What you end up with is a client-centric application,
 where all of the logic resides client-side. If there are things we want to
 accomplish server-side, it will be extremely hard to pull off. Things like
 caching, websocket, aggregation, batch actions, translation, etc What
 you end up with is a client with no help from the server.

 Obviously the other extreme is what we have today, where we do everything
 server-side and only using client-side for binding events. I personally
 prefer a more balance approach where we can leverage both the server and
 client. There are things that client can do well, and there are things that
 server can do well. Going the RPC way restrict us to just client
 technologies and may hamper any additional future functionalities we want
 to bring server-side. In other words, using REST over RPC gives us the
 opportunity to use server-side technologies to help solve problems should
 the need for it arises.

 I would also argue that the REST approach is NOT what we have today. What
 we have today is a static webpage that is generated server-side, where API
 is hidden from the client. What we end up with using the REST approach is a
 dynamic webpage generated client-side, two very different things. We have
 essentially striped out the rendering logic from Django templating and
 replaced it with Angular.


 -Tihomir Trifonov t.trifo...@gmail.commailto:t.trifo...@gmail.com
 wrote: -
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
 
 From: Tihomir Trifonov t.trifo...@gmail.commailto:t.trifo...@gmail.com
 Date: 12/12/2014 04:53AM
 Subject: Re: [openstack-dev] [horizon] REST and Django

 Here's an example: Admin user Joe has an Domain open and stares at it for
 15 minutes while he updates the description. Admin user Bob is asked to go
 ahead and enable it. He opens the record, edits it, and then saves it. Joe
 finished perfecting the description and saves it. Doing this action would
 mean that the Domain is enabled and the description gets updated. Last man
 in still wins if he updates the same fields, but if they update different
 fields then both of their changes will take affect without them stomping on
 each other. Whether that is good or bad may depend on the situation…


 That's a great example. I believe that all of the Openstack APIs support
 PATCH updates of arbitrary fields. This way - the frontend(AngularJS) can
 detect which fields are being modified, and to submit only these fields for
 update. If we however use a form with POST, although we will load the
 object before updating it, the middleware cannot find which fields are
 actually modified, and will update them all, which is more likely what PUT
 should do. Thus having full control in the frontend part, we can submit
 only changed fields. If however a service API doesn't support PATCH, it is
 actually a problem in the API and not in the client...



 The service API documentation almost always lags (although, helped by
 specs now) and the service team takes on the burden of exposing a
 programmatic way to access the API.  This is tested and easily consumable
 via the python clients, which removes some guesswork from using the service.

 True. But what if the service team modifies a method signature from let's
 say:

 def add_something(self, request,
 ​ field1, field2):


 to

 def add_something(self, request,
 ​ field1, field2, field3):


 and in the middleware we have the old signature:

 ​def add_something(self, request,
 ​ field1, field2):

 we still need to modify the middleware to add the new field. If however
 the middleware is transparent and just passes **kwargs, it will pass
 through whatever

Re: [openstack-dev] [horizon] REST and Django

2014-12-12 Thread Tihomir Trifonov
 need the lines:​
 
  project = api.keystone.tenant_get(request, id)
  kwargs = _tenant_kwargs_from_DATA(request.DATA, enabled=None)
 ​
 I agree that if you already have all the data it may be bad to have to do
 another call. I do think there is room for discussing the reasoning,
 though.
 As far as I can tell, they do this so that if you are updating an entity,
 you have to be very specific about the fields you are changing. I
 actually see this as potentially a protectionary measure against data
 loss and sometimes a very nice to have feature. It perhaps was intended
 to *help* guard against race conditions (no locking and no transactions
 with many users simultaneously accessing the data).
 
 Here's an example: Admin user Joe has a Domain open and stares at it for
 15 minutes while he updates just the description. Admin user Bob is asked
 to go ahead and enable it. He opens the record, edits it, and then saves
 it. Joe finished perfecting the description and saves it. They could in
 effect both edit the same domain independently. Last man in still wins if
 he updates the same fields, but if they update different fields then both
 of their changes will take affect without them stomping on each other. Or
 maybe it is intended to encourage client users to compare their current
 and previous to see if they should issue a warning if the data changed
 between getting and updating the data. Or maybe like you said, it is just
 overhead API calls.



 
 From: Tihomir Trifonov t.trifo...@gmail.commailto:t.trifo...@gmail.com
 
 Reply-To: OpenStack List
 openstack-dev@lists.openstack.orgmailto:
 openstack-...@lists.openstack.or
 g
 Date: Thursday, December 11, 2014 at 7:53 AM
 To: OpenStack List
 openstack-dev@lists.openstack.orgmailto:
 openstack-...@lists.openstack.or
 g
 Subject: Re: [openstack-dev] [horizon] REST and Django
 
 ​​
 Client just needs to know which URL to hit in order to invoke a certain
 API, and does not need to know the procedure name or parameters ordering.
 
 
 ​That's where the difference is. I think the client has to know the
 procedure name and parameters. Otherwise​ we have a translation factory
 pattern, that converts one naming convention to another. And you won't be
 able to call any service API if there is no code in the middleware to
 translate it to the service API procedure name and parameters. To avoid
 this - we can use a transparent proxy model - direct mapping of a client
 call to service API naming, which can be done if the client invokes the
 methods with the names in the service API, so that the middleware will
 just pass parameters, and will not translate. Instead of:
 
 
 updating user data:
 
 client: POST /user/=middleware: convert to
 /keystone/update/=   keystone: update
 
 we may use:
 
 client: POST /keystone/{ver:=x.0}/{method:=update}=
 middleware: just forward to clients[ver].getattr(method)(**kwargs) 
 =   keystone: update
 
 
 ​The idea here is that if we have keystone 4.0 client, ​we will have to
 just add it to the clients [] list and nothing more is required at the
 middleware level. Just create the frontend code to use the new Keystone
 4.0 methods. Otherwise we will have to add all new/different signatures
 of 4.0 against 2.0/3.0 in the middleware in order to use Keystone 4.0.
 
 There is also a great example of using a pluggable/new feature in
 Horizon. Do you remember the volume types support patch? The patch was
 pending in Gerrit for few months - first waiting the cinder support for
 volume types to go upstream, then waiting few more weeks for review. I am
 not sure, but as far as I remember, the Horizon patch even missed a
 release milestone and was introduced in the next release.
 
 If we have a transparent middleware - this will be no more an issue. As
 long as someone has written the frontend modules(which should be easy to
 add and customize), and they install the required version of the service
 API - they will not need updated Horizon to start using the feature.
 Maybe I am not the right person to give examples here, but how many of
 you had some kind of Horizon customization being locally merged/patched
 in your local distros/setups, until the patch is being pushed upstream?
 
 I will say it again. Nova, Keystone, Cinder, Glance etc. already have
 stable public APIs. Why do we want to add the translation middleware and
 to introduce another level of REST API? This layer will often hide new
 features, added to the service APIs and will delay their appearance in
 Horizon. That's simply not needed. I believe it is possible to just wrap
 the authentication in the middleware REST, but not to translate anything
 as RPC methods/parameters.
 
 
 ​And one more example:
 
 ​@rest_utils.ajax()
 def put(self, request, id):
 Update a single project.
 
 The POST data should be an application/json object containing the
 parameters to update: name (string),  description (string),
 domain_id (string) and enabled

Re: [openstack-dev] [horizon] REST and Django

2014-12-11 Thread Tihomir Trifonov
 deletions.

 -Tihomir Trifonov t.trifo...@gmail.com wrote: -
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 From: Tihomir Trifonov t.trifo...@gmail.com
 Date: 12/10/2014 03:04AM

 Subject: Re: [openstack-dev] [horizon] REST and Django

 Richard, thanks for the reply,


 I agree that the given example is not a real REST. But we already have the
 REST API - that's Keystone, Nova, Cinder, Glance, Neutron etc, APIs. So
 what we plan to do here? To add a new REST layer to communicate with other
 REST API? Do we really need Frontend-REST-REST architecture ? My opinion is
 that we don't need another REST layer as we currently are trying to go away
 from the Django layer, which is the same - another processing layer.
 Although we call it REST proxy or whatever - it doesn't need to be a real
 REST, but just an aggregation proxy that combines and forwards some
 requests with adding minimal processing overhead. What makes sense for me
 is to keep the authentication in this layer as it is now - push a cookie to
 the frontend, but the REST layer will extract the auth tokens from the
 session storage and prepare the auth context for the REST API request to OS
 services. This way we will not expose the tokens to the JS frontend, and
 will have strict control over the authentication. The frontend will just
 send data requests, they will be wrapped with auth context and forwarded.

 Regarding the existing issues with versions in the API - for me the
 existing approach is wrong. All these fixes were made as workarounds. What
 should have been done is to create abstractions for each version and to use
 a separate class for each version. This was partially done for the
 keystoneclient in api/keystone.py, but not for the forms/views, where we
 still have if-else for versions. What I suggest here is to have
 different(concrete) views/forms for each version, and to use them according
 the context. If the Keystone backend is v2.0 - then in the Frontend use
 keystone2() object, otherwise use keystone3() object. This of course needs
 some more coding, but is much cleaner in terms of customization and
 testing. For me the current hacks with 'if keystone.version == 3.0' are
 wrong at many levels. And this can be solved now. *The problem till now
 was that we had one frontend that had to be backed by different versions of
 backend components*. *Now we can have different frontends that map to
 specific backend*. That's how I understand the power of Angular with it's
 views and directives. That's where I see the real benefit of using
 full-featured frontend. Also imagine how easy will be then to deprecate a
 component version, compared to what we need to do now for the same.

 Otherwise we just rewrite the current Django middleware with another
 DjangoRest middleware and don't change anything, we don't fix the problems.
 We just move them to another place.

 I still think that in Paris we talked about a new generation of the
 Dashboard, a different approach on building the frontend for OpenStack.
 What I've heard there from users/operators of Horizon was that it was
 extremely hard to add customizations and new features to the Dashboard, as
 all these needed to go through upstream changes and to wait until next
 release cycle to get them. Do we still want to address these concerns and
 how? Please, correct me if I got things wrong.


 On Wed, Dec 10, 2014 at 11:56 AM, Richard Jones r1chardj0...@gmail.com
 wrote:

 Sorry I didn't respond to this earlier today, I had intended to.

 What you're describing isn't REST, and the principles of REST are what
 have been guiding the design of the new API so far. I see a lot of value in
 using REST approaches, mostly around clarity of the interface.

 While the idea of a very thin proxy seemed like a great idea at one
 point, my conversations at the summit convinced me that there was value in
 both using the client interfaces present in the openstack_dashboard/api
 code base (since they abstract away many issues in the apis including
 across versions) and also value in us being able to clean up (for example,
 using project_id rather than project in the user API we've already
 implemented) and extend those interfaces (to allow batched operations).

 We want to be careful about what we expose in Horizon to the JS clients
 through this API. That necessitates some amount of code in Horizon. About
 half of the current API for keysone represents that control (the other half
 is docstrings :)


  Richard


 On Tue Dec 09 2014 at 9:37:47 PM Tihomir Trifonov t.trifo...@gmail.com
 wrote:

 Sorry for the late reply, just few thoughts on the matter.

 IMO the REST middleware should be as thin as possible. And I mean thin
 in terms of processing - it should not do pre/post processing of the
 requests, but just unpack/pack. So here is an example:

 instead of making AJAX calls that contain instructions:

 ​​
 POST --json --data {action: delete, data

Re: [openstack-dev] [horizon] REST and Django

2014-12-10 Thread Tihomir Trifonov
Richard, thanks for the reply,


I agree that the given example is not a real REST. But we already have the
REST API - that's Keystone, Nova, Cinder, Glance, Neutron etc, APIs. So
what we plan to do here? To add a new REST layer to communicate with other
REST API? Do we really need Frontend-REST-REST architecture ? My opinion is
that we don't need another REST layer as we currently are trying to go away
from the Django layer, which is the same - another processing layer.
Although we call it REST proxy or whatever - it doesn't need to be a real
REST, but just an aggregation proxy that combines and forwards some
requests with adding minimal processing overhead. What makes sense for me
is to keep the authentication in this layer as it is now - push a cookie to
the frontend, but the REST layer will extract the auth tokens from the
session storage and prepare the auth context for the REST API request to OS
services. This way we will not expose the tokens to the JS frontend, and
will have strict control over the authentication. The frontend will just
send data requests, they will be wrapped with auth context and forwarded.

Regarding the existing issues with versions in the API - for me the
existing approach is wrong. All these fixes were made as workarounds. What
should have been done is to create abstractions for each version and to use
a separate class for each version. This was partially done for the
keystoneclient in api/keystone.py, but not for the forms/views, where we
still have if-else for versions. What I suggest here is to have
different(concrete) views/forms for each version, and to use them according
the context. If the Keystone backend is v2.0 - then in the Frontend use
keystone2() object, otherwise use keystone3() object. This of course needs
some more coding, but is much cleaner in terms of customization and
testing. For me the current hacks with 'if keystone.version == 3.0' are
wrong at many levels. And this can be solved now. *The problem till now was
that we had one frontend that had to be backed by different versions of
backend components*. *Now we can have different frontends that map to
specific backend*. That's how I understand the power of Angular with it's
views and directives. That's where I see the real benefit of using
full-featured frontend. Also imagine how easy will be then to deprecate a
component version, compared to what we need to do now for the same.

Otherwise we just rewrite the current Django middleware with another
DjangoRest middleware and don't change anything, we don't fix the problems.
We just move them to another place.

I still think that in Paris we talked about a new generation of the
Dashboard, a different approach on building the frontend for OpenStack.
What I've heard there from users/operators of Horizon was that it was
extremely hard to add customizations and new features to the Dashboard, as
all these needed to go through upstream changes and to wait until next
release cycle to get them. Do we still want to address these concerns and
how? Please, correct me if I got things wrong.


On Wed, Dec 10, 2014 at 11:56 AM, Richard Jones r1chardj0...@gmail.com
wrote:

 Sorry I didn't respond to this earlier today, I had intended to.

 What you're describing isn't REST, and the principles of REST are what
 have been guiding the design of the new API so far. I see a lot of value in
 using REST approaches, mostly around clarity of the interface.

 While the idea of a very thin proxy seemed like a great idea at one point,
 my conversations at the summit convinced me that there was value in both
 using the client interfaces present in the openstack_dashboard/api code
 base (since they abstract away many issues in the apis including across
 versions) and also value in us being able to clean up (for example, using
 project_id rather than project in the user API we've already
 implemented) and extend those interfaces (to allow batched operations).

 We want to be careful about what we expose in Horizon to the JS clients
 through this API. That necessitates some amount of code in Horizon. About
 half of the current API for keysone represents that control (the other half
 is docstrings :)


  Richard


 On Tue Dec 09 2014 at 9:37:47 PM Tihomir Trifonov t.trifo...@gmail.com
 wrote:

 Sorry for the late reply, just few thoughts on the matter.

 IMO the REST middleware should be as thin as possible. And I mean thin in
 terms of processing - it should not do pre/post processing of the requests,
 but just unpack/pack. So here is an example:

 instead of making AJAX calls that contain instructions:

 ​​
 POST --json --data {action: delete, data: [ {name:
 item1}, {name: item2}, {name: item3 ]}


 I think a better approach is just to pack/unpack batch commands, and
 leave execution to the frontend/backend and not middleware:


 ​​
 POST --json --data {
 ​batch
 :
 ​[
 {​
 
 ​
 action
 ​ : delete​
 ,
 ​payload: ​
 {name: item1}
 ​,
 {​
 
 ​
 action
 ​ : delete​
 ,
 ​
 payload

Re: [openstack-dev] [horizon] REST and Django

2014-12-09 Thread Tihomir Trifonov
 sanity to check
   things were working

   *https://review.openstack.org/#/c/136676*
   https://review.openstack.org/#/c/136676


 Richard

   On Wed Nov 26 2014 at 12:18:25 PM Tripp, Travis S 
   *travis.tr...@hp.com* travis.tr...@hp.com wrote:


 Hello all,

  Great discussion on the REST urls today! I think that we are on
  track to come to a common REST API usage pattern.  To provide quick 
 summary:

  We all agreed that going to a straight REST pattern rather than
  through tables was a good idea. We discussed using direct get / 
 post in
  Django views like what Max originally used[1][2] and Thai also 
 started[3]
  with the identity table rework or to go with djangorestframework 
 [5] like
  what Richard was prototyping with[4].

  The main things we would use from Django Rest Framework were
  built in JSON serialization (avoid boilerplate), better exception 
 handling,
  and some request wrapping.  However, we all weren’t sure about the 
 need for
  a full new framework just for that. At the end of the conversation, 
 we
  decided that it was a cleaner approach, but Richard would see if he 
 could
  provide some utility code to do that much for us without requiring 
 the full
  framework.  David voiced that he doesn’t want us building out a 
 whole
  framework on our own either.

  So, Richard will do some investigation during his day today and
  get back to us.  Whatever the case, we’ll get a patch in horizon 
 for the
  base dependency (framework or Richard’s utilities) that both Thai’s 
 work
  and the launch instance work is dependent upon.  We’ll build REST 
 style
  API’s using the same pattern.  We will likely put the rest api’s in
  horizon/openstack_dashboard/api/rest/.

  [1]
  
 *https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/keypair.py*
  
 https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/keypair.py
  [2]
  
 *https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/launch.py*
  
 https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/launch.py
  [3]
  
 *https://review.openstack.org/#/c/133767/8/openstack_dashboard/dashboards/identity/users/views.py*
  
 https://review.openstack.org/#/c/133767/8/openstack_dashboard/dashboards/identity/users/views.py
  [4]
  
 *https://review.openstack.org/#/c/136676/4/openstack_dashboard/rest_api/identity.py*
  
 https://review.openstack.org/#/c/136676/4/openstack_dashboard/rest_api/identity.py
  [5] *http://www.django-rest-framework.org/*
  http://www.django-rest-framework.org/

  Thanks,


 Travis___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org

  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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



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



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




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


Re: [openstack-dev] [Horizon] Nominations to Horizon Core

2014-06-24 Thread Tihomir Trifonov
+1
+1

Deserved.


On Tue, Jun 24, 2014 at 10:41 AM, Tatiana Ovtchinnikova 
t.v.ovtchinnik...@gmail.com wrote:

 +1 and +1
 Thank you Ana and Zhenguo!

 --
 Kind regards,
 Tatiana


 2014-06-21 1:17 GMT+04:00 Lyle, David david.l...@hp.com:

 I would like to nominate Zhenguo Niu and Ana Krivokapic to Horizon core.

 Zhenguo has been a prolific reviewer for the past two releases providing
 high quality reviews. And providing a significant number of patches over
 the past three releases.

 Ana has been a significant reviewer in the Icehouse and Juno release
 cycles. She has also contributed several patches in this timeframe to both
 Horizon and tuskar-ui.

 Please feel free to respond in public or private your support or any
 concerns.

 Thanks,
 David



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



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




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


Re: [openstack-dev] [horizon][infra] Plan for the splitting of Horizon into two repositories

2014-05-29 Thread Tihomir Trifonov
Hi Gabriel,

thanks for joining the conversation. It is a quite old discussion that was
also discussed at the Atlanta design summit, and it seems that the moment
this to happen had finally come. It is always nice to hear the opinion of a
real Django core developer.

Just a follow-up from the discussions in Atlanta for those who didn't
attend - as long as there are some new Web UI projects in OpenStack, it is
a good reason to make a common web framework that to be used for all
projects(something like a common layer on top of Django, to be used from
different projects), which will need to only add their custom logic and
views. Currently there is a lot of duplicate and similar code in different
projects that could be unified. Also this will make it very easy to add new
openstack-related dashboard sites, keeping it consistent to other sites,
hence easier contribution from other project developers.

Back on the naming thing - since Horizon from the very beginning keeps the
common files(base templates and scripts), isn't it better to keep it's
name?. Since Horizon is the base on which the different Dashboard
projects will be built over, I'd propose a kind of broader naming concept -
what comes on the horizon? A *Rainbow*? A *Storm*? This would allow the
easy selection of new names when needed, and all will be related to Horizon
in some way. I'm not sure if this makes sense, but I personally like when
project names have something in common :)

About the plan - it seems reasonable for me, count me in for the big rush.



On Wed, May 28, 2014 at 11:03 PM, Gabriel Hurley
gabriel.hur...@nebula.comwrote:

 It's sort of a silly point, but as someone who would likely consume the
 split-off package outside of the OpenStack context, please give it a proper
 name instead of django_horizon. The module only works in Django, the name
 adds both clutter and confusion, and it's against the Django community's
 conventions to have the python import name be prefixed with django_.

 If the name horizon needs to stay with the reference implementation of
 the dashboard rather than keeping it with the framework as-is that's fine,
 but choose a new real name for the framework code.

 Just to get the ball rolling, and as a nod to the old-timers, I'll propose
 the runner up in the original naming debate: bourbon. ;-)

 If there are architectural questions I can help with in this process let
 me know. I'll try to keep an eye on the progress as it goes.

 All the best,

- Gabriel

  -Original Message-
  From: Radomir Dopieralski [mailto:openst...@sheep.art.pl]
  Sent: Wednesday, May 28, 2014 5:55 AM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: [openstack-dev] [horizon][infra] Plan for the splitting of
 Horizon into
  two repositories
 
  Hello,
 
  we plan to finally do the split in this cycle, and I started some
 preparations for
  that. I also started to prepare a detailed plan for the whole operation,
 as it
  seems to be a rather big endeavor.
 
  You can view and amend the plan at the etherpad at:
  https://etherpad.openstack.org/p/horizon-split-plan
 
  It's still a little vague, but I plan to gradually get it more detailed.
  All the points are up for discussion, if anybody has any good ideas or
  suggestions, or can help in any way, please don't hesitate to add to this
  document.
 
  We still don't have any dates or anything -- I suppose we will work that
 out
  soonish.
 
  Oh, and great thanks to all the people who have helped me so far with
 it, I
  wouldn't even dream about trying such a thing without you. Also thanks in
  advance to anybody who plans to help!
 
  --
  Radomir Dopieralski
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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




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


Re: [openstack-dev] [Horizon] Nominating Radomir Dopieralski to Horizon Core

2014-03-05 Thread Tihomir Trifonov
+1


On Thu, Mar 6, 2014 at 5:47 AM, Jason Rist jr...@redhat.com wrote:

 On Wed 05 Mar 2014 03:36:22 PM MST, Lyle, David wrote:
  I'd like to nominate Radomir Dopieralski to Horizon Core.  I find his
 reviews very insightful and more importantly have come to rely on their
 quality. He has contributed to several areas in Horizon and he understands
 the code base well.  Radomir is also very active in tuskar-ui both
 contributing and reviewing.
 
  David
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 As someone who benefits from his insightful reviews, I second the
 nomination.

 --
 Jason E. Rist
 Senior Software Engineer
 OpenStack Management UI
 Red Hat, Inc.
 +1.720.256.3933
 Freenode: jrist
 github/identi.ca: knowncitizen

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




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


Re: [openstack-dev] [Horizon] Nominations to Horizon Core

2013-12-10 Thread Tihomir Trifonov
+1 for Tatiana.


On Tue, Dec 10, 2013 at 10:24 PM, Lyle, David david.l...@hp.com wrote:

 I would like to nominate Tatiana Mazur to Horizon Core.  Tatiana has been
 a significant code contributor in the last two releases, understands the
 code base well and has been doing a significant number of reviews for the
 last to milestones.


 Additionally, I'd like to remove some inactive members of Horizon-core who
 have been inactive since the early Grizzly release at the latest.
 Devin Carlen
 Jake Dahn
 Jesse Andrews
 Joe Heck
 John Postlethwait
 Paul McMillan
 Todd Willey
 Tres Henry
 paul-tashima
 sleepsonthefloor


 Please respond with a +1/-1 by this Friday.

 -David Lyle




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




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