> You will get different checksums with tar and/or gzip, you can check the
> extracted files and they should be the same.
Yes, content is the same, it's just difference in timestamps of
folders and generated files (ChangeLog, egg-info etc).
> I would like to see signed commits in the 'official' r
Hi All ,
Would like to know why have we removed the API details for Order and
Consumer Resource in the following update link for API Documentation of
Barbican
http://docs.openstack.org/developer/barbican/api/index.html
Does the Barbican support order and consumer resource now ?
Any help would
Editing the subject
On Mon, Jun 1, 2015 at 2:35 AM, Asha Seshagiri
wrote:
> Hi All ,
>
> Would like to know why have we removed the API details for Order and
> Consumer Resource in the following update link for API Documentation of
> Barbican
>
> http://docs.openstack.org/developer/barbican/api/
On 1 Jun 2015 10:50 am, "Alan Pevec" wrote:
>
> 2015-05-29 18:30 GMT+02:00 Jeremy Stanley :
> > On 2015-05-29 16:30:12 +0100 (+0100), Dave Walker wrote:
> >> This is generally my opinion as-well, I always hoped that *every*
> >> commit would be considered a release rather than an arbitrary
> >> ta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/01/2015 02:20 AM, Steve Gordon wrote:
> - Original Message -
>> From: "Maish Saidel-Keesing" To:
>> openstack-dev@lists.openstack.org
>>
>> On 05/29/15 18:25, Matthew Thode wrote:
>>> On 05/29/2015 10:18 AM, Ihar Hrachyshka wrote:
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/29/2015 06:24 PM, Jeremy Stanley wrote:
> On 2015-05-29 17:50:01 +0200 (+0200), Ihar Hrachyshka wrote: [...]
>> if we attempt to fix a security issue that has a backwards
>> incompatible fix, then we are forced in introducing a new
>> configu
Asha,
We haven't removed anything. Unfortunately, no one has had the chance to port
those resources over from the old github wiki page and into the new sphinx
format yet. Also, yes they are still supported.
John Vrbanac
From: Asha Seshagiri
Sent: Monday, June
>> One issue is how would we provide source tarballs, statically hosting
>> tarballs for each and every micro version is not realistic, also those
>> wouldn't be signed.
>
> Sorry, but why isn't it realistic, and why wouldn't they be signed?
I thought storage requirements to generate tarball for e
Hi Ramy,
I tried the disk-image-builder and now i can't ssh with any user with any
key.
Everytime i get "Permission denied (publickey).".
Here's my nodepool.yaml:
script-dir: /etc/nodepool/scripts
elements-dir: /etc/nodepool/elements
images-dir: /opt/nodepool_dib
dburi: 'mysql://nodepool:chang
On 29/05/15 09:44 -0500, Matt Riedemann wrote:
On 5/29/2015 8:41 AM, Thierry Carrez wrote:
Hi everyone,
TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though
Long
On 01/06/15 10:07 +0200, Alan Pevec wrote:
One issue is how would we provide source tarballs, statically hosting
tarballs for each and every micro version is not realistic, also those
wouldn't be signed.
Sorry, but why isn't it realistic, and why wouldn't they be signed?
I thought storage req
Doug Hellmann wrote:
> Please let me know if you think I missed any details, or misunderstood
> something as agreed to. Or, of course, if you weren’t there and see something
> wrong with the plan after looking at it now.
We'd also provide a tool to easily translate the series name with the
curre
On 31/05/15 18:12 +, Ildikó Váncsa wrote:
Hi All,
I would like to ask about the user-facing notifications part of the list. Do
you have a roadmap for this? Is this driven by the Zaqar team? What are the
next steps?
Hey,
This will require cross-project efforts and we (the Zaqar team) wou
On 27/05/15 11:19 -0700, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2015-05-27 10:40:48 -0700:
On 27/05/15 12:42, Clint Byrum wrote:
>
> == Crazy idea section ==
>
> One thing I never had a chance to discuss with any of the Zaqar devs that
> I would find interesting is an email-on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/29/2015 11:46 PM, Haïkel wrote:
> A release version makes it easy to know what fixes are shipped in a
> package. If you rebase on stable branches, then you can just put
> the git sha1sum (though, it's not very friendly) in the version,
> and le
Hi BaoHua,
For kilo you test, I am not sure what's the steps you did, as the dev-guide
is for master branch development.
If you have any questions, you can ask in #openstack-containers IRC channel
or file bug in launchpad.
Thanks
Best Wishes,
-
On 29 May 2015 at 18:32, Neil Jerram wrote:
> Hi all,
>
> Per yesterday's IRC meeting [1], and discussion in Vancouver, Nova work is
> being somewhat driven by the etherpad at [2]. But this etherpad doesn't
> have a section for libvirt / vif driver changes. The log at [1] briefly
> touched on th
Hi Benton,
I'm sorry that seems I missed your discuss. I just seen your patch's merge
yesterday.
But I don't know that does NAK matters? A client will get a ACK and a NAK
if there are two agents, it's ok because client will assign IP address
successfully according to the ACK.
"dhcp-authoritative
On 28/05/15 16:48 +0100, Gordon Sim wrote:
On 05/27/2015 05:08 PM, Hayes, Graham wrote:
It was agreed that Zaqar would look at a oslo_messaging driver for the
services that did not agree with the 3 options presented.
Another option there would be to add amqp 1.0 support to zaqar, and
then you
On 29 May 2015 at 17:10, Chris Friesen wrote:
> On 05/29/2015 06:27 AM, John Garbutt wrote:
>>
>> On 27 May 2015 at 23:36, Robert Collins wrote:
>>>
>>> On 26 May 2015 at 03:37, Chris Friesen
>>> wrote:
>
>
Basically the problem is this:
When booting up instances, nova allows the
>But I don't know that does NAK matters?
Yes, some clients will honor it and re-request, so they end up in a loop. I
believe the dhcp client in the Cirros image does this.
>"dhcp-authoritative" is really a simple way to solve the problem of that
dnsmasq will lose lease if restarted
Yes, unfortun
Thanks!
Reported the bug here at https://bugs.launchpad.net/magnum/+bug/1460574.
On Mon, Jun 1, 2015 at 4:37 PM, Kai Qiang Wu wrote:
> Hi BaoHua,
>
> For kilo you test, I am not sure what's the steps you did, as the
> dev-guide is for master branch development.
>
>
> If you have any questions, y
On 29/05/15 14:50 +0200, Sebastien Han wrote:
@Flavio: I wrote this, so we don’t forget (I guess you know how much I want
this one ^^). If you already committed on it, then it is awesome :).
Ah, that makes sense now. cool.
So yeah, I'll be focusing on improving tasks and image conversion for
Thierry Carrez wrote:
> TL;DR:
> - We propose to stop tagging coordinated point releases (like 2015.1.1)
> - We continue maintaining stable branches as a trusted source of stable
> updates for all projects though
Thanks everyone for the constructive discussion on this. Lots of good
stuff. Let me s
On 1 Jun 2015 8:07 pm, "Alan Pevec" wrote:
>
> >> One issue is how would we provide source tarballs, statically hosting
> >> tarballs for each and every micro version is not realistic, also those
> >> wouldn't be signed.
> >
> > Sorry, but why isn't it realistic, and why wouldn't they be signed?
>
On 01/06/15 10:29, Flavio Percoco wrote:
AFAIK, these tarballs are generated on the flight in GH. Couldn't we
do the same ?
The issue with on-the-fly generation is: timestamps are actually new,
and not the same as when the release was tagged.
And: you probably want some hashes to verify, your
how to configure a rsync with password in OpenStack Swift?
I am currently working on Swift and configure it to working with rsync
without a password properly. However, i wander if we can configure rsync
with a password so that we can make rsync more safe. Is there any way or
manual to instruct to
Looks like a bug to be filed for devstack. Based on some discussions
here [1], this is not a magnum problem. Maybe the worlddump.py file in
devstack should add a '-xdev' param to avoid touching DVFS.
[1]
http://unix.stackexchange.com/questions/77453/why-cannot-find-read-run-user-1000-gvfs-even-tho
Hi,
Seems i missed a step, NODEPOOL_SSH_KEY was not exported so the image was
not properly configured.
Now i got an instance that is added to the jenkins master as slave and it's
online.
Thanks.
Eduard
__
OpenStack Developmen
Thierry Carrez wrote:
> Thanks everyone for the constructive discussion on this. Lots of good
> stuff. Let me summarize the objections so far:
>
> 1. we'd lose the focus rhythm
>
> Point releases triggered some attention to stable branches: the
> necessity to fix the CI there when it's broken, an
On 01/06/15 11:27 +0200, Matthias Runge wrote:
On 01/06/15 10:29, Flavio Percoco wrote:
AFAIK, these tarballs are generated on the flight in GH. Couldn't we
do the same ?
s/flight/fly+(facepalm)/ LOL, on the *flight* would be really hard.
The issue with on-the-fly generation is: timestamps a
On 05/29/2015 11:37 AM, Derek Higgins wrote:
> Whats important I think is
> that we can change things to use sbuild without docker if that is what
> works best for you for debs.
Ok. Though if we are to use delorean, we'll have to switch to that in
upstream Debian as well, and I'm not sure if that'
On 27/05/15 11:30 -0400, Nikhil Komawar wrote:
I kinda agree with all 3 of you, possibly because there are Grey areas
on how best we can actually do this. We are talking about one cycle
ahead to the very least. While that is a great thing to do, I think we
should focus on making the current Art
On 01/06/15 12:10, Flavio Percoco wrote:
Is this a real problem? What are *tarball timestamps* used for in the
packaging world?
I'm sure there's a way we can workaround this issue.
timestamps just give you a hint, how old the source actually is, not
when a packager downloaded the tarball som
On Fri, May 29, 2015 at 7:55 PM, Fox, Kevin M wrote:
> As an Op, I really really want to replace one image with a new one
> atomically with security updates preapplied. Think shellshock, ghost, etc.
> It will be basically be the same exact image as before, but patched.
> Referencing local ID's e
> On 26/05/15 13:54 -0400, Nikhil Komawar wrote:
>> On 5/26/15 12:57 PM, Jesse Cook wrote:
>>We also had some hallway talk about putting the v1 and v2 APIs on top
>> of
>>the v3 API. This forces faster adoption, verifies supportability via v1
>> and
>>v2 tests, increases supportability
FYI, the channel is openstack-meeting-3.
On Sun, May 31, 2015 at 10:41 PM Mohammad Hanif wrote:
> Hi Thomas,
>
> The time reserved for the weekly IRC is 1600 UTC on Tuesdays (
> http://eavesdrop.openstack.org/#Neutron_VPNaaS_Meeting). The IRC channel
> might not be available on any other time (
On 29 May 2015 at 14:41, Thierry Carrez wrote:
> Hi everyone,
>
> TL;DR:
> - We propose to stop tagging coordinated point releases (like 2015.1.1)
> - We continue maintaining stable branches as a trusted source of stable
> updates for all projects though
>
Ideally I would still want to see tarbal
On 29 May 2015 at 22:38, Doug Hellmann wrote:
> As with our other semver projects, we will use pbr’s interpretation of the
> semver rules (http://docs.openstack.org/developer/pbr/semver.html) for minor
> updates and patch releases. I don’t believe we discussed whether to increment
> the major v
On 29 May 2015 at 19:58, Jay Pipes wrote:
> On 05/29/2015 05:04 AM, John Garbutt wrote:
>>
>> On 29 May 2015 at 09:00, Sahid Orentino Ferdjaoui
>> wrote:
>>>
>>> On Fri, May 29, 2015 at 08:47:01AM +0200, Jens Rosenboom wrote:
As the discussion in https://review.openstack.org/179569 stil
On 31 May 2015 at 14:15, Xu, Hejie wrote:
> Replied in line with prefix [alex]
>
> -Original Message-
> From: John Garbutt [mailto:j...@johngarbutt.com]
> 1)
> We agreed changing a 500 error to an existing error (or making it succeed in
> the usual way) is a change that doesn't need a ver
Hi All,
We try to use the LVS load balancer with Open Stack[1]. Here we want to
define the dummy interface for keepalived virtual server IP. But seems
"keepalived" enable to resolve this Virtual IP with OpenStack.
Have anyone tried the LVS load balancer with OpenStack before? Any
suggestion or wo
On 28 May 2015 at 19:26, Vladik Romanovsky
wrote:
>> As part of the work to object-ify the image metadata dicts, I'm looking
>> at the current way the libvirt driver fetches image metadata for an
>> instance, in cases where the compute manager hasn't already passed it
>> into the virt driver API.
On 01/06/15 11:57 +0100, John Garbutt wrote:
On 26/05/15 13:54 -0400, Nikhil Komawar wrote:
On 5/26/15 12:57 PM, Jesse Cook wrote:
We also had some hallway talk about putting the v1 and v2 APIs on top
of
the v3 API. This forces faster adoption, verifies supportability via v1
and
v2 test
Just to follow up here, we agreed the nova-docker team would report
back in a nova IRC team meeting on how things are going post
liberty-1.
Thanks,
John
On 27 May 2015 at 16:29, Davanum Srinivas wrote:
> Bich,
>
> Sure thing, just start on #nova-docker irc channel and we can talk there
>
> -- di
On 1 June 2015 at 13:10, Flavio Percoco wrote:
> On 01/06/15 11:57 +0100, John Garbutt wrote:
>>>
>>> On 26/05/15 13:54 -0400, Nikhil Komawar wrote:
On 5/26/15 12:57 PM, Jesse Cook wrote:
We also had some hallway talk about putting the v1 and v2 APIs on top
of
the v3
Several of the discussions at Vancouver got me thinking about what seems to me
to be a fundamental mis-match in Nova: the way we think about resources, and
how we handle requesting/claiming them. I wrote down my initial thoughts
(http://blog.leafe.com/rethinking-resources/), but as many of you t
Le 01/06/2015 14:40, Ed Leafe a écrit :
Several of the discussions at Vancouver got me thinking about what seems to me
to be a fundamental mis-match in Nova: the way we think about resources, and
how we handle requesting/claiming them. I wrote down my initial thoughts
(http://blog.leafe.com/
Excerpts from John Garbutt's message of 2015-06-01 12:26:48 +0100:
> On 29 May 2015 at 22:38, Doug Hellmann wrote:
> > As with our other semver projects, we will use pbr’s interpretation of the
> > semver rules (http://docs.openstack.org/developer/pbr/semver.html) for
> > minor updates and patch
Excerpts from Thierry Carrez's message of 2015-06-01 10:30:33 +0200:
> Doug Hellmann wrote:
> > Please let me know if you think I missed any details, or misunderstood
> > something as agreed to. Or, of course, if you weren’t there and see
> > something wrong with the plan after looking at it now.
On 05/29/2015 11:03 PM, Jeremy Stanley wrote:
> On 2015-05-28 23:19:36 +0200 (+0200), Thomas Goirand wrote:
> [...]
>> By the way, I was thinking about the sbuild package caching system, and
>> thought: how about network mounting /var/cache/pbuilder/aptcache using
>> something like Manila (or any o
On Jun 1, 2015, at 7:49 AM, Sylvain Bauza wrote:
> Long story short :
> https://blueprints.launchpad.net/nova/+spec/resource-objects
>
> Until we get this, it's difficult to discuss on different resources within
> Nova. Let's work by small steps and provide a versioned resource system
> before
On 01/06/15 13:30 +0100, John Garbutt wrote:
On 1 June 2015 at 13:10, Flavio Percoco wrote:
On 01/06/15 11:57 +0100, John Garbutt wrote:
On 26/05/15 13:54 -0400, Nikhil Komawar wrote:
On 5/26/15 12:57 PM, Jesse Cook wrote:
We also had some hallway talk about putting the v1 and v2 APIs on
Hi Mistral team,
This is just a reminder that we’ll have a team meeting today at
#openstack-meeting at 16.00 UTC (not 16.20 like it was during a couple of
months!)
Agenda:
Review action items
Current status (progress, issues, roadblocks, further plans)
Liberty Roadmap
Add seconds granularity in
On Fri, May 29, 2015 at 06:32:18PM +0100, Neil Jerram wrote:
> Hi all,
>
> Per yesterday's IRC meeting [1], and discussion in Vancouver, Nova work is
> being somewhat driven by the etherpad at [2]. But this etherpad doesn't
> have a section for libvirt / vif driver changes. The log at [1] briefl
Thanks! I'll reconsider about this.
2015-06-01 16:54 GMT+08:00 Kevin Benton :
> >But I don't know that does NAK matters?
>
> Yes, some clients will honor it and re-request, so they end up in a loop.
> I believe the dhcp client in the Cirros image does this.
>
> >"dhcp-authoritative" is really a s
On 05/27/15 at 07:38pm, Chris Friesen wrote:
On 05/27/2015 05:09 PM, Fox, Kevin M wrote:
If the current behavior is broken, and the behavior is causing problems with
things like fixing quota's, should it just be deprecated and pushed off to
orchestration rather then change it?
Is this causing
We are jubilant to announce the release of:
wsme 0.7.0: Simplify the writing of REST APIs, and extend them with
additional protocols.
With source available at:
http://git.openstack.org/cgit/stackforge/wsme
For more details, please see the git log history below and:
https://launchpad.ne
On Mon, Jun 01, 2015 at 09:44:24AM +0100, John Garbutt wrote:
> On 29 May 2015 at 18:32, Neil Jerram wrote:
> > Hi all,
> >
> > Per yesterday's IRC meeting [1], and discussion in Vancouver, Nova work is
> > being somewhat driven by the etherpad at [2]. But this etherpad doesn't
> > have a section
Finally back after a few days offline. Thanks everyone. Just glad to be
part of this great group. Thank you for all the positive comments from
cores and non-cores alike.
Sean
On 05/26/2015 04:42 PM, Ivan Kolodyazhny wrote:
+1,
Welcome to the team, Sean.
Regards,
Ivan Kolodyazhny
On Wed, M
Well deserved, and hope you had a nice break.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailm
On 06/01/2015 08:30 AM, John Garbutt wrote:
On 1 June 2015 at 13:10, Flavio Percoco wrote:
On 01/06/15 11:57 +0100, John Garbutt wrote:
On 26/05/15 13:54 -0400, Nikhil Komawar wrote:
FWIW, moving Nova from glance v1 to glance v2, without breaking Nova's
public API, will require someone gettin
On 05/31/2015 05:38 PM, Jay Lau wrote:
Just want to use ML to trigger more discussion here. There are now
bugs/patches tracing this, but seems more discussions are needed before
we come to a conclusion.
https://bugs.launchpad.net/magnum/+bug/1453732
https://review.openstack.org/#/c/181839/
https
There is a spec to get this work started. It's currently a Heat spec:
https://review.openstack.org/#/c/186436/
That spec is for defining a basic schema to start with.
-Alex
On Mon, Jun 1, 2015 at 4:48 AM, Flavio Percoco wrote:
> On 28/05/15 16:48 +0100, Gordon Sim wrote:
>
>> On 05/27/2015 05:
Hi everyone,
In an attempt to document shared understandings and "the OpenStack way",
the Technical Committee created a workgroup around the idea of a
"Project Team Guide". This group is however open to anyone who would
like to contribute. The current outline for the guide lives here:
https://eth
We are happy to announce the release of:
python-barbicanclient 3.2.0: Client Library for OpenStack Barbican Key
Management API
With source available at:
http://git.openstack.org/cgit/openstack/python-barbicanclient
For more details, please see the git log history below and:
http://laun
Hi,
Are we going to add this feature to 7.0? There are some customers who tried
Fuel from nightly or technical previews builds. However, they don't want to
install fuel master node once again. There are several reasons for that. As
a sample it's dev environment, though production environment shoul
We are thrilled to announce the release of:
python-ironicclient 0.7.0: OpenStack Bare Metal Provisioning API
Client Library
With source available at:
http://git.openstack.org/cgit/openstack/python-ironicclient
For more details, please see the git log history below and:
http://launchpad
We are jubilant to announce the release of:
os-brick 0.2.0: OpenStack Cinder brick library for managing local
volume attaches
With source available at:
http://git.openstack.org/cgit/openstack/os-brick
For more details, please see the git log history below and:
http://launchpad.net/os-b
We are thrilled to announce the release of:
python-neutronclient 2.6.0: CLI and Client Library for OpenStack
Networking
With source available at:
http://git.openstack.org/cgit/openstack/python-neutronclient
For more details, please see the git log history below and:
http://launchpad.ne
We are thrilled to announce the release of:
python-manilaclient 1.2.0: Client library for OpenStack Manila API.
With source available at:
http://git.openstack.org/cgit/openstack/python-manilaclient
For more details, please see the git log history below and:
http://launchpad.net/python-
On 06/01/2015 04:34 AM, Flavio Percoco wrote:
> On 31/05/15 18:12 +, Ildikó Váncsa wrote:
>> Hi All,
>>
>> I would like to ask about the user-facing notifications part of the
>> list. Do you have a roadmap for this? Is this driven by the Zaqar
>> team? What are the next steps?
>
> Hey,
>
> Th
We are delighted to announce the release of:
python-troveclient 1.2.0: Client library for OpenStack DBaaS API
With source available at:
http://git.openstack.org/cgit/openstack/python-troveclient
For more details, please see the git log history below and:
http://launchpad.net/python-tro
We are excited to announce the release of:
os-collect-config 0.1.35: Collect and cache metadata, run hooks on
changes.
For more details, please see the git log history below.
Changes in os-collect-config 0.1.34..0.1.35
---
4a41f0b Drop use of 'oslo' name
On Sat, May 30, 2015 at 03:00:04AM +, Steven Dake (stdake) wrote:
Hey Folks,
I noticed the Kolla functional gate is failing sporadically.
It seems that sometimes an image doesn’t build.
http://logs.openstack.org/75/186475/1/check/check-kolla-functional-f21/8f23913/console.html
(For the r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I have a suggestion... Since it's not obvious now which stable branch
a release corresponds to, can we add that info into release note email
body somewhere for the sake of those who may closely track stable
updates but not so much those in-developmen
Excerpts from Doug Hellmann's message of 2015-06-01 10:27:38 -0400:
> We are thrilled to announce the release of:
>
> python-manilaclient 1.2.0: Client library for OpenStack Manila API.
>
> With source available at:
>
> http://git.openstack.org/cgit/openstack/python-manilaclient
>
> For mor
We are delighted to announce the release of:
oslo.middleware 1.3.0: Oslo Middleware library
With source available at:
http://git.openstack.org/cgit/openstack/oslo.middleware
For more details, please see the git log history below and:
http://launchpad.net/oslo.middleware/+milestone/1.3.
Hi Ryan and Flavio,
Thanks for the quick response and the pointers, I will check out the reviews to
catch up.
Best Regards,
Ildikó
> -Original Message-
> From: Ryan Brown [mailto:rybr...@redhat.com]
> Sent: June 01, 2015 16:34
> To: openstack-dev@lists.openstack.org
> Subject: Re: [open
Excerpts from Doug Hellmann's message of 2015-06-01 10:27:41 -0400:
> We are thrilled to announce the release of:
>
> python-neutronclient 2.6.0: CLI and Client Library for OpenStack
> Networking
>
> With source available at:
>
> http://git.openstack.org/cgit/openstack/python-neutronclient
>
Excerpts from Doug Hellmann's message of 2015-06-01 10:31:36 -0400:
> We are excited to announce the release of:
>
> os-collect-config 0.1.35: Collect and cache metadata, run hooks on
> changes.
>
> For more details, please see the git log history below.
>
>
> Changes in os-collect-config 0.1.3
Excerpts from Doug Hellmann's message of 2015-06-01 10:29:32 -0400:
> We are jubilant to announce the release of:
>
> os-brick 0.2.0: OpenStack Cinder brick library for managing local
> volume attaches
>
> With source available at:
>
> http://git.openstack.org/cgit/openstack/os-brick
>
> Fo
2015-06-01 21:54 GMT+08:00 Jay Pipes :
> On 05/31/2015 05:38 PM, Jay Lau wrote:
>
>> Just want to use ML to trigger more discussion here. There are now
>> bugs/patches tracing this, but seems more discussions are needed before
>> we come to a conclusion.
>>
>> https://bugs.launchpad.net/magnum/+bu
Hi,
what are the prereqs to get a spec for a new nova VIF type approved?
In my case I'm planning for a new neutron ml2 driver and agent (on
stackforge) that adds general support for macvtap to neutron. I've not
yet published anything regarding the neutron part so far - but this will
happen in the
Thank you!!
Hopefully this release will be the starting point for a small rebirth of
the WSME project. Many bugs still need fixes, the code needs improvements
and probably some standardisation towards the OpenStack guidelines.
It would be very useful to receive some feedback from the projects who
> *Plan C* would be to just let projects tag stable point releases from
> time to time. That would solve all the original stated problems. And
> that would solve objections 2 and 3, which I think are the most valid ones.
and *Plan D* would be to start doing automatic per-project
micro-versions on
On Jun 1, 2015, at 8:26 AM, Andrew Laski wrote:
>> In any case, even if we wanted to deprecate it (and I think an argument
>> could be made for that) we still have to decide what the "correct" behaviour
>> should be for the API as it exists today. In my view the current behaviour
>> doesn't m
Hi Paul, all,
Yes, it's good to have a discussion on BGP VPN and edge VPN proposals
during the VPNaaS meeting.
At least Mathieu and I will participate to see how we can help.
To avoid confusion we think it's good to keep separate the discussion on
the details of the work around the networking
Hi,
We confirm this meeting for tomorrow Tuesday 2nd @15:00 UTC on
#openstack-meeting-alt .
We'll discuss tomorrow what we want to do for future IRC meetings
(day, time, periodicity, etc.).
(Everyone is encouraged to also follow the VPNaaS meeting that will follow)
Best,
-Thomas
2015-05-2
On 05/30/2015 09:15 AM, Kashyap Chamarthy wrote:
On Sat, May 30, 2015 at 03:52:02PM +0300, Yaroslav Lobankov wrote:
Hi everyone,
Is it possible for other people (not only core reviewers) to
participate in bug triage? I would like to help in doing this.
Absolutely. There's no such silly rule th
On 6/1/15, 06:20, "Dimitri John Ledkov" wrote:
>On 29 May 2015 at 14:41, Thierry Carrez wrote:
>> Hi everyone,
>>
>> TL;DR:
>> - We propose to stop tagging coordinated point releases (like 2015.1.1)
>> - We continue maintaining stable branches as a trusted source of stable
>> updates for all p
2015-06-01 17:32 GMT+02:00 Alan Pevec :
>> *Plan C* would be to just let projects tag stable point releases from
>> time to time. That would solve all the original stated problems. And
>> that would solve objections 2 and 3, which I think are the most valid ones.
>
> and *Plan D* would be to start
On 2015-06-01 12:04:34 +0200 (+0200), Thierry Carrez wrote:
> Thierry Carrez wrote:
[...]
> > 2. it would be difficult to get proper release notes
> >
> > If we don't have point releases anymore, we don't have release notes
> > anymore. Release notes contain various types of information: the list
On 2015-06-01 17:32:03 +0200 (+0200), Alan Pevec wrote:
[...]
> and *Plan D* would be to start doing automatic per-project
> micro-versions on each commit: e.g. 2015.1.N where N is increased on
> each commit. There's just TBD item how to provide source tarballs for
> this.
[...]
That would happen
On 2015-06-01 12:20:22 +0100 (+0100), Dimitri John Ledkov wrote:
[...]
> If the stable tarball snapshots had stable, ever increasing names, I
> would switch to using those straight away. (Out of which $ git
> describe --tags satisfies said requirement)
Current PBR releases already create monotonic
On 2015-06-01 15:57:17 + (+), Jeremy Stanley wrote:
[...]
> The biggest hurdle is that we'd need a separate upload job name
> for those since the current version of Zuul lacks a way to run a
> particular job for different branches in different pipelines (we'd
> want to do versioned uploads
Hi everyone,
The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday June 2nd, at 19:00 UTC in #openstack-meeting
Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)
Everyone interested
Doug Hellmann wrote:
> Excerpts from Thierry Carrez's message of 2015-06-01 10:30:33 +0200:
>> Doug Hellmann wrote:
>>> Please let me know if you think I missed any details, or misunderstood
>>> something as agreed to. Or, of course, if you weren’t there and see
>>> something wrong with the plan
Since we had a bunch of interest at the Summit in VPN, we'll hold a meeting
at our time-slot, Tuesday, 1600 UTC, openstack-meeting-3, tomorrow on June
2nd.
I updated the agenda. If you have other updates, please add them to the
wiki page:
https://wiki.openstack.org/wiki/Meetings/VPNaaS
Regards,
Note that the 11am PDT meeting has moved to the #openstack-meeting channel
On Sun, May 31, 2015 at 2:20 PM, sean roberts
wrote:
> Starting tomorrow, the akanda project will be meeting on
> #openstack-meeting at 11:00 PDT. Agenda is in the usual place
> https://wiki.openstack.org/wiki/Meetings/ak
1 - 100 of 151 matches
Mail list logo