less requests is pre-installed on the executor
too ?)
Thanks for the full analysis, I learned a couple of things :)
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
n the executor -- the trick is that for
such a short job the overhead of requesting a test node is a bit heavy,
and we want to run the job on every vote change on release requests
Other ideas?
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
cy as that constituency feels is appropriate.
The advisory board will also serve as a point of contact for the OpenDev
project when making changes that may be disruptive. The intent is to create
bidirectional communication between OpenDev and the advisory board.
How does this look?
Loving it.
Jeremy Stanley wrote:
On 2019-12-04 09:45:48 -0500 (-0500), Mohammed Naser wrote:
On Wed, Dec 4, 2019 at 5:47 AM Thierry Carrez wrote:
[...]
I'm also wondering if the advisory board should not also include seats
for the infrastructure donors... Since we should definitely be making
visory board should not also include seats
for the infrastructure donors... Since we should definitely be making
sure Opendev goes in a direction that encourages them to continue
investing in (or increase) the resources that they give us.
--
Thierry Carrez (ttx)
Jeremy Stanley wrote:
On 2019-11-14 17:14:35 + (+), Jeremy Stanley wrote:
On 2019-11-14 17:54:45 +0100 (+0100), Thierry Carrez wrote:
[...]
"checking that the PTL or designated liaisons have actually +1 the
request, before casting our own +2 vote."
[...]
Not that I hav
e
simpler ways to achieve a similar results.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Sorin Sbarnea wrote:
Having a StackOverflow kind Q&A site is of great value but only if there is
enough critical mass to maintain it. Clearly ask.openstack.org is far from reaching
that mass.
I would personally see more useful to redirect users to two existing platforms
that already passed th
Jim and Thierry wrote:
[...]
One consequence of that transition is that non-OpenStack repositories
that were previously mirrored to GitHub under the "openstack"
organization are now stale and no longer updated, which is very
misleading. Those should now be retired, with a clear pointer to the
Hi everyone,
The migration of our infrastructure to the Opendev domain gave us the
opportunity to no longer have everything under "openstack" and stop the
confusion around what is a part of OpenStack and what is just hosted on
the same infrastructure. To that effect, in April we transferred
n
vering other ways to retrieve our deliverables (pypi, git).
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
account for the repo
renames under the Infrastructure team, but we have to do that anyway.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
openstack-infra/ -> openstack/
rename, with things like:
openstack-infra/gerrit -> openstack/gerrit
Shouldn't that be directly moved to opendev/gerrit? Moving it to
openstack/ sounds like a step backward.
--
Thierry Carrez (ttx)
___
OpenStack-In
k/edge-computing-group should probably be added as a FEMDC SIG
repo and stay under openstack/.
openstack/arch-wg should be added under TC-owned repos and stay under
openstack/.
If that works for everyone, I'll propose the corresponding changes.
--
Thierry
/22151762d1147da9bbbe9353fe52c6995ab8b658/release/propose-update-constraints/453d5a1/
: SUCCESS in 3m 21s
Looks like the readthedocs integration for JJB is misconfigured, causing
the trigger-readthedocs-webhook to fail ?
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing
tatus, not
listed above)
AFAIK we can remove these two as well - looking at:
https://review.openstack.org/254817
Yes releasestatus is not used anymore.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
:)
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
ed
by Anil Rao (although Vinay Yadhav might be able to change that as the
original registrant), and the OpenStack Administrators was never added
as a co-owner.
Anil: any chance you could update the maintainer ?
Thanks in advance,
--
Thierry Carrez (ttx)
__
s calendars generally work on a weekly basis
> for other things...?
Maybe we should engage with other currently "monthly" meeting chairs and
ask them how happy they would be with a 4weekly ? Because if they don't
plan to switch to it, there is little point in pursuing that option ?
Blair Bethwaite wrote:
> On 10 Nov 2016 8:56 PM, "Thierry Carrez" <mailto:thie...@openstack.org>> wrote:
>>
>> The issue with this solution is that any "monthly" slot ends up being
>> exactly the same as a "weekly" slot: you can
Tony Breeds wrote:
> On Wed, Nov 09, 2016 at 10:56:38AM +0100, Thierry Carrez wrote:
>
>> Our scheduling system currently only supports biweekly or weekly
>> meetings. We don't currently support monthly or triweekly meetings
>> (mostly to avoid having to detect co
pretty difficult to find empty
slots manually.
Any chance you could express what you are after using only biweekly
meetings ? Like schedule odd Mondays, odd Thursdays and even Tuesdays ?
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
Ope
Jeremy Stanley wrote:
On 2016-06-21 17:34:07 + (+), Jeremy Stanley wrote:
On 2016-06-21 18:16:49 +0200 (+0200), Thierry Carrez wrote:
It hurts a lot when it's down because of so many services being served from
it. We could also separate the published websites (statu
;s down because of so many services being served
from it. We could also separate the published websites (status.o.o,
governance.o.o, security.o.o, releases.o.o...) which require limited
resources and grow slowly, from the more resource-hungry storage sites
(logs.o.o, tarballs.o.o...).
--
Thie
n docker 1.8.2. Now we can use any version of Docker we need,
which is 1.10 and greater.
Hope the context is useful.
OK, as I said, liberty is pre-official so I'm fine with any solution
here. We seem to be in agreement that the proposed
ities, slow moving and safe changes. What
you're proposing wouldn't be an option for stable/mitaka -- so I'd like
to make sure we don't find ourselves in a similar situation in the future.
--
Thierry Carrez (ttx)
___
OpenStack-I
wiki,
but we should probably protect whatever is left (while we continue the
effort of replacing those pages by properly peer-reviewed sites).
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
had a "storyboard"-focused sprint some time ago that
was also not about training, and was also very productive :)
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
a proper noun is
a good idea. It would help with a lot of confusion.
You could generalize usage of "Infra" as a team name and phase out usage
of "Infrastructure". That would avoid a lot of renaming.
"""
The "Infra" team is the horizontal team devel
ant to get in touch with John Dickinson (the
Swift project team lead) and discuss that with him (if you haven't already).
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.
nfidence you'll let me know
>> if this is insane, and in that case provide alternative suggestions!
The Task tracking session is at the same time as the talk Doug and
myself are giving on the conference side... I'd really like to be able
to attend that session though -- any chance y
plan.
> If we can achieve consensus on the approach, we will make further
> announcements as to specifics soon.
Sounds good. I like that we take the opportunity to clean up abandoned
projects: since there is no "project team owner" for those projects,
it's easy to create one and
n production.
I think it's fair for infra-core to quickly revert commits that would
break our production instance. That sounds like a reasonable compromise:
let devs make fast progress but still keep our continuous deployment to
storyboard.o.
: it will ultimately result in them
forking their future development on another platform. To avoid that, I'd
rather reboot the team completely and give them the keys.
Thoughts ?
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-
bricator
is from covering OpenStack needs. Hope this was helpful.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
nto Wikimedia: for security, our friends there
implemented something pretty close to what we need, as an extension:
https://git.wikimedia.org/tree/phabricator%2Fextensions%2Fsecurity.git
Next up on my list, looking into the CLI and API.
[1]
https://www.mediawiki.org/wiki/Phabricator/Creating_and_r
Stay tuned for episode 2...
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
ick a
biweekly spot and skip meetings liberally.
> According to ICAL examples[2], it looks like monthly is basically done
> as based on a day, and a week-of-month position:
> [...]
Right, there is nothing technical preventing to encode it in ICAL -- it
just generate
probably work around the limitation: Release reporting
---
One of the things we use Launchpad for is to produce release pages
listing what features and bugfixes landed in a given release tag. There
is no support for that (at all) in Man
t; Suggestion: Oslo
>
> The specs cookiecutter seems to be outside of the Oslo mission.
> Maybe the release management team should own it?
Works for me. Or we can make it a TC-owned repo.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing
ne of them.
> Since they're configured to allow any registered user to
> approve/merge changes this seems like it would be a quick loophole
> for achieving ATC.
Right, those were intentionally kept in limbo. Let's keep it tis way.
--
Thierry Carrez (ttx)
_
openstack/ossa
>Suggestion: Release cycle management
>
> openstack-dev/devstack-vagrant
>Suggestion: QA
>
> openstack-dev/specs-cookiecutter
>Suggestion: Oslo
>
> Do you agree with my suggestions? If yes, I can sent patches for the
> governance repo.
Yes
rojects and play around, that would be great.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Launchpad is not (yet) out of the game. It
could grow the set of features we need (ability to auth using
OpenStackID, multi-task features with tags and comments, task
dashboards, no more silly timeouts, comprehensive API...). Unlikely, but
still possible :)
I look forward to
that!
I know that should make some StoryBoard devs quite happy.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
API is available at
> https://pypi.python.org/pypi/gerritlib.
It's also possible to simply push the branch, if you have the required
permissions in Gerrit.
That's what the release script which creates proposed/$SERIES branch
operates:
http://git.openstack.org/cgit
ld we fix the -tarball job and
retrigger it manually ?)
Staying put,
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Cross-posting from -dev
FWIW I agree with the request, the wiki session duration seems to have
been dramatically lowered a few months ago.
Message transféré
Sujet : [openstack-dev] Session length on wiki.openstack.org
Date : Fri, 5 Dec 2014 12:03:49 +1100
De : Tony Breeds
Répon
quests are tracked using our
experimental task tracker at:
https://storyboard.openstack.org/#!/project/719
Welcome!
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
(Ben, CC-ed) to see how he wanted to organize his
development cycle.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
generally
agreed that supporting proposed/foo was not very complex, or at least
not as weird as switching ACLs for stable/foo at release time.
So it looks like we should proceed with supporting proposed/foo on
prerelease, but I wanted to do a last-minute check to make sure everyon
cycle and what for?
They are created at release time. Note that we are changing the process
this cycle, though. We'll probably have a proposed/juno branch (NVIE's
release branch) which then turns into stable/juno (~ NVIE's master branch).
Hope this helps,
--
Thierr
worried that I
>>> may miss an update to a changeset.
>>
>> You mean for the requirements repository ?
>
> No, sorry I wasn't clear. I mean for the config repo for changes that create
> new oslo source repositories.
Ah! makes sense, yes.
--
Thierry Carrez (ttx)
set.
You mean for the requirements repository ?
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
s, the question of
whether all client libraries should also live under that program, and
the question of whether it should be lumped in a bigger end-user UX program.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
ternative... potentially making it a gigantic
distraction.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
er to match the
> naming of Zuul.
> [...]
Being fully aware of the irony, I'll play the devil's advocate:
Could you detail why improving Gerrit is not an option ? At first glance
its development seemed to be open enough, and it didn't appear
fundamentally wrong (just nee
e repo under your program.
>From what you're saying that seems to be a "nascent separate group"
forming, in which case I agree stackforge is probably the best bet.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
enstack/*.
The move to stackforge would make sense if it was developed by a nascent
separate group, but I don't think that's the case here ?
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
o have everything on the same page: activity
mixed with comments in a single event log (like in the POC). I would
allow to submit comments when changing status. I would also use icons to
convey the event nature (task created, comment added... etc.). To see
how the POC handled it, see [2].
[2] http
tter and which should be given extra resources and
parallel testing.
--
Thierry Carrez (ttx)
signature.asc
Description: OpenPGP digital signature
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/ma
James E. Blair wrote:
> Thierry Carrez writes:
>
>> In the short term, since adding ops is a slightly painful process, I'd
>> like to suggest we add one person in Europe and one in India/China to
>> that team to improve our op coverage. I'm volunteering for th
t shiny openstack cloaks. Perl
coders out there might be interested in speeding that up by helping out
on http://dev.freenode.net/GMS development :)
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists
osed change for
future conflicts before it is even reviewed and at merge time, using the
same check/gate mechanisms we have for everything else. It sounds a lot
more difficult to set up such automated verification in the drupal case,
so that would push the conflict validation onto the human
e fashion). I can help as
the "customer" expressing feature requests, but can't spend too much
time mentoring.
Let us know if they grab it so that we don't spend more time on it.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mail
Stefano Maffulli wrote:
> On 12/12/2013 05:43 AM, Thierry Carrez wrote:
>> One benefit of coming up with our own format is that we can seriously
>> limit the options (weekly, bi-weekly, monthly with or without rotating
>> time), which I think cover all our current cases... wh
y.
One benefit of coming up with our own format is that we can seriously
limit the options (weekly, bi-weekly, monthly with or without rotating
time), which I think cover all our current cases... while remaining
user-friendly enough.
--
Thierry Carrez (ttx)
s
Chmouel Boudjnah wrote:
> On 12 Dec 2013, at 10:21, Thierry Carrez wrote:
>
>> The format of the YAML file would limit errors (all times in UTC,
>
> What would be the YAML format ? something like this ? [1]:
>
> openstack-meeting:
> - nova:
> - time
great way to visit a number of aspects of OpenStack infra &
development: gerrit, check tests, merge jobs, docs publication... all in
a small package !
Let me now what you think,
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
O
James E. Blair wrote:
> Thierry Carrez writes:
>
>> To script milestone-proposed branch creation, it looks like granting
>> createReference to "Release managers" on refs/heads/proposed/* would do
>> the job (although maybe the current "push" permiss
It's a bit tricky though, since proposed/icehouse-1
needs to be deleted at the end of pre-release, while proposed/icehouse
(the branch that will hold all the RCs and get turned into
stable/icehouse) should stay alive until final release and its
conversion
ld taskflow be a part of oslo?
That would make sense... Sounds generic enough to me, and I know Joshua
has plans for it to be included in multiple projects at this point.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.o
ck-infra/jeepyb/blob/master/jeepyb/projects.py#L134
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
"new
openstack project" and calling it "openstack FOO". This grey area serves
the marketing of a lot of companies well, but creates confusion and
dilutes whatever impression of quality and integration we may have
created on our users.
I fear that adding #openstack-BAR channels
ed to an arbitrary review ? Or just that the accounts are kept
separate ? It might be inconvenient to have to ask everyone to join
first, in order to get all the right people available for review help
later...
Cheers,
--
Thierry Carrez (ttx)
___
Ope
I would rather use the money (if any) to fund some positions that would
free some time from the people that already work on it.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
provider on Foundation systems
(including Launchpad's one for those attached to it).
As long as we depend on Launchpad (which ONLY supports Launchpad's
OpenID provider) there is no way to migrate to something else anyway...
so this is more a "future plans" thing.
--
Thierry Car
/irc.html#statusbot
I actually read it during the "crisis" but thought that the commands had
to be issued by PRIVMSG :) Then that lead me to look for the nick
statusbot was running on, which was a red herring.
Proposed doc clarification @ https://review.openstack.org/48209
--
Thierry C
ts
> http://laughing-spice/logviewer/?q=http://worker/job/index.html where
> the index.html contains links to logs like
> http://laughing-spice/logviewer/?q=http://worker/job/mysqllog.txt etc.
> [...]
Sidenote: I like that idea too, but I'm not
Condorcet.
For serious stuff (Condorcet method) we've been using CIVS (which
requires you have the precise list of voters emails).
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
ng your design goals... (which may involve
additional copying of backup data to another provider).
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
.D (with D fixing a bug in B) and
smokestack rejects B (because it has a bug ?). How would you reconcile
that without manually building wildly different trees ?
Regards,
--
Thierry Carrez (ttx)
Release Manager, OpenStack
___
OpenStack-Infra mailing list
O
jobs while having nobody looking after
their failure is useless. The trouble here is that nobody (stable team,
security team, Swift devs) cares enough about stable/folsom Swift to
maintain it in good shape... so I guess we'll have to wait for some
security issue to pop up and the th
83 matches
Mail list logo
