Re: [openstack-dev] [Horizon] Core Reviewer Update
Great news!!! Welcome. On Wed, Apr 29, 2015 at 11:54 AM, Matthias Runge 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/
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 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, 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] static files handling, bower/
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, 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] REST and Django
a class
> where the url_regex maps to the desired path and gives direct passthrough.
> Maybe that kind of passthrough could always be provided for ease of
> customization / extensibility and additional methods with wrappers provided
> when necessary. I need to leave for today, so can’t actually try that out
> at the moment.
>
> Thanks,
> Travis
>
> From: Thai Q Tran mailto:tqt...@us.ibm.com>>
> Reply-To: OpenStack List openstack-dev@lists.openstack.org>>
> Date: Friday, December 12, 2014 at 11:05 AM
> To: OpenStack List 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}).
> => forward to clients[ver].getattr("method")(**kwargs)> =>
>
> 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 mailto:t.trifo...@gmail.com>>
> wrote: -
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org
> >>
> From: Tihomir Trifonov mailto: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 gues
Re: [openstack-dev] [horizon] REST and Django
gt;views could be supported by just dropping in a new REST API decorated > >module with the APIs you want, including direct pass through support if > >desired to new APIs. Downstream customizations / Upstream changes to > >views seem a bit like a bit of a related, but different issue to me as > >long as their is an easy way to drop in new API support. > > > >Finally, regarding the client making two calls to do an update: > > > >>>Do we really 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 mailto:t.trifo...@gmail.com > >> > >Reply-To: OpenStack List > > openstack-...@lists.openstack.or > >g>> > >Date: Thursday, December 11, 2014 at 7:53 AM > >To: OpenStack List > > 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: > > > > => >/keystone/update/ > => > > > >we may use: > > > > => > > > >=> > > > > > >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 th
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:
=> =>
we may use:
=>
=>
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" (boolean, defaults to true).
Additional, undefined parameters may also be provided, but you'll
have
to look deep into keystone to figure out what they might be.
This method returns HTTP 204 (no content) on success.
"""
project = api.keystone.tenant_get(request, id)
kwargs = _tenant_kwargs_from_DATA(request.DATA, enabled=None)
api.keystone.tenant_update(request, project, **kwargs)
Do we really need the lines:
project = api.keystone.tenant_get(request, id)
kwargs = _tenant_kwargs_from_DATA(request.DATA, enabled=None)
? Since we update the project on the client, it is obvious that we already
fetched the project data. So we can simply send:
POST /keystone/3.0/tenant_update
Content-Type: application/json
{"id": cached.id, "domain_id": cached.domain_id, "name": "new name",
"description": "new description", "enabled": cached.enabled}
Fewer requests, faster application.
On Wed, Dec 10, 2014 at 8:39 PM, Thai Q Tran wrote:
>
>
> I think we're arguing for the same thing, but maybe slightly different
> approach. I think we can both agree that a middle-layer is required,
> whether we intend to use it as a proxy or REST endpoints. Regardless of the
> approach, the client needs to relay what API it wants to invoke, and you
> can do that either via RPC or REST. I personally prefer the REST approach
> because it shields the client. 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. Having said all of that, I do believe we
> should keep it as thin as possible. I do like the idea of having separate
> classes for different API versions. What we have today is a thin REST layer
> that acts like a proxy. You hit a certain URL, and the middle layer
> forwards the API invokation. The only e
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
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
> 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&qu
Re: [openstack-dev] [horizon] REST and Django
;, "Chen, Shaoquan" < >>*sean.ch...@hp.com* >, "Farina, Matt (HP Cloud)" < >>*matthew.far...@hp.com* >, Cindy Lu/Silicon >>Valley/IBM <*c...@us.ibm.com* >, Justin >>Pomeroy/Rochester/IBM <*jpom...@us.ibm.com* >, >>Neill Cox <*neill@ingenious.com.au* > >> * Subject: *Re: REST and Django >> >>I'm not sure whether this is the appropriate place to discuss this, >>or whether I should be posting to the list under [Horizon] but I think we >>need to have a clear idea of what goes in the REST API and what goes in >> the >>client (angular) code. >> >>In my mind, the thinner the REST API the better. Indeed if we can get >>away with proxying requests through without touching any *client code, >> that >>would be great. >> >>Coding additional logic into the REST API means that a developer >>would need to look in two places, instead of one, to determine what was >>happening for a particular call. If we keep it thin then the API presented >>to the client developer is very, very similar to the API presented by the >>services. Minimum surprise. >> >>Your thoughts? >> >> >> Richard >> >> >>On Wed Nov 26 2014 at 2:40:52 PM Richard Jones < >>*r1chardj0...@gmail.com* > wrote: >> >> >> Thanks for the great summary, Travis. >> >> I've completed the work I pledged this morning, so now the REST >> API change set has: >> >> - no rest framework dependency >> - AJAX scaffolding in openstack_dashboard.api.rest.utils >> - code in openstack_dashboard/api/rest/ >> - renamed the API from "identity" to "keystone" to be consistent >> - added a sample of testing, mostly for my own 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* > 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
+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 : > >> 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
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 wrote: > 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
+1 On Thu, Mar 6, 2014 at 5:47 AM, Jason Rist 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
+1 for Tatiana. On Tue, Dec 10, 2013 at 10:24 PM, Lyle, David 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
