Re: [openstack-dev] [horizon] Javascript development improvement
On 20/11/13 17:01 +0100, Maxime Vidori wrote: Hi all, I know it is pretty annoying but I have to resurrect this subject. With the integration of Angularjs into Horizon we will encounter a lot of issues with javascript. I ask you to reconsider to bring back Nodejs as a development platform. I am not talking about production, we are all agree that Node is not ready for production, and we do not want it as a backend. But the facts are that we need a lot of its features, which will increase the tests and the development. Currently, we do not have any javascript code quality: jslint is a great tool and can be used easily into node. Angularjs also provides end-to-end testing based on nodejs again, testing is important especially if we start to put more logic into JS. Selenium is used just to run qUnit tests, we can bring back these tests into node and have a clean unified testing platform. Tests will be easier to perform. Finally, (do not punch me in the face) lessc which is used for bootstrap is completely integrated into it. I am afraid that modern javascript development can not be perform without this tool. +1 / I will not punch you in the face It'd be nice to add in the modern angular testing model, karma / jasmine, and my JS can *DEFINITELY* use jslint :) -- Jordan O'Mara Red Hat Engineering, Raleigh pgpLgesTBFHZT.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Javascript development improvement
On 22/11/13 12:06 -0500, Julie Pichon wrote: I don't think Selenium is going away, and efforts have started around using it as well for our integration tests [0]. Looking at the current AngularJS patch up for review, it is testable without requiring NodeJS. While the Angular modules are testable in QUnit, it would be a boon to use the testing patterns common with most Angular projects. It would make new developers, familiar with Angular but not Horizon, immediately familiar with the workflow. QUnit is acceptable, but karma/jasmine is preferable From the initial mailing list discussion [1], my understanding is that we're planning on using a specific AngularJS feature, not rewriting everything with it. Changing our build system to accommodate this seems like getting a bit ahead of ourselves. [1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/018850.html To be clear, we're using a specific feature of Angular (the directive) to introduce it into the existing Django templates; that's not the only feature of Angular we're using. There are controllers & services behind the directive, but using a directive is the cleanest way of integrating these features with the existing templates. -- Jordan O'Mara Red Hat Engineering, Raleigh pgpVLkAm0WvI6.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Summit session wrapup
On 01/12/13 00:27 -0500, Tzu-Mainn Chen wrote: I think we may all be approaching the planning of this project in the wrong way, because of confusions such as: Well, I think there is one small misunderstanding. I've never said that manual way should be primary workflow for us. I agree that we should lean toward as much automation and smartness as possible. But in the same time, I am adding that we need manual fallback for user to change that smart decision. Primary way would be to let TripleO decide, where the stuff go. I think we agree here. That's a pretty fundamental requirement that both sides seem to agree upon - but that agreement got lost in the discussions of what feature should come in which release, etc. That seems backwards to me. I think it's far more important that we list out requirements and create a design document that people agree upon first. Otherwise, we run the risk of focusing on feature X for release 1 without ensuring that our architecture supports feature Y for release 2. To make this example more specific: it seems clear that everyone agrees that the current Tuskar design (where nodes must be assigned to racks, which are then used as the primary means of manipulation) is not quite correct. Instead, we'd like to introduce a philosophy where we assume that users don't want to deal with homogeneous nodes individually, instead letting TripleO make decisions for them. I agree; getting buy-in on a design document up front is going to save us future anguish Regarding this - I think we may want to clarify what the purpose of our releases are at the moment. Personally, I don't think our current planning is about several individual product releases that we expect to be production-ready and usable by the world; I think it's about milestone releases which build towards a more complete product. From that perspective, if I were a prospective user, I would be less concerned with each release containing exactly what I need. Instead, what I would want most out of the project is: a) frequent stable releases (so I can be comfortable with the pace of development and the quality of code) b) design documentation and wireframes (so I can be comfortable that the architecture will support features I need) c) a roadmap (so I have an idea when my requirements will be met) +1 -- Jordan O'Mara Red Hat Engineering, Raleigh pgp7rupTEuBS0.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tripleo] Core reviewer update Dec
On 04/12/13 12:07 +0100, Jiri Tomasek wrote: Hi, As the development of Tuskar-UI somehow stagnated recently, I have been focusing more on Horizon project lately to get features we need for Tuskar-UI. I acknowledge that I haven't been paying enough attention and reviews in TripleO. The statistics says it all. Although as the development of Tuskar-UI is about to rise rapidly, it would be nice to be able to give +2's here. I'll try to get up to speed with TripleO together with upcoming Tuskar-UI changes. Jirka I'm in exactly the same boat -- Jordan O'Mara Red Hat Engineering, Raleigh pgpNoVY5J4YkJ.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Less compiler dependency
On 10/12/13 16:41 +0100, Jiri Tomasek wrote: On 12/09/2013 12:47 PM, Jaromir Coufal wrote: Hey all Horizoners, This is last time I am trying to bring this concern up (well at least last time for a while :)). But... Watching latest progress with updating Bootstrap to v3 and dealing with compiling issues, I am more and more concerned about dependency on lesscpy. Currently the library supports only some features of less. It is very small and very young project, containing one or two maintainers. We are already waiting couple of months so that we can update to Bootstrap 3 because of this dependency. And all of these problems will not disappear once we update Bootstrap. Because the library will support certain use cases but when Horizon will grow we will use more advanced features which the library will not have covered. And we will be blocked by the same issue over and over again. So I would like to ask everybody, if we can reconsider this dependency and find some other alternative. I know we moved from nodejs, because it is packaging nightmare. But honestly, better to invest more into packaging than being blocked months waiting for features we need to get in. If we find some alternative for both, it is win for us. But current situation is making me nervous. Thanks -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hi all, So in IRC discussion we agreed to try 3 approaches how to resolve the problem: 1/ Try to dive into Lesscpy and help with making it support Bootstrap 3 (and gradually all less features), subsequently keep it up to date. 2/ Investigate using lessc with other js engine than nodejs (eg. Rhino) Rhino is written in Java and thus requires a JRE as a dependency for LESS compilation. I don't see how this is any better than requiring NodeJS as a build time dependency, when NodeJS buys us a lot of other features for css/js and Rhino does not. I'm currently checking out PhantomJS, which only requires coffeescript, but I'm hesistant to suggest a complex workaround when better options are available. 3/ Have production and development environment in Horizon, where development includes nodejs, release compiled css as well as less files. The styling customization would then require user to recompile stylesheets with his changes. On the other hand we'd have nodejs present in development envitonment and be able to use other tools that require it. I like the idea of having a default development mode that's a little more supportive for developers, including not-automatically-compiling your JS/CSS so you can debug it. -- Jordan O'Mara Red Hat Engineering, Raleigh pgpR4adabFn2Y.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Less compiler dependency
On 11/12/13 01:06 +0800, Thomas Goirand wrote: On 12/10/2013 11:41 PM, Jiri Tomasek wrote: On 12/09/2013 12:47 PM, Jaromir Coufal wrote: So I would like to ask everybody, if we can reconsider this dependency and find some other alternative. I know we moved from nodejs, because it is packaging nightmare. But honestly, better to invest more into packaging than being blocked months waiting for features we need to get in. I don't agree, because ... I'll be doing the work! :) More seriously, we are much better off NodeJS, and keep everything in Python. So in IRC discussion we agreed to try 3 approaches how to resolve the problem: 1/ Try to dive into Lesscpy and help with making it support Bootstrap 3 (and gradually all less features), subsequently keep it up to date. That'd be great. 3/ Have production and development environment in Horizon, where development includes nodejs, release compiled css as well as less files. The styling customization would then require user to recompile stylesheets with his changes. On the other hand we'd have nodejs present in development envitonment and be able to use other tools that require it. With all due respect, this is a very bad idea. If by this, you mean that the release tarballs would ship some pre-compiled-in files instead of the original source files, then you are effectively making Horizon non-free, and non suitable for Debian main. If you want to ship both, then you may as well discard the already pre-compiled files, because a package maintainer will never use them. At least in Debian, we are *required* to always use the "preferred form for modification", whatever that is. This means the package will have to use NodeJS and the "development environment" in the build process. So then we're back to square one, with a NodeJS packaging nightmare. You'd better directly go back to the idea of using NodeJS then, because that would be exactly the same. I'm a bit newer to this conversation than some, but I'm not sure what exactly the "NodeJS packaging nightmare" is? Isn't it already packaged for many major distributions? -- Jordan O'Mara Red Hat Engineering, Raleigh pgpBRgDAsm8Q0.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Terminology
On 11/12/13 14:15 -0500, Tzu-Mainn Chen wrote: Hi, I'm trying to clarify the terminology being used for Tuskar, which may be helpful so that we're sure that we're all talking about the same thing :) I'm copying responses from the requirements thread and combining them with current requirements to try and create a unified view. Hopefully, we can come to a reasonably rapid consensus on any desired changes; once that's done, the requirements can be updated. * NODE a physical general purpose machine capable of running in many roles. Some nodes may have hardware layout that is particularly useful for a given role. * REGISTRATION - the act of creating a node in Ironic * ROLE - a specific workload we want to map onto one or more nodes. Examples include 'undercloud control plane', 'overcloud control plane', 'overcloud storage', 'overcloud compute' etc. * MANAGEMENT NODE - a node that has been mapped with an undercloud role * SERVICE NODE - a node that has been mapped with an overcloud role * COMPUTE NODE - a service node that has been mapped to an overcloud compute role * CONTROLLER NODE - a service node that has been mapped to an overcloud controller role * OBJECT STORAGE NODE - a service node that has been mapped to an overcloud object storage role * BLOCK STORAGE NODE - a service node that has been mapped to an overcloud block storage role * UNDEPLOYED NODE - a node that has not been mapped with a role * another option - UNALLOCATED NODE - a node that has not been allocated through nova scheduler (?) - (after reading lifeless's explanation, I agree that "allocation" may be a misleading term under TripleO, so I personally vote for UNDEPLOYED) * INSTANCE - A role deployed on a node - this is where work actually happens. * DEPLOYMENT * SIZE THE ROLES - the act of deciding how many nodes will need to be assigned to each role * another option - DISTRIBUTE NODES (?) - (I think the former is more accurate, but perhaps there's a better way to say it?) * SCHEDULING - the process of deciding which role is deployed on which node * SERVICE CLASS - a further categorization within a service role for a particular deployment. * NODE PROFILE - a set of requirements that specify what attributes a node must have in order to be mapped to a service class Does this seem accurate? All feedback is appreciated! Mainn Thanks for doing this! Presumably this is going to go on a wiki where we can look at it forever and ever? -- Jordan O'Mara Red Hat Engineering, Raleigh pgpn_aW3DEuC0.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones
On 13/12/13 11:36 +0100, Jaromir Coufal wrote: *VERSION 0* === Enable user to deploy OpenStack with the simpliest TripleO way, no difference between hardware. Target: - end of icehouse-2 Features we need to get in: - Enable manual nodes registration (Ironic) - Get images available for user (Glance) - Node roles (hardcode): Controller, Compute, Object Storage, Block Storage - Design deployment (number of nodes per role) - Deploy (Heat + Nova) Thanks for summarizing this Jarda! I noticed one thing missing from the V0 list that we had talked about earlier that seemed important. Copied below from an earlier doc: retrieve node lists (Ironic + Nova + Heat?) management node(s) (awareness of the node) resource nodes, broken down by role unallocated nodes This seems also important to include in v0. -- Jordan O'Mara Red Hat Engineering, Raleigh pgpgJlPGEy1Tc.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Terminology
On 13/12/13 16:20 +1300, Robert Collins wrote: On 12 December 2013 21:59, Jaromir Coufal wrote: On 2013/12/12 01:21, Robert Collins wrote: Avoiding cloud - ack. However, on instance - 'instance' is a very well defined term in Nova and thus OpenStack: Nova boot gets you an instance, nova delete gets rid of an instance, nova rebuild recreates it, etc. Instances run [virtual|baremetal] machines managed by a hypervisor. So nova-scheduler is not ever going to be confused with instance in the OpenStack space IMO. But it brings up a broader question, which is - what should we do when terms that are well defined in OpenStack - like Node, Instance, Flavor - are not so well defined for new users? We could use different terms, but that may confuse 'stackers, and will mean that our UI needs it's own dedicated terminology to map back to e.g. the manuals for Nova and Ironic. I'm inclined to suggest that as a principle, where there is a well defined OpenStack concept, that we use it, even if it is not ideal, because the consistency will be valuable. I think this is a really important point. I think the consistency is a powerful tool for teaching new users how they should expect tripleo/tuskar to work and should lessen the learning curve, as long they've used openstack before. -- Jordan O'Mara Red Hat Engineering, Raleigh pgpvsMEMEL94Z.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support
On 30/01/14 16:14 -0500, Tzu-Mainn Chen wrote: Thanks for the reply! So if I understand correctly, the proposal is for: Icehouse: one flavor per service role, so nodes are homogeneous per role J: multiple flavors per service role That sounds reasonable; the part that gives me pause is when you talk about handling variations in hardware by registering the nodes as equal. If those differences vanish, then won't there be problems in the future when we might be able to properly handle those variations? Or do you propose that we only allow minor variations to be registered as equal, so that the UI has to understand the concept of minor variances? Back to your original point, the idea of "are we going to allow" seems fraught with peril. Do we have some kind of tolerance for what hardware the user is allowed to register after they register their first one? This sounds like a recipe for user frustration Mainn ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Jordan O'Mara Red Hat Engineering, Raleigh pgpYmCvfhgVO3.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Installation instructions
On 21/05/14 14:31 -0600, Jason Rist wrote: Some of us do instack: https://github.com/slagle/instack There are some really detailed instructions on running instack with RDO, if that is your weapon of choice: http://openstack.redhat.com/Deploying_RDO_using_Instack -- Jordan O'Mara Red Hat Engineering, Raleigh pgpKz3qO8cE0s.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup
On 10/06/14 17:15 +1200, Robert Collins wrote: That seems pretty solid reasoning; +1 from me no July 21-25th; I know not everyone can attend - but with the size of the team every situation will have some folk that can't play. What do we need to do to lock this in to RedHat's venue schedule? -Rob I'm working on this now, I'll keep the etherpad updated with information as I get it. -- Jordan O'Mara Red Hat Engineering, Raleigh pgpQkEc5lUzvQ.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] reviewer update march
On 04/04/14 00:02 +1300, Robert Collins wrote: Getting back in the swing of things... Hi, like most OpenStack projects we need to keep the core team up to date: folk who are not regularly reviewing will lose context over time, and new folk who have been reviewing regularly should be trusted with -core responsibilities. In this months review: - Jordan O'Mara for removal from -core +1 : focused on horizon/tuskar-ui features now -- Jordan O'Mara Red Hat Engineering, Raleigh pgpmywKzp7CMb.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] Reminder: Mid-cycle Meetup - Attendance Confirmation
On 20/06/14 16:26 -0400, Charles Crouch wrote: Any more takers for the tripleo mid-cycle meetup in Raleigh? If so, please sign up on the etherpad below. The hotel group room rate will be finalized on Monday Jul 23rd (US time), after that time you will be on your own for finding accommodation. Thanks Charles Just an update that I've got us a block of rooms reserved at the nearest, cheapest hotel (the Marriott in downtown Raleigh, about 200 yards from the Red Hat office) - I'll have details on how to actually book at this rate in just a few minutes. -- Jordan O'Mara Red Hat Engineering, Raleigh pgpz8FNkWvGI5.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] Reminder: Mid-cycle Meetup - Attendance Confirmation
On 24/06/14 10:55 -0400, Jordan OMara wrote: On 20/06/14 16:26 -0400, Charles Crouch wrote: Any more takers for the tripleo mid-cycle meetup in Raleigh? If so, please sign up on the etherpad below. The hotel group room rate will be finalized on Monday Jul 23rd (US time), after that time you will be on your own for finding accommodation. Thanks Charles Just an update that I've got us a block of rooms reserved at the nearest, cheapest hotel (the Marriott in downtown Raleigh, about 200 yards from the Red Hat office) - I'll have details on how to actually book at this rate in just a few minutes. Please use the following link to reserve at the marriott (it's copied on the etherpad) http://tinyurl.com/redhat-marriott We have a 24-room block reserved at that rate from SUN-FRI -- Jordan O'Mara Red Hat Engineering, Raleigh pgp1uiWMlmgmN.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] Reminder: Mid-cycle Meetup - Attendance Confirmation
On 25/06/14 18:20 +, Carlino, Chuck (OpenStack TripleO, Neutron) wrote: Is $179/day the expected rate? Thanks, Chuck Yes, that's the best rate available from both of the downtown (walkable) hotels. -- Jordan O'Mara Red Hat Engineering, Raleigh pgpq2YbXSIITm.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] Reminder: Mid-cycle Meetup - Attendance Confirmation
On 25/06/14 14:32 -0400, Jordan OMara wrote: On 25/06/14 18:20 +, Carlino, Chuck (OpenStack TripleO, Neutron) wrote: Is $179/day the expected rate? Thanks, Chuck Yes, that's the best rate available from both of the downtown (walkable) hotels. Just an update that we only have a few rooms left in our block at the Marriott. Please book ASAP if you haven't -- Jordan O'Mara Red Hat Engineering, Raleigh pgplWdMerEsnR.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] Reminder: Mid-cycle Meetup - Attendance Confirmation
On 30/06/14 13:02 -0400, Jordan OMara wrote: On 25/06/14 14:32 -0400, Jordan OMara wrote: On 25/06/14 18:20 +, Carlino, Chuck (OpenStack TripleO, Neutron) wrote: Is $179/day the expected rate? Thanks, Chuck Yes, that's the best rate available from both of the downtown (walkable) hotels. Just an update that we only have a few rooms left in our block at the Marriott. Please book ASAP if you haven't Final reminder: our group rate expires tomorrow! -- Jordan O'Mara Red Hat Engineering, Raleigh pgpu8uLlRZ1iW.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] TripleO core reviewer update - november
On 30/10/13 18:16 +, Joe Gordon wrote: On Oct 30, 2013 9:10 AM, "Robert Collins" wrote: Hi, like most OpenStack projects we need to keep the core team up to date: folk who are not regularly reviewing will lose context over time, and new folk who have been reviewing regularly should be trusted with -core responsibilities. In this months review: - James Slagle for -core +1 - Arata Notsu to be removed from -core +1 - Devananda van der veen to be removed from -core +1 Existing -core members are eligible to vote - please indicate your opinion on each of the three changes above in reply to this email. -- Jordan O'Mara Red Hat Engineering, Raleigh pgpPi39jmD_dK.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] Introduction of AngularJS in membership workflow
Hello Horizon! On November 11th, we submitted a patch to introduce AngularJS into Horizon [1]. We believe AngularJS adds a lot of value to Horizon. First, AngularJS allows us to write HTML templates for interactive elements instead of doing jQuery-based DOM manipulation. This allows the JavaScript layer to focus on business logic, provides easy to write JavaScript testing that focuses on the concern (e.g. business logic, template, DOM manipulation), and eases the on-boarding for new developers working with the JavaScript libraries. Second, AngularJS is not an all or nothing solution and integrates with the existing Django templates. For each feature that requires JavaScript, we can write a self-contained directive to handle the DOM, a template to define our view and a controller to contain the business logic. Then, we can add this directive to the existing template. To see an example in action look at _workflow_step_update_member.html [2]. It can also be done incrementally - this isn't an all-or-nothing approach with a massive front-end time investment, as the Angular components can be introduced over time. Finally, the initial work to bring AngularJS to Horizon provides a springboard to remove the "DOM Database" (i.e. hidden-divs) used on the membership page (and others). Instead of abusing the DOM, we can instead expose an API for membership data, add an AngularJS resource (i.e. reusable representation of API entities) for the API. The data can then be loaded data asynchronously and allow the HTML to focus on expressing a semantic representation of the data to the user. Please give our patch a try! You can find the interactions on Domains/Groups, Flavors/Access(this form does not seem to work in current master or on my patch) and Projects/Users&Groups. You should notice that it behaves...exactly the same! We look forward to your feedback. Jordan O'Mara & Jirka Tomasek [1] [https://review.openstack.org/#/c/55901/] [2] [https://github.com/jsomara/horizon/blob/angular2/horizon/templates/horizon/common/_workflow_step_update_members.html] -- Jordan O'Mara Red Hat Engineering, Raleigh pgpZe8F1BKZYs.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Introduction of AngularJS in membership workflow
On 13/11/13 11:47 +0100, Jiri Tomasek wrote: On 11/13/2013 11:20 AM, Maxime Vidori wrote: Hi all, I was wondering how can we continue to maintain a no js version of Horizon with the integration of Angular, it seems to be a lot of work on top of it. I would favor not having to maintain the non-js functionality, as IMHO most of current modern UIs depend on javascript and the command line interface should take over where javascript is not available. Though, if we want to maintain non-js functionality, directives are not a blocker. The directive html element can include the non-js code which is replaced by directive template when js and angular get's in. If not, the original content of directive's element is available. Maintaining non-js functionality becomes problematic when we need to serve multiple types of responses in controller - correct me if I am wrong, please. I agree that a command line utility seems like the most sensible "non-js" implementation of Horizon features. Additionally, we can write javascript with AngularJS that is friendly to various accessibility needs, like screen readers. I mentioned this in the chat last night and promised some examples. Here's an excellent walkthrough of using ARIA tags with javascript: http://stackoverflow.com/questions/15318661/accessibility-in-single-page-applications-aria-etc And a little more: http://webaim.org/techniques/javascript/eventhandlers http://stackoverflow.com/questions/18853183/what-are-the-accessibility-implications-of-using-a-framework-like-angularjs Basically, if you can make an HTML page friendly to screen readers, you can make a javascript-built app friendly to screen readers. In addition, do we know the performance of Angularjs, where are the limits, it could be good to check some documentation and made some POC. I have tried the asynchronous API and I encountered some issues with the two way data bind. Does people have some feedbacks? I didn't get any perfromance issues while using Angular, could you elaborate o the issues you had? I will try to search some performance related topics. In my experience, the performance has always been "Excellent", but there could certainly be use cases where it's not Thanks! -- Jordan O'Mara Red Hat Engineering, Raleigh pgpt0gsCbrkvn.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
