[openstack-dev] periodic-stable job reports (was Re: [Openstack-stable-maint] Stable check of $THINGS failed)
As exciting as these emails are, I find them a bit unexciting. They don't give me any context to let me know whether this was a one-off or if something has been broken for a while. Long term, having a dashboard (see https://review.openstack.org/#/c/192253/ for the spec) will help us get better visibility into what these jobs are doing. But purely to scratch my own itch to get a better handle on what's happening right now, I grabbed some code Derek H has been using for a dashboard for the TripleO jobs and bashed at it a bit to make it a bit more generic. I've put the reports up at http://bruce.jamezpolley.com/reports/ This is *not* a first draft of the dashboard described in the spec, nor a prototype; it's purely something I pulled together to help me understand what data we can already pull out of Jenkins to help show the history of our jobs. But since I've got it online, I figured I may as well share it in case it's useful to anyone else as well. If you think having some kind of dashboard would be more useful than these emails, please go check out that spec so that we can start to make progress towards something useful. On Sun, Jul 19, 2015 at 4:22 PM A mailing list for the OpenStack Stable Branch test reports. openstack-stable-ma...@lists.openstack.org wrote: Build failed. - periodic-ironic-docs-juno http://logs.openstack.org/periodic-stable/periodic-ironic-docs-juno/943be60/ : FAILURE in 5m 51s - periodic-ironic-python26-juno http://logs.openstack.org/periodic-stable/periodic-ironic-python26-juno/0d25bc4/ : FAILURE in 6m 36s - periodic-ironic-python27-juno http://logs.openstack.org/periodic-stable/periodic-ironic-python27-juno/b8bcec1/ : FAILURE in 6m 51s - periodic-ironic-docs-kilo http://logs.openstack.org/periodic-stable/periodic-ironic-docs-kilo/47ee329/ : SUCCESS in 6m 06s - periodic-ironic-python27-kilo http://logs.openstack.org/periodic-stable/periodic-ironic-python27-kilo/c426b36/ : SUCCESS in 8m 17s ___ Openstack-stable-maint mailing list openstack-stable-ma...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint __ 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] [all][pbr] splitting our deployment vs install dependencies
On Mon, Apr 13, 2015 at 9:12 AM, Monty Taylor mord...@inaugust.com wrote: On 04/12/2015 06:43 PM, Robert Collins wrote: Right now we do something that upstream pip considers wrong: we make our requirements.txt be our install_requires. Upstream there are two separate concepts. install_requirements, which are meant to document what *must* be installed to import the package, and should encode any mandatory version constraints while being as loose as otherwise possible. E.g. if package A depends on package B version 1.5 or above, it should say B=1.5 in A's install_requires. They should not specify maximum versions except when that is known to be a problem: they shouldn't borrow trouble. deploy requirements - requirements.txt - which are meant to be *local to a deployment*, and are commonly expected to specify very narrow (or even exact fit) versions. That sounds, to me, very similar to a discussion we had a few weeks ago in the context of our stable branches. In that context, we have two competing requirements. One requirement is that our CI system wants a very tightly pinned requirements, as do downstream CI systems and deployers that want to test and deploy exact known-tested versions of things. On the other hand, downstream distributors (including OS packagers) need to balance OpenStack's version requirements with version requirements from all the other packages in their distribution; the tighter the requirements we list are, the harder it is for the requirements to work with the requirements of other packages in the distribution. tl;dr - I'm mostly in support of what you're saying - but I'm going to bludgeon it some. To be either fair or unfair, depending on how you look at it - some people upstream consider those two to be a pattern, but it is not encoded anywhere except in hidden lore that is shared between secret people. Upstream's tools have bumpkiss for support for this, and if we hadn't drawn a line in the sand encoding SOME behavior there would still be nothing. Nor, btw, is it the right split. It optimizes for the wrong thing. rust gets it wright. There is a Cargo.toml and a Cargo.lock, which are understood by the tooling in a manner similar to what you have described, and it is not just understood but DOCUMENTED that an _application_ should ship with a Cargo.lock and a _library_ should not. This sounds similar to a solution that was proposed for the stable branches: a requirements.in with mandatory version constraints while being as loose as otherwise possible, which is used to generate a requirements.txt which has the local to deployment exact versions that are used in our CI. The details of the proposal are in https://review.openstack.org/#/c/161047/ Without the library/application distinction, the effort in differentiating is misplaced, I believe - because it's libraries that need flexible depends - and applications where the specific set of depends that were tested in CI become important to consumers. What pbr, which nearly if not all OpenStack projects use, does, is to map the contents of requirements.txt into install_requires. And then we use the same requirements.txt in our CI to control whats deployed in our test environment[*]. and there we often have tight constraints like seen here - http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n63 That is, btw, because that's what the overwhelming majority of consumers assume those files mean. I take overwhelming majority from the days when we had files but did not process them automatically and everyone was confused. I'd like to align our patterns with those of upstream, so that we're not fighting our tooling so much. Ok. I mean, they don't have a better answer, but if it makes python hate us less, sweet. Concretely, I think we need to: - teach pbr to read in install_requires from setup.cfg, not requirements.txt - when there are requirements in setup.cfg, stop reading requirements.txt - separate out the global intall_requirements from the global CI requirements, and update our syncing code to be aware of this Then, setup.cfg contains more open requirements suitable for being on PyPI, requirements.txt is the local CI set we know works - and can be much more restrictive as needed. Thoughts? If there's broad apathy-or-agreement I can turn this into a spec for fine coverage of ramifications and corner cases. I'm concerned that it adds a layer of difference that is confusing to people for the sole benefit of pleasing someone else's pedantic worldview. I'm also concerned that dstufft is actively wanting to move towards a world where the build tooling is not needed or used as part of the install pipeline (metadata 2.0) -- so I'm concerned that we're aligning with a pattern that isn't very robust and isn't supported by tooling directly and that we're going to need to change understood usage
Re: [openstack-dev] BUG in OpenVSwitch Version ovs-vswitchd (Open vSwitch) 1.4.6
On Sat, Feb 7, 2015 at 5:09 AM, masoom alam masoom.a...@wanclouds.net wrote: raise DistributionNotFound(req)\npkg_resources.DistributionNotFound: alembic0.6.4,=0.4.1\n' It looks like your system is failing to find a version of alembic that satisfies those requirements. In your last post on this issue you said you had alembic 0.7.4 installed already. That doesn't satisfy the requirement for a version 0.6.4. Perhaps you need to uninstall that version, or downgrade to something that meets the requirements? Alternatively - it seems as though you may have a very old version of neutron-rootwrap. I don't know much about Neutron so maybe I'm reading this wrong, but require(\'neutron==2013.2.4.dev32\') suggests old age to me. Perhaps it would be possible to upgrade your version? FWIW, I tested in a virtualenv; with just alembic==0.7.4 installed, pip install -r requirements.txt on a file that contained alembic0.6.4,=0.4.1 was able to downgrade my environment from 0.7.4 to 0.6.3. It seems possible that maybe you could be talking to a PyPi proxy that is missing the older alembic packages, and that adding those packages to the proxy so they can be downloaded might possibly resolve your issue __ 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] [TripleO] nominating James Polley for tripleo-core
Thanks for the nomination Clint (and +1s from people who have already responded) At this stage, I believe we've traditionally[1] asked[2] the potential new Core Reviewer to commit to 3 reviews per work-day. I don't feel that that's a commitment I can make at this point. It's not something I've been able to achieve in the past - I've come close over the last 30 days, but the 90 day report shows me barely above 2 per day. I think my current throughput is something I can commit to maintaining, and I'd like to think that it can grow over time; but I don't think I can commit to doing anything more than I've already been able to do. If the rest of the core reviewers think I'm still making a valuable contribution, I'm more than happy to accept this nomination. [1] At least for the last 12 months or so, since I first started working on TripleO [2] more accurately, I believe we don't usually nominate a new Core until they've demonstrated their commitment by having already sustained 3 reviews per work-day for a few months [3] http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt On Wed, Jan 14, 2015 at 6:14 PM, Clint Byrum cl...@fewbar.com wrote: Hello! It has been a while since we expanded our review team. The numbers aren't easy to read with recent dips caused by the summit and holidays. However, I believe James has demonstrated superb review skills and a commitment to the project that shows broad awareness of the project. Below are the results of a meta-review I did, selecting recent reviews by James with comments and a final score. I didn't find any reviews by James that I objected to. https://review.openstack.org/#/c/133554/ -- Took charge and provided valuable feedback. +2 https://review.openstack.org/#/c/114360/ -- Good -1 asking for better commit message and then timely follow-up +1 with positive comments for more improvement. +2 https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec. 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this is only really about 7 - 10 working days and acceptable. +2 https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of recent change with alternatives to the approach submitted as patches. https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in agreement with everyone else. +1 https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with consideration for other reviewers. +2 https://review.openstack.org/#/c/113983/ -- Thorough spec review with grammar pedantry noted as something that would not prevent a positive review score. +2 All current tripleo-core members are invited to vote at this time. Thank you! __ 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
[openstack-dev] [TripleO] CI/CD report - 2014-12-20 - 2014-12-27
It's been a bad week for CI, mostly due to setuptools. Cores, please review https://review.openstack.org/#/c/144184/ immediately, as CI is currently broken. 2014-12-19 - Neutron committed a change which had a symlink. This broke pip install neutron, which broke CI for around 6 hours. 2014-12-22 - the release of pip 6.0 immediately triggered two distinct issues. One was fixed by 6.0.2 being released, the other required a patch to version specifiers in ceilometer. In total, CI was broken for around 24 hours. 2014-12-24 - new nodepool images were built which contained pip 6.0. This triggered another issue related to the fact that pip now creates ~/.cache if it doesn't already exist. At the time of writing, CI has been broken for ~3.5 days. https://review.openstack.org/#/c/144184/ seems to fix the problem, but it needs to get review from cores before it can land. Not listed here: setuptools 8.4 was released, then pulled after it was found to have problems installing/upgrading many packages. Because our CI was already broken, this had no noticeable effect. As always, most of this information is pulled from DerekH's notes on https://etherpad.openstack.org/p/tripleo-ci-breakages and more details can be found there. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [CI][TripleO][Ironic] check-tripleo-ironic-xxx fails
as I've said on https://bugs.launchpad.net/tripleo/+bug/1405732, suspecting this comes from sudo pip is a good pointer - but as far as I can tell our tripleo-ci scripts never run sudo pip. This seems to be something that's happening before the testenv gets handed to the tripleo-ci scripts. I've filed https://review.openstack.org/#/c/144107/ to clean up all the uses of sudo pip I can find in project-config, but I don't know if that will be sufficient. On Fri, Dec 26, 2014 at 12:13 PM, Denis Makogon dmako...@mirantis.com wrote: On Fri, Dec 26, 2014 at 11:01 AM, Adam Gandelman ad...@ubuntu.com wrote: This is fallout from a new upstream release of pip that went out earlier in the week. It looks like no formal bug ever got filed, tho the same problem discovered in devstack and trove's integration testing repository. Added some comments comments to the bug. Proper solution was merged into devstack (see [1]) and proposed for trove-integration (see [2]). So, it seems that we've faced with same problem across multiple projects that are relaying on pip. [1] https://review.openstack.org/#/c/143501 [2] https://review.openstack.org/#/c/143746/ Kind regards, Denis M. On Thu, Dec 25, 2014 at 10:59 PM, James Polley j...@jamezpolley.com wrote: Thanks for the alert The earliest failure I can see because of this is http://logs.openstack.org/43/141043/6/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/36c9771/ I've raised https://bugs.launchpad.net/tripleo/+bug/1405732 and I've put some preliminary notes on https://etherpad.openstack.org/p/tripleo-ci-breakages On Fri, Dec 26, 2014 at 3:42 AM, ZhiQiang Fan aji.zq...@gmail.com wrote: check-tripleo-ironic-xxx failed because: rm -rf /home/jenkins/.cache/image-create/pypi/mirror/ rm: cannot remove `/home/jenkins/.cache/image-create/pypi/mirror/': Permission denie see http://logs.openstack.org/37/143937/1/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/9be729b/console.html search on logstash.openstack.org: message:rm: cannot remove `/home/jenkins/.cache/image-create/pypi/mirror/\': Permission denied there are 59 hits in last 48 hours ___ 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 ___ 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] [CI][TripleO][Ironic] check-tripleo-ironic-xxx fails
Thanks for the alert The earliest failure I can see because of this is http://logs.openstack.org/43/141043/6/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/36c9771/ I've raised https://bugs.launchpad.net/tripleo/+bug/1405732 and I've put some preliminary notes on https://etherpad.openstack.org/p/tripleo-ci-breakages On Fri, Dec 26, 2014 at 3:42 AM, ZhiQiang Fan aji.zq...@gmail.com wrote: check-tripleo-ironic-xxx failed because: rm -rf /home/jenkins/.cache/image-create/pypi/mirror/ rm: cannot remove `/home/jenkins/.cache/image-create/pypi/mirror/': Permission denie see http://logs.openstack.org/37/143937/1/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/9be729b/console.html search on logstash.openstack.org: message:rm: cannot remove `/home/jenkins/.cache/image-create/pypi/mirror/\': Permission denied there are 59 hits in last 48 hours ___ 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] [TripleO] Weekly meeting roundup - midcycle confirmation, nomergepy blockage
We had a few topics come up in this week's meeting which we thought are worth drawing everyone's attention to You can see the full meeting logs at http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-12-16-19.01.log.html (the shorter meeting notes don't have much information) *No mergepy - blocked by bug 1401929* As part of our plans to move away from needing merge.py, Tomas Sedovic raised https://review.openstack.org/#/c/140375/ to make the f20 job use the no-mergepy options. Unfortunately this has run into a roadblock, discussed in https://bugs.launchpad.net/heat/+bug/1401929 (Overzealous validation of images in empty ResourceGroups). Steve Hardy is (I believe) working on a fix, targeted at kilo-2. In the meantime it'd be nice if we could find a workaround... *Mid-cycle dates confirmed - please RSVP* Clint has confirmed that we have the Seattle office booked for Feb 18-20. We have limisted space, so if you're planning to attend, *please visit https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup and add your name to the confirmed list, even if you previously indicated you were coming. *Currently we only have 8 confirmed attendees The etherpad also has a draft schedule and venue details. We aren't planning to arrange a group rate for the hotel, but there are many good hotels in a short distance from the HP office. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] CI/CD report - 2014-12-12 - 2014-12-19
Two major CI outages this week 2014-12-12 - 2014-12-15 - pip install MySQL-python failing on fedora - There was an updated mariadb-devel package, which caused pip install of the python bindings to fail as gcc could not build using the provided headers. - derekh put in a workaround on the 15th but we have to wait until upstream provides a fixed package for a permanent resolution 2014-12-17 - failures in many projects on py33 tests - Caused by an unexpected interaction between new features in pbr and the way docutils handles python3 compatibility - derekh resolved this by tweaking the build process to not build pbr - just download the latest pbr from upstream As always, more details can be found at https://etherpad.openstack.org/p/tripleo-ci-breakages The HP2 region is still struggling along trying to be built. I've created a trello board at https://trello.com/b/MXbIP2qe/tripleo-cd to track current roadblocks + the current outstanding patches we're using to build HP2. If you're a CD admin and would like to help get HP2 up and running, take a look at the board (and ping me when you hit something I've written in a way that only makes sense if you already understand the problem). If you're not a CD admin, a few of the patches need some simple tidyups. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] py33 jobs seem to be failing
Tweaking subject as this seems to be broader than just the clients It's been seen on os-apply-config as well; I've marked 1403557 as a dupe 1403510. It's also been reported on stackforge/yaql as well as python-*client There's been some discussion of this in #openstack-infra and it seems dstufft has identified the cause; I'll update 1403510 once we have confirmation that we know what the problem is. On Wed, Dec 17, 2014 at 5:09 PM, Steve Martinelli steve...@ca.ibm.com wrote: Wondering if anyone can shed some light on this, it seems like a few of the clients have been unable to build py33 environments lately: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiTmFtZUVycm9yOiBuYW1lICdTdGFuZGFyZEVycm9yJyBpcyBub3QgZGVmaW5lZFwiIGJ1aWxkX3N0YXR1czonRkFJTFVSRSciLCJmaWVsZHMiOlsibWVzc2FnZSIsImJ1aWxkX25hbWUiLCJidWlsZF9zdGF0dXMiXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI0MzIwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MTg4MzIzNzM5ODl9 If you want to see additional logs I went ahead and opened a bug against python-openstackclient since that's where I saw it first: https://bugs.launchpad.net/python-openstackclient/+bug/1403557 Though it seems at least glanceclient/neutronclient/keystoneclient are affected as well. The stack trace leads me to believe that docutils or sphinx is the culprit, but neither has released a new version in the time the bug has been around, so I'm not sure what the root cause of the problem is. Steve ___ 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] [all][gerrit] Showing all inline comments from all patch sets
But equally I think finding out why the New Screen still doesn't do what you want is valuable - it's likely other people want something similar to what you want, so this kind of feedback can be used to decide on future features On Wed, Dec 17, 2014 at 8:38 AM, Radoslav Gerganov rgerga...@vmware.com wrote: I am aware of this New Screen but it is not useful to me. I'd like to see comments grouped by patchset, file and commented line rather than a flat view mixed with everything else. Anyway, I guess there is no one-size-fits-all solution for this and everyone has different preferences which is cool. -Rado On 12/17/14, 8:58 AM, James Polley wrote: I was looking at the new change screen on https://review.openstack.org today[1] and it seems to do something vaguely similar. Rather than saying James polley made 4 inline comments, the contents of the comments are shown, along with a link to the file so you can see the context. Have you seen this? It seems fairly similar to what you're wanting. Have [1] To activate it, go to https://review.openstack.org/#/settings/preferences and set Change view to New Screen, then look at a change screen (such as https://review.openstack.org/#/c/127283/) On Tue, Dec 16, 2014 at 4:45 PM, Jeremy Stanley fu...@yuggoth.org mailto:fu...@yuggoth.org wrote: On 2014-12-16 17:19:55 +0200 (+0200), Radoslav Gerganov wrote: We don't need GoogleAppEngine if we decide that this is useful. We simply need to put the html page which renders the view on https://review.openstack.org. It is all javascript which talks asynchronously to the Gerrit backend. I am using GAE to simply illustrate the idea without having to spin up an entire Gerrit server. That makes a lot more sense--thanks for the clarification! I guess I can also submit a patch to the infra project and see how this works onhttps://review-dev.openstack.org if you want. If there's a general desire from the developer community for it, then that's probably the next step. However, ultimately this seems like something better suited as an upstream feature request for Gerrit (there may even already be thread-oriented improvements in the works for the new change screen--I haven't kept up with their progress lately). -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] mid-cycle details -- CONFIRMED Feb. 18 - 20
Is there a group hotel booking being arranged? On Tue, Dec 16, 2014 at 5:26 AM, Clint Byrum cl...@fewbar.com wrote: I'm happy to announce we've cleared the schedule and the Mid-Cycle is confirmed for February 18 - 20 in Seattle, WA at HP's downtown offices. Please refer to the etherpad linked below for details including address and instructions for access to the building. PLEASE make sure you add yourself to the list of confirmed attendees on the etherpad *BEFORE* booking travel. We have a hard limit of 30 participants, so if you are not certain you have a spot, please contact me before booking travel. Excerpts from Clint Byrum's message of 2014-12-01 14:58:58 -0800: Hello! I've received confirmation that our venue, the HP offices in downtown Seattle, will be available for the most-often-preferred least-often-cannot week of Feb 16 - 20. Our venue has a maximum of 20 participants, but I only have 16 possible attendees now. Please add yourself to that list _now_ if you will be joining us. I've asked our office staff to confirm Feb 18 - 20 (Wed-Fri). When they do, I will reply to this thread to let everyone know so you can all start to book travel. See the etherpad for travel details. https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup ___ 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] [all][gerrit] Showing all inline comments from all patch sets
I was looking at the new change screen on https://review.openstack.org today[1] and it seems to do something vaguely similar. Rather than saying James polley made 4 inline comments, the contents of the comments are shown, along with a link to the file so you can see the context. Have you seen this? It seems fairly similar to what you're wanting. Have [1] To activate it, go to https://review.openstack.org/#/settings/preferences and set Change view to New Screen, then look at a change screen (such as https://review.openstack.org/#/c/127283/) On Tue, Dec 16, 2014 at 4:45 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2014-12-16 17:19:55 +0200 (+0200), Radoslav Gerganov wrote: We don't need GoogleAppEngine if we decide that this is useful. We simply need to put the html page which renders the view on https://review.openstack.org. It is all javascript which talks asynchronously to the Gerrit backend. I am using GAE to simply illustrate the idea without having to spin up an entire Gerrit server. That makes a lot more sense--thanks for the clarification! I guess I can also submit a patch to the infra project and see how this works on https://review-dev.openstack.org if you want. If there's a general desire from the developer community for it, then that's probably the next step. However, ultimately this seems like something better suited as an upstream feature request for Gerrit (there may even already be thread-oriented improvements in the works for the new change screen--I haven't kept up with their progress lately). -- Jeremy Stanley ___ 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] [TripleO] CI report: 2014-12-5 - 2014-12-11
Resending with correct subject tag. Never send email before coffee. On Fri, Dec 12, 2014 at 9:33 AM, James Polley j...@jamezpolley.com wrote: In the week since the last email we've had no major CI failures. This makes it very easy for me to write my first CI report. There was a brief period where all the Ubuntu tests failed while an update was rolling out to various mirrors. DerekH worked around this quickly by dropping in a DNS hack, which remains in place. A long term fix for this problem probably involves setting up our own apt mirrors. check-tripleo-ironic-overcloud-precise-ha remains flaky, and hence non-voting. As always more details can be found here (although this week there's nothing to see) https://etherpad.openstack.org/p/tripleo-ci-breakages ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleP] CI report: 2014-12-5 - 2014-12-11
In the week since the last email we've had no major CI failures. This makes it very easy for me to write my first CI report. There was a brief period where all the Ubuntu tests failed while an update was rolling out to various mirrors. DerekH worked around this quickly by dropping in a DNS hack, which remains in place. A long term fix for this problem probably involves setting up our own apt mirrors. check-tripleo-ironic-overcloud-precise-ha remains flaky, and hence non-voting. As always more details can be found here (although this week there's nothing to see) https://etherpad.openstack.org/p/tripleo-ci-breakages ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Bug Squashing Day
How do you find the Australian at the international online meeting? You don't, they'll find you and make loud pointed remarks about your lack of understanding of the ramifications of the world being round, the IDL, and so on. On Wed, Dec 10, 2014 at 10:36 PM, Gregory Haynes g...@greghaynes.net wrote: A couple weeks ago we discussed having a bug squash day. AFAICT we all forgot, and we still have a huge bug backlog. I'd like to propose we make next Wed. (12/17, in whatever 24 window is Wed. in your time zone) a bug squashing day. Hopefully we can add this as an item to our weekly meeting on Tues. to help remind everyone the day before. Luckily next week's meeting is the UTC1900 meeting - so for Europe that's Tuesday night, and for Christchurch and Sydney that's 9am and 6am respectively. The meeting we had earlier today was at 9am Wednesday CET (still time for a reminder) - 10pm/8pm Wednesday in Christchurch/Sydney. On any case, I've added a note to the agenda ( https://wiki.openstack.org/wiki/Meetings/TripleO#One-off_agenda_items) and linked it back to the original discussion ( http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-12-02-19.06.log.html#l-32 ) Cheers, Greg -- Gregory Haynes g...@greghaynes.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
Re: [openstack-dev] [TripleO] Bug Squashing Day
My previous email is a long-winded whinging-aussie way of saying that I think the bug-squashing day is a great idea, and I think Wednesday sounds like a great day for it. On Wed, Dec 10, 2014 at 11:01 PM, James Polley j...@jamezpolley.com wrote: How do you find the Australian at the international online meeting? You don't, they'll find you and make loud pointed remarks about your lack of understanding of the ramifications of the world being round, the IDL, and so on. On Wed, Dec 10, 2014 at 10:36 PM, Gregory Haynes g...@greghaynes.net wrote: A couple weeks ago we discussed having a bug squash day. AFAICT we all forgot, and we still have a huge bug backlog. I'd like to propose we make next Wed. (12/17, in whatever 24 window is Wed. in your time zone) a bug squashing day. Hopefully we can add this as an item to our weekly meeting on Tues. to help remind everyone the day before. Luckily next week's meeting is the UTC1900 meeting - so for Europe that's Tuesday night, and for Christchurch and Sydney that's 9am and 6am respectively. The meeting we had earlier today was at 9am Wednesday CET (still time for a reminder) - 10pm/8pm Wednesday in Christchurch/Sydney. On any case, I've added a note to the agenda ( https://wiki.openstack.org/wiki/Meetings/TripleO#One-off_agenda_items) and linked it back to the original discussion ( http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-12-02-19.06.log.html#l-32 ) Cheers, Greg -- Gregory Haynes g...@greghaynes.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
Re: [openstack-dev] [neutron][TripleO] Clear all flows when ovs agent start? why and how avoid?
On Fri, Oct 31, 2014 at 3:28 PM, Ben Nemec openst...@nemebean.com wrote: On 10/29/2014 10:17 AM, Kyle Mestery wrote: On Wed, Oct 29, 2014 at 7:25 AM, Hly henry4...@gmail.com wrote: Sent from my iPad On 2014-10-29, at 下午8:01, Robert van Leeuwen robert.vanleeu...@spilgames.com wrote: I find our current design is remove all flows then add flow by entry, this will cause every network node will break off all tunnels between other network node and all compute node. Perhaps a way around this would be to add a flag on agent startup which would have it skip reprogramming flows. This could be used for the upgrade case. I hit the same issue last week and filed a bug here: https://bugs.launchpad.net/neutron/+bug/1383674 From an operators perspective this is VERY annoying since you also cannot push any config changes that requires/triggers a restart of the agent. e.g. something simple like changing a log setting becomes a hassle. I would prefer the default behaviour to be to not clear the flows or at the least an config option to disable it. +1, we also suffered from this even when a very little patch is done I'd really like to get some input from the tripleo folks, because they were the ones who filed the original bug here and were hit by the agent NOT reprogramming flows on agent restart. It does seem fairly obvious that adding an option around this would be a good way forward, however. Since nobody else has commented, I'll put in my two cents (though I might be overcharging you ;-). I've also added the TripleO tag to the subject, although with Summit coming up I don't know if that will help. Summit did lead to some delays - I started this response and then got distracted, and only just found the draft again Anyway, if the bug you're referring to is the one I think, then our issue was just with the flows not existing. I don't think we care whether they get reprogrammed on agent restart or not as long as they somehow come into existence at some point. Is https://bugs.launchpad.net/bugs/1290486 the bug in you'rethinking of? That seems to have been solved with https://review.openstack.org/#/c/96919/ My memory of that problem is that prior to 96919, when the daemon was restarted, existing flows were thrown away. We'd end up with just a NORMAL flow, which didn't route the traffic where we need it. The fix implemented there seems to have been to implement a canary rule to detect when this happens - ie, detect that all the existing flows had been thrown away. Once we know they've been thrown away, we know we need to recreate the flows that were thrown away when the daemon restarted. If my memory is correct (and it may not be, I'm not 100% sure I fully understood the problem at the time), the root cause here is not the change added in 96919 - by the time that code is triggered and the flows are reprogrammed, they've already been lost. It's possible I'm wrong about that, and probably the best person to talk to would be Robert Collins since I think he's the one who actually tracked down the problem in the first place. I think (if I'm looking at the right bug) that you're referring to his comment: we're trying to do things before ovs-db is up and running and neutron- openvswitch-agent is not handling ovs-db being down properly - it should back off and retry, or alternatively, do a full sync once the db is available. As far as I can tell, everything after that point (ie, once I got involved) focused on the latter, which is why we ended up with the canary and the reprogramming. Assuming he's right about the race condition, it sounds as though fixing that might be preferable. Later discussion on this thread has centered around a full flow-synchornization approach: it sounds to me as though handling the db being unavailable will need to be part of that approach (we don't want to synchronize towards no rules just because we can't get a canonical list of rules from the DB) -Ben ___ 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] [TripleO] Meeting purpose
Hi all, The other topic that has come up a few times in our meetings is: what value do we get from these meetings? There's no doubt that regular meetings provide value - but that doesn't mean that everything we do in them is valuable. As an example of something that I think doesn't add much value in the meeting - DerekH has already been giving semi-regular CI/CD status reports via email. I'd like to make these weekly update emails regular, and take the update off the meeting agenda. I'm offering to share the load with him to make this easier to achieve. Are there other things on our regular agenda that you feel aren't offering much value? Are there things you'd like to see moved onto, or off, the agenda? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Alternate meeting time
Just taking a look at http://doodle.com/27ffgkdm5gxzr654 again - we've had 10 people respond so far. The winning time so far is Monday 2100UTC - 7 yes and one If I have to. ... but the 2 people who can't make that time work in UTC or CET. Finding a time that includes those people rules out people who work in Eastern Australia and New Zealand. Purely in terms of getting the biggest numbers in, Monday 2100UTC seems like the most workable time so far. On Tue, Dec 2, 2014 at 4:25 PM, Derek Higgins der...@redhat.com wrote: On 02/12/14 15:12, Giulio Fidente wrote: On 12/02/2014 03:45 PM, Derek Higgins wrote: On 02/12/14 14:10, James Polley wrote: Months ago, I pushed for us to alternate meeting times to something that was friendlier to me, so we started doing alternate weeks at 0700UTC. That worked well for me, but wasn't working so well for a few people in Europe, so we decided to give 0800UTC a try. Then DST changes happened, and wiki pages got out of sync, and there was confusion about what time the meeting is at.. The alternate meeting hasn't been very well attended for the last ~3 meetings. Partly I think that's due to summit and travel plans, but it seems like the 0800UTC time doesn't work very well for quite a few people. So, instead of trying things at random, I've created https://etherpad.openstack.org/p/tripleo-alternate-meeting-time as a starting point for figuring out what meeting time might work well for the most people. Obviously the world is round, and people have different schedules, and we're never going to get a meeting time that works well for everyone - but it'd be nice to try to maximise attendance (and minimise inconvenience) as much as we can. If you regularly attend, or would like to attend, the meeting, please take a moment to look at the etherpad to register your vote for which time works best for you. There's even a section for you to cast your vote if the UTC1900 meeting (aka the main or US-Friendly meeting) works better for you! Can I suggest an alternative data gathering method, I've put each hour in a week in a poll, for each slot you have 3 options I think it is great, but would be even better if we could trim it to just a *single* day and once we agreed on the timeframe, we decide on the day as that probably won't count much so long as it is a weekday I suppose I think leaving the whole week in there is better, some people may have different schedules on different weekdays, me for example ;-) ___ 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] [TripleO] Alternate meeting time
On Thu, Dec 4, 2014 at 11:40 AM, marios mar...@redhat.com wrote: On 04/12/14 11:40, James Polley wrote: Just taking a look at http://doodle.com/27ffgkdm5gxzr654 again - we've had 10 people respond so far. The winning time so far is Monday 2100UTC - 7 yes and one If I have to. for me it currently shows 1200 UTC as the preferred time. You're the 11th responder :) And yes, 1200/1400/1500 are now all leading with 8/0/3. So to be clear, we are voting here for the alternate meeting. The 'original' meeting is at 1900UTC. If in fact 2100UTC ends up being the most popular, what would be the point of an alternating meeting that is only 2 hours apart in time? To me the point would be to get more people able to come along to the meeting. But if the difference *was* that small, I'd be wanting to ask if changing the format or content of the meeting could convince more people to join the 1900UTC meeting - I think that having just one meeting for the whole team would be preferable, if we could manage it. But at present, it looks like if we want to maximise attendance, we should be focusing on European early afternoon. That unfortunately means that it's going to be very hard for those of us in Australia/New Zealand/China/Japan to make it - 1400UTC is 1am Sydney, 10pm Beijing. It's 7:30pm New Delhi, which might be doable, but I don't know of anyone working there who would regularly attend. ... but the 2 people who can't make that time work in UTC or CET. Finding a time that includes those people rules out people who work in Eastern Australia and New Zealand. Purely in terms of getting the biggest numbers in, Monday 2100UTC seems like the most workable time so far. On Tue, Dec 2, 2014 at 4:25 PM, Derek Higgins der...@redhat.com mailto:der...@redhat.com wrote: On 02/12/14 15:12, Giulio Fidente wrote: On 12/02/2014 03:45 PM, Derek Higgins wrote: On 02/12/14 14:10, James Polley wrote: Months ago, I pushed for us to alternate meeting times to something that was friendlier to me, so we started doing alternate weeks at 0700UTC. That worked well for me, but wasn't working so well for a few people in Europe, so we decided to give 0800UTC a try. Then DST changes happened, and wiki pages got out of sync, and there was confusion about what time the meeting is at.. The alternate meeting hasn't been very well attended for the last ~3 meetings. Partly I think that's due to summit and travel plans, but it seems like the 0800UTC time doesn't work very well for quite a few people. So, instead of trying things at random, I've created https://etherpad.openstack.org/p/tripleo-alternate-meeting-time as a starting point for figuring out what meeting time might work well for the most people. Obviously the world is round, and people have different schedules, and we're never going to get a meeting time that works well for everyone - but it'd be nice to try to maximise attendance (and minimise inconvenience) as much as we can. If you regularly attend, or would like to attend, the meeting, please take a moment to look at the etherpad to register your vote for which time works best for you. There's even a section for you to cast your vote if the UTC1900 meeting (aka the main or US-Friendly meeting) works better for you! Can I suggest an alternative data gathering method, I've put each hour in a week in a poll, for each slot you have 3 options I think it is great, but would be even better if we could trim it to just a *single* day and once we agreed on the timeframe, we decide on the day as that probably won't count much so long as it is a weekday I suppose I think leaving the whole week in there is better, some people may have different schedules on different weekdays, me for example ;-) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Meeting purpose
On Thu, Dec 4, 2014 at 3:35 PM, Jay Dobies jason.dob...@redhat.com wrote: As an example of something that I think doesn't add much value in the meeting - DerekH has already been giving semi-regular CI/CD status reports via email. I'd like to make these weekly update emails regular, and take the update off the meeting agenda. I'm offering to share the load with him to make this easier to achieve. The Tuskar item is the same way. Not sure how that was added as an explicit agenda item, but I don't see why we'd call out to one particular project within TripleO. Anything we'd need eyes on should be covered when we chime in about specs or reviews needing eyes. Are there other things on our regular agenda that you feel aren't offering much value? I'd propose we axe the regular agenda entirely and let people promote things in open discussion if they need to. In fact the regular agenda often seems like a bunch of motions we go through... to the extent that while the TripleO meeting was going on we've actually discussed what was in my opinion the most important things in the normal #tripleo IRC channel. Is getting through our review stats really that important!? I think the review stats would be better handled in e-mail format like Derek's CI status e-mails. We don't want the reviews to get out of hand, but the time spent pasting in the links and everyone looking at the stats during the meeting itself are wasteful. I could see bringing it up if it's becoming a problem, but the number crunching doesn't need to be part of the meeting. I agree; I think it's useful to make sure we keep on top of the stats, but I don't think it needs to be done in the meeting. Are there things you'd like to see moved onto, or off, the agenda? Perhaps a streamlined agenda like this would work better: * Bugs This one is valuable and I like the idea of keeping it. * Projects needing releases Is this even needed as well? It feels like for months now the answer is always Yes, release the world. But the next question is: Who is going to release the world? and that is usually a volunteer from the meeting. Perhaps if we had a regular release team this could be arranged outside of the meeting. I think our cadence on those release can be slowed down as well (the last few releases I've done have had minimal churn at best), but I'm not trying to thread jack into that discussion. I bring it up because we could remove that from the meeting and do an entirely new model where we get the release volunteer through other means on a (potentially) less frequent release basis. * Open Discussion (including important SPECs, CI, or anything needing attention). ** Leader might have to drive this ** I like the idea of a specific Specs/Reviews section. It should be quick, but a specific point in time where people can #info a review they need eyes on. I think it appeals to my OCD to have this more structured than interspersed with other topics in open discussion. One issue I have with these is that I don't know if they get seen by people who aren't at the meeting. Perhaps a weekly email pointing to the minutes and hilighing these would help? ___ 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] [TripleO] Alternate meeting time
Months ago, I pushed for us to alternate meeting times to something that was friendlier to me, so we started doing alternate weeks at 0700UTC. That worked well for me, but wasn't working so well for a few people in Europe, so we decided to give 0800UTC a try. Then DST changes happened, and wiki pages got out of sync, and there was confusion about what time the meeting is at.. The alternate meeting hasn't been very well attended for the last ~3 meetings. Partly I think that's due to summit and travel plans, but it seems like the 0800UTC time doesn't work very well for quite a few people. So, instead of trying things at random, I've created https://etherpad.openstack.org/p/tripleo-alternate-meeting-time as a starting point for figuring out what meeting time might work well for the most people. Obviously the world is round, and people have different schedules, and we're never going to get a meeting time that works well for everyone - but it'd be nice to try to maximise attendance (and minimise inconvenience) as much as we can. If you regularly attend, or would like to attend, the meeting, please take a moment to look at the etherpad to register your vote for which time works best for you. There's even a section for you to cast your vote if the UTC1900 meeting (aka the main or US-Friendly meeting) works better for you! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Alternate meeting time
On Tue, Dec 2, 2014 at 3:22 PM, marios mar...@redhat.com wrote: On 02/12/14 16:10, James Polley wrote: Months ago, I pushed for us to alternate meeting times to something that was friendlier to me, so we started doing alternate weeks at 0700UTC. That worked well for me, but wasn't working so well for a few people in Europe, so we decided to give 0800UTC a try. Then DST changes happened, and wiki pages got out of sync, and there was confusion about what time the meeting is at.. The alternate meeting hasn't been very well attended for the last ~3 meetings. Partly I think that's due to summit and travel plans, but it seems like the 0800UTC time doesn't work very well for quite a few people. So, instead of trying things at random, I've created https://etherpad.openstack.org/p/tripleo-alternate-meeting-time as a starting point for figuring out what meeting time might work well for the most people. Obviously the world is round, and people have different schedules, and we're never going to get a meeting time that works well for everyone - but it'd be nice to try to maximise attendance (and minimise inconvenience) as much as we can. If you regularly attend, or would like to attend, the meeting, please take a moment to look at the etherpad to register your vote for which time works best for you. There's even a section for you to cast your vote if the UTC1900 meeting (aka the main or US-Friendly meeting) works better for you! slight clarification - are we discussing which time would suit best for the alternative meeting, or that we are scrapping the alternate, and re-voting for the best main meeting time. In either case the proposed times are still mostly not EU friendly (I guess the 1800 UTC would be ok for UK), thanks, marios I was only intending to talk about the best time for the alternate meeting. The main/US/original meeting time still seems to have been fairly well attended lately, aside from the interruption due to summit; I haven't been aware of any meetings that got abandoned or shortened due to lack of participants in that timezone (except for the week of summit), and I haven't heard anyone in that meeting talking about how hard it is for them to make the meeting. But perhaps I'm not hearing the people who'd like to be at that meeting - maybe because they can't *be* at the meeting to be heard? Derek has suggested a Doodle poll to help us look at which hours across the week people would find it possible to make the meeting - I think the data it gathers would help us figure out if it's worth considering moving the US meeting time as well. If there are other people who'd like to move the time of the US meeting so they can make it, now is probably a good time to speak up! ___ 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] [TripleO] Alternate meeting time
On Tue, Dec 2, 2014 at 4:12 PM, Giulio Fidente gfide...@redhat.com wrote: On 12/02/2014 03:45 PM, Derek Higgins wrote: On 02/12/14 14:10, James Polley wrote: Months ago, I pushed for us to alternate meeting times to something that was friendlier to me, so we started doing alternate weeks at 0700UTC. That worked well for me, but wasn't working so well for a few people in Europe, so we decided to give 0800UTC a try. Then DST changes happened, and wiki pages got out of sync, and there was confusion about what time the meeting is at.. The alternate meeting hasn't been very well attended for the last ~3 meetings. Partly I think that's due to summit and travel plans, but it seems like the 0800UTC time doesn't work very well for quite a few people. So, instead of trying things at random, I've created https://etherpad.openstack.org/p/tripleo-alternate-meeting-time as a starting point for figuring out what meeting time might work well for the most people. Obviously the world is round, and people have different schedules, and we're never going to get a meeting time that works well for everyone - but it'd be nice to try to maximise attendance (and minimise inconvenience) as much as we can. If you regularly attend, or would like to attend, the meeting, please take a moment to look at the etherpad to register your vote for which time works best for you. There's even a section for you to cast your vote if the UTC1900 meeting (aka the main or US-Friendly meeting) works better for you! Can I suggest an alternative data gathering method, I've put each hour in a week in a poll, for each slot you have 3 options I think it is great, but would be even better if we could trim it to just a *single* day and once we agreed on the timeframe, we decide on the day as that probably won't count much so long as it is a weekday I suppose *hand-waggle* I thought that at first too, but then I remembered that I had regular commitments on thursday nights all of last year, but this year it's shifted to wednesday night. I'd prefer to keep those nights more free than other nights, if I can. -- Giulio Fidente GPG KEY: 08D733BA ___ 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] [TripleO] Finding old reviews for action
At the mid-cycle, there was some discussion around using our weekly meeting time to find 5 old reviews and assign people to shepherd those reviews - either marking them as abandoned if there hasn't been any action, or rounding up reviewers or people to help make changes if required to drive it forward. What we didn't nail down at the time was how to find the 5 reviews. Because of the ambiguity, we spent some time a few weeks ago trying to decide on a method. Full logs are at [1] but in short we settled on using the Longest waiting reviews (based on latest revision): from [2]. I'm mentioning this on the list so that (A) we can be consistent across meetings in how we look for issues that need attention, (B) so that other people can suggest other methods of finding the reviews that need attention, if this isn't the best method, and (C) in case this set of reviews is something we might want to surface elsewhere (sadly, I don't believe it can't be surfaced in a Gerrit dashboard, unless Gerrit can now handle any sorting other than newest-first) [1] http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-11-12-08.16.log.html [2] http://russellbryant.net/openstack-stats/tripleo-openreviews.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Meeting time update
On Wed, Sep 3, 2014 at 2:27 PM, Thierry Carrez thie...@openstack.org wrote: Tomas Sedovic wrote: As you all (hopefully) know, our meetings alternate between Tuesdays 19:00 UTC and Wednesdays 7:00 UTC. Because of the whining^W weekly-expressed preferences[1] of the Europe-based folks, the latter meetings are going to be moved by +1 hour. So the new meeting times are: * Tuesdays at 19:00 UTC (unchanged) * Wednesdays at 8:00 UTC (1 hour later) The first new EU-friendly meeting will take place on Wednesday 17th September. The wiki page has been updated accordingly: https://wiki.openstack.org/wiki/Meetings/TripleO I've now also updated https://wiki.openstack.org/wiki/Meetings#TripleO_team_meeting to list the same time but I don't know how to reflect the change in the iCal feed. Anyone willing to do that, please? Time updated. For some reason I don't get notified on that page change anymore. Sigh. Also: http://lists.openstack.org/pipermail/openstack-infra/2013-December/000517.html -- Thierry Carrez (ttx) ___ 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] [TripleO] prep-source-repos - new tool for managing repos+patchsets?
I've got a new tool, currently called prep-source-repos, that I'd like to set up as a new project. Most of the work was done by adamg and lifeless, with a bit of polish from me to make it ready to be packaged. The tool is something the tripleo-cd-admins have been using to let us deploy a cloud from trunk + unlanded patchsets from Gerrit. It takes a YAML file with a list of repos to clone, then allows for individual gerrit patches to be added on top. It also creates a file with all the DIB_REPO* variables required to have DIB use these local patched repos rather than the upstream repos. This allows us to test out patches - to TripleO tools, but also to any of the other openstack tools we install from source - without needing to wait for them to land. I believe it's something that can be useful in other places as well though: * I think that it could replace http://git.openstack.org/cgit/openstack/tripleo-incubator/tree/scripts/pull-tools as something we use inside TripleO to pull and update the tools we use * In https://review.openstack.org/#/c/118426/ jp_at_hp proposed a simpler tool that applies patches from gerrit to individual repos; I think prep-source-repos solves the need for this as well * At one point I was running Gertty from trunk with a whole bunch of un-landed patches from lifeless and I. To make things easier on myself, I'd pushed my changes to Gerrit as being a big dependency chain, which didn't reflect reality. push-source-repose would make it easy to run Gerrit from upstream trunk + pull in all my unlanded patches, without needed to set up a fake dependency tree. The code is currently sitting at https://github.com/jamezpolley/prep-source-repos, but I'd like to add it to git.openstack.org, (probably as a stackforge project) if there's consensus that this is something we'd find useful. So, right now, I've got two questions for the team: * Can you think of a better name? prep-source-repos sounds a bit clumsy to me, but I haven't been able to come up with anything I like better. * Am I wrong in thinking that this tool is useful enough to be worth splitting out into its own repo? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Kilo Mid-Cycle Meetup Planning
On 10 Oct 2014, at 07:32, Gregory Haynes g...@greghaynes.net wrote: Hello TripleO-ers, Last time around there was a lot of feedback that we should plan our mid-cycle metup a lot sooner, so lets do that! I've created a (mostly bare) etherpad here: https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup Note that there are currently no possible venues listed. If you are able to provide a possible venue (Thank you!) please reply and/or add it to the etherpad. I have also listed a few possible Mon-Fri meetup dates. Do not take this as any indication that Mon-Fri is an ideal meetup length or time of week, and feel free to add feedback / combinations of your own. Personally, I felt pretty burned out by Friday last time so maybe Mon-Wed is a better size? Assuming it's in the US or Europe, Mon-Fri gives me about 3 useful days, once you take out the time I lose to jet lag. That's barely worth the 48 hours or so I spent in transit last time. I would strongly prefer not to reduce the length of the mid-cycle. I agree that it can be quite draining but reducing the length would make it much more draining for me. I'd feel different if it was hosted somewhere localish to me, and I think it's reasonable that we plan the mid-cycle around what works for the majority of attendees rather than the minority. But even so, my personal preference is for a full week. Cheers, Greg ___ 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] [TripleO] a need to assert user ownership in preserved state
On 3 Oct 2014, at 00:25, Clint Byrum cl...@fewbar.com wrote: Excerpts from James Polley's message of 2014-10-01 22:37:25 -0700: All three of the options presented here seem to assume that UIDs will always be allocated at image-build time. I think that's because most of these UIDs will be used to write files into the chroot at image-create time - if I could think of some way around that, I think we could avoid this problem more neatly by not assigning the UIDs until first boot Yeah I don't think we're going to work around that. It is part of the magic of images that the metadata is all in place and there's no churn at boot. Agree - it would be quite a significant change in how TripleO works, not just a workaround. But since we can't do that, would it be possible to compromise by having the UIDs read in from heat metadata, and using the current allocation process if none is provided? I really, really dislike this. Post-boot tools like Heat are for per-server customization and site-wide changes. UIDs seem like plumbing under the hood. I think that the part of this you dislike is specifically storing the data in heat? Would you object less if I phrased it as a job file to be read at image build time, which is closer to what I had in mind? This should allow people who prefer to have static UIDs to have simple drop-in config, but also allow people who want to dynamically read from existing images to scrape the details and then drop them in. I see your point, and I'm now confused as I don't really understand what would make somebody prefer dynamic UID allocation. I was thinking of a case where an operator might have several existing images with different sets of services, or different base distribtions, and hence different sets of uids; they'd probably prefer to have the build process extract the details from the previous image rather than having a single fixed map of uids. Someone starting fresh might prefer to provide a static map of pre-assigned UIDs To aid people who have existing images, perhaps we could provide a small tool (if one doesn't already exist) that simply reads /etc/passwd and returns a JSON username:uid map, to be added into the heat local environment when building the next image? Or a tool that reads the image, and returns /etc/passwd and /etc/group. Sure, but I think it would be handy if it could accept data from another source as well as the previous image, to cater for people who want to be more prescriptive about which UIDs are used but don't have adv Bing existing image yet. I don't know if this is a real use case though - maybe I'm just remembering bad experiences from a previous pre-cloud life. Thanks very much for your thoughts. :) ___ 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] [TripleO] a need to assert user ownership in preserved state
On 3 Oct 2014, at 02:57, James Polley j...@jamezpolley.com wrote: On 3 Oct 2014, at 00:25, Clint Byrum cl...@fewbar.com wrote: Excerpts from James Polley's message of 2014-10-01 22:37:25 -0700: All three of the options presented here seem to assume that UIDs will always be allocated at image-build time. I think that's because most of these UIDs will be used to write files into the chroot at image-create time - if I could think of some way around that, I think we could avoid this problem more neatly by not assigning the UIDs until first boot Yeah I don't think we're going to work around that. It is part of the magic of images that the metadata is all in place and there's no churn at boot. Agree - it would be quite a significant change in how TripleO works, not just a workaround. But since we can't do that, would it be possible to compromise by having the UIDs read in from heat metadata, and using the current allocation process if none is provided? I really, really dislike this. Post-boot tools like Heat are for per-server customization and site-wide changes. UIDs seem like plumbing under the hood. I think that the part of this you dislike is specifically storing the data in heat? Would you object less if I phrased it as a job file to be read at image build time, which is closer to what I had in mind? This should allow people who prefer to have static UIDs to have simple drop-in config, but also allow people who want to dynamically read from existing images to scrape the details and then drop them in. I see your point, and I'm now confused as I don't really understand what would make somebody prefer dynamic UID allocation. I was thinking of a case where an operator might have several existing images with different sets of services, or different base distribtions, and hence different sets of uids; they'd probably prefer to have the build process extract the details from the previous image rather than having a single fixed map of uids. Someone starting fresh might prefer to provide a static map of pre-assigned UIDs To be clear - I don't think either of these is novel - these are cases 1 and 2 from the mail that started the thread. The point I'm ineptly trying to make (why am I sending email at 3am?) is that I think we can easily support both 1 and 2 simply by thinking of read list of UIDs from an existing image and apply existing list of UIDs to new image as separate tasks and implement both separately To aid people who have existing images, perhaps we could provide a small tool (if one doesn't already exist) that simply reads /etc/passwd and returns a JSON username:uid map, to be added into the heat local environment when building the next image? Or a tool that reads the image, and returns /etc/passwd and /etc/group. Sure, but I think it would be handy if it could accept data from another source as well as the previous image, to cater for people who want to be more prescriptive about which UIDs are used but don't have adv Bing existing image yet. I don't know if this is a real use case though - maybe I'm just remembering bad experiences from a previous pre-cloud life. Thanks very much for your thoughts. :) ___ 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] [TripleO] a need to assert user ownership in preserved state
All three of the options presented here seem to assume that UIDs will always be allocated at image-build time. I think that's because most of these UIDs will be used to write files into the chroot at image-create time - if I could think of some way around that, I think we could avoid this problem more neatly by not assigning the UIDs until first boot But since we can't do that, would it be possible to compromise by having the UIDs read in from heat metadata, and using the current allocation process if none is provided? This should allow people who prefer to have static UIDs to have simple drop-in config, but also allow people who want to dynamically read from existing images to scrape the details and then drop them in. To aid people who have existing images, perhaps we could provide a small tool (if one doesn't already exist) that simply reads /etc/passwd and returns a JSON username:uid map, to be added into the heat local environment when building the next image? On 2 Oct 2014, at 11:50, Clint Byrum cl...@fewbar.com wrote: Recently we've been testing image based updates using TripleO, and we've run into an interesting conundrum. Currently, our image build scripts create a user per service for the image. We don't, at this time, assert a UID, so it could get any UID in the /etc/passwd database of the image. However, if we add a service that happens to have its users created before a previously existing service, the UID's shift by one. When this new image is deployed, the username might be 'ceilometer', but /mnt/state/var/lib/ceilometer is now owned by 'cinder'. Here are 3 approaches, which are not mutually exclusive to one another. There are likely others, and I'd be interested in hearing your ideas. * Static UID's for all state-preserving services. Basically we'd just allocate these UID's from a static pool and those are always the UIDs no matter what. This is the simplest solution, but does not help anybody who is already looking to update a TripleO cloud. Also, this would cause problems if TripleO wants to merge with any existing system that might also want to use similar UID's. This also provides no guard against non-static UID's storing things on the state partition. * Fix the UID's on image update. We can backup /etc/passwd and /etc/group to /mnt/state, and on bootup we can diff the two, and any UIDs that changed can be migrated. This could be very costly if the swift storage UID changed, with millions of files present on the system. This merge process is also not atomic and may not be reversible, so it is a bit scary to automate this. * Assert ownership when registering state path. We could have any state-preserving elements register their desire for any important globs for the state drive to be owned by a particular symbolic username. This is just a different, more manual way to fix the UID's and carries the same cons. So, what do people think? ___ 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] [TripleO] Summit topics
The Summit Planning wiki page[1] links to an etherpad[2] for planning topics for us to discuss at summit. So far there's only one topic listed - which makes me happy, as it's a topic I proposed (and will email about again next week after I'm back from leave). Are there other things we want to talk about in Paris? Is there somewhere else we're using for planning? I'm hoping to see some other topics listed on the etherpad over the next few days :) [1] https://wiki.openstack.org/wiki/Summit/Planning [2] https://etherpad.openstack.org/p/kilo-tripleo-summit-topics ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Bringing back auto-abandon
On Thu, Sep 11, 2014 at 8:32 AM, James E. Blair cor...@inaugust.com wrote: James Polley j...@jamezpolley.com writes: On Thu, Sep 11, 2014 at 6:52 AM, James E. Blair cor...@inaugust.com wrote: Steven Hardy sha...@redhat.com writes: Yeah, I don't know what the optimal solution is - my attention has recently been drawn to queries generated via gerrit-dash-creator, which I'm finding help a lot. This is one of several great solutions to the problem. Any query in Gerrit can include an age specifier. To get the old behavior, just add age:-2week (that translates to last updated less than 2 weeks ago) to any query -- whether a dashboard or your own bookmarked query like this one: https://review.openstack.org/#/q/status:open+age:-2week+project:openstack/nova,n,z If someone uploads a patch, and 15 days later it's had no comments at all, would it be visible in this query? My understanding is that it wouldn't, as it was last updated more than two weeks ago In my mind, a patch that's had no comments in two weeks should be high on the list of thing that need feedback. As far as I know, Gerrit doesn't have any way to sort by oldest-first though, so even if a two-week-old patch was visible in the query, it would be at the bottom of the list. Indeed, however, a slightly different query will get you exactly what you're looking for. This will show changes that are at least 2 days old, have no code reviews, are not WIP, and have passed Jenkins: project:openstack/nova status:open label:Verified=1,jenkins NOT label:Workflow=-1 NOT label:Code-Review=2 age:2d or the direct link: https://review.openstack.org/#/q/project:openstack/nova+status:open+label:Verified%253E%253D1%252Cjenkins+NOT+label:Workflow%253C%253D-1+NOT+label:Code-Review%253C%253D2+age:2d,n,z Weeks later I finally went to add this to our dashboard, only to find that we already have something similar, if I'm reading correctly. http://git.openstack.org/cgit/stackforge/gerrit-dash-creator/tree/dashboards/tripleo.dash#n15 [section 5 Days Without Feedback] query = label:Verified=1%2cjenkins NOT owner:self NOT project:openstack/tripleo-specs NOT label:Code-Review=2 age:5d (plus the other qualifiers added in the header: status:open NOT label:Workflow=-1 NOT label:Code-Review=-2) This particular section is okay right now - only one change visible. The Needs Approval section (query = label:Verified=1%2cjenkins NOT owner:self label:Code-Review=2 NOT label:Code-Review-1) is more of a problem; 43 reviews, with the oldest hidden at the bottom. I can see a few ways I could improve this; one would be to to split Needs approval into multiple sections - Needs Approval for 0-5 days, Really needs approval for 5-10, and so on. Another would be to add something to enable oldest-first sorting in Gerrit. I'm thinking that it doesn't even need to be server-side, a client-side script (just like the one that adds the Toggle CI button) would probably suffice to enable the sorting. If anyone has other ideas before I start tinkering with jquery to make the tables sortable, I'd love to hear it - but from my limited experience with jquery I don't think it should be too much of an issue. Incidentally, that is the query in the Wayward Changes section of the Review Inbox dashboard (thanks Sean!); for nova, you can see it here: https://review.openstack.org/#/projects/openstack/nova,dashboards/important-changes:review-inbox-dashboard The key here is that there are a lot of changes in a lot of different states, and one query isn't going to do everything that everyone wants it to do. Gerrit has a _very_ powerful query language that can actually help us make sense of all the changes we have in our system without externalizing the cost of that onto contributors in the form of forced-abandoning of changes. Dashboards can help us share the knowledge of how to get the most out of it. https://review.openstack.org/Documentation/user-dashboards.html https://review.openstack.org/Documentation/user-search.html -Jim ___ 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] [TripleO] Set WIP for stale patches?
On Thu, Sep 18, 2014 at 5:21 PM, mar...@redhat.com mandr...@redhat.com wrote: On 17/09/14 16:40, Charles Crouch wrote: - Original Message - Hi, as part of general housekeeping on our reviews, it was discussed at last week's meeting [1] that we should set workflow -1 for stale reviews (like gerrit used to do when I were a lad). The specific criteria discussed was 'items that have a -1 from a core but no response from author for 14 days'. This topic came up again during today's meeting and it wasn't clear if the intention was for cores to start enforcing this? So: Do we start setting WIP/workflow -1 for those reviews that have a -1 from a core but no response from author for 14 days thanks, marios [1] http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-09-09-19.04.log.html So it looks like this has already started.. https://review.openstack.org/#/c/105275/ I think we need to document on the wiki *precisely* the criteria for setting WIP/workflow -1. For example that review above has a Jenkins failure but no core reviews at all. +1 on being precise - another case in point: https://review.openstack.org/#/c/102304/ this review has a *-2* from core, which seems to 'stick' for future revisions; the last revision is from 14 days ago, so does this fulfill the criteria (I'd say it doesn't)? Not sure if you were also suggesting that -1 from Jenkins also counts, which imo makes sense... 'items that have a -1 from core or jenkins, or a -2 from core on the latest revision, and no response from author for 14 days' Really this needs to be put as a motion and voted on in the next meeting, My understanding has always been that we don't make decisions based on votes on IRC meetings, because it's hard to get a time for the meeting that allows the whole team to be easily present. I wouldn't feel comfortable doing this at the US-timezone meeting as it excludes most of APAC; nor at the EU-timezone meeting as it excludes most of the US. If we're looking for consensus, I'd suggest we use Gerrit to collect votes. We could model this is a change to the CONTRIBUTING.rst[1], or perhaps we could draft a spec around the expected workflow (perhaps formalising some of our expectations around cores averaging 3 reviews/workday + 1 spec review/workday at the same time? But perhaps I'm overthinking and making this far more formal than it has to be. We've had a fair bit of discussion on the list and we seem to be broadly in agreement; perhaps we just need someone to propose some details and see if we can get consensus here. [1] What's that you say? We don't have a CONTRIBUTING.rst? One second, let me fix that *tap tap tap* We will as soon as https://review.openstack.org/#/c/122350/ lands! thanks, marios ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Set WIP for stale patches?
On 18 Sep 2014, at 6:06 pm, Sullivan, Jon Paul jonpaul.sulli...@hp.com wrote: -Original Message- From: James E. Blair [mailto:cor...@inaugust.com] Sent: 17 September 2014 23:24 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [TripleO] Set WIP for stale patches? Sullivan, Jon Paul jonpaul.sulli...@hp.com writes: I think this highlights exactly why this should be an automated process. No errors in application, and no errors in interpretation of what has happened. So the -1 from Jenkins was a reaction to the comment created by adding the workflow -1. This is going to happen on all of the patches that have their workflow value altered (tests will run, result would be whatever the result of the test was, of course). Jenkins only runs tests in reaction to comments if they say recheck. This is not my experience. In my experience if the check results are not fresh enough the recheck is automatically run. I am not on the infra team, so without looking up code I am just guessing, but my guess is that the workflow score change triggers the check on the presumption that it has been approved, not accounting for the recent(ish) update that move wip to the workflow score. But I also agree that the Jenkins vote should not be included in the determination of marking a patch WIP, but a human review should (So Code-Review and not Verified column). And in fact, for the specific example to hand, the last Jenkins vote was actually a +1, so as I understand it should not have been marked WIP. I'd like to help you see the reviews you want to see without externalizing your individual workflow onto contributors. What tool do you use to find reviews? If it's gerrit's webui, have you tried using the Review Inbox dashboard? Here it is for the tripleo-image-elements project: https://review.openstack.org/#/projects/openstack/tripleo-image- elements,dashboards/important-changes:review-inbox-dashboard If you would prefer something else, we can customize those dashboards to do whatever you want, including ignoring changes that have not been updated in 2 weeks. This is not solely about finding reviews. It is about pruning stale reviews. I think the auto-abandon code was excellent at doing this, but alas, it is no more. The only reason i'm aware of for pruning apparently stale reviews is to make it easier to find and review things that are being actively worked on. Do you have other reasons for wanting stale reviews pruned? -Jim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Thanks, Jon-Paul Sullivan ☺ Cloud Services - @hpcloud Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park, Galway. Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John Rogerson's Quay, Dublin 2. Registered Number: 361933 The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated, you should consider this message and attachments as HP CONFIDENTIAL. ___ 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] [TripleO] Set WIP for stale patches?
On Wed, Sep 17, 2014 at 6:26 PM, mar...@redhat.com mandr...@redhat.com wrote: Hi, as part of general housekeeping on our reviews, it was discussed at last week's meeting [1] that we should set workflow -1 for stale reviews (like gerrit used to do when I were a lad). The specific criteria discussed was 'items that have a -1 from a core but no response from author for 14 days'. This topic came up again during today's meeting and it wasn't clear if the intention was for cores to start enforcing this? So: Do we start setting WIP/workflow -1 for those reviews that have a -1 from a core but no response from author for 14 days I'm in favour of doing this; as long as we make it clear that we're doing it to help us focus review effort on things that are under active development - it doesn't mean we think the patch shouldn't land, it just means we know it's not ready yet so we don't want reviewers to be looking at it until it moves forward. For the sake of making sure new developers don't get put off, I'd like to see us leaving a comment explaining why we're WIPing the change and noting that uploading a new revision will remove the WIP automatically thanks, marios [1] http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-09-09-19.04.log.html ___ 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] [TripleO] Set WIP for stale patches?
On Thu, Sep 18, 2014 at 8:24 AM, James E. Blair cor...@inaugust.com wrote: Sullivan, Jon Paul jonpaul.sulli...@hp.com writes: I think this highlights exactly why this should be an automated process. No errors in application, and no errors in interpretation of what has happened. So the -1 from Jenkins was a reaction to the comment created by adding the workflow -1. This is going to happen on all of the patches that have their workflow value altered (tests will run, result would be whatever the result of the test was, of course). Jenkins only runs tests in reaction to comments if they say recheck. But I also agree that the Jenkins vote should not be included in the determination of marking a patch WIP, but a human review should (So Code-Review and not Verified column). And in fact, for the specific example to hand, the last Jenkins vote was actually a +1, so as I understand it should not have been marked WIP. I'd like to help you see the reviews you want to see without externalizing your individual workflow onto contributors. What tool do you use to find reviews? We updated our wiki back in June to point people at: https://review.openstack.org/#/dashboard/?foreach=%28project%3Aopenstack%2Ftripleo-incubator+OR+project%3Aopenstack%2Ftripleo-image-elements+OR+project%3Aopenstack%2Ftripleo-heat-templates+OR+project%3Aopenstack%2Ftripleo-specs+OR+project%3Aopenstack%2Fos-apply-config+OR+project%3Aopenstack%2Fos-collect-config+OR+project%3Aopenstack%2Fos-refresh-config+OR+project%3Aopenstack%2Fos-cloud-config+OR+project%3Aopenstack%2Fdiskimage-builder+OR+project%3Aopenstack%2Fdib-utils+OR+project%3Aopenstack-infra%2Ftripleo-ci+OR+project%3Aopenstack%2Ftuskar+OR+project%3Aopenstack%2Fpython-tuskarclient%29+status%3Aopen+NOT+label%3AWorkflow%3C%3D-1+NOT+label%3ACode-Review%3C%3D-2title=TripleO+InboxMy+Patches+Requiring+Attention=owner%3Aself+%28label%3AVerified-1%252cjenkins+OR+label%3ACode-Review-1%29TripleO+Specs=NOT+owner%3Aself+project%3Aopenstack%2Ftripleo-specsNeeds+Approval=label%3AVerified%3E%3D1%252cjenkins+NOT+owner%3Aself+label%3ACode-Review%3E%3D2+NOT+label%3ACode-Review-15+Days+Without+Feedback=label%3AVerified%3E%3D1%252cjenkins+NOT+owner%3Aself+NOT+project%3Aopenstack%2Ftripleo-specs+NOT+label%3ACode-Review%3C%3D2+age%3A5dNo+Negative+Feedback=label%3AVerified%3E%3D1%252cjenkins+NOT+owner%3Aself+NOT+project%3Aopenstack%2Ftripleo-specs+NOT+label%3ACode-Review%3C%3D-1+NOT+label%3ACode-Review%3E%3D2+limit%3A50Other=label%3AVerified%3E%3D1%252cjenkins+NOT+owner%3Aself+NOT+project%3Aopenstack%2Ftripleo-specs+label%3ACode-Review-1+limit%3A20 It's probably not the only thing people use, but it should give you an idea of what we'd find useful. If it's gerrit's webui, have you tried using the Review Inbox dashboard? Here it is for the tripleo-image-elements project: https://review.openstack.org/#/projects/openstack/tripleo-image-elements,dashboards/important-changes:review-inbox-dashboard That gave me an error: Error in operator label:Code-Review=0,self After trying a few times I realised I hadn't logged in yet. After logging in, it works. It'd be nice if it triggered the login sequence instead of just giving me an error. If you would prefer something else, we can customize those dashboards to do whatever you want, including ignoring changes that have not been updated in 2 weeks. I'd love to be able to sort by least-recently-updated, to encourage a FIFO pattern. At present, even on our dashboard above, the best we've been able to do is highlight things that are (for instance) 2 weeks without review - but even then, the things that are just barely two weeks without review sit at the top, while things that have been 60 days or more without review are hidden further down. -Jim ___ 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] [TripleO] Review metrics - what do we want to measure?
There was some discussion of this topic during today's meeting. Full notes are at http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-09-09-19.04.log.html starting around 19:24 To summarise, we had one action item, and one comment from dprince which attracted broad agreement, and which I think is worth repeating here: 19:34:26 tchaypo #action bnemec to look at adding a report of items that have a -1 from a core but no response for 14 days, as a first step towards possibly auto-WIPing these patches 19:41:54 dprince I sort of feel like all the focus on stats in our meetings is going to encourage people to game them (i.e. fly by reviews) 19:42:13 dprince when what we really need is ownershipt to push through the important things... 19:42:45 * dprince thinkgs stats are becoming a TripleO waste of time 19:44:12 jp_at_hp stats not important, being active and responsive enough to not push new contributors away does matter 19:44:51 lifeless jp_at_hp: I agree; the stats are a tool, not the thing itself. On Fri, Sep 5, 2014 at 9:47 PM, Sullivan, Jon Paul jonpaul.sulli...@hp.com wrote: -Original Message- From: Jay Dobies [mailto:jason.dob...@redhat.com] Sent: 04 September 2014 18:24 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [TripleO] Review metrics - what do we want to measure? It can, by running your own... but again it seems far better for core reviewers to decide if a change has potential or needs to be abandoned--that way there's an accountable human making that deliberate choice rather than the review team hiding behind an automated process so that no one is to blame for hurt feelings besides the infra operators who are enforcing this draconian measure for you. The thing is that it's also pushing more work onto already overloaded core review teams. Maybe submitters don't like auto-abandon, but I bet they like having a core reviewer spending time cleaning up dead reviews instead of reviewing their change even less. TBH, if someone's offended by the bot then I can't imagine how incensed they must be when a human does the same thing. The bot clearly isn't making it personal, and even if the human isn't either it's much easier to have misunderstandings (see also every over- reaction to a -1 ever). I suppose it makes it easier for cores to ignore reviews, but from the other discussions I've read that hasn't gone away just because auto-abandon did, so I'm not convinced that's a solution anyway. +1, I don't think it'll come as much of a shock if a -1 review gets closed due to time without progress. +1 to auto-abandon. Taking an excerpt from Dereks mail: A patch got negative feedback and we're automating the process to prompt the submitter to deal with it. It may be more friendly if it was a 2 step process 1. (after a few days if inactivity) Add a comment saying you got negative feedback with suggestions of how to proceed and information that the review will be autoabandoned if nothing is done in X number of days. 2. Auto abandon patch, with as much information as possible on how to reopen if needed. This sounds like the best solution. A 1 week warning and a 2 week abandoning. It is about as welcoming as this sort of thing could be for a new committer, whilst also avoiding an ever-growing backlog of changes that will never see attention because the submitter has moved on to other things. There is also the benefit of prompting submitters into action when things get auto-abandoned, rather than them having sitting at priority #2 or #3 forever. I was never particularly upset over the auto-abandon, just click a single button in the ui and get on with it. /2 cents To make the whole process a little friendlier we could increase the time frame from 1 week to 2. snarkHow about just automatically abandon any new change as soon as it's published, and if the contributor really feels it's important they'll unabandon it./snark ___ 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 Thanks, Jon-Paul Sullivan ☺ Cloud Services - @hpcloud Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park, Galway. Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John Rogerson's Quay, Dublin 2. Registered Number: 361933 The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error you should delete it from your system immediately and advise the sender. To any recipient of this message within
Re: [openstack-dev] [all] Bringing back auto-abandon
On Thu, Sep 11, 2014 at 6:52 AM, James E. Blair cor...@inaugust.com wrote: Steven Hardy sha...@redhat.com writes: Yeah, I don't know what the optimal solution is - my attention has recently been drawn to queries generated via gerrit-dash-creator, which I'm finding help a lot. This is one of several great solutions to the problem. Any query in Gerrit can include an age specifier. To get the old behavior, just add age:-2week (that translates to last updated less than 2 weeks ago) to any query -- whether a dashboard or your own bookmarked query like this one: https://review.openstack.org/#/q/status:open+age:-2week+project:openstack/nova,n,z If someone uploads a patch, and 15 days later it's had no comments at all, would it be visible in this query? My understanding is that it wouldn't, as it was last updated more than two weeks ago In my mind, a patch that's had no comments in two weeks should be high on the list of thing that need feedback. As far as I know, Gerrit doesn't have any way to sort by oldest-first though, so even if a two-week-old patch was visible in the query, it would be at the bottom of the list. -Jim ___ 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] [TripleO] Review velocity and core reviewer commitments
One recurring topic in our weekly meetings over the last few months has been the fact that it's taking us longer and longer to review and land patches. Right now, http://www.nemebean.com/reviewstats/tripleo-open.html has the following stats: - Stats since the latest revision: 1. Average wait time: 10 days, 14 hours, 37 minutes 2. 1st quartile wait time: 4 days, 8 hours, 45 minutes 3. Median wait time: 7 days, 10 hours, 50 minutes 4. 3rd quartile wait time: 15 days, 9 hours, 57 minutes 5. Number waiting more than 7 days: 63 - Stats since the last revision without -1 or -2 : 1. Average wait time: 11 days, 22 hours, 21 minutes 2. 1st quartile wait time: 4 days, 10 hours, 55 minutes 3. Median wait time: 8 days, 3 hours, 49 minutes 4. 3rd quartile wait time: 18 days, 23 hours, 20 minutes There are many things that can contribute to this; for instance, a patch that has no negative reviews but also can't be approved (because it isn't passing CI, or because it depends on other changes that are more contentious) will increase these average wait times. I kicked off a discussion about the possibility that we're measuring the wrong thing a few weeks ago ( http://lists.openstack.org/pipermail/openstack-dev/2014-August/042960.html) - if you've got suggestions about what we should be measuring, please follow up there. There's one trend I'm seeing that seems as though it's exacerbating our sluggishness: many of our core reviewers are not meeting their commitment to 3 reviews per day. http://www.nemebean.com/reviewstats/tripleo-30.txt currently shows just 9 cores (and 2 non-cores!) meeting have exceeded 60 reviews over the last 30 days; 10 cores have not[1]. This isn't just a short-term glitch either: the 90-day stats show the same numbers, although a slightly different set of reviewers on either side of the cutoff. The commitment to 3 reviews per day is one of the most important things we ask of our core reviewers. We want their reviews to be good quality to help make sure our code is also good quality - but if they can't commit to 3 reviews per day, they are slowing the project down by making it harder for even good quality code to land. There's little point in us having good quality code if it's perpetually out of date. I'd like to call on all existing cores to make a concerted effort to meet the commitment they made when they were accepted as core reviewers. We need to ensure that patches are being reviewed and landed, and we can't do that unless cores take the time to do reviews. If you aren't able to meet the commitment you made when you became a core, it would be helpful if you could let us know - or undertake a meta-review so we can consider possibly adding some new cores (it seems like we might have 2 strong candidates, if the quality of their reviews matches the quantity) I'd like to call on everyone else (myself included - I've only managed 13 reviews over the last 30 days!) to help out as well. It's easier for cores to review patchsets that already have several +1s. If you're looking for a place to start, http://www.nemebean.com/reviewstats/tripleo-open.html has a list of the oldest patches that are looking for reviews, and https://wiki.openstack.org/wiki/TripleO#Review_team has a link to a dashboard that has sections for reviews that have been a long time without feedback. If you have ideas for other things we can or should measure, please follow up on the other thread, or in our weekly meeting. [1] lxsli and jonpaul-sullivan are cores since the conclusion of the thread starting at http://lists.openstack.org/pipermail/openstack-dev/2014-July/039762.html, but not shown as such. https://review.openstack.org/#/c/118483 will correct this. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs
I'm fairly certain the buzzing sound I can hear is a bee in my bonnet... so I suspect that I'm starting to sound like someone chasing a bee that only they can hear. I'm not sure if it's helpful to keep this discussion on this list - would there be a better forum somewhere else? On Fri, Aug 29, 2014 at 7:34 PM, Thierry Carrez thie...@openstack.org wrote: James Polley wrote: However, Thierry pointed to https://wiki.openstack.org/wiki/Governance/Foundation/Structure which still refers to Project Technical Leads and says explicitly that they lead individual projects, not programs. I actually have edit access to that page, so I could at least update that with a simple s/Project/Program/, if I was sure that was the right thing to do. Don't underestimate how stale wiki pages can become! Yes, fix it. I don't know if I've fixed it, but I've certainly replaced all users of the word Project with Program. Whether or not it now matches reality, I'm not sure. I alsp removed (what I assume is) a stale reference to the PPB and added a new heading for the TC. It looks correct to me, thanks! http://www.openstack.org/ has a link in the bottom nav that says Projects; it points to http://www.openstack.org/projects/ which redirects to http://www.openstack.org/software/ which has a list of things like Compute and Storage - which as far as I know are Programs, not Projects. I don't know how to update that link in the nav panel. That's because the same word (compute) is used for two different things: a program name (Compute) and an official OpenStack name for a project (OpenStack Compute a.k.a. Nova). Basically official OpenStack names reduce confusion for newcomers (What is Nova ?), but they confuse old-timers at some point (so the Compute program produces Nova a.k.a. OpenStack Compute ?). That's confusing to me. I had thought that part of the reason for the separation was to enable a level of indirection - if the Compute program team decide that a new project called (for example) SuperNova should be the main project, that just means that Openstack Compute is now a pointer to a different project, supported by the same program team. It sounds like that isn't the intent though? That's more of a side-effect than the intent, IMHO. The indirection we created is between teams and code repositories. I wasn't around when the original Programs/Projects discussion was happening - which, I suspect, has a lot to do with why I'm confused today - it seems as though people who were around at the time understand the difference, but people who have joined since then are relying on multiple conflicting verbal definitions. I believe, though, that http://lists.openstack.org/pipermail/openstack-dev/2013-June/010821.html was one of the earliest starting points of the discussion. That page points at https://wiki.openstack.org/wiki/Projects, which today contains a list of Programs. That page does have a definition of what a Program is, but doesn't explain what a Project is or how they relate to Programs. This page seems to be locked down, so I can't edit it. https://wiki.openstack.org/wiki/Projects was renamed to https://wiki.openstack.org/wiki/Programs with the wiki helpfully leaving a redirect behind. So the content you are seeing here is the Programs wiki page, which is why it doesn't define projects. We don't really use the word project that much anymore, we prefer to talk about code repositories. Programs are teams working on a set of code repositories. Some of those code repositories may appear in the integrated release. This explanation of the difference between projects and programs sounds like it would be useful to add to /Programs - but I can't edit that page. This page reflects the official list of programs, which is why it's protected. it's supposed to be replaced by an automatic publication from http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml which is the ultimate source of truth on that topic. I was going to ask about the reference to The process new projects can follow to become an Integrated project - is that intended to refer to a project or a program? But then I read https://review.openstack.org/#/c/116727/ and and http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements.rst, seem to make it clear that it's entirely possible that the Kitty program might have a mix of Integrated and non-Integrated projects. Is it safe to assume that the Governance repo is canonical and up-to-date, and rework the wiki pages based on the information in the Governance repo? [1] https://wiki.openstack.org/wiki
Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs
On Thu, Aug 28, 2014 at 10:40 PM, Thierry Carrez thie...@openstack.org wrote: James Polley wrote: Point of clarification: I've heard PTL=Project Technical Lead and PTL=Program Technical Lead. Which is it? It is kind of important as OpenStack grows, because the first is responsible for *a* project, and the second is responsible for all projects within a program. Now Program, formerly Project. I think this is worthy of more exploration. Our docs seem to be very inconsistent about what a PTL is - and more broadly, what the difference is between a Project and a Program. Just a few examples: https://wiki.openstack.org/wiki/PTLguide says Program Technical Lead. https://wiki.openstack.org/wiki/PTL_Elections_March/April_2014 simply says PTL - but does say that each PTL is elected by/for a Program. However, Thierry pointed to https://wiki.openstack.org/wiki/Governance/Foundation/Structure which still refers to Project Technical Leads and says explicitly that they lead individual projects, not programs. I actually have edit access to that page, so I could at least update that with a simple s/Project/Program/, if I was sure that was the right thing to do. Don't underestimate how stale wiki pages can become! Yes, fix it. I don't know if I've fixed it, but I've certainly replaced all users of the word Project with Program. Whether or not it now matches reality, I'm not sure. I alsp removed (what I assume is) a stale reference to the PPB and added a new heading for the TC. http://www.openstack.org/ has a link in the bottom nav that says Projects; it points to http://www.openstack.org/projects/ which redirects to http://www.openstack.org/software/ which has a list of things like Compute and Storage - which as far as I know are Programs, not Projects. I don't know how to update that link in the nav panel. That's because the same word (compute) is used for two different things: a program name (Compute) and an official OpenStack name for a project (OpenStack Compute a.k.a. Nova). Basically official OpenStack names reduce confusion for newcomers (What is Nova ?), but they confuse old-timers at some point (so the Compute program produces Nova a.k.a. OpenStack Compute ?). That's confusing to me. I had thought that part of the reason for the separation was to enable a level of indirection - if the Compute program team decide that a new project called (for example) SuperNova should be the main project, that just means that Openstack Compute is now a pointer to a different project, supported by the same program team. It sounds like that isn't the intent though? I wasn't around when the original Programs/Projects discussion was happening - which, I suspect, has a lot to do with why I'm confused today - it seems as though people who were around at the time understand the difference, but people who have joined since then are relying on multiple conflicting verbal definitions. I believe, though, that http://lists.openstack.org/pipermail/openstack-dev/2013-June/010821.html was one of the earliest starting points of the discussion. That page points at https://wiki.openstack.org/wiki/Projects, which today contains a list of Programs. That page does have a definition of what a Program is, but doesn't explain what a Project is or how they relate to Programs. This page seems to be locked down, so I can't edit it. https://wiki.openstack.org/wiki/Projects was renamed to https://wiki.openstack.org/wiki/Programs with the wiki helpfully leaving a redirect behind. So the content you are seeing here is the Programs wiki page, which is why it doesn't define projects. We don't really use the word project that much anymore, we prefer to talk about code repositories. Programs are teams working on a set of code repositories. Some of those code repositories may appear in the integrated release. This explanation of the difference between projects and programs sounds like it would be useful to add to /Programs - but I can't edit that page. That page does mention projects, once. The context makes it read, to me, as though a program can follow one process to become part of OpenStack and then another process to become an Integrated project and part of the OpenStack coordinated release - when my understanding of reality is that the second process applies to Projects, not Programs. I've tried to find any other page that talks about what a Project is and how they relate to Programs, but I haven't been able to find anything. Perhaps there's some definition locked up in a mailing list thread or some TC minutes, but I haven't been able to find it. During the previous megathread, I got the feeling that at least some of the differing viewpoints we saw were possibly down to some people thinking of a PTL as responsible for just one project, while others think of a PTL as being
Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs
On Sat, Aug 23, 2014 at 11:02 AM, Anne Gentle a...@openstack.org wrote: On Fri, Aug 22, 2014 at 6:17 PM, Rochelle.RochelleGrober rochelle.gro...@huawei.com wrote: /flame-on Ok, this is funny to some of us in the community. The general populace of this community is so against the idea of management that they will use the term for a despotic dictator as a position name rather than manager. Sorry, but this needed to be said. /flame-off Specific comments in line: Thierry Carrez wrote: Hi everyone, We all know being a project PTL is an extremely busy job. That's because in our structure the PTL is responsible for almost everything in a project: - Release management contact - Work prioritization - Keeping bugs under control - Communicate about work being planned or done - Make sure the gate is not broken - Team logistics (run meetings, organize sprints) - ... Point of clarification: I've heard PTL=Project Technical Lead and PTL=Program Technical Lead. Which is it? It is kind of important as OpenStack grows, because the first is responsible for *a* project, and the second is responsible for all projects within a program. Now Program, formerly Project. I think this is worthy of more exploration. Our docs seem to be very inconsistent about what a PTL is - and more broadly, what the difference is between a Project and a Program. Just a few examples: https://wiki.openstack.org/wiki/PTLguide says Program Technical Lead. https://wiki.openstack.org/wiki/PTL_Elections_March/April_2014 simply says PTL - but does say that each PTL is elected by/for a Program. However, Thierry pointed to https://wiki.openstack.org/wiki/Governance/Foundation/Structure which still refers to Project Technical Leads and says explicitly that they lead individual projects, not programs. I actually have edit access to that page, so I could at least update that with a simple s/Project/Program/, if I was sure that was the right thing to do. http://www.openstack.org/ has a link in the bottom nav that says Projects; it points to http://www.openstack.org/projects/ which redirects to http://www.openstack.org/software/ which has a list of things like Compute and Storage - which as far as I know are Programs, not Projects. I don't know how to update that link in the nav panel. I wasn't around when the original Programs/Projects discussion was happening - which, I suspect, has a lot to do with why I'm confused today - it seems as though people who were around at the time understand the difference, but people who have joined since then are relying on multiple conflicting verbal definitions. I believe, though, that http://lists.openstack.org/pipermail/openstack-dev/2013-June/010821.html was one of the earliest starting points of the discussion. That page points at https://wiki.openstack.org/wiki/Projects, which today contains a list of Programs. That page does have a definition of what a Program is, but doesn't explain what a Project is or how they relate to Programs. This page seems to be locked down, so I can't edit it. That page does mention projects, once. The context makes it read, to me, as though a program can follow one process to become part of OpenStack and then another process to become an Integrated project and part of the OpenStack coordinated release - when my understanding of reality is that the second process applies to Projects, not Programs. I've tried to find any other page that talks about what a Project is and how they relate to Programs, but I haven't been able to find anything. Perhaps there's some definition locked up in a mailing list thread or some TC minutes, but I haven't been able to find it. During the previous megathread, I got the feeling that at least some of the differing viewpoints we saw were possibly down to some people thinking of a PTL as responsible for just one project, while others think of a PTL as being responsible for any projects that might fit within a Program's scope. As we approach the next PTL elections, I think it would be helpful for us to recap the discussions that led to the Program/Project split and make sure our docs are consistent, so that people who weren't following the discussion this time last year can still be clear what they're voting for. I'd also like to set out as an example of a Program that is growing to encompass multiple projects, the Neutron Program. Look at how it is expanding: Multiple sub-teams for: LBAAS, DNAAS, GBP, etc. This model could be extended such that: - the subteam is responsible for code reviews, including the first +2 for design, architecture and code of the sub-project, always also keeping an eye out that the sub-project code continues to both integrate well with the program, and that the program continues to provide the needed code bits, architecture modifications and improvements, etc. to support the sub-project. - the final +2/A would be from the Program reviewers to ensure that
Re: [openstack-dev] [Openstack][TripleO] What if undercloud machines down, can we reboot overcloud machines?
That is correct, we intend that the undercloud should be designed with HA in mind. In terms of the design of TripleO, the devtest.sh implementation aims to have this available as a default (see http://docs.openstack.org/developer/tripleo-incubator/README.html#stage-2-being-worked-on for some dated and very brief notes about our aims). This is something that's been receiving a lot of attention over the last cycle, but it's not quite ready out-of-the-box yet. In terms of implementation, this will still require the implementor to make sure that their implementation meets their needs for HA. For instance, it doesn't matter how many redundant neutron nodes we run if they all hang off the back of a single physical non-redundant switch... Are there particular concerns you have with this design? On Thu, Aug 28, 2014 at 2:20 PM, Jyoti Ranjan jran...@gmail.com wrote: I do agree but it create an extra requirement for Undercloud if we high availability is important criteria. Because of this, undercloud has to be there 24x7, 365 days and to make it available we need to have HA for this also. So, you indirectly mean that undercloud also should be designed keeping high availability in mind. On Wed, Aug 27, 2014 at 7:53 PM, Ben Nemec openst...@nemebean.com wrote: We probably will at some point, but I don't know that it's a huge priority right now. The PXE booting method works fine, and as I mentioned we don't intend you to reboot machines without using the undercloud anyway, just like Nova doesn't expect you to reboot vms directly via libvirt (or your driver of choice). It's likely there would be other issues booting a deployed machine if the undercloud is down anyway (nothing to respond to DHCP requests, for one), so I don't see that as something we want to encourage anyway. -Ben On 08/27/2014 04:11 AM, Jyoti Ranjan wrote: I believe that local boot option is available in Ironic. Will not be a good idea to boot from local disk instead of relying on PXE boot always? Curious to know why we are not going this path? On Wed, Aug 27, 2014 at 3:54 AM, 严超 yanchao...@gmail.com wrote: Thank you very much. And sorry for the cross-posting. *Best Regards！* *Chao Yan--**My twitter：Andy Yan @yanchao727 https://twitter.com/yanchao727* *My Weibo：http://weibo.com/herewearenow http://weibo.com/herewearenow--* 2014-08-26 23:17 GMT+08:00 Ben Nemec openst...@nemebean.com: Oh, after writing my response below I realized this is cross-posted between openstack and openstack-dev. Please don't do that. I suppose this probably belongs on the users list, but since I've already written the response I guess I'm not going to argue too much. :-) On 08/26/2014 07:36 AM, 严超 wrote: Hi, All: I've deployed undercloud and overcloud on some baremetals. All overcloud machines are deployed by undercloud. Then I tried to shutdown undercloud machines. After that, if I reboot one overcloud machine, it will never boot from net, AKA PXE used by undercloud. Yes, that's normal. With the way our baremetal deployments work today, the deployed systems always PXE boot. After deployment they PXE boot a kernel and ramdisk that use the deployed hard disk image, but it's still a PXE boot. Is that what TripleO is designed to be ? We can never shutdown undercloud machines for maintainance of overcloud ? Please help me clearify that. Yes, that's working as intended at the moment. I recall hearing that there were plans to eliminate the PXE requirement after deployment, but you'd have to talk to the Ironic team about that. Also, I don't think it was ever the intent of TripleO that the undercloud would be shut down after deployment. The idea is that you use the undercloud to manage the overcloud machines, so if you want to reboot one you do it via the undercloud nova, not directly on the system itself. *Best Regards！* *Chao Yan--**My twitter：Andy Yan @yanchao727 https://twitter.com/yanchao727* *My Weibo：http://weibo.com/herewearenow http://weibo.com/herewearenow--* ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Time to break backwards compatibility for *cloud-password file location?
After some more discussion and several attempts at different ways to solve this problem, here's the message I've just added to https://review.openstack.org/#/c/97657/ I spoke to xu haiwei about this change a few days ago and agreed to have a stab at switching from using environment variables to command-line flags, in line with the comments above. The best way i could see to do this was to store the password file location in $TE_DATAFILE. I wanted to check if this was a sensible idea so I jumped into #tripleo This led to some discussion in-channel where we (bnemec, lifeless, myself) tried to step back, look at what problem we're trying to solve, and look for a good way to solve it. We think, if our understanding is correct, that we're trying to do a few different things here: 1) The current logic (look in $CWD for passwords first, then look in $TRIPLEO_ROOT) is confusing, especially for someone reading the code - we think it's not particularly clear what's happening or why 2) We (who were discussing it at the time) think that we (the broader TripleO team) want to make sure that users can drive multiple stacks - eg, running multiple overclouds out of one undercloud - and have different credentials for each. We (who were discussing it at the time) don't actually know of anyone who does this, so we're only speculating that this something that some people *might* find useful - if we could talk to someone who needs this functionality, it would help us make sure we're doing something useful for them 3) Looking to the future, these passwords should eventually be stored in Barbican or something similar. In the shorter term, it would probably be a good idea to move the passwords into $TE_DATAFILE. However, the work required to do that today is non-trivial as we'd need to find all the places the passwords are currently used and change the way the password is looked up. Looking at the history of this change, it seems that it was originally trying to solve (1) by making the logic for finding passwords simpler and cleaner. However, that broke (2); in trying to make (2) work again, this change got made more complex, even though we haven't found anyone who actually relies on this functionality working. We seem to have a solution (put the filenames into $TE_DATAFILE) which achieves (1) and preserves the ability to do (2) - but any work we do on it will have to be tweaked again (probably soon) when we work on (3) So, assuming I've understood the motivations of this change correctly, here's what I plan to do: 1) Wait for people to tell me I've misunderstood the intent of this change (this is a non-blocking step, other steps will proceed in parallel with waiting) 2) Raise https://bugs.launchpad.net/tripleo/+bug/1358600 about getting a solution for (3) (which will enable (2) and help with (1) ) 3) Raise a new CR (I12d013196b0c533a0550167b9b8209e590e3bd49) which attempts to add some docs into the scripts to clarify the existing logic I'll copy this message onto the mailing list as well - if we've misunderstood what's needed here, or these plans don't meet your needs, please follow up there with some more details. On Thu, Jul 3, 2014 at 9:10 AM, James Polley j...@jamezpolley.com wrote: On Thu, Jul 3, 2014 at 5:33 AM, Sullivan, Jon Paul jonpaul.sulli...@hp.com wrote: -Original Message- From: Giulio Fidente [mailto:gfide...@redhat.com] Sent: 01 July 2014 13:08 Subject: Re: [openstack-dev] [TripleO] Time to break backwards compatibility for *cloud-password file location? On 06/25/2014 11:25 AM, mar...@redhat.com wrote: On 25/06/14 10:52, James Polley wrote: Until https://review.openstack.org/#/c/83250/, the setup-*-password scripts used to drop password files into $CWD, which meant that if you ran the script from a different location next time, your old passwords wouldn't be found. https://review.openstack.org/#/c/83250/ changed this so that the default behaviour is to put the password files in $TRIPLEO_ROOT; but for backwards compatibility we left the script checking to see if there's a file in the current directory, and using that file in preference to $TRIPLEO_ROOT if it exists. However, this behaviour is still confusing to people. I'm not entirely clear on why it's confusing (it makes perfect sense to me...) but I imagine it's because we still have the problem that the code works fine if run from one directory, but run from a different directory it can't find passwords. There are two open patches which would break backwards compatibility and only ever use the files in $TRIPLEO_ROOT: https://review.openstack.org/#/c/93981/ https://review.openstack.org/#/c/97657/ The latter review is under more active development, and has suggestions that the directory containing the password files should be parameterised, defaulting to $TRIPLEO_ROOT. This would still break for anyone who relies on the password files being
[openstack-dev] [TripleO] Review metrics - what do we want to measure?
In recent history, we've been looking each week at stats from http://russellbryant.net/openstack-stats/tripleo-openreviews.html to get a gauge on how our review pipeline is tracking. The main stats we've been tracking have been the since the last revision without -1 or -2. I've included some history at [1], but the summary is that our 3rd quartile has slipped from 13 days to 16 days over the last 4 weeks or so. Our 1st quartile is fairly steady lately, around 1 day (down from 4 a month ago) and median is unchanged around 7 days. There was lots of discussion in our last meeting about what could be causing this[2]. However, the thing we wanted to bring to the list for the discussion is: Are we tracking the right metric? Should we be looking to something else to tell us how well our pipeline is performing? The meeting logs have quite a few suggestions about ways we could tweak the existing metrics, but if we're measuring the wrong thing that's not going to help. I think that what we are looking for is a metric that lets us know whether the majority of patches are getting feedback quickly. Maybe there's some other metric that would give us a good indication? [1] Current Stats since the last revision without -1 or -2 : Average wait time: 10 days, 17 hours, 6 minutes 1st quartile wait time: 1 days, 1 hours, 36 minutes Median wait time: 7 days, 5 hours, 33 minutes 3rd quartile wait time: 16 days, 8 hours, 16 minutes At last week's meeting we had: 3rd quartile wait time: 15 days, 13 hours, 47 minutes A week before that: 3rd quartile wait time: 13 days, 9 hours, 11 minutes The week before that was the mid-cycle, but the week before that: 19:53:38 lifeless Stats since the last revision without -1 or -2 : 19:53:38 lifeless Average wait time: 10 days, 17 hours, 49 minutes 19:53:38 lifeless 1st quartile wait time: 4 days, 7 hours, 57 minutes 19:53:38 lifeless Median wait time: 7 days, 10 hours, 52 minutes 19:53:40 lifeless 3rd quartile wait time: 13 days, 13 hours, 25 minutes [2] Some of the things suggested as potential causes of the long 3rd median times: * We have small number of really old reviews that have only positive scores but aren't being landed * Some reviews get a -1 but then sit for a long time waiting for the author to reply * We have some really old reviews that suddenly get revived after a long period being in WIP or abandoned, which reviewstats seems to miscount * Reviewstats counts weekends, we don't (so a change that gets pushed at 5pm US Friday and gets reviewed at 9am Aus Monday would be seen by us as having no wait time, but by reviewstats as ~36 hours) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] No weekly meeting this week
Due to the fact that the vast majority of the TripleO team are in a room staring at me as I write this email, the weekly IRC meeting won't be happening this week. If you have any issues that need to be discussed this week, please bring them up on IRC in #tripleo or via email. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] pypi-mirror is now unsupported - what do we do now?
On Mon, Jul 14, 2014 at 2:58 AM, Monty Taylor mord...@inaugust.com wrote: On 07/10/2014 02:44 PM, Richard Jones wrote: On 10 July 2014 23:27, Mulcahy, Stephen stephen.mulc...@hp.com wrote: When I last tested bandersnatch, it didn’t work well behind a proxy (in fact most of the existing pypi mirroring tools suffered from the same problem) – pypi-mirror has worked extremely well for mirroring a subset of pypi and doing so behind a proxy. I’d also echo the requirement for a tool that provides wheels as we have seen significant performance improvement from using wheels with TripleO devpi works behind a proxy. If bandersnatch doesn't then that bug should be addressed ASAP. I'm in contact with its author regarding that. I'm currently investigating a sensible approach to having wheels be automatically built (for the most sensible value of automatic that we can determine wink). We're also thinking about how we continue to offer the pre-built wheels for each of our build platforms. For infra, what I'm thinking is: On each mirror slave (We have one for each OS combo we use), do something similar to: pip wheel -r global-requirements.txt rsync $wheelhouse pypi.openstack.org/$(lsb_release) This may require keeping pypi-mirror and using an option to only do wheel building so that we can get the directory publication split. Ok. I got bored and wrote that: https://review.openstack.org/106638 So if we land that, you can do; pip wheel -r global-requirements.txt run-mirror --wheels-only --wheelhouse=wheelhouse --wheeldest=mirror rsync -avz mirror pypi.openstack.org:/srv/mirror If we went the devpi route, we could do; pip wheel -r global-requirements.txt for pkg in $wheelhouse; do devpi upload $pkg done And put that into a cron. Obviously keeping pypi-mirror would require the least amount of change to how we suggest developers set up their systems. I think the devpi option seems fairly reasonable too. It looks like it's easier (and faster, and less bandwidth-consuming) than setting up bandersnatch or apt-mirror, which we currently suggest people consider. It doesn't look any more heavyweight than having a squid proxy for caching, which we currently suggest as a bare minimum. For an individual dev testing their own setup, I think we need a slightly different approach from the infra approach listed above though. I'm assuming that it's possible to probe the package index to determine if a wheel is available for a particular version of a package yet. If that's the case, we should be able to tweak tools like os-svc-install to notice when no wheel is available, and build and upload the wheel. I think this should give us a good balance between making sure that each build (except the first) uses wheels to save time, still gets the latest packages (since the last time the system was online at least), and the user doesn't need to remember to manually update the wheels when they're online. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] pypi-mirror is now unsupported - what do we do now?
On 14 Jul 2014, at 08:08, Gregory Haynes g...@greghaynes.net wrote: On Sun, Jul 13, 2014, at 02:36 PM, James Polley wrote: We're also thinking about how we continue to offer the pre-built wheels for each of our build platforms. For infra, what I'm thinking is: On each mirror slave (We have one for each OS combo we use), do something similar to: pip wheel -r global-requirements.txt rsync $wheelhouse pypi.openstack.org/$(lsb_release) This may require keeping pypi-mirror and using an option to only do wheel building so that we can get the directory publication split. Ok. I got bored and wrote that: https://review.openstack.org/106638 So if we land that, you can do; pip wheel -r global-requirements.txt run-mirror --wheels-only --wheelhouse=wheelhouse --wheeldest=mirror rsync -avz mirror pypi.openstack.org:/srv/mirror If we went the devpi route, we could do; pip wheel -r global-requirements.txt for pkg in $wheelhouse; do devpi upload $pkg done And put that into a cron. Obviously keeping pypi-mirror would require the least amount of change to how we suggest developers set up their systems. I think the devpi option seems fairly reasonable too. It looks like it's easier (and faster, and less bandwidth-consuming) than setting up bandersnatch or apt-mirror, which we currently suggest people consider. It doesn't look any more heavyweight than having a squid proxy for caching, which we currently suggest as a bare minimum. For an individual dev testing their own setup, I think we need a slightly different approach from the infra approach listed above though. I'm assuming that it's possible to probe the package index to determine if a wheel is available for a particular version of a package yet. If that's the case, we should be able to tweak tools like os-svc-install to notice when no wheel is available, and build and upload the wheel. I think this should give us a good balance between making sure that each build (except the first) uses wheels to save time, still gets the latest packages (since the last time the system was online at least), and the user doesn't need to remember to manually update the wheels when they're online. This gave me an idea: There was talk about pip being able to use a wheel cache (wheelhouse). Can we bind-mount an arch-specific wheelhouse from the hypervisor into our chroots as we build? This would let people get most of the wheel speedup while doing almost no specifal configuration. Pip still doesn't handle case insensitivity on file:// indexurls as well as its does for http:// - that should be fixed with a 1.6.0 release. There's some chance that we'll run into issues with this that we wouldn't hit using http, but i don't expect any major issues. This still leaves us needing to build that arch-specific wheelhouse though -Greg ___ 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] [TripleO] pypi-mirror is now unsupported - what do we do now?
It may not have been clear from the below email, but clarkb clarifies on https://bugs.launchpad.net/openstack-ci/+bug/1294381 that the infra team is no longer maintaining pypi-mirror This has been a very useful tool for tripleo. It's much simpler for new developers to set up and use than a full bandersnatch mirror (and requires less disk space), and it can create a local cache of wheels which saves build time. But it's now unsupported. To me it seems like we have two options: A) Deprecate usage of pypi-mirror; update docs to instruct new devs in setting up a local bandersnatch mirror instead or B) Take on care-and-feeding of the tool. or, I guess, C) Continue to recommend people use an unsupported unmaintained known-buggy tool (it works reasonably well for us today, but it's going to work less and less well as time goes by) Are there other options I haven't thought of? Do you have thoughts on which option is preferred? -- Forwarded message -- From: Clark Boylan clark.boy...@gmail.com Date: Tue, Jul 8, 2014 at 8:50 AM Subject: Re: [openstack-dev] Policy around Requirements Adds (was: New class of requirements for Stackforge projects) To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org On Mon, Jul 7, 2014 at 3:45 PM, Joe Gordon joe.gord...@gmail.com wrote: On Jul 7, 2014 4:48 PM, Sean Dague s...@dague.net wrote: This thread was unfortunately hidden under a project specific tag (I have thus stripped all the tags). The crux of the argument here is the following: Is a stackforge project project able to propose additions to global-requirements.txt that aren't used by any projects in OpenStack. I believe the answer is firmly *no*. ++ global-requirements.txt provides a way for us to have a single point of vetting for requirements for OpenStack. It lets us assess licensing, maturity, current state of packaging, python3 support, all in one place. And it lets us enforce that integration of OpenStack projects all run under a well understood set of requirements. The requirements sync that happens after requirements land is basically just a nicety for getting openstack projects to the tested state by eventual consistency. If a stackforge project wants to be limited by global-requirements, that's cool. We have a mechanism for that. However, they are accepting that they will be limited by it. That means they live with how the OpenStack project establishes that list. It specifically means they *don't* get to propose any new requirements. Basically in this case Solum wants to have it's cake and eat it to. Both be enforced on requirements, and not be enforced. Or some 3rd thing that means the same as that. The near term fix is to remove solum from projects.txt. The email included below mentions an additional motivation for using global-requirements is to avoid using pypi.python.org and instead use pypi.openstack.org for speed and reliability. Perhaps there is a way we can support use case for stackforge projects not in projects.txt? I thought I saw something the other day about adding a full pypi mirror to OpenStack infra. This is done. All tests are now run against a bandersnatch built full mirror of pypi. Enforcement of the global requirements is performed via the enforcement jobs. On 06/26/2014 02:00 AM, Adrian Otto wrote: Ok, I submitted and abandoned a couple of reviews[1][2] for a solution aimed to meet my goals without adding a new per-project requirements file. The flaw with this approach is that pip may install other requirements when installing the one(s) loaded from the fallback mirror, and those may conflict with the ones loaded from the primary mirror. After discussing this further in #openstack-infra this evening, we should give serious consideration to adding python-mistralclient to global requirements. I have posted a review[3] for that to get input from the requirements review team. Thanks, Adrian [1] https://review.openstack.org/102716 [2] https://review.openstack.org/102719 [3] https://review.openstack.org/102738 https://review.openstack.org/1027387 On Jun 25, 2014, at 9:51 PM, Matthew Oliver m...@oliver.net.au mailto:m...@oliver.net.au wrote: On Jun 26, 2014 12:12 PM, Angus Salkeld angus.salk...@rackspace.com mailto:angus.salk...@rackspace.com wrote: On 25/06/14 15:13, Clark Boylan wrote: On Tue, Jun 24, 2014 at 9:54 PM, Adrian Otto adrian.o...@rackspace.com mailto:adrian.o...@rackspace.com wrote: Hello, Solum has run into a constraint with the current scheme for requirements management within the OpenStack CI system. We have a proposal for dealing with this constraint that involves making a contribution to openstack-infra. This message explains the constraint, and our proposal for addressing it. == Background == OpenStack uses a list of global requirements in the requirements repo[1], and each
Re: [openstack-dev] [TripleO] Time to break backwards compatibility for *cloud-password file location?
On Thu, Jul 3, 2014 at 5:33 AM, Sullivan, Jon Paul jonpaul.sulli...@hp.com wrote: -Original Message- From: Giulio Fidente [mailto:gfide...@redhat.com] Sent: 01 July 2014 13:08 Subject: Re: [openstack-dev] [TripleO] Time to break backwards compatibility for *cloud-password file location? On 06/25/2014 11:25 AM, mar...@redhat.com wrote: On 25/06/14 10:52, James Polley wrote: Until https://review.openstack.org/#/c/83250/, the setup-*-password scripts used to drop password files into $CWD, which meant that if you ran the script from a different location next time, your old passwords wouldn't be found. https://review.openstack.org/#/c/83250/ changed this so that the default behaviour is to put the password files in $TRIPLEO_ROOT; but for backwards compatibility we left the script checking to see if there's a file in the current directory, and using that file in preference to $TRIPLEO_ROOT if it exists. However, this behaviour is still confusing to people. I'm not entirely clear on why it's confusing (it makes perfect sense to me...) but I imagine it's because we still have the problem that the code works fine if run from one directory, but run from a different directory it can't find passwords. There are two open patches which would break backwards compatibility and only ever use the files in $TRIPLEO_ROOT: https://review.openstack.org/#/c/93981/ https://review.openstack.org/#/c/97657/ The latter review is under more active development, and has suggestions that the directory containing the password files should be parameterised, defaulting to $TRIPLEO_ROOT. This would still break for anyone who relies on the password files being in the directory they run the script from, but at least there would be a fairly easy fix for them. How about we: * parameterize as suggested by Fabio in the review @ https://review.openstack.org/#/c/97657/ +1 * move setting of this param to more visible location (setup, like devtest_variables or testenv). We can then give this better visibility in the dev/test autodocs with a warning about the 'old' behaviour +1 * add a deprecation warning to the code that reads from $CWD/tripleo-overcloud-passwords to say that this will now need to be set as a parameter in ... wherever. How long is a good period for this? +1 +1 Would it make sense to copy the passwords across such that the users behaviour is not changed were they to delete their old passwords file. The deprecation warning would read that they can set VAR to point to the passwords file they are currently using, or delete passwords file to pick up the new default location of VAR (which has defaulted to TRIPLEO_ROOT) This sounds like something I was trying in the first 10 revisions of https://review.openstack.org/#/c/83250. I ended up ditching it because it seemed like the logic was getting too complex. Eg, if someone has multiple sets of password files, this is fine when we see the first set - we just copy it to $TRIPLEO_ROOT and print the deprecation warning. But later on if we see a second file - do we clobber the one in $TRIPLEO_ROOT? Do we skip the copy and just print the deprecation warning, maybe with an addendum to point out that we've seen two different files? Do we diff the one in $CWD and the one in $TRIPLEO_ROOT to check if they're the same? At the time I was working on 83250 I decided it was simplest to not make any attempt to clean up, but maybe it's time to revisit that decision. actually, I have probably being the first suggesting that we should parametrize the path to the password files so I want to add my motivations here the big win that I see here is that people may want to customize only some of the passwords, for example, the undercloud admin the script creating the password files is *already* capable of pushing in the file only new passwords, without regenerating passwords which could have been manually set in there already this basically implements the 'feature' I mentioned except people just doesn't know it! so I'd like we to expose this as a feature, from the early stages as Marios suggests too, maybe from devtest_variables -- Giulio Fidente GPG KEY: 08D733BA ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Thanks, Jon-Paul Sullivan ☺ Cloud Services - @hpcloud Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park, Galway. Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John Rogerson's Quay, Dublin 2. Registered Number: 361933 The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error you should delete it from your system immediately and advise the sender
[openstack-dev] [TripleO] Weekly meeting
Minutes are at http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.html (or http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.txt if you prefer plain-text). For your convenience I've pasted them below. During the meeting it was suggested we add a Specs item to the agenda for any specs people want to ask for more eyeballs on. I've added this to the agenda for next week. I don't plan to regularly mail these minutes (they're always at http://eavesdrop.openstack.org/meetings/tripleo) but we had particularly low attendance today and we have a couple of time-sensitive one-off items. #openstack-meeting-alt: tripleoMeeting started by tchaypo at 06:59:56 UTC (full logs http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html ). Meeting summary 1. *bugs* (tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-11, 07:01:20) 1. https://bugs.launchpad.net/tripleo/ (tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-12, 07:01:29) 2. https://bugs.launchpad.net/diskimage-builder/ (tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-13, 07:01:32) 3. https://bugs.launchpad.net/os-refresh-config (tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-14, 07:01:34) 4. https://bugs.launchpad.net/os-apply-config (tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-15, 07:01:36) 5. https://bugs.launchpad.net/os-collect-config (tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-16, 07:01:38) 6. https://bugs.launchpad.net/os-cloud-config (tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-17, 07:01:40) 7. https://bugs.launchpad.net/tuskar (tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-18, 07:01:42) 8. https://bugs.launchpad.net/python-tuskarclient (tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-19, 07:01:44) 9. https://review.openstack.org/#/c/98758/ (GheRivero http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-29, 07:06:07) 2. *reviews* (tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-34, 07:07:40) 1. There's a new dashboard linked from https://wiki.openstack.org/wiki/TripleO#Review_team - look for TripleO Inbox Dashboard (tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-35, 07:07:44) 2. http://russellbryant.net/openstack-stats/tripleo-openreviews.html ( tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-36, 07:07:47) 3. http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt ( tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-37, 07:07:49) 4. http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt ( tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-38, 07:07:51) 5. 3rd quartile has dropped from 13 days 12 hours to 11 days 21 hours over the last week, other quartiles roughly unchanged (tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-50, 07:10:20) 6. stackforge/gertty is a tty-based locally-caching client for gerrit, so you can do reviews on a plane (tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-68, 07:14:41) 3. *Projects needing releases* (tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-78, 07:18:20) 1. shadower will release all the things (shadower http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-100, 07:21:46) 2. https://wiki.openstack.org/wiki/TripleO/ReleaseManagement (tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-105, 07:22:24) 4. *CD Cloud status* (tchaypo http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-109, 07:22:37) 1. https://review.openstack.org/#/c/102291/ should land before releasing dif-utils (shadower http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.log.html#l-112, 07:23:18) 2.
[openstack-dev] [TripleO] Time to break backwards compatibility for *cloud-password file location?
Until https://review.openstack.org/#/c/83250/, the setup-*-password scripts used to drop password files into $CWD, which meant that if you ran the script from a different location next time, your old passwords wouldn't be found. https://review.openstack.org/#/c/83250/ changed this so that the default behaviour is to put the password files in $TRIPLEO_ROOT; but for backwards compatibility we left the script checking to see if there's a file in the current directory, and using that file in preference to $TRIPLEO_ROOT if it exists. However, this behaviour is still confusing to people. I'm not entirely clear on why it's confusing (it makes perfect sense to me...) but I imagine it's because we still have the problem that the code works fine if run from one directory, but run from a different directory it can't find passwords. There are two open patches which would break backwards compatibility and only ever use the files in $TRIPLEO_ROOT: https://review.openstack.org/#/c/93981/ https://review.openstack.org/#/c/97657/ The latter review is under more active development, and has suggestions that the directory containing the password files should be parameterised, defaulting to $TRIPLEO_ROOT. This would still break for anyone who relies on the password files being in the directory they run the script from, but at least there would be a fairly easy fix for them. To help decide if it's time to break backwards compatibility in this case (and if so, how), I'd love to see some more comments on 97657. If we don't want to break backwards compatibility, maybe comments about a better way to handle the ambiguity would be helpful. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Reviews - we need your help!
Thanks Tomas and Matthew I've updated https://wiki.openstack.org/wiki/TripleO#Review_team to have a link to the new dashboard. On Fri, Jun 13, 2014 at 5:20 PM, Macdonald-Wallace, Matthew matthew.macdonald-wall...@hp.com wrote: Thanks Tomas, http://bit.ly/1lsg3SH now contains the missing projects and has been re-ordered slightly so that you see outdated reviews first then the Jenkins/-1 stuff. Cheers, Matt -Original Message- From: Tomas Sedovic [mailto:tsedo...@redhat.com] Sent: 12 June 2014 19:03 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [TripleO] Reviews - we need your help! On 12/06/14 16:02, Macdonald-Wallace, Matthew wrote: FWIW, I've tried to make a useful dashboard for this using Sean Dague's gerrit-dash-creator [0]. Short URL is http://bit.ly/1l4DLFS long url is: https://review.openstack.org/#/dashboard/?foreach=%28project%3Aopenstack %2Ftripleo-incubator+OR+project%3Aopenstack%2Ftripleo-image- elements+OR+project%3Aopenstack%2Ftripleo-heat- templates+OR+project%3Aopenstack%2Ftripleo- specs+OR+project%3Aopenstack%2Fos-apply- config+OR+project%3Aopenstack%2Fos-collect- config+OR+project%3Aopenstack%2Fos-refresh- config+OR+project%3Aopenstack%2Fdiskimage- builder%29+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D- 1+label%3AVerified%3E%3D1%252cjenkins+NOT+label%3ACode- Review%3E%3D- 2%252cself+branch%3Amaster+status%3Aopentitle=TripleO+ReviewsYour+a re+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=reviewer% 3AselfPassed+Jenkins%2C+No+Negative+Feedback=NOT+label%3ACode- Review%3C%3D- 1+limit%3A100Changes+with+no+code+review+in+the+last+48hrs=NOT+label %3ACode- Review%3C%3D2+age%3A48hChanges+with+no+code+review+in+the+last+5+ days=NOT+label%3ACode- Review%3C%3D2+age%3A5dChanges+with+no+code+review+in+the+last+7+d ays=NOT+label%3ACode-Review%! 3C%3D2+age %3A7dSome+adjustment+required+%28-1+only%29=label%3ACode- Review%3D-1+NOT+label%3ACode-Review%3D- 2+limit%3A100Dead+Specs+%28-2%29=label%3ACode-Review%3C%3D-2 I'll add it to my fork and submit a PR if people think it useful. I was about to mention this, too. The gerrit-dash-creator is fantastic. This one is missing the Tuskar-related projects (openstack/tuskar, openstack/tuskar-ui and openstack/python-tuskarclient) and also openstack/os- cloud-config, though. Matt [0] https://github.com/sdague/gerrit-dash-creator *From:*James Polley [mailto:j...@jamezpolley.com] *Sent:* 12 June 2014 06:08 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* [openstack-dev] [TripleO] Reviews - we need your help! During yesterday's IRC meeting, we realized that our review stats are starting to slip again. Just after summit, our stats were starting to improve. In the 2014-05-20 meeting, the TripleO Stats since the last revision without -1 or -2[1] looked like this: 1rd quartile wait time: 1 days, 1 hours, 11 minutes Median wait time: 6 days, 9 hours, 49 minutes 3rd quartile wait time: 13 days, 5 hours, 46 minutes As of yesterdays meeting, we have: 1rd quartile wait time: 4 days, 23 hours, 19 minutes Median wait time: 7 days, 22 hours, 8 minutes 3rd quartile wait time: 13 days, 19 hours, 17 minutes This really hurts our velocity, and is especially hard on people making their first commit, as it can take them almost a full work week before they even get their first feedback. To get things moving, we need everyone to make a special effort to do a few reviews every day. It would be most helpful if you can look for older reviews without a -1 or -2 and help those reviews get over the line. If you find reviews that are just waiting for a simple fix - typo or syntax fixes, simple code fixes, or a simple rebase - it would be even more helpful if you could take a few minutes to make those patches, rather than just leaving the review waiting for the attention of the original submitter. Please keep in mind that these stats are based on all of our projects, not just tripleo-incubator. To save you heading to the wiki, here's a handy link that shows you all open code reviews in all our projects: bit.ly/1hQco1N http://bit.ly/1hQco1N If you'd prefer the long version: https://review.openstack.org/#/q/status:open+%28project:openstack/trip leo-incubator+OR+project:openstack/tuskar+OR+project:openstack/tuskar- ui+OR+project:openstack-infra/tripleo-ci+OR+project:openstack/os-apply -config+OR+project:openstack/os-collect-config+OR+project:openstack/os -refresh-config+OR+project:openstack/os-cloud-config+OR+project:openst ack/tripleo-image-elements+OR+project:openstack/tripleo-heat-templates +OR+project:openstack/diskimage-builder+OR+project:openstack/python-tu skarclient
[openstack-dev] [TripleO] Reviews - we need your help!
During yesterday's IRC meeting, we realized that our review stats are starting to slip again. Just after summit, our stats were starting to improve. In the 2014-05-20 meeting, the TripleO Stats since the last revision without -1 or -2[1] looked like this: 1rd quartile wait time: 1 days, 1 hours, 11 minutesMedian wait time: 6 days, 9 hours, 49 minutes3rd quartile wait time: 13 days, 5 hours, 46 minutes As of yesterdays meeting, we have: 1rd quartile wait time: 4 days, 23 hours, 19 minutesMedian wait time: 7 days, 22 hours, 8 minutes3rd quartile wait time: 13 days, 19 hours, 17 minutes This really hurts our velocity, and is especially hard on people making their first commit, as it can take them almost a full work week before they even get their first feedback. To get things moving, we need everyone to make a special effort to do a few reviews every day. It would be most helpful if you can look for older reviews without a -1 or -2 and help those reviews get over the line. If you find reviews that are just waiting for a simple fix - typo or syntax fixes, simple code fixes, or a simple rebase - it would be even more helpful if you could take a few minutes to make those patches, rather than just leaving the review waiting for the attention of the original submitter. Please keep in mind that these stats are based on all of our projects, not just tripleo-incubator. To save you heading to the wiki, here's a handy link that shows you all open code reviews in all our projects: bit.ly/1hQco1N If you'd prefer the long version: https://review.openstack.org/#/q/status:open+%28project:openstack/tripleo-incubator+OR+project:openstack/tuskar+OR+project:openstack/tuskar-ui+OR+project:openstack-infra/tripleo-ci+OR+project:openstack/os-apply-config+OR+project:openstack/os-collect-config+OR+project:openstack/os-refresh-config+OR+project:openstack/os-cloud-config+OR+project:openstack/tripleo-image-elements+OR+project:openstack/tripleo-heat-templates+OR+project:openstack/diskimage-builder+OR+project:openstack/python-tuskarclient+OR+project:openstack/tripleo-specs%29,n,z https://wiki.openstack.org/wiki/TripleO#Bug_Triage has links to reviews for individual projects as well as more information about how we triage bugs. [1] http://www.nemebean.com/reviewstats/tripleo-open.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup
On Fri, May 30, 2014 at 4:57 AM, Zane Bitter zbit...@redhat.com wrote: On 29/05/14 13:33, Mike Spreitzer wrote: Devananda van der Veen devananda@gmail.com wrote on 05/29/2014 01:26:12 PM: Hi Jaromir, I agree that the midcycle meetup with TripleO and Ironic was very beneficial last cycle, but this cycle, Ironic is co-locating its sprint with Nova. Our focus needs to be working with them to merge the nova.virt.ironic driver. Details will be forthcoming as we work out the exact details with Nova. That said, I'll try to make the TripleO sprint as well -- assuming the dates don't overlap. Cheers, Devananda On Wed, May 28, 2014 at 4:05 AM, Jaromir Coufal jcou...@redhat.com wrote: Hi to all, after previous TripleO Ironic mid-cycle meetup, which I believe was beneficial for all, I would like to suggest that we meet again in the middle of Juno cycle to discuss current progress, blockers, next steps and of course get some beer all together :) Last time, TripleO and Ironic merged their meetings together and I think it was great idea. This time I would like to invite also Heat team if they want to join. Our cooperation is increasing and I think it would be great, if we can discuss all issues together. Red Hat offered to host this event, so I am very happy to invite you all and I would like to ask, who would come if there was a mid-cycle meetup in following dates and place: * July 28 - Aug 1 * Red Hat office, Raleigh, North Carolina If you are intending to join, please, fill yourselves into this etherpad: https://etherpad.openstack.org/p/juno-midcycle-meetup Cheers -- Jarda Given the organizers, I assume this will be strongly focused on TripleO and Ironic. Would this be a good venue for all the mid-cycle discussion that will be relevant to Heat? Is anyone planning a distinct Heat-focused mid-cycle meetup? We haven't had one in the past, but the project is getting bigger so, given our need to sync with the TripleO folks anyway, this may be a good opportunity to try. Certainly it's unlikely that any Heat developers attending will spend the _whole_ week working with the TripleO team, so there should be time to do something like what you're suggesting. I think we just need to see who is willing able to attend, and work out an agenda on that basis. For my part, I will certainly be there for the whole week if it's July 28 - Aug 1. If it's the week before I may not be able to make it at all. BTW one timing option I haven't seen mentioned is to follow Pycon-AU's model of running e.g. Friday-Tuesday (July 25-29). I know nobody wants to be stuck in Raleigh, NC on a weekend (I've lived there, I understand ;), but for folks who have a long ways to travel it's one weekend lost instead of two. I quite like this idea. Yes, it means a weekend in Raleigh, but that's better than spending 1.5 weekends on a plane, which is what I have to do at the moment. I'll still be spending just as much time on a plane, but doing it during the week has less of an impact on my work/life balance. Alternatively maybe we can find somewhere to host the next mid-cycle Down Under ;) cheers, Zane. ___ 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] [TripleO] Adding Tuskar to weekly IRC meetings agenda
On 30 May 2014, at 8:13 pm, Jaromir Coufal jcou...@redhat.com wrote: Hi All, I would like to propose to add Tuskar as a permanent topic to the agenda for our weekly IRC meetings. It is an official TripleO's project, there happening quite a lot around it and we are targeting for Juno to have something solid. So I think that it is important for us to regularly keep track on what is going on there. Sounds good to me. What do you think we would talk about under this topic? I'm thinking that a brief summary of changes since last week, and any blockers tuskar is seeing from the broader project would be a good start? -- Jarda ___ 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] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup
Thanks for putting this together Jaromir! August 1 may be a problem for those of us from Australia - it's the day of the OpenStack miniconf at Pycon-AU. I don't know if any of us intended to go to that, but if we did we'd need to leave no later than the 4:40pm flight on July 30 in order to make it back in time - and that would have us arriving in Brisbane at 7am on the day of the miniconf. If we stayed till midday Friday and caught the 4:40pm flight out, we'd arrive in BNE at 7am on the 3rd - just in time for the last day of talks and the two days of sprints. As I said, I'm not sure how many other people from this part of the world had intended to go to Pycon-AU and the openstack miniconf, so I'm not sure how much of a problem this is. On Wed, May 28, 2014 at 9:05 PM, Jaromir Coufal jcou...@redhat.com wrote: Hi to all, after previous TripleO Ironic mid-cycle meetup, which I believe was beneficial for all, I would like to suggest that we meet again in the middle of Juno cycle to discuss current progress, blockers, next steps and of course get some beer all together :) Last time, TripleO and Ironic merged their meetings together and I think it was great idea. This time I would like to invite also Heat team if they want to join. Our cooperation is increasing and I think it would be great, if we can discuss all issues together. Red Hat offered to host this event, so I am very happy to invite you all and I would like to ask, who would come if there was a mid-cycle meetup in following dates and place: * July 28 - Aug 1 * Red Hat office, Raleigh, North Carolina If you are intending to join, please, fill yourselves into this etherpad: https://etherpad.openstack.org/p/juno-midcycle-meetup Cheers -- Jarda ___ 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] [TripleO] Change of meeting time
Following a lengthy discussion under the subject Alternating meeting tmie for more TZ friendliness, the TripleO meeting now alternates between Tuesday 1900UTC (the former time) and Wednesday 0700UTC, for better coverage across Australia, India, China, Japan, and the other parts of the world that found it impossible to get to our previous meeting time. https://wiki.openstack.org/wiki/Meetings/TripleO#Weekly_TripleO_team_meetinghas been updated with a link to the iCal feed so you can figure out which time we're using each week. The coming meeting will be our first Wednesday 0700UTC meeting. We look forward to seeing some fresh faces (well, fresh nicks at least)! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Installation instructions
On Wed, May 21, 2014 at 4:31 PM, Jason Rist jr...@redhat.com wrote: On 05/21/2014 02:22 PM, Sanchez, Cristian A wrote: Hi, In our team we’re planning to make some contributions to TripleO, after we met with Robert Collins in an Intel hosted meeting during Summit. As our first step we want to use TripleO to deploy the under-cloud and over-cloud. Is there some instructions of how to start with this? Thanks Cristian ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hi Cristian - There are quite a few options. Some of us do devtest: https://wiki.openstack.org/wiki/Tuskar/Devtest There are more docs for devtest at http://docs.openstack.org/developer/tripleo-incubator/devtest.html - less RedHat specific, but they won't get you to the point of having Tuskar running. That doc links to docs for the devtest_undercloud.sh and devtest_overcloud.sh scripts, which will show you one way to deploy the clouds. Some of us do instack: https://github.com/slagle/instack And some of us do devstack and then fire up another horizon with tuskar-ui running: https://github.com/openstack/tuskar-ui/blob/master/doc/source/install.rst -J -- Jason E. Rist Senior Software Engineer OpenStack Management UI Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/identi.ca: knowncitizen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Spec Template Change Proposal
On Wed, May 21, 2014 at 4:37 PM, Jay Dobies jason.dob...@redhat.com wrote: Currently, there is the following in the template: Proposed change === [snip] Alternatives [snip] Security impact --- The unit tests assert the top and second level sections are standard, so if I add a section at the same level as Alternatives under Proposed Change, the tests will fail. If I add a third level section using ^, they pass. The problem is that you can't add a ^ section under Proposed Change. Sphinx complains about a title level inconsistency since I'm skipping the second level and jumping to the third. But I can't add a second-level section directly under Proposed Change because it will break the unit tests that validate the structure. The proposed change is going to be one of the beefier sections of a spec, so not being able to subdivide it is going to make the documentation messy and removes the ability to link directly to a portion of a proposed change. I propose we add a section at the top of Proposed Change called Overview that will hold the change itself. That will allow us to use third level sections in the change itself while still having the first and section section structure validated by the tests. I like all of this plan, except for the name Overview. To me, Overview suggests a high-level summary rather than being one of the beefier sections of a spec. Something like Detail or Detailed overview (because the low-level detail will come in the changes that implement the spec, not in the spec) seem like better descriptions of what we intend to have there. I have no problem making the change to the templates, unit tests, and any existing specs (I don't think we have any yet), but before I go through that, I wanted to make sure there wasn't a major disagreement. Thoughts? ___ 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] [TripleO] Use of environment variables in tripleo-incubator
I spoke to JP offline and confirmed that the link to 85418 should have been a link to https://review.openstack.org/#/c/88252 I think that https://etherpad.openstack.org/p/tripleo-incubator-rationalise-ui and https://etherpad.openstack.org/p/tripleo-devtest.sh-refactoring-blueprintare the closest things to documentation we've got about this. Now that we have the specs repo, perhaps we should be creating a spec and moving the discussion there. On Tue, May 20, 2014 at 12:06 PM, Sullivan, Jon Paul jonpaul.sulli...@hp.com wrote: Hi, There are a number of reviews[1][2] where new environment variables are being disliked, leading to -1 or -2 code reviews because new environment variables are added. It is looking like this is becoming a policy. If this is a policy, then could that be stated, and an alternate mechanism made available so that any reviews adding environment variables can use the replacement mechanism, please? Otherwise, some guidelines for developers where environment variables are acceptable or not would equally be useful. [1] https://review.openstack.org/85009 [2] https://review.openstack.org/85418 Thanks, ,: jonpaul.sulli...@hp.com J *Cloud Services - @hpcloud* (: +353 (91) 75 4169 Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park, Galway. Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John Rogerson's Quay, Dublin 2. Registered Number: 361933 The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated, you should consider this message and attachments as HP CONFIDENTIAL. ___ 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] [TripleO] Alternating meeting time for more TZ friendliness
To revive this thread... I'd really like to see us trying out alternate meeting times for a while. Tuesdays at 14:00 UTC on #openstack-meeting-alt is available. Looking at the iCal feed it looks like it's actually taken by Solum. But in any case: On Thu, Mar 20, 2014 at 11:17 AM, Robert Collins robe...@robertcollins.net wrote: I think we need a timezone to cover the current impossible regions: - Australia - China / Japan - India 1400UTC is midnight Sydney time, 11pm Tokyo, 7:30pm New Delhi. Personally that's worse for me than 1700UTC. I'd prefer to move it significantly later than 1900UTC, especially if we want a time that's civilized (or at least, achievable) in India. 0700UTC seems ideal to me - 5pm Sydney, 4pm Tokyo, 12:30pm New Delhi. It's not friendly to the US (midnight SF, 3am NYC). but it should work well for Europe - 8am London, and it gets later in the day as you go east. What would we need to do to try this time out next week? On Thu, Mar 20, 2014 at 8:03 PM, j...@ioctl.org wrote: On Wed, 19 Mar 2014, Sullivan, Jon Paul wrote: From: James Slagle [mailto:james.sla...@gmail.com] Sent: 18 March 2014 19:58 Subject: [openstack-dev] [TripleO] Alternating meeting time for more TZ friendliness Our current meeting time is Tuesdays at 19:00 UTC. I think this works ok for most folks in and around North America. It was proposed during today's meeting to see if there is interest is an alternating meeting time every other week so that we can be a bit more friendly to those folks that currently can't attend. If that interests you, speak up :). Speaking up! :D Also interested. Tuesdays at 14:00 UTC on #openstack-meeting-alt is available. Relatively speaking, that's actually sociable. -- Update your address books: j...@ioctl.org http://ioctl.org/jan/ perl -e 's?ck?t??print:perl==pants if $_=Just Another Perl Hacker\n' ___ 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] [TripleO] Alternating meeting time for more TZ friendliness
Actually, it's probably best that we don't do the first meeting at a US-unfriendly timezone in a week that the summit is on in Atlanta. Maybe the week after summit, or even the second week after summit? On Tue, May 6, 2014 at 10:49 AM, James Polley j...@jamezpolley.com wrote: To revive this thread... I'd really like to see us trying out alternate meeting times for a while. Tuesdays at 14:00 UTC on #openstack-meeting-alt is available. Looking at the iCal feed it looks like it's actually taken by Solum. But in any case: On Thu, Mar 20, 2014 at 11:17 AM, Robert Collins robe...@robertcollins.net wrote: I think we need a timezone to cover the current impossible regions: - Australia - China / Japan - India 1400UTC is midnight Sydney time, 11pm Tokyo, 7:30pm New Delhi. Personally that's worse for me than 1700UTC. I'd prefer to move it significantly later than 1900UTC, especially if we want a time that's civilized (or at least, achievable) in India. 0700UTC seems ideal to me - 5pm Sydney, 4pm Tokyo, 12:30pm New Delhi. It's not friendly to the US (midnight SF, 3am NYC). but it should work well for Europe - 8am London, and it gets later in the day as you go east. What would we need to do to try this time out next week? On Thu, Mar 20, 2014 at 8:03 PM, j...@ioctl.org wrote: On Wed, 19 Mar 2014, Sullivan, Jon Paul wrote: From: James Slagle [mailto:james.sla...@gmail.com] Sent: 18 March 2014 19:58 Subject: [openstack-dev] [TripleO] Alternating meeting time for more TZ friendliness Our current meeting time is Tuesdays at 19:00 UTC. I think this works ok for most folks in and around North America. It was proposed during today's meeting to see if there is interest is an alternating meeting time every other week so that we can be a bit more friendly to those folks that currently can't attend. If that interests you, speak up :). Speaking up! :D Also interested. Tuesdays at 14:00 UTC on #openstack-meeting-alt is available. Relatively speaking, that's actually sociable. -- Update your address books: j...@ioctl.org http://ioctl.org/jan/ perl -e 's?ck?t??print:perl==pants if $_=Just Another Perl Hacker\n' ___ 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] [TripleO] Alternating meeting time for more TZ friendliness
On 20 Mar 2014, at 5:44 am, Clint Byrum cl...@fewbar.com wrote: Excerpts from Sullivan, Jon Paul's message of 2014-03-19 09:26:44 -0700: From: James Slagle [mailto:james.sla...@gmail.com] Sent: 18 March 2014 19:58 Subject: [openstack-dev] [TripleO] Alternating meeting time for more TZ friendliness Our current meeting time is Tuesdays at 19:00 UTC. I think this works ok for most folks in and around North America. It was proposed during today's meeting to see if there is interest is an alternating meeting time every other week so that we can be a bit more friendly to those folks that currently can't attend. If that interests you, speak up :). Speaking up! :D For reference, the current meeting schedules are at: https://wiki.openstack.org/wiki/Meetings Tuesdays at 14:00 UTC on #openstack-meeting-alt is available. If we were to have one at that time, we'd need to move the other time as well. One driver for moving it is that our participants on the Eastern side of Australia are already joining at 0600 their time, and will be joining at 0500 soon. If I've done my TZ math right, Tuesdays at 1400 UTC would be Wednesdays at 0100 for Sydney. 0100 now, in a few weeks when DST flips here. I'd prefer 0500 to My first priority is making sure that theacimum Speaking for myself, I find the current time is slightly painful, but doable. 0500 will be more painful. If I'm reading the iCal feed linked from https://wiki.openstack.org/wiki/Meetings correctly, it looks like there's a PCI passthrough meeting scheduled at that time in -alt. Is that correct? Is the iCal feed canonical? I don't see the meeting listed on the page, but maybe that's also because of the tiny little screen I'm using right now. If I'm doing the timezone math right, it looks like the iCal feed says that 2100UTC Wednesday is free every second week. Once all the DST flips happen, that'll be 2100 London, 1500 SF, 0700 Sydney. If we ran at that time on alternate weeks I'd have one I could make easily and one I could probably make at a stretch. ___ 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] [TripleO] Alternating meeting time for more TZ friendliness
On Thu, Mar 20, 2014 at 7:00 AM, James Polley j...@jamezpolley.com wrote: On 20 Mar 2014, at 5:44 am, Clint Byrum cl...@fewbar.com wrote: Excerpts from Sullivan, Jon Paul's message of 2014-03-19 09:26:44 -0700: From: James Slagle [mailto:james.sla...@gmail.com james.sla...@gmail.com ] Sent: 18 March 2014 19:58 Subject: [openstack-dev] [TripleO] Alternating meeting time for more TZ friendliness Our current meeting time is Tuesdays at 19:00 UTC. I think this works ok for most folks in and around North America. It was proposed during today's meeting to see if there is interest is an alternating meeting time every other week so that we can be a bit more friendly to those folks that currently can't attend. If that interests you, speak up :). Speaking up! :D For reference, the current meeting schedules are at: https://wiki.openstack.org/wiki/Meetings Tuesdays at 14:00 UTC on #openstack-meeting-alt is available. If we were to have one at that time, we'd need to move the other time as well. One driver for moving it is that our participants on the Eastern side of Australia are already joining at 0600 their time, and will be joining at 0500 soon. If I've done my TZ math right, Tuesdays at 1400 UTC would be Wednesdays at 0100 for Sydney. 0100 now, in a few weeks when DST flips here. I'd prefer 0500 to My first priority is making sure that theacimum Ah. So that's what happened to the email I was composing on my iPhone - it got sent! Next time I'll ask my pocket to delete it rather than send it. As I was trying to say, I think our priority should be maximizing the number of people who can attend, not maximizing for me attending. I worry that having alternating meetings will lead to having non-overlapping sets of people in the meetings, but even if that happens I'm not sure if it's worse than only having a subset of people in the meeting. I'd be happy to stick with 1900UTC if it means more people can regularly make the meeting, even if it means I can't make it all the time. Switching to alternating 1900 Tuesday and 2100 Wednesday would mean I could make more meetings, but I don't know how it would affect other people. Speaking for myself, I find the current time is slightly painful, but doable. 0500 will be more painful. If I'm reading the iCal feed linked from https://wiki.openstack.org/wiki/Meetings correctly, it looks like there's a PCI passthrough meeting scheduled at that time in -alt. Is that correct? Is the iCal feed canonical? I don't see the meeting listed on the page, but maybe that's also because of the tiny little screen I'm using right now. If I'm doing the timezone math right, it looks like the iCal feed says that 2100UTC Wednesday is free every second week. Once all the DST flips happen, that'll be 2100 London, 1500 SF, 0700 Sydney. Bad time math - I was in the middle of updating this when my phone decided to send the mail. 2100UTC will be 2200 London, 1400 SF, 0700 Sydney. If we ran at that time on alternate weeks I'd have one I could make easily and one I could probably make at a stretch. ___ 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] [heatclient] Jenkins Fail (gate-python-heatclient-pypy FAILURE)
I believe this is the issue being tracked in https://bugs.launchpad.net/openstack-ci/+bug/1290562 The latest update to that issue has a suggested workaround. On Tue, Mar 18, 2014 at 6:32 PM, 黎林果 lilinguo8...@gmail.com wrote: Hi, Anybody know the Jenkins Fail? I've encountered this fail in tow patches. gate-python-heatclient-pypyhttp://logs.openstack.org/58/73558/7/check/gate-python-heatclient-pypy/5157eed FAILURE in 1m 28s error: option --single-version-externally-managed not recognized ERROR: could not install deps [-r/home/jenkins/workspace/gate-python-heatclient-pypy/requirements.txt, -r/home/jenkins/workspace/gate-python-heatclient-pypy/test-requirements.txt] http://logs.openstack.org/58/73558/7/check/gate-python-heatclient-pypy/5157eed/console.html https://review.openstack.org/#/c/73558/ Thanks! ___ 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] [Tripleo] tripleo-cd-admins team update / contact info question
I'm not sure how well it would work here, but I've used Pagerduty.com for something similar before. The big up side of pagerduty is that it is pretty good at contacting people who aren't at their computers. It supports email notifications and webhooks for people who want to lots of control over what to do with alerts; push notifications to iOS or Android; and SMS or phone call as a last resort. Each person can configure their own alerts to suit them It handles escalating unhandled alerts, including looping back to the start if it can't reach anyone. It allows incidents to be handed over to arbitrary people regardless of who the roster says is on call, and for schedule overrides when a shift has to be reassigned. Incidents can be created via REST, email, or (I think) webhooks, so it's easy for users or for automated systems to raise an alarm It has some drawbacks: it would force us to define a rotation (or several rotations, one for each region, if we want to follow the sun), and someone needs to pay for it. I think it handles most of what we want though. It gives infra admins a bat-signal to request urgent help, and it gives us a way to ping other team members when we need to hand over. It isn't very good for $randoms asking for low-priority issues though - it treats every incident as equally urgent. I haven't used it, but opsgenie seems to have a similar set of features (more, if https://www.opsgenie.com/pagerduty is to be believed) On 26 Feb 2014, at 9:30 am, Robert Collins robe...@robertcollins.net wrote: In the tripleo meeting today we re-affirmed that the tripleo-cd-admins team is aimed at delivering production-availability clouds - thats how we know the the tripleo program is succeeding (or not !). So if you're a member of that team, you're on the hook - effectively on call, where production issues will take precedence over development / bug fixing etc. We have the following clouds today: cd-undercloud (baremetal, one per region) cd-overcloud (KVM in the HP region, not sure yet for the RH region) - multi region. ci-overcloud (same as cd-overcloud, and will go away when cd-overcloud is robust enough). And we have two users: - TripleO ATCs, all of whom are eligible for accounts on *-overcloud - TripleO reviewers, indirectly via openstack-infra who provide 99% of the load on the clouds Right now when there is a problem, there's no clearly defined 'get hold of someone' mechanism other than IRC in #tripleo. And thats pretty good since most of the admins are on IRC most of the time. But. There are two holes - a) what if its sunday evening :) and b) what if someone (for instance Derek) has been troubleshooting a problem, but needs to go do personal stuff, or you know, sleep. There's no reliable defined handoff mechanism. So - I think we need to define two things: - a stock way for $randoms to ask for support w/ these clouds that will be fairly low latency and reliable. - a way for us to escalate to each other *even if folk happen to be away from the keyboard at the time*. And possibly a third: - a way for openstack-infra admins to escalate to us in the event of OMG things happening. Like, we send 1000 VMs all at once at their git mirrors or something. And with that lets open the door for ideas! -Rob -- Robert Collins rbtcoll...@hp.com 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Fwd: [TripleO] mid-cycle meetup?
I'd love to come, but at this stage I won't be able to travel before about March 3, which sounds like it's a few weeks later than most people were thinking of. -- Forwarded message -- From: Robert Collins robe...@robertcollins.netmailto:robe...@robertcollins.net robe...@robertcollins.net Date: 24 January 2014 08:47 Subject: [TripleO] mid-cycle meetup? To: openstack-operat...@lists.openstack.orgmailto:openstack-operat...@lists.openstack.org openstack-operat...@lists.openstack.org openstack-operat...@lists.openstack.orgmailto:openstack-operat...@lists.openstack.org openstack-operat...@lists.openstack.org Hi, sorry for proposing this at *cough* the mid-way point [christmas shutdown got in the way of internal acks...], but who would come if there was a mid-cycle meetup? I'm thinking the HP sunnyvale office as a venue. -Rob -- Robert Collins rbtcoll...@hp.commailto:rbtcoll...@hp.com rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
