ack-infra/project-config we ship a wrapper
along these lines:
http://git.openstack.org/cgit/openstack-infra/project-config/tree/tools/build-image.sh
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage
ck.org maintained by Infra sill under
development, but some final coordination with the current
Stackalytics maintainers at Mirantis is needed to get lifecycle
management details for the service worked out.
--
Jeremy Stanley
__
Ope
onally just use Linux as my development platform. I gather
some in our community prefer to use Mac or Win systems but I think
in most cases they end up augmenting their development workflow with
Linux virtual machines (either local or at a remote service
provider).
--
Jeremy S
een tagged yet as far as I can tell (no 9.0.0 in the git
repo for openstack/python-fuelclient).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ..
ing-a-project
--
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/openst
penstack.org/legal, but the wording seems to have been
partially copied from the Ubuntu community's[1] which refers to
their analogue[2] of our TC.
[1] https://launchpad.net/codeofconduct/1.0.1
[2] https://wiki.ubuntu.com/TechnicalBoard
--
Jeremy Stanley
__
nction.
--
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
On 2016-04-21 14:05:17 +1200 (+1200), Robert Collins wrote:
> On 20 April 2016 at 03:00, Jeremy Stanley <fu...@yuggoth.org> wrote:
[...]
> > When we were firming up the constraints idea in Vancouver, if my
> > memory is correct (which it quite often is not these days), part
to having a lot more low-popularity projects packaged in
major distros and written by small teams who don't have experience
handling vulnerability reports.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for
he other consuming projects to be able to say either way.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http:/
On 2016-04-19 16:10:12 +0100 (+0100), Chris Dent wrote:
> On Tue, 19 Apr 2016, Jeremy Stanley wrote:
[...]
> > I feel like many of the people pushing this idea simply didn't
> > get to experience the pain it causes the first time around and
> > won't believe their pe
ing sessions don't overlap with
Infra sessions so we should be able to get some
brainstorming/hacking going with you there at the very least.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questi
ly unrelated to
OpenStack. I can see where strict coordinated release process and
consistency for the former makes sense, but a lot of projects in the
latter category likely see it as unnecessary overkill for their
releases.
--
Jeremy Stanley
recall any objection from those of us
around the table, though it was a small ad-hoc group and we
certainly didn't dig too deeply into the potential caveats that
might imply.
--
Jeremy Stanley
__
OpenStack Development Ma
idea simply didn't get to experience the pain it
causes the first time around and won't believe their peers who lived
through it.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
uirements repository
changes (to make sure deps being added are going to be sane things
for someone in your distro to maintain packages of in the long term)
would also make sense.
https://review.openstack.org/#/q/project:openstack/requirements+status:open
--
Jerem
orking on post currently: https://review.openstack.org/293194
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
shouldn't
persist for you.
[*] https://review.openstack.org/306835
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubsc
rt pip versions as old as the
ones which predate prerelease identification in their version
parsing so could probably just start running the same sdist
publication to PyPI for prereleases as we do for full release
version tags.
--
Jeremy S
C as well, but would an RSS/ATOM feed be a good
compromise between active notification and focus on the dashboard as
an entry point to researching job failures?
--
Jeremy Stanley
__
OpenStack Development Mailing List (not
integral. Your call for a "single CI system" also seemed to imply
combining this and the upstream CI rather than simply combining
multiple third-party CI systems into a single third-party CI system,
which I now get is not actually the case. Thanks for clarifying!
--
Jeremy Stanley
the point of the application criteria are to make sure projects know
what sort of convincing we're looking for.
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Un
are addressed anyway).
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://li
ling the size of the VMT, in an effort to handle the "big tent"
model, this sanity check seemed like something we could easily
delegate to other interested volunteers to reduce our own workload
and help us cover more and a wider variety
se similarly for diskimage-builder, as there is a lot
of TripleO/Infra cross-over use and contribution happening there.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openst
d that this new Gerrit server is working as
intended and expected features are available, but if you experience
any problems please let us know in the #openstack-infra channel on
the Freenode IRC network, or via the
openstack-in...@lists.openstack.org mailing li
tml
--
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
the rise
lately, is random +1 votes on changes whose commit messages and/or
status clearly indicate they should not merged and do not need to be
reviewed. I suppose that's another an easy way to avoid the dreaded
"disagreements" counter?
impact. On the
other hand, if you find that many of them have addresses at the same
company domain... well I guess we can find people higher up the
ladder in those companies and talk to them about how to channel
their employee quotas/incentives in more productive directions for
the community as well.
--
ving changes. Below that there's a pretty varied spread (with
23% of repos having only 1 approver). This is a pretty raw analysis
though, so something taking into account how many of those reviewers
regularly exercised their approval access may yield different
insights entirely.
--
Jeremy Stanley
es result in a
significant bloat in electorate size (certainly a lot less of one
than I expected anyway).
--
Jeremy Stanley
Owners of only 1 changes: 887
Owners of only 2 changes: 428
Owners of only 3 changes: 242
Owners of only 4 changes: 178
Owners of only 5 changes: 112
Owners of only 6 changes: 1
e backdoor your
server firmware with shims that even masquerade as the firmware
updater and persist through redeployments that include firmware
refreshes.
Physical servers persist, and are therefore vulnerable in this
scenario in ways which virtual servers are not.
--
m responsible for its care
and feeding and getting the OpenStack Foundation to dedicate staff
to that end, then my concerns stand as stated.
[*] http://lists.openstack.org/pipermail/openstack-dev/2016-March/090513.html
--
Jeremy Stanley
___
On 2016-04-04 13:54:34 -0400 (-0400), Jay Pipes wrote:
> On 03/30/2016 11:00 PM, Robert Collins wrote:
> >On 26 March 2016 at 09:08, Jeremy Stanley <fu...@yuggoth.org> wrote:
> >>On 2016-03-25 15:20:00 -0400 (-0400), Jay Pipes wrote:
> >>[...]
> >>
t;marketing
potential" for releases.openstack.org so it can be viewed simply as
a source of _objective_ technical data.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsub
ces, and that may have befallen the
ec2-api project. It's the first time we've seen this since the 2.11
upgrade, as far as I know, and a Gerrit restart was necessary to get
it to start showing up as usable again. If you happen to spot any
seemingly related issues, please let the Infra team know.
--
Jer
e good to determine whether stable/mitaka changes
are meeting the same fate in the gate-trove-python27-db job (for
example, this could be a concurrency/ordering related race which may
not always surface on everyone's systems).
w our gating jobs are able to
run in any of 9 regions from 6 providers, which mitigates this
risk).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@list
allenge even with a larger sysadmin team
than you estimate being required.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
ict resolution in the merge, hence the somewhat verbose commit
message we include).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.open
model, but it should still be
generally applicable.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstac
ing on local machine and on CI.
>
> What do you think?
There are a number of projects already following that pattern as
well. http://codesearch.openstack.org/?q=zuul-cloner brings up
dozens of examples.
--
Jeremy Stanley
__
On 2016-03-25 10:39:12 +1300 (+1300), Robert Collins wrote:
> On 25 March 2016 at 10:30, Jeremy Stanley <fu...@yuggoth.org> wrote:
> > On 2016-03-24 16:21:30 -0500 (-0500), Ian Cordasco wrote:
> >> Also this only affects libraries and not the server projects.
> >&g
eases on off-master
branches:
http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openst
le branch, at the stable branches
> creation.
I could be misunderstanding, but isn't this why we have a release
pipeline job which merges the release tag into master? So that ~as
soon as there is a new release, post-versioning in the master branch
is parsed by PBR as being at or later than the mos
ic knowledge we've relied on
in Infra on multiple occasions, so consider this an outside
recommendation.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openst
ions, and we make it available on all our job workers at
/usr/zuul-env/bin/zuul-cloner. Check job macros in the
project-config directory for numerous examples of creating clonemaps
and invoking zuul-cloner in jobs.
--
Jeremy Stanley
__
itself
but also for all the software being packaged--sysadmins consuming
our packages aren't going to take the time to figure out which of
packages installed from there are "supported" by us and which
aren't.
--
Jeremy Stanley
signature.asc
Desc
ts
in our upstream CI. If you controlled the full CI stack you could in
theory support jobs which run as long as you need.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
rs are unavailable to take
over.
--
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
? I
don't think I heard about it. Was there another ML thread I missed?
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubsc
o work on developing it, pushed
up a skeleton repo, and then we never heard back from them after
that. Unfortunate.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
are not
security supported by us, not intended for production use, and if
they break your deployment you get to keep all the pieces. Users of
legitimate distros need to consider those packages superior to ours
in every way, since I really don't want to be on the hook to support
them for more than validatio
a.2016-03-11.log.html#t2016-03-11T14:46:05
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi
ad
too thin.
--
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
t matches on
"#startmeeting infra" or whatever you need to be around for...
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subje
ial
bots use a feature-rich framework which has an active upstream and
is usable on Freenode without ugly hacks like bypassing DNS or
passing credentials in the clear would still be awesome.
--
Jeremy Stanley
__
OpenStack Develop
Still, I've been holding out hope someone
might start work on a unified replacement for all of those in a more
modern codebase like errbot.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
We (Infra) also generally try to avoid overlap
with Release Management, Stable Branch, Quality Assurance, and also
Infra-related sessions for other teams.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage
ule on inconclusive
cases: the Technical Committee.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstac
t, agreeing to the ICLA and filing contact
information), and then try your git-review again once that's done.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@li
ack.org/#/q/status:merged+project:openstack/deb-openstack-pkg-tools
Obviously, we'll need the TC to step in on unusual corner cases with
inactive/newly-minted teams, such as this one.
--
Jeremy Stanley
__
OpenStack Development Mailing List
TripleO, but I'm not (yet) clear on what
tangible benefit you're receiving now that you lose by switching to
that model.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-de
issues which arise from
being half-integrated into one they don't control.
I've been meaning to bring that up for discussion for a while, just
keep forgetting, but this thread seems like a good segue into the
topic.
--
Jeremy Stanley
vite-only seemed to be the only simple solution to
preventing anyone from using that channel name indefinitely.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack
"special" (nonstandard) base
images. We've mostly got a handle on that now and once these jobs
all move from "devstack-trusty" to our new generic "ubuntu-trusty"
workers in the coming weeks we should be co
rk) so would require rewriting history.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/c
On 2016-03-09 13:57:45 +1300 (+1300), Robert Collins wrote:
> On 9 March 2016 at 13:07, Jeremy Stanley <fu...@yuggoth.org> wrote:
> > On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote:
> > [...]
> >> SOLUTION 6 - make zuul capable of performing atomic
all again, but I
don't know if that's sane with respect to the current release
schedule.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.open
On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote:
[...]
> SOLUTION 6 - make zuul capable of performing atomic cross-repository
> commits.
This seems unlikely to happen, as it's very much counter to Zuul's
designed-in reliance on serializing changes to test before merging
them.
--
you
intend to have separate rolls for your different subsystem
deliverables anyway.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.
rmine is a sane duration would be sufficient.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-
debug.
I'll move followup comments to your
https://review.openstack.org/289278 review.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.opensta
sfully logs into postgres with a root password of
"insecure_slave" and creates an openstack_citest role with password
"openstack_citest".
Any help from those more familiar with the database use in Fuel's
unit tests in narrowing down what's different about this postgrest
have a page here with
some basic information and a list of them:
https://wiki.openstack.org/wiki/Puppet
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: op
n more than we can reasonably handle, since
the VMT is by design a constrained team centrally assigning
identifiers, tracking the state of outstanding embargoes and
privately curating impact descriptions for later inclusion in public
advisories.
--
Jeremy Stanley
signature.asc
Description: D
eutron when connecting to a
shared provider network. (Rhetorical question: i.e., I'm pretty sure
this is not a one-size-fits-all fix to the problem.)
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage que
On 2016-03-02 21:25:25 + (+), Sean M. Collins wrote:
> Jeremy Stanley wrote:
> > On 2016-03-03 07:49:03 +1300 (+1300), Xav Paice wrote:
> > [...]
> > > In my mind, the default security group is there so that as people
> > > are developing their securi
f I want
packet filtering, I can bring a firewall into the colo and plug it
in, then configure it to my liking, but the default bare-bones
experience is a _less_ complex one (no firewall appliance) and if I
want separate filtering that's additional complexity I opt into b
model turns out to be true, then serving 90% in the way we
intended with only 10% freeloading seems fine to me (as long as
people who have no real intention of contributing stay out of design
sessions and let the rest of us get work done).
--
y, or update to Gertty's master branch
which avoids installing 1.0.2 and later via
https://review.openstack.org/279582
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openst
tractions and effectively sequester myself to
focus solely on the event; in-person gatherings provide a slightly
more constant reminder of what I'm supposed to be doing).
--
Jeremy Stanley
__
OpenStack Development Mai
les is not
unnecessarily entangled with the state of the software itself (and
vice versa).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack
rovoke major and minor
> version bumps.
[...]
> No - its much more than that. See
> http://docs.openstack.org/developer/pbr/#version
Thanks! Somehow the Sem-Ver: pseudo header implementation escaped my
notice, so I was definitely working on an outdated understandin
ion number which sorts after the most recent tag,
but that's really only a reflection of what the next version should
be _if_ all the changes since the last tag are trivial bug fixes.
--
Jeremy Stanley
__
OpenStack Development
r this use case make me suspect
our CI system is a poor place to attempt to implement such a
solution, but hopefully others have ideas which simply aren't
occurring to me.
--
Jeremy Stanley
__
OpenStack Developme
ese implementations, this
important work on feature parity should still be driven to
completion.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subje
ot; that people can agree on before figuring
out what Poppy even is. I've browsed its documentation and it
doesn't seem to actually define this, so I get the impression that
its entire existence is defined and informed solely by other
proprietary application designs.
ple have posted additional
troubleshooting suggestions at
https://ask.openstack.org/question/56720 .
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@list
enstack_project/manifests/static.pp
[4]
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
funding challenges.
--
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
sane_
command-line tools however, it should disable all terminal escapes
if it detects that there's no controlling terminal (for example, if
stdin is null). No idea whether command-line sanity is common to
Javascript programmers, but perhaps someone here is willing to make
it a reality if not.
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 a trusted key.
; 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
correctly in Rackspac
pdates
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 on
some branch (or were at some point in recent history
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 on their be
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.
--
uch 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.
--
Jeremy Stanley
signature.asc
ed 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
__
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 (or
801 - 900 of 1661 matches
Mail list logo
