e that projects who are interested
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 D
This would 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 c
week ago. That said, I didn't sense much enthusiasm over it (or
really over mascot selection in general) so if Nova *really* wants
to be an ant there might be room for negotiation.
--
Jeremy Stanley
__
OpenStack Developme
ng efforts to make stable
branch testing less problematic, so it's possible over time we'll be
able to increase the support duration for them. Stating that it's
okay to keep them open for changes with no testin
mall images is important,
however, since our base images are already quite large (in the
neighborhood of 5GiB as compressed qcow2) and we don't want to bloat
them further if we can help it.
--
Jeremy Stanley
__
Open
ot;
> image with all the capabilities we may be missing for general tempest
> testing? (ipv6, vlan, etc..? )
I haven't personally tested the CirrOS build instructions, but have
a feeling writing a diskimage-builder element wrapper for that
would
console.html).
> Anybody have some idea to fix that?
This looks like a corner case recently broken in our script for that
job. I have proposed https://review.openstack.org/352490 as a fix
for it.
--
Jeremy Stanley
__
OpenSt
;ve held that if a branch is no longer
testable, then there's not much reason to collaborate on code
reviewing proposed backports in the first place. If we're reducing
these branches to merely a holding place for "fixes" that "
o pull them into the AFS cache over the Internet, but
some experimentation with small and infrequently-updated custom disk
images seems like it could prove worthwhile.
--
Jeremy Stanley
__
OpenStack Development Mailing
o have been previously missing:
https://review.openstack.org/351199
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsub
ere no merge commit was needed. I
think this would get considerably more complicated, but I'll defer
to someone with deeper knowledge of Zuul's internals on the actual
complexity.
--
Jeremy Stanley
__
OpenStack Development M
create a
> branch from it.
Or `git checkout -B stable/icehouse icehouse-eol` to automatically
create a local stable/icehouse branch from the icehouse-eol tag.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not fo
e
unified diff view (rather than side-by-side as depicted in your
screenshot) it would amount to just color-coding the - and + at the
start of changed lines which probably won't jump out much visually.
--
Jeremy Stanley
_
uld be
toggled on/off fairly instantaneously while in diff view, so that if
it becomes hard to read one way (syntax highlight colors too noisy)
you just switch to the other (diff highlighting only) and keep
reading.
--
lack a simple mechanism for
granting access other than with our baked in keys/accounts, and also
because they're quite large due to pre-caching of all our git repos
and any distro packages our CI jobs are likely to try installing
(around 5GiB in compressed qcow2 format the last time I looked).
On 2016-07-29 09:41:40 -0700 (-0700), Joshua Harlow wrote:
[...]
> What shall we name it???
[...]
Also, one bucket repo for OpenStack community Errbot plug-ins, or
one repo per plug-in with a consistent naming scheme?
--
Jeremy Stan
That's what the -dev
suffix is meant to imply.
There's a general mailing list, openst...@lists.openstack.org, which
is generally recommended for usage-related questions.
--
Jeremy Stanley
__
OpenStack Development Ma
options (which admittedly was probably
at least a year ago), errbot seemed like the leading contender for
our desired language and featureset.
To echo Morgan, we just need (and would really appreciate!) someone
working on the imple
y adding core reviewers seems a little weird as
they're officially appointed by the PTL and so allowing the
incumbent PTL to appoint (or remove) specific voters before their
pending reelection... well anyway, I guess it's balanced out by
there being a lot more committers to that repo than
rs from the norm then that
may take some additional coding to automate.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
hat can be accessed if you
> are not a fan of the etherpad colors.
[...]
You can also hide the authorship colours in your browser (the
"settings" dropdown that looks like a gear has a checkbox for that),
if they're annoying.
--
Jeremy Stanley
__
ents repo over the past year) like most teams use,
or is there a different focus and constituency for this team?
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: opensta
mming your jobs, thanks!
Though that points out that you have a very incomplete mapping
defined, so presumably you've only added each of those entries after
discovering that an attempted backport failed tests.
--
Jeremy Stanley
#x27;t run into the issue yet because most have received no
backports at all and the handful of changes that have been
backported are usually within the first few days to a month after
branching while still fairly close to the master branch state (aft
Worth noting though, you can find your old content in the pad
history, like:
https://etherpad.openstack.org/p/app-catalog-mascot/timeslider
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage
which was created at the time it merged and use that
instead to find the post job.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstac
se-tools/tree/releasetools/release_notes.py?id=da89264#n33
>
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
project-config/tree/jenkins/scripts/run-docs.sh
[3]
http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-30-20.01.log.html#l-27
[4] https://review.openstack.org/119875
[5] http://governance.openstack.org/reference/cti/p
igger opening that query URL directly into a
running Gertty session?).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subjec
7;re limited to deciding which jobs run based
on filename patterns appearing in the diff instead).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.ope
; query-able list, and the reviewer would immediately have some context.
This sounds like another case for reviewday and/or a custom Gerrit
review dashboard dynamically updated like Neutron does...
http://status.openstack.org/reviews/
https://review.openstack.org/298779
-
masse, to
the point where rechecking syntax gets redesigned to make that
action easier instead.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.or
t from it which might have still been useful to track is since
implicit through release:cycle-with* tags. Thanks for clarifying!
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: opens
ck/kuryr"
>
> PTAL, https://review.openstack.org/#/c/336617/
There's a simple solution to that: correct the .gitreview file to
reference the correct project name.
http://git.openstack.org/cgit/openstack/kuryr-libnetw
when that was done:
https://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html
>
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openst
number of
significant changes we'll need to forward-port into the v3 branch.
We'd want to discuss these new features in the context of Zuul v3
instead.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for
Have you considered just writing a throwaway devstack-gate change
which overrides the gate_hook to run that one suspect Tempest test,
say, a thousand times in a loop? Would be far more efficient if you
don't need to be concerned with all the environment setup/teardown
overhead.
--
Jeremy St
e plenty of official projects that currently follow their
own independent release process and push their own tags instead.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-
for the
deliverable are handled by the Release Management team. A quick
parsing of the projects.yaml indicates that only ~21% (125 out of
582) of the deliverables for official projects have that tag
applied.
--
Jeremy Stanley
_
In the case of zuul layout.yaml, the updated config is put
in place by the Puppet module in the openstack-infra/puppet-zuul
module.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
ack.org/pipermail/openstack-infra/2016-May/004284.html
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.op
aking
it harder for us to abandon that model quickly once we have
something better in place.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.opens
at process if it does merit
changing).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi
On 2016-06-24 22:08:40 + (+), Jeremy Stanley wrote:
[...]
> the gate-horizon-npm-run-test job uses that same configuration
> (just passing a different {command}) and we're still seeing
> failures registered for it even now.
[...]
Just following up since I got a few more minu
ack/requirements repository. It could be worked around with
additional logic to fall back on the master URL if the branch
doesn't exist, but it's also possible we just document this as a
shortcoming for the sake of simp
ackinfra account founder permissions[1] and adding your
channel to our accessbot config[2].
[1] http://docs.openstack.org/infra/system-config/irc.html#access
[2]
http://git.openstack.org/cgit/openstack-infra/project-config/tree/accessbot/channels
=stats_counts.zuul.pipeline.check.job.gate-horizon-npm-run-test.FAILURE&from=-24days
>
--
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
f people
running it needed to adjust their configs, and many of us considered
that a significant hassle.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lis
penstack.org/reference/cti/python_cti.html#specific-commands
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://l
good enough to me. Thanks for all the clarification!
--
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
s of
http://git.openstack.org/cgit/openstack-infra/system-config/tree/hiera/common.yaml
(do you have a change proposed for that yet?).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscrib
contracts) then what is the point of making RHEL free
for developer use (does it come with a free support contract)? And
if the difference is that there's software/features available in
RHEL that you can't get under Cen
_all_ software provided by RHEL is also now included under free and
open licenses, then I'm thrilled and may be more inclined to give it
a try again in the future.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not
parated
experimental project under OpenStack namespace with own specs
and core team. The nearest example of the same governance is 3rd
party Fuel plugin done not by Mirantis."
So basically it's not officially part of Fuel, and isn't (currently)
eve
s a library within Zuul because we need to be able to
parse our current massive set of job configurations. Also, Zuul 2.x
continues to support using Jenkins as a worker (it just now also
supports using its own Ansible-based launcher too).
--
Jer
nfra/project-config repo, the above
is purely in reference to aspects of the v3 redesign.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.
eech (libre)? If so, that's still proprietary so I'm
curious how that changes the situation. Would OpenStack welcome a
project built exclusively around a "free for developer use" product
into the tent?
--
Jeremy Stanley
_
ng the necessary parameters in your jobs
(and also because turning off a default security measure without the
admin's knowledge is bad form).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Jenkins job.
[...]
Very recent Jenkins releases began preventing injected parameters
from making it into worker environments.
http://lists.openstack.org/pipermail/openstack-infra/2016-May/004284.html
--
Jeremy Stanley
__
OpenStack
triggered the release announcement job.
--
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
u
have to draw a line between running a reasonably representative
sample and running so many jobs that you'll never be able to merge
another change again (because even very small nondeterministic
failure rates compound to make that imposs
to enqueue it but
couldn't because it was actually already merged a couple months ago.
I manually instructed Zuul to try and requeue 324209 and that seems
to have worked.
--
Jeremy Stanley
__
OpenStack Development Mail
it's ok." So if you agree with this whole idea (sometimes
> create new repos for some applications with number mentioned earlier (no
> more then 10 per year)), current question may be ignored.
Okay, thanks--I couldn't tell whether ther
entirely through
configuration (you just need some project-config-core reviewers to
approve the changes you propose), but that might mean I'm
misunderstanding you.
--
Jeremy Stanley
__
OpenStack Developme
r confirming he's also cool with the added responsibility).
Thank you for stepping up to help on shade reviews, Ricardo!
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for u
you.
--
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
allowing new users to create/update content there.
--
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
se of executing its
"Merge if Necessary" submit type).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
htt
On 2016-05-21 16:04:17 -0500 (-0500), Dean Troyer wrote:
[...]
> Congrats and thank you Morgan, I'll show myself out now...I see a chair
> over there...
Hm! Dean is made of harder stuff! Cardinal Fang - fetch...the comfy
chair!
--
Jer
nient times over
critical bugs make him an ideal addition to the team. When you see
him responding on embargoed bugs, sending downstream stakeholder
notices or security advisories, don't be surprised; this is
expected.
Welcome, Morgan!
--
Jeremy Stanley
signature.asc
Description: Digital
ssProjectLiaisons#Vulnerability_management
[...]
Awesome--thanks! I'm always glad to see more people interested in
fixing security vulnerabilities in OpenStack.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage
e information" as it
definitely doesn't. You can see that file's full commit history at
http://git.openstack.org/cgit/openstack/openstack/log/.gitmodules
(such as it is), updated once or twice a year by a total of three
people over the entirety of i
ck-infra to delete the project?
It's fine with one slight alteration: we don't (can't really) "delete"
Git repos, we merely "retire" them. The process is outlined at
http://docs.openstack.org/infra/manual/drivers.html#retiring-a
enstack/openstack and
submitted https://review.openstack.org/318661 to update it. Thanks
for pointing that out. I've also submitted
https://review.openstack.org/318665 to try and make sure it doesn't
happen as often in the future.
--
Jeremy Stanley
__
er precisely because projects might want to do those things
outside the context of devstack-gate.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...
ying to get to the bottom of nondeterministic
network connectivity issues in that region. Taking it out of service
is painful though, because it's the region in which they give us the
majority of our overall instance quota. Hopefully it'll be figured
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
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
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
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
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
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
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-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
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
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
okay
place to publish things you don't need people to find through
external search engines? Then we could quite easily open account
creation back up with minimal risk and much lower moderator demand.
--
Jeremy Stanley
eserve the check-tripleo and
experimental-tripleo backlog.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.o
ure and their deployed base broadens further.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstac
nd just new accounts created solely for the purpose of
spamming places relying on the Ubuntu SSO for authentication.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-de
On 2016-05-10 21:07:29 +0200 (+0200), Andreas Jaeger wrote:
> On 05/10/2016 09:00 PM, Jeremy Stanley wrote:
> > [...]
> > Another outcome of this is that Andreas Jaeger put together some
> > project-config specific reviewing guidelines:
> > http://git.openstack.org/c
On 2016-05-10 20:17:43 + (+), Jeremy Stanley wrote:
[...]
> Last I heard, wiki.ubuntu.com has been made read-only for general
> users because they're having too hard a time keeping spam under
> control (they obviously also use
> login.launchpad.net/login.ubuntu.com). I
too hard a time keeping
spam under control (they obviously also use
login.launchpad.net/login.ubuntu.com). I'm trying to create an
account there right now to confirm whether this is still the case,
and the post-OpenID page which should in theory be creating my
account is timing out in my browser wi
we
should get that set up ASAP."
That concludes my recollection of these sessions over the course of
the week--thanks for reading this far--feel free to follow up (on
the openstack-dev ML please) with any corrections/additions!
--
Jeremy Stanley
signature.asc
Description: Digital
ders blocking IP protocol 47
on their LANs).
http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/multinode_setup_info.txt
http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/functions.sh#n1050
--
Jeremy Stanley
_
stack.org/cgit/openstack/governance/commit/reference/projects.yaml?id=refs/changes/99/251999/1
>
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@li
s still in the process of
drafting his to send to the ML, hopefully later today). I'm not sure
what drives people to put these on random personal blogs instead,
but the "blog" of our contributor community is the openstack-dev
mai
eel free to drop it from g-r if nothing else is using it.
Yep, in general if codesearch turns up use in a repo which isn't
mentioned in
http://git.openstack.org/cgit/openstack/requirements/tree/projects.txt
then the cruft requirement
while back (2014 maybe?) I noticed at least a few where `git blame
global-requirements.txt` led me back to commit messages mentioning
corresponding changes to consuming projects which were still in
review (some for many months) or had been abandoned.
--
module). We don't usually list transitive-only
dependencies in global requirements unless we need to pin/skip
versions of them in some way, and instead rely on the constraints
list to represent the complete transitive dependency set.
--
Jeremy Stanley
___
701 - 800 of 1706 matches
Mail list logo