Re: [openstack-dev] Avoiding regression in project governance
Blocking the acceptance of new projects seems punitive and against the spirit of the big tent. Classification (tagging) can be done at any point, and is hardly fixed in stone. You can refine tags as needed. To put it harshly: it is a failure of both leadership and process to have stripped out the old process and set a low bar only to insist that no one may be accepted under the new criteria because you haven't defined the rest of the process yet. Even more concerning is the sentiment of projects we want to consciously drop from Russell's original email. I realize that was meant to apply to whatever becomes the integrated release tag, yet still... the point of the big tent is not to exclude; the big tent is meant to *include and classify* so that the community, operators, distros, and vendors could make the best choices for themselves. So I agree that these projects are a great litmus test for what kind of tags you need, but at this point I don't think you have a leg to stand on for not accepting projects that meet the current criteria. The bar for acceptance is in the governance documents. A freeze seems unjustifiable and dragging your feet seems unnecessary, at least unless you all plan on changing the governance yet again. - Gabriel -Original Message- From: Thierry Carrez [mailto:thie...@openstack.org] Sent: Tuesday, March 10, 2015 11:00 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Avoiding regression in project governance Russell Bryant wrote: [...] We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. The resulting set of tags doesn't have to be focused on replicating our previous set of criteria. The focus must be on what information is needed by various groups of consumers and tags are a mechanism to implement that. In any case, we're far from that point because today we have nothing. I agree that we need tags to represent the various facets of what was in the integrated release concept. I'm not sure we should block accepting new project teams until all tags are defined, though. That sounds like a way to stall forever. So could you be more specific ? Is there a clear set of tags you'd like to see defined before we add new project teams ? I can't think of any good reason to rush into approving projects in the short term. If we're not able to work out this rich tagging system in a reasonable amount of time, then maybe the whole approach is broken and we need to rethink the whole approach. The current plan for the Vancouver Design Summit is to only give space to OpenStack projects (while non-OpenStack projects may get space in ecosystem sessions outside of the Design Summit). So it's only fair for those projects to file for recognition before that happens. -- Thierry Carrez (ttx) __ 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 __ 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] the future of angularjs development in Horizon
As the former Horizon PTL, I have a great respect for the importance of the contributions the distro maintainers/developers make to Horizon and OpenStack as a whole. From how many bugs the distros manage to find, to their diligence in vetting the software that we as Horizon developers provide, to their overall passion for the work they do. It is interesting to me to see the level to which the distros have not had to address this problem before. It shows a significant disconnect between the Node/JavaScript community and the distros as a whole (not surprising since node.js wasn't packaged on many distros until quite recently). I'm not excited to see the OpenStack community leading the charge on resolving packaging issues that ought to be settled between the JS community and the distros. Yet, if we have to in order to move forward I would urge us to reach out to the NPM maintainers, major library maintainers, etc. to try and make decisions that will benefit everyone for years to come. It's also interesting to see how strongly people take sides in this debate... who is OpenStack for? How crucial are the distros? Obviously if you work for RedHat or Canonical the distros are the end-all; OpenStack has to be packaged. Other companies? Opinions vary. Flexibility on this issue is not consistent, as has been pointed out already. Monty and Adam Young have, I think, voiced a good moderate viewpoint, which is that the distros are a core part of OpenStack's success and we have to ensure that they can package our software, but that the distros also cannot dictate the tools we use in order to produce the best possible product. Distros are ultimately middle-men, they provide value to their users and they make sure more people use the software we produce. We can all agree that we want to maximize the number of people we can reach. So, I propose that a group gets together and defines criteria: we need to accept that the Horizon team (and those knowledgeable about web-app development) know best what tools they need, and they need to produce such a list as a starting point. We then need packagers and maintainers to examine that list and evaluate it for problems (non-free software, irresolvable dependencies, etc.). They're looking strictly for things which are un-packageable, not commenting on the necessity of said software. And we need people (thanks, Monty) willing to build new tools to find a way to turn that list into something the package maintainers can consume without burdening either side. Make sense? - Gabriel -Original Message- From: Thomas Goirand [mailto:z...@debian.org] Sent: Friday, November 14, 2014 11:11 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon On 11/14/2014 10:10 PM, Martin Geisler wrote: Of course, I need to run tests. That's a big part of the QA work, and I will certainly not give-up on that. You will have a hard time convincing anyone within the OpenStack community that it's OK to not run unit tests. That's not what I said: the OpenStack developers will continue to tests the software. I personally don't think it's the job of the downstream packagers to do this QA work. (It's of course cool to run the tests on the system installed by your packages -- that test run would then install the needed tools using npm and bower and whatnot if that's how the upstream has setup the test framework.) What happens is that the environment within the distribution, inevitably, will be different from the one ran on the gate. There's going to be different versions of many components and so on. So it is very important for me to also run these unit tests, to make sure that everything continues to work. Yes, the build-dependencies will pull the same components as pulled by npm/bower, though they may be installed in different path, and maybe using different versions. On 11/14/2014 10:21 PM, Jeremy Stanley wrote: On 2014-11-14 15:10:59 +0100 (+0100), Martin Geisler wrote: [...] Just to quibble on this particular point... distro packagers are also developers. They often (more often than we'd like, and we do try to find ways to help avoid this where possible) need to carry their own patches to tweak the software to fit their deployment and operation model. Being able to rerun tests in-place with packaged versions of everything including their patches helps them confirm that what they distribute still works as intended. Further, the distro users are well within their rights to modify and respin these packages themselves, and will potentially want to be able to run these tests for the same reasons. We distribute our tests as part of our software because our tests *are* part of our software. Exactly! Let me give a few examples... In Jessie, Nova carries patches so that there is support for Ceph. Until a few days,
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
Two things of note, having been doing heavy javascript development over the past couple years: 1) NPM actually resolves conflicts in a dependency tree. Unlike Python, it can ensure that if different packages declare conflicting versions, each one gets the version it requested. And conflicting dependencies are very common in JS packages. That's gonna be a nightmare for more traditional packaging systems if you try to shoehorn them together. 2) The OpenStack community is overwhelmingly fond of reinventing wheels. The JavaScript community has the opposite habit, and tends to create a package for every last function (that's why some of these seemingly single-purpose tools have 50+ dependencies). I caution against putting in place a system that penalizes developers for trying to use established tools or to use packages that do the job and do it well (such as forcing them to deal with xstatic packaging). While I respect the licensing and packaging concerns involved in large dependency trees, we need to stop encouraging people to reinvent wheels. I think most folks at this point agree that the future of Horizon is to become a JavaScript-driven web app. It's the way the industry is going this point, and it's the way to satisfy what users want and expect. Provided we accept that future, we should strive to embrace the best practices of that development community, not to tell them we don't like it or it doesn't fit how OpenStack does things. On a historical note, OpenStack had a very rocky relationship with the broader Python community in its early days. Since then, thanks to great efforts on both sides, that relationship has gotten much better. Let's try not to replay history by doing the same thing with the JavaScript/Node community. We have to attract great developers so we can produce the best possible OpenStack. I remind people to think about how we can do *that* first and how we can deal with distro requirements to support the process second. - Gabriel -Original Message- From: Thomas Goirand [mailto:z...@debian.org] Sent: Wednesday, November 12, 2014 5:30 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon On 11/12/2014 11:12 PM, Jiri Tomasek wrote: As Monty Taylor said, nodejs itself is not a blocker as multiple versions of it should not be needed by our tools. (That's also what npm and bower are taking care of, right?) Only thing that is required is that all tools/js libs we want to use would eventually have to be packaged. This is just a bunch of work for packagers. Approach on using Xstatic packages vs Js tooling: As only problem with using js tooling should be just actual packaging of it, I think it makes sense to use these tools and make development simpler then going other way around and using Xstatic packages - which means devs would have to care about getting stuff packaged as xstatic and added to the code, while maintaining proper versions and making sure that they work ok together. NPM and Bower do this for us. Common sense tells me packagers should take care of packaging. Packaging of these tools will have to get resolved somehow anyway, as there will be rise in requirements of using them not just from Horizon... I see an obvious issue with your approach. Just like with pip and PyPi, it's going to be just one line of patch for Horizon people to add yet-another-javascript-dependency. It's already a dependency hell. I have created 21 new python-xstatic packages in Debian, and at least, for half a dozen of them (maybe more), I also packaged the libjs-* packages. It took a long time to have them in order, and it just got stabilized for Juno (there's still something to fix in Jessie, but I don't really care as it's Icehouse there...). Now, your motivation to go into the direction of using tooling seems to be motivated so that it's super easy to add more. And more... And more again. This leads me to believe that it's going to be even more crazy. When is this going to stop? We're definitively enlarging the potential surface of attack and potential security breaches. And OpenStack at large is not at all doing great in terms of security. [1] I just don't understand why all of this is needed. I did some JS programming myself back in the days (10 years ago, using PHP...). I could do Ajax by hand, without using a single library. What is it that you're doing in Horizon that needs so many libs? When I see Horizon in Juno, I don't even get it. Or is it because you just want to have fancy animation? Frankly, I don't care these. I care a lot more that we're not adding new potential security problems. On 11/13/2014 12:18 AM, Julie Pichon wrote: There are instructions already on how to create xstatic packages [1], it's not very complicated and just takes some review time. Exactly!!! And if someone can't make the
Re: [openstack-dev] [Horizon] Cookie collision between Horizon Stacktach
I have no familiarity with stacktach, but it sounds like it's trampling data on the sessionid cookie (even if it's also setting a beaker.session.stacktach cookie). Your options include running the two at different domains/subdomains (and specifying the subdomain as the cookie domain; that needs to be explicit), or you can change the Django cookie names using settings: Session cookie name: https://docs.djangoproject.com/en/dev/ref/settings/#session-cookie-name CSRF cookie name: https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-CSRF_COOKIE_NAME It doesn't sound like you had a CSRF cookie problem though. It is expected behavior that if you clear your cookies and don't revisit the login page to get a new CSRF token that form POSTs will fail. - Gabriel -Original Message- From: Aaron Sahlin [mailto:asah...@linux.vnet.ibm.com] Sent: Friday, October 31, 2014 12:37 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Horizon] Cookie collision between Horizon Stacktach I was posed this question, but am not familiar with Horizon or StackTach cookie management. Anyone know what the issue might be? Issue: Logging into one site logs you out of the other. (horizon/stacktach) First I open horizon and notice there are two cookies: csrftoken (horizon) and sessionid. I log into Horizon, then open up a new tab and log into stacktach (same domain, different port). After logging into stacktach, there's another cookie created named beaker.session.stacktach. I go back to the horizon dashboard and get logged off after clicking anything. After trying to log back in, this error comes up: Your Web browser doesn't appear to have cookies enabled. Cookies are required for logging in. I then clear the cookies and am able to log in, but see this error message: Forbidden (403) CSRF verification failed. Request aborted. I go back to the Horizon log in page, finally log in, go to stacktach tab and am logged out of that. Note that stacktach is at a separate port on the controller and uses beaker to create the cookie session. I've read that cookies aren't port-speciic on the same domain name, but should still work with different cookie names.. I've also tried changing the paths on the stacktach urls, but no luck there either. ___ 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
Re: [openstack-dev] [Horizon] [Devstack]
SQLite doesn't introduce any additional dependencies, memcached requires installation of memcached (admittedly it's not hard on most distros, but it *is* yet another step) and in most cases the installation of another python module to interface with it. Memcached might be a good choice for devstack, but it may or may not be the right thing to recommend for Horizon by default. - Gabriel -Original Message- From: Yves-Gwenaël Bourhis [mailto:yves-gwenael.bour...@cloudwatt.com] Sent: Friday, October 24, 2014 7:06 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Horizon] [Devstack] Le 24/10/2014 13:30, Chmouel Boudjnah a écrit : On Fri, Oct 24, 2014 at 12:27 PM, Yves-Gwenaël Bourhis yves-gwenael.bour...@cloudwatt.com mailto:yves-gwenael.bour...@cloudwatt.com wrote: memcache can be distributed (so usable in HA) and has far better performances then db sessions. Why not use memcache by default? I guess for the simple reason that if you restart your memcache you loose all the sessions? Indeed, and for devstack that's an easy way do do a cleanup of old sessions :-) We are well talking about devstack in this thread, where loosing sessions after a memcache restart is not an issue and looks more like a very handy feature. For production it's another mater, and operators have the choice. -- Yves-Gwenaël Bourhis ___ 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
Re: [openstack-dev] [Horizon] [Devstack]
All in all this is been a long time coming. The cookie-based option was useful as a batteries-included, simplest-case scenario. Moving to SQLite is a reasonable second choice since most systems Horizon might be deployed on support sqlite out of the box. I would make a couple notes: 1) If you’re going to store very large amounts of data in the session, then session cleanup is going to become an important issue to prevent excessive data growth from old sessions. 2) SQLite is far worse to go into production with than cookie-based sessions (which are far from perfect). The more we can do to ensure people don’t make that mistake, the better. 3) There should be a clear deprecation for cookie-based sessions. Don’t just drop them in a single release, as tempting as it is. Otherwise, seems good to me. - Gabriel From: David Lyle [mailto:dkly...@gmail.com] Sent: Thursday, October 23, 2014 2:44 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Horizon] [Devstack] In order to help ease an ongoing struggle with session size limit issues, Horizon is planning on changing the default session store from signed cookie to simple server side session storage using sqlite. The size limit for cookie based sessions is 4K and when this value is overrun, the result is truncation of the session data in the cookie or a complete lack of session data updates. Operators will have the flexibility to replace the sqlite backend with the DB of their choice, or memcached. We gain: support for non-trivial service catalogs, support for higher number of regions, space for holding multiple tokens (domain scoped and project scoped), better support for PKI and PKIZ tokens, and frees up cookie space for user preferences. The drawbacks are we lose HA as a default, a slightly more complicated configuration. Once the cookie size limit is removed, cookie based storage would no longer be supported. Additionally, this will require a few config changes to devstack to configure the session store DB and clean it up periodically. Concerns? David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
This is generally the right plan. The hard parts are in getting people to deploy it correctly and securely, and handling fallback cases for lack of browser support, etc. What we really don't want to do is to encourage people to set Access-Control-Allow-Origin: * type headers or other such nonsense simply because it's too much work to do things correctly. This becomes especially challenging for federated clouds. I would encourage looking at the problem of adding all the necessary headers for CORS as an OpenStack-wide issue. Once you figure it out for Keystone, the next logical step is to want to make calls from the browser directly to all the other service endpoints, and each service is going to have to respond with the correct CORS headers (Access-Control-Allow-Methods and Access-Control-Allow-Headers are particularly fun ones for projects like Glance or Swift). A common middleware and means of configuring it will go a long way to easing user pain and spurring adoption of the new mechanisms. It will help the Horizon team substantially in the long run to do it consistently and predictably across the stack. As a side-note, once we're in the realm of handling all this sensitive data with the browser as a middleman, encouraging people to configure things like CSP is probably also a good idea to make sure we're not loading malicious scripts or other resources. Securing a browser-centric world is a tricky realm... let's make sure we get it right. :-) - Gabriel -Original Message- From: Adam Young [mailto:ayo...@redhat.com] Sent: Tuesday, September 16, 2014 3:40 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Keystone][Horizon] CORS and Federation Phase one for dealing with Federation can be done with CORS support solely for Keystone/Horizon integration: 1. Horizon Login page creates Javascript to do AJAX call to Keystone 2. Keystone generates a token 3. Javascript reads token out of response and sends it to Horizon. This should support Kerberos, X509, and Password auth; the Keystone team is discussing how to advertise mechanisms, lets leave the onus on us to solve that one and get back in a timely manner. For Federation, the handshake is a little more complex, and there might be a need for some sort of popup window for the user to log in to their home SAML provider. Its several more AJAX calls, but the end effect should be the same: get a standard Keystone token and hand it to Horizon. This would mean that Horizon would have to validate tokens the same way as any other endpoint. That should not be too hard, but there is a little bit of create a user, get a token, make a call logic that currently lives only in keystonemiddleware/auth_token; Its a solvable problem. This approach will support the straight Javascript approach that Richard Jones discussed; Keystone behind a proxy will work this way without CORS support. If CORS can be sorted out for the other services, we can do straight Javascript without the Proxy. I see it as phased approach with this being the first phase. ___ 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
Re: [openstack-dev] [Designate][Horizon][Tempest][DevStack] Supporting code for incubated projects
I would also like to add that incubated != integrated. There's no telling how long a project may stay in incubation or how many changes it may undergo before it's deemed ready (see David's reasoning around client changes during RC's). While the Horizon team has always made every effort to work closely with the incubated projects in getting them ready for merge as soon as they're officially integrated, doing so prior to that promise of stability, distro support, etc. isn't just infeasible, it's dangerous to the Horizon project. Perhaps instead we should focus on making a better flow for installing experimental modules in a more official capacity. I always go back to how we can help build a better ecosystem. This problem applies to projects which are not and may never be incubated just as much as to incubated ones. Sure, anyone with some know-how *can* load in another dashboard or panel into Horizon through their settings, but maybe it's time we looked at how to do this in a more user-friendly way. - Gabriel -Original Message- From: Lyle, David [mailto:david.l...@hp.com] Sent: Tuesday, September 09, 2014 2:07 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Designate][Horizon][Tempest][DevStack] Supporting code for incubated projects Adding support for incubated projects in Horizon is blocked mainly for dependency issues. The way Horizon utilizes the python-*clients we force a requirement on distros to now include that version of the client even though it is not officially part of OpenStack's integrated release. Additionally, we've made exceptions and included incubated project support in the past and doing so has been borderline disastrous from a release point of view. Things like non-backward compatible client releases have happened in the RC cycles. I've been struggling with a better way forward. But including directly in the Horizon tree, will create problems. David On 9/9/14, 8:12 AM, Sean Dague s...@dague.net wrote: On 09/09/2014 07:58 AM, Mac Innes, Kiall wrote: Hi all, While requesting a openstack/designate-dashboard project from the TC/ Infra The topic of why Designate panels, as an incubated project, can¹t be merged into openstack/horizon was raised. In the openstack/governance review[1], Russell asked: Hm, I think we should discuss this with the horizon team, then. We are telling projects that incubation is a key time for integrating with other projects. I would expect merging horizon integration into horizon itself to be a part of that. With this in mind I¹d like to start a conversation with the Horizon, Tempest and DevStack teams around merging of code to support Incubated projects What are the drawbacks?, Why is this currently frowned upon by the various teams? And What do each of the parties believe is the Right Way forward? I though the Devstack and Tempest cases were pretty clear, once things are incubated they are fair game to get added in. Devstack is usually the right starting point, as that makes it easy for everyone to have access to the code, and makes the testability by other systems viable. I currently don't see any designate changes that are passing Jenkins that need to be addressed, is there something that got missed? -Sean -- Sean Dague http://dague.net ___ 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 list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Kerberization of Horizon (kerbhorizon?)
I've implemented Kerberos (via Apache) + Django once before, and yes, taking this as pseudo-code you're on the right track. Obviously the devil is in the details and you'll work out the particulars as you go. The most important bit (obviously) is just making absolutely sure your REMOTE_USER header/environment variable is trusted, but that's outside the Django layer. Assuming that you can work out with the other parameters from the original call going into auth, session, or client as appropriate as you said then you should be fine. All the best, - Gabriel From: Adam Young [mailto:ayo...@redhat.com] Sent: Wednesday, June 04, 2014 11:53 AM To: OpenStack Development Mailing List Subject: [openstack-dev] Kerberization of Horizon (kerbhorizon?) OK, so I'm cranking on All of the Kerberso stuff: plus S4U2Proxy work etcexcept that I have never worked with DJango directly before. I want to get a sanity check on my approach: Instead of authenticating to Keystone, Horizon will use mod_auth_krb5 and REMOTE_USER to authenticate the user. Then, in order to get a Keystone token, the code in openstack_dashboard/api/keystone.py:keystoneclient needs to fetch a token for the user. This will be done using a Kerberized Keystone and S4U2Proxy setup. There are alternatives using TGT delegation that I really want to have nothing to do with. The keystoneclient call currently does: conn = api_version['client'].Client(token=user.token.id, endpoint=endpoint, original_ip=remote_addr, insecure=insecure, cacert=cacert, auth_url=endpoint, debug=settings.DEBUG) when I am done it would do: from keystoneclient.contrib.auth.v3 import kerberos ... if REMOTE_USER: auth = kerberos.Kerberos(OS_AUTH_URL) else: auth = v3.auth.Token(token=user.token.id) sess=session.Session(kerb_auth, verify=OS_CACERT) conn = client.Client(session=sess, region_name='RegionOne') (with the other parameters from the original call going into auth, session. or client as appropriate) Am I on track? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Kerberization of Horizon (kerbhorizon?)
I suspect that to be true. Just adding a second authentication backend to the django-openstack-auth package would be fine. At least some of the logic should be reusable and creating a whole additional package seems like an unnecessary separation. - Gabriel From: Adam Young [mailto:ayo...@redhat.com] Sent: Wednesday, June 04, 2014 12:43 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Kerberization of Horizon (kerbhorizon?) On 06/04/2014 03:10 PM, Gabriel Hurley wrote: I've implemented Kerberos (via Apache) + Django once before, and yes, taking this as pseudo-code you're on the right track. Obviously the devil is in the details and you'll work out the particulars as you go. The most important bit (obviously) is just making absolutely sure your REMOTE_USER header/environment variable is trusted, but that's outside the Django layer. Assuming that you can work out with the other parameters from the original call going into auth, session, or client as appropriate as you said then you should be fine. Thanks. One part I'm not really sure about was if it is OK to skip adding a token to the session before calling on the keystone code. It seems like the django_openstack_auth code creates a user object and adds that to the session. I don't want any of the login forms from that package. I'm guessing that I would really need to write django-openstack-kerberos-backend to merge the logic from RemoteUserBackend with django_openstack_auth; I think I want the logic of django_openstack_auth.backend.KeystoneBackend.authenticate All the best, - Gabriel From: Adam Young [mailto:ayo...@redhat.com] Sent: Wednesday, June 04, 2014 11:53 AM To: OpenStack Development Mailing List Subject: [openstack-dev] Kerberization of Horizon (kerbhorizon?) OK, so I'm cranking on All of the Kerberso stuff: plus S4U2Proxy work etcexcept that I have never worked with DJango directly before. I want to get a sanity check on my approach: Instead of authenticating to Keystone, Horizon will use mod_auth_krb5 and REMOTE_USER to authenticate the user. Then, in order to get a Keystone token, the code in openstack_dashboard/api/keystone.py:keystoneclient needs to fetch a token for the user. This will be done using a Kerberized Keystone and S4U2Proxy setup. There are alternatives using TGT delegation that I really want to have nothing to do with. The keystoneclient call currently does: conn = api_version['client'].Client(token=user.token.id, endpoint=endpoint, original_ip=remote_addr, insecure=insecure, cacert=cacert, auth_url=endpoint, debug=settings.DEBUG) when I am done it would do: from keystoneclient.contrib.auth.v3 import kerberos ... if REMOTE_USER: auth = kerberos.Kerberos(OS_AUTH_URL) else: auth = v3.auth.Token(token=user.token.id) sess=session.Session(kerb_auth,verify=OS_CACERT) conn=client.Client(session=sess,region_name='RegionOne') (with the other parameters from the original call going into auth, session. or client as appropriate) Am I on track? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
Re: [openstack-dev] [horizon][infra] Plan for the splitting of Horizon into two repositories
Forgive me if I'm misunderstanding, but those all look like repositories that are strictly tracking upstreams. They're not maintained by the Horizon/OpenStack developers whatsoever. Is this intentional/necessary? - Gabriel -Original Message- From: Anita Kuno [mailto:ante...@anteaya.info] Sent: Thursday, May 29, 2014 12:30 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [horizon][infra] Plan for the splitting of Horizon into two repositories On 05/28/2014 08:54 AM, Radomir Dopieralski wrote: 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! I'd like to confirm that we are all aware that this patch creates 16 new repos under the administration of horizon-ptl and horizon-core: https://review.openstack.org/#/c/95716/ If I'm late to the party and the only one that this is news to, that is fine. Sixteen additional repos seems like a lot of additional reviews will be needed. Thanks, Anita. ___ 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
Re: [openstack-dev] [horizon][infra] Plan for the splitting of Horizon into two repositories
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
Re: [openstack-dev] [Horizon] RFC - Suggestion for switching from Less to Sass (Bootstrap 3 Sass support)
I would imagine the downstream distros won't have the same problems with Ruby as they did with Node.js from a dependency standpoint, though it still doesn't jive with the community's all-Python bias. My real concern, though, is anyone who may have extended the Horizon stylesheets using the capabilities of LESS. There are lots of ways you can customize the appearance of Horizon, and some folks may have gone that route. My recommended course of action would be to think deeply on some recommended ways of upgrading from LESS to SASS for existing deployments who may have written their own stylesheets. Treat this like a feature deprecation (which is what it is). Otherwise, if it makes people's lives better to use SASS instead of LESS, it sounds good to me. - Gabriel -Original Message- From: Jason Rist [mailto:jr...@redhat.com] Sent: Wednesday, February 05, 2014 9:48 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Horizon] RFC - Suggestion for switching from Less to Sass (Bootstrap 3 Sass support) On Wed 05 Feb 2014 09:32:54 AM MST, Jaromir Coufal wrote: Dear Horizoners, in last days there were couple of interesting discussions about updating to Bootstrap 3. In this e-mail, I would love to give a small summary and propose a solution for us. As Bootstrap was heavily dependent on Less, when we got rid of node.js we started to use lesscpy. Unfortunately because of this change we were unable to update to Bootstrap 3. Fixing lesscpy looks problematic - there are issues with supporting all use-cases and even if we fix this in some time, we might challenge these issues again in the future. There is great news for Bootstrap. It started to support Sass [0]. (Thanks Toshi and MaxV for highlighting this news!) Thanks to this step forward, we might get out of our lesscpy issues by switching to Sass. I am very happy with this possible change, since Sass is more powerful than Less and we will be able to update our libraries without any constraints. There are few downsides - we will need to change our Horizon Less files to Sass, but it shouldn't be very big deal as far as we discussed it with some Horizon folks. We can actually do it as a part of Bootstrap update [1] (or CSS files restructuring [2]). Other concern will be with compilers. So far I've found 3 ways: * rails dependency (how big problem would it be?) * https://pypi.python.org/pypi/scss/0.7.1 * https://pypi.python.org/pypi/SassPython/0.2.1 * ... (other suggestions?) Nice benefit of Sass is, that we can use advantage of Compass framework [3], which will save us a lot of energy when writing (not just cross-browser) stylesheets thanks to their mixins. When we discussed on IRC with Horizoners, it looks like this is good way to go in order to move us forward. So I am here, bringing this suggestion up to whole community. My proposal for Horizon is to *switch from Less to Sass*. Then we can unblock our already existing BPs, get Bootstrap updates and include Compass framework. I believe this is all doable in Icehouse timeframe if there are no problems with compilers. Thoughts? -- Jarda [0] http://getbootstrap.com/getting-started/ [1] https://blueprints.launchpad.net/horizon/+spec/bootstrap-update [2] https://blueprints.launchpad.net/horizon/+spec/css-breakdown [3] http://compass-style.org/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I think this is a fantastic idea. Having no experience with Less, but seeing that it is troublesome - if we can use SASS/Compass, I'd be much more comfortable with the switch. +1 -- Jason E. Rist Senior Software Engineer OpenStack Management UI Red Hat, Inc. +1.919.754.4048 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][nova] Re: Hierarchicical Multitenancy Discussion
Yes this is one approach if keystone really wants to extend domains to work this way, but I think this is more complex than just using nested projects. Having domains contain domains containing projects is less intuitive than projects all the way down. It's worth mentioning that at the meeting last Friday where all this was discussed it was pointed out that currently there are very few functional differences between projects and domains (user namespacing being the main one right now), so aside from a philosophical exercise it doesn't seem like it matters whether you extend domains or projects to be hierarchical. It accomplishes the exact same thing. Personally I favor projects being hierarchical, but maybe that's just because they've been around longer, although domains might tie better into a story around federated clouds, etc... All the best, - Gabriel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Can somebody help me to determine if an URL validation in python-glanceclient horizon projects is safe
Adding this to glanceclient is probably acceptable since the worst abuse of it would be to disrupt a user's local machine until they terminated the process, but adding this to Horizon is a no-go. Django removed the verify_exists option from URLField in Django 1.5 for very good reasons. Here's the release notes summary: django.db.models.fields.URLField.verify_exists will be removed. The feature was deprecated in 1.3.1 due to intractable security and performance issues and will follow a slightly accelerated deprecation timeframe. Note that intractable security issues bit. Doing this type of validation server-side opens you up to some nasty DoS attacks and simply shouldn't be done. If you have further questions, I recommend talking to Paul McMillan, who was the original reporter of the security issues with verify_exists in Django. All the best, - Gabriel From: Victor Joel Morales Ruvalcaba [mailto:chipah...@hotmail.com] Sent: Monday, January 20, 2014 9:44 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] Can somebody help me to determine if an URL validation in python-glanceclient horizon projects is safe I'm implementing an URL validation that checks if the external location value provided exists and if it's reachable. To achieve that I'm using the method urlopen of six.moves.urllib.request module which it seems similar like to the deprecated django's method of verify_exists. I'm wondering if I can proceed with the current implementation or if there's a way to implement those validations https://review.openstack.org/#/c/64295/ https://review.openstack.org/#/c/64312/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Re-using Horizon bits in OpenDaylight
I've also used the core Horizon bits for dashboards other than the OpenStack dashboard. I can't speak for any current bugs you may run into, but by-and-large the ability to create arbitrary dashboards, tables, workflows, etc. to interact with RESTful APIs works perfectly without the OpenStack bits. My goal has always been to keep a clean separation between the generic (horizon) and specific (openstack_dashboard) code. I always encouraged people to file any problems they have using the horizon module for non-OpenStack purposes as bugs on the project. Someday the modules may actually be split into two separate packages, but for nw the design goal stands, at least. All the best, - Gabriel From: Walls, Jeffrey Joel (Cloud OS RD) [mailto:jeff.wa...@hp.com] Sent: Friday, January 10, 2014 7:43 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Re-using Horizon bits in OpenDaylight I have used the Horizon framework for an application other than the OpenStack Dashboard and it worked really well. There is an effort to create a separation between the Horizon framework and the OpenStack Dashboard and once that happens it will be even easier. How hard or difficult it is will depend on exactly what you're trying to do and how well its UI metaphor matches that of the OpenStack Dashboard. Jeff From: Endre Karlson [mailto:endre.karl...@gmail.com] Sent: Friday, January 10, 2014 8:20 AM To: OpenStack Development Mailing List Subject: [openstack-dev] Re-using Horizon bits in OpenDaylight Hello everyone. I would like to know if anyone here has knowledge on how easy it is to use Horizon for something else then OpenStack things? I'm the starter of the dlux project that aims to consume the OpenDaylight SDN controller Northbound REST APIs instead of the integrated UI it has now. Though the current PoC is done using AngularJS i came into issues like how we make it easy for third part things that are not core to plugin it's things into the app which I know that can be done using panels and alike in Horizon. So the question boils down to, can I easily re-use Horizon for ODL? Endre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Changes to keystone-core!
Sounds like a good decision all around. Cleaning out -core lists seems to be the hip thing to do lately. ;-) All the best, - Gabriel From: Dolph Mathews [mailto:dolph.math...@gmail.com] Sent: Tuesday, January 07, 2014 11:16 AM To: OpenStack Development Mailing List Cc: Steve Martinelli; Jamie Lennox; David Stanek; Andy Smith; Gabriel Hurley; Joe Heck; Devin Carlen Subject: [keystone] Changes to keystone-core! Hello everyone! We've been talking this for a long while, and we finally have a bunch of changes to make to keystone-core all at once. A few people have moved on, the project has grown a bit, and our review queue grows ever longer. As ayoung phrased it in today's keystone meeting, with entirely selfish motivations, we'd like to welcome the following new Guardians of the Gate to keystone-core: + Steve Martinelli (stevemar) + Jamie Lennox (jamielennox) + David Stanek (dstanek) And I'll be removing the following inactive members from keystone-core (which hopefully won't come as a surprise to anyone!): - Andy Smith (termie) - Devin Carlen (devcamcar) - Gabriel Hurley (gabrielhurley) - Joe Heck (heckj) I'll be making these changes today. Thanks to EVERYONE for your contributions! Happy code reviewing, -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon and Tuskar-UI codebase merge
From my experience, directly adding incubated projects to the main Horizon codebase prior to graduation has been fraught with peril. That said, the closer they can be together prior to the graduation merge, the better. I like the idea of these types of projects being under the OpenStack Dashboard Program umbrella. Ideally I think it would be a jointly-managed resource in Gerrit. The Horizon Core folks would have +2 power, but the Tuskar core folks would also have +2 power. (I'm 90% certain that can be done in the Gerrit admin...) That way development speed isn't bottlenecked by Horizon Core, but there's a closer tie-in with the people who may ultimately be maintaining it. It becomes easier to keep track of, and can be more easily guided in the right directions. With a little work incubated dashboard components like this could even be made to be a non-gating part of the testing infrastructure to indicate when things change or break. Adding developers to Horizon Core just for the purpose of reviewing an incubated umbrella project is not the right way to do things at all. If my proposal of two separate groups having the +2 power in Gerrit isn't technically feasible then a new group should be created for management of umbrella projects. All the best, - Gabriel -Original Message- From: Julie Pichon [mailto:jpic...@redhat.com] Sent: Wednesday, December 18, 2013 4:50 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI codebase merge Jaromir Coufal jcou...@redhat.com wrote: Hi All, After yesterday's weekly meeting it seems that majority of us is leaning towards this approach (codebase merge). However there are few concerns regarding speed of development and resources especially for reviews. With this e-mail, I'd like to kick off discussion about how we might assure to get enough people so that we can fulfill Horizon as well as Tuskar-UI goals. It seems to me the opinions were still divided in the meeting, and this is why we are continuing the discussion. Personally I'm more favourable to the initial proposal, of moving the tuskar-ui repository under the Horizon program. Existing Horizon cores add it to their Watched Changes under Gerrit, just like for Horizon and django_openstack_auth now, and get familiar with the project during its development. Tuskar-ui cores can move their discussions to the #openstack-horizon channel and that's another way that we all become part of the same horizon community, and another chance for the horizon folks to understand what's important to Tuskar. There's a number of exceptions that are being requested, that make me think now is not the right time to just merge the code into the main horizon codebase. A few that have come up during the IRC meeting: - Request for more attention due to the need to move very fast - (Possibly) Request for an exception to the same company approval rule - Request to be able to check in broken stuff at times In my mind these requirements come from being an incubated project with different priorities, which is fine but make the project not suitable for the main horizon codebase yet. I think it makes more sense to merge once the project is integrated, like we've done so far. Another discussion on list ([1]) makes it clear that there's no promise an incubated project will become integrated, and that it can be dropped from incubation. IMHO that's another argument for waiting for a project to be integrated before merging it. This doesn't mean it doesn't get any attention from the existing Horizon team. I think extending this rule to all - moving dashboard components from incubated projects under the Horizon program - would be more reasonable and easier to scale, than the proposed alternative. With respect to the e-mail which was sent Dec 17 (quoted below), I think all of what was written applies, we just need to clarify couple more details. And I hope we can get to consensus by the end of this week so that we can make things happen. *Blueprints:* Currently there is couple of already existing blueprints for Tuskar-UI and there will appear more based on wireframes around deployment setup (which are not finished yet). https://blueprints.launchpad.net/tuskar-ui We want to make sure, that Horizoners are fine with these blueprints being merged with Horizon ones, keeping their priorities and that there will appear couple more in time. *Cores:* To make sure that we have enough people to get the code in and also to help Horizoners to free load of reviews on their side, we propose to merge our core team (plus rdopieralski). All of them contributes to Horizon so they know the code well. People we are talking about: - jomara - jtomasek - lsmola - rdopieralski - tzumainn - (jcoufal) - At the moment
[openstack-dev] Project-Scoped Service Catalog Entries
I've run into a use case that doesn't currently seem to have a great solution: Let's say my users want to use a top-of-stack OpenStack project such as Heat, Trove, etc. that I don't currently support in my deployment. There's absolutely no reason these services can't live happily in a VM talking to Nova, etc. via the normal APIs. However, in order to have a good experience (Horizon integration, seamless CLI integration) the service needs to be in the Service Catalog. One user could have their service added to the catalog by an admin, but then everyone in the cloud would be using their VM. And if you have multiple users all doing the same thing in their own projects, you've got collisions! So, I submit to you all that there is value in having a way to scope Service Catalog entries to specific projects, and to allow users with appropriate permissions on their project to add/remove those project-level service catalog entries. This could be accomplished in a number of ways: * Adding a new field to the model to store a Project ID. * Adding it in a standardized manner to service metadata as with https://blueprints.launchpad.net/keystone/+spec/service-metadata * Adding it as an additional requirement as proposed by https://blueprints.launchpad.net/keystone/+spec/auth-mechanisms-for-services * Use the existing Region field to track project scope as a hack. * Something else... I see this as analogous to Nova's concept of per-project flavors, or Glance's private/public/shared image capabilities. Allowing explicit sharing would even be an interesting option for service endpoints. It all depends how far we would want to go with it. Feel free to offer feedback or other suggestions. Thanks! - Gabriel ___ 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 on Tatiana Mazur being added to Core. I'm also okay with cleaning out the Core list. I considered doing it myself last cycle since none of those folks are involved anymore, but figured I'd leave them as a posthumous honor. ;-) I think now's a good time to trim it down. Glad I didn't make the axe list, - Gabriel -Original Message- From: Lyle, David [mailto:david.l...@hp.com] Sent: Tuesday, December 10, 2013 12:24 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Horizon] Nominations to Horizon Core 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] Abdicating the PTL Position
Hi all, It saddens me to say that for a mix of reasons I have decided to abdicate my position as PTL for Horizon. If anything, the reasons are all good ones overall, I just have to make the right decision for both myself and the project. In the interim David Lyle will be the acting PTL. The Horizon core team has all weighed in with their confidence in his abilities, and he has confirmed his ability and interest in doing so. There will be a nomination period in coming weeks to determine the PTL for the full release cycle, should anyone else wish to run for the job as well. Thierry will announce more information about that soon. Rest assured, you're not rid of me entirely; I'm just making a decision to focus in on other areas for a time. Horizon is blessed to have other phenomenal candidates willing and able to lead, and I would rather see the project in the hands of someone who can devote their full attention and energy to it. I will still be around and engaged (though not in Hong Kong). I'll catch you all next time around. All the best, - Gabriel Hurley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Abdicating the PTL Position
Thanks for the well-wishes (from everyone)! As I said, I'm not gone for good. By way of explanation, it's a combination of things: personal items I've put off too long (startup life, right?) and new responsibilities at Nebula (which will keep me at least partly engaged in OpenStack, just not on the Horizon side). All in all I hold myself to a high standard in anything I do, and looking at the next six months I saw my attention being split too many ways. At the same time I saw strong people in Horizon Core and knew the project would be in good hands so I chose to ensure that everyone and everything gets the attention it deserves, even if not all from me personally. In truth I probably care about Horizon more than I ought to. It's been my baby for the last 2+ years, long before I was PTL officially. I don't intend to see it decline or degrade at all, and given what the team has been talking about (and will discuss at the summit) I think the best is yet to come! - Gabriel From: Endre Karlson [mailto:endre.karl...@gmail.com] Sent: Thursday, October 31, 2013 2:52 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Horizon] Abdicating the PTL Position @Gabriel, thanks for an awesome time leading Horizon in towards what is now a awesome Framework / UI for OpenStack! I'm sure you'll bring awesome to whatever you're doing next! It's very sad to see good people leave the PTL positions but hey, time goes by and people do new things. Good luck and see you around dude, it was awesome to meet you in Portland in the last summit :) Endre. 2013/10/31 Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com Nevermind and ignore the last e-mail, it was wrongly intended. Endre 2013/10/31 Endre Karlson endre.karl...@gmail.commailto:endre.karl...@gmail.com Hey, I'm just curious. You quitting the PTL position to focus on Nebula efforts or ? 2013/10/31 Gabriel Hurley gabriel.hur...@nebula.commailto:gabriel.hur...@nebula.com Hi all, It saddens me to say that for a mix of reasons I have decided to abdicate my position as PTL for Horizon. If anything, the reasons are all good ones overall, I just have to make the right decision for both myself and the project. In the interim David Lyle will be the acting PTL. The Horizon core team has all weighed in with their confidence in his abilities, and he has confirmed his ability and interest in doing so. There will be a nomination period in coming weeks to determine the PTL for the full release cycle, should anyone else wish to run for the job as well. Thierry will announce more information about that soon. Rest assured, you're not rid of me entirely; I'm just making a decision to focus in on other areas for a time. Horizon is blessed to have other phenomenal candidates willing and able to lead, and I would rather see the project in the hands of someone who can devote their full attention and energy to it. I will still be around and engaged (though not in Hong Kong). I'll catch you all next time around. All the best, - Gabriel Hurley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
Re: [openstack-dev] Does openstack have a notification system that will let us know when a server changes state ?
The answer is sort of. Most projects (including Nova) publish to an RPC notifications channel (e.g. in rabbitMQ or whichever you use in your deployment). This is how Ceilometer gets some of its data. There is common code for connecting to the notification queue in Oslo (the rpc and notifier modules, particularly), but the exercise of actually setting up your consumer is left up to you, and there are various gotchas that aren't well-documented. Ceilometer's code is a reasonable starting point for building your own. As this is an area I've been experimenting with lately I'll say that once you get it all working it is certainly functional and will deliver exactly what you're asking for, but it can be a fair bit of engineering effort if you're not familiar with how these things work already. This is an area I hope can be improved in OpenStack in future releases. Hope that helps, - Gabriel From: openstack learner [mailto:openstacklea...@gmail.com] Sent: Friday, October 18, 2013 11:57 AM To: openst...@lists.openstack.org; openstack-dev@lists.openstack.org Subject: [openstack-dev] Does openstack have a notification system that will let us know when a server changes state ? Hi all, I am using the openstack python api. After I boot an instance, I will keep polling the instance status to check if its status changes from BUILD to ACTIVE. My question is: does openstack have a notification system that will let us know when a vm changes state (e.g. goes into ACTIVE state)? then we won't have to keep on polling it when we need to know the change of the machine state. Thanks xin ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] django-openstack-auth with Django 1.6
FWIW, Django 1.6 is not officially supported with Horizon yet. That aside, pickle is generally a security risk (it's equivalent to eval), hence the move away from it in Django. We'll want to see what we can do about making things properly serializable with the JSON serializer in Icehouse. It shouldn't be hard. Thank you for noting the temporary fix, though. - Gabriel From: Cristian Tomoiaga [mailto:ctomoi...@gmail.com] Sent: Thursday, October 17, 2013 11:06 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [horizon] django-openstack-auth with Django 1.6 Hello, It seems Django 1.6 switched from Pickle to Json for session serialization. https://docs.djangoproject.com/en/1.6/topics/http/sessions/#session-serialization For anyone getting the error about Token not being serializable, just add the following in settings.py: SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer' until this is fixed. Out of curiosity, should everything be switched to Json (make Token serializable), or Pickle will be used in the foreseeable future ? -- Regards, Cristian Tomoiaga ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] TC Candidacy
I hereby announce my candidacy to continue serving on the Technical Committee. My current qualifications: * Two prior terms actively engaged on the TC. * Horizon PTL for the Grizzly and Havana cycles. * Core Horizon developer since Essex, and Keystone Core since Folsom. * Author of the Core Values of Horizon: http://docs.openstack.org/developer/horizon/intro.html * Extensive depth and breadth of knowledge of all of the OpenStack projects and service APIs. * Aided both the OpenStack Translation team and the OpenStack UX Group in their initial formations and growth phases. * Ongoing advocate for OpenStack to provide a unified and sensible experience for end users. * Highly involved in discussions around the future of OpenStack. Here are what I see as the two most important issues facing OpenStack: 1. Presenting a unified experience for OpenStack, across all programs/projects, all APIs, the dashboard, and the documentation would do a HUGE amount to improve what we offer to our users. The level of frustration that OpenStack's users endure on a regular basis due to our fragmentation is a true pain. I see it as the job of the Technical Committee to provide leadership across projects and to bear in mind the needs of the broader community in ways that individual projects may not have insights into. 2. The ongoing question of the scope of OpenStack is of critical importance. Recent TC discussion and votes on Savanna, Trove, etc. have shown just how unclear people are on the where the edges of OpenStack are. This question has no easy answers and I want to continue to try and define those boundaries in the way that best supports the broader ecosystem around OpenStack. There are myriad other issues such as the engagement between the Foundation Board and the TC, coordination within OpenStack, and more, but I won't go into those now. Hopefully I've proven myself thus far to be a considered and well-reasoned member of the TC. It would be my honor to consider doing the good work of OpenStack. Thank you, - Gabriel Hurley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] core reviewers needed
Hi Kaiwai, First, the bad news: 1. The Horizon release candidate has already been cut, so for Havana we're only considering release-blocking bugs at this point (and even those have to meet a high bar to warrant a new release candidate). The feature freeze deadline was almost a month ago. 2. As Akihiro Motoki pointed out on the Launchpad ticket, this looks more like a small feature addition than a bug. Whether it should be tracked as a blueprint or a bug with the priority wishlist is debatable, but either way it's not something we can consider for a Havana RC2. The good news is that as of today Horizon's master branch is now open for Icehouse development, which means that reviews like this will start getting attention again. I don't see any immediate reasons why this shouldn't be accepted (pending real reviews), it will just go into the I1 milestone instead of the Havana final release. Thank you for your work in putting together the patch and working through the feature. I'm sorry the timing wasn't more fortuitous. All the best, - Gabriel -Original Message- From: f...@vmware.com [mailto:f...@vmware.com] Sent: Wednesday, October 02, 2013 11:44 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Horizon] core reviewers needed Dear Horizon core reviewers, I filed a bug recently (https://bugs.launchpad.net/horizon/+bug/1231248) to add Horizon UI support for Neutron NVP advanced service router. The Neutron plugin has been merged and we would like to have the Horizon UI support for Havanas release if possible. I have submitted the patch for review (https://review.openstack.org/#/c/48393/) as well. If you can spend sometime reviewing the bug/patch I'd really appreciate it. Thanks, -Kaiwei ___ 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
Re: [openstack-dev] [Tuskar] [UI] Introducing POC Wireframes
After reading your description in the other email, I might suggest the term “hardware profile” instead of “class”. Just a thought. - Gabriel From: Jaromir Coufal [mailto:jcou...@redhat.com] Sent: Wednesday, September 25, 2013 6:11 AM To: OpenStack Development Mailing List Cc: Gabriel Hurley Subject: Re: [openstack-dev] [Tuskar] [UI] Introducing POC Wireframes Hi Gabriel, thanks for follwoing this thread and having a look on wireframes. Regarding the term 'resource class', the naming is what we got into during our initial intents. It's not final version, so if there are concerns, there is no problem in finding more accurate one (we just couldn't find better). As for resource class definition, I tried to explain it a bit more in reply to Rob's mail (in this thread), so if you get that one, I hope it will help to answer and explain the concept of classes a little bit more. If you still have any concerns, let me know I will try to be more explicit. -- Jarda On 2013/25/09 02:03, Gabriel Hurley wrote: Really digging a lot of that. Particularly the inter-rack/inter-node communication stuff around page 36ish or so. I’m concerned about using the term “Class”. Maybe it’s just me as a developer, but I couldn’t think of a more generic, less inherently meaningful word there. I read through it and I still only vaguely understand what a “Class” is in this context. We either need better terminolody or some serious documentation/user education on that one. Also, I can’t quite say how, but I feel like the “Class” stuff ought to be meshed with the Resource side of things. The separation seems artificial and based more on the API structure (presumably?) than on the most productive user flow when interacting with that system. Maybe start with the question “if the system were empty, what would I need to do and how would I find it?” Very cool though. - Gabriel From: Jaromir Coufal [mailto:jcou...@redhat.com] Sent: Tuesday, September 24, 2013 2:04 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Tuskar] [UI] Introducing POC Wireframes Hey folks, I want to introduce our direction of Tuskar UI, currently described with POC wireframes. Keep in mind, that wireframes which I am sending were made for purpose of proof of concept (which was built and released in August) and there are various changes since then, which were already adopted. However, basic concepts are staying similar. Any updates for wireframes and future direction will be sent here to the dev-list for feedback and reviews. http://people.redhat.com/~jcoufal/openstack/tuskar/2013-07-11_tuskar_poc_wireframes.pdfhttp://people.redhat.com/%7Ejcoufal/openstack/tuskar/2013-07-11_tuskar_poc_wireframes.pdf Just quick description of what is happening there: * 1st step implementation - Layouts (page 2) - just showing that we are re-using all Horizon components and layouts * Where we are heading - Layouts (page 8) - possible smaller improvements to Horizon concepts - majority just smaller CSS changes in POC timeframe scope * Resource Management - Flavors (page 15) - ALREADY REMOVED - these were templates for flavors, which were part of selection in resource class creation process - currently the whole flavor definition moved under compute resource class completely (templates are no longer used) * Resource Management - Resources (page 22) - this is rack management - creation workflow was based on currently obsolete data (settings are going to be changed a bit) - upload rack needs to make sure that we know some standard csv file format (can we specify some?) - detail page of rack and node, which are going through enhancement process * Resource Management - Classes (page 40) - resource class management - few changes will happen here as well regarding creation workflow - detail page is going through enhancements as well as racks/nodes detail pages * Graphic Design - just showing the very similar look and feel as OpenStack Dashboard If you have any further questions, just follow this thread, I'll be very happy to answer as much as possible. Cheers, -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
Re: [openstack-dev] [Horizon] Ceilometer Alarm management page
3. There is a thought about watching correlation of multiple alarm histories in one Chart (either Alarm Histories, or the real statistics the Alarm is defined by). Do you think it will be needed? Any real life examples you have in mind? I think the first use case is to debug combined alarms. There's also a lot of potential to debug an entire platform activity by superimposing several alarm graphs. Yep, this is where it gets useful for admins. For a regular user a basic set of alarms is fine, you just want to react to certain conditions in your app/workload/whatever. But for an admin if you can correlate alarms to hosts and metrics and cross-project resource creation/deletion/etc. and start to understand the cloud as a whole. I think this is an end-game use case that's very valuable, and which many companies have built their entire businesses around (which is to say it's not an easy problem or a small problem, but the need is very real). 4. There is a thought about tagging the alarms by user defined tag, so user can easily group alarms together and then watch them together based on their tag. The alarm API don't provide that directly, but you can imagine some sort of filter based on description matching some texts. I'd love to see this as an extension to the alarm API. I think tracking metadata about alarms (e.g. tags or arbitrary key-value pairs) would be tremendously useful. 5. There is a thought about generating a default alarms, that could observe the most important things (verifying good behaviour, showing bad behaviour). Does anybody have an idea which alarms could be the most important and usable for everybody? I'm not sure you want to create alarm by default; alarm are resources, I don't think we should create resources without the user asking for it. Seconded. Maybe you were talking about generating alarm template? You could start with things like CPU usage staying at 90% for more than 1 hour, and having an action that alerts the user via mail. Same for disk usage. We do this kind of template for common user tasks with security group rules already. The same concept applies to alarms. 6. There is a thought about making overview pages customizable by the users, so they can really observe, what they need. (includes Ceilometer statistics and alarms) I think that could be as easy as picking the alarms you want in overviews with a very small and narrowed graph. Conceptually easy pickings, non-trivial work. But agreed. All the best, - Gabriel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tuskar] [UI] Introducing POC Wireframes
Really digging a lot of that. Particularly the inter-rack/inter-node communication stuff around page 36ish or so. I’m concerned about using the term “Class”. Maybe it’s just me as a developer, but I couldn’t think of a more generic, less inherently meaningful word there. I read through it and I still only vaguely understand what a “Class” is in this context. We either need better terminolody or some serious documentation/user education on that one. Also, I can’t quite say how, but I feel like the “Class” stuff ought to be meshed with the Resource side of things. The separation seems artificial and based more on the API structure (presumably?) than on the most productive user flow when interacting with that system. Maybe start with the question “if the system were empty, what would I need to do and how would I find it?” Very cool though. - Gabriel From: Jaromir Coufal [mailto:jcou...@redhat.com] Sent: Tuesday, September 24, 2013 2:04 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Tuskar] [UI] Introducing POC Wireframes Hey folks, I want to introduce our direction of Tuskar UI, currently described with POC wireframes. Keep in mind, that wireframes which I am sending were made for purpose of proof of concept (which was built and released in August) and there are various changes since then, which were already adopted. However, basic concepts are staying similar. Any updates for wireframes and future direction will be sent here to the dev-list for feedback and reviews. http://people.redhat.com/~jcoufal/openstack/tuskar/2013-07-11_tuskar_poc_wireframes.pdf Just quick description of what is happening there: * 1st step implementation - Layouts (page 2) - just showing that we are re-using all Horizon components and layouts * Where we are heading - Layouts (page 8) - possible smaller improvements to Horizon concepts - majority just smaller CSS changes in POC timeframe scope * Resource Management - Flavors (page 15) - ALREADY REMOVED - these were templates for flavors, which were part of selection in resource class creation process - currently the whole flavor definition moved under compute resource class completely (templates are no longer used) * Resource Management - Resources (page 22) - this is rack management - creation workflow was based on currently obsolete data (settings are going to be changed a bit) - upload rack needs to make sure that we know some standard csv file format (can we specify some?) - detail page of rack and node, which are going through enhancement process * Resource Management - Classes (page 40) - resource class management - few changes will happen here as well regarding creation workflow - detail page is going through enhancements as well as racks/nodes detail pages * Graphic Design - just showing the very similar look and feel as OpenStack Dashboard If you have any further questions, just follow this thread, I'll be very happy to answer as much as possible. Cheers, -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] PTL Candidacy
I hereby declare my candidacy for the Horizon PTL position. My current qualifications: * PTL for the Grizzly and Havana cycles. * Core developer on Horizon since Essex, and Keystone core since Folsom. * Primary architect of the existing Horizon framework. * Core developer for the Django web framework upon which Horizon is built. * Author of the Core Values of Horizon: http://docs.openstack.org/developer/horizon/intro.html * Extensive depth and breadth of knowledge of all of the OpenStack service APIs. * Helped shape the Keystone V3 API and Nova v3 API. * Provided the initial push to internationalize OpenStack as a whole in the Grizzly cycle which has now extended to all projects and dozens of translators. * Ongoing advocate for OpenStack to provide a unified and sensible experience for end users. * Highly engaged in discussions around the future of OpenStack. Things I can't directly take credit for but which happened under my watch (and I'd like to think with my guidance): * Overall contributor base has grown steadily with each release. * Core team expanded significantly in size and diversity. * New OpenStack projects have continued to be represented in each release. * Translation team actively engaged. * UX team formed and steadily becoming an active part of the design and development process. * Essex, Folsom, Grizzly and Havana releases have all been stable, high-quality, on-time, and both forwards and backwards compatible. What I see for Icehouse and beyond: * We have known goals for making Horizon truly event-driven. This is a large job and now is the time. * Downstream distros and large OpenStack providers have given feedback on their pain points; they center around packaging, configuration, and how to alter or remix the OpenStack Dashboard. We can and must improve in these areas. * More projects are entering and graduating from incubation each cycle. We will continue to fulfill our commitment to those projects, and the PTL must engage those projects leaders and their developers to drive their own integrations. * The UX community is giving great insight into how the usability of the dashboard can be improved as it grows. Navigation, user-oriented workflows, and responsive design are low-hanging fruit. * Providing raw data and tools are a base layer, but there are vast green fields for how we can anticipate user questions and needs and provide solutions that cover the 90% cases. * Visualizations and interactivity not only provide better experiences, they also help capture OpenStack mindshare. First impressions matter. * Better integration of help by collaborating with the Docs team connects the end users to the information they need when they need it most. * Multi-region, federation, hybrid public-private, etc. clouds are on the horizon (no pun intended) and we need to start thinking about these issues. All of these lists could go on, but these are the high level items. I want to close by saying that I'm thrilled that someone else in the Horizon community is interested in being PTL, and that the outcome is not a foregone conclusion. It is the highest order of success for a project that there are enough people with passion and vision that there's actually competition for the position. I don't intend to be PTL forever but I believe l have the right experience and vision to guide Horizon through Icehouse. Best of luck to all! - Gabriel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Bootstrap 3 update and problems with lesscpy
I'm also strongly against reverting the move to lesscpy. As David said, that change was highly-requested by the downstream distros and other folks packaging Horizon in various ways. Since there's no evidence that lesscpy does not intend to support bootstrap 3 in a reasonable timeframe, reverting the patch in the interim would simply be impatience. The better thing to do as a member of the larger open source community is to contribute your own energy to lesscpy and to help them improve their project in a timely manner. I'm glad to hear that Sasha is already working on that. I'm sure they're happy for the assistance and for having their work utilized by a significant project like Horizon. We'll get to bootstrap 3, but not by undoing work we've already done. Please keep us all updated on the progress upstream, I know I for one look forward to seeing the benefits we can derive from the newer bootstrap code. - Gabriel -Original Message- From: Lyle, David (Cloud Services) [mailto:david.l...@hp.com] Sent: Wednesday, September 18, 2013 8:44 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Horizon] Bootstrap 3 update and problems with lesscpy Right now, master in Horizon is still working toward Havana-rc1. We are still likely more than a week away from master moving to Icehouse-1. As this is the case, reverting a highly desired Havana change to address a blueprint for Icehouse that can be addressed properly upstream in lesscpy does not seem like a good course of action. I understand the amount of work involved in updating Bootstrap, but our goal should be to properly resolve the conflict once we are working on Icehouse. -David On Wednesday, September 18, 2013 6:27 AM Jiri Tomasek [mailto:jtoma...@redhat.com] wrote: Hi all, I've started working on updating Bootstrap to version 3 in Horizon. https://blueprints.launchpad.net/horizon/+spec/bootstrap-update As I have described in blueprint whiteboard, I am experiencing compile problems with the new lesscpy compiler that we started using recently. The compiled css code is incorrect and when running the compilation from terminal, about 200 syntax errors occur. This is related to certain features of Less not being supported by lesscpy. I have created a GIthub issue for lesscpy here: https://github.com/robotis/Lesscpy/issues/22 . Sasha Peilicke has already started working on updating the lesscpy library to support all less features needed to compile Bootstrap 3 properly. Although I think that it will take more than a few weeks before lesscpy is there where we need it. I have part of Bootstrap 3 update ready and as it is quite a large patch I would like to get this in as soon as possible because any rebase to a new Horizon master is quite tedious process. Also there are another blueprints that depend on this update (font-icons and css-breakdown, see dependency tree). So I would like to propose to revert the patch that introduces lesscpy library (a0739c9423 Drop NodeJS dependency in favor of pure-python lesscpy) and use the lessc library for the time being untill lesscpy is capable of compiling Bootstrap 3. I have revert patch ready together with update of lessc library in horizon/bin, which I can make part of Bootstrap-update blueprint and send them right away to gerrit for a review. I have also tested that with this setup the Bootstrap 3 updated Horizon less file compiles properly. When lesscpy is ready to support Bootstrap 3, geting back to lesscpy is then simple process of just reapplying the reverted commit. -- Jirka Tomasek ___ 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
Re: [openstack-dev] [keystone][horizon]Backend filtering in Keystone
While these are useful steps in isolation, I'm hesitant to just say go for it! because I see this as a problem that OpenStack as a whole needs to solve. Your implementation here is a good proof-of-concept that's likely worth vetting and then emulating elsewhere. However looking at it a different way it adds further fragmentation to the filtering, sorting, paging, etc. methods that Horizon has to attempt to support across all the projects. It's my intention to run a session on this at the summit and probably walk out of that summit with a Horizon will support X, so if you want people to have a good experience with your project in Horizon you should support X too kind of agreement that we can work towards across projects in Icehouse. That X will likely reflect what you've done here and the great discussions that happened recently about the possibility of doing away with pagination entirely. If the patch is ready to go then by all means merge it and we can start playing with it to see where it shines and where it needs polish. I'm all for it in principle. All the best, - Gabriel From: Henry Nash [mailto:hen...@linux.vnet.ibm.com] Sent: Wednesday, August 28, 2013 1:58 AM To: Gabriel Hurley Cc: OpenStack Development Mailing List; Dolph Mathews; Adam Young Subject: [keystone][horizon]Backend filtering in Keystone Hi Gabriel, Following up on our discussions on filtering and pagination, here's where we stand: 1) We have a patch ready to go into H that implements a framework that lets the keystone backend drivers implement filters (e.g. would be included in the SQL SELECT rather than being a post-prcessed filter on the full list, which is what happens today). See: https://review.openstack.org/#/c/43257/ . It includes the SQL drivers fixed up so they work with this, although it's unlikely we can get the LDAP one complete for H given the freeze (which just means queries to an LDAP backed entity will just work as they do today). 2) The above patch also lets a cloud provider set a limit on the number of rows return by a list query, to avoid excessively long responses and data in the case where the caller doesn't do a good job of filtering. We have two other changes ready, but are deferring to IceHouse: 3) The inexact filtering (e.g. GET /v3/users?name__startswitch=Hen) is coded and included in 1). However, since this is an API change we have it turned off, and will enable early in IceHouse. An API review for this is already posted (with you as one of the reviewers): https://review.openstack.org/#/c/43900/ 4) A separate patch is also ready for Pagination (https://review.openstack.org/#/c/43581/), using the simple page and per_page semantics. Given the contention over this, we'll discuss this at the HK summit I wanted to gauge how advantageous 1) and 2) are to you and the Horizon team? Some concerns have been raised (given how close we are to the freeze) as to whether we should push them in. Personally I'm OK with it, but wanted to balance that with real need (or not if you see these as only minor). Henry ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Modal form without redirect
If you look at the code in the post()[1] method of the base workflow view you'll note that a response to a successful workflow POST is always a redirect[2] (caveat for when it's specifically adding data back to a field, which isn't relevant here). The reason for this is that in general when you POST via a standard browser request you want to send back a redirect so that reloading the page, etc. behave correctly and don't potentially result in double-POSTs. If you're submitting the workflow via a regular HTTP from submit POST then I'd say redirecting is correct; you simply want to redirect to the current page. If you're doing this via AJAX then you'll want to add some new code to otherwise signal a successful response (both to the code and to the user) and to take action accordingly. Hope that helps, - Gabriel [1] https://github.com/openstack/horizon/blob/master/horizon/workflows/views.py#L130 [2] https://github.com/openstack/horizon/blob/master/horizon/workflows/views.py#L156 -Original Message- From: Toshiyuki Hayashi [mailto:haya...@ntti3.com] Sent: Tuesday, August 27, 2013 2:26 PM To: OpenStack-dev@lists.openstack.org Subject: [openstack-dev] [Horizon] Modal form without redirect Hi all, I'm working on custmoizing modal form for topology view, I would like to prevent redirecting after submitting. https://github.com/openstack/horizon/blob/master/horizon/static/horizon/ js/horizon.modals.js#L110 According to this code, if there is a no redirect_header, the modal form won't redirect. But I couldn't figure out how to remove redirect information from http header. For example, if I want to remove redirect from LaunchInstance https://github.com/openstack/horizon/blob/master/openstack_dashboard/ dashboards/project/instances/workflows/create_instance.py#L508 How should I do that? I tried success_url = None, but it doesn't work. If you have any idea, that would be great. Regards, Toshiyuki ___ 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
Re: [openstack-dev] [keystone] Pagination
I have been one of the earliest, loudest, and most consistent PITA's about pagination, so I probably oughta speak up. I would like to state three facts: 1. Marker + limit (e.g. forward-only) pagination is horrific for building a user interface. 2. Pagination doesn't scale. 3. OpenStack's APIs have historically had useless filtering capabilities. In a world where pagination is a must-have feature we need to have page number + limit pagination in order to build a reasonable UI. Ironically though, I'm in favor of ditching pagination altogether. It's the lowest-common denominator, used because we as a community haven't buckled down and built meaningful ways for our users to get to the data they really want. Filtering is great, but it's only 1/3 of the solution. Let me break it down with problems and high level solutions: Problem 1: I know what I want and I need to find it. Solution: filtering/search systems. Problem 2: I don't know what I want, and it may or may not exist. Solution: tailored discovery mechanisms. Problem 3: I need to know something about *all* the data in my system. Solution: reporting systems. We've got the better part of none of that. But I'd like to solve these issues. I have lots of thoughts on all of those, and I think the UX and design communities can offer a lot in terms of the usability of the solutions we come up with. Even more, I think this would be an awesome working group session at the next summit to talk about nothing other than how can we get rid of pagination? As a parting thought, what percentage of the time do you click to the second page of results in Google? All the best, - Gabriel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] how to add unmerged dependency to test-requirements
The short answer is: you can test and develop it locally but you cannot push it upstream until you get the dependencies released. As much as that may be frustrating, it prevents an enormous amount of pain which OpenStack has gone through in the past when things fail to be released as expected. Please work with the Neutron team to get their end of things done first. Thanks! - Gabriel -Original Message- From: Monty Taylor [mailto:mord...@inaugust.com] Sent: Wednesday, July 31, 2013 10:29 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Horizon] how to add unmerged dependency to test-requirements Hi! Not really. We don't support OpenStack projects having dependencies on unreleased software. What does fwaas come from? Is this part of neutron? On 08/01/2013 01:24 AM, Kuang-Ching Wang wrote: Hi, I am working on fwaas Horizon support, which requires fwaas CLI to work. Since fwaas CLI has not been merged (though it is functional), is there anyway I can specify the dependency in horizon/test-requirements file, such that Jenkins would be able to run for my horizon patch. Thanks! KC ___ 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 list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Long-term, how do we make heat image/flavor name agnostic?
Generally spot-on with what Adrian said, but I have one question from that email: Mappings is one of the high level concepts in CFN that I think can be completely eliminated with auto-discovery. What do you mean by this? What kind of autodiscovery, and where? I'm all for eliminating mappings someday if possible, but I haven't heard this proposal before. Enlighten me? Thanks! - Gabriel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] Long-term, how do we make heat image/flavor name agnostic?
I spent a bunch of time working with and understanding Heat in H2, and I find myself with one overarching question which I wonder if anyone's thought about or even answered already... At present, the CloudFormation template format is the first-class means of doing things in Heat. CloudFormation was created for Amazon, and Amazon has this massive convenience of having a (more or less) static list of images and flavors that they control. Therefore in CloudFormation everything is specified by a unique, specific name. OpenStack doesn't have this luxury. We have as many image and flavor names as we have deployments. Now, there are simple answers... 1. Name everything the way Amazon does, or 2. Alter your templates. But personally, I don't like either of these options. I think in the long term we win at platform/ecosystem by making it possible to take a template off the internet and having it work on *any* OpenStack cloud. To get there, we need a system that chooses images based on metadata (platform, architecture, distro) and flavors based on actual minimum requirements. Has anyone on the Heat team thought about this? Are there efforts in the works to alleviate this? Am I missing something obvious? All the best, - Gabriel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Horizon] Is there precedent for validating user input on data types to APIs?
I responded on the ticket as well, but here’s my take: An error like this should absolutely be caught before it raises a database error. A useful, human-friendly error message should be returned via the API. Any uncaught exception is a bug. On the other side of the equation, anything using the API (such as Horizon) should do its best to pre-validate the input, but if invalid input *is* sent it should be handled well. The best way to let Horizon devs know what the problem is is for the API to return an intelligent failure. All the best, - Gabriel From: Dirk Müller [mailto:d...@dmllr.de] Sent: Sunday, July 14, 2013 5:20 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Nova][Horizon] Is there precedent for validating user input on data types to APIs? Hi Matt, Given that the Nova API is public, this needs to be validated in the API, otherwise the security guys are unhappy. Of course the API shouldn't get bad data in the first place. That's a bug in nova client. I have sent reviews for both code fixes but I've not seen any serious reaction or approval on those for two weeks. Eventually somebody is going to look at it, I guess. Greetings, Dirk ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Ceilometer visualization in Horizon
Brooklyn Chen, Julie Pichon and others have already been putting in a lot of effort in this area. I suggest you check out https://blueprints.launchpad.net/horizon/+spec/ceilometer and sync up with them if you're interested in proceeding. - Gabriel -Original Message- From: Christian Berendt [mailto:bere...@b1-systems.de] Sent: Tuesday, July 09, 2013 1:29 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Ceilometer visualization in Horizon On 07/09/2013 09:32 AM, Matthias Runge wrote: d3 is already included in horizon. At the last summit, we agreed to use just a single graphing lib. This being said, I strongly suggest to try it. Will have a look at d3. -- Christian Berendt Cloud Computing Solution Architect Mail: bere...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 ___ 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
