Re: [openstack-dev] [Horizon] import only module message and #noqa
On Fri, Jan 03, 2014 at 10:18:58AM -0500, Russell Bryant wrote: On 01/03/2014 10:10 AM, Radomir Dopieralski wrote: I think that we can actually do a little bit better and remove many of the #noqa tags without forfeiting automatic checking. I submitted a patch: https://review.openstack.org/#/c/64832/ This basically adds a h302_exceptions option to tox.ini, that lets us specify which names are allowed to be imported. For example, we can do: [hacking] h302_exceptions = django.conf.settings, django.utils.translation.ugettext_lazy, django.core.urlresolvers. To have settings, _ and everything from urlresolvers importable without the need for the #noqa tag. Of course every project can add their own names there, depending what they need. Isn't that what import_exceptions is for? For example, we have this in nova: import_exceptions = nova.openstack.common.gettextutils._ -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I guess it could work too, but that would disable all warnings against these imports (unused imports, * imports, etc), right? I think a specific option is useful. -- Gabriel Pettier Software Engineer at CloudWatt.com 06 85 10 36 34 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] import only module message and #noqa
So Tatiana pointed http://lists.openstack.org/pipermail/openstack-dev/2013-June/thread.html#9993 to me, and from there i went on to read http://lists.openstack.org/pipermail/openstack-dev/2013-August/thread.html#13074 and i can see valid points for H302, even if it annoy me sometime, if it's better for reviews, i understand. Sorry for the noise On Mon, Dec 30, 2013 at 03:43:03PM +0100, Gabriel pettier wrote: Hi Reading horizon's code and recent reviews, i'm under the impression that it's a common practice to use #noqa to bypass the import only modules qa message, i'm unconvinced of the advantages of this policy (i think the namespace is often cleaner when one import only the symbols needed from the modules), so i think this policy could be removed, by adding H302 to the list of ignored errors in tox.ini. This would allow removing a lot of #noqa comments, making for cleaner code. If there are significant advantages to this policy, however, it should be made more consistently applied to fix all these imports. Regards -- Gabriel Pettier Software Engineer at CloudWatt.com 06 85 10 36 34 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Gabriel Pettier Software Engineer at CloudWatt.com 06 85 10 36 34 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack][keystone] Is the user password too simple?
On Mon, Dec 30, 2013 at 11:15:06PM +0800, Thomas Goirand wrote: On 12/30/2013 02:55 PM, li-zheming wrote: hi all: when create user, you can set user password. You can set password as a simple word 'a'. the password is too simple but not limit. if someone want to steal your password, it is so easily(such as exhaustion). I consider that it must be limited when set password, like this: 1. inlcude uppper and lower letters 2. include nums 3. include particular symbol，such as '_','' 4. the length8 administor can set the password rule. Hi, If you want to check for password complexity, do it the correct way. I'm used to *always* use a password generator that uses only lower case, and removes chars that can be confused with one another, so that you don't have l and 1, or O and 0 in my passwords. Yet, they are high entropy and long. If you just force me to add upper+lower case and add symbols, then you are just annoying me even with my very good passwords. I want to provide a BP about this issue. can you give me some advice or ideas?? Please use a password entropy function. Something like this: https://pypi.python.org/pypi/cracklib Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I agree with this, if there is a check, it should check general safety, rather than expect to fulfill all conditions, if i have a 50 letters pass (and i do, using full sentences is quite convenient), don't force me to have numbers or symbols in it, it's already way harder to crack than an 8 chars word with a capital, a number, and a non-alphanumerical char. -- Gabriel Pettier Software Engineer at CloudWatt.com 06 85 10 36 34 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Enhance UX of Launch Instance Form
I've been working on this blueprint's implementation, the first bullet point has been implemented by the two following Gerrit reviews: https://review.openstack.org/#/c/61754/3 and https://review.openstack.org/#/c/62442/ The first one is simply there to allow for any modal view to declare itself as fullscreen, and provide style for the modal to take screen space relative to the buffer size. The second one makes use of this feature for the LaunchInstance Workflow, and changes the step template to use responsive elements instead of a table. This doesn't touch the content of the steps at all, only the size/responsiveness of the whole popup UI. Feedbacks about the blueprint are of course still welcome, as well as feedback for the implementation. This video shows the state of the popup after the two patchsets. http://youtu.be/0b9aqtH0dSI On Tue, Dec 03, 2013 at 07:44:12PM +0100, Gabriel pettier wrote: (Previous mail went out a bit fast) These features could be developed iteratively to improve upon the existing code base: - First allow the modal view system to expand for better usage of screen real-estate combined with responsiveness of the whole popin - Then rework existing menus to simplify user flow: - ephemeral/persistent switch - images/flavors choice list instead of combobox I saw work had been started for the wizard-navigation in [1] As for implementation details we obviously need to discuss them, for exemple as there have been a recent addition of AngularJS, should we use it for the view implementation? Feedback/directions? [1] http://ask-openstackux.rhcloud.com/question/81/wizard-ui-for-workflow/ On Tue, Dec 03, 2013 at 05:49:29PM +0100, Gabriel pettier wrote: Hi there I read the proposal and related documentation, and intend to start implementing it into horizon. Regards on Wed Nov 20 15:09:05 UTC 2013 C?dric Soulas Wrote Thanks for all the feedback on the Enhance UX of launch instance form subject and its prototype. Try the latest version of the prototype: http://cedricss.github.io/openstack-dashboard-ux-blueprints/launch-instance This update was made after several discussion on those different channels: - openstack ux google group - launchpad horizon (and now launchpad openstack ux) - mailing list and IRC - the new ask bots for openstack UX We tried to write back most of discussions on ask bot, and are now focusing on this tool. Below a digest of those discussions, with links to ask bot (on each subject, there are links to related blueprints, google doc drafts, etc) = General topics = - Modals and supporting different screen sizes [2] Current modal doesn't work well on the top 8 screen resolutions [2] = Responsive and full screen modal added on the prototype [1] - Wizard mode for some modals [3] = try the wizard [1] = Specific to launch instance = - Improve boot source options [4] * first choose to boot from ephemeral or persistent disk * if no ephemeral flavor are available, hide the selector * group by public, project, shared with me * warning message added for delete on terminate option (when boot from persistent) - Scaling the flavor list [5] * sort the columns of the table. In particular: by name. * group of flavor list (for example: performance, standard...)? - Scaling the image list [5] * a scrollbar on the image list * limit the number of list items and add a x more instance snapshots - See more line * a search / filter feature would be great, like discussed at the scaling horizon design session - Step 1 / Step 2 workflow: when the user click on select from one boot source item it goes directly to the step 2. If it goes back from step 2 to step 1: * the text Please select a boot source would be replaced with a Next button * the button select on the selected boot source item would be replaced with a check-mark (or equivalent). * the user would still have the possibility to select another boot source - flavor depending on image requirements and quotas available: * this a very good point, lot of things to discuss about = should open a separate thread on this - Network: still a work in progress * if a single choice: then make it default choice - Several wording updates (cancel, ephemeral boot source, ...) [1] http://cedricss.github.io/openstack-dashboard-ux-blueprints/launch-instance [2] http://ask-openstackux.rhcloud.com/question/11/modals-and-supporting-different-screen-sizes/ [3] http://ask-openstackux.rhcloud.com/question/81/wizard-ui-for-workflow [4] http://ask-openstackux.rhcloud.com/question/13/improve-boot-source-ux-ephemeral-vs-persistent-disk/ [5] http://ask-openstackux.rhcloud.com/question/12/enhance-the-selection-of-a-flavor-and-an-image/ Best, Cédric Oct 11
Re: [openstack-dev] How to best make User Experience a priority in every project
, focusing cross-project, thinking user way and proposing solutions it's so big help and support of others work. Of course we can do UIs, APIs, CLIs without specialized group of people, but each engineer thinks a bit differently, each can have different perception of what is valuable for user and the lack of unification will raise. And that's actually what is happening. At the moment we are not the biggest group of people, so I understand the concerns. Anyway, getting the blessing for UX is not a question of us continuing in the effort, but supporting us and spreading out the message - that we as OpenStack care. I am not trying to convince anybody here, I accept the decision 'no' (at least for this moment). I just feel that it was not consensus that most of people thinks that this is nonsense. I don't see any strong reasons why not. In time, I believe more people will see how important it is and hopefully OpenStack will recognize UX efforts officially. Anyway... I want to encourage anybody interested in the UX (any area) - reach us and help us to make OpenStack more usable. Everybody's hand is welcome. Thanks all for contributing to this thread and expressing your opinions. I really appreciate that. -- Jarda --- Jaromir Coufal (jcoufal) --- OpenStack User Experience --- IRC: #openstack-ux (at FreeNode) --- Forum: http://ask-openstackux.rhcloud.com --- Wiki: https://wiki.openstack.org/wiki/UX On 2013/20/11 16:09, Thierry Carrez wrote: Hi everyone, How should we proceed to make sure UX (user experience) is properly taken into account into OpenStack development ? Historically it was hard for UX sessions (especially the ones that affect multiple projects, like CLI / API experience) to get session time at our design summits. This visibility issue prompted the recent request by UX-minded folks to make UX an official OpenStack program. However, as was apparent in the Technical Committee meeting discussion about it yesterday, most of us are not convinced that establishing and blessing a separate team is the most efficient way to give UX the attention it deserves. Ideally, UX-minded folks would get active *within* existing project teams rather than form some sort of counter-power as a separate team. In the same way we want scalability and security mindset to be present in every project, we want UX to be present in every project. It's more of an advocacy group than a program imho. So my recommendation would be to encourage UX folks to get involved within projects and during project-specific weekly meetings to efficiently drive better UX there, as a direct project contributor. If all the UX-minded folks need a forum to coordinate, I think [UX] ML threads and, maybe, a UX weekly meeting would be an interesting first step. There would still be an issue with UX session space at the Design Summit... but that's a well known issue that affects more than just UX: the way our design summits were historically organized (around programs only) made it difficult to discuss cross-project and cross-program issues. To address that, the plan is to carve cross-project space into the next design summit, even if that means a little less topical sessions for everyone else. Thoughts ? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Gabriel Pettier Software Engineer at CloudWatt.com 06 85 10 36 34 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [horizon] Enhance UX of Launch Instance Form
Hi there I read the proposal and related documentation, and intend to start implementing it into horizon. Regards on Wed Nov 20 15:09:05 UTC 2013 C?dric Soulas Wrote Thanks for all the feedback on the Enhance UX of launch instance form subject and its prototype. Try the latest version of the prototype: http://cedricss.github.io/openstack-dashboard-ux-blueprints/launch-instance This update was made after several discussion on those different channels: - openstack ux google group - launchpad horizon (and now launchpad openstack ux) - mailing list and IRC - the new ask bots for openstack UX We tried to write back most of discussions on ask bot, and are now focusing on this tool. Below a digest of those discussions, with links to ask bot (on each subject, there are links to related blueprints, google doc drafts, etc) = General topics = - Modals and supporting different screen sizes [2] Current modal doesn't work well on the top 8 screen resolutions [2] = Responsive and full screen modal added on the prototype [1] - Wizard mode for some modals [3] = try the wizard [1] = Specific to launch instance = - Improve boot source options [4] * first choose to boot from ephemeral or persistent disk * if no ephemeral flavor are available, hide the selector * group by public, project, shared with me * warning message added for delete on terminate option (when boot from persistent) - Scaling the flavor list [5] * sort the columns of the table. In particular: by name. * group of flavor list (for example: performance, standard...)? - Scaling the image list [5] * a scrollbar on the image list * limit the number of list items and add a x more instance snapshots - See more line * a search / filter feature would be great, like discussed at the scaling horizon design session - Step 1 / Step 2 workflow: when the user click on select from one boot source item it goes directly to the step 2. If it goes back from step 2 to step 1: * the text Please select a boot source would be replaced with a Next button * the button select on the selected boot source item would be replaced with a check-mark (or equivalent). * the user would still have the possibility to select another boot source - flavor depending on image requirements and quotas available: * this a very good point, lot of things to discuss about = should open a separate thread on this - Network: still a work in progress * if a single choice: then make it default choice - Several wording updates (cancel, ephemeral boot source, ...) [1] http://cedricss.github.io/openstack-dashboard-ux-blueprints/launch-instance [2] http://ask-openstackux.rhcloud.com/question/11/modals-and-supporting-different-screen-sizes/ [3] http://ask-openstackux.rhcloud.com/question/81/wizard-ui-for-workflow [4] http://ask-openstackux.rhcloud.com/question/13/improve-boot-source-ux-ephemeral-vs-persistent-disk/ [5] http://ask-openstackux.rhcloud.com/question/12/enhance-the-selection-of-a-flavor-and-an-image/ Best, C?dric -- Gabriel Pettier Software Engineer at CloudWatt.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Enhance UX of Launch Instance Form
(Previous mail went out a bit fast) These features could be developed iteratively to improve upon the existing code base: - First allow the modal view system to expand for better usage of screen real-estate combined with responsiveness of the whole popin - Then rework existing menus to simplify user flow: - ephemeral/persistent switch - images/flavors choice list instead of combobox I saw work had been started for the wizard-navigation in [1] As for implementation details we obviously need to discuss them, for exemple as there have been a recent addition of AngularJS, should we use it for the view implementation? Feedback/directions? [1] http://ask-openstackux.rhcloud.com/question/81/wizard-ui-for-workflow/ On Tue, Dec 03, 2013 at 05:49:29PM +0100, Gabriel pettier wrote: Hi there I read the proposal and related documentation, and intend to start implementing it into horizon. Regards on Wed Nov 20 15:09:05 UTC 2013 C?dric Soulas Wrote Thanks for all the feedback on the Enhance UX of launch instance form subject and its prototype. Try the latest version of the prototype: http://cedricss.github.io/openstack-dashboard-ux-blueprints/launch-instance This update was made after several discussion on those different channels: - openstack ux google group - launchpad horizon (and now launchpad openstack ux) - mailing list and IRC - the new ask bots for openstack UX We tried to write back most of discussions on ask bot, and are now focusing on this tool. Below a digest of those discussions, with links to ask bot (on each subject, there are links to related blueprints, google doc drafts, etc) = General topics = - Modals and supporting different screen sizes [2] Current modal doesn't work well on the top 8 screen resolutions [2] = Responsive and full screen modal added on the prototype [1] - Wizard mode for some modals [3] = try the wizard [1] = Specific to launch instance = - Improve boot source options [4] * first choose to boot from ephemeral or persistent disk * if no ephemeral flavor are available, hide the selector * group by public, project, shared with me * warning message added for delete on terminate option (when boot from persistent) - Scaling the flavor list [5] * sort the columns of the table. In particular: by name. * group of flavor list (for example: performance, standard...)? - Scaling the image list [5] * a scrollbar on the image list * limit the number of list items and add a x more instance snapshots - See more line * a search / filter feature would be great, like discussed at the scaling horizon design session - Step 1 / Step 2 workflow: when the user click on select from one boot source item it goes directly to the step 2. If it goes back from step 2 to step 1: * the text Please select a boot source would be replaced with a Next button * the button select on the selected boot source item would be replaced with a check-mark (or equivalent). * the user would still have the possibility to select another boot source - flavor depending on image requirements and quotas available: * this a very good point, lot of things to discuss about = should open a separate thread on this - Network: still a work in progress * if a single choice: then make it default choice - Several wording updates (cancel, ephemeral boot source, ...) [1] http://cedricss.github.io/openstack-dashboard-ux-blueprints/launch-instance [2] http://ask-openstackux.rhcloud.com/question/11/modals-and-supporting-different-screen-sizes/ [3] http://ask-openstackux.rhcloud.com/question/81/wizard-ui-for-workflow [4] http://ask-openstackux.rhcloud.com/question/13/improve-boot-source-ux-ephemeral-vs-persistent-disk/ [5] http://ask-openstackux.rhcloud.com/question/12/enhance-the-selection-of-a-flavor-and-an-image/ Best, Cédric Oct 11 17:11:26 UTC 2013, Jesse Pretorius jesse.pretorius at gmail.com wrote: +1 A few comments: 1. Bear in mind that sometimes a user may not have access to any Ephemeral flavors, so the tabbing should ideally be adaptive. An alternative would not to bother with the tabs and just show a flavor list. In our deployment we have no flavors with ephemeral disk space larger than 0. 2. Whenever there's a selection, but only one choice, make it a default choice. It's tedious to choose the only selection only because you have to. It's common for our users to have one network/subnet defined, but the current UI requires them to switch tabs and select the network which is rather tedious. 3. The selection of the flavor is divorced from the quota available and from the image requirements. Ideally those two items should somehow be incorporated. A user needs to know up-front that the server will build based on both their quota and the image minimum requirements. 4. We'd like
Re: [openstack-dev] [horizon] Enhance UX of Launch Instance Form
(Previous mail went out a bit fast) These features could be developed iteratively to improve upon the existing code base: - First allow the modal view system to expand for better usage of screen real-estate combined with responsiveness of the whole popin - Then rework existing menus to simplify user flow: - ephemeral/persistent switch - images/flavors choice list instead of combobox I saw work had been started for the wizard-navigation in [1] As for implementation details we obviously need to discuss them, for exemple as there have been a recent addition of AngularJS, should we use it for the view implementation? Feedback/directions? [1] http://ask-openstackux.rhcloud.com/question/81/wizard-ui-for-workflow/ On Tue, Dec 03, 2013 at 05:49:29PM +0100, Gabriel pettier wrote: Hi there I read the proposal and related documentation, and intend to start implementing it into horizon. Regards on Wed Nov 20 15:09:05 UTC 2013 C?dric Soulas Wrote Thanks for all the feedback on the Enhance UX of launch instance form subject and its prototype. Try the latest version of the prototype: http://cedricss.github.io/openstack-dashboard-ux-blueprints/launch-instance This update was made after several discussion on those different channels: - openstack ux google group - launchpad horizon (and now launchpad openstack ux) - mailing list and IRC - the new ask bots for openstack UX We tried to write back most of discussions on ask bot, and are now focusing on this tool. Below a digest of those discussions, with links to ask bot (on each subject, there are links to related blueprints, google doc drafts, etc) = General topics = - Modals and supporting different screen sizes [2] Current modal doesn't work well on the top 8 screen resolutions [2] = Responsive and full screen modal added on the prototype [1] - Wizard mode for some modals [3] = try the wizard [1] = Specific to launch instance = - Improve boot source options [4] * first choose to boot from ephemeral or persistent disk * if no ephemeral flavor are available, hide the selector * group by public, project, shared with me * warning message added for delete on terminate option (when boot from persistent) - Scaling the flavor list [5] * sort the columns of the table. In particular: by name. * group of flavor list (for example: performance, standard...)? - Scaling the image list [5] * a scrollbar on the image list * limit the number of list items and add a x more instance snapshots - See more line * a search / filter feature would be great, like discussed at the scaling horizon design session - Step 1 / Step 2 workflow: when the user click on select from one boot source item it goes directly to the step 2. If it goes back from step 2 to step 1: * the text Please select a boot source would be replaced with a Next button * the button select on the selected boot source item would be replaced with a check-mark (or equivalent). * the user would still have the possibility to select another boot source - flavor depending on image requirements and quotas available: * this a very good point, lot of things to discuss about = should open a separate thread on this - Network: still a work in progress * if a single choice: then make it default choice - Several wording updates (cancel, ephemeral boot source, ...) [1] http://cedricss.github.io/openstack-dashboard-ux-blueprints/launch-instance [2] http://ask-openstackux.rhcloud.com/question/11/modals-and-supporting-different-screen-sizes/ [3] http://ask-openstackux.rhcloud.com/question/81/wizard-ui-for-workflow [4] http://ask-openstackux.rhcloud.com/question/13/improve-boot-source-ux-ephemeral-vs-persistent-disk/ [5] http://ask-openstackux.rhcloud.com/question/12/enhance-the-selection-of-a-flavor-and-an-image/ Best, C?dric Oct 11 17:11:26 UTC 2013, Jesse Pretorius jesse.pretorius at gmail.com wrote: +1 A few comments: 1. Bear in mind that sometimes a user may not have access to any Ephemeral flavors, so the tabbing should ideally be adaptive. An alternative would not to bother with the tabs and just show a flavor list. In our deployment we have no flavors with ephemeral disk space larger than 0. 2. Whenever there's a selection, but only one choice, make it a default choice. It's tedious to choose the only selection only because you have to. It's common for our users to have one network/subnet defined, but the current UI requires them to switch tabs and select the network which is rather tedious. 3. The selection of the flavor is divorced from the quota available and from the image requirements. Ideally those two items should somehow be incorporated. A user needs to know up-front that the server will build based on both their quota and the image minimum requirements. 4. We'd like
