://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1]
http://lists.openstack.org/pipermail/openstack-operators/2018-September/015919.html
--
Jeremy Stanley
signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack
o them
over the next week.
[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
--
Jeremy Stanley
signature.asc
Description: PGP signature
___
Open
case either might be resulting in
subscribers missing it.
[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
--
Jeremy Stanley
signature.asc
Description: PGP sign
community SIG to cover it?
[...]
It may also be worthwhile to ask this on the openstack-sigs mailing
list.
--
Jeremy Stanley
signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openst
opics
Which is its initial location for crowd-sourcing/brainstorming, but
will get published to a more durable location like on
lists.openstack.org itself or perhaps the Project-Team Guide once
the list is in use.
--
Jeremy Stanley
signature.asc
Description: PGP signature
_
are closed
down for good).
[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
--
Jeremy Stanley
signature.asc
Description: PGP signature
___
good).
[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
--
Jeremy Stanley
signature.asc
Description: PGP signature
___
OpenStack-operators ma
t; Local meetups/events, we discussed putting that here as well.
It seems a fine plan, just keep in mind that documenting and
publishing feedback doesn't magically translate into developers
acting on any of it (and this is far from the first time it's been
nfra-ptg-denver-2018
[4] https://www.ietf.org/rfc/rfc2369.txt
[5] https://etherpad.openstack.org/p/common-openstack-ml-topics
--
Jeremy Stanley
signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
hing new, since we already declare how and where
official discussion takes place and the measure doesn't make any
attempt to change that. We also don't regulate where unofficial
discussions are allowed to take place, and so it doesn't open up any
ne
he concrete reasons why continue to be missing from these
discussions.
--
Jeremy Stanley
signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
r willingness to do
> that within their project, they shouldn't be the PTL. The same
> goes for TC members IMO.
Completely agree, I think we might just disagree on where to strike
the balance of purely technical priorities for the TC (as I
personally think the TC is somewha
On 2018-09-12 17:03:10 -0600 (-0600), Matt Riedemann wrote:
> On 9/12/2018 4:14 PM, Jeremy Stanley wrote:
> > I think Doug's work leading the Python 3 First effort is a great
> > example. He has helped find and enable several other goal champions
> > to collaborate
On 2018-09-12 16:03:12 -0600 (-0600), Zhipeng Huang wrote:
> On Wed, Sep 12, 2018 at 3:55 PM Jeremy Stanley wrote:
> > On 2018-09-12 09:47:27 -0600 (-0600), Matt Riedemann wrote:
> > [...]
> > > So I encourage all elected TC members to work directly with the
> > >
hate to give the impression
that you must be on the TC to have such an impact.
--
Jeremy Stanley
signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin
On 2018-09-06 15:03:52 -0500 (-0500), Matt Riedemann wrote:
> On 9/6/2018 2:56 PM, Jeremy Stanley wrote:
> > On 2018-09-06 14:31:01 -0500 (-0500), Matt Riedemann wrote:
> > > On 8/29/2018 1:08 PM, Jim Rollenhagen wrote:
> > > > On Wed, Aug 29, 2018 at 12:51 PM, Ji
> > // jim
>
> FYI for those that didn't see this on the other ML:
>
> http://lists.openstack.org/pipermail/foundation/2018-August/002617.html
[...]
While I agree that's a great post to point out to all corners of the
community, I don't see what it has to do wit
pointed out we
don't usually tell them to take their questions elsewhere any more).
--
Jeremy Stanley
signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/
tough, but luckily MIT's
listadmins have posted some so we don't need to:
http://web.mit.edu/lists/mailman/topics.html
--
Jeremy Stanley
signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists
welcome
message, or merely linked to a published document (and whether
that's best suited for the Infra Manual or New Contributor Guide or
somewhere else entirely is certainly up for debate), or even
potentially both.
--
Jeremy Stanley
signature
way, come to understand it, and
become part of that process. Requiring them to have their
conversations elsewhere sends the opposite message.
--
Jeremy Stanley
signature.asc
Description: PGP signature
___
OpenStack-operators mailing lis
ve a *lot*
of "black hole" subscribers who aren't actually following that list
but whose addresses aren't bouncing new posts we send them for any
of a number of possible reasons.
--
Jeremy Stanley
signature.asc
Description: PGP signature
___
support in
Mailman unless we can somehow work with them to help in
reimplementing it.
--
Jeremy Stanley
signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-
he irony of cross-posting this
message to four mailing lists is not lost on me. ;)
[1] https://etherpad.openstack.org/p/YVR-ops-devs-one-community
[2] https://etherpad.openstack.org/p/common-openstack-ml-topics
--
Jeremy Stanley
signature.asc
Description: PGP signature
an also tell by looking at the general project properties:
https://review.openstack.org/#/admin/projects/openstack/operations-guide
"Require a valid contributor agreement to upload" there is "INHERIT
(false)" which indicates it's not set.
--
Jeremy Stanley
sig
On 2018-08-09 09:56:47 +0200 (+0200), Thierry Carrez wrote:
> Jeremy Stanley wrote:
> > [...]
> > It does indeed sound like you might be caught up in the
> > aforementioned SASL-only network blacklist (I wasn't even aware of
> > it until this ML thread) which Fr
s too. This is entirely independent
from the Infra team measure to require nick registration in official
OpenStack IRC channels, but certainly another symptom of the same
fundamental problem.
--
Jeremy Stanley
signature.asc
Description: PGP signature
_
nted you from connecting to
Freenode. You only need to be in a server buffer and connected to be
able to `/msg nickserv ...` but don't need to be in any channels at
all so shouldn't be a chicken-and-egg scenario.
--
Jeremy Stanley
signature.asc
Description: PGP signature
tups?
> >
> > Doug
> >
>
> We've been around 100ish so pretty light
How does it compare to respondent count from previous surveys about
organizing operations-focused gatherings?
--
Jeremy Stanley
signature.asc
Description: PGP signature
_
/deployers find the tag useful at all. If you or
your organization relies on this tag in any way, the OpenStack
Technical Committee would like to hear about it so they can know
whether continuing to track it is in any way an effective use of
time. Thanks!
--
Jeremy Stanley
signature.asc
Description
e OpenStack Foundation and doesn't even require any
account on www.openstack.org for now, just login.ubuntu.com (this
will likely change in the future when we eventually switch OpenID
providers).
--
Jeremy Stanley
signature.asc
Descriptio
level) to be
able to do so. Participation in the survey is not mandatory, but
still much appreciated as it helps the OpenStack project
contributors better determine where improvements are most needed.
--
Jeremy Stanley
signature.asc
Description: PGP signature
___
are eligible to do so.
--
Jeremy Stanley
signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
hose who mostly run software (and
vice versa). Having dedicated events and separate named identities
for these overlapping groups of people serves only to further divide
us, rather than bring us together where we can better draw on our
collective strengths to make something great.
--
Jeremy Stanley
security risks exposed by DEBUG level
logging to be only hardening opportunities, and as such these often
linger unfixed or don't get backported to earlier releases (in other
words, we consider running in production with DEBUG level logging to
be a risky from an information security standpoint).
to know how your deployments are. This is the area
> that deployment tools (like ansible, tripleo, fuel and so on)
> handle.
[...]
The burgeoning discussions about an etcd backend for oslo.config may
be relevant to this piece of the problem.
--
Jeremy Stanley
signature.asc
Description:
oftware is more on topic. Add "[horizon]" to the subject
line for more visibility within that team.
You can also sometimes find Horizon team regulars hanging out in the
#openstack-horizon channel on the Freenode IRC network if you need
to bounce ideas off someone in a more synch
binding decisions (and expect other TC members feel the same).
--
Jeremy Stanley
signature.asc
Description: Digital signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
oes not work ??
Perhaps not the answer you are looking for, but the metadata service
is far less reliable in most cases than using configdrive metadata
(which recent cloud-init releases should support fine).
--
Jeremy Stanley
signature.asc
Description: Digit
e
is realistic. Do we have a database validation tool now? If we do,
is it deficient in some way? If we don't, what specifically should
it be checking? Seems like something we would also want to run at
the end of all our upgrade tests too.
--
Jeremy Stanley
signature.asc
Description:
grade between
those two LTS releases will _also_ involve in-place upgrading of
Ubuntu.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
mmittee,
> not Thierry Carrez but I could be wrong.)
[...]
I never connected those before, but now I get why he was so keen to
replace the PPB with the TC. ;)
--
Jeremy Stanley
signature.asc
Description: Digital signature
___
OpenStack-operators maili
of service down to the
individual instance being targeted or used rather than knocking the
entire compute node offline (hopefully anyway), and is no substitute
for actual attack mitigation devices/services inline on the network.
--
Jeremy Stanley
signature.
probably helps, but I consider any public cloud which
doesn't give you some means of automatically setting reverse DNS
(either through an API or delegation to your own nameservers) to be
thoroughly broken, at least for Internet-facing use cases.
--
Jeremy Stanley
signature.asc
Description
epended on this
service.
[1] https://review.openstack.org/452086
[2] https://apps.openstack.org/
[3] https://git.openstack.org/cgit/openstack/app-catalog/
--
Jeremy Stanley
signature.asc
Description: Digital signature
___
OpenStack-operators mailing list
will queue at the senders' MTAs
until the server is back in service and so should not result in any
obvious disruption.
Apologies for cross-posting so widely, but we wanted to make sure
copies of this announcement went to most of our higher-traffic
lists.
--
Jeremy Stanley
signatur
messages bound for the server will
queue at the senders' MTAs until the server is back in service and
so should not result in any obvious disruption.
Apologies for cross-posting so widely, but we wanted to make sure
copies of this announcement went to most of our higher-traffic
lists.
--
J
tually
necessary?
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
74).
3. Lots of things, for example facter, like to beat on it heavily
which makes for a fun DDoS and so is a bit of a scaling challenge in
large deployments.
There are probably plenty more I don't know since I'm not steeped in
operating OpenStack deplo
k that you keep in mind that publicly recommending non-free
tools in the service of free software development sets an example.
OpenStack already has a slightly negative reputation as "not really
free" in the wider community... one which we're desperately trying
to overcome, bit by bit.
--
Jeremy Stanley
signature.asc
Description: Digital signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
tterns to follow; so again if you have any details
as to what was lacking in our community workflows and governance,
that might help us understand where to focus on improving so we can
better serve your needs in the future.
--
Jeremy Stanley
signature.asc
Description: Digital signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
ssing a graph for the
/var/lib/elasticsearch filesystem).
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/elasticsearch_node.pp
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailm
cerns or want additional information on
this maintenance.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
ase using our trademarked logo), so that we
hopefully don't need to resort to blocking their MTAs and reporting
them to spam blacklists.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.opens
On 2016-05-20 14:55:31 + (+), Jeremy Stanley wrote:
[...]
> The "users" being defined for AUC include a lot of roles orthogonal
> to software user personas
[...]
I also could have probably better phrased this as what's being
worked out in the context of AUC is not
s: organizers of community user group
meetings, moderators on panels or track chairs at conferences,
members of board-appointed working groups, authors of articles,
people who answer questions in and police online forums... I don't
think the term "user" here is being employed in
On 2016-05-17 16:42:43 + (+), Jeremy Stanley wrote:
> On 2016-05-17 17:30:31 +0100 (+0100), Matt Jarvis wrote:
> > We've noticed that as well, is everyone getting strange bounces from
> > openstack-private ? Any list admins lurking here ?
>
> I have a feeling
On 2016-05-17 16:42:43 + (+), Jeremy Stanley wrote:
> On 2016-05-17 17:30:31 +0100 (+0100), Matt Jarvis wrote:
> > We've noticed that as well, is everyone getting strange bounces from
> > openstack-private ? Any list admins lurking here ?
>
> I have a feeling
in control of, but I guess I'll find out when it
bounces back to my reply.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
sting wiki account and an interest in this topic could volunteer
to help them capture the details there for now.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mail
t https://code.google.com/p/gerrit/issues/list for your
detailed bug report.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
match) are the most common reasons for the error you're
reporting. Also check out https://ask.openstack.org/question/56720
for some additional troubleshooting suggestions.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators
tack.org/question/56720 if you need them.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
cope for the
body governing them, and I don't personally think we should hand the
TC additional jurisdiction outside its present charter.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists
w to get the community better involved in
these events, but making everyone an "ATC" isn't really the solution
to that problem.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
by the conference coordinators on an
event-by-event basis and often does not extend to _all_ official
ATCs (for example, people with contributions in the prior cycle but
not the current cycle are officially ATC but don't get free
admission for that).
--
Jeremy Stanley
___
we band together in a unity of design and function.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
munity" and
welcome to collaborate on maintaining this (or any) resource on
which they depend. It's all a matter of individual priority.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
analysis answering this exact question. See page 22 (labeled 21) of
https://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf
for a very appropriate graph.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack
periods of time. Unfortunately the original poster
cross-posted this thread to multiple mailing lists so the discussion
has rapidly bifurcated, but I addressed this particular topic in my
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078735.html
reply.
--
Jeremy Stanley
___
stable/juno branches themselves deleted, per our usual
EOL process. After which time the Project Infrastructure team will
delete stable/juno CI jobs and dismantle any Juno-specific support
infrastructure (for example, CentOS 6.x workers which were kept to
support contemporary Python 2.6 compatibility
Cross-Project_Meeting
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
registration fees for non-gratis participants:
http://debconf15.debconf.org/registration.xhtml#registration
But basically if you want to go and you or your employer can't/won't
cough up enough € for professional or corporate registration, then
you attend as a private participa
n not to have separate tags like
packaged-in-ubuntu and packaged-in-centos? Of course there's still
some ambiguity over details like "how new is the packaged version?"
and "in what release(s) of the distro?" but those are probably
things you co
... https://wiki.openstack.org/wiki/OSSN/OSSN-0027
--
Jeremy Stanley
signature.asc
Description: Digital signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
am takes care of DevStack itself.
http://governance.openstack.org/reference/projects/quality-assurance.html
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/li
upport. This
blog post is somewhat encouraging:
http://blog.dustinkirkland.com/2013/12/everything-you-need-to-know-about-intel.html
>
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstac
ted per-project
specs) once sufficiently refined for a broader audience?
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
continue publishing something which they knew would get
further and further out of sync with reality.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
On 2014-12-18 01:57:20 + (+), Jeremy Stanley wrote:
[...]
> Anyway, this is just an attempt to level-set and spur the
> discussion onward to actionable solutions rather than continuing
> to debate in the abstract. Hopefully it takes us in a good
> direction.
I meant to ad
be misleading.
Anyway, this is just an attempt to level-set and spur the discussion
onward to actionable solutions rather than continuing to debate in
the abstract. Hopefully it takes us in a good direction.
--
Jeremy Stanley
___
OpenStack-operators
t specifically would be a mark against
Debian's OpenStack packages.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
veloper docs which are auto-built for each
new change merged as well. This would provide a stable location from
which the sample can be referenced without needing to unpack a
tarball or manually rerun the generator.
--
Jeremy Stanley
___
OpenStack-opera
e a great idea--it's basically what the Smokestack CI
was doing to spot early regressions on trunk for Red Hat's RPMs (I
haven't kept up with its status, so not sure if this is still
happening).
--
Jeremy Stanley
___
OpenStack-operator
commend to all projects for future
releases.
[1] https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-b
I've opened a bug[2] for it. Thanks!
[1] https://review.openstack.org/124651
[2] https://launchpad.net/bugs/1394425
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
rkflow for packagers on a
variety of platforms, so any feedback like this is helpful to drive
future improvements on that front.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/c
On 2014-11-15 07:22:32 +1100 (+1100), Roland Chan wrote:
> On 15/11/2014 1:46 am, "Jeremy Stanley" wrote:
> > the truth is that work on these projects is entirely voluntary
> > and we have no effective way to enforce a decree like that.
>
> I don't th
itical and security bug fix backports will be
allowed... *sigh* English... perhaps we SHOULD adopt RFC 2119? ;)
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
see as an unnecessary separation
between "developers" and "operators."
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
ution process. Starting new projects and contributing to
existing ones is meant to be easy, and newcomers to our ranks are
doing it every day. Don't be afraid to shed the divisive mantle of
"operator" or "developer" and just join the action. We're all in it
toge
!). For the moment, our grok rules are
here if it helps anyone:
https://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/templates/logstash/indexer.conf.erb
>
--
Jeremy Stanley
___
OpenStack-operators mailing list
Ope
keep Icehouse
working and testable for the duration. If you feel strongly that
this should happen, please help make that possible in whatever way
you are able.
--
Jeremy Stanley
___
OpenStack-operators mailing list
OpenStack-operators@lists.open
tack is just too raw and buggy. Example: bug in neutron
> (havana) which cause instances to loose networking on reboot was
> fixed year after initial release. And security support was dropped
> right after that release.
This is also a fair criticism, and will only improve with help from
yo
presently working on
the patches to our CI to tear out testing for it, and the
stable/havana branches of all our projects will most likely be
tagged "havana-eol" and deleted some time this week.
--
Jeremy Stanley
___
OpenStack-operators mail
96 matches
Mail list logo
