Multidisciplinary training rules! As an architect with field experience
building roads, sidewalks, roofs, city planning (and training in lean
manufacturing and services) I think I can have a say ;)
You're not really introducing a successful Kanban here, you're just
clarifying that there
If we try to limit the number of WIP slots, then surely aspiring
contributors will simply work around that restriction by preparing
the code they're interested in on their own private branches, or
in their github forks?
OK, some pragmatic contributors will adjust their priorities to
Dear All,
Let me use my first post to this list to introduce Cyclops and initiate a
discussion towards possibility of this platform as a future incubated
project in OpenStack.
We at Zurich university of Applied Sciences have a python project in open
source (Apache 2 Licensing) that
On 08/07/2014 01:41 PM, Eoghan Glynn wrote:
My point was simply that we don't have direct control over the
contributors' activities
This is not correct and I've seen it repeated too often to let it go
uncorrected: we (the OpenStack project as a whole) have a lot of control
over
We seem to be unable to address some key issues in the software we
produce, and part of it is due to strategic contributors (and core
reviewers) being overwhelmed just trying to stay afloat of what's
happening. For such projects, is it time for a pause ? Is it time to
define key cycle
Hi Folks,
Dina Belova has recently landed some infra patches[1,2] to create
an experimental mongodb-based Tempest job. This effectively just
overrides the ceilometer storage backend config so that mongodb
is used instead of sql-alchemy. The new job has been running
happily for a
, Eoghan Glynn egl...@redhat.com wrote:
Hi Folks,
Dina Belova has recently landed some infra patches[1,2] to create
an experimental mongodb-based Tempest job. This effectively just
overrides the ceilometer storage backend config so that mongodb
is used instead of sql-alchemy. The new job
+2 from me,
More mongodb adoption (as stated) when it's questionable legally doesn't seem
like a good long term strategy (I know it will/does impact yahoo adopting or
using ceilometer...). Is this another one of those tactical changes that we
keep on making that ends up being yet another
-ballpark performance characteristics to mongodb.
Cheers,
Eoghan
Just my 2cents.
Sent from my really tiny device...
On Aug 9, 2014, at 10:53 AM, Eoghan Glynn egl...@redhat.com wrote:
+2 from me,
More mongodb adoption (as stated) when it's questionable legally doesn't
seem
concrete progress on that score.
I hope that provides enough detail to answer to your question?
Cheers,
Eoghan
Thanks,
Brad
Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet: bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680
From: Eoghan
On 8/11/2014 4:22 PM, Eoghan Glynn wrote:
Hi Eoghan,
Thanks for the note below. However, one thing the overview below does not
cover is why InfluxDB ( http://influxdb.com/ ) is not being leveraged.
Many
folks feel that this technology is a viable solution for the problem space
On 8/11/2014 4:22 PM, Eoghan Glynn wrote:
Hi Eoghan,
Thanks for the note below. However, one thing the overview below does
not
cover is why InfluxDB ( http://influxdb.com/ ) is not being leveraged.
Many
folks feel that this technology is a viable solution for the problem
space
Ignoring the question of is it ok to say: 'to run ceilometer in any sort of
non-trivial deployment you must manager yet another underlying service,
mongodb' I would prefer not adding an addition gate variant to all projects.
With the effort to reduce the number of gate variants we have [0] I
So would we:
(a) add a new integrated-gate-ceilometer project-template to [1],
in the style of integrated-gate-neutron or integrated-gate-sahara,
which would replicate the main integrated-gate template but with
the addition of
Doesn't InfluxDB do the same?
InfluxDB stores timeseries data primarily.
Gnocchi in intended to store strongly-typed OpenStack resource
representations (instance, images, etc.) in addition to providing
a means to access timeseries data associated with those resources.
So to
It seems like this is exactly what the slots give us, though. The core review
team picks a number of slots indicating how much work they think they can
actually do (less than the available number of blueprints), and then
blueprints queue up to get a slot based on priorities and turnaround
One thing I'm not seeing shine through in this discussion of slots is
whether any notion of individual cores, or small subsets of the core
team with aligned interests, can champion blueprints that they have
a particular interest in.
I think that's because we've focussed in this
It seems like this is exactly what the slots give us, though. The core
review
team picks a number of slots indicating how much work they think they can
actually do (less than the available number of blueprints), and then
blueprints queue up to get a slot based on priorities and
At the end of the day, that's probably going to mean saying No to more
things. Everytime I turn around everyone wants the TC to say No to
things, just not to their particular thing. :) Which is human nature.
But I think if we don't start saying No to more things we're going to
end up
Divert all cross project efforts from the following projects so we can
focus
our cross project resources. Once we are in a bitter place we can expand
our
cross project resources to cover these again. This doesn't mean removing
anything.
* Sahara
* Trove
* Tripleo
You write
Additional cross-project resources can be ponied up by the large
contributor companies, and existing cross-project resources are not
necessarily divertable on command.
Sure additional cross-project resources can and need to be ponied up, but I
am doubtful that will be enough.
OK, so
But, if someone asked me what they should use for metering today,
I'd point them towards Monasca in a heartbeat.
FWIW my view is that Monasca is an interesting emerging project, with a
team accreting around it that seems to be interested in collaboration.
We've had ongoing discussions with
Additional cross-project resources can be ponied up by the large
contributor companies, and existing cross-project resources are not
necessarily divertable on command.
Sure additional cross-project resources can and need to be ponied up, but I
am doubtful that will be enough.
One of the outcomes from Juno will be horizontal scalability in the
central agent and alarm evaluator via partitioning[1]. The compute
agent will get the same capability if you choose to use it, but it
doesn't make quite as much sense.
I haven't investigated the alarm evaluator side
On 09/02/2014 11:33 PM, Robert Collins wrote:
The implementation in ceilometer is very different to the Ironic one -
are you saying the test you linked fails with Ironic, or that it fails
with the ceilometer code today?
Disclaimer: in Ironic terms, node = conductor, key = host
The
The implementation in ceilometer is very different to the Ironic one -
are you saying the test you linked fails with Ironic, or that it fails
with the ceilometer code today?
Disclaimer: in Ironic terms, node = conductor, key = host
The test I linked fails with Ironic hash ring
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time).
Am I missing some compelling advantage of moving all these emergent
project-specific meetups to the Friday?
One is that due to space limitations, we won't have nearly as many
pods as in Atlanta (more like half or a third of them). Without one
pod per program, the model breaks a bit.
Hi,
Nejc has been doing a great work and has been very helpful during the
Juno cycle and his help is very valuable.
I'd like to propose that we add Nejc Saje to the ceilometer-core group.
Please, dear ceilometer-core members, reply with your votes!
A hearty +1 for me, Nejc has made a
As you all know, there has recently been several very active discussions
around how to improve assorted aspects of our development process. One idea
that was brought up is to come up with a list of cycle goals/project
priorities for Kilo [0].
To that end, I would like to propose an
Hi,
Dina has been doing a great work and has been very helpful during the
Juno cycle and her help is very valuable. She's been doing a lot of
reviews and has been very active in our community.
I'd like to propose that we add Dina Belova to the ceilometer-core
group, as I'm convinced
I visited the Paris Design Summit space on Monday and confirmed that it
should be possible to split it in a way that would allow to have
per-program contributors meetups on the Friday. The schedule would go
as follows:
Tuesday: cross-project workshops
Wednesday, Thursday: traditional
Thanks for bring this to the list, Flavio.
A few thoughts in line ...
Greetings,
As probably many of you already know, Zaqar (formerly known as Marconi)
has recently been evaluated for integration. This is the second time
this project (and team) has gone through this process and just like
Hi,
Nejc has been doing a great work and has been very helpful during the
Juno cycle and his help is very valuable.
I'd like to propose that we add Nejc Saje to the ceilometer-core group.
Please, dear ceilometer-core members, reply with your votes!
With eight yeas and zero nays, I
Hi,
Dina has been doing a great work and has been very helpful during the
Juno cycle and her help is very valuable. She's been doing a lot of
reviews and has been very active in our community.
I'd like to propose that we add Dina Belova to the ceilometer-core
group, as I'm convinced
Hi All,
My understanding of Zaqar is that it's like SQS. SQS uses distributed queues,
which have a few unusual properties [0]:
Message Order
Amazon SQS makes a best effort to preserve order in messages, but due to the
distributed nature of the queue, we cannot guarantee you will
Folks,
I'd like to continue serving as Telemetry PTL for a second cycle.
When I took on the role for Juno, I saw some challenges facing the
project that would take multi-cycle efforts to resolve, so I'd like to
have the opportunity to see that move closer to completion.
Over Juno, our focus as
The ceilometer team released python-ceilometerclient vesion 1.0.11 yesterday:
https://pypi.python.org/pypi/python-ceilometerclient/1.0.11
Cheers,
Eoghan
Keystone team has released 0.11.1 of python-keystoneclient. Due to some
delays getting things through the gate this took a few extra
Thanks Thierry,
For completeness, the ceilometer links are below.
tarball:
http://tarballs.openstack.org/ceilometer/ceilometer-milestone-proposed.tar.gz
milestone-proposed branch:
https://github.com/openstack/ceilometer/tree/milestone-proposed
Cheers,
Eoghan
- Original Message -
Folks,
Time for some new blood on the ceilometer core team.
I'd like to nominate Ildikó Váncsa and Nadya Privalova as ceilometer
cores in recognition of their contributions([1], [2]) over the Icehouse
cycle, and looking forward to their continued participation for Juno.
Both showed up with
Hi,
Right now Ironic is being responsible for storing the credentials for the
IPMI and SSH drivers (and potentially other drivers in the future), I wonder
if we should delegate this task to Keystone. The Keystone V3 API now has a
/credentials endpoint which would allow us to specify
On 3/25/2014 1:50 PM, Matt Wagner wrote:
This would argue to me that the easiest thing for Ceilometer might be
to query us for IPMI stats, if the credential store is pluggable.
Fetch these bare metal statistics doesn't seem too off-course for
Ironic to me. The alternative is that
- Original Message -
On 27 March 2014 06:28, Eoghan Glynn egl...@redhat.com wrote:
On 3/25/2014 1:50 PM, Matt Wagner wrote:
This would argue to me that the easiest thing for Ceilometer might be
to query us for IPMI stats, if the credential store is pluggable.
Fetch
Collins robe...@robertcollins.net
wrote:
On 27 March 2014 06:28, Eoghan Glynn egl...@redhat.com wrote:
On 3/25/2014 1:50 PM, Matt Wagner wrote:
This would argue to me that the easiest thing for Ceilometer might be
to query us for IPMI stats, if the credential store
Hi Folks,
I would like to throw my hat into the ring for the upcoming ceilometer
PTL election.
Over the past three release cycles, I've become increasingly focused
on Telemetry in OpenStack, and feel at this stage that I'm in a
position to make a positive impact on the project as PTL.
We've
Sphoorti,
Just copying the list with some pointers on this issue that
I gave you on IRC.
Running 'neutron router-update' show that the tenant ID is absent
from the 'router.update.start' but present in the 'router.update.end'
notification.
Note that the logic to send the update.start
On 11/10/2013 11:53 PM, John Dickinson wrote:
A random off-the-top-of-my-head use case would be to subscribe to
events from creating or changing objects in a particular Swift
account or container. This would allow much more efficient listings
in Horizon for active containers (and may
Hello, guys!
I hope everybody has eventually got home after the summit and feeling ok :)
So it's time to proceed thinking about integration, unit and performance
testing in Ceilometer. First of all I'd like to appreciate your help in
composing etherpad
Hi Nejc,
Apologies for the delay in responding, I'm just getting to grips with
Tempest myself.
So the problem here is nothing to do with whether the tenant
exists in keystone, in fact creating an alarm with a completely
fictitious project_id will work just fine in general.
Rather it appears to
- Original Message -
On 12/02/2013 10:24 AM, Julien Danjou wrote:
On Fri, Nov 29 2013, David Kranz wrote:
In preparing to fail builds with log errors I have been trying to make
things easier for projects by maintaining a whitelist. But these bugs in
ceilometer are coming in so
Thanks for bringing this to the list Matt, comments inline ...
tl;dr: some pervasive changes were made to nova to enable polling in
ceilometer which broke some things and in my opinion shouldn't have been
merged as a bug fix but rather should have been a blueprint.
===
The
On 6/12/2014 10:31 AM, John Garbutt wrote:
On 11 June 2014 20:07, Joe Gordon joe.gord...@gmail.com wrote:
On Wed, Jun 11, 2014 at 11:38 AM, Matt Riedemann
mrie...@linux.vnet.ibm.com wrote:
On 6/11/2014 10:01 AM, Eoghan Glynn wrote:
Thanks for bringing this to the list Matt, comments
- Original Message -
On 11 June 2014 20:07, Joe Gordon joe.gord...@gmail.com wrote:
On Wed, Jun 11, 2014 at 11:38 AM, Matt Riedemann
mrie...@linux.vnet.ibm.com wrote:
On 6/11/2014 10:01 AM, Eoghan Glynn wrote:
Thanks for bringing this to the list Matt, comments inline ...
tl
On Thu Jun 12 14:13:05 2014, Chris Friesen wrote:
Hi,
I'm looking for the community viewpoint on whether there is any chance
of license contamination between mysql and nova. I realize that
lawyers would need to be involved for a proper ruling, but I'm curious
about the view of the
TL;DR: how about we adopt a soft enforcement model, relying
on sound judgement and good faith within the community?
Hi Folks,
I'm concerned that the expected election behaviour review[1]
is not converging on the optimal approach, partially due to the
initial concentration on the
Hello guys,
I was taking a look at the proposed alarm-page designs [1] for the bp:
https://blueprints.launchpad.net/horizon/+spec/ceilometer-alarm-management-page
and I saw that the alarms table has a column named “Resource Name”. The
intention of that column is to show the resources
On Mon, 2014-06-16 at 10:56 +0100, Daniel P. Berrange wrote:
On Mon, Jun 16, 2014 at 05:04:51AM -0400, Eoghan Glynn wrote:
How about we rely instead on the values and attributes that
actually make our community strong?
Specifically: maturity, honesty, and a self-correcting nature
and will send a fresh link out when done.
Anyone else with feedback, please feel free to fire away.
Best,
Liz
On Jun 4, 2014, at 12:33 PM, Eoghan Glynn egl...@redhat.com wrote:
Hi Liz,
Two further thoughts occurred to me after hitting send on
my previous mail.
First
On Jun 16, 2014, at 10:56 AM, Eoghan Glynn egl...@redhat.com wrote:
Apologies for the top-posting, but just wanted to call out some
potential confusion that arose on the #os-ceilometer channel earlier
today.
TL;DR: the UI shouldn't assume a 1:1 mapping between alarms
Folks,
A question for the taskflow ninjas.
Any thoughts on best practice WRT $subject?
Specifically I have in mind this ceilometer review[1] which adopts
the approach of using very fine-grained tasks (at the level of an
individual alarm evaluation) combined with short-term assignments
to
@lists.openstack.org
Date: Tuesday, June 17, 2014 at 5:33 AM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [taskflow] Recommendations for the
granularity of tasks and their stickiness to workers
On 6/17/2014 7:04 AM, Eoghan
James E. Blair wrote:
I think our recent experience has shown that the fundamental problem is
that not all of the members of our community knew what kind of behavior
we expected around elections. That's understandable -- we had hardly
articulated it. I think the best solution to that
Hi Swiftsters!
A basic question about swift eventual- versus strong-consistency.
The context is potentially using swift as a store for metric data.
Say datapoints {p1, p2, ..., p_i} are stored in a swift object.
Presumably these data are replicated across the object ring in
an eventually
Looks like many are in Paris midcycle meet-up. Do we have the weekly IRC
meeting today?
Hi Lianhao,
We'll do a very short meeeting just to review juno-2 status, and remind
folks about the upcoming spec deadlines for Juno. Shouldn't take more
than a few minutes.
Cheers,
Eoghan
This is an attempt to summarize a really useful discussion that Victor,
Flavio and I have been having today. At the bottom are some background
links - basically what I have open in my browser right now thinking
through all of this.
Thanks for the detailed summary, it puts a more flesh on
In current Alarm implementation, Ceilometer will send back Heat an
'alarm' using the pre-signed URL (or other channel under development).
By the other channel, do you mean the trusts-based interaction?
We discussed this at the mid-cycle in Paris last week, and it turns out
there appear to be
Alarms in ceilometer may currently only be based on a statistics trend
crossing a threshold, and not on the occurrence of an event such as
compute.instance.delete.end.
Right. I realized this after spending some more time understanding the
alarm-evaluator code. Having 'Statistics'
TL;DR: branchless Tempest shouldn't impact on backporting policy, yet
makes it difficult to test new features not discoverable via APIs
Folks,
At the project/release status meeting yesterday[1], I raised the issue
that featureful backports to stable are beginning to show up[2], purely
to
Thanks for the response Matt, some comments inline.
At the project/release status meeting yesterday[1], I raised the issue
that featureful backports to stable are beginning to show up[2], purely
to facilitate branchless Tempest. We had a useful exchange of views on
IRC but ran out of
tomorrow. I'll circle back with a more
complete response after that.
Cheers,
Eoghan
-Sean
On 07/09/2014 05:41 AM, Eoghan Glynn wrote:
TL;DR: branchless Tempest shouldn't impact on backporting policy, yet
makes it difficult to test new features not discoverable via APIs
TL;DR: do we need to stabilize notifications behind a versioned
and discoverable contract?
Folks,
One of the issues that has been raised in the recent discussions with
the QA team about branchless Tempest relates to some legacy defects
in the OpenStack notification system.
Now, I don't
Note that the notifications that capture these resource state transitions
are a long-standing mechanism in openstack that ceilometer has depended
on from the very outset. I don't think it's realistic to envisage these
interactions will be replaced by REST APIs any time soon.
I wasn't
It's not clear to me in this discussion what it is that is being
versioned, contracted or standardized.
Well the statement in the original mail was pretty explicit:
versioned notification payloads to protect consumers from breaking
changes in payload format
So it's the standardization of
One of the issues that has been raised in the recent discussions with
the QA team about branchless Tempest relates to some legacy defects
in the OpenStack notification system.
Got links to specifics? I thought the consensus was that there was a
contract here which we need to maintain,
thinking discoverablity of the more
downstream thing (the gathering of certain meters in ceilometer's case)
would be far more meaningful to reason over.
Cheers,
Eoghan
On Jul 10, 2014, at 2:48 AM, Eoghan Glynn egl...@redhat.com wrote:
TL;DR: do we need to stabilize notifications behind
The original implementation of the notification system was never intended
to be the *final* implementation. I think we all identified the need for
versioning several years ago. As for backwards compatibility, I think the
version field itself, in whatever form it takes, should be optional. If
tl;dr: Having a minimum payload standard enables more and more robust
services on both sides of notification bus.
Yes, that's exactly the point of this thread.
We do not have a standard format for the payload. I think we should
(more on that below).
Again, such standardization is exactly
But I guess you're suggesting not only that we version/schematize
individual notification payloads, but that we do so in a way that's
global across event types and emitters?
That's partially correct. I'm suggesting the we consider standardizing a
general format for notification
So I'm not sure that this should be a mandatory thing, but an
opt-in. My real concern is the manpower, who is going to take the
time to write all the test suites for all of the projects. I think
it would be better to add that on-demand as the extra testing is
required. That being said, I
So what we need to figure out is how exactly this common structure can be
accommodated without reverting back to what Sandy called the wild west
in another post.
I got the impression that wild west is what we've already got
(within the payload)?
Yeah, exactly, that was my
Sean Dague wrote:
To be clear, the functional tests will not be Tempest tests. This is a
different class of testing, it's really another tox target that needs a
devstack to run. A really good initial transition would be things like
the CLI testing.
Also, the Tempest team has gone out
Swift is already emitting those numbers[1] in statsd format; could
ceilometer consume those metrics and convert them to whatever
notification format it uses?
The problem with that approach, IIUC, is that the statsd metrics
provide insufficient context.
Ceilometer wants to meter usage on a
As a curiosity, are there any ballpark numbers around the volume of
notifications ceilometers can handle? Thinking about large scale swift
deployments I expect to see thousands or even 10s of thousands of events per
second. And that's with today's technology. Looking longer term I
Disclaimer: I'm not fully vested on ceilometer internals, so bear with me.
For consumers wanting to leverage ceilometer as a telemetry service atop
non-OpenStack Clouds or infrastructure they don't own, some edge cases
crop up. Most notably the consumer may not have access to the
wrong :)
Best regards!
Kurt
-邮件原件-
发件人: Eoghan Glynn [mailto:egl...@redhat.com]
发送时间: 2014年8月1日 14:46
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [ceilometer] Compute agent local VM inspector -
potential enhancement
Folks,
It's come to our attention that some key individuals are not
fully up-to-date on gnocchi activities, so it being a good and
healthy thing to ensure we're as communicative as possible about
our roadmap, I've provided a high-level overview here of our
thinking. This is intended as a
Hi everyone,
With the incredible growth of OpenStack, our development community is
facing complex challenges. How we handle those might determine the
ultimate success or failure of OpenStack.
With this cycle we hit new limits in our processes, tools and cultural
setup. This resulted in
- Original Message -
Hey everyone!
I’d like to get your gut reaction on an idea for the future of alarming.
Should I or should I not put it up for debate at the design summit?
Hi Nejc,
Yes this is certainly worthy of discussion at the design summit.
Because the algorithms being
Hi Folks,
Since our French, Hungarian, Chinese, Russian and Slovenian contributors
(geo-diversity WTF!) will all be celebrating International Workers' Day
on May 1st, let's skip the weekly meeting.
If anything pressing comes up, let's just have an emergent discussion to
deal with it on
Hi Folks,
Since our French, Hungarian, Chinese, Russian and Slovenian contributors
(geo-diversity WTF!) will all be celebrating International Workers' Day
A dyslexic moment: I meant geo-diversity FTW! :)
on May 1st, let's skip the weekly meeting.
If anything pressing comes up, let's
... the $subject says it all.
Wondering about dedicated spaces for a cores meet-up prior
to the design summit proper kicking off on the Tuesday.
Thanks!
Eoghan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
IIRC Thierry said that pods will be available starting from Monday.
Thanks Sergey, in the absence of any other indications to the
contrary, I'm gonna assume that's the case :)
Cheers,
Eoghan
On Tue, Apr 29, 2014 at 2:56 PM, Eoghan Glynn egl...@redhat.com wrote:
... the $subject says
Hi Alexandre,
I wanted to let this discussion develop a little before jumping in, as
we've already had many circular debates about the cross-over between
ceilometer and monitoring infrastructure in general.
Personally I'm in favor of the big tent/broad church interpretation of
ceilometer's
One of the things that OpenStack does really well is review our process
for various activities. I don't believe we have had a discussion in the
past reviewing our electoral process and I think it would be good to
have this discussion.
There are two issues that I feel need to be addressed:
Hi Ceilometer folks,
Just in case you weren't following the thread on *-specs repos
being renamed from {project}-specs - {program}-specs[1] ...
Note that there was a change of heart once the feedback from
the community indicated some concerns about the discoverability
of repos named for the
- Original Message -
Hello Stackers,
Disclaimer: I'm on a quest to develop a new agent, already have coding a few
lines. The next step is Unit Testing and enabling me to create a patch to
test on a devstack. So, this is what brings me here, the need to understand
and learn the
Alex reported the bug against setuptools
(https://bitbucket.org/pypa/setuptools/issue/213/regression-setuptools-37-installation)
if you want to track progress.
Thanks Doug,
In the meantime, I'm wondering do we have any way of insulating
ourselves against breakages like this?
(along the
Comments inline ...
Hi Liz,
The designs look really cool and I think that we should consider a couple of
things (more related to the alarm’s implementation made at Ceilometer):
· There are combined alarms, which are a combination of two or more alarms.
We need to see how they work and
Hi Liz,
Two further thoughts occurred to me after hitting send on
my previous mail.
First, is the concept of alarm dimensioning; see my RDO Ceilometer
getting started guide[1] for an explanation of that notion.
A key associated concept is the notion of dimensioning which defines the set
of
So there are certain words that mean certain things, most don't, some do.
If words that mean certain things are used then some folks start using
the word and have expectations around the word and the OpenStack
Technical Committee and other OpenStack programs find themselves on the
hook
1 - 100 of 175 matches
Mail list logo
