Support sort and pagination together will be the biggest challenge: it's up to
how many cells will be involved in the query, 3,5 may be OK, you can search
each cells, and cached data. But how about 20, 50 or more, and how many data
will be cached?
More over, during the query there are instances
On Thu, May 18 2017, aalvarez wrote:
> Yes but doesn't Pecan allow to use a development server (pecan serve) that
> can accept interface and port options? I thought this would be the
> test/development server Gnocchi would use.
We could but there's no need and it's just one line to rely on pbr's
On Fri, May 19, 2017 at 10:54 AM, Vikash Kumar <
vikash.ku...@oneconvergence.com> wrote:
> Hi Team,
>
>Are we planning for Heat support for FWAASV2 ? I see its missing.
>
> --
> Regards,
> Vikash
>
--
Regards,
Vikash
_
We'll miss you Steve.:(
Amy (spotz)
Sent from my iPhone
> On May 18, 2017, at 8:55 PM, Steve Lewis wrote:
>
> It is clear to me now that I won't be able to work on OpenStack as a part of
> my next day job, wherever that ends up being. As such, I’ll no longer be able
> to invest the time and
Hi Greg,
Please include my email in this spec also. We are also dealing with HA
of Virtual Instances (especially for Vendors) and will participate.
On Thu, May 18, 2017 at 11:33 PM, Waines, Greg
wrote:
> Yes I am good with writing spec for this in masakari-spec.
>
>
>
> Do you use gerrit fo
It is clear to me now that I won't be able to work on OpenStack as a part
of my next day job, wherever that ends up being. As such, I’ll no longer be
able to invest the time and energy required to maintain my involvement in
the community. It's time to resign my role as a core reviewer, effective
im
On 18/05/17 09:23, Monty Taylor wrote:
But think of the following use cases:
As a user, I want to make an API key that I'm going to use for general
automation just like I use my Password auth plugin based user account
today. I want it to be able to do everything I can do today - but I
value the
Yes but doesn't Pecan allow to use a development server (pecan serve) that
can accept interface and port options? I thought this would be the
test/development server Gnocchi would use.
--
View this message in context:
http://openstack.10931.n7.nabble.com/gnocchi-Running-Gnocchi-API-in-specific-
On 19 May 2017 11:43 am, Curtis wrote:On Thu, May 18, 2017 at 4:13 PM, Adrian Turjak wrote:
> Hello fellow OpenStackers,
>
> For the last while I've been looking at options for multi-region
> multi-master Keystone, as well as multi-master for other services I've
> been developing and one thing th
The etherpad for this session is here [1]. The goal for this session was
to inform operators and get feedback on the plan for what we're doing
with moving claims from the computes to the control layer (scheduler or
conductor).
We mostly talked about retries, which also came up in the cells v2
Chris Friesen wrote:
On 05/16/2017 10:45 AM, Joshua Harlow wrote:
So fyi,
If you really want something like this:
Just use:
http://fasteners.readthedocs.io/en/latest/api/lock.html#fasteners.lock.ReaderWriterLock
And always get a write lock.
It is a slightly different way of getting those
I just wanted to blurt this out since it hit me a few times at the
summit, and see if I'm misreading the rooms.
For the last few years, Nova has pushed back on adding orchestration to
the compute API, and even define a policy for it since it comes up so
much [1]. The stance is that the compute
On 2017-05-18 18:04:35 -0400 (-0400), Paul Belanger wrote:
[...]
> if we decide to publish to docker, I don't think we'd push
> directly. Maybe push to our docker registry then mirror to docker
> hub. That is something we can figure out a little later.
[...]
Ideally by iterating on https://review.
The etherpad for this session is here [1]. This was about discussing
ways to achieve co-location or affinity for VMs and volumes for
high-performance, and was spurred by an older dev list discussion
(linked in the etherpad).
This quickly grew into side discussions and it became apparent that a
On Thu, May 18, 2017 at 4:13 PM, Adrian Turjak wrote:
> Hello fellow OpenStackers,
>
> For the last while I've been looking at options for multi-region
> multi-master Keystone, as well as multi-master for other services I've
> been developing and one thing that always came up was there aren't many
From: Duncan Thomas
> On 18 May 2017 at 22:26, Rochelle Grober
> wrote:
> > If you're going to use --distance, then you should have specific values
> (standard definitions) rather than operator defined:
> > And for that matter, is there something better than distance? Collocated
> maybe?
> >
>
Team,
Please take a look at this devstack review that adds a new etcd3 service:
https://review.openstack.org/#/c/445432/
Waiting on infra team to help with creating a directory on
tarballs.openstack.org with etcd release binaries as so far i haven't
been able to get time/effort from ubuntu/debian
On 05/16/2017 10:45 AM, Joshua Harlow wrote:
So fyi,
If you really want something like this:
Just use:
http://fasteners.readthedocs.io/en/latest/api/lock.html#fasteners.lock.ReaderWriterLock
And always get a write lock.
It is a slightly different way of getting those locks (via a context ma
On 18 May 2017 at 22:26, Rochelle Grober wrote:
> If you're going to use --distance, then you should have specific values
> (standard definitions) rather than operator defined:
> And for that matter, is there something better than distance? Collocated
> maybe?
>
> colocated={local, rack, row, m
Hello fellow OpenStackers,
For the last while I've been looking at options for multi-region
multi-master Keystone, as well as multi-master for other services I've
been developing and one thing that always came up was there aren't many
truly good options for a true multi-master backend. Recently I'
On 05/18/2017 04:32 PM, Zane Bitter wrote:
On 18/05/17 07:53, Sean Dague wrote:
My worry about policy also is that I'm not sure how safe it is for a
project owned API key to inherit permissions from the user who created
it. I can't think of a better way to it though but I'm still slightly
unco
On Thu, May 18, 2017 at 09:34:44AM -0700, Michał Jastrzębski wrote:
> >> Issue with that is
> >>
> >> 1. Apache served is harder to use because we want to follow docker API
> >> and we'd have to reimplement it
> >
> > No, the idea is apache is transparent, for now we have been using proxypass
> > m
Hi team,
It's time for us to request a room (or share one) for the next PTG in
September if we want to meet. Last time we did not. Do we want one this
time?
--
Julien Danjou
/* Free Software hacker
https://julien.danjou.info */
signature.asc
Description: PGP signature
__
On 18/05/17 07:53, Sean Dague wrote:
My worry about policy also is that I'm not sure how safe it is for a
project owned API key to inherit permissions from the user who created
it. I can't think of a better way to it though but I'm still slightly
uncomfortable with it since a user with more rol
From: Matt Riedemann
> On 5/15/2017 2:28 PM, Edmund Rhudy (BLOOMBERG/ 120 PARK) wrote:
> > Hi all,
> >
> > I'd like to follow up on a few discussions that took place last week
> > in Boston, specifically in the Compute Instance/Volume Affinity for
> > HPC session
> > (https://etherpad.openstack
The etherpad for this session is here [1]. The goal for this session was
figuring out the use cases for using Cinder as instance ephemeral
storage and short/long-term solutions.
This really came down to a single use case, which is as an operator I
want to use Cinder for all of my storage needs
Hi everyone,
After previous summits where we had vertical tracks for Nova sessions I
would provide a recap for each session.
The Forum in Boston was a bit different, so here I'm only attempting to
recap the Forum sessions that I ran. Dan Smith led a session on Cells
v2, John Garbutt led seve
On 05/18/2017 01:02 PM, Mike Bayer wrote:
>
>
> On 05/17/2017 02:38 PM, Sean Dague wrote:
>>
>> Some of the concerns/feedback has been "please describe things that are
>> harder by this being an abstraction", so examples are provided.
>
> so let's go through this list:
>
> - OpenStack services
On Thu, May 18 2017, Mike Bayer wrote:
> replaces oslo.service with a multiprocessing approach that doesn't use
> eventlet. great! any openstack service that rides on oslo.service would like
> to be able to transparently switch from eventlet to multiprocessing the same
> way they can more or les
On 05/18/2017 02:37 PM, Julien Danjou wrote:
On Thu, May 18 2017, Mike Bayer wrote:
I'm not understanding this? do you mean this?
In the long run, yes. Unfortunately, we're not happy with the way Oslo
libraries are managed and too OpenStack centric. I've tried for the last
couple of years
On Thu, May 18 2017, Mike Bayer wrote:
> I'm not understanding this? do you mean this?
In the long run, yes. Unfortunately, we're not happy with the way Oslo
libraries are managed and too OpenStack centric. I've tried for the last
couple of years to move things on, but it's barely possible to de
Hi Greg,
Thank you.
> Do you use gerrit for this git ?
Yes, we use gerrit, same as other openstack projects.
https://review.openstack.org/#/admin/projects/openstack/masakari-specs
Here is the list for current and past spec works.
https://review.openstack.org/#/q/project:openstack/masakari-specs
Hi Greg,
Thank you for proposal.
#BTW, I replied to our discussion in [1].
Masakari mainly focuses on black box monitoring the VMs.
But that does not mean Masakari do not do white box type of monitoring.
There will be a configuration options for operators for whether to
use it or not and how
Yes I am good with writing spec for this in masakari-spec.
Do you use gerrit for this git ?
Do you have a template for your specs ?
Greg.
From: Sam P
Reply-To: "openstack-dev@lists.openstack.org"
Date: Thursday, May 18, 2017 at 1:51 PM
To: "openstack-dev@lists.openstack.org"
Subject: Re: [
Hi Greg,
Thank you Adam for followup.
This is new feature for masakari-monitors and think Masakari can
accommodate this feature in masakari-monitors.
From the implementation prospective, it is not that hard to do.
However, as you can see in our Boston presentation, Masakari will
replace its m
On 18 May 2017, at 2:27, Thierry Carrez wrote:
> Hi everyone,
>
> For the PTG events we have a number of rooms available for 5 days, of
> which we need to make the best usage. We also want to keep it simple and
> productive, so we want to minimize room changes (allocating the same
> room to the
On 18 May 2017, at 2:57, Thierry Carrez wrote:
> Hi again,
>
> For the PTG events we have, by design, a pretty loose schedule. Each
> room is free to organize their agenda in whatever way they see fit, and
> take breaks whenever they need. This flexibility is key to keep our
> productivity at th
On 05/16/2017 05:42 AM, Julien Danjou wrote:
On Wed, Apr 19 2017, Julien Danjou wrote:
So Gnocchi gate is all broken (agan) because it depends on "pbr" and
some new release of oslo.* depends on pbr!=2.1.0.
Same things happened today with Babel. As far as Gnocchi is concerned,
we're goin
Excerpts from Thierry Carrez's message of 2017-05-18 11:57:04 +0200:
> Hi again,
>
> For the PTG events we have, by design, a pretty loose schedule. Each
> room is free to organize their agenda in whatever way they see fit, and
> take breaks whenever they need. This flexibility is key to keep our
On 05/17/2017 02:38 PM, Sean Dague wrote:
Some of the concerns/feedback has been "please describe things that are
harder by this being an abstraction", so examples are provided.
so let's go through this list:
- OpenStack services taking a more active role in managing the DBMS
, "managi
I followed up with Sean in IRC [0]. My last note about rebuilding role
assignment dynamically doesn't really make sense. I was approaching this
from a different perspective.
[0]
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2017-05-18.log.html#t2017-05-18T15:20:32
On T
Hi,
I've started to migrate Gnocchi itself to GitHub. The Launchpad bugs
have been re-created at https://github.com/gnocchixyz/gnocchi/issues and
I'll move the repository as soon as all opened reviews are merged.
Cheers,
--
Julien Danjou
// Free Software hacker
// https://julien.danjou.info
si
Greetings OpenStack community,
A short meeting today, mostly reflecting on the Birds of a Feather session [4]
at Summit last week. It was well attended and engendered plenty of good
discussion. There are notes on an etherpad at
https://etherpad.openstack.org/p/BOS-API-WG-BOF that continue to
On 18 May 2017 at 08:03, Paul Belanger wrote:
> On Tue, May 16, 2017 at 02:11:18PM +, Sam Yaple wrote:
>> I would like to bring up a subject that hasn't really been discussed in
>> this thread yet, forgive me if I missed an email mentioning this.
>>
>> What I personally would like to see is a
>> Issue with that is
>>
>> 1. Apache served is harder to use because we want to follow docker API
>> and we'd have to reimplement it
>
> No, the idea is apache is transparent, for now we have been using proxypass
> module in apache. I think what Doug was mentioning was have a primary docker
> reg
On 17 May 2017 at 20:02, Dean Troyer wrote:
> On Wed, May 17, 2017 at 1:47 PM, Doug Hellmann wrote:
>> The timeline depends on who signed up to do the next revision. Did
>> we get someone to do that, yet, or are we still looking for a
>> volunteer? (Note that I am not volunteering here, just ask
There isn't a specific time for blueprint review at the moment. It's usually
whenever I get time, or someone asks via email or IRC. During the weekly
meetings we always have time for open discussion of bugs/blueprints/patches etc.
Rob
On 18 May 2017 at 16:31, Waines, Greg
mailto:greg.wai...@wi
A blueprint question for horizon team.
I registered a new blueprint the other day.
https://blueprints.launchpad.net/horizon/+spec/vitrage-alarm-counts-in-topnavbar
Do I need to do anything else to get this reviewed? I don’t think so, but
wanted to double check.
How frequently do horizon bluepri
On Tue, May 16, 2017 at 02:11:18PM +, Sam Yaple wrote:
> I would like to bring up a subject that hasn't really been discussed in
> this thread yet, forgive me if I missed an email mentioning this.
>
> What I personally would like to see is a publishing infrastructure to allow
> pushing built i
On Tue, May 16, 2017 at 06:57:04AM -0700, Michał Jastrzębski wrote:
> On 16 May 2017 at 06:22, Doug Hellmann wrote:
> > Excerpts from Thierry Carrez's message of 2017-05-16 14:08:07 +0200:
> >> Flavio Percoco wrote:
> >> > From a release perspective, as Doug mentioned, we've avoided releasing
> >
On Thu, May 18, 2017 at 8:45 AM, Sean Dague wrote:
> On 05/18/2017 09:27 AM, Doug Hellmann wrote:
> > Excerpts from Adrian Turjak's message of 2017-05-18 13:34:56 +1200:
> >
> >> Fully agree that expecting users of a particular cloud to understand how
> >> the policy stuff works is pointless, but
On 05/18/2017 09:27 AM, Doug Hellmann wrote:
> Excerpts from Adrian Turjak's message of 2017-05-18 13:34:56 +1200:
>
>> Fully agree that expecting users of a particular cloud to understand how
>> the policy stuff works is pointless, but it does fall on the cloud
>> provider to educate and document
Excerpts from Adrian Turjak's message of 2017-05-18 13:34:56 +1200:
> Fully agree that expecting users of a particular cloud to understand how
> the policy stuff works is pointless, but it does fall on the cloud
> provider to educate and document their roles and the permissions of
> those roles. I
On 05/18/2017 06:53 AM, Sean Dague wrote:
On 05/17/2017 09:34 PM, Adrian Turjak wrote:
On 17/05/17 23:20, Sean Dague wrote:
On 05/16/2017 07:34 PM, Adrian Turjak wrote:
Anyway that aside, I'm sold on API keys as a concept in this case
provided they are project owned rather than user owned,
On Thu, May 18, 2017 at 11:26:41AM +0200, Lance Haig wrote:
This is not only an Aodh/Ceilometer alarm issue. I can confirm that
whatever the resource prefix, this works well.
But an alarm description also contains a query an external API to
retrieve statistics. Aodh alarms are currently able t
Dmitry Tantsur wrote:
>> [...]
>> After giving it some thought, my current thinking is that we should
>> still split the week in two, but should move away from an arbitrary
>> horizontal/vertical split. My strawman proposal would be to split the
>> week between inter-project work (+ teams that rely
On 05/17/2017 09:34 PM, Adrian Turjak wrote:
>
>
> On 17/05/17 23:20, Sean Dague wrote:
>> On 05/16/2017 07:34 PM, Adrian Turjak wrote:
>>
>>> Anyway that aside, I'm sold on API keys as a concept in this case
>>> provided they are project owned rather than user owned, I just don't
>>> think we s
On Thu, 2017-05-18 at 03:29 +, Steven Dake (stdake) wrote:
> My experience with BTRFS has been flawless. My experience with
> overlayfs is that occasionally (older centos kernels) returned
> as permissions (rather the drwxrwrw). This most often
> happened after using the yum overlay
Hi,
I am trying to configure openstack with VMware as an compute and network
driver as vlan/vxlan. My instances are being created in vCenter, but are
not getting IP.
The bridge created in the neutron node are being created in the vCenter but
they are not attached to any exsi host. I figured that a
On 16.05.2017 20:57, Michał Jastrzębski wrote:
> On 16 May 2017 at 11:49, Doug Hellmann wrote:
>> Excerpts from Michał Jastrzębski's message of 2017-05-16 11:38:19 -0700:
>>> On 16 May 2017 at 11:27, Doug Hellmann wrote:
Excerpts from Michał Jastrzębski's message of 2017-05-16 09:46:19 -0700
Hi Thierry, thanks for raising it. I think it's very important to discuss
indeed.
On 05/18/2017 11:27 AM, Thierry Carrez wrote:
Hi everyone,
For the PTG events we have a number of rooms available for 5 days, of
which we need to make the best usage. We also want to keep it simple and
productive
Chris Jones wrote:
> I have a fairly simple proposal to make - I'd like to suggest that
> Feature Freeze move to being much earlier in the release cycle (no
> earlier than M.1 and no later than M.2 would be my preference).
> [...]
Hey Chris,
From my (admittedly too long) experience in release man
On Thu, May 18, 2017 at 5:57 AM, Thierry Carrez wrote:
> Hi again,
>
> For the PTG events we have, by design, a pretty loose schedule. Each
> room is free to organize their agenda in whatever way they see fit, and
> take breaks whenever they need. This flexibility is key to keep our
> productivity
Hi again,
For the PTG events we have, by design, a pretty loose schedule. Each
room is free to organize their agenda in whatever way they see fit, and
take breaks whenever they need. This flexibility is key to keep our
productivity at those events at a maximum. In Atlanta, most teams ended
up dyna
+1, Totally agree.
Best Regards,
Attila
On Tue, May 16, 2017 at 10:22 AM, Andrea Frittoli wrote:
> Hello team,
>
> I'm very pleased to propose Fanglei Zhu (zhufl) for Tempest core.
>
> Over the past two cycle Fanglei has been steadily contributing to Tempest
> and its community.
> She's done a
On 18.05.17 08:00, Mehdi Abaakouk wrote:
Hi,
On Mon, May 15, 2017 at 01:01:57PM -0400, Zane Bitter wrote:
On 15/05/17 12:10, Steven Hardy wrote:
On Mon, May 15, 2017 at 04:46:28PM +0200, Lance Haig wrote:
Hi Steve,
I am happy to assist in any way to be honest.
It was great to meet you in
Hi everyone,
For the PTG events we have a number of rooms available for 5 days, of
which we need to make the best usage. We also want to keep it simple and
productive, so we want to minimize room changes (allocating the same
room to the same group for one or more days).
For the first PTG in Atlan
On 17.05.17 22:18, Zane Bitter wrote:
On 16/05/17 10:32, Lance Haig wrote:
What if instead of a directory per release, we just had a 'deprecated'
directory where we move stuff that is going away (e.g. anything
relying on OS::Glance::Image), and then deleted them when it
disappeared from any su
Hey everyone,
The docs meeting will continue today in #openstack-meeting as scheduled
(Thursday at 16:00 UTC). For more details, and the agenda, see the meeting
page: -
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting
The meeting chair will be me! Hope you can al
On Thu, May 18 2017, Hanxi Liu wrote:
> Ceilometer, Gnocchi, Aodh all use pbr, so the port is 8000 by default.
>
> I guess we also should hardcode Gnocchi's port in rdo project, together
> with Aodh.
> i proposed patchs for Aodh and Gnocchi:
>
> https://review.rdoproject.org/r/#/c/5848/
> https://
On Thu, May 18 2017, aalvarez wrote:
> I thought the API was based on and mounted by Pecan? Isn't there a way to
> pass these options to Pecan?
Pecan is an API framework, not a HTTP server.
--
Julien Danjou
# Free Software hacker
# https://julien.danjou.info
signature.asc
Description: PGP sig
I thought the API was based on and mounted by Pecan? Isn't there a way to
pass these options to Pecan?
--
View this message in context:
http://openstack.10931.n7.nabble.com/gnocchi-Running-Gnocchi-API-in-specific-interface-tp135004p135012.html
Sent from the Developer mailing list archive at Nab
On Thu, May 18, 2017 at 3:06 PM, Julien Danjou wrote:
> On Wed, May 17 2017, aalvarez wrote:
>
> > I do not need this functionality for production, but for testing. I
> think it
> > would be nice if we can specify the interface for the gnocchi-api even
> for
> > test purposes, just like the port.
On 18.05.2017 2:38, Fox, Kevin M wrote:
> I've only used btrfs and devicemapper on el7. btrfs has worked well.
> devicemapper ate may data on multiple occasions. Is redhat supporting overlay
> in the el7 kernels now?
Please take a look this fs benchmark results thread and comments [0]
before eva
On Wed, May 17 2017, aalvarez wrote:
> I do not need this functionality for production, but for testing. I think it
> would be nice if we can specify the interface for the gnocchi-api even for
> test purposes, just like the port.
Feel free to send a patch. This is provided by pbr so that's where
75 matches
Mail list logo