Re: [openstack-dev] [requirements] - taskflow preventing sqla 0.8 upgrade
On 5 January 2014 04:22, Thomas Goirand wrote: > Sean, > > Before everything, I'd like to thank you for insisting in making the > transition to SQLA 0.8.x. > > Since it has been uploaded to Sid, this SQLA <0.7.99 has been without > any doubt the biggest reoccurring pain in the but with the packaging of > OpenStack. Without people like you, insisting again and again, I would > have loose hope that progress could happen in OpenStack! So thanks > again, Sean. > > We're even more into sci-fi when we see stuff like: > > pbr>=0.5.21,<1 > > Monty, did you decide you would release 1.0 with lots of backward > incompatibility? Has the topic been raised and I missed it??? I'm > convinced this isn't the case (and let's pretend it isn't, just until > the end of this message). Strictly speak, yes. More generously, this should be pbr>=0.5.21,<2 Because pbr is using semver, and 0.x has no stability guarantees, so the point when we will hit an incompatible change to a stable API is the 2 transition. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][external networks] "neutron net-external-list" returns empty list after restart of neutron-server
Hi all, I'm testing the Havana devstack and I noticed that after killing and restarting the neutron server public networks are not returned when queried via horizon or command line, which in Grizzly devstack the query returns the external network even after a quantum-server restart: Basically, before killing neutron-server, executing the below command as demo/demo/nova we have: /stack@host1:~$ neutron net-external-list // //+--++--+// //| id | name | subnets |// //+--++--+// //| 16c986b3-fa3d-4666-a6bd-a0dd9bfb5f19 | public | f0895c49-32ce-4ba2-9062-421c254892ec 172.24.4.224/28 |// //+--++--+// //stack@///host1/:~$ // / After killing and restarting neutron-server we have: /stack@///host1/:~$ neutron net-external-list / /stack@///host1/:~$ / I can get around this problem by making the "public" network/subnet shared then everything starts working, but after that I'm not able to revert it back to private again. In checking with grizzly version the external "public" network is listed for all tenants even when it is not shared, so making it shared is not a solution, only verification of what the problem is. First, I think this is a neutron bug, and want to report it if not reported already. I didn't find a bug report, but if you know of it please let me know. Second, I am looking for documentation that explains the security policy and permissions for external networks. Although by checking legacy and current behaviour it seems that all tenants should be able to list all external networks even if they aren't shared, I'm looking for documentation that explains the thinking and reasons behind this behaviour. Also confusing is if by default all tenants can see external networks then what is the purpose of the "shared" flag, and why once a network/subnet is shared it cannot be undone. Thanks in advance. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada
Folks, I finally got over my fear of weather and booked my flight and hotel for this sprint. I am relatively new to OpenStack community with a strong desire to learn and contribute. You may have seen that "Arista Testing" has come alive and is voting on the newly submitted neutron patches. I have been busy putting together the framework, and learning the Jenkins/Gerrit interface. Now, I have shifted my focus on Neutron/networking tempest tests. I notice some of these tests are failing on my setup. I have started to dig into these with the intent to understand them. In terms of this upcoming sprint, if you folks can give some pointers that will help me get better prepared and productive, that will be appreciated. Looking forward to meeting and working with you. regards.. -Sukhdev On Fri, Dec 27, 2013 at 9:00 AM, Anita Kuno wrote: > On 12/18/2013 04:17 PM, Anita Kuno wrote: > > Okay time for a recap. > > > > What: Neutron Tempest code sprint > > Where: Montreal, QC, Canada > > When: January 15, 16, 17 2014 > > Location: I am about to sign the contract for Salle du Parc at 3625 Parc > > avenue, a room in a residence of McGill University. > > Time: 9am - 5am > Time: 9am - 5pm > > > > I am expecting to see the following people in Montreal in January: > > Mark McClain > > Salvatore Orlando > > Sean Dague > > Matt Trenish > > Jay Pipes > > Sukhdev Kapur > > Miguel Lavelle > > Oleg Bondarev > > Rossella Sblendido > > Emilien Macchi > > Sylvain Afchain > > Nicolas Planel > > Kyle Mestery > > Dane Leblanc > > Sumit Naiksatam > > Henry Gessau > > Don Kehn > > Carl Baldwin > > Justin Hammond > > Anita Kuno > > > > If you are on the above list and can't attend, please email me so I have > > an up-to-date list. If you are planning on attending and I don't have > > your name listed, please email me without delay so that I can add you > > and you get done what you need to get done to attend. > > > > I have the contract for the room and will be signing it and sending it > > in with the room deposit tomorrow. Monty has about 6 more hours to get > > back to me on this, then I just have to go ahead and do it. > > > > Caterer is booked and I will be doing menu selection over the holidays. > > I can post the intended, _the intended_ menu once I have decided. Soup, > > salad, sandwich - not glamourous but hopefully filling. If the menu on > > the day isn't the same as what I post, please forgive me. Unforeseen > > circumstances may crop up and I will do my best to get you fed. One > > person has identified they have a specific food request, if there are > > any more out there, please email me now. This covers breakfast, lunch > > and tea/coffee all day. > Menu: > Breakfast: 8am - 10am > Fruit, Yogurt, Baked Items: ie. Muffins, Scones, Juice, Coffee, Tea > > Lunch: Noon - 2pm > Sandwiches: > Roast Beef with Stone Ground Mustard, > Smoked Turkey Breast with Cranberry Sauce, > Chicken Salad with Apples and Celery, > Flavoured Tortilla with Spinach and Sun-dried Tomatoes, > Smoked Meat, > Egg Salad, > Tuna with fresh Dill, > Black Forest Ham with aged Cheddar > on a variety of breads > > Soup: > Wednesday: Potato and Leek Cream Soup > Thursday: Sweet Potato and Red Pepper Bisque > Friday: Wild Rice and Smoked Turkey Soup > > Salad: > Green Garden Salad with Balsamic Vinaigrette > and > Wednesday: Greek Salad > Thursday: Tortellini Pesto Salad > Friday: Potato Aglio e Olio Salad > > Tea and Coffee all day > > This is to convey a sense of what to expect, items may change with no > notice. > > > > > Henry Gessau will be social convener for dinners. If you have some > > restaurant suggestions, please contact Henry. Organization of dinners > > will take place once we congregate in our meeting room. > > > > T-shirts: we decided that the code quality of Neutron was a higher > > priority than t-shirts. > > > > One person required a letter of invitation for visa purposes and > > received it. I hope the visa has been granted. > > > > Individuals arrangements for hotels seem to be going well from what I > > have been hearing. A few people will be staying at Le Nouvel Hotel, > > thanks for finding that one, Rosella. > > > > Weather: well you got me on this one. This winter is colder than we have > > had in some time and more snow too. So it will be beautiful but bring or > > buy warm clothes. A few suggestions: > > * layer your clothes (t-shirt, turtleneck, sweatshirt) > > * boots with removable liners (this is my boot of choice: > > http://amzn.to/19ddJve) remove the liners at the end of each day to dry > them > > * warm coat > > * toque (wool unless you are allergic) I'm seeing them for $35, don't > > pay that much, you should be able to get something warm for $15 or less > > * warm socks (cotton socks and wool over top)- keep your feet dry > > * mitts (mitts keep my fingers warmer than gloves) > > * scarf > > If the weather is making you panic, talk to me and I will see about > > bringing some of my extra accessories with me. The
Re: [openstack-dev] [requirements] - taskflow preventing sqla 0.8 upgrade
I was more of referring to general dependency issues, sqlalchemy hopefully never again but one never knows :P Sent from my really tiny device... > On Jan 4, 2014, at 8:40 AM, "Thomas Goirand" wrote: > >> On 01/05/2014 12:12 AM, Joshua Harlow wrote: >> it won't >> be the last time a library that is used in various projects >> causes dependency issues > > Please, tell me the opposite thing. Please tell me that this is the last > time we're having a discussion about problems with SQLA 0.8. Please tell > me that we're actually learning from these mistakes and that we'll see > improvements... > > Thomas > > Db Csq > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-devsaws ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements] - taskflow preventing sqla 0.8 upgrade
On 01/05/2014 12:12 AM, Joshua Harlow wrote: > it won't > be the last time a library that is used in various projects > causes dependency issues Please, tell me the opposite thing. Please tell me that this is the last time we're having a discussion about problems with SQLA 0.8. Please tell me that we're actually learning from these mistakes and that we'll see improvements... Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements] - taskflow preventing sqla 0.8 upgrade
Such a bad state seems like FUD. Taskflow was just syncing its requirements with the same requirements that everyone else is... Those global requirements have <0.7.99 in them as we speak (which is why taskflow picked up that version). The issue here will be worked through and fixed, it won't be the last time a library that is used in various projects causes dependency issues, so we are working through this process as we learn what works best. 1, don't sync with that requirements file to attempt to use the same version as integrating projects, or become more integrated with the gate... or a few other solutions that have been discussed... New release will happen early next week of taskflow with adjusted sqlalchemy upper bound. Sent from my really tiny device... > On Jan 4, 2014, at 7:27 AM, "Thomas Goirand" wrote: > >> On 01/04/2014 06:10 AM, Ivan Melnikov wrote: >>> On 04.01.2014 01:29, Sean Dague wrote: >>> On 01/03/2014 04:17 PM, Doug Hellmann wrote: >> [...] That's what made me think of the solution. But isn't setuptools in fact telling us that somehow the versions of things we expected to have installed are no longer installed and so something *is* broken (even if the versions of the installed libraries work together). >>> >>> It actually tells us that a human, somewhere, decided that their >>> software did not work with some combination of other software, and that >>> we are no longer able to correct their mistaken assumptions. >> [...] >> >> But sometimes humans are not wrong. For example, no released TaskFlow >> version really works with SQLAlchemy >= 0.8 -- that was fixed only >> recently (https://review.openstack.org/#/c/62661/). > > What's wrong is to allow taskflow to be added to the global-requirements > if it is in such a bad state, blocking such an important transition that > has been needed for more than 6 months. > > Thomas > > > ___ > 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] [requirements] - taskflow preventing sqla 0.8 upgrade
On 01/04/2014 07:53 AM, Joshua Harlow wrote: > So another idea that was talked about on IRC. > > Taskflow exposes entrypoints for these storage backends (like your storage > callback/interface idea). > > It currently provides 3 such 'default' backends [sqlalchemy, file/dir > based, in-memory <--> mainly for testing]. > > A 4th one is in progress for icehouse (zookeeper based). > > These backends are used to store intermediary 'flow/task' state (allowing > the taskflow engine to resume if an app crashes/stopped while doing stuff). > > A couple ideas about this, since its already pluggable. > > Split the sqlalchemy backend -> 'taskflow-sa' repo/new package. For those > projects that want to use this backend, they include it (still means > 'taskflow-sa' package has a dependency on sqlalchemy of some version). > Another idea is to move the sqlalchemy dependency currently in taskflow > requirements.txt -> taskflow test-requirements.txt and for those projects > that want to use the sqlalchemy backend, they include the sqlalchemy > version themselves in there requirements.txt (taskflow keeps it in > test-requirements.txt so that it can run its unit/integration tests, > making sure the backend still works). > > I'm not really sure which is the best, none seem super-great, but > sometimes u just work with what u got :-P Feel free to explore all kinds of direction you want, but *AFTER* we've moved to SQLA 0.8. It's been really too long already... Thanks for your understanding. Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements] - taskflow preventing sqla 0.8 upgrade
On 01/04/2014 06:10 AM, Ivan Melnikov wrote: > On 04.01.2014 01:29, Sean Dague wrote: >> On 01/03/2014 04:17 PM, Doug Hellmann wrote: > [...] >>> That's what made me think of the solution. But isn't setuptools in fact >>> telling us that somehow the versions of things we expected to have >>> installed are no longer installed and so something *is* broken (even if >>> the versions of the installed libraries work together). >> >> It actually tells us that a human, somewhere, decided that their >> software did not work with some combination of other software, and that >> we are no longer able to correct their mistaken assumptions. > [...] > > But sometimes humans are not wrong. For example, no released TaskFlow > version really works with SQLAlchemy >= 0.8 -- that was fixed only > recently (https://review.openstack.org/#/c/62661/). What's wrong is to allow taskflow to be added to the global-requirements if it is in such a bad state, blocking such an important transition that has been needed for more than 6 months. Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements] - taskflow preventing sqla 0.8 upgrade
Sean, Before everything, I'd like to thank you for insisting in making the transition to SQLA 0.8.x. Since it has been uploaded to Sid, this SQLA <0.7.99 has been without any doubt the biggest reoccurring pain in the but with the packaging of OpenStack. Without people like you, insisting again and again, I would have loose hope that progress could happen in OpenStack! So thanks again, Sean. On 01/03/2014 11:26 PM, Sean Dague wrote: > Given that sqla 0.9 just came out, I wanted to explore, again, what the > state of the world was with sqla 0.8 (especially given that Ubuntu and > Red Hat are both shipping 0.8 in their OpenStack bundles) - > https://review.openstack.org/#/c/64831/ > > The answer is not great. But more importantly, the answer is actually > worse than the last time we checked, which I think gives this some > urgency to move forward. For me, it's been urgent since the 6th of July... SQLA 0.8.2 was uploaded to Sid on the 6th of July. Since then, I've been bugging everyone on this list about it, explaining that I have no choice but to have Debian packages to support it (since I upload in Sid, and Sid has SQL 0.8.x). It seems I still haven't been heard. Now, we're 6 months after that, and after the release of Havana which happened more than 3 months after this, and after everything was fixed in all core packages (the last one was heat, at the end of August). So, in January 2014, I'm still fixing manually most requirements.txt, which still advertize for support of only SQL <0.7.99. I currently have fixes-SQLAlchemy-requirement.patch in Cinder, Neutron, and Nova (for Havana), just to allow it and stop the software to break because it was decided it is the case, even though they perfectly work with SQLA 0.8. Some other project have SQLAlchemy>=0.7.8,<=0.7.99 in the requirements.txt, but do not break as badly as these 3 just because of the bad declaration that doesn't reflect the reality (that's the case for Heat Keystone and Glance, for example). Something is going extremely wrong here. And seeing the actual result of the SQLA transition, I am really leaning toward thinking we have a process problem. What I believe is wrong, is that instead of having project wide decisions imposing some constraints, we have leaf packages that do. Until absolutely all of OpenStack is ready and fixed, then there's no constraint applied. This is the thing that must change. It shouldn't be this way. It should be from top to bottom. While I do understand that we do need the gate to be able to continue working with all projects at any given time, we still must find a solution so that this kind of 6 months transition never happens again. This really goes against the culture that we have inside OpenStack, and our common belief that things must be able to move fast. On 01/04/2014 04:13 AM, Sean Dague wrote:> > Because of entry points any library that specifies any dependencies > that OpenStack components specify, at incompatible levels, means that > library effectively puts a hold on the rest of OpenStack and prevents > it from being able to move forward. That's exactly the kind of *very bad* habits that needs to stop in OpenStack. On 01/04/2014 04:13 AM, Sean Dague wrote: > The only other option is that libraries we own (stackforge / oslo), > for condition to be included in global- requirements, *can never* > specify a maximum version of any dependency (and I really mean > never), and can never specify a minimum greater than current global > requirements. PLEASE !!! Let's do this !!! :) On 01/04/2014 05:29 AM, Sean Dague wrote: > It actually tells us that a human, somewhere, decided that their > software did not work with some combination of other software Often it's even worse. Sometimes, a human decide that, just it case, the software will declare itself incompatible with some non-existent future version of another software, even if there's no way to know. We're even more into sci-fi when we see stuff like: pbr>=0.5.21,<1 Monty, did you decide you would release 1.0 with lots of backward incompatibility? Has the topic been raised and I missed it??? I'm convinced this isn't the case (and let's pretend it isn't, just until the end of this message). So, how does one know that the thing he's using in PBR will be the thing that will cause trouble later on? For a version which hasn't been released yet?!? Who's the person with such a looking glass, who can predict the future? I'd like to know as well some stuff in my personal future... Please, let's stop this kind of non-sense and stop pretending we can tell if something is incompatible with a version of something else that doesn't even exist yet. It's hurting and slowing down the whole of OpenStack for no reason. > One of the key problems is taskflow, which has an sqla pin, which breaks > all the cinder entry points. This was actually entirely the problem > global requirements was meant to address, but it really can't when there > are nested requirements like
Re: [openstack-dev] [elastic-recheck] Thoughts on next steps
On 01/03/2014 12:09 PM, James E. Blair wrote: Sean Dague writes: So my feeling is we should move away from the point graphs we have, and present these as weekly and daily failure rates (with graphs and error bars). And slice those per job. My suggestion is that we do the actual visualization with matplotlib because it's super easy to output that from pandas data sets. I am very excited about this and everything above it! = Take over of /recheck = There is still a bunch of useful data coming in on "recheck bug " data which hasn't been curated into ER queries. I think the right thing to do is treat these as a work queue of bugs we should be building patterns out of (or completely invalidating). I've got a preliminary gerrit bulk query piece of code that does this, which would remove the need of the daemon the way that's currently happening. The gerrit queries are a little long right now, but I think if we are only doing this on hourly cron, the additional load will be negligible. I think this is fine and am all for reducing complexity, but consider this alternative: over the break, I moved both components of elastic-recheck onto a new server (status.openstack.org). Since they are now co-located, you could have the component of e-r that watches the stream to provide responses to gerrit also note recheck actions. You could stick the data in a file, memcache, trove database, etc, and the status page could display that "work queue". No extra daemons required. So I've got the bulk query written. Which means we could have this by the end of next week with the approach I've got. I think that handling the rest of this is an optimization. I think the main user-visible aspect of this decision is the delay before unprocessed bugs are made visible. If a bug starts affecting a number of jobs, it might be nice to see what bug numbers people are using for rechecks without waiting for the next cron run. So my experience is that most rechecks happen > 1 hr after a patch fails. And the people that are sitting on patches for bugs that have never been seen before find their way to IRC. The current state of the world is not all roses and unicorns. The recheck daemon has died, and not been noticed that it was dead for *weeks*. So a guarantee that we are only 1 hr delayed would actually be on average better than the delays we've seen over the last six months of following the event stream. And again, we can optimize that over time. I also think that caching should probably actually happen in gerritlib itself. There is a concern that too many things are hitting gerrit, and the result is that everyone is implementing their own client side caching to try to be nice. (like the pickles in Russell's review stats programs). This seems like the wrong place to do be doing it. But, part of the reason for this email was to sort these sorts of issues out, so let me know if you think the caching issue is an architectural blocker. Because if we're generally agreed on the architecture forward and are just reviewing for correctness, the code can move fast, and we can actually have ER 1.0 by the end of the month. Architecture review in gerrit is where we grind to a halt. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements] - taskflow preventing sqla 0.8 upgrade
On 01/03/2014 08:27 PM, Robert Collins wrote: On 4 January 2014 08:44, Doug Hellmann wrote: It seems safer to gate changes to libraries against the apps' trunk (to avoid making backwards-incompatible changes), and then gate changes to the apps against the released libraries (to ensure they work with something available to be packaged by the distros). There are lots and lots of version numbers available to us, so I see no problem with releasing new versions of libraries frequently. So we used to do that the apps against release libraries. And the result was more and more full day gate breaks. We did 2 consecutive ones in 2 weeks. Basically, once you get to be a certain level of coupled in OpenStack we can no longer let you manage your own requirements file. We need a global lever on it. Because people were doing it wrong, and slowly (we could go through specific examples about how bad this was. This was a top issue at nearly every summit I'd been at going back to Essex. Some reading from the break times: * http://lists.openstack.org/pipermail/openstack-dev/2013-July/011660.html * http://lists.openstack.org/pipermail/openstack-dev/2013-July/011708.html * http://lists.openstack.org/pipermail/openstack-dev/2013-July/012342.html (It was about 14 days to resolve the python client issue, there was a django issue around the same time that never made it to the list, as we did it all under fire in IRC) And we have a solution now. Which is one list of requirements that we can test everything with, that we can propose requirements updates speculatively, and see what works and what doesn't. And *after* we know they work, we propose the changes back into the projects, now automatically. I do see the issue Sean is pointing at, which is that we have to fix the libraries first and then the things that use them. OTOH thats normal in the software world, I don't see anything unique about it. Well, as the person that normally gets stuck figuring this out when .eu has been gate blocked for a day, and I'm one of the first people up on the east coast, I find the normal state of affairs unsatisfying. :) I also think that what we are basically dealing with is the classical N^2 comms problem. With N git trees that we need to all get working together, this gets exponentially more difficult over time. Which is why we created the integrated gate and the global requirements lever. Another solution would be reduce the number of OpenStack git trees to make N^2 more manageable, and let us with single commits affect multiple components. But that's not the direction we've taken. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
