Thanks for putting this together!
But one feature gap is some means to tag topic submissions, e.g.
tagging the project-specific topics by individual project relevance.
That could be a basis for grouping topics, to allow folks to better
manage their time during the Forum.
(e.g. if someone was
> > We are close to the first milestone in Pike, right ? We also have
> > priorities for Placement that we discussed at the PTG and we never
> > discussed about how to cut placement during the PTG.
> >
> > Also, we haven't discussed yet with operators about how they would like
> > to see Placement
> >> What are these issues? My original message was to highlight one
> >> particular deployment type which is completely independent of
> >> how things get packaged in the traditional sense of the word
> >> (rpms/deb/tar.gz). Perhaps it's getting lost in terminology,
> >> but packaging the
> >> Sylvain and I were talking about how he's going to work placement
> >> microversion requests into his filter scheduler patch [1]. He needs to
> >> make
> >> requests to the placement API with microversion 1.4 [2] or later for
> >> resource provider filtering on specific resource classes like
- Original Message -
>
> > > > >>> I would like to request for some space dedicated to TripleO project
> > > > >>> for the first OpenStack PTG.
> > > > >>>
> > > > >>> https://www.openstack.org/ptg/
> > > > >>>
> > > > >>> The event will happen in February 2017 during the next PTG in
>
> > > >>> I would like to request for some space dedicated to TripleO project
> > > >>> for the first OpenStack PTG.
> > > >>>
> > > >>> https://www.openstack.org/ptg/
> > > >>>
> > > >>> The event will happen in February 2017 during the next PTG in
> > > >>> Atlanta.
> > > >>> Any feedback is
> > > Excerpts from Jaesuk Ahn's message of 2016-10-12 15:08:24 +:
> > >> It can be cheap if you are in the US. However, for Asia folks, it is not
> > >> that cheap considering it is all overseas travel. In addition,
> > >> all-in-one
> > >> event like the current summit makes us much easier
> >>> I would like to request for some space dedicated to TripleO project
> >>> for the first OpenStack PTG.
> >>>
> >>> https://www.openstack.org/ptg/
> >>>
> >>> The event will happen in February 2017 during the next PTG in Atlanta.
> >>> Any feedback is welcome,
> >>
> >> Just a quick note:
> Emilien Macchi wrote:
> > I would like to request for some space dedicated to TripleO project
> > for the first OpenStack PTG.
> >
> > https://www.openstack.org/ptg/
> >
> > The event will happen in February 2017 during the next PTG in Atlanta.
> > Any feedback is welcome,
>
> Just a quick
; what you mean when you are going to the Quay.
> >
> >
> > On 14 July 2016 at 21:35, Neil Jerram <n...@tigera.io
> > <mailto:n...@tigera.io>> wrote:
> >
> > Not sure what the problem would be with 'Quay' or 'Street' - they
>
> >> Hey all!
> >>
> >> The poll emails for the P and Q naming have started to go out - and
> >> we're experiencing some difficulties. Not sure at the moment what's
> >> going on ... but we'll keep working on the issues and get ballots to
> >> everyone as soon as we can.
> >
> > You'll need to
> > Increase the commit requirements, but don't remove the summit pass
> > perk. You'll add a barrier for ATCs and see fewer of them at
> > summits.
>
> The commit counts for the latest TC electorate show 27% had only one
> merged change in Gerrit during the qualifying one year period. It's
>
> >> However, the turnout continues to slide, dipping below 20% for
> >> the first time:
> >
> >Election | Electorate (delta %) | Votes | Turnout (delta %)
> >===
> >Oct '13 | 1106 | 342 | 30.92
> >Apr '14
> > > > Please join me in congratulating the 7 newly elected members of the TC.
> > > >
> > > > << REMOVE UNEEDED >
> > > > * Davanum Srinivas (dims)
> > > > * Flavio Percoco (flaper87)
> > > > * John Garbutt (johnthetubaguy)
> > > > * Matthew Treinish (mtreinish)
> > > > * Mike Perez
> > Please join me in congratulating the 7 newly elected members of the TC.
> >
> > << REMOVE UNEEDED >
> > * Davanum Srinivas (dims)
> > * Flavio Percoco (flaper87)
> > * John Garbutt (johnthetubaguy)
> > * Matthew Treinish (mtreinish)
> > * Mike Perez (thingee)
> > * Morgan Fainberg
> Please join me in congratulating the 7 newly elected members of the TC.
>
> << REMOVE UNEEDED >
> * Davanum Srinivas (dims)
> * Flavio Percoco (flaper87)
> * John Garbutt (johnthetubaguy)
> * Matthew Treinish (mtreinish)
> * Mike Perez (thingee)
> * Morgan Fainberg
> Hi all,
>
> Thanks for all the fish. But it's time for me to move over and let some
> new voices contribute to the OpenStack Technical Committee.
>
> I will continue to be a proponent for the viewpoint that OpenStack
> should be considered a toolkit of small, focused services and utilities,
> > Current thinking would be to give preferential rates to access the main
> > summit to people who are present to other events (like this new
> > separated contributors-oriented event, or Ops midcycle(s)). That would
> > allow for a wider definition of "active community member"
> >>> Current thinking would be to give preferential rates to access the main
> >>> summit to people who are present to other events (like this new
> >>> separated contributors-oriented event, or Ops midcycle(s)). That would
> >>> allow for a wider definition of "active community member" and
> > Current thinking would be to give preferential rates to access the main
> > summit to people who are present to other events (like this new
> > separated contributors-oriented event, or Ops midcycle(s)). That would
> > allow for a wider definition of "active community member" and reduce
> >
> Hi everyone,
>
> TL;DR: Let's split the events, starting after Barcelona.
>
> Long long version:
>
> In a global and virtual community, high-bandwidth face-to-face time is
> essential. This is why we made the OpenStack Design Summits an integral
> part of our processes from day 0. Those
> > Honestly I don't know of any communication between two cores at a +2
> > party that couldn't have just as easily happened surrounded by other
> > contributors. Nor, I hope, does anyone put in the substantial
> > reviewing effort required to become a core in order to score a few
> > free
> > [...]
> > * much of the problem with the lavish parties is IMO related to the
> > *exclusivity* of certain shindigs, as opposed to devs socializing at
> > summit being inappropriate per se. In that vein, I think the cores
> > party sends the wrong message and has run its
> Hello all,
>
> tl;dr
> =
>
> I have long thought that the OpenStack Summits have become too
> commercial and provide little value to the software engineers
> contributing to OpenStack.
>
> I propose the following:
>
> 1) Separate the design summits from the conferences
> 2) Hold only a
> > For the cores party, much as I enjoyed the First Nation cuisine in
> > Vancouver
> > or the performance art in Tokyo, IMO it's probably time to draw a line
> > under
> > that excess also, as it too projects a notion of exclusivity that runs
> > counter
> > to building a community.
>
> ...
> > > > [...]
> > > > * much of the problem with the lavish parties is IMO related to
> > > > the
> > > > *exclusivity* of certain shindigs, as opposed to devs
> > > > socializing at
> > > > summit being inappropriate per se. In that vein, I think the
> > > > cores
> > > > party
> Hi
>
> Can anyone plz help me on how to specify a simple query with multiple values
> for a query field in a Ceilometer meter-list request? I need to fetch meters
> that belongs to more than one project id. I have tried the following query
> format, but only the last query value (in this
I think removing options from the API requires version bump. So if we
plan to do this, that should be introduced in v3 as opposed to v2,
which should remain the same and maintained for two cycles (assuming
that we still have this policy in OpenStack). It this is achievable by
Hi all,
we have a problem with dependencies for the kilo-rc1 release of Heat - see
bug [1]. Root cause is ceilometerclient was not updated for a long time and
just got an update recently. We are sure that Heat in Kilo would not work
with ceilometerclient =1.0.12 (users would not be able
Pavlo Shchelokovskyy wrote:
unfortunately, in Heat we do not have yet integration tests for all the
Heat resources (creating them in real OpenStack), and Ceilometer alarms
are in those not covered. In unit tests the real client is of course
mocked out. When we stumbled on this issue
Hi Folks,
Just a quick note to say that I won't be running again for
ceilometer PTL over the liberty cycle.
I've taken on a new role internally that won't realistically
allow me the time that the PTL role deserves. But y'all haven't
seen the last of me, I'll be sticking around as a contributor,
I tracked down the cause of the check-grenade-dsvm failure on
https://review.openstack.org/#/c/167370 . As I understand it, grenade is
taking the previous stable release, deploying it, then upgrading to the
current master (plus the proposed changeset) without changing any of the
config from
After some discussion with Sean Dague and a few others it became
clear that it would be a good idea to introduce a new tool I've been
working on to the list to get a sense of its usefulness generally,
work towards getting it into global requirements, and get the
documentation fleshed out so
From: Sandy Walsh [sandy.wa...@rackspace.com] Monday, December 01, 2014 9:29
AM
From: Duncan Thomas [duncan.tho...@gmail.com]
Sent: Sunday, November 30, 2014 5:40 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Where should Schema files live?
Duncan Thomas
On
Toews everett.to...@rackspace.com
wrote:
On Nov 20, 2014, at 4:06 PM, Eoghan Glynn egl...@redhat.com wrote:
How about allowing the caller to specify what level of detail
they require via the Accept header?
▶ GET /prefix/resource_name
Accept: application/json; detail
I think Doug's suggestion of keeping the schema files in-tree and pushing
them to a well-known tarball maker in a build step is best so far.
It's still a little clunky, but not as clunky as having to sync two repos.
Yes, I tend to agree.
So just to confirm that my understanding lines up:
Right, agreed. This has always been an open meeting.
Yes of course, as I said up-thread.
This is a central plank of our 4 Opens principle[1], which should
apply across the board to all community meetings related to the
OpenStack project.
All project meetings are held in public IRC channels
Why wouldn’t they live in the repo of the application that generates the
notification, like we do with the database schema and APIs defined by
those apps?
That would mean downstream consumers (potentially in different languages)
would need to pull all repos and extract just the
Some problems / options:
a. Unlike Python, there is no simple pip install for text files. No
version control per se. Basically whatever we pull from the repo. The
problem with a git clone is we need to tweak config files to point to a
directory and that's a pain for gating tests and
Hi everyone,
TL;DR:
I propose we turn the weekly project/release meeting timeslot
(Tuesdays at 21:00 UTC) into a weekly cross-project meeting, to
discuss cross-project topics with all the project leadership, rather
than keep it release-specific.
Long version:
Since the dawn of
Thanks for raising this Sandy,
Some questions/observations inline.
Hey y'all,
To avoid cross-posting, please inform your -infra / -operations buddies about
this post.
We've just started thinking about where notification schema files should live
and how they should be deployed. Kind
Aloha guardians of the API!
I haven recently* reviewed a spec for neutron [1] proposing a distinct URI
for returning resource count on list operations.
This proposal is for selected neutron resources, but I believe the topic is
general enough to require a guideline for the API working
1. *make a minor concession to proportionality* - while keeping the
focus on consensus, e.g. by adopting the proportional Condorcet
variant.
It would be interesting to see the analysis again, but in the past this
proved to not make much difference.
For the record, I
It's certainly not a fun thing to do (trying to guide a
community of disjoint folks) and it likely comes with little
recognition when successful, but IMHO we surely need more of
this active technical leadership vs. blessing of projects; of
course the boundary between being a engaging
I think you missed the most important option I mentioned in the thread -
for
the TC to engage more with the community and take an active technical
leadership role in the design of OpenStack as a whole.
+1
I've been in this scene for about half a year now and the only
reason I
So, just to round out this thread, the key questions are:
* whether a low declining turnout is a real problem
and, if so:
* could this have been driven by a weakness in the voting model,
and/or the perception of representative balance in the outcomes
The options that
+1 to this, with a term limit.
Notable that the Debian TC has been discussing term limits for
months now, and since DebConf they seem to have gotten much closer
to a concrete proposal[1] in the last week or so. Could be worth
watching for ideas on how our community might attempt to
So, just to round out this thread, the key questions are:
* whether a low declining turnout is a real problem
I'd like to point out that there 580 'regular' contributors at the
moment[1], these are the authors of 95% of the OpenStack code. 506 total
number of voters.
Thanks Stef,
IIRC, there is no method for removing foundation members. So there
are likely a number of people listed who have moved on to other
activities and are no longer involved with OpenStack. I'd actually
be quite interested to see the turnout numbers with voters who
missed the last two
IIRC, there is no method for removing foundation members. So there
are likely a number of people listed who have moved on to other
activities and are no longer involved with OpenStack. I'd actually
be quite interested to see the turnout numbers with voters who
missed the last two
IIRC, there is no method for removing foundation members. So there
are likely a number of people listed who have moved on to other
activities and are no longer involved with OpenStack. I'd actually
be quite interested to see the turnout numbers with voters who
missed the last two
IIRC, there is no method for removing foundation members. So there
are likely a number of people listed who have moved on to other
activities and are no longer involved with OpenStack. I'd actually
be quite interested to see the turnout numbers with voters who
missed the last two
Hi everyone,
Before we start the larger discussion at summit next week about the future of
testing in OpenStack - specifically about spinning up functional testing and
how
it relates to tempest - I would like to share some of my thoughts on how we
can
get things started and how I think
If we're serious about improving participation rates, then I think we
should consider factors what would tend to drive interest levels and
excitement around election time. My own suspicion is that open races
where the outcome is in doubt are more likely to garner attention from
voters,
Matthew wrote:
This would have the advantage of making tempest slimmer for every project
and begin the process of getting projects to take responsibility for their
functional testing rather than relying on tempest.
[much snipping]
Sean wrote:
Ok, so part of this remains to be seen about
This is already on the agenda proposed by the board (as well as a quick
presentation on the need for structural reform in the ways we handle
projects in OpenStack).
Would it be possible for the slidedeck and a quick summary of that
presentation to be posted to the os-dev list after the
The low (and dropping) level of turnout is worrying, particularly in
light of that analysis showing the proportion of drive-by contributors
is relatively static, but it is always going to be hard to discern the
motives of people who didn't vote from the single bit of data we have on
them.
voters (4.15%) preferred Russell Bryant Eoghan Glynn (RHAT/RHAT)
16 voters (3.16%) preferred Doug Hellmann Sean Dague(HP/HP)
Conclusion
==
The rate of potentially partisan voting didn't diverge significantly
from the norms we've seen in previous elections.
The continuing decline
On Oct 29, 2014, at 3:32 PM, Eoghan Glynn egl...@redhat.com wrote:
Folks,
I haven't seen the customary number-crunching on the recent TC election,
so I quickly ran the numbers myself.
Voter Turnout
=
The turnout rate continues to decline, in this case
Folks,
Just a quick reminder that we'll be considering the summit design
sessions proposals[1] at the weekly meeting today at 1500UTC.
We'll start the process of collaborative scheduling of topics with
each session proposer giving a short pitch for inclusion.
We've got 15 proposals already,
Folks,
I would like to throw my hat into the ring for the upcoming Technical
Committee election.
I've been involved in the OpenStack community for nearly three years,
starting off by becoming core on glance, before moving my focus mainly
onto the ceilometer project. Along the way I've landed a
So a bit of background here. This began from thinking about functional
dependencies, and pondering whether a map of the dependency graph of
our projects could inform our gating structure, specifically to
encourage (or dare I say, actually force) all of us (the project
teams) to become
As promised at this week’s TC meeting, I have applied the various blog posts
and mailing list threads related to changing our governance model to a
series of patches against the openstack/governance repository [1].
I have tried to include all of the inputs, as well as my own opinions, and
- Original Message -
On Fri, Oct 3, 2014 at 6:07 AM, Doug Hellmann d...@doughellmann.com
wrote:
On Oct 3, 2014, at 12:46 AM, Joe Gordon joe.gord...@gmail.com wrote:
On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen
devananda@gmail.com wrote:
So a bit of background here. This began from thinking about functional
dependencies, and pondering whether a map of the dependency graph of
our projects could inform our gating structure, specifically to
encourage (or dare I say, actually force) all of us (the project
teams) to become more
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
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
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
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
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
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.
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
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
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.
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.
OK, so
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
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
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
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
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
1 - 100 of 175 matches
Mail list logo
