hi Thierry Carrez,
Could you help me to delete this wiki page[1]? This page about
Smaug is not used any longer. Thanks.
[1] https://wiki.openstack.org/wiki/File:Smaug-available-protectables.svg
Best regards
chen ying
2017-08-29 11:02 GMT+08:00 Chen Ying :
> Thanks a lot.
>
> Best re
On Wed, Aug 30, 2017 at 7:54 AM, Emilien Macchi wrote:
> On Tue, Aug 29, 2017 at 4:17 PM, Emilien Macchi
> wrote:
> > We are currently dealing with 4 issues and until they are fix, please
> > do not approve any patch. We want to keep the gate clear to merge the
> > fixes for the 4 problems first
On Tue, Aug 29, 2017 at 4:17 PM, Emilien Macchi wrote:
> We are currently dealing with 4 issues and until they are fix, please
> do not approve any patch. We want to keep the gate clear to merge the
> fixes for the 4 problems first.
>
> 1) devstack-gate broke us because we use it as a library (bad
On 17-08-29 15:58:55, Jeremy Stanley wrote:
> On 2017-08-29 10:30:42 -0500 (-0500), Matthew Thode wrote:
> [...]
> > 3. reversion. Start new versions at 3000 or something, kinda
> > dirty imo.
>
> And sort of a 3.1 option is to prepend a PEP 440 version epoch:
>
> https://www.python.org/dev/p
Hi
Kindly please share a remote go-to meeting invite.
Thanks for the initiative.
/Trinath
From: Tetsuya Nakamura
Sent: Wednesday, August 30, 2017 5:12:19 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [all] NFV Tut
On Tue, Aug 29, 2017 at 02:09:32PM +, Claudiu Belu wrote:
> (test) ubuntu@ubuntu:~$ pip freeze | grep networking-hyperv
>
> (test) ubuntu@ubuntu:~$ pip install networking-hyperv
I know this isn't a solution but I'd be remiss if I didn't point it out:
uc_url=https://git.openstack.org/cgit/op
All,
Just a reminder. The NFV Tutorial & SpecFest will be held on September 11th in
Denver. The venue (Sheraton DTC) is about 30 minutes driving from the OpenStack
PTG venue.
The event is open to everyone. Please take a look at the detailed agenda:
https://nfvwiki.etsi.org/index.php?title=ETSI_
We are currently dealing with 4 issues and until they are fix, please
do not approve any patch. We want to keep the gate clear to merge the
fixes for the 4 problems first.
1) devstack-gate broke us because we use it as a library (bad)
https://bugs.launchpad.net/tripleo/+bug/1713868
2) https://rev
Hello Tony,Thanks for the heads-up!Responding for the 'networking-bigswitch' plugin - could we retain mitaka and upwards for this project please? We have a controller release which supports mitaka - so we would like to keep it for any patch fixes in the near future.We're good to remove anything <=
Chris and I were talking about the various bugs related to not cleaning
up allocations during failures, of which I've reported two more today
[1][2].
The discovery process here is really just me doing code inspection, then
opening a bug, writing a recreate functional test and then fixing the
Like in Newton and Ocata, I've started an etherpad for a Pike retrospective:
https://etherpad.openstack.org/p/nova-pike-retrospective
We'll go over this at the PTG so please fill in your thoughts before
that happens so we can try and come away with action items at the PTG.
--
Thanks,
Matt
On 29.08.2017 17:58, David Moreau Simard wrote:
> Hi,
>
> At the the last few RDO meetings [1][2][3], we brought up that no one
> had stepped up to do the work to build and ship what ends up being
> stable TripleO containers for Pike.
> There was different mentions that we should bring this to the
On 2017-08-29 06:28 AM, Mikhail Kebich wrote:
> Hello Telemetry Team,
>
> I see that the Panko API does not provide a way to go through all events
> in the order they were stored in database. Panko sorts events by
> generated and message_id fields and uses message_id field as a marker
> for p
On 2017-08-29 18:26:49 +0200 (+0200), Thierry Carrez wrote:
[...]
> Yeah, in that specific case I think that's the simplest route. It's not
> really destroying it, it just prevents PyPI from erroneously
> distributing it, without having to add a PEP440-Epoch to an OpenStack
> deliverable and discov
Doug Hellmann wrote:
> If that 2015 version is no longer maintained, then deleting it from
> PyPI may be the most effective way to avoid this particular support
> issue, even though that is normally not something we recommend.
Yeah, in that specific case I think that's the simplest route. It's not
Dear all,
The agenda is available at:
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 (line
1059)
Please indicate actions that have been achieved and feel free to add items in
the Opening discussion Section.
Best,
Ad_rien_
_
Rich,
I think it would be good for members of the Cinder team to participate
in this given that we have people on the team working on containerizing.
I will raise this opportunity in this week's Cinder meeting. Let me
know when you have a space planned to meet.
Thanks!
Jay
On 8/29/2017
On 8/22/2017 8:18 PM, Matt Riedemann wrote:
I'm proposing that we add gibi to the nova core team. He's been around
for awhile now and has shown persistence and leadership in the
multi-release versioned notifications effort, which also included
helping new contributors to Nova get involved which
On 2017-08-29 10:30:42 -0500 (-0500), Matthew Thode wrote:
[...]
> 3. reversion. Start new versions at 3000 or something, kinda
> dirty imo.
And sort of a 3.1 option is to prepend a PEP 440 version epoch:
https://www.python.org/dev/peps/pep-0440/#version-epochs
Challenge there is that, while
Hi,
At the the last few RDO meetings [1][2][3], we brought up that no one
had stepped up to do the work to build and ship what ends up being
stable TripleO containers for Pike.
There was different mentions that we should bring this to the MLs but
we never did, so here it is.
TL;DR, Do we want sta
Hi Folks,
Would there be some interest from Cinder and Ironic (and others of course)
team members to have a quick session at the PTG with the Kolla team on the
latest developments in Kolla (like the new kolla-ansible devmode for
example)?
Also it would give the Kolla team an opportunity to hear a
Excerpts from Claudiu Belu's message of 2017-08-29 14:09:32 +:
> Hello,
>
> As many of you know, during Kilo, the neutron vendor decomposition happened,
> which lead to the birth of many networking-* libraries, including
> networking-hyperv. When it was time for us to make a release for that
On Mon, Aug 28, 2017 at 3:17 PM, Emilien Macchi wrote:
[...]
> Also, it's still time to propose topics, please go ahead and
> contribute to the etherpad. We'll review the schedule before the PTG
> (probably during our weekly meetings tomorrow and next week).
[...]
I forgot to remind folks that PT
So to the existing core team members, please respond with a yay/nay and
after about a week or so we should have a decision (knowing a few cores
are on vacation right now).
+1 on the condition that gibi stops finding so many bugs in the stuff I
worked on. It's embarrassing.
--Dan
___
Rochelle, I like the idea. I added a new section "Thursday:
Installation Guides" to
https://etherpad.openstack.org/p/docs-i18n-ptg-queens.
Everybody, if you are available on Thu and interested in install guide
testing, please sign up.
Thanks,
pk
On Fri, 25 Aug 2017 20:32:38 +
Rochelle Grobe
On 17-08-29 14:09:32, Claudiu Belu wrote:
> Hello,
>
> As many of you know, during Kilo, the neutron vendor decomposition happened,
> which lead to the birth of many networking-* libraries, including
> networking-hyperv. When it was time for us to make a release for that cycle,
> pretty much ev
On Fri, 25 Aug 2017 15:40:07 +0200
Roger Luethi wrote:
> I don't know what will get changed or created until the release, but
> what I can find right now in terms of installation instructions is this:
>
> https://docs.openstack.org/pike/install/
>
> leading to the "OpenStack Installation Tutoria
On Tue, 22 Aug 2017 20:18:18 -0500, Matt Riedemann wrote:
So to the existing core team members, please respond with a yay/nay and
after about a week or so we should have a decision (knowing a few cores
are on vacation right now).
+1
___
On Tue, Aug 29, 2017 at 2:14 AM, Jiří Stránský wrote:
[...]
> the CI for containerized deployments with Pacemaker is close! In fact, it
> works [1][2] (but there are pending changes to merge).
Really good news, thanks for the update!
> The way it's proposed in gerrit currently is to switch the
>
Hello,
As many of you know, during Kilo, the neutron vendor decomposition happened,
which lead to the birth of many networking-* libraries, including
networking-hyperv. When it was time for us to make a release for that cycle,
pretty much every networking-* project followed the release version
On 29.8.2017 14:42, Giulio Fidente wrote:
On 08/29/2017 02:33 PM, Jiří Stránský wrote:
A bit of context: Currently our only upgrade check job is non-OVB -
containers-multinode-upgrades-nv. As of late we started hitting
timeouts, and the job only does mixed-version deploy + 1 node AIO
overcloud u
On 08/29/2017 02:33 PM, Jiří Stránský wrote:
A bit of context: Currently our only upgrade check job is non-OVB -
containers-multinode-upgrades-nv. As of late we started hitting
timeouts, and the job only does mixed-version deploy + 1 node AIO
overcloud upgrade (just the main step). It doesn't d
On 29.8.2017 13:22, Giulio Fidente wrote:
On 08/29/2017 11:14 AM, Jiří Stránský wrote:
Hi owls,
the CI for containerized deployments with Pacemaker is close! In fact,
it works [1][2] (but there are pending changes to merge).
cool :D
I also spotted this which we need for ceph
https://review.o
On 08/29/2017 11:14 AM, Jiří Stránský wrote:
Hi owls,
the CI for containerized deployments with Pacemaker is close! In fact,
it works [1][2] (but there are pending changes to merge).
cool :D
I also spotted this which we need for ceph
https://review.openstack.org/#/c/498356/
but I am not s
Hello Telemetry Team,
I see that the Panko API does not provide a way to go through all events in
the order they were stored in database. Panko sorts events by generated and
message_id fields and uses message_id field as a marker for pagination. So,
the following case is possible:
Before the firs
Folks,
Everyone please feel free to vote on that review as a way of
celebrating the release
https://review.openstack.org/#/c/498263/
Thanks,
Dims
On Tue, Aug 29, 2017 at 4:30 AM, Thierry Carrez wrote:
> Hi everyone,
>
> Pike will be formally released tomorrow before 1500utc, with the last
> rel
Hi owls,
the CI for containerized deployments with Pacemaker is close! In fact,
it works [1][2] (but there are pending changes to merge).
The way it's proposed in gerrit currently is to switch the
centos-7-containers-multinode job (featureset010) to deploy with
Pacemaker. What do you think a
Hi Tony, Thanks for reaching out. With regards to
“group-based-policy”, branches < mitaka (meaning Liberty or older) can
be EOL’ed. We would still like to have the stable/mitaka branches for
a little more time if that’s possible. This applies to the repos:
group-based-policy
group-based-policy-auto
On 28/08/2017 21:20, Jeremy Stanley wrote:
> On 2017-08-11 15:31:58 +0200 (+0200), Jakub Libosvar wrote:
> [...]
>> My best hope is they are gonna backport the fix to 4.4.0 and tag a
>> new kernel so we can start running the tests again.
>
> Just to follow up on this thread, it looks like the Ubun
Hi everyone,
Pike will be formally released tomorrow before 1500utc, with the last
release candidates being promoted to final (for cycle-with-milestones
deliverables) and the release page being finalized.
A change proposing those promotions is up for review at:
https://review.openstack.org/#/c/49
Hi Aakash
On Tue, 29 Aug 2017 at 05:09 Aakash Kt wrote:
> Hello all,
> Resending this mail since I think there might have been some error
> sending it the last time.
>
>I am looking to develop an openstack bundle which uses OVN as the SDN.
> I have been reading : https://docs.openstack.o
On Mon, Aug 28, 2017 at 11:27 PM, Matt Riedemann
wrote:
On 8/28/2017 10:52 AM, Balazs Gibizer wrote:
> [Undecided] https://bugs.launchpad.net/nova/+bug/1700496
Notifications
> are emitted per-cell instead of globally
> Devstack config has already been modified so notifications are
emitted
>
On 17-08-29 17:21:00, Ian Wienand wrote:
> Hi,
>
> The "fedora" element -- the one that downloads the upstream .qcow2 and
> re-packages it -- is currently broken as the links we use have
> disappeared [1]. Even allowing for this, it's still broken with some
> changes to the kernel install scripts
Hi,
The "fedora" element -- the one that downloads the upstream .qcow2 and
re-packages it -- is currently broken as the links we use have
disappeared [1]. Even allowing for this, it's still broken with some
changes to the kernel install scripts [2]. AFAICT, the only thing
noticing this is our C
44 matches
Mail list logo