Re: [openstack-dev] [heat][heat-translator][tacker] Need new release of heat-translator library

[龚永生]

I know tacker project is using heat-translator and tosca-parser projects. Who 
can tell
if other projects in OpenStack tents are using them?


regards,
yong sheng gong

At 2018-06-23 01:25:39, "Zane Bitter"  wrote:
>On 21/06/18 16:37, Sean McGinnis wrote:
>>>
>>> Apparently heat-translator has a healthy ecosystem of contributors and
>>> users, but not of maintainers, and it remaining a deliverable of the Heat
>>> project is doing nothing to alleviate the latter problem. I'd like to find
>>> it a home that _would_ help.
>>>
>> 
>> I'd be interested to hear thoughts if this is somewhere where we (the TC)
>> should step in and make a few people cores on this project?
>
> Let's save that remedy for projects that are unresponsive.
>
>> Or are the existing
>> contributors a healthy amount but not involved enough to trust to be cores?
>
> heat-translator cores are aware of the problem and 
>are theoretically on the lookout for new cores, but I presume there's 
>nobody with the track record of reviews to nominate yet.
>
>- ZB
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Openstack-Zun Service Appears down

[Hongbin Lu]

Hi  Muhammad,

I am not sure what is the exact problem, but here is the list of things you
might want to check:

1. Make sure the security group is open. This document explains how to find
the security group(s) of the container:
https://docs.openstack.org/zun/latest/admin/security-groups.html#find-container-s-security-groups
.

2. Check if you can ping the container from outside
$ NET_ID=$(openstack network show private | awk '/ id /{print $4}')
$ sudo ip netns | grep $NET_ID
qdhcp-6d688072-a0c3-4f1c-979e-2d1882564931
$ sudo ip netns exec qdhcp-6d688072-a0c3-4f1c-979e-2d1882564931 ping
10.0.0.9
PING 10.0.0.9 (10.0.0.9) 56(84) bytes of data.
64 bytes from 10.0.0.9: icmp_seq=1 ttl=64 time=0.845 ms
64 bytes from 10.0.0.9: icmp_seq=2 ttl=64 time=0.258 ms
...

3. Check if you can ping outside from the container
$ zun list
...
| 2c5d01ef-11f9-46f6-8ef2-da59914b6a10 | pi-24-container  | nginx  |
Running  | None   | 10.0.0.9, fd66:a11d:c60:0:f816:3eff:fe9c:8f46  |
[80]  |
...
$ CONTAINER_ID=$(zun show pi-24-container | awk '/ uuid /{print $4}')
$ docker ps | grep $CONTAINER_ID
f9cd8aa9a911nginx:latest"nginx -g 'daemon of…"   21 minutes
ago  Up 21 minutes
 zun-2c5d01ef-11f9-46f6-8ef2-da59914b6a10
$ docker inspect -f {{.State.Pid}} f9cd8aa9a911
15001
$ sudo nsenter -t 15001 -n ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=49 time=1.46 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=49 time=0.957 ms

4. traceroute
$ sudo nsenter -t 15001 -n traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  ip-10-0-0-1.ec2.internal (10.0.0.1)  3.173 ms  3.154 ms  3.139 ms
 2  ip-172-24-4-1.ec2.internal (172.24.4.1)  3.086 ms  3.074 ms  3.064 ms
...

5. ping & tcpdump on various interfaces. This is for checking where the
traffic is blocked.
$ sudo ip netns exec qdhcp-6d688072-a0c3-4f1c-979e-2d1882564931 tcpdump -i
tap2813b3ae-8d
...

See if you can find something by performing above steps. In any case, you
might consider restarting the neutron processes which might fix everything
magically. If no, I would need more details about your setup.

Best regards,
Hongbin

On Fri, Jun 22, 2018 at 5:05 AM Usman Awais  wrote:

> Hi Hongbin,
>
> Many thanks, got it running, that was awesom... :) The problem was
> unsynched time. I installed chrony and it started working.
>
> Now I am running into another problem; the networking of the container.
> The container gets started, I can shell into it through appcontainer API,
> it even gets the correct IP address of my private network (named priv-net)
> in openstack, through DHCP. But when I ping any address, even the address
> of the priv-net's gateway, it does nothing. I have following configuration
>
> neutron-openvswitch-agent is running
> neutron-ovs-cleanup is  running
> neutron-destroy-patch-ports is running
> kuryr-libnetwork is running
> docker is running
> zun-compute is running
>
> The eth0 network card has standard configuration of an OVSBridge.
>
> When I create a new container it also creates taps and patch ports on the
> compute node. Now I am going to try to use kuryr script to test what
> happens with "bridged" and "host" networks.
>
> Muhammad Usman Awais
>
>
>
> On Thu, Jun 21, 2018 at 1:14 PM, Hongbin Lu  wrote:
>
>> HI  Muhammad,
>>
>> Here is the code (run in controller node) that decides whether a service
>> is up
>> https://github.com/openstack/zun/blob/master/zun/api/servicegroup.py .
>> There are several possibilities to cause a service to be 'down':
>> 1. The service was being 'force_down' via API (e.g. explicitly issued a
>> command like "appcontainer service forcedown")
>> 2. The zun compute process is not doing the heartbeat for a certain
>> period of time (CONF.service_down_time).
>> 3. The zun compute process is doing the heartbeat properly but the time
>> between controller node and compute node is out of sync.
>>
>> In before, #3 is the common pitfall that people ran into. If it is not
>> #3, you might want to check if the zun compute process is doing the
>> heartbeat properly. Each zun compute process is running a periodic task to
>> update its state in DB:
>> https://github.com/openstack/zun/blob/master/zun/servicegroup/zun_service_periodic.py
>> . The call of ' report_state_up ' will record this service is up in DB
>> at current time. You might want to check if this periodic task is running
>> properly, or if the current state is updated in the DB.
>>
>> Above is my best guess. Please feel free to follow it up with me or other
>> team members if you need further assistant for this issue.
>>
>> Best regards,
>> Hongbin
>>
>> On Wed, Jun 20, 2018 at 9:14 AM Usman Awais 
>> wrote:
>>
>>> Dear Zuners,
>>>
>>> I have installed RDO pike. I stopped openstack-nova-compute service on
>>> one of the hosts, and installed a zun-compute service. Although all the
>>> services seems to be running ok on both controller and compute but when I
>>> do
>>>
>>>  openstack appcontaine

Re: [openstack-dev] [neutron][api[[graphql] A starting point

[Gilles Dubreuil]

Great, thanks to the API SIG!


On 23/06/18 06:53, Flint WALRUS wrote:
Oh! That’s its truly a sweet sweet attention, that will indeed really 
help us to focus on what we have to do without having to goes through 
an extensive email back and forth :-)


Thanks a lot!!
Le ven. 22 juin 2018 à 22:48, Ed Leafe > a écrit :


On Jun 15, 2018, at 5:42 PM, Gilles Dubreuil mailto:gdubr...@redhat.com>> wrote:
>
> This initial patch [1]  allows to retrieve networks, subnets.
>
> This is very easy, thanks to the graphene-sqlalchemy helper.
>
> The edges, nodes layer might be confusing at first meanwhile
they make the Schema Relay-compliant in order to offer
re-fetching, pagination features out of the box.
>
> The next priority is to set the unit test in order to implement
mutations.
>
> Could someone help provide a base in order to respect Neutron
test requirements?

Glad to see some progress!

We have migrated the API-SIG from Launchpad to StoryBoard [0],
specifically so that your group has a place to record stories,
tasks, etc. Please feel free to use this to help coordinated your
work.

[0] https://storyboard.openstack.org/#!/project/1039



-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][api[[graphql] A starting point

[Flint WALRUS]

Oh! That’s its truly a sweet sweet attention, that will indeed really help
us to focus on what we have to do without having to goes through an
extensive email back and forth :-)

Thanks a lot!!
Le ven. 22 juin 2018 à 22:48, Ed Leafe  a écrit :

> On Jun 15, 2018, at 5:42 PM, Gilles Dubreuil  wrote:
> >
> > This initial patch [1]  allows to retrieve networks, subnets.
> >
> > This is very easy, thanks to the graphene-sqlalchemy helper.
> >
> > The edges, nodes layer might be confusing at first meanwhile they make
> the Schema Relay-compliant in order to offer re-fetching, pagination
> features out of the box.
> >
> > The next priority is to set the unit test in order to implement
> mutations.
> >
> > Could someone help provide a base in order to respect Neutron test
> requirements?
>
> Glad to see some progress!
>
> We have migrated the API-SIG from Launchpad to StoryBoard [0],
> specifically so that your group has a place to record stories, tasks, etc.
> Please feel free to use this to help coordinated your work.
>
> [0] https://storyboard.openstack.org/#!/project/1039
>
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][api[[graphql] A starting point

[Ed Leafe]

On Jun 15, 2018, at 5:42 PM, Gilles Dubreuil  wrote:
> 
> This initial patch [1]  allows to retrieve networks, subnets.
> 
> This is very easy, thanks to the graphene-sqlalchemy helper.
> 
> The edges, nodes layer might be confusing at first meanwhile they make the 
> Schema Relay-compliant in order to offer re-fetching, pagination features out 
> of the box.
> 
> The next priority is to set the unit test in order to implement mutations.
> 
> Could someone help provide a base in order to respect Neutron test 
> requirements?

Glad to see some progress! 

We have migrated the API-SIG from Launchpad to StoryBoard [0], specifically so 
that your group has a place to record stories, tasks, etc. Please feel free to 
use this to help coordinated your work.

[0] https://storyboard.openstack.org/#!/project/1039


-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][heat-translator][tacker] Need new release of heat-translator library

[Sean McGinnis]

> > > Apparently heat-translator has a healthy ecosystem of contributors and
> > > users, but not of maintainers, and it remaining a deliverable of the Heat
> > > project is doing nothing to alleviate the latter problem. I'd like to find
> > > it a home that _would_ help.
> > > 
> > 
> > I'd be interested to hear thoughts if this is somewhere where we (the TC)
> > should step in and make a few people cores on this project?
> 
>  Let's save that remedy for projects that are unresponsive.
> 
> > Or are the existing
> > contributors a healthy amount but not involved enough to trust to be cores?
> 
>  heat-translator cores are aware of the problem and are
> theoretically on the lookout for new cores, but I presume there's nobody
> with the track record of reviews to nominate yet.
> 
> - ZB
> 

Great, thanks Zane. I don't think the TC should step on any toes, so I'm happy
that it doesn't appear to be to the point where that would be necessary.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][heat-translator][tacker] Need new release of heat-translator library

[Zane Bitter]

On 21/06/18 16:37, Sean McGinnis wrote:


Apparently heat-translator has a healthy ecosystem of contributors and
users, but not of maintainers, and it remaining a deliverable of the Heat
project is doing nothing to alleviate the latter problem. I'd like to find
it a home that _would_ help.



I'd be interested to hear thoughts if this is somewhere where we (the TC)
should step in and make a few people cores on this project?


 Let's save that remedy for projects that are unresponsive.


Or are the existing
contributors a healthy amount but not involved enough to trust to be cores?


 heat-translator cores are aware of the problem and 
are theoretically on the lookout for new cores, but I presume there's 
nobody with the track record of reviews to nominate yet.


- ZB

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] [placement] placement update 18-25

[Chris Dent]

HTML: https://anticdent.org/placement-update-18-25.html

This is placement update 18-25, a weekly update of ongoing
development related to the [OpenStack](https://www.openstack.org/)
[placement
service](https://developer.openstack.org/api-ref/placement/).

This is a "contract" version, meaning that the spec and other lists
do no have new additions, they are updated to remove what has been
merged or abandoned. This is done to encourage people to review
existing stuff before jumping on whatever the new shiny is.

With this edition I'm adding a Documentation theme as it was
something that's been pointed out recently as a gap.

# Most Important

Nested allocation candidates are getting very close, but remain a
critical piece of functionality. After that is making sure that we
are progressing on the /reshapher functionality and bringing the
various virt drivers into line with all this nice new functionality
(which mostly means ProviderTrees).

All that nice new functionality means bugs. Experiment. Break stuff.
Find bugs. Fix them.

# What's Changed

The optional placement database changes merged. This means that if
[placement_database]/connection is set, that's the target database
for placement data, instead of the nova_api database connection.

Support for consumer generations in allocations has merged.

The PlacementDirect non-HTTP interface to placement has merged.

Most placement unit tests no longer rely on the nova base test
classs.

The spec for Reshape Provider Trees (the thing driving /reshaper)
merged.

# Bugs

* Placement related [bugs not yet in
  progress](https://goo.gl/TgiPXb): 17, one more than last week.
  We've got some work either starting or killing these.
* [In progress placement bugs](https://goo.gl/vzGGDQ) 8, -1 on last
  time.

# Questions

In [IRC
yesterday](http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2018-06-21.log.html#t2018-06-21T13:21:14)
we had an extensive discussion about being able to set custom
resource classes on the resource provider representing a
compute node, outside the virt driver. At the moment the virt driver
will clobber it. Is this what we always want?

# Specs

Total last week: 13. Now: 12

Spec-freeze has passed, so presumably exceptions will be required
for these. For those that are just not going to happen in Rocky, I
guess we can start pushing them into Stein.

* 
  VMware: place instances on resource pool (using update_provider_tree)

* 
  Proposes NUMA topology with RPs

* 
  Account for host agg allocation ratio in placement

* 
  Support default allocation ratios
  This one has two +2, but is pending some decision on spec-freeze.

* 
  Spec on preemptible servers

* 
  Standardize CPU resource tracking

* 
  Propose counting quota usage from placement

* 
  Add history behind nullable project_id and user_id

* 
  Placement: any traits in allocation_candidate query

* 
  Placement: support mixing required traits with any traits

* 
  [WIP] Support Placement in Cinder

* 
  Count quota based on resource class

# Main Themes

## Documentation

This is a section for reminding us to document all the fun stuff we
are enabling. Open areas include:

* Documenting optional placement database. A bug,
  [1778227](https://bugs.launchpad.net/nova/+bug/1778227) has been
  created to track this.

* "How to deploy / model shared disk. Seems fairly straight-forward,
  and we could even maybe create a multi-node ceph job that does
  this - wouldn't that be awesome?!?!", says an enthusiastic Matt
  Riedemann.

* The when's and where's of re-shaping and VGPUs.

## Nested providers in allocation candidates

As far as I can tell the main thing left here is to turn it on in a
microversion. That code is at:

* 

There have been some tweaks to account for the behavior leakage
discussed last week.

## Consumer Generations

There are a couple of patches left on the consumer generation topic:

* 

Is someone already working on code for making use of this in the
resource tracker?

## Reshape Provider Trees

This allows moving inventory and allocations that were on resource
provider A to resource provider B in an atomic fashion. The
blueprint topic is:

* 

There are WIPs for the HTTP parts and the resource tracker parts, on
that topic.

## Mirror Host Aggregates

I thought this 

Re: [openstack-dev] [Nova] [Cyborg] [Glance] Updated spec for Cyborg-Nova-Glance interaction, including os-acc

[Nadathur, Sundar]

s/review the new version is/review the new version/

Regards,
Sundar
On 6/22/2018 8:06 AM, Nadathur, Sundar wrote:

Hello folks,
The os-acc spec [1] has been updated substantially. Please review the 
new version is https://review.openstack.org/#/c/577438/ .


The background for the update is that several important aspects were 
raised as comments on the previous spec ([1], [2]). An alternative 
workflow for attaching accelerators to instances was proposed [3], to 
which I responded with [4] and [5]. Finally, with another IRC 
discussion [6], it was concluded that the design/flow in [4], [5] fits 
the bill. The new version of the os-acc spec incorporates that discussion.


The main points that were raised and addressed are these:

* Some architectures like Power treat devices differently. The os-acc 
framework must provide for plugins to handle such variation. Done.


* The os-acc framework should be more closely patterned after the 
os-vif framework and Neutron flow. This is a bit debatable since 
Neutron ports and Cyborg accelerators differ in some key respects, 
though the os-acc library can be structured like os-vif. I have 
attempted to compare and contrast the os-vif and os-acc approaches.


This discussion is important because we may have programmable NICs 
based on FPGAs. Then Cyborg, Neutron and Nova are going to get tangled 
in a triangle. (If you throw Glance in for FPGA images, that leads 
quickly to a quadrilateral. Add Cinder for storage-related FPGA 
devices, and we get pulled into a pentagram. Geometry is scary. Just 
saying. ;-} )


* Not enough detail in [1]. Mea culpa. Hopefully fixed now.

[1] https://review.openstack.org/#/c/566798/

[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-06-14.log.html#t2018-06-14T18:38:28 



[3] 
https://review.openstack.org/#/c/575545/1/specs/rocky/approved/nova-cyborg-flow.rst 



[4] https://etherpad.openstack.org/p/os-acc-discussion

[5] 
https://docs.google.com/drawings/d/1gbfimiyA1f5sTeobN9mpavEkHT7Z_ScNUqimOkdIYGA/edit 



[6] 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-06-18.log.html#t2018-06-18T22:07:02 



Regards,
Sundar



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] [Cyborg] [Glance] Updated spec for Cyborg-Nova-Glance interaction, including os-acc

[Nadathur, Sundar]

Hello folks,
The os-acc spec [1] has been updated substantially. Please review the 
new version is https://review.openstack.org/#/c/577438/ .


The background for the update is that several important aspects were 
raised as comments on the previous spec ([1], [2]). An alternative 
workflow for attaching accelerators to instances was proposed [3], to 
which I responded with [4] and [5]. Finally, with another IRC discussion 
[6], it was concluded that the design/flow in [4], [5] fits the bill. 
The new version of the os-acc spec incorporates that discussion.


The main points that were raised and addressed are these:

* Some architectures like Power treat devices differently. The os-acc 
framework must provide for plugins to handle such variation. Done.


* The os-acc framework should be more closely patterned after the os-vif 
framework and Neutron flow. This is a bit debatable since Neutron ports 
and Cyborg accelerators differ in some key respects, though the os-acc 
library can be structured like os-vif. I have attempted to compare and 
contrast the os-vif and os-acc approaches.


This discussion is important because we may have programmable NICs based 
on FPGAs. Then Cyborg, Neutron and Nova are going to get tangled in a 
triangle. (If you throw Glance in for FPGA images, that leads quickly to 
a quadrilateral. Add Cinder for storage-related FPGA devices, and we get 
pulled into a pentagram. Geometry is scary. Just saying. ;-} )


* Not enough detail in [1]. Mea culpa. Hopefully fixed now.

[1] https://review.openstack.org/#/c/566798/

[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-06-14.log.html#t2018-06-14T18:38:28 



[3] 
https://review.openstack.org/#/c/575545/1/specs/rocky/approved/nova-cyborg-flow.rst 



[4] https://etherpad.openstack.org/p/os-acc-discussion

[5] 
https://docs.google.com/drawings/d/1gbfimiyA1f5sTeobN9mpavEkHT7Z_ScNUqimOkdIYGA/edit 



[6] 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-06-18.log.html#t2018-06-18T22:07:02 



Regards,
Sundar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [telemetry][ceilometer][monasca] Monasca publisher for Ceilometer

[Bedyk, Witold]

Sounds great. Going to get a cold beer to celebrate that ;)

Witek

> -Original Message-
> From: Julien Danjou 
> Sent: Freitag, 22. Juni 2018 16:51
> To: Bedyk, Witold 
> Cc: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [telemetry][ceilometer][monasca] Monasca
> publisher for Ceilometer
> 
> On Fri, Jun 22 2018, Bedyk, Witold wrote:
> 
> > You've said lacking manpower is currently the main issue in Ceilometer
> > which stops you from accepting new publishers and that you don't want
> > to add maintenance overhead.
> >
> > We're offering help on maintaining the project.
> 
> Oh cool, I misunderstood. I though you were offering only help for
> maintaining your publisher. That sounds great.
> We never worked with each other yet, so it'd be hard for us to add you right
> away to the core team — but we'd be more than happy to see how you can
> help and bring you in ASAP!
> 
> --
> Julien Danjou
> ;; Free Software hacker
> ;; https://julien.danjou.info
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [telemetry][ceilometer][monasca] Monasca publisher for Ceilometer

[Julien Danjou]

On Fri, Jun 22 2018, Bedyk, Witold wrote:

> You've said lacking manpower is currently the main issue in Ceilometer which
> stops you from accepting new publishers and that you don't want to add
> maintenance overhead.
>
> We're offering help on maintaining the project.

Oh cool, I misunderstood. I though you were offering only help for
maintaining your publisher. That sounds great.
We never worked with each other yet, so it'd be hard for us to add you
right away to the core team — but we'd be more than happy to see how you
can help and bring you in ASAP!

-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Keystone Team Update - Week of 18 June 2018

[Eric Fried]

Also:

keystoneauth1 3.9.0 was released.  Its new feature is the ability to set
raise_exc on the Adapter object so you don't have to do it per request.
Here's a patch that makes use of the feature:
https://review.openstack.org/#/c/577437/

-efried

On 06/22/2018 06:53 AM, Colleen Murphy wrote:
> # Keystone Team Update - Week of 18 June 2018
> 
> ## News
> 
> ### Default Roles Fallout
> 
> Our change to automatically create the 'reader' and 'member' roles during 
> bootstrap[1] caused some problems in the CI of other projects[2]. One problem 
> was that projects were manually creating a 'Member' role, and with the 
> database backend being case-insensitve, there would be a conflict with the 
> 'member' role that keystone is now creating. The immediate fix is to ensure 
> the clients in CI are checking for the 'member' role rather than the 'Member' 
> role before trying to create either role, but in the longer term, clients 
> would benefit from decoupling the API case sensitivity from the configuration 
> of the database backend[3].
> 
> Another problem was a bug related to implied roles in trusts[4]. If a role 
> implies another, but a trust is created with both roles explicitly, the token 
> will contain duplicate role names, which breaks the usage of trusts and hit 
> Sahara. This issue would have existed before, but was only discovered now 
> that we have implied roles by default.
> 
> [1] https://review.openstack.org/572243
> [2] 
> http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-19-16.00.log.html#l-24
> [3] 
> http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-19-16.00.log.html#l-175
> [4] https://bugs.launchpad.net/keystone/+bug/1778109
> 
> ### Limits Schema Restructuring
> 
> Morgan discovered some problems with the database schemas[5] for registered 
> limits and project limits and proposed that we can improve performance and 
> reduce data duplication by doing some restructuring and adding some indexes. 
> The migration path to the new schema is tricky[6] and we're still trying to 
> come up with a strategy that avoids triggers[7].
> 
> [5] 
> http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-19-16.00.log.html#l-184
> [6] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-06-19.log.html#t2018-06-19T21:04:05
> [7] https://etherpad.openstack.org/p/keystone-unified-limit-migration-notepad
> 
> ### No-nitpicking Culture
> 
> Following the community discussion on fostering a healthier culture by 
> avoiding needlessly nitpicking changes[8], the keystone team had a thoughtful 
> discussion on what constitutes nitpicking and how we should be voting on 
> changes[9]. Context is always important, and considering who the author is, 
> how significant the imperfection is, and how much effort it will take the 
> author to correct it should to be considered when deciding whether to ask 
> them to change something about their patch versus proposing yor own fix in a 
> folllowup. I've always been proud of keystone's no-nitpicking culture and 
> it's encouraging to see continuous introspection.
> 
> [8] https://governance.openstack.org/tc/reference/principles.html
> [9] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-06-19.log.html#t2018-06-19T21:18:01
> 
> ## Recently Merged Changes
> 
> Search query: https://bit.ly/2IACk3F
> 
> We merged 16 changes this week, including client support for limits and a 
> major bugfix for implied roles.
> 
> ## Changes that need Attention
> 
> Search query: https://bit.ly/2wv7QLK
> 
> There are 57 changes that are passing CI, not in merge conflict, have no 
> negative reviews and aren't proposed by bots, so their authors are waiting 
> for any feedback.
> 
> ## Bugs
> 
> This week we opened 5 new bugs and closed 4.
> 
> Bugs opened (5) 
> Bug #1777671 (keystone:Medium) opened by Morgan Fainberg 
> https://bugs.launchpad.net/keystone/+bug/1777671 
> Bug #1777892 (keystone:Medium) opened by Lance Bragstad 
> https://bugs.launchpad.net/keystone/+bug/1777892 
> Bug #1777893 (keystone:Medium) opened by Lance Bragstad 
> https://bugs.launchpad.net/keystone/+bug/1777893 
> Bug #1778023 (keystone:Undecided) opened by kirandevraaj 
> https://bugs.launchpad.net/keystone/+bug/1778023 
> Bug #1778109 (keystone:Undecided) opened by Jeremy Freudberg 
> https://bugs.launchpad.net/keystone/+bug/1778109 
> 
> Bugs closed (2) 
> Bug #1758460 (keystone:Low) https://bugs.launchpad.net/keystone/+bug/1758460 
> Bug #1774654 (keystone:Undecided) 
> https://bugs.launchpad.net/keystone/+bug/1774654 
> 
> Bugs fixed (2) 
> Bug #1754184 (keystone:Medium) fixed by wangxiyuan 
> https://bugs.launchpad.net/keystone/+bug/1754184 
> Bug #1774229 (keystone:Medium) fixed by Lance Bragstad 
> https://bugs.launchpad.net/keystone/+bug/1774229
> 
> ## Milestone Outlook
> 
> https://releases.openstack.org/rocky/schedule.html
> 
> This week is our feature proposal freeze de

Re: [openstack-dev] [telemetry][ceilometer][monasca] Monasca publisher for Ceilometer

[Chris Dent]

On Fri, 22 Jun 2018, Bedyk, Witold wrote:


You've said lacking manpower is currently the main issue in
Ceilometer which stops you from accepting new publishers and that
you don't want to add maintenance overhead.


I've lost track of the details of the thread, can you remind me why
keeping the plugin as an external (perhaps packaged with monasca
itself) is not a good option? As I understood things, that was the
benefit of the plugin architecture.


We're offering help on maintaining the project.


I think this could potentially be a great option, if everyone
involved thinks it is a good idea, but it is somewhat orthogonal to
the question above about being an external plugin.


--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [telemetry][ceilometer][monasca] Monasca publisher for Ceilometer

[Bedyk, Witold]

You've said lacking manpower is currently the main issue in Ceilometer which 
stops you from accepting new publishers and that you don't want to add 
maintenance overhead.

We're offering help on maintaining the project.

Cheers
Witek


> -Original Message-
> From: Julien Danjou 
> Sent: Freitag, 22. Juni 2018 15:48
> To: Bedyk, Witold 
> Cc: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [telemetry][ceilometer][monasca] Monasca
> publisher for Ceilometer
> 
> On Fri, Jun 22 2018, Bedyk, Witold wrote:
> 
> > I know it's not how it normally works, but in that case it seems to be
> > a clear win-win situation.
> 
> I'm sorry, I really don't see what's the win for Ceilometer or its developer.
> Could you elaborate?
> 
> --
> Julien Danjou
> ;; Free Software hacker
> ;; https://julien.danjou.info

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [telemetry][ceilometer][monasca] Monasca publisher for Ceilometer

[Julien Danjou]

On Fri, Jun 22 2018, Bedyk, Witold wrote:

> I know it's not how it normally works, but in that case it seems to be a clear
> win-win situation.

I'm sorry, I really don't see what's the win for Ceilometer or its
developer. Could you elaborate?

-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kayobe] Kayobe update

[Mark Goddard]

Hi all,

I thought it might be useful to start an irregular update on Kayobe,
covering recent and upcoming events. This follows on from the update blog
article [1] that I wrote a couple of months ago (which includes a video and
asciinema demo!).

# OpenStack-related

The switch to using OpenStack infrastructure was completed successfully,
and went relatively smoothly. The more thorough CI testing enabled by Zuul
has helped to increase confidence in new changes, and has caught a few bugs
that might previously have slipped through the net. We have a good baseline
of test coverage, but should continue working to ensure coverage continues
to improve.

# Queens & beyond

Kayobe tends to trail the OpenStack and Kolla release cycles somewhat,
largely driven by demand for new Kayobe features on stable OpenStack
releases. We recently added support support for deploying the Queens
release to the Kayobe master branch, and now enforce a stable policy on the
stable/pike branch. There is a patch [2] up to switch to master branches of
dependencies that allows us to keep on top of the required changes for
Rocky.

# Recently added features

* Custom Ansible playbooks [3] allow us to keep the core of Kayobe
relatively lightweight, while supporting arbitrary extensions.
* Automatic naming of bare metal compute nodes based on inventory & IPMI
address [4]
* Separate cleaning network for ironic [5]

# Upcoming features

* Deployment pipeline configuration [6] will provide enhancements to the
kayobe-config structure to support deploying to multiple environments
(think dev/staging/prod) from a single kayobe-config repository
* Ansible 2.5 support [7]
* Admin/SSH network [8] allows us to stop using the provisioning network
for SSH access
* Support for deploying Monasca [9] (most work is in kolla)

# Will Szumski

Based on Will's recent contributions to Kayobe, and how quickly he's come
up to speed, he's been added to kayobe-core. Congratulations Will!

As always, feel free to drop into IRC with questions: #openstack-kayobe

[1] http://www.stackhpc.com/kayobe-update.html
[2] https://review.openstack.org/#/c/568804
[3] https://kayobe.readthedocs.io/en/latest/custom-ansible-playbooks.html
[4] https://storyboard.openstack.org/#!/story/2002176
[5] https://storyboard.openstack.org/#!/story/2002097
[6] https://storyboard.openstack.org/#!/story/2002009
[7] https://storyboard.openstack.org/#!/story/2001649
[8] https://storyboard.openstack.org/#!/story/2002096
[9] https://storyboard.openstack.org/#!/story/2001627

Cheers,
Mark
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [telemetry][ceilometer][monasca] Monasca publisher for Ceilometer

[Bedyk, Witold]

Hi Julien and Mehdi,

I obviously care more about Monasca and integration with other OpenStack 
projects. If the publisher wouldn't be an important piece of the puzzle I 
wouldn't be pushing this.

I have stressed a couple of times that we are ready to take the complete 
responsibility for the code and its maintenance. If manpower is an issue, what 
about an idea of adding one or two of us to the core reviewers group? We don't 
have the expertise to approve the changes in the core agent, but we could help 
on simple maintenance tasks and of course keeping our publisher running and 
bugfixing.

I know it's not how it normally works, but in that case it seems to be a clear 
win-win situation.

What do you say?

Wish you a nice weekend
Witek


> -Original Message-
> From: Julien Danjou 
> Sent: Mittwoch, 20. Juni 2018 16:26
> To: Bedyk, Witold 
> Cc: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [telemetry][ceilometer][monasca] Monasca
> publisher for Ceilometer
> 
> On Wed, Jun 20 2018, Bedyk, Witold wrote:
> 
> Hi Witek,
> 
> It's not a transparency issue. It's a manpower issue. We are only 2 developers
> active on Ceilometer: me and Mehdi. Neither me nor Mehdi wants to
> maintain Monasca stuff; meaning, we don't want to spend time reviewing
> patches, having bug opened, or whatever. There's no interest for us in that.
> 
> THe Prometheus publisher you mention has been written by Mehdi and
> we've approved it because it fits the roadmap of the Ceilometer developers
> that we are — and, again we're just two.
> 
> We have other projects — such as Panko — that provide Ceilometer
> publishers and their code is in Panko, not in Ceilometer. It's totally 
> possible
> and sane.
> 
> Now, if you really, really, care that much about Ceilometer and its 
> integration
> with Monasca, and if you have an amazing roadmap that'll make Ceilometer
> better and awesome, please, do start with that.
> 
> Right now it just looks like more work for us with no gain. :(
> 
> > could you please add some transparency to the decision process on
> > which publishers are acceptable and which not? Just two months ago you
> > have added new Prometheus publisher. That's around the same time
> when
> > our code was submitted to review.
> >
> > We have delivered tested code and offer its maintenance. The code is
> > self-contained and does not touch Ceilometer core. If it's broken,
> > just Monasca interface won't work.
> >
> > Please reconsider it again.
> >
> > Greetings
> > Witek
> >
> >
> >> -Original Message-
> >> From: Julien Danjou 
> >> Sent: Mittwoch, 20. Juni 2018 14:07
> >> To: Bedyk, Witold 
> >> Cc: OpenStack Development Mailing List (not for usage questions)
> >> 
> >> Subject: Re: [openstack-dev] [telemetry][ceilometer][monasca] Monasca
> >> publisher for Ceilometer
> >>
> >> On Wed, Jun 20 2018, Bedyk, Witold wrote:
> >>
> >> Same as Gordon. You should maintain that in your own repo.
> >> There's just no bandwidth in Ceilometer right now for things like that.
> >> :(
> >>
> >> > Hello Telemetry Team,
> >> >
> >> > any opinion on this?
> >> >
> >> > Best greetings
> >> > Witek
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: Bedyk, Witold 
> >> >> Sent: Mittwoch, 13. Juni 2018 10:28
> >> >> To: OpenStack Development Mailing List (not for usage questions)
> >> >> 
> >> >> Subject: [openstack-dev] [telemetry][ceilometer][monasca] Monasca
> >> >> publisher for Ceilometer
> >> >>
> >> >> Hello Telemetry Team,
> >> >>
> >> >> We would like to contribute a Monasca publisher to Ceilometer
> >> >> project [1] and add it to the list of currently supported transports 
> >> >> [2].
> >> >> The goal of the plugin is to send Ceilometer samples to Monasca API.
> >> >>
> >> >> I understand Gordon's concerns about adding maintenance overhead
> >> >> for Ceilometer team which he expressed in review but the code is
> >> >> pretty much self-contained and does not affect Ceilometer core.
> >> >> It's not our intention to shift the maintenance effort and Monasca
> >> >> team should still be responsible for this code.
> >> >>
> >> >> Adding this plugin will help in terms of interoperability of both
> >> >> projects and can be useful for wider parts of the OpenStack
> community.
> >> >>
> >> >> Please let me know your thoughts. I hope we can get this code
> merged.
> >> >>
> >> >> Cheers
> >> >> Witek
> >> >>
> >> >>
> >> >> [1] https://review.openstack.org/562400
> >> >> [2]
> >> >> https://docs.openstack.org/ceilometer/latest/contributor/architect
> >> >> ure
> >> >> .html
> >> >> #processing-the-data
> >> >
> >>
> >> --
> >> Julien Danjou
> >> /* Free Software hacker
> >>https://julien.danjou.info */
> >
> >
> 
> --
> Julien Danjou
> ;; Free Software hacker
> ;; https://julien.danjou.info
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.o

[openstack-dev] [keystone] Keystone Team Update - Week of 18 June 2018

[Colleen Murphy]

# Keystone Team Update - Week of 18 June 2018

## News

### Default Roles Fallout

Our change to automatically create the 'reader' and 'member' roles during 
bootstrap[1] caused some problems in the CI of other projects[2]. One problem 
was that projects were manually creating a 'Member' role, and with the database 
backend being case-insensitve, there would be a conflict with the 'member' role 
that keystone is now creating. The immediate fix is to ensure the clients in CI 
are checking for the 'member' role rather than the 'Member' role before trying 
to create either role, but in the longer term, clients would benefit from 
decoupling the API case sensitivity from the configuration of the database 
backend[3].

Another problem was a bug related to implied roles in trusts[4]. If a role 
implies another, but a trust is created with both roles explicitly, the token 
will contain duplicate role names, which breaks the usage of trusts and hit 
Sahara. This issue would have existed before, but was only discovered now that 
we have implied roles by default.

[1] https://review.openstack.org/572243
[2] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-19-16.00.log.html#l-24
[3] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-19-16.00.log.html#l-175
[4] https://bugs.launchpad.net/keystone/+bug/1778109

### Limits Schema Restructuring

Morgan discovered some problems with the database schemas[5] for registered 
limits and project limits and proposed that we can improve performance and 
reduce data duplication by doing some restructuring and adding some indexes. 
The migration path to the new schema is tricky[6] and we're still trying to 
come up with a strategy that avoids triggers[7].

[5] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-19-16.00.log.html#l-184
[6] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-06-19.log.html#t2018-06-19T21:04:05
[7] https://etherpad.openstack.org/p/keystone-unified-limit-migration-notepad

### No-nitpicking Culture

Following the community discussion on fostering a healthier culture by avoiding 
needlessly nitpicking changes[8], the keystone team had a thoughtful discussion 
on what constitutes nitpicking and how we should be voting on changes[9]. 
Context is always important, and considering who the author is, how significant 
the imperfection is, and how much effort it will take the author to correct it 
should to be considered when deciding whether to ask them to change something 
about their patch versus proposing yor own fix in a folllowup. I've always been 
proud of keystone's no-nitpicking culture and it's encouraging to see 
continuous introspection.

[8] https://governance.openstack.org/tc/reference/principles.html
[9] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-06-19.log.html#t2018-06-19T21:18:01

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 16 changes this week, including client support for limits and a major 
bugfix for implied roles.

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 57 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots, so their authors are waiting for 
any feedback.

## Bugs

This week we opened 5 new bugs and closed 4.

Bugs opened (5) 
Bug #1777671 (keystone:Medium) opened by Morgan Fainberg 
https://bugs.launchpad.net/keystone/+bug/1777671 
Bug #1777892 (keystone:Medium) opened by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1777892 
Bug #1777893 (keystone:Medium) opened by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1777893 
Bug #1778023 (keystone:Undecided) opened by kirandevraaj 
https://bugs.launchpad.net/keystone/+bug/1778023 
Bug #1778109 (keystone:Undecided) opened by Jeremy Freudberg 
https://bugs.launchpad.net/keystone/+bug/1778109 

Bugs closed (2) 
Bug #1758460 (keystone:Low) https://bugs.launchpad.net/keystone/+bug/1758460 
Bug #1774654 (keystone:Undecided) 
https://bugs.launchpad.net/keystone/+bug/1774654 

Bugs fixed (2) 
Bug #1754184 (keystone:Medium) fixed by wangxiyuan 
https://bugs.launchpad.net/keystone/+bug/1754184 
Bug #1774229 (keystone:Medium) fixed by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1774229

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

This week is our feature proposal freeze deadline. All our major efforts seem 
to have at least one initial patch proposed for them.

The keystone feature freeze is only 3 weeks away. The final release for 
non-client libraries is the week after that[10], so we need to ensure that all 
the work needed especially for keystonemiddleware is completed by them.

[10] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131732.html

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.ope

Re: [openstack-dev] Openstack-Zun Service Appears down

[Usman Awais]

Hi Hongbin,

Many thanks, got it running, that was awesom... :) The problem was
unsynched time. I installed chrony and it started working.

Now I am running into another problem; the networking of the container. The
container gets started, I can shell into it through appcontainer API, it
even gets the correct IP address of my private network (named priv-net) in
openstack, through DHCP. But when I ping any address, even the address of
the priv-net's gateway, it does nothing. I have following configuration

neutron-openvswitch-agent is running
neutron-ovs-cleanup is  running
neutron-destroy-patch-ports is running
kuryr-libnetwork is running
docker is running
zun-compute is running

The eth0 network card has standard configuration of an OVSBridge.

When I create a new container it also creates taps and patch ports on the
compute node. Now I am going to try to use kuryr script to test what
happens with "bridged" and "host" networks.

Muhammad Usman Awais



On Thu, Jun 21, 2018 at 1:14 PM, Hongbin Lu  wrote:

> HI  Muhammad,
>
> Here is the code (run in controller node) that decides whether a service
> is up https://github.com/openstack/zun/blob/master/zun/api/servicegroup.py
> . There are several possibilities to cause a service to be 'down':
> 1. The service was being 'force_down' via API (e.g. explicitly issued a
> command like "appcontainer service forcedown")
> 2. The zun compute process is not doing the heartbeat for a certain period
> of time (CONF.service_down_time).
> 3. The zun compute process is doing the heartbeat properly but the time
> between controller node and compute node is out of sync.
>
> In before, #3 is the common pitfall that people ran into. If it is not #3,
> you might want to check if the zun compute process is doing the heartbeat
> properly. Each zun compute process is running a periodic task to update its
> state in DB: https://github.com/openstack/zun/blob/master/zun/
> servicegroup/zun_service_periodic.py . The call of ' report_state_up '
> will record this service is up in DB at current time. You might want to
> check if this periodic task is running properly, or if the current state is
> updated in the DB.
>
> Above is my best guess. Please feel free to follow it up with me or other
> team members if you need further assistant for this issue.
>
> Best regards,
> Hongbin
>
> On Wed, Jun 20, 2018 at 9:14 AM Usman Awais  wrote:
>
>> Dear Zuners,
>>
>> I have installed RDO pike. I stopped openstack-nova-compute service on
>> one of the hosts, and installed a zun-compute service. Although all the
>> services seems to be running ok on both controller and compute but when I
>> do
>>
>>  openstack appcontainer service list
>>
>> It gives me following
>>
>> ++--+-+---+--+--
>> ---+-+---+
>> | Id | Host | Binary  | State | Disabled | Disabled Reason |
>> Updated At  | Availability Zone |
>> ++--+-+---+--+--
>> ---+-+---+
>> |  1 | node1.os.lab | zun-compute | down  | False| None|
>> 2018-06-20 13:14:31 | nova  |
>> ++--+-+---+--+--
>> ---+-+---+
>>
>> I have checked all ports in both directions they are open, including etcd
>> ports and others. All services are running, only docker service has the
>> warning message saying "failed to retrieve docker-runc version: exec:
>> \"docker-runc\": executable file not found in $PATH". There is also a
>> message at zun-compute "/usr/lib64/python2.7/site-
>> packages/sqlalchemy/sql/default_comparator.py:161: SAWarning: The
>> IN-predicate on "container.uuid" was invoked with an empty sequence. This
>> results in a contradiction, which nonetheless can be expensive to
>> evaluate.  Consider alternative strategies for improved performance."
>>
>> Please guide...
>>
>> Regards,
>> Muhammad Usman Awais
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][api[[graphql] A starting point

[Tristan Cacqueray]

On June 22, 2018 8:01 am, Flint WALRUS wrote:

About your code, I feel that we should extract the schemas from the base.py
under neutron/api/graphql/schemas/ right now before the code became to
large, that would then allows for a better granularity.

Thanks.



Since this is the graphql branch, maybe we should use the neutron model
directly by adding the graphene SQLAlchemyObjectType parent and the Meta
class.

-Tristan


pgpPJx2xGVEBf.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [sahara] Anti-Affinity Broke

[Luigi Toscano]

On Friday, 22 June 2018 05:00:16 CEST Joe Topjian wrote:
> Hello,
> 
> I originally posted this to the general openstack list to get a sanity
> check on what I was seeing. Jeremy F reached out and confirmed that, so I'm
> going to re-post the details here to begin a discussion.

Hi,

thanks for investigating the issue; it's not the most trivial thing to test 
without a real CI system based on baremetal, and we don't have one at this 
time.

> I can also create something on StoryBoard for this, too.

Yes, that would be preferred; could you please open it describing the symptoms 
that you found in addition to the workarounds?

Ciao
-- 
Luigi



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][api[[graphql] A starting point

[Flint WALRUS]

Hi Gilles, I just had a look at your patch, cool, thanks for the work.

ok, that good to start with a limited subsets of query types indeed, you're
right.

Ok, perfect for the patch to branch, I don't know why but I had the feeling
that you were requesting for the branch to be merged back and not for the
patch :D I just read my emails too quickly I suppose.

About your code, I feel that we should extract the schemas from the base.py
under neutron/api/graphql/schemas/ right now before the code became to
large, that would then allows for a better granularity.

Thanks.

Le ven. 22 juin 2018 à 08:42, Gilles Dubreuil  a
écrit :

>
>
> On 22/06/18 15:57, Flint WALRUS wrote:
>
> Hi everyone,
>
> Thanks for the updates and support, that appreciated.
>
> @Gilles, did you already implemented all the service types?
>
>
> We have query types for networks and subnets for now.
> Before we add more we are going to focus on oslo policies so we can access
> and modify those items in respect of the existing security approach.
> Then we will have a solid foundation to add more types.
>
>
>
> What is left to do? You already want to merge the feature branch with
> master?
>
>
> The feature branch graphql is the Proof of Concept and won't be merged to
> master until we have it full ready to share/demonstrate it to others.
> So we're pushing patches against that branch. The initial one to be
> hopefully merged soon.
>
>
>
> @tristan I’d like to work on the feature branch but I’ll wait for gilles
> answers as I don’t want to mess up having pieces of code everywhere.
>
> Thanks!
> Le ven. 22 juin 2018 à 06:44, Gilles Dubreuil  a
> écrit :
>
>>
>> On 22/06/18 09:21, Tristan Cacqueray wrote:
>>
>> Hi Flint,
>>
>> On June 21, 2018 5:32 pm, Flint WALRUS wrote:
>>
>> Hi everyone, sorry for the late answer but I’m currently trapped into a
>> cluster issue with cinder-volume that doesn’t give me that much time.
>>
>> That being said, I’ll have some times to work on this feature during the
>> summer (July/August) and so do some coding once I’ll have catched up with
>> your work.
>>
>> That's great to hear! The next step is to understand how to deal with
>> oslo policy and control objects access/modification.
>>
>> Did you created a specific tree or did you created a new graphql folder
>> within the neutron/neutron/api/ path regarding the schemas etc?
>>
>>
>> There is a feature/graphql branch were an initial patch[1] adds a new
>> neutron/api/graphql directory as well as a new test_graphql.py
>> functional tests.
>> The api-paste is also updated to expose the '/graphql' http endpoint.
>>
>> Not sure if we want to keep on updating that change, or propose further
>> code as new change on top of this skeleton?
>>
>>
>> Makes sense to merge it, I think we have the base we needed to get going.
>> I'll make it green so we can get merge it.
>>
>>
>> Regards,
>> -Tristan
>>
>>
>> Le sam. 16 juin 2018 à 08:42, Tristan Cacqueray 
>>  a
>> écrit :
>>
>> On June 15, 2018 10:42 pm, Gilles Dubreuil wrote:
>> > Hello,
>> >
>> > This initial patch [1]  allows to retrieve networks, subnets.
>> >
>> > This is very easy, thanks to the graphene-sqlalchemy helper.
>> >
>> > The edges, nodes layer might be confusing at first meanwhile they make
>> > the Schema Relay-compliant in order to offer re-fetching, pagination
>> > features out of the box.
>> >
>> > The next priority is to set the unit test in order to implement
>> mutations.
>> >
>> > Could someone help provide a base in order to respect Neutron test
>> > requirements?
>> >
>> >
>> > [1] [abandoned]
>>
>> Actually, the correct review (proposed on the feature/graphql branch)
>> is:
>>
>> [1] https://review.openstack.org/575898
>>
>> >
>> > Thanks,
>> > Gilles
>> >
>> >
>> __
>>
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> --
>> Gilles Dubreuil
>> Senior Software Engineer -