Cool.
I'll start to prepare a BP for this, so we can have more detailed
discussion.
On Wed, Jun 6, 2018 at 11:08 PM, Antoni Segura Puimedon
wrote:
> On Wed, Jun 6, 2018 at 2:37 PM, Irena Berezovsky
> wrote:
> > Sounds like a great initiative.
> >
> > Lets follow up on the proposal by the
The branch is now available under feature/graphql on the neutron core
repository [1].
Just to summarize our initial requirements:
- GraphQL endpoint to be added through a new WeBoB/WSGI stack
- Add graphene library [2]
- Unit tests and implementation for GraphQL schema for networks, subnets
Hello!
As you hopefully are aware the First Contact SIG strives to provide a place
for new contributors to come for information and advice. Part of this is
helping new contributors find more established contributors in the
community they can ask for help from. While the group of people involved
Status:
glanceclient - released 2.11.1 today
glance_store - one outstanding patch that would be worth including in
the release:
- https://review.openstack.org/#/c/534745/ (use only exceptions for
uri validations)
glance - two patches we should get in:
- https://review.openstack.org/#/c/514114/
Excerpts from Jeremy Stanley's message of 2018-06-06 20:09:36 +:
> On 2018-06-06 14:52:04 -0400 (-0400), Zane Bitter wrote:
> > On 29/05/18 13:37, Jeremy Stanley wrote:
> > > On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote:
> [...]
> > > > * If the repo is a fork of another project,
Excerpts from Sean McGinnis's message of 2018-06-06 15:14:48 -0500:
> On 06/06/2018 03:04 PM, Doug Hellmann wrote:
> > I have started submitting a series of patches to fix up the tox.ini
> > settings for projects as a step towards running "python3 first"
> > [1]. The point of doing this now is to
Zuul will be updating the version of Ansible it uses to run jobs from version
2.3 to 2.5 tomorrow, June 7, 2018. The Infra team will followup shortly after
and get that update deployed.
Other users have apparently checked that this works in general and we have
tests that exercise some basic
When the system boots up, the IP addresses seem correct:
Jun 6 12:43:07 overcloud-controller-0 cloud-init: ci-info: | eno5: |
True | . | . | . | 6c:ae:8b:25:34:ed |
Jun 6 12:43:07 overcloud-controller-0 cloud-init: ci-info: | eno4: |
True | 9.114.118.241
On 06/06/2018 03:04 PM, Doug Hellmann wrote:
I have started submitting a series of patches to fix up the tox.ini
settings for projects as a step towards running "python3 first"
[1]. The point of doing this now is to give teams a head start on
understanding the work involved as we consider
Excerpts from Anne Bertucio's message of 2018-06-06 12:28:25 -0700:
> > Either way, I would like to ensure that someone from
> > Kata is communicating with qemu upstream.
>
> Since probably not too many Kata folks are on the OpenStack dev list
> (something to tackle in another thread or OSF
On 2018-06-06 15:16:59 -0400 (-0400), Doug Hellmann wrote:
[...]
> Kata also has a qemu fork, but that is under the kata-containers
> github org and not our infrastructure. I'm not sure someone outside
> of our community would differentiate between the two, but maybe
> they would.
[...]
The Kata
On 2018-06-06 14:52:04 -0400 (-0400), Zane Bitter wrote:
> On 29/05/18 13:37, Jeremy Stanley wrote:
> > On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote:
[...]
> > > * If the repo is a fork of another project, there must be (public)
> > > evidence of an attempt to co-ordinate with the
I have started submitting a series of patches to fix up the tox.ini
settings for projects as a step towards running "python3 first"
[1]. The point of doing this now is to give teams a head start on
understanding the work involved as we consider whether to make this
a community goal.
The current
Here is the nova patch for those following along:
https://review.openstack.org/#/c/572790/
On 6/6/2018 9:07 AM, Jay Pipes wrote:
On 06/06/2018 10:02 AM, Matt Riedemann wrote:
On 6/6/2018 8:24 AM, Jay Pipes wrote:
On 06/06/2018 09:10 AM, Artom Lifshitz wrote:
I think regardless of how we
Dear OpenStack Networking community of projects,
As part of the implementation of multiple port bindings in the Neutron
reference implementation (
https://specs.openstack.org/openstack/neutron-specs/specs/backlog/pike/portbinding_information_for_nova.html),
the port_binding relationship in the
> Either way, I would like to ensure that someone from
> Kata is communicating with qemu upstream.
Since probably not too many Kata folks are on the OpenStack dev list (something
to tackle in another thread or OSF all-project meeting), chiming in to say
yup!, we’ve got QEMU upstream folks in
Excerpts from Zane Bitter's message of 2018-06-06 14:52:04 -0400:
> On 29/05/18 13:37, Jeremy Stanley wrote:
> > On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote:
> >> We allow various open source projects that are not an official
> >> part of OpenStack or necessarily used by OpenStack to
On 29/05/18 13:37, Jeremy Stanley wrote:
On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote:
We allow various open source projects that are not an official
part of OpenStack or necessarily used by OpenStack to be hosted on
OpenStack infrastructure - previously under the 'StackForge'
Octavia also has an informal rule about two cores from the same
company merging patches. I support this because it makes sure we have
a diverse perspective on the patches. Specifically it has worked well
for us as all of the cores have different cloud designs, so it catches
anything that would
On Thu, 31 May 2018 15:04:53 -0500, Matt Riedemann wrote:
On 5/31/2018 1:35 PM, melanie witt wrote:
This cycle at the PTG, we had decided to start making some progress
toward removing nova-network [1] (thanks to those who have helped!) and
so far, we've landed some patches to extract common
On Tue, May 29, 2018 at 12:41 PM, Mathieu Gagné wrote:
> Hi Julia,
>
> Thanks for the follow up on this topic.
>
> On Tue, May 29, 2018 at 6:55 AM, Julia Kreger
> wrote:
>>
>> These things are not just frustrating, but also very inhibiting for
>> part time contributors such as students who may
On 06/06/2018 11:35 AM, Jeremy Stanley wrote:
On 2018-06-06 18:24:00 +0200 (+0200), Dmitry Tantsur wrote:
In Ironic world we run doc8 on README.rst as part of the pep8 job.
Maybe we should make it a common practice?
[...]
First, the doc8 tool should be considered generally useful for any
On 2018-06-06 18:24:00 +0200 (+0200), Dmitry Tantsur wrote:
> In Ironic world we run doc8 on README.rst as part of the pep8 job.
> Maybe we should make it a common practice?
[...]
First, the doc8 tool should be considered generally useful for any
project with Sphinx-based documentation,
Excerpts from Dmitry Tantsur's message of 2018-06-06 18:24:00 +0200:
> In Ironic world we run doc8 on README.rst as part of the pep8 job. Maybe we
> should make it a common practice?
That seems like it may be a good thing to add, but I don't know
that it is sufficient to detect all of the
In Ironic world we run doc8 on README.rst as part of the pep8 job. Maybe we
should make it a common practice?
On 06/06/2018 03:35 PM, Jeremy Stanley wrote:
On 2018-06-06 16:36:45 +0900 (+0900), Akihiro Motoki wrote:
[...]
In addition, unfortunately such checks are not run in project gate,
so
"do you think this is an area that OpenLab could help out with?" <<
YES!! please ping mrhillsman and RuiChen over on #askopenlab
-- Dims
On Wed, Jun 6, 2018 at 11:44 AM, Zane Bitter wrote:
> On 06/06/18 11:18, Chris Hoge wrote:
>>
>> Hi Zane,
>>
>> Do you think this effort would make sense as a
On 06/06/18 11:18, Chris Hoge wrote:
Hi Zane,
Do you think this effort would make sense as a subproject within the Cloud
Provider OpenStack repository hosted within the Kubernetes org? We have
a solid group of people working on the cloud provider, and while it’s not
the same code, it’s a
Hi Zane,
Do you think this effort would make sense as a subproject within the Cloud
Provider OpenStack repository hosted within the Kubernetes org? We have
a solid group of people working on the cloud provider, and while it’s not
the same code, it’s a collection of the same expertise and test
Hey everyone,
Just a quick reminder that tomorrow, June 7, is the Rocky-2 milestone.
Any projects follow the cycle-with-milestones model should propose a patch to
the openstack/releases repo before the end of the day tomorrow to have a b2
release created.
Please see the releases repo README for
On Wed, Jun 6, 2018 at 2:37 PM, Irena Berezovsky wrote:
> Sounds like a great initiative.
>
> Lets follow up on the proposal by the kuryr-kubernetes blueprint.
I fully subscribe what Irena said. Let's get on this quick!
>
> BR,
> Irena
>
> On Wed, Jun 6, 2018 at 6:47 AM, Peng Liu wrote:
>>
>>
On 06/06/2018 10:02 AM, Matt Riedemann wrote:
On 6/6/2018 8:24 AM, Jay Pipes wrote:
On 06/06/2018 09:10 AM, Artom Lifshitz wrote:
I think regardless of how we ended up with this situation, we're still
in a position where we have a public-facing API that could lead to
data-corruption when used
On 6 June 2018 at 13:55, Jay Pipes wrote:
> On 06/06/2018 07:46 AM, Matthew Booth wrote:
>>
>> TL;DR I think we need to entirely disable swap volume for multiattach
>> volumes, and this will be an api breaking change with no immediate
>> workaround.
>>
>> I was looking through tempest and came
On 6/6/2018 8:24 AM, Jay Pipes wrote:
On 06/06/2018 09:10 AM, Artom Lifshitz wrote:
I think regardless of how we ended up with this situation, we're still
in a position where we have a public-facing API that could lead to
data-corruption when used in a specific way. That should never be the
Excerpts from Akihiro Motoki's message of 2018-06-06 16:36:45 +0900:
> Hi the release team,
>
> When I prepared neutron Rocky-2 deliverables, I noticed a new metadata
> syntax check
> which checks README.rst was introduced.
>
> As of now, README.rst in networking-bagpipe and networking-ovn hit
On 2018-06-06 16:36:45 +0900 (+0900), Akihiro Motoki wrote:
[...]
> In addition, unfortunately such checks are not run in project gate,
> so there is no way to detect in advance.
> I think we need a way to check this when a change is made
> instead of detecting an error when a release patch is
Some of our xstatic packages require an elaborate build process, as they
use various javascript-based tools to do the build. In this case, it's more
than just minification — it's macros and includes, basically a
pre-processor, and it would be very hard to re-create that in Python. Thus,
we did
On 06/06/2018 09:10 AM, Artom Lifshitz wrote:
I think regardless of how we ended up with this situation, we're still
in a position where we have a public-facing API that could lead to
data-corruption when used in a specific way. That should never be the
case. I would think re-using the already
On 6/6/2018 7:55 AM, Jay Pipes wrote:
I'd love to know who is actually using the swap_volume() functionality,
actually. I'd especially like to know who is using swap_volume() with
multiattach.
The swap volume API in nova only exists as a callback routine during
volume live migration or
I think regardless of how we ended up with this situation, we're still
in a position where we have a public-facing API that could lead to
data-corruption when used in a specific way. That should never be the
case. I would think re-using the already possible 400 response code to
update-volume when
On 06/06/2018 07:46 AM, Matthew Booth wrote:
TL;DR I think we need to entirely disable swap volume for multiattach
volumes, and this will be an api breaking change with no immediate
workaround.
I was looking through tempest and came across
Sounds like a great initiative.
Lets follow up on the proposal by the kuryr-kubernetes blueprint.
BR,
Irena
On Wed, Jun 6, 2018 at 6:47 AM, Peng Liu wrote:
> Hi Kuryr-kubernetes team,
>
> I'm thinking to propose a new BP to support Kubernetes Network Custom
> Resource Definition De-facto
> -Original Message-
> From: Doug Hellmann
> Sent: Monday, June 4, 2018 5:52 PM
> To: openstack-dev
> Subject: Re: [openstack-dev] [tc] Organizational diversity tag
>
> Excerpts from Zane Bitter's message of 2018-06-04 17:41:10 -0400:
> > On 02/06/18 13:23, Doug Hellmann wrote:
> > >
TL;DR I think we need to entirely disable swap volume for multiattach
volumes, and this will be an api breaking change with no immediate
workaround.
I was looking through tempest and came across
api.compute.admin.test_volume_swap.TestMultiAttachVolumeSwap.test_volume_swap_with_multiattach.
This
Hi Peng,
Thanks for the proposal! See below
On 06/06/2018 05:47 AM, Peng Liu wrote:
> Hi Kuryr-kubernetes team,
>
> I'm thinking to propose a new BP to support Kubernetes Network Custom
> Resource Definition De-facto Standard Version 1 [1], which was drafted
> by network plumbing working group
Ihar,
Neutron can not be what it is without all your work! Thank you and wish you
all the best!
On Wed, Jun 6, 2018 at 11:22 AM Andreas Scheuring <
scheu...@linux.vnet.ibm.com> wrote:
> Hi Ihar, it was always a pleasure learning from and working with you. Wish
> you all the best for your new
Hi all
Summit is over for weeks.
Would like to share with team on what we got in Summit
*Heat Onboarding Session*
We didn't get many people shows up in Onboarding session this time, but we
do get much more view in our video.
Slide:
Hi,
I'm trying to create a fix for the failing networking-bgpvpn stable
periodic sphinx-docs job [1], but meanwhile it turned out that other
"check" (and possibly "gate") jobs are failing on stable, too, on
networking-bgpvpn, because of missing dependency: networking-odl
repository (for
Hi Watcher team,
We have meeting today at 8:00 UTC on #openstack-meeting-alt channel
Best Regards,
Alex
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
Hi Blair,
Sorry for the late reply, could you elaborate more on the proxy driver idea
?
On Mon, May 21, 2018 at 4:05 PM, Blair Bethwaite
wrote:
> (Please excuse the top-posting)
>
> The other possibility is that the Cyborg managed devices are plumbed in
> via IP in guest network space. Then
After reading the spec
https://review.openstack.org/#/c/554717/14/doc/specs/rocky/cyborg-nova-sched.rst
,
I confuse on the CUSTOM_ACCELERATOR_FPGA meaning. Initially, I thought it
means a region. But after reading the spec, it can be a device, a region or
a function. Is it on purpose design?
Hi the release team,
When I prepared neutron Rocky-2 deliverables, I noticed a new metadata
syntax check
which checks README.rst was introduced.
As of now, README.rst in networking-bagpipe and networking-ovn hit this [1].
Although they can be fixed in individual projects, what is the current
Hi Ihar, it was always a pleasure learning from and working with you. Wish you
all the best for your new project!
---
Andreas Scheuring (andreas_s)
On 4. Jun 2018, at 22:31, Ihar Hrachyshka wrote:
Hi neutrinos and all,
As some of you've already noticed, the last several months I was
Hi Team,
let's resume the team meeting, at today's meeting we need to make decisions
on all Rocky critical specs in order to meet MS2 deadline.
--
Zhipeng (Howard) Huang
Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office:
53 matches
Mail list logo
