e with the paste server too, and as soon as we added a
robots.txt to get search engines to cease indexing them the abuse
situation we had there trailed off to nothing in a matter of weeks.
--
Jeremy Stanley
__
OpenStack Devel
sleia.com/journal/2016/05/openstack-summit-days-3-5/
That's an awesome redux, and does a great job of highlighting some
items I failed to mention. Definitely worth the read!
--
Jeremy Stanley
__
OpenStack Development Maili
On 2016-05-10 19:00:35 + (+), Jeremy Stanley wrote:
[...]
> Wiki Upgrades
> -
[...]
> I'll be starting a thread on the openst...@lists.openstack.org
> mailing list in the next few days to cover the situation in greater
> detail and get the community-facing
rently running a lightweight fork of bandersnatch with his hash
indexing patch applied so need to make sure that still applies
cleanly and include it in whatever updated version we deploy on the
mirror-update server.
--
On 2016-05-12 08:11:46 +1200 (+1200), Robert Collins wrote:
[...]
> Right now we support Python, Java, Javascript, Ruby in CI (as I
> understand it - infra focused folk please jump in here :)).
[...]
We also support boatloads of shell script! ;)
--
Jeremy S
u may still want to take this
as an opportunity to rotate out some of your less-active reviewers
(if there are any).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: opensta
agree that option 3 is just shuffling around (or even increasing)
the overall pain.
For option 2 keep in mind that our current version of Gerrit allows
you to make edits from its Web UI in your browser, so it may be
almost as easy to correct trivial issues while you're reviewing
instead of co
that'll make it tricky for us to stick with whatever's in Sid.
> Non-compatible LTS cycles make for an unhappy infra.
[...]
Looks like with Stretch and beyond we can rely on not having to
import/pin/backport a nodejs 4.x package, but in Jessie we'll likely
need a workaround sti
the last year with the new openstack.py system.
>
> Interesting - I'd like to know more. A quick find / grip didn't help me
> find anything, can you help?
I assume the reference was to:
https://github.com/ansible/ansible/blob/devel/contr
On 2016-05-12 17:38:22 -0400 (-0400), Nikhil Komawar wrote:
> On 5/12/16 8:35 AM, Jeremy Stanley wrote:
[...]
> > While the size I picked in item #2 at
> > > https://governance.openstack.org/reference/tags/vulnerability_managed.html#requirements
> > >
> > is no
enstack.org/cgit/openstack/ossa/tree/doc/source/_exts/vmt.py
which does very similar things.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstac
27;t, since upper-constraints is merely used to constrain
requirements lists.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:uns
On 2015-12-12 16:51:09 + (+), Jeremy Stanley wrote:
[...]
> No, it won't, since upper-constraints is merely used to constrain
> requirements lists.
I take that back, the pip_install function in DevStack applies
upper-constraints.txt on anything it installs, but regardless it
should run on nodes with an earlier
(working) tox version.
If anyone sees any further use of tox 2.3.0 after the time of this
E-mail, please let us know.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for u
a virtualenv, so if tox is not a
direct or transitive requirement then it will end up dropped from
upper-constraints.txt on the next automated proposal in review.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not
Infra
team know as soon as possible and we can roll back to pre-2.3.x
images again.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
e way to accomplish it (as we discovered
back when we used to run DevStack smoke tests to validate our images
and frequently rejected perfectly good images due to
nondeterministic errors in the tests).
--
Jeremy Stanley
__
o unforeseen issues
like people thinking it's sane to delete their latest releases of
some dependencies from PyPI) but it's a long road to full
implementation.
--
Jeremy Stanley
__
OpenStack Development Mailing
e openstack-manuals
maintainers. Thanks for spotting this and brining it up!
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsub
or years. The
constraints-based solution is certainly a cross-project priority
effort, but the developers who are in the process of implementing it
are wary of rushing it into place and causing new problems.
Sometimes the devil you know is easier to deal with than the on
all either have "constraints" or
"dsvm" in their job names).
I'll let Robert and Sachi, who have been spearheading this effort up
to this point, comment on whether additional assistance is needed
and where they see next steps
est release have it's own kill ring (copy/paste), but I can also
use tmux's copy and paste features as well. Less time touching the
mouse means more efficient reviewing for me!
--
Jeremy Stanley
__
OpenStack Developm
https://bugs.launchpad.net/openstack-org/+filebug and someone should
get back to you after fixing the problem.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ..
st, but I observed the unwanted behavior using Iceweasel 38.1.0
(basically un/rebranded FF 38.0).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.open
ng
lack a swap memory device. I have a feeling if you swapoff before
this point in the job you'll see it fail everywhere.
For consistency, we probably should make sure that our workers have
similarly sized swap devices (using a swapfile on the rootfs if
necessary).
--
nty of time (~5 weeks from now) for
people to figure out for sure whether they can attend, so let's just
update the wiki to reflect that.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
t; noting blueprint/spec?).
I'm not a core reviewer for DIB, but for a small modification I
doubt they expect you to create a Launchpad blueprint or an
associated specification. I would just start by pushing the proposed
addition into Gerrit and see what
to it from
their earlier state), I'm even less thrilled with the idea that
people might just slash-and-burn repos, abandoning them and creating
new ones because they've put them in an unusable state.
--
Jeremy Stanley
__
Op
27;s
something broken. The systems we support are working as designed,
and you should still be able to use them for your existing project
without having to abandon it and create a new one under a different
name.
--
Jeremy Stanley
signatu
gh" instead of
complaining about how nobody has time to build an ideal environment
for him before he can even get started.
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development Mailing L
ct basis.
--
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
ply a requirement of the Docs team, since
they were having trouble triaging auto-generated bugs they were
receiving and wanted to enforce the inclusion of some expository
metadata.
--
Jeremy Stanley
__
OpenStack Development Mail
e TC, however don't confuse that with the "TC Approved
Release" which is something else:
https://governance.openstack.org/reference/tags/tc-approved-release.html
--
Jeremy Stanley
__
OpenStack Developmen
it will also probably
destroy any system on which it runs.
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-d
to the requirements repo (our generic unit
test job-templates very specifically assume the change proposed is
to the repo under which tox is invoked and what's needed is
something more like an integration test job).
--
Jeremy Stanley
__
bian-sid
nodepool image shows up we could certainly try running Py3K jobs on
that instead.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.opens
LTS distro releases to run production systems. We've also got a
modest sized OpenStack deployment on its way to production, again on
an LTS distro release. I agree that releasing server software which
is only well tested on "desktop" pace distro releases would be a
serious misst
sulting in the summary at
https://wiki.openstack.org/wiki/LegalIssuesFAQ#Copyright_Headers for
those who choose to learn from history rather than repeating it.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for u
On 2016-01-15 23:09:34 +0800 (+0800), Thomas Goirand wrote:
> On 01/15/2016 09:57 PM, Jeremy Stanley wrote:
[...]
> > resulting in the summary at
> > https://wiki.openstack.org/wiki/LegalIssuesFAQ#Copyright_Headers for
> > those who choose to learn from history rather than re
t we've reported crippling bugs in newer versions of system
dependencies which have caused us to scurry to roll that back. While
it may be time to try our luck again and hope we fare better, we're
also only a few months from the next Ubuntu LTS (and as also
mentioned CentOS 7 is available for
penstack.org/resolutions/20150615-stackforge-retirement.html
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://
On 2016-01-16 12:12:00 +0800 (+0800), Thomas Goirand wrote:
> On 01/15/2016 11:26 PM, Jeremy Stanley wrote:
> > On 2016-01-15 23:09:34 +0800 (+0800), Thomas Goirand wrote:
> >> On 01/15/2016 09:57 PM, Jeremy Stanley wrote:
> > [...]
> >>> res
our life as a package maintainer easier. If there was
ever a good reason for copyright assignment in free software, that's
not it.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsub
lack
sufficient experience in copyright law to know whether it's possible
at all under the current foundation bylaws and I doubt you know
either.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage q
itching to a
copyright assignment model) would need input from their legal
counsel, and possibly even a majority vote of the foundation
membership to actually enact.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not f
04
LTS, which looks like it's going to ship with QEMU 2.5.
Alternatively, look into getting a live migration job running on
CentOS 7 or Fedora 23 if it can't wait until after Mitaka.
[1] http://lists.openstack.org/pipermail/openstack-dev/2016-Janu
tabilized the ones we already
added (while riding in on magic rainbow-vomiting unicorns, perhaps).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ..
valent is:
https://git.openstack.org/cgit/openstack/fuel-library/plain/deployment/Puppetfile
The copy on GitHub is only a best-effort mirror and may not always
reflect upstream reality.
--
Jeremy Stanley
__
OpenStack Develop
bug upstream:
https://github.com/eventlet/eventlet/issues/290
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lis
permail/openstack-dev/2015-December/082902.html
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.or
ion the tox.ini is also configured to add
(--download-cache), making the sdist unbuildable via tox at that
tagged point in the ceilometer repository.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage
ot
admins. The drawbacks mostly come down to needing to apply some
additional scrutiny to the generated tarball before pronouncing it
viable, and the need to place trust in a manual process slightly
inconsistent with our usual sdist gener
On 2016-01-29 18:27:18 + (+), Jeremy Stanley wrote:
[...]
> Due to unfortunate timing, the last commit on stable/liberty was
> tested with pip 7 and merged, but the 2015.1.2 tag for that commit
> was pushed after pip 8 was released and so tox was no longer able
> to work wit
s for
this, as long as it's acceptable to leadership from stable branch
management, Telemetry and the community at large. Our infrastructure
exists to make things more consistent and convenient, but it's there
to serve us and so we shouldn't be slaves to it.
--
Jeremy Stanley
_
ceilometer-2015.1.3.tar.gz
sha256sum:
a84fd2b18f922be4b2aca7c89baf2153f9656ebe6791a9de37f56283f866645c
/srv/static/tarballs/ceilometer/ceilometer-2015.1.3-py2-none-any.whl
465f8605639b36bbb86c3198a58ef3282e54546bc587c436db34cb613e1f2404
/srv/static/tarballs/ceilometer/ceilometer-2015.1.3.tar.gz
--
Jeremy Stanley
te project instead rather than
improving Cinder's existing solution so that people who have been
using that can benefit directly?
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questio
If anyone has any details about this, please give me a heads up so
we can try to correct the situation.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@
On 2016-02-04 18:17:07 + (+), Jeremy Stanley wrote:
> I was getting around to taking care of this just now, and it looks
> like someone has deleted the stable/icehouse branch without tagging
> it icehouse-eol first?
[...]
Nevermind--it's still there. Perhaps I need glasses
ating in such an
event, but just wanted to clarify it's my understanding that our
conference organizers aren't prepared for the logistical challenges
of generating extra codes for Bug Smash participants who haven't
otherwise contributed to the release so close to the Summit dates.
--
ensed and
openly-developed client software which people can use with a
proprietary service and for which there is no alternative open
equivalent service on the market (yet), we need to be prepared to
answer these other questions about where we draw the line on "open
enough."
--
Jeremy Stanley
nt out again that snapshots != backups,
> at least not for those who care about backups.
And just to be clear, you assert that the Nova team would reject
extending their existing backup implementation to support this, so
the only real solution is to make another project
ify anyone for a registration
code. Some of our conference coordinators had expressed concern that
new or latent contributors participating in the Bug Smash may be
expecting a discount code, so I volunteered to send a follow-up to
this thread o
gt; Igor Belikov did an amazing job at it, let's please not get this stuck
> because no core reviewers are helping.
Absolutely! I'm excited about this, but was holding off reviewing
for the past week while waiting for Igor to make sure it's booting
c
s long as their requirements and the constraints list updates
are being kept up with. Jobs for repos not participating in global
requirements may still benefit if they share some requirement
versions with things which are listed in the constraints file
l/e70f5c0/logs/devstack-gate-post_test_hook.txt.gz#_2016-02-11_05_12_01_023
[...]
The error there implies that diskimage-builder invocation in your
job is reusing the host's apt sources but not its apt configuration,
and so is expecting the packages on the mirrors to be secure-apt
signed by
ME_MAX on our test platforms.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bi
.
2. There are concerns that capitalized use of project codenames
makes them more likely to present a high-profile/infringing
target for intellectual property (trademark, et cetera) claims.
--
Jeremy S
he logic it embodies lacks the
branch-specific alignment possessed by the requirements data it was
originally set to contain.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: op
realistically have our
cake and eat it too, as they say.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists
r processes and customs are infantile. It's not
constructive at all. Further, we should pick one mailing list on
which to have this discussion rather than cross-posting to four.
--
Jeremy Stanley
__
OpenStack Developmen
they're outweighed by the ongoing cost of working
around the problem.
--
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
resolver and finding what actual versions we're ending
up with out of the manually vetted ranges in our requirements.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac
oned
later in this thread) is a static code analysis tool for shell
scripts (analogous to pylint/pyflakes in the Python world). Both
potentially useful tools for helping you maintain code quality on
shell script based projects, but neither of these is a unit testing
framework.
s at runtime. For
example:
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/puppet-module-jobs.yaml#n45
>
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questio
then have the
lawyers vet them in community preferred order instead. You're
basically arguing in favor of the old process people were
complaining about.
This is a great example of "you can't make everyone happy."
--
Jeremy Stanley
___
e not asking tox to invoke the pep8 tool; rather you're asking
tox to invoke a set of commands associated with an environment
definition named "pep8" in its tox.ini file.
--
Jeremy Stanley
__
O
only DevStack is making use of the constraints
file currently. Unit tests are still relying on pip to install
working versions of packages from the requirements.txt and
test-requirements.txt within each repo.
--
Jeremy Stanley
_
Juno early, we
can't drop 2.6 jobs until October.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.op
https://review.openstack.org/198620
--
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/li
rs into tests_require.
Without more of the logs indicating what installed which versions of
PBR and why, it's hard to tell you any more than that. Are you
running from the DevStack master branch or a stable/something
branch?
--
Jeremy Stanley
__
On 2015-07-11 18:09:26 + (+), Jeremy Stanley wrote:
> On 2015-07-11 22:49:27 +0530 (+0530), Venkateswarlu P wrote:
> > After running ./stack.sh
> > I am getting the following error.
> >
> > 015-07-11 17:01:02.188 | error in setup command: 'tests_requi
to install and run
python-novaclient from PyPI can use the stable/juno version (though
I'll admit that finding which version works with 2.6 may be a tricky
proposition for a consumer who is unaware of this situation).
--
Jeremy Stanley
_
uation has changed, and it's worth revisiting that choice.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsub
ibs working
with 2.6 for several more months, or be able to push forward with
our constraints overhaul between now and then. I'll be hard to have
the necessary tooling in place before the liberty release if we
can't actually use it before then (since that's roughly when juno
EOL is
e stable branch release managers
and the rest of the release team along with the quality assurance
team.
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage quest
, which repos run
them, and the branches on which they're allowed to run).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subjec
le idea) then we should enforce it in tests somewhere first.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lis
any marker simplification
routine is probably better implemented in setuptools/pkg_resources
which is already parsing these.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: opensta
ep
requirements pinned to a known-passing set in DevStack-based jobs,
and that is already determined by the jobs which report on the
constraints update itself.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not
e the URL memorized:
https://wiki.openstack.org/wiki/Infrastructure/Conferencing
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subje
git
This should not _ever_ be necessary with git-review. IF git-review
is able to authenticate to Gerrit, it will add the remote
automatically. The actual problem here is an authentication failure.
Please never recommend this as a workaround, it only increases
confusion.
--
Jeremy Stanley
signa
ironic) then that will be necessary for you as
well.
For reference, our account setup documentation is available at:
http://docs.openstack.org/infra/manual/developers.html#account-setup
--
Jeremy Stanley
signature.asc
Description: Digital signature
___
sions (1.25.0 certainly, maybe 1.24 as well but I'm having
trouble tracking down exactly which commit improved that situation)
are clearer about this and you'll actually see the CLA or contact
info errors rather than a misleading error abo
s.yml,
> loop on them, clone them, apply the templates and submit the review.
Also, does msync know to take advantage of the on-disk cache of git
repositories on our job workers, or does it clone them all over the
network every time it runs? The la
y in the
environment markers section, which is hopefully only a mildly
confusing attempt to reduce duplication of examples).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
actice (especially when
you have one team of people pushing tags and a different team
approving updates to the repo's setup.cfg file).
A suitable compromise might be to add a knob to PBR (probably via a
directive in setup.cfg) to emit a warning and fall back on version
guessing as if the v
making that change during mitaka.
I fully support this. Getting away from needing to update versions
in setup.cfg at all will be great.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscrib
by replacing the -1..+1 with 0..+1 for the neutron-ci group:
http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/neutron.config#n7
>
--
Jeremy Stanley
__
OpenStack Development Mailing
use
if/when it happens again.
--
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/mailm
w gerrit event can't trigger any
> jenkins job.
I must not be understanding what you're describing, since it sounds
exactly like Zuul's existing graceful shutdown behavior and also
because I have no idea how that would help this situ
501 - 600 of 1706 matches
Mail list logo