I like the programs idea and the direction this thread is going.
As we reconsider the relationship of repos and programs to the OpenStack
project, I think we should include one more aspect of taxonomy.
We have several orgs on github related to openstack:
openstack/
openstack-infra/
opensta
Thierry Carrez writes:
> James E. Blair wrote:
>> I propose that in the future, we adopt the following strategy:
>>
>> * Any repo associated with an official OpenStack program is entitled to
>>use the openstack org.
>> * Programs may request an org for
Hi,
On Saturday July 6th at 1600 UTC, Gerrit will be offline for a short
time while we rename the source code repositories of quantum and
python-quantumclient to neutron and python-neutronclient. To convert
that time to your local timezone, see:
http://www.timeanddate.com/worldclock/fixedtime.
Hi,
There are some changes to Zuul's behavior that will be arriving
beginning this Friday, July 19th. Here's what you need to know:
* Zuul will be more aggressive at dequeuing changes in the gate
pipeline when there are merge conflicts.
* Zuul will prioritize jobs for the gate pipeline ahead
Hi,
Jenkins Job Builder project (part of the Infrastructure program) has
proven to be quite popular!
There are a number of folks who contribute valuable reviews to the
project, and among those, four in particular have stood out recently.
Therefore, I'd like to spin off a new core team to manage
Hi,
Anthony Dodd has recently implemented some cool new features that we
discussed at the summit -- driving more automation from commit messages.
Here's what you need to know to use the new features:
Use header style references when referencing a bug in your commit
log. The following styles are n
Sean Dague writes:
> On 08/04/2013 12:09 PM, Thierry Carrez wrote:
>> Nachi Ueno wrote:
>>> It looks like neutron gating error improves as much as non-neutron gating
>>> one,
>>> so I would like to suggest to enable neturon-gating again.
>>
>> +1
>
> If those numbers are still valid as of today,
Monty Taylor writes:
> Hi!
>
> Currently, we make motions by email, then we discuss them by mailing
> list, then we discuss them more in IRC, then we vote on them - at which
> point the actual thing voted on may or may not get recorded somewhere
> easy to find.
>
> What if instead we had a repo w
Thierry Carrez writes:
> Monty Taylor wrote:
>> What if instead we had a repo with a bunch of ReStructureText in it -
>> perhaps a copy of the TC charter and then a dir for additional things
>> the TC has decided. That repo would be autopublished to a non-wiki
>> website ... and the core team for
Roman Gorodeckij writes:
> Hi,
>
> I just completely messed up in here.
>
> Was reading a manual about Gerrit workflow:
> https://wiki.openstack.org/wiki/Gerrit_Workflow#Committing_Changes
> And then there's link to here about how to build commit messages:
> https://wiki.openstack.org/wiki/Git
Jeremy Stanley writes:
> On 2013-08-07 09:35:33 +0200 (+0200), Flavio Percoco wrote:
> [...]
>> Would it make sense to have a copy of the votes at the end of that RST
>> file (or somewhere in that commit) ? This will replicate vote results
>> to our repo instead of just keeping them in Gerrit - i
Monty Taylor writes:
> The infra team has done a lot of work in prep for our favorite time of
> year, and we've actually landed several upgrades to the gate without
> which we'd be in particularly bad shape right now. (I'll let Jim write
> about some of them later when he's not battling the curre
Michael Still writes:
> On Sat, Aug 24, 2013 at 4:20 AM, Elizabeth Krumbach Joseph
> wrote:
>> Hi everyone,
>>
>> Several months ago the OpenStack Infrastructure team filed a bug to
>> "Create a git.openstack.org mirror system"[0]
>
> Does git.openstack.org replace git hub for developers cloning
Matthew Treinish writes:
> This should improve the run times for tempest jobs to between 20-30min
> on average which will definitely help with the upcoming milestone
> rush.
This is great! Thanks to you and the Tempest team for getting this
_huge_ effort done! I'm really excited that we're abl
ZhiQiang Fan writes:
> currently, i don't know if it is coverage problem or something else.
>
> the direct cause is:
>
> sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post
>
> Sep 9 06:57:23 precise1 sudo: jenkins : 3 incorrect password
> attempts ; TTY=unknown ;
> PWD=/home/jenkin
Hi,
I'm pleased to announce the availability of a new micro-library named
requestsexceptions. Now the task of convincing the requests library
not to fill up your filesystem with warnings about SSL requests has
never been easier!
Over in infra-land, we use the requests library a lot, whether it's
Khai Do and I attended the Gerrit User Summit this weekend. It was a
very busy weekend indeed with quite a lot of activity in all areas
related to Gerrit. The following is a brief summary of items which
may be of interest to our community.
--==--
David Pursehouse from Sony Mobile spoke about wh
Aleksandra Fedorova writes:
> Hi, everyone,
>
>
>
> in Fuel project we run two HA deployment tests for every commit in
> openstack/fuel-library repository. Currently these tests are run by
> Fuel CI - the standalone Third-Party CI system, which can vote on
> openstack/fuel* projects. But we'd li
Sean Dague writes:
> Has anyone considered using #openstack-dev, instead of a new meeting
> room? #openstack-dev is mostly a ghost town at this point, and deciding
> that instead it would be the dedicated cross project space, including
> meetings support, might be interesting.
I agree it might b
Sean Dague writes:
> Given that it's on track for getting accepted upstream, it's probably
> something we could cherry pick into our deploy, as it won't be a
> divergence issue.
Once it merges upstream, yes.
-Jim
__
OpenSt
Since its inception, the OpenStack project has used Jenkins to perform
its testing and artifact building. When OpenStack was two git repos,
we had one Jenkins master, a few slaves, and we configured all of our
jobs manually in the web interface. It was easy for a new project
like OpenStack to set
Now that we have retired Jenkins, we have some upcoming changes:
* Console logs are now available via TCP
The status page now has "telnet" protocol links to running jobs. If
you connect to the host and port specified in that link, you will be
sent the console log for that job up to that po
Kashyap Chamarthy writes:
> If it reduces nondeterministic spam for the CI Infra, and makes us
> achieve the task at hand, sure. [/me need to educate himself a
> bit more on the Zuul pipeline infrastructure.]
>
> Worth filing this (and your 'idle pipeline' thought below) in the Zuul
> tracker he
Sean Dague writes:
> Bummer. This gets used a to figure out the state of things given that
> zuul links to the console even after the job is complete. Changing that
> to the log server link would mitigate the blind spot.
Yeah, we know it's important, which is why we're working on getting it
back
Sean Dague writes:
> On 04/18/2016 11:22 AM, James E. Blair wrote:
>> Sean Dague writes:
>>
>>> Bummer. This gets used a to figure out the state of things given that
>>> zuul links to the console even after the job is complete. Changing that
>>> to th
Sean Dague writes:
> Yes, that would let you see the results of an individual experimental
> run that is complete before they all return and post to the change. Once
> they are all done, they are listed on the change, so that's good enough.
We'll need a Zuul restart for this, so it may take anot
Announcing Gertty 1.3.0
===
Gertty is a console-based interface to the Gerrit Code Review system.
Gertty is designed to support a workflow similar to reading network
news or mail. It syncs information from Gerrit to local storage to
support disconnected operation and easy man
Michał Dulko writes:
> As this was sent to openstack-dev list, I'll ask a Gertty usage question
> here. Was anyone able to use Gertty successfully behind a proxy? My
> environment doesn't allow any traffic outside the proxy and I haven't
> noticed a config option to set it up.
Gertty uses the py
Hi,
I'm pleased to announce a new and very simple tool to help with managing
large patch series with our Gerrit workflow.
In our workflow we often find it necessary to create a series of
dependent changes in order to make a larger change in manageable chunks,
or because we have a series of relate
Paul Michali writes:
> Sounds interesting... the link
> https://docs.openstack.org/infra/git-restack/ referenced
> as the home page in PyPI is a broken link.
I'm clearly getting ahead of things. The correct link is:
http://docs.openstack.org/infra/git-restack/
Thanks,
Jim
___
"Elizabeth K. Joseph" writes:
> Hi everyone,
>
> The OpenStack Infrastructure (Infra) team is having our next weekly
> meeting on Tuesday July 28th, at 19:00 UTC in #openstack-meeting
>
> Meeting agenda available here:
> https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
> welco
Hi,
The TC has recently been considering what the big tent means for
Stackforge. In short, very little will be changing, except that we will
now start putting projects previously destined for stackforge/ in the
openstack/ git namespace.
The big tent is a recognition that there are a lot of proje
Hi,
As mentioned previously[1], we are retiring the stackforge/ namespace
for git repositories and creating new projects in openstack/. This is
largely a cosmetic change and does not change the governance model for
new projects.
As part of this we want to move all of the projects that are curren
"Fox, Kevin M" writes:
> What is the process for current stackforge projects to move into the
> openstack namespace then? Is it a simple request now, or a more
> complicated process?
Great question. I have proposed a process for that in a new thread:
http://lists.openstack.org/pipermail/openst
On Friday, September 11 at 23:00 UTC Gerrit will be unavailable for
about 30 minutes while we rename some projects.
Existing reviews, project watches, etc, should all be carried
over. Currently, we plan on renaming the following projects:
stackforge/os-ansible-deployment -> openstack/openstack-
Hi,
In a previous message[1] I described a plan for moving projects in the
stackforge/ git namespace into openstack/.
We have scheduled this migration for Saturday October 17, 2015.
If you are responsible for a stackforge project, please visit the
following wiki page as soon as possible and add
Hi,
I've been the Infrastructure PTL for some time now and I've been
fortunate to serve during a time when we have not only grown the
OpenStack project to a scale that we only hoped we would attain, but
also we have grown the Infrastructure project itself into truly
uncharted territory.
Serving a
cor...@inaugust.com (James E. Blair) writes:
> On Friday, September 11 at 23:00 UTC Gerrit will be unavailable for
> about 30 minutes while we rename some projects.
>
> Existing reviews, project watches, etc, should all be carried
> over.
This has been completed without incident
Thierry Carrez writes:
> Doug Hellmann wrote:
>> [...]
>> 1. Resolve the situation preventing the DefCore committee from
>>including image upload capabilities in the tests used for trademark
>>and interoperability validation.
>>
>> 2. Follow through on the original commitment of the proj
Hi,
Recently we noted some projects modifying the ERROR_ON_CLONE environment
variable in devstack gate jobs. It is never acceptable to do that. It
is also not acceptable to read its value and alter a program's behavior.
Devstack is used by developers and users to set up a simple OpenStack
envir
Michael Krotscheck writes:
> I am resigning, effective immediately, as StoryBoard Core, and will no
> longer contribute to the project.
Thank you for your work on Storyboard and I look forward to working with
you as you share your expertise with other parts of the OpenStack
project.
-Jim
_
Hi,
This came up at the TC meeting today, and I volunteered to provide an
update from the discussion.
In general, I think there is a lot of support for a packaging effort in
OpenStack. The discussion here has been great; we need to answer a few
questions, get some decisions written down, and mak
Evgeny Antyshev writes:
> Some CIs like to narrow their scope to a certain set of files.
> For that, they specify file mask on per-job basis. So there appear
> annoying comments with only "Build succeeded".
> (an example complaint:
> http://lists.openstack.org/pipermail/openstack-dev/2015-June/06
On Friday, June 12 at 22:00 UTC Gerrit will be unavailable for about 30
minutes while we rename some projects.
Existing reviews, project watches, etc, should all be carried
over. Currently, we plan on renaming the following projects:
stackforge/mistral -> openstack/mistral
stackforge/iron
Announcing Gertty 1.2.0
===
Gertty is a console-based interface to the Gerrit Code Review system.
Gertty is designed to support a workflow similar to reading network
news or mail. It syncs information from Gerrit to local storage to
support disconnected operation and easy man
Emilien Macchi writes:
> On my side, I can take care of 1/ make sure the repo is on Stackforge
> (for start, then it will move under OpenStack namespace once done) 2/
> help in unit/functional testing (rspec, beaker).
If the PuppetOpenStack project will be adopting this, then we can just
go ahea
The Infrastructure program has a unique three-tier team structure:
contributors (that's all of us!), core members (people with +2 ability
on infra projects in Gerrit) and root members (people with
administrative access). Read all about it here:
http://docs.openstack.org/infra/system-config/proj
Hi,
I'd like to apologize to all of the people who worked hard on
researching and proposing names for the M release that did not appear in
the poll.
When we worked on the new method for choosing a name, we did so with the
idea that the entire process should be public and that the community is
equ
Hi all,
I'm glad that by asking the ironic-dashboard creators to propose their
project to ironic initially (rather than stackforge) we have prompted
this conversation. We now know that two independent groups of people
have created standalone ironic dashboards, neither of which is currently
part o
Jim Rollenhagen writes:
> As a note, the asterisk setup that Infra provided was *fantastic*, and
> the virtual-ness of this midcycle is going better than I ever expected.
> Thanks again to the infra team for all that you do for us. <3
That's great to hear!
I'm looking forward to hearing what wo
Monty Taylor writes:
> I do not like how we are selecting names for our releases right now.
> The current process is autocratic and opaque and not fun - which is the
> exact opposite of what a community selected name should be.
>
> I propose:
>
> * As soon as development starts on release X, we o
Lauren Sell writes:
> Hey Monty,
>
> I’d like to weigh in here, because I think there have been some
> misunderstandings around Lemming-gate. I’m glad you raised your
> concerns; it’s a good test of release naming for us all to discuss and
> learn from.
>
> To provide a little context for those n
Thierry Carrez writes:
> Monty Taylor wrote:
>> You'll notice that I did say in my suggestion that ANYONE should be able
>> to propose a name - I believe that would include non-dev people. Since
>> the people in question are marketing people, I would imagine that if any
>> of them feel strongly a
Hi,
On Friday, January 30 at 19:00 UTC Gerrit will be unavailable for about
30 minutes while we rename some projects. Existing reviews, project
watches, etc, should all be carried over. Currently, we plan on
renaming the following projects (this list is subject to change):
openstack/oslo.ve
Hi,
The Infrastructure program has a unique three-tier team structure:
contributors (that's all of us!), core members (people with +2 ability
on infra projects in Gerrit) and root members (people with
administrative access). Read all about it here:
http://ci.openstack.org/project.html#team
El
Hi,
As part of an effort to better support re-use of the Infrastructure
program's software, tooling, and systems-administration work, we have
moved all of our puppet modules out of the system-config repository.
Now each of them may be found in its own git repo, such as
openstack-infra/puppet-zuul
"Kevin L. Mitchell" writes:
> On Fri, 2015-01-30 at 22:33 +, Everett Toews wrote:
>> It was suggested that the API WG use the openstack-specs [1] and/or
>> the api-wg [2] repo to publish its guidelines. We’ve already arrived
>> at the consensus that we should only use 1 repo [3]. So the purpo
Sean Dague writes:
> On 01/31/2015 05:24 AM, Duncan Thomas wrote:
>> What I would rather not see is leakage of information when something
>> internal to the cloud goes wrong, that the tenant can do nothing
>> against. We certainly shouldn't be leaking internal implementation
>> details like vendo
Thierry Carrez writes:
> You make a good point when you mention "traditional distro" here. I
> would argue that containers are slightly changing the rules of the
> don't-run-as-root game.
>
> Solution (2) aligns pretty well with container-powered OpenStack
> deployments -- running compute nodes a
Thierry Carrez writes:
> I also disagree with the proposed solution. We announced a support
> timeframe for Icehouse, our downstream users made plans around it, so we
> should stick to it as much as we can.
To be fair, if we did that, we did not communicate accurately the
sentiment of the room a
cor...@inaugust.com (James E. Blair) writes:
> Hi,
>
> The Infrastructure program has a unique three-tier team structure:
> contributors (that's all of us!), core members (people with +2 ability
> on infra projects in Gerrit) and root members (people with
> administrative a
Hi,
We have added support for cross-repo dependencies (CRD) in Zuul. The
important bits:
* To use them, include "Depends-On: " in the footer of
your commit message. Use the full Change-ID ('I' + 40 characters).
* These are one-way dependencies only -- do not create a cycle.
* This is what a
Amrith Kumar writes:
> This is awesome news!
>
> If I understand correctly, your description of "multiple changes"
> describes cases where a single change depends on multiple changes. My
> question is related to one-to-one dependencies in the form A -> B ->
> C.
>
> I'm assuming that this is supp
"Sullivan, Jon Paul" writes:
>> A change may depend on more than one Gerrit change ID as well. So it is
>> possible for a change in tempest to depend on a change in devstack and a
>> change in nova. Simply add more "Depends-On:" lines to the footer.
>
> Have you considered a case where changes
sean roberts writes:
> At our last meeting I volunteered to figure out what we need to do for
> milestone 2. Here is what I propose:
>
> Repo cleanup:
> We tag today's release with 2015.1.0b2. This is copying tag the other
> openstack projects are using. I believe below is the correct syntax. Let
Thierry Carrez writes:
> So what is it we actually want for that repository ? In a world where
> Gerrit can do anything, what would you like to have ?
>
> Personally, I want our technical community in general, and our PTLs/CPLs
> in particular, to be able to record their opinion on the proposed
>
Thierry Carrez writes:
>> Current Cross-Project Repo Rules
>>
...
>> * Only the TC chair may vote Workflow +1.
>
> My understanding is that currently, any TC member can Workflow+1 (which
> lead to the accidental approval of the previous spec).
I think that was in
"Kuvaja, Erno" writes:
> Hi all,
>
> We have almost year old (from last update) reviews still in the queue
> for glance. The discussion was initiated on yesterday's meeting for
> adopting abandon policy for stale changes.
Hi,
Abandoning changes submitted by other people is not a good experience
Anita Kuno writes:
> I'd like to make sure that if Infra is saying that CI jobs on drivers
> can gate that this is a substantial difference from what I have been
> saying for a year, specifically that they can't and won't.
For the purposes of this conversation, the distinction between drivers
an
A group of folks from HP is interested in starting an effort to run a
cloud as part of the Infrastructure program with the purpose of
providing resources to nodepool for OpenStack testing. HP is supplying
two racks of machines, and we will operate each as an independent cloud.
I think this is a re
Stefano Maffulli writes:
> On Thu, 2015-02-26 at 15:58 -0600, Kevin L. Mitchell wrote:
>> One thing that comes to mind is that there are a lot of reviews that
>> appear to have been abandoned; I just cleared several from the
>> novaclient review queue (or commented on them to see if they were sti
Stefano Maffulli writes:
> In any case, since Sean said that nova (and other projects) already
> remove unmergeable changesets regularly, I think the data are already
> "clean enough" to give us food for thoughts.
I am asking you to please independently remove changes that you don't
think should
John Griffith writes:
> For what it's worth, at one point the Cinder project setup an auto-abandon
> job that did purge items that had a negative mark either from a reviewer or
> from Jenkins and had not been updated in over two weeks. This had
> absolutely nothing to do with metrics or statisti
Duncan Thomas writes:
> Why do you say auto-abandon is the wrong tool? I've no problem with the 1
> week warning if somebody wants to implement it - I can see the value. A
> change-set that has been ignored for X weeks is pretty much the dictionary
> definition of abandoned, and restoring it is o
Doug Wiegley writes:
> A default query that edited out old, jenkins failing, and -2 stuff
> would be helpful. A default or easy query that highlighted things
> relevant to the current milestone's blueprints and bugs would be SUPER
> useful to guiding folks towards the most useful reviews to be d
Stefano branched this thread from an older one to talk about
auto-abandon. In the previous thread, I believe I explained my
concerns, but since the topic split, perhaps it would be good to
summarize why this is an issue.
1) A core reviewer forcefully abandoning a change contributed by someone
els
Sean Dague writes:
> Right, I think this is the 'procedural -2' case, which feels like we
> need another state for things that are being held for procedural
> reasons, which is unrelated to normal code-review.
We have been looking into that and believe we may be able to do
something like that in
John Griffith writes:
> Should we just rename this thread to "Sensitivity training for
> contributors"?
I do not think that only new contributors might feel it is negative. I
think that both some new and long-time contributors do.
My oldest patch is from July -- it's still relevant, just not
Hi,
Also, in either Gerrit's web UI or Gertty, there is an option for
displaying unified diffs, rather than side-by-side (it's a link on the
change page in Gerrit, and a config file option in Gertty). I do not
know if that would be helpful, but would be happy to learn.
Thanks,
Jim
Announcing Gertty 1.1.0
===
Gertty is a console-based interface to the Gerrit Code Review system.
Gertty is designed to support a workflow similar to reading network
news or mail. It syncs information from Gerrit to local storage to
support disconnected operation and easy man
Russell Bryant writes:
> Part of the change is to recognize more projects as being part of the
> OpenStack community. Another critical part was replacing the integrated
> release with a set of tags. A project would be given a tag if it meets
> some defined set of criteria.
...
> I can't think o
Joe Gordon writes:
> After watching the TC meeting, and double checking with the meeting notes
> [0], it looks like the magnum vote was deferred to next week. But what
> concerns me is the lack of action items assigned that will help make sure
> next weeks discussion isn't just a repeat of what h
Hi,
Gerrit will be unavailable for a few hours starting at 1500 UTC on
Saturday, March 21.
Also, as Jeremy indicated in this email, its IP address will be changing:
http://lists.openstack.org/pipermail/openstack-infra/2015-February/002425.html
If you use Gerrit from a network with egress filt
cor...@inaugust.com (James E. Blair) writes:
> Hi,
>
> Gerrit will be unavailable for a few hours starting at 1500 UTC on
> Saturday, March 21.
Gerrit is up and running on the new server. Actual downtime was about 1
hour from 1500 to 1600.
Please let us know either here or on
Chmouel Boudjnah writes:
> On Thu, Mar 26, 2015 at 12:22 AM, Monty Taylor wrote:
>
>> git review is used by a ton of people who write in non-python. I think
>> adding openstack-specific style enforcement to it would make it way less
>> generally useful.
>>
>
>
> I think if we wanted to do that w
I would like to announce my candidacy for the Infrastructure PTL.
I have developed and operated the project infrastructure for several
years and have been honored to serve as the PTL for the Kilo cycle.
I was instrumental not only in creating the project gating system and
development process, but
On Friday, April 17 at 22:00 UTC Gerrit will be unavailable for about 2
hours while we rename some projects and perform some database
maintenance.
Existing reviews, project watches, etc, should all be carried
over. Currently, we plan on renaming the following projects:
stackforge/murano
On Saturday, May 9 at 16:00 UTC Gerrit will be unavailable for about 4
hours while we upgrade to the latest release of Gerrit: version 2.10.
We are currently running Gerrit 2.8 so this is an upgrade across two
major releases of Gerrit. The release notes for both versions are here:
https://ger
Hi,
I'd like to announce my candidacy for re-election to the TC.
About Me
I am the PTL for the OpenStack Infrastructure Program, which I have
been helping to build for nearly four years. I have also served on
the TC since the Icehouse cycle.
I am responsible for a significant portion
cor...@inaugust.com (James E. Blair) writes:
> On Saturday, May 9 at 16:00 UTC Gerrit will be unavailable for about 4
> hours while we upgrade to the latest release of Gerrit: version 2.10.
>
> We are currently running Gerrit 2.8 so this is an upgrade across two
> major releases
Jeremy Stanley writes:
> On 2015-05-11 11:02:17 -0500 (-0500), Kevin L. Mitchell wrote:
>> As a point of information, I logged in to review a python-novaclient
>> review, and now I find I can't load any nova reviews at all; I get a
>> page with the top bar, but below that is a "Toggle CI" button
Robert Collins writes:
> tl;dr:
> - NEVER clone from git.openstack.org during CI. Use the local cache.
> - ALWAYS use the ZUUL_REF
> (http://ci.openstack.org/zuul/launchers.html#common-parameters) when
> using git sources, so that you test what zuul expects to be tested.
Better yet, always use
"bogda...@mail.ru" writes:
> That's great news! In-repo configs will speed up development for teams,
> with a security caveat for infrastructure team to keep in mind. The
> ansible runner CI node which runs playbooks for defined jobs, should not
> content sensitive information, like keys and secr
"bogda...@mail.ru" writes:
> The mail-man for the openstack-dev mail list is missing at least 'kolla'
> and 'development' checkboxes. It would be nice to make its filter case
> unsensitive as well, so it would match both 'All' and 'all' tags. How
> could we fix that? Any place to submit a PR?
Un
Telles Nobrega writes:
> Hello,
>
> we from Sahara use the compatibility layer with Zuulv2.5 and we are
> wondering if with the change to Zuulv3 this compatibility layer will still
> be maintained.
> If the layer is removed it will reflect into some changes on our side and
> we are looking for th
Hi,
In working on the implementation of the encrypted secrets feature of
Zuul v3, I have found some things that warrant further discussion. It's
important to be deliberate about this and I welcome any feedback.
For reference, here is the relevant portion of the Zuul v3 spec:
http://specs.openst
Clint Byrum writes:
> Excerpts from Matthieu Huin's message of 2017-03-21 18:43:49 +0100:
>> Hello James,
>>
>> Thanks for opening the discussion on this topic. I'd like to mention that a
>> very common type of secrets that are used in Continuous Deployments
>> scenarios are SSH keys. Correct me
David Moreau Simard writes:
> I don't have a horse in this race or a strong opinion on the topic, in
> fact I'm admittedly not very knowledgeable when it comes to low-level
> encryption things.
>
> However, I did have a question, even if just to generate discussion.
> Did we ever consider simply
Ian Cordasco writes:
> On Tue, Mar 21, 2017 at 6:10 PM, James E. Blair wrote:
>> We did talk about some other options, though unfortunately it doesn't
>> look like a lot of that made it into the spec reviews. Among them, it's
>> probably worth noting that th
Darragh Bailey writes:
> On 22 March 2017 at 15:02, James E. Blair wrote:
>
>> Ian Cordasco writes:
>>
>> >
>> > I suppose Barbican doesn't meet those requirements either, then, yes?
>>
>> Right -- we don't want to require ano
101 - 200 of 267 matches
Mail list logo
