Re: [openstack-dev] [OpenStack-Infra] [infra][security] Encryption in Zuul v3
On 22 March 2017 at 15:02, James E. Blair <cor...@inaugust.com> wrote: > Ian Cordasco <sigmaviru...@gmail.com> writes: > > > > > I suppose Barbican doesn't meet those requirements either, then, yes? > > Right -- we don't want to require another service or tie Zuul to an > authn/authz system for a fundamental feature. However, I do think we > can look at making integration with Barbican and similar systems an > option for folks who have such an installation and prefer to use it. > > -Jim > Sounds like you're going to make this plugable, is that a hard requirement that will be added to the spec? or just a possibility? -- Darragh Bailey "Nothing is foolproof to a sufficiently talented fool" __ 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] [git-upstream] [Duplicate Changes] How to view only commits applied since last import
On 18/11/16 15:27, Darragh Bailey - mailing lists wrote: > > At this point, now you'll see X, X' & X'', and Y, Y' & Y''. Obviously > this cause a bit of confusion when listing the changes using: > > git log --oneline --graph E~1..local/mitaka > > you see something like the following (see [1] for how I created this): > > * 899cb6e [O] Merging Y2 into N > |\ > | * 3c08f48 [Y] Adding tmp7wtzvo69 <--- really Y'' > | * db8d2c3 [X] Adding tmpnxot0u9s > | * 97cc90c [I] Adding tmps2xhxp2f > * | 9ea35c3 [N] Merging Y1 into Y > |\ \ > | * | f361e9f [Y] Adding tmp7wtzvo69 <--- really Y' > | * | 90d58eb [X] Adding tmpnxot0u9s > | |/ > | * ed973e6 [G] Adding tmpb443aabz > | * 74cd9b8 [E] Adding tmpwcrm4bxi > * 3cc85cf [Y] Adding tmp7wtzvo69 <--- original Y > * e93f6cb [X] Adding tmpnxot0u9s I forgot to add the reference for how I generated that tree: git clone git://git.openstack.org/openstack/git-upstream cd git-upstream cat < test.yaml - tree: - [A, []] - [E, [A]] - [G, [E]] - [I, [G]] - [X, [A]] - [Y, [X]] - [X1, [G]] - [Y1, [X1]] - [N, [Y, =Y1]] - [X2, [I]] - [Y2, [X2]] - [O, [N, =Y2]] branches: head: [local/mitaka, O] upstream: [stable/mitaka, I] EOF tox -e build-tree -- test.yaml cd .git-test-trees/test -- Regards, Darragh Bailey IRC: electrofelix "Nothing is foolproof to a sufficiently talented fool" - Unknown __ 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] [git-upstream] [Duplicate Changes] How to view only commits applied since last import
blished branch can work, and I know some linux kernel developers have special published branches that are regularly rebased, so it can be made work. * Avoiding needing a dedicated maintainer. When merge to resolve conflicts between branches with multiple divergent commits are involved, it frequently means the person needs to know a lot of the codebase or be really good with git, and in turn have someone that can review all the conflicts sensibly in Gerrit. Assuming you're planning on contributing the changes upstream, someone is going to have to resolve the conflict for each change anyway and upload for review against the upstream. Having a dedicated maintainer can work within some projects, but many grow to the point that different people know different sections better. And if you're goal is collaboration and promoting exchange of knowledge it seems better to avoid silo'ing related knowledge. If instead the conflicts are resolved for each carried change, it's possible to re-review the updated patch with the context of what that change was intended to resolve (and submit an updated patch for upstream). It seemed unlikely to me that it would be possible to maximise the automated syncing, since the odds of a conflict seemed high: * locally landed changes are likely to be done because there is a problem and need to keep something working * getting accepted upstream means it should do the right thing The correct approach could be either superficially or logically different. Potentially the correct fix was to amend some code elsewhere. If we merged from upstream, and resolved a conflict, then the correct fix appeared upsteam, how to automatically drop the local changes? Since they can't be simply reverted without the conflict resolution in the merge conflicting on revert of the earlier change. Seems more likely to require a lot more manual effort. Also looked previously at using a dedicated branch and rebasing the changes from the previous onto the updated: * Any local changes not yet landed need to be re-targeted * Have to block any changes submitted against the outdated * Developers need to be provided with a tool that knows which is the correct branch and re-target before uploading the commit for review each time. Other alternatives to this include using a patch series (guilt, git-buildpackage), or producing a different target branch or rewriting the history in way that would cause issues if the branch was published (think topgit and stgit work this way). Not familiar enough with git-series to know which set to include it in, and there is also "pry", which I think is taking a list of patch id's to retrieve from OpenStack Gerrit to be applied on top, and used by RackSpace??? So a few solutions in this area using different approaches for different benefits/trade-offs. YMMV, and I'm almost certain I'm forgetting some reasons as well ;-) -- Regards, Darragh Bailey IRC: electrofelix "Nothing is foolproof to a sufficiently talented fool" - Unknown __ 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] [git-upstream] [Additional Branches] How to view only commits applied since last import
On 17/11/16 12:47, Paul Bourke wrote: > Hi Darragh / git-upstream community, My current understanding is we have a branch, that consists of a mixture > of upstream commits from previous imports, and custom commits. We want > to show a list of commits added since the last import. However, if those > commits also contain commits from another non upstream branch, we want > to exclude those? This makes sense with the example of say a packaging > branch, but what if commits came from say a feature branch? Does it also > make sense to ignore those? Probably worth explaining additional branches a bit more in the docs (where did I say that before?) For any feature branch that is contributing to the tree and touching the same files as the upstream project, definitely they should be included, and git will do so by default. The packaging branch item stems from when we were carrying packaging related files that would never go upstream, and were actually from a completely separate history with it's own root, and own upstream as we did have some previously tracking ubuntu packaging repos to pull in the packaging files from there. However I think can regard the additional branches as just being an edge case that if they get excluded from the listed output, it's not the worst case. If it makes sense down the road to include them, or just ensure something is included about them, hopefully I'll have had a chat with some more git experts and might know how to do so. A quick off the top of my head guess. Given the graph mentioned in the other email: A / \ -M---X---N---O local/mitaka / / / X'---(rebase/cherry-pick of X onto G) / / -E---F---G upstream stable/mitaka branch Adding '--not M..N^1' might do the right thing in only excluding a range rather than everything behind it, though would need to check with a scenario that if another commit existed between X and N, that this wouldn't accidentally exclude A as well. > Thanks in advance for anything that might help cut through some of the > confusion. > > Cheers, > -Paul In any case, I think don't worry about the additional branches for now, just let them be excluded, as they way they are merged in only works if they are unrelated history. Since any feature branches wouldn't be merged in this way, they would get included the same way any other commit that is merged to the tree currently does, just that there will be more of them listed. -- Regards, Darragh Bailey IRC: electrofelix "Nothing is foolproof to a sufficiently talented fool" - Unknown signature.asc Description: OpenPGP digital signature __ 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] [git-upstream] How to view only commits applied since last import
t this. Locally in the same scenario, > taking the parent of the commit marked that subject and plugging it into > the command is not showing the same graph as you pasted. Think two questions are being asked; 1) how did I know which commit was the previous import 2) how does git-upstream identify such commits Short answer to the first part; because the test scenario was written to have "I" represent a previous import merge commit. The test case referenced in the review is simulating a particular history layout to exercise git-upstream replaying changes when one of them is based on a commit from before the most recent import merge commit. It was looking that that problem that revealed some of the behaviour of git log's history simplification. The test scenario is described by a yaml list in git_upstream/tests/searchers/scenarios/changes_upload_prior_to_import.yaml see: https://github.com/openstack/git-upstream/blob/a52f01f89401e79db95ad9fee9195de90e5a71f2/git_upstream/tests/searchers/scenarios/changes_upload_prior_to_import.yaml This is combined with some code in git_upstream/tests/base.py see the following for the code involved in taking the list and generated a git repository from it: https://github.com/openstack/git-upstream/blob/a52f01f89401e79db95ad9fee9195de90e5a71f2/git_upstream/tests/base.py#L196-L319 https://github.com/openstack/git-upstream/blob/a52f01f89401e79db95ad9fee9195de90e5a71f2/git_upstream/tests/base.py#L49-L92 Within the tree definition, there is an entry "[I, [E, =E1]]", which means: 1) Create a merge commit "I" with parents "E" and "E1", merged in that order 2) The "=" symbol means that the resulting tree contents of the merge commit "I" should be exactly the same as "E1" instead of a combination of "E" and "E1" The code in git_upstream/tests/base.py has an algorithm that understands how to workout the root commits of such graphs (no parents), and will create the commits only after any required parents exist. I won't go into detail on it here, you can look at the referenced urls above to see what it does. So this answers, when I was discussing the scenario how I knew that "[I] Merging E1 into E" identified the previous import. I noticed that I forgot to give a directly link to that file in the review, or even include the ascii representation when discussing, oops! However, I think you're also possibly asking, how does git-upstream identify that "I" was the previous import? The answer to that lies in the idea of TREESAME and !TREESAME. If git-upstream encounters a merge commit, and one of the parents is the exact same tree SHA1 (so exactly the same contents and file/directory metadata) as the merge commit itself, then it assumes that the parent commit that is TREESAME was a previous import, and the commit that had a different contents that were discarded was the previous history. There's a little bit more to it than that, since it has to cover some edge cases seen as well. The code for this is at: https://github.com/openstack/git-upstream/blob/a52f01f89401e79db95ad9fee9195de90e5a71f2/git_upstream/lib/searchers.py#L69-L249 Specifically the code that identifies the previous import is: https://github.com/openstack/git-upstream/blob/a52f01f89401e79db95ad9fee9195de90e5a71f2/git_upstream/lib/searchers.py#L153-L179 Taking another look at it, I think moving that second block out to a separate method would make it easier to complete the 'carrying' command by allowing you to simply call it to do the heavy work of identifying the previous import merge commit. > Thanks in advance for anything that might help cut through some of the > confusion. > > Cheers, > -Paul > Sorry that ended up being a bit wordy, hope it helps explain things a bit better, and hope you can help be get some of those points into the docs for a useful reference in the future :D -- Regards, Darragh Bailey IRC: electrofelix "Nothing is foolproof to a sufficiently talented fool" - Unknown signature.asc Description: OpenPGP digital signature __ 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] [release] git-upstream 0.12.1 release
Pleased to announce the 0.12.1 release of git-upstream. Main reason to ensure the man page is installed by default. With source available at: http://git.openstack.org/cgit/openstack/git-upstream Please report any issues through launchpad: https://bugs.launchpad.net/git-upstream git-upstream is an open source Python application that can be used to keep in sync with upstream open source projects, mainly OpenStack. For more info on what git-upstream is for: https://pypi.python.org/pypi/git-upstream Full changelog available from: https://git.openstack.org/cgit/openstack/git-upstream/tree/ChangeLog For more details see below. Changes in git-upstream 0.12.0..0.12.1 -- bbf2511 Update ChangeLog for 0.12.1 98b283e Include files for sphinx based documentation b95b257 Auto build and install default man page ac76015 Move build_manpage utility to doc area bc9fc64 Ensure correct prog name available to manpage d2c0306 Update authors 2455b7e Remove requirement sphinxcontrib-programoutput Diffstat (except docs and test files) - AUTHORS| 5 + ChangeLog | 12 +++ build_manpage.py | 136 - doc/source/conf.py | 246 + doc/source/index.rst | 21 doc/utils/build_manpage.py | 151 docs-requirements.txt | 2 + git_upstream/main.py | 3 +- setup.cfg | 10 ++ setup.py | 5 + test-requirements.txt | 1 - tox.ini| 4 +- 12 files changed, 457 insertions(+), 139 deletions(-) Requirements updates diff --git a/test-requirements.txt b/test-requirements.txt index 63c4a34..3f35ec1 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -9,5 +9,4 @@ python-subunit testrepository>=0.0.17 testscenarios>=0.4 testtools>=0.9.32 -sphinxcontrib-programoutput PyYAML>=3.1.0 -- Regards, Darragh Bailey IRC: electrofelix "Nothing is foolproof to a sufficiently talented fool" - Unknown (possibly Douglas Adams) 0xCDD2EB9C.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature __ 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] [release] git-upstream 0.12.0 release
gt;=0.3.2.RC1,!=0.3.2 +GitPython>=1.0.1 # BSD License (3 clause) +# pbr 1.6 or newer required by openstack global-requirements +# >= 1.0.0 should be sufficient for compatibility +pbr>=1.6 # Apache-2.0 +six>=1.9.0 # MIT diff --git a/test-requirements.txt b/test-requirements.txt index 6db383b..63c4a34 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -1,8 +1,9 @@ -hacking>=0.9,<=0.10.0 +hacking>=0.11.0,<0.12 # Apache-2.0 loremipsum mock!=1.1.1,<=1.3.0 Sphinx>=1.1.2,<1.2 discover +coverage>=3.6 # Apache-2.0 fixtures>=0.3.14 python-subunit testrepository>=0.0.17 -- Regards, Darragh Bailey IRC: electrofelix "Nothing is foolproof to a sufficiently talented fool" - Unknown (probably Douglas Adams) 0xCDD2EB9C.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature __ 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
