ck.org/cgit/openstack-infra/bindep/tree/README.rst
be a better user experience than
http://docs.openstack.org/infra/bindep/readme.html ?
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage que
e the source code
browser configured for what it does best: browsing source code.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject
r unit tests locally.
[...]
Note that we've also got a fairly well-received addendum to the
Consistent Testing Guidelines which aligns nicely with this option:
https://review.openstack.org/397502
--
Jeremy Stanley
gt; whatever other external network you might connect to - necessarily being
> able to do the same.)
[...]
Probably just my knee jerking over what seems like yet another
gratuitously unnecessary use of NAT here, but why not simply use
packet filtering (and if necessary, additional virtual NICs)?
--
enty over the years and I think a lot of the easier
cases have already been fixed. Places where you'll have more trouble
are the ones like https://launchpad.net/bugs/1348339 (inherited from
Swift's use of MD5 for etags).
--
Jerem
ing. I won't reiterate the
reasons for avoiding Git submodules, but suggest reviewing the
meeting log:
http://eavesdrop.openstack.org/meetings/kolla/2016/kolla.2016-11-16-16.01.log.html#l-108
--
Jeremy Stanley
__
Ope
t once we migrate off Launchpad SSO we'll be able to begin
migrating toward more transparent authentication for the
applications we're hosting, so that users no longer have to click
through several pages to authenticate each Webapp, only to have it
expire again soon thereafter.
--
Jerem
begins to bog down (keep on the lookout for that).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.opensta
as me telling you what works best.
Just wanted to make sure nobody thought the wiki option precludes
having a history/audit log.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
oth
repos.
--
Jeremy Stanley
__
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
://governance.openstack.org/reference/licensing.html
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.o
repo has a dangerous-looking mix of Puppet
modules under Apache License v2.0 and GPLv2 licenses, so probably
not a shining example of how to go about this.
Hopefully that provides a diverse cross-section of examples.
--
Jeremy Stanley
signature.asc
Description: Digital
t
is guaranteed to happen and we cannot prevent that (nor would we
want to).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:u
r the Kolla devs deciding they don't want this file in the
same repo as Kolla, but if we're going to say that there are legal
reasons forcing their hand I'd like to see those reasons enumerated.
--
Jeremy Stanley
__
O
n/stable/reference/pip_install/#requirement-specifiers
https://www.python.org/dev/peps/pep-0426/#environment-markers
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
ion of other languages actually solves this either. If
anything, those camps will still most likely exist... just one of
them will be entirely outside the official reaches of our community
and so even more isolated and bitter.
--
Jeremy Stanley
signature.asc
Description: Digit
d them after the
import is successful and you've looked it over).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
In this case, etcd
tarballs might be something well suited to this, or you could
consider trying to use Ubuntu's etcd package (I'm unsure what you
have DevStack doing with etcd so it's hard to know if this is a
viable alternative for you).
--
Jeremy Stanley
_
community infrastructure eases experimentation and
promotes language-specific innovation for unofficial repositories
within our ecosystem.
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Developme
On 2016-11-06 14:59:03 + (+), Jeremy Stanley wrote:
> On 2016-11-06 08:05:51 + (+), Steven Dake (stdake) wrote:
[...]
> > An orthogonal question I have received from one of our community
> > members (Pavo on irc) is whether pycrypto (or if we move to
> > crypt
if you need, for example, a FIPS-compliant
AES implementation under the hood, then this is dependent more on
what backend libraries you're using... e.g.,
https://www.openssl.org/docs/fips.html
https://www.openssl.org/docs/fipsvalidation.html
--
Jeremy Stanley
ould just be up to the Kolla team to decide
whether they also find it acceptable or require some logical
separation there for other reasons.
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development
case ASL2.0 should be used).
[...]
Yep, thanks! I started questioning this interpretation too and found
counterexamples endorsed by Ansible so this does seem like a
relatively easy way out (see my other reply to myself just now).
--
Jeremy Stanley
signature.asc
Description: Digit
On 2016-11-04 22:50:10 + (+), Jeremy Stanley wrote:
[...]
> As I understand it, the challenge here is that plugins for Ansible
> will by definition be derivative works of Ansible and thus inherit
> their license choice. No amount of "clean room reimplementation"
>
cial OpenStack project team, then perhaps it
could just be distributed in an unofficial repo instead (though this
seems overly proscriptive to me).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage
hile shipped in
the same repo as Apache License 2.0 Kolla source code would simply
be aggregation of software under distinct licenses.
That said, it can't hurt to ask this again on
legal-disc...@lists.openstack.org where it's much more on-topic.
--
Jeremy Stanley
signature.asc
Description: Digit
pointed out the other thread on the
related topic of mass changes for cross-project efforts does address
the case specifically, but becomes less necessary if you end up
agreeing to drop the TrivialFix requirement.)
--
Je
of every
review team and individually adjust such mass changes myself, so
rely on you to "fix" my patches for me in such situations.
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack De
ht
situation you've raised gets sorted out:
http://eavesdrop.openstack.org/meetings/releaseteam/2016/releaseteam.2016-11-04-14.00.html
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development
s
in them aren't actually derivatives of something which had a Datadog
license, which would be unfortunate from a legal/copyright
standpoint. Ideally that LICENSE file is just wrong and can be
deleted/replaced, but someone from the Monasca team would need to
weigh in on whether that's the case.
-
as
added here in error, and we've not actually been shipping an
incorrectly-licensed derivative of their software this entire time?
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development Maili
On 2016-11-01 14:10:44 -0400 (-0400), Ben Swartzlander wrote:
> On 11/01/2016 12:03 PM, Jeremy Stanley wrote:
[...]
> > into it the kernel's process space. This is the closest analogue we
> > have to our drivers importing proprietary Python modules.
>
> I'm not talking about
because we're
already wandering into territory that's better handled on the
legal-discuss@ ML.
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsu
modules within drivers, and is also a suboptimal solution I
think we should discourage in favor of providing _actual_ free
drivers. I suppose it's worth a try, but I'm skeptical it will
significantly alter the dynamics of the situati
e community of being able to review the
> code and give some assurance that it is doing things correctly.
> And the only benefit really it gives the vendor is they have an
> out of tree driver that gets advertised as being in tree.
[...]
I expect we'd need to rej
se
(quite probably the latter, since bindep itself doesn't install
anything for you and only tells you what packages you're currently
lacking).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage ques
operates.
Thanks for wanting to get involved in OpenStack!
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists
On 2016-10-20 15:43:53 + (+), Jeremy Stanley wrote:
> Yes, the Infra team is digging into it and trying to decide on an
> optimal solution for this. We'll rerun the failed jobs once we have
> a fix in place, and let the Release team know. I'll also follow up
> on this thread
place, and let the Release team know. I'll also follow up
on this thread once that's done.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.opensta
ugh them faster and make them public sooner. Thanks for keeping
the wheels turning!
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
and has the property
that it's not overloading a typical field separator within either
8601 or HTTP encodings. (Now I've fulfilled my bikeshed quota for
the month.)
--
Jeremy Stanley
__
OpenStack Development Mailing List (no
it sounds like you may
have time and interest to help us get this supported properly (at
least for rpm-based platforms), so I'm thrilled and looking forward
to working with you toward that goal. Thanks again!
--
Jeremy Stanley
__
O
ing to his open question, so I'll
spare our gentle readers a rehashing of the same here.
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage que
dom concerns, for
example encouraging driver support in official projects to embody
the spirit of our license choice rather than merely the letter of
that license.
--
Jeremy Stanley
signature.asc
Description: Digital signature
___
mostly just end up attempting to map them to the candidates I knew
were running based on the opinions I know them to hold.
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (n
On 2016-10-03 16:11:25 + (+), Jeremy Stanley wrote:
[...]
> I think we can bring this thread to a close now. Upstream deleted
> the broken wheel from PyPI a little over an hour ago, and within
> about 5 minutes it disappeared from our CI system mirrors as well
> (PyPI deletio
through our mirroring). At
this point things _should_ be back to normal, and projects can
probably start working on reverting or abandoning any temporary
workarounds.
--
Jeremy Stanley
__
OpenStack Development Mailing List (no
t in the best
interests of industry pundits or vendor product roadmaps.
OpenStack is people. If we lose sight of that, it's over.
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development
penstack.org/#/q/project:openstack/governance+is:open
are remarkably effective to that end.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?s
On 2016-09-27 11:45:14 -0700 (-0700), Travis McPeak wrote:
> There is a private security bug about it right now too. No, not all XML
> libraries are immune now.
https://launchpad.net/bugs/1625402 which I've just now declassified.
--
Jeremy Stanley
signature.asc
Description: Digital sig
newton jobs will get "fixed" retroactively.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists
one project in the
projects.txt file of the requirements repo would be a good idea both
as a demonstration that it's a viable tool and also as a precaution
against its later removal due to lack of use.
--
Jeremy Stanley
__
Ope
roject
repos.
--
Jeremy Stanley
__
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
ated" projects before the big tent were semi-official, could
use the "openstack" Git namespace (back when we still restricted
it), could publish to docs.openstack.org, and so on.
--
Jeremy Stanley
__
OpenS
(unhelpfully) lists tags by their long
descriptions. Go ahead and click on the Details link next to the
Cross-project coordination topic and you'll see that's actually the
name for the [all] tag.
--
Jeremy Stanley
__
OpenStack
as likely
> inexperienced at some time in their life...)
Anyone who doesn't _still_ feel like they're inexperienced from time
to time isn't human. ;)
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
ocess for Leaderless
Programs" was passed, removal was basically their only accepted
option for dealing with teams that lacked a PTL. That resolution
gave them the _additional_ option of appointing a PTL volunteer.
[*]
http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-20-2
on't
regularly attend its weekly meetings nor participate in development
of any of its outputs beyond what intersects with VMT needs (though
also I'm not confident I could wear two PTL hats effectively, unlike
some superhumans in our community).
--
Jeremy Stanley
signature.asc
Descripti
index ID) refers to one specific commit in one repository.
If that same commit SHA appears in the history of another repository
(because it's a fork or something) then it won't have its own Gerrit
change number and so won't show up a second time.
--
Jeremy Stanley
__
possibility that something
can be treated as a vulnerability by the OpenStack community but
only fixed in some supported branches, that introduces a lot of
additional uncertainty for downstream consumers of our advisory
process and the associated patches tracked by it.
--
Jeremy Stanley
sig
ast worst option.
[...]
At least from my perspective with my VMT hat on, declaring that we
have a security vulnerability severe enough to fix in stable/mitaka
but unfixable in stable/liberty calls into question whether the
latter is actually maintainable by our general definition as a
project or is r
on't
believe that has ever actually happened and so isn't something I
would worry about.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.o
circle_usecase1.png
>
> then exception encountered, and not able to upload any pictures
[...]
Sorry about that, the Cinder device where it stores images had a
communication issue and needed to be checked and remounted. It
should be working now if you want to try agai
sounds great to me!
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
interface boundary.
--
Jeremy Stanley
__
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
eption being election for Stable Branch Maintenance PTL, where we
count changes merged to stable/.* branches of all official projects).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
lly useful to our community, then
feel free to put it there. If you want that software to be an
official part of OpenStack, talk to the TC.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage ques
someone else if you want to. A bit
> > like keeping a headphone jack. Options.
> >
> I see what you did there (and I like it).
An act of true courage if I've ever seen one. ;)
--
Jeremy Stanley
__
OpenStack Developmen
r organizations who cannot help but succumb to greed and a
lack of empathy for positive work being done by the rest of us.
Taking a stance that we can't trust contributions from some parts of
our community reinforces an idea that we're still willing to accept
them.
ser checked it got
presented a captcha but saw no captcha after checking verified in
the account permissions. Hopefully this makes things more convenient
for everyone.
--
Jeremy Stanley
__
OpenStack Development Mailing L
hat
users whose previous edits have been confirmed by a wiki admin are
added to a group that bypasses the captcha, and then get a team of
wiki groomers in the habit of adding known good accounts to that
group).
--
Jeremy Stanley
_
are
also be distributed under an OSI-approved or similar license and I
doubt I'm alone in that, yet I also recognize that goal may take a
significant amount of time and effort for us to reach.
--
Jeremy Stanley
__
OpenStac
o download and install separate
proprietary tools from the hardware vendor. It's not what we say
today, but it's what I personally feel like we *should* be saying.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not f
ronous release cadence, and that
suggestion would unnecessarily tie their governance even more
strongly to the schedules of the minority who do.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage que
to have everyone's input on it.
>
> Doug
>
> [1]
> http://governance.openstack.org/reference/projects/release-management.html#release-tools
Oh--indeed! I missed that it was the only project in the
openstack-infra namespace belonging to an official team oth
epos
> have already demonstrated a good attention to detail, especially
> of the release schedule and processes.
[...]
Sounds great to me. As PTL over the openstack-infra/release-tools
repo, I don't object.
--
Jeremy Stanley
___
trol from where the old documentation source could be exhumed)?
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:u
rovider is running. Likewise, my application/library need not
figure out what release of Neutron is in use to be able to interact
with its API, it should only need to know the reported API version.
The most complete picture of the Neutron API will, in theory, be
reflected in the API documentation in the
ph of context,
which started out:
> > Make the oslo libraries Nova and Neutron are using better. Work
> > with the Nova and Neutron teams on a consolidated approach.
[...]
I don't read that at all as sugge
On 2016-08-31 18:58:31 + (+), Jeremy Stanley wrote:
> On 2016-08-31 17:59:43 +0100 (+0100), Matthew Booth wrote:
> > On Wed, Aug 31, 2016 at 5:31 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:
> [...]
> > > Also we have naming conventions for third-party CI
On 2016-08-31 17:59:43 +0100 (+0100), Matthew Booth wrote:
> On Wed, Aug 31, 2016 at 5:31 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:
[...]
> > Also we have naming conventions for third-party CI accounts that
> > suggest they should end in " CI" so you could match
hey're in that group already (in which case let the Infra
team know because we might have a bug to look into) or ask one of
the members of
https://review.openstack.org/#/admin/groups/440,members to add the
stragglers (or even volunteer to become part of that coordinators
group and help
e way it's been handled in other already
grandfathered-in projects is that the core security review team for
that project subscribes a subject matter expert to the bug and they
use their knowledge/access to vet proposed fixes under embargo and
then we take their word for it.
--
enstack/security-analysis/tree/doc/source/templates/
[10]
https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
Open
/openstackid.org/accounts/user/login see the sentence on the
next page above the Web form where it says, "If you no longer have
access to the email address associated with your OpenStackID, please
send an email to i...@openstack.org with the relevant details
On 2016-08-17 09:21:49 -0700 (-0700), John Villalovos wrote:
> Maybe I missed it, but it would be nice if the documentation had some
> sample commented bindep.txt files.
Seems like a grand idea. I'll start a change to add a section to the
bindep documentation.
--
Jeremy S
roughput from random job
failures on Ubuntu Trusty vs. reduced throughput from turning off
~1/3 of our test capacity.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac
elp write a project's
bindep.txt to include information I know about my particular
platform so as to ease development work for the project, but I
wouldn't expect it to contain information to help me perform my
distro packaging work.
--
Jerem
e
as installing bindep from their distro and then running it with
their CWD in a Git checkout, or perhaps even doing `tox -e bindep`,
ought to be sufficient to let them know what packages they're
missing before they can, e.g., do a `tox -e py35`.
--
Jeremy Stanley
___
our infrastructure simply by proposing the change to your project
and seeing if any of your jobs fail due to missing packages.
[*] http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/data/bindep-fallback.txt
&
as now been
fixed and tested.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/m
currently uses, though there is the risk that lots of projects want
their own special images cached on disk and at some point we have to
make some hard decisions as to what we can reasonably keep embedding
in our nodepool images.
--
or want additional information on
this maintenance.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
are encountered forcing us to roll back.
Feel free to catch us in #openstack-infra or follow up to this
message if you have any concerns or want additional information on
this maintenance.
--
Jeremy Stanley
__
OpenStack Development
On 2016-08-11 08:25:00 +1000 (+1000), Michael Still wrote:
[...]
> At the time I proposed it for the tools directory in the governance repo,
> but it never actually landed.
[...]
For reference: https://review.openstack.org/121730
--
Jeremy S
ach potential extra-ATC.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listi
py
script get used.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman
easing any attempts to
test backports post-release would certainly free up a lot of our
current upstream effort and resources we could redirect into other
priorities. Or is it just stable branch changes for drivers we
shouldn't bother testing?
sted
in multi-node jobs start with just 2 job nodes and get some initial
tests performing well and returning stable results before trying to
push past 2.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not f
bring the "OSSG CoreSec (ossg-coresec)" group in
Launchpad up to 5 active members, which seems like a good number to
better distribute the work and diversity of viewpoints for embargoed
bugs that require operational security consultation.
--
601 - 700 of 1661 matches
Mail list logo
