Re: [openstack-dev] [neutron] out-of-tree l3 service providers

[Isaku Yamahata]

On Fri, Sep 08, 2017 at 12:26:56PM +0900,
Takashi Yamamoto  wrote:

> hi,
> 
> On Fri, Sep 8, 2017 at 5:52 AM, Isaku Yamahata  
> wrote:
> > Hi.
> >
> > Any update on this? Now L3 service provider got the time slot at the PTG.
> >
> > Yamamoto, do you have any proposal for the interface?
> 
> no
> 
> > Although ODL surely is interested in L3 flavor, the networking-odl team 
> > hasn't
> > spec or experimental patch yet unfortunately.
> 
> can you at least provide your requirements?

Sure.

networking-odl needs PRECOMMIT/AFTER_CREATE/UPDATE/DELETE for
router/floaringip and PRECOMMIT for disassociate_floatingip.
The reason why precommit_disassociate_floatingip is needed is that
right now ODL doesn't support to updating floatingip status by ODL.
So floatingip status is forcibly set to DOWN by the callback for now.
(It's in future roadmap)
networking-odl doesn't need callback for add/remove_router_interface because
only db operation does. ODL identifies router interface by port:owner which is
updated by update_port.

Thanks,

> networking-midonet needs to send the following info to its backend on
> AFTER_CREATE/AFTER_UPDATE for router, router_interface, and
> floating_ip.
> https://github.com/midonet/midonet/blob/fcc127f5c9216b7a563c89d2684461428feb9a67/nsdb/src/main/proto/neutron.proto#L129-L161
> (some of fields are actually unused right now. eg. tenant_id)
> on AFTER_DELETE, we only need "id" field of the resource.
> in feature we want to use PRECOMMIT_xxx events as well. necessary
> fields are same as AFTER_xxx.
> 
> > Dragon flow folks seems to have their own spec.
> >
> > thanks,
> >
> > On Mon, Jul 31, 2017 at 02:10:07PM +0900,
> > Takashi Yamamoto  wrote:
> >
> >> hi,
> >>
> >> On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton  wrote:
> >> > If I understand the main issue with using regular callbacks, it's mainly
> >> > just that the flavor assignment itself is in a callback, right?
> >>
> >> yes.
> >>
> >> >
> >> > If so, couldn't we solve the problem by just moving flavor assignment to 
> >> > an
> >> > explicit call before emitting the callbacks? Or would that still result 
> >> > in
> >> > other ordering issues?
> >>
> >> it would solve the problem for CREATE.
> >> for UPDATE and DELETE, i'm not sure.
> >> UPDATE can change the flavor but it's supposed to be a special case
> >> only for dvr/ha, right?
> >> AFTER_DELETE might be tricky as we probably need to provide flavor
> >> info to subscribers.
> >>
> >> >
> >> > On Thu, Jul 13, 2017 at 3:01 AM, Takashi Yamamoto 
> >> > wrote:
> >> >>
> >> >> hi,
> >> >>
> >> >> today i managed to play with l3 flavors.
> >> >> i wrote a crude patch to implement midonet flavor. [1]
> >> >>
> >> >> [1] https://review.openstack.org/#/c/483174/
> >> >>
> >> >> a good news is it's somehow working.
> >> >>
> >> >> a bad news is it has a lot of issues, as you can see in TODO comments
> >> >> in the patch.
> >> >> given these issues, now i tend to think it's cleaner to introduce
> >> >> ml2-like precommit/postcommit driver api (or its equivalent via
> >> >> callbacks) rather than using these existing notifications.
> >> >>
> >> >> how do you think?
> >> >
> >> >
> >>
> >> __
> >> 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
> >
> > --
> > Isaku Yamahata 

-- 
Isaku Yamahata 

__
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] Hello everyone, ask a few vm hot plug cpu and ram problem [nova]

[Paul Schlacter]

Like CPU and ram have a maximum value. If I want to produce this product,
provided to the cloud host users.  The maximum value is set to how much
more appropriate.


If the settings are too small, users want to dynamically add CPU or memory,
and can't meet the needs of users.


If the setting is too large, such as max memory set to 40G, current memory
is set to 2G, the virtual machine memory only 1G more, much less than 2G.
If this value is set too large,  Are there any other effects?


Ask your advice.
__
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] out-of-tree l3 service providers

[Takashi Yamamoto]

hi,

On Fri, Sep 8, 2017 at 5:52 AM, Isaku Yamahata  wrote:
> Hi.
>
> Any update on this? Now L3 service provider got the time slot at the PTG.
>
> Yamamoto, do you have any proposal for the interface?

no

> Although ODL surely is interested in L3 flavor, the networking-odl team hasn't
> spec or experimental patch yet unfortunately.

can you at least provide your requirements?

networking-midonet needs to send the following info to its backend on
AFTER_CREATE/AFTER_UPDATE for router, router_interface, and
floating_ip.
https://github.com/midonet/midonet/blob/fcc127f5c9216b7a563c89d2684461428feb9a67/nsdb/src/main/proto/neutron.proto#L129-L161
(some of fields are actually unused right now. eg. tenant_id)
on AFTER_DELETE, we only need "id" field of the resource.
in feature we want to use PRECOMMIT_xxx events as well. necessary
fields are same as AFTER_xxx.

> Dragon flow folks seems to have their own spec.
>
> thanks,
>
> On Mon, Jul 31, 2017 at 02:10:07PM +0900,
> Takashi Yamamoto  wrote:
>
>> hi,
>>
>> On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton  wrote:
>> > If I understand the main issue with using regular callbacks, it's mainly
>> > just that the flavor assignment itself is in a callback, right?
>>
>> yes.
>>
>> >
>> > If so, couldn't we solve the problem by just moving flavor assignment to an
>> > explicit call before emitting the callbacks? Or would that still result in
>> > other ordering issues?
>>
>> it would solve the problem for CREATE.
>> for UPDATE and DELETE, i'm not sure.
>> UPDATE can change the flavor but it's supposed to be a special case
>> only for dvr/ha, right?
>> AFTER_DELETE might be tricky as we probably need to provide flavor
>> info to subscribers.
>>
>> >
>> > On Thu, Jul 13, 2017 at 3:01 AM, Takashi Yamamoto 
>> > wrote:
>> >>
>> >> hi,
>> >>
>> >> today i managed to play with l3 flavors.
>> >> i wrote a crude patch to implement midonet flavor. [1]
>> >>
>> >> [1] https://review.openstack.org/#/c/483174/
>> >>
>> >> a good news is it's somehow working.
>> >>
>> >> a bad news is it has a lot of issues, as you can see in TODO comments
>> >> in the patch.
>> >> given these issues, now i tend to think it's cleaner to introduce
>> >> ml2-like precommit/postcommit driver api (or its equivalent via
>> >> callbacks) rather than using these existing notifications.
>> >>
>> >> how do you think?
>> >
>> >
>>
>> __
>> 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
>
> --
> Isaku Yamahata 

__
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] removing screen from devstack - RSN

[John Griffith]

On Thu, Sep 7, 2017 at 7:07 PM, Sean Dague  wrote:

> On 09/07/2017 04:54 PM, Eric Fried wrote:
>
>> All-
>>
>> The plain pdb doc patch [1] is merging.
>>
>> On clarkb's suggestion, I took a look at remote-pdb [2], and it
>> turned
>> out to be easy-peasy to use.  I submitted a followon doc patch for that
>> [3].
>>
>> Thanks, John, for speaking up and getting this rolling.
>>
>> Eric
>>
>
> Approved for merge, should be in shortly.
>
> Eric, thanks again for stepping up and pulling this all together. Very
> much appreciated.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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
>
​Thanks everyone, and thanks sdague for driving this to begin with!​
__
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] [oslo] No meeting on next Monday( Sep 11th)

[ChangBo Guo]

Most of us will attend the PTG, so there is no weekly meeting next Monday.

-- 
ChangBo Guo(gcb)
__
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] removing screen from devstack - RSN

[Sean Dague]

On 09/07/2017 04:54 PM, Eric Fried wrote:

All-

The plain pdb doc patch [1] is merging.

On clarkb's suggestion, I took a look at remote-pdb [2], and it turned
out to be easy-peasy to use.  I submitted a followon doc patch for that [3].

Thanks, John, for speaking up and getting this rolling.

Eric


Approved for merge, should be in shortly.

Eric, thanks again for stepping up and pulling this all together. Very 
much appreciated.


-Sean

--
Sean Dague
http://dague.net

__
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] - PTG neutron attendee info

[Kevin Benton]

Hello everyone,

With the help of Miguel we have a tentative schedule in the PTG. Please
check the etherpad and if there is anything missing you wanted to see
discussed, please reach out to me or Miguel right away to get it added.

Cheers,
Kevin Benton

On Thu, Jul 27, 2017 at 9:53 PM, Kevin Benton  wrote:

> Hi all,
>
> If you are planning on attending the PTG and the Neutron sessions, please
> add your name to the etherpad[1] so we can get a rough size estimate.
>
>
> 1. https://etherpad.openstack.org/p/neutron-queens-ptg
>
> Cheers,
> Kevin Benton
>
__
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] [all] Cinder V1 API Removal

[Sean McGinnis]

Just a heads up for anyone consuming Cinder APIs. The v1 API was 
deprecated in the Juno release, but
we've kept it around for quite awhile because we knew there were client 
implementations out there that

were lagging in getting up to date.

Well, it's now been many releases, and we've had the v1 API disabled by 
default for awhile now. Patch
https://review.openstack.org/#/c/499342/ now removes that API. Queens 
onward, it will not be possible

to run with V1 anymore.

The v3 API is the currently supported version. All tools and 
integrations should now be targeting that API.
This will hopefully be the final API version going forward, with all 
updates and changes being implemented

as microversions under the v3.0 version.

Thanks,

Sean


__
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] [nova] [neutron] Adding neutron VIF NUMA locality support

[Eric Fried]

Stephen-

FYI, we're teeing up (anti-)affinity and neutron-nova interaction
topics for the "generic device management" discussions at the PTG.
Please jump on the etherpad [1] and expand/expound in the relevant
spots, which, as of this writing, you can find by searching for
"aggregate", "vf selection policy", and "interplay".

Thanks,
Eric

[1]
https://etherpad.openstack.org/p/nova-ptg-queens-generic-device-management

On 09/07/2017 01:07 PM, Mooney, Sean K wrote:
> 
> 
>> -Original Message-
>> From: Stephen Finucane [mailto:sfinu...@redhat.com]
>> Sent: Thursday, September 7, 2017 5:42 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Cc: Jakub Libosvar ; Karthik Sundaravel
>> ; Mooney, Sean K 
>> Subject: [nova] [neutron] Adding neutron VIF NUMA locality support
>>
>> Hey,
>>
>> NUMA locality matters as much for NICs used e.g for Open vSwitch as for
>> SR-IOV devices. At the moment, nova support NUMA affinity for PCI
>> passthrough devices and SR-IOV devices, but it makes no attempt to do
>> the same for other NICs. In the name of NFV enablement, we should
>> probably close this gap.
> [Mooney, Sean K] I like this idea in general, that said in ovs-dpdk we 
> modified
> ovs to schedule the vhost-user port to be processed on a pmd that is on the 
> same
> Numa node as the vm and reallocate the vhsot user port memory where possible
> To also have the same affinity. 
>>
>> I have some ideas around how this could work, but they're fuzzy enough
>> and involve exchanging os-vif objects between nova and neutron. This is
>> probably the most difficult path as we've been trying to get os-vif
>> objects over the nova-neutron wire for a while now, to no success.
> [Mooney, Sean K] actually we have so poc code you should proably review
> This topic.
> https://blueprints.launchpad.net/os-vif/+spec/vif-port-profile
> https://review.openstack.org/#/c/490829/ 
> https://review.openstack.org/#/c/490819/ 
> https://review.openstack.org/#/c/441590/
> the first patch of the neutron side poc should be up before the ptg.
> 
>>
>> Anyone else keen on such a feature? Given that there are a significant
>> amount of people from nova, neutron, and general NFV backgrounds at the
>> PTG next week, we have a very good opportunity to talk about this
>> (either in the nova- neutron sync, if that's not already full, or in
>> some hallway somewhere).
> [Mooney, Sean K] in terms of basic numa affinity this is not as important
> With ovs-dpdk because we make best effort to fix it in ovs this is less 
> pressing
> Then it used to be. It is still important for other backbends but we need
> Also have a mechanism to control numa affinity policy like 
>  https://review.openstack.org/#/c/361140/ to not break existing deployments.
> 
> I have some taught about modeling network backbends
> in placement and also passing traits requests for neutron that this would dove
> tail with so would love to talk to anyone who is interested in this.
> By modeling ovs and other network backend in placement and combining that
> With traits and the nova-neutron negotiation protocol we support several
> Advance usescase.
> 
> By the way  ovs-dpdk allow you to specify vhost-port rx/tx queue mapping 
> to pmd which could give a nice performance boost if done correctly. It
> might be worth extending os-vif to do that in the future though this could
> equally be handeled by the neutron ovs l2 agent.
>>
>> At this point in the day, this is probably very much a Rocky feature,
>> but we could definitely put in whatever groundwork is necessary this
>> cycle to make the work in Rocky as easy possible.
> [Mooney, Sean K] I'm hoping we can get the nova neutron negotiation done in 
> queens.
>>
>> Cheers,
>> Stephen
> __
> 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] removing screen from devstack - RSN

[Eric Fried]

All-

The plain pdb doc patch [1] is merging.

On clarkb's suggestion, I took a look at remote-pdb [2], and it turned
out to be easy-peasy to use.  I submitted a followon doc patch for that [3].

Thanks, John, for speaking up and getting this rolling.

Eric

[1] https://review.openstack.org/#/c/501834/
[2] https://pypi.python.org/pypi/remote-pdb
[3] https://review.openstack.org/#/c/501870/

On 09/07/2017 02:30 PM, John Griffith wrote:
> 
> 
> On Thu, Sep 7, 2017 at 1:28 PM, Sean Dague  > wrote:
> 
> On 09/07/2017 01:52 PM, Eric Fried wrote:
> 
> John-
> 
> You're not the only one for whom the transition to
> systemd has been
> painful.
> 
> However...
> 
> It *is* possible (some would argue just as easy) to do
> all things with
> systemd that were done with screen.
> 
> For starters, have you seen [1] ?
> 
> Though looking at that again, I realize it could use a
> section on how
> to do pdb - I'll propose something for that.  In the meantime,
> feel free
> to find me in #openstack-dev and I can talk you through it.
> 
> [1] https://docs.openstack.org/devstack/latest/systemd.html
> 
> 
> Thanks,
> Eric Fried (efried)
> 
> 
> Thank you Eric. Would love to get a recommended pdb path into the
> docs. Ping me as soon as it's up for review, and I'll get it merged
> quickly.
> 
> Thanks for stepping up here, it's highly appreciated.
> 
> -Sean
> 
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __
> 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
> 
> 
> ​Patch is here [1] for those that are interested:
> 
> [1]: https://review.openstack.org/#/c/501834/1​
> 
> 
> 
> __
> 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] out-of-tree l3 service providers

[Isaku Yamahata]

Hi.

Any update on this? Now L3 service provider got the time slot at the PTG.

Yamamoto, do you have any proposal for the interface?
Although ODL surely is interested in L3 flavor, the networking-odl team hasn't
spec or experimental patch yet unfortunately.
Dragon flow folks seems to have their own spec.

thanks,

On Mon, Jul 31, 2017 at 02:10:07PM +0900,
Takashi Yamamoto  wrote:

> hi,
> 
> On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton  wrote:
> > If I understand the main issue with using regular callbacks, it's mainly
> > just that the flavor assignment itself is in a callback, right?
> 
> yes.
> 
> >
> > If so, couldn't we solve the problem by just moving flavor assignment to an
> > explicit call before emitting the callbacks? Or would that still result in
> > other ordering issues?
> 
> it would solve the problem for CREATE.
> for UPDATE and DELETE, i'm not sure.
> UPDATE can change the flavor but it's supposed to be a special case
> only for dvr/ha, right?
> AFTER_DELETE might be tricky as we probably need to provide flavor
> info to subscribers.
> 
> >
> > On Thu, Jul 13, 2017 at 3:01 AM, Takashi Yamamoto 
> > wrote:
> >>
> >> hi,
> >>
> >> today i managed to play with l3 flavors.
> >> i wrote a crude patch to implement midonet flavor. [1]
> >>
> >> [1] https://review.openstack.org/#/c/483174/
> >>
> >> a good news is it's somehow working.
> >>
> >> a bad news is it has a lot of issues, as you can see in TODO comments
> >> in the patch.
> >> given these issues, now i tend to think it's cleaner to introduce
> >> ml2-like precommit/postcommit driver api (or its equivalent via
> >> callbacks) rather than using these existing notifications.
> >>
> >> how do you think?
> >
> >
> 
> __
> 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

-- 
Isaku Yamahata 

__
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] [panko][ceilometer][keystone] Support X-Is-Admin-Project

[gordon chung]

On 2017-09-07 02:15 PM, Innus, Martins wrote:
> The fix seems to be something like the attached patch and setting the 
> appropriate configs in keystone.conf.
> 
> 
> One curious thing is that with the default keystone config, requests from all 
> projects have "X-Is-Admin-Project: True”
> 
> If I set admin_project_domain_name and admin_project_name , only then do the 
> non admin projects have the header set to False.

apologies, do you have more details on what 'X-Is-Admin-Project' is? i'm 
not familiar with this header.

currently, the behaviour is that:
- a member of a project can only see its own events
- an admin of a project can see all the events of a project (and any 
events without any project associated with it)

if this is the way of denoting a user is a 'super-admin' that has access 
to all events, i'm ok with it.

cheers,

-- 
gord
__
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] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Nisha Agarwal]

>>Nisha is raising the question about whether or not we're making incorrect
assumptions >>about how people are using nova/ironic and they want to use
the non-Exact filters for >>VCPU/MEMORY_MB/DISK_GB, which as far as I have
ever heard is not >>recommended/supported upstream as it can lead to
resource tracking issues in Nova that >>eventually lead to scheduling
failures later because of the scheduler thinking a node is >>available for
more than one instance when it's really not.

Just to clarify, I havent heard about this issue lately when we use
non-Exact filters. (before Pike release).

Regards
Nisha


On Fri, Sep 8, 2017 at 1:27 AM, Matt Riedemann  wrote:

> On 9/7/2017 2:48 PM, Nisha Agarwal wrote:
>
>> Hi Ironic Operators,
>>
>>  From Pike, ironic nodes get scheduled based on just the resource class
>> from nova. Do you guys see any concerns over this "rigid resource class
>> only ironic scheduling"?
>>
>> To be more specific, at your datacentre/production environment what all
>> filters are configured in nova.conf (configuration file for nova) for
>> scheduling an ironic node? Do you use RamFilter/DiskFilter/CoreFilter in
>> the "use_baremetal_filters" for ironic nodes scheduling from nova?
>>
>> Thanks and Regards
>> Nisha
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> Some more background information is in the ironic spec here:
>
> https://review.openstack.org/#/c/500429/
>
> Also, be aware of these release notes for Pike related to baremetal
> scheduling:
>
> http://docs-draft.openstack.org/77/501477/1/check/gate-nova-
> releasenotes/1dc7513//releasenotes/build/html/unreleased.html#id2
>
> In Pike, nova is using a combination of VCPU/MEMORY_MB/DISK_GB resource
> class amounts from the flavor during scheduling as it always has, but it
> will also check for the custom resource_class which comes from the ironic
> node. The custom resource class is optional in Pike but will be a hard
> requirement in Queens, or at least that was the plan. The idea being that
> long-term we'd stop consulting VCPU/MEMORY_MB/DISK_GB from the flavor
> during scheduling and just use the atomic node.resource_class since we want
> to allocate a nova instance to an entire ironic node, and this is also why
> the Exact* filters were used too.
>
> There are more details on using custom resource classes for scheduling
> here:
>
> https://specs.openstack.org/openstack/nova-specs/specs/pike/
> approved/custom-resource-classes-in-flavors.html
>
> Nisha is raising the question about whether or not we're making incorrect
> assumptions about how people are using nova/ironic and they want to use the
> non-Exact filters for VCPU/MEMORY_MB/DISK_GB, which as far as I have ever
> heard is not recommended/supported upstream as it can lead to resource
> tracking issues in Nova that eventually lead to scheduling failures later
> because of the scheduler thinking a node is available for more than one
> instance when it's really not.
>
> --
>
> Thanks,
>
> Matt
>
> __
> 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
>



-- 
The Secret Of Success is learning how to use pain and pleasure, instead
of having pain and pleasure use you. If You do that you are in control
of your life. If you don't life controls you.
__
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] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Matt Riedemann]

On 9/7/2017 2:48 PM, Nisha Agarwal wrote:

Hi Ironic Operators,

 From Pike, ironic nodes get scheduled based on just the resource class 
from nova. Do you guys see any concerns over this "rigid resource class 
only ironic scheduling"?


To be more specific, at your datacentre/production environment what all 
filters are configured in nova.conf (configuration file for nova) for 
scheduling an ironic node? Do you use RamFilter/DiskFilter/CoreFilter in 
the "use_baremetal_filters" for ironic nodes scheduling from nova?


Thanks and Regards
Nisha



__
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



Some more background information is in the ironic spec here:

https://review.openstack.org/#/c/500429/

Also, be aware of these release notes for Pike related to baremetal 
scheduling:


http://docs-draft.openstack.org/77/501477/1/check/gate-nova-releasenotes/1dc7513//releasenotes/build/html/unreleased.html#id2

In Pike, nova is using a combination of VCPU/MEMORY_MB/DISK_GB resource 
class amounts from the flavor during scheduling as it always has, but it 
will also check for the custom resource_class which comes from the 
ironic node. The custom resource class is optional in Pike but will be a 
hard requirement in Queens, or at least that was the plan. The idea 
being that long-term we'd stop consulting VCPU/MEMORY_MB/DISK_GB from 
the flavor during scheduling and just use the atomic node.resource_class 
since we want to allocate a nova instance to an entire ironic node, and 
this is also why the Exact* filters were used too.


There are more details on using custom resource classes for scheduling here:

https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/custom-resource-classes-in-flavors.html

Nisha is raising the question about whether or not we're making 
incorrect assumptions about how people are using nova/ironic and they 
want to use the non-Exact filters for VCPU/MEMORY_MB/DISK_GB, which as 
far as I have ever heard is not recommended/supported upstream as it can 
lead to resource tracking issues in Nova that eventually lead to 
scheduling failures later because of the scheduler thinking a node is 
available for more than one instance when it's really not.


--

Thanks,

Matt

__
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][ironic] Concerns over rigid resource class-only ironic scheduling

[Nisha Agarwal]

Hi Ironic Operators,

>From Pike, ironic nodes get scheduled based on just the resource class from
nova. Do you guys see any concerns over this "rigid resource class only
ironic scheduling"?

To be more specific, at your datacentre/production environment what all
filters are configured in nova.conf (configuration file for nova) for
scheduling an ironic node? Do you use RamFilter/DiskFilter/CoreFilter in
the "use_baremetal_filters" for ironic nodes scheduling from nova?

Thanks and Regards
Nisha
__
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] [nova] [neutron] Should we continue providing FQDNs for instance hostnames?

[Ben Nemec]

On 09/06/2017 04:40 AM, Stephen Finucane wrote:

On Tue, 2017-09-05 at 12:30 -0500, Ben Nemec wrote:

On 09/04/2017 07:48 AM, Stephen Finucane wrote:

On Mon, 2017-09-04 at 11:51 +, Gary Kotton wrote:

On 9/4/17, 11:18 AM, "Stephen Finucane"  wrote:

Nova has a feature whereby it will provide instance host names that
cloud-init can extract and use inside the guest, i.e. this won't happen
without cloud-init. These host names are fully qualified domain names
(FQDNs) based upon the instance name and local domain name. However, as
noted in bug #1698010 [1], the domain name part of this is based up
nova's 'dhcp_domain' option, which is a nova-network option that has
been deprecated [2].
  
I've started work on a fix [3] that will allow us to retrieve this

information from neutron instead, uncoupling us from this legacy
option. However, some commentators have pointed out that this may not
necessarily be what we want to do: a FQDN is a hostname and domain
name, and using one as a hostname may not be that clever nor correct.

My networking fu isn't strong enough to deliver a verdict so I'm hoping
someone else can make my mind up for me: do we want to migrate this
feature to neutron, or do we want to stop using FQDN and just use
instance names?


Hi,

Your patch https://review.openstack.org/#/c/480616/ requires that neutron
expose the ‘DNS Integration’ extension be support by neutron and the
relevant networking plugin. If it does not then will be a regression and
things will not work.

In addition to this that is per network and not global so there will also
be a regression for running instances if nova is updated.


OK, so ultimately this isn't something we can rely on from neutron? Does
that mean we should abandon the idea of providing FQDN when using neutron?
Mores to the original point, is there any reason we would want to/should
use FQDN?


TripleO gets its FQDNs from this feature, which is how I noticed it was
still using the deprecated nova.conf value.  So we need some way to
maintain that functionality.  I'm not sure what would happen if
cloud-init stopped getting an FQDN - would it just set the hostname but
leave the domain as whatever was provided via DHCP?  If so I think that
would be acceptable for us.


OK, and we do want to use a FQDN as the hostnames inside the guest? That's my
key question. Random ServerFault questions seems to suggest no clear answer to
this [1].


It's true that there is no definitive answer there, but I will point out 
this: At least three different answers say something along the lines of 
"I normally use just the shortname, but I discovered that [application] 
requires the hostname to be an FQDN."  The three examples I see are some 
Oracle applications, FreeIPA, and Ganeti.  I know we ran into issues 
with non-FQDN hostnames in TripleO as well, probably for either Puppet 
or RabbitMQ.  I know they're both hostname-sensitive, I just don't 
recall which was FQDN-sensitive too.  That's why one of the first steps 
of the undercloud install says "Ensure that there is a FQDN hostname set 
and that the $HOSTNAME environment variable matches that value."


In that case we even went so far as to codify the hostname configuration 
to make sure everything was FQDN and consistent.  So I guess my vote 
would be in favor of hostname as FQDN, which I realize doesn't simplify 
this discussion at all. :-)





On the other hand, since it turns out this configuration option isn't
only used with nova-network maybe it should just be un-deprecated?
Perhaps with an update so that it is only used when Neutron doesn't
provide an FQDN?


You're correct in pointing out that it's not only used by nova-network, but
this seemed to be a mistake. The main issue I saw was that the nova-network
option is completely divorced from the neutron configuration and is static.
However, if we can't guarantee that this information will be available from
neutron, then perhaps a static configuration option is the only way to go? It's
quite the pickle.

Stephen

[1] https://serverfault.com/q/331936/


[1] https://bugs.launchpad.net/nova/+bug/1698010
[2] https://review.openstack.org/#/c/395683/
[3] https://review.openstack.org/#/c/480616/


__
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] removing screen from devstack - RSN

[John Griffith]

On Thu, Sep 7, 2017 at 1:28 PM, Sean Dague  wrote:

> On 09/07/2017 01:52 PM, Eric Fried wrote:
>
>> John-
>>
>> You're not the only one for whom the transition to systemd has
>> been
>> painful.
>>
>> However...
>>
>> It *is* possible (some would argue just as easy) to do all things
>> with
>> systemd that were done with screen.
>>
>> For starters, have you seen [1] ?
>>
>> Though looking at that again, I realize it could use a section on
>> how
>> to do pdb - I'll propose something for that.  In the meantime, feel free
>> to find me in #openstack-dev and I can talk you through it.
>>
>> [1] https://docs.openstack.org/devstack/latest/systemd.html
>>
>> Thanks,
>> Eric Fried (efried)
>>
>
> Thank you Eric. Would love to get a recommended pdb path into the docs.
> Ping me as soon as it's up for review, and I'll get it merged quickly.
>
> Thanks for stepping up here, it's highly appreciated.
>
> -Sean
>
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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
>
​Patch is here [1] for those that are interested:

[1]: https://review.openstack.org/#/c/501834/1​
__
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] removing screen from devstack - RSN

[John Griffith]

On Thu, Sep 7, 2017 at 11:52 AM, Eric Fried  wrote:

> John-
>
> You're not the only one for whom the transition to systemd has been
> painful.
>
> However...
>
> It *is* possible (some would argue just as easy) to do all things
> with
> systemd that were done with screen.
>
> For starters, have you seen [1] ?
>
> Though looking at that again, I realize it could use a section on
> how
> to do pdb - I'll propose something for that.  In the meantime, feel free
> to find me in #openstack-dev and I can talk you through it.
>
> [1] https://docs.openstack.org/devstack/latest/systemd.html
>
> Thanks,
> Eric Fried (efried)
>
> On 09/07/2017 12:34 PM, John Griffith wrote:
> >
> >
> > On Thu, Sep 7, 2017 at 11:29 AM, John Griffith  > > wrote:
> >
> > Please don't, some of us have no issues with screen and use it
> > extensively for debugging.  Unless there's a viable option using
> > systemd I fail to understand why this is such a big deal.  I've been
> > using devstack in screen for a long time without issue, and I still
> > use rejoin that supposedly didn't work (without issue).
> >
> > I completely get the "run like customers" but in theory I'm not sure
> > how screen makes it much different than what customers do, it's
> > executing the same binary at the end of the day.  I'd also ask then
> > is devstack no longer "dev" stack, but now a preferred method of
> > install for running production clouds?  Anyway, I'd just ask to
> > leave it as an option, unless there's equivalent options for things
> > like using pdb etc.  It's annoying enough that we lost that
> > capability for the API services, is there a possibility we can
> > reconsider not allowing this an option?
> >
> > Thanks,
> > John
> >
> > On Thu, Sep 7, 2017 at 7:31 AM, Davanum Srinivas  > > wrote:
> >
> > w00t!
> >
> > On Thu, Sep 7, 2017 at 8:45 AM, Sean Dague  > > wrote:
> > > On 08/31/2017 06:27 AM, Sean Dague wrote:
> > >> The work that started last cycle to make devstack only have a
> > single
> > >> execution mode, that was the same between automated QA and
> > local, is
> > >> nearing it's completion.
> > >>
> > >> https://review.openstack.org/#/c/499186/
> >  is the patch that
> > will remove
> > >> screen from devstack (which was only left as a fall back for
> > things like
> > >> grenade during Pike). Tests are currently passing on all the
> > gating jobs
> > >> for it. And experimental looks mostly useful.
> > >>
> > >> The intent is to merge this in about a week (right before
> > PTG). So, if
> > >> you have a complicated devstack plugin you think might be
> > affected by
> > >> this (and were previously making jobs pretend to be grenade
> > to keep
> > >> screen running), now is the time to run tests against this
> > patch and see
> > >> where things stand.
> > >
> > > This patch is in the gate and now merging, and with it
> > devstack now has
> > > a single run mode, using systemd units, which is the same
> > between test
> > > and development.
> > >
> > > Thanks to everyone helping with the transition!
> > >
> > > -Sean
> > >
> > > --
> > > Sean Dague
> > > http://dague.net
> > >
> > >
> > 
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >  unsubscribe>
> > >
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev  openstack-dev>
> >
> >
> >
> > --
> > Davanum Srinivas :: https://twitter.com/dims
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >  unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev  openstack-dev>
> >
> >
> > ​FWIW I realize my opinion doesn't count here particularly since this
> > already merged, BUT I also realize that it didn't c

Re: [openstack-dev] removing screen from devstack - RSN

[Sean Dague]

On 09/07/2017 01:52 PM, Eric Fried wrote:

John-

You're not the only one for whom the transition to systemd has been
painful.

However...

It *is* possible (some would argue just as easy) to do all things with
systemd that were done with screen.

For starters, have you seen [1] ?

Though looking at that again, I realize it could use a section on how
to do pdb - I'll propose something for that.  In the meantime, feel free
to find me in #openstack-dev and I can talk you through it.

[1] https://docs.openstack.org/devstack/latest/systemd.html

Thanks,
Eric Fried (efried)


Thank you Eric. Would love to get a recommended pdb path into the docs. 
Ping me as soon as it's up for review, and I'll get it merged quickly.


Thanks for stepping up here, it's highly appreciated.

-Sean


--
Sean Dague
http://dague.net

__
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] Unified Limits work stalled - next steps, need for new leadership

[Sean Dague]

This is an email that's probably overdue, but time gets away from all of 
us. Coming out of Atlanta and even Boston we were pushing pretty hard on 
a new approach to unify limits, as well as building the infrastructure 
to have hierarchical limits possible in OpenStack (keystone merged spec 
- 
https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/unified-limits.html)


However, this effort pretty much as run out of gas, and really needs a 
new driver (or set of drivers) to make forward progress. My current set 
of responsibilities doesn't really make it possible for me to own 
driving this (though I will be happy to help others). That seems to also 
be true of many of the others that were engaged.


This is going out in advance of the PTG in case any developer(s), or 
organizations feel that hierarchical limits are a priority for them, and 
would be willing to step up there. If so please feel free to reach out, 
and we can carve out some PTG time in helping a new push organize here.


However, without new leadership here, the current plan is to just put 
the effort to rest.


-Sean

--
Sean Dague
http://dague.net

__
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] [Neutron][L3-subteam] Weekly IRC meeting cancelled on September 14th

[Miguel Lavalle]

Dear L3-subteam,

Due to the OpenStack PTG next week in Denver, we will cancel our weekly
meeting on September 14th. We will resume normally on the 21st

See you in Denver!
__
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] [TripleO][CI] FreeIPA Deployment

[Harry Rybacki]

On Thu, Aug 31, 2017 at 12:52 PM, Juan Antonio Osorio
 wrote:
> Something that just came to my mind: Another option would be to allocate an
> extra IP Address for the undercloud, that would be dedicated to FreeIPA, and
> that way we MAY be able to deploy the FreeIPA server in the undercloud. If
> folks are OK with this I could experiment on this front. Maybe I could try
> to run FreeIPA on a container [1] (which wasn't available when I started
> working on this).
>
Interesting idea, Ozz! I'm not sure what/if the security implications
of running them
on the same host would be.

I'm cc'ing Toure to discuss possible workflow approach to this as well.

/R

> [1] https://hub.docker.com/r/freeipa/freeipa-server/
>
> On Sat, Aug 26, 2017 at 2:52 AM, Emilien Macchi  wrote:
>>
>> On Sun, Aug 20, 2017 at 11:45 PM, Juan Antonio Osorio
>>  wrote:
>> > The second option seems like the most viable. Not sure how the TripleO
>> > integration would go though. Care to elaborate on what you had in mind?
>>
>> Trying to reproduce what we did with ceph-ansible and use Mistral to
>> deploy FreeIPA with an external deployment tool.
>> Though I find the solution quite complex, maybe we can come-up with an
>> easier approach this time?
>> --
>> Emilien Macchi
>>
>> __
>> 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
>
>
>
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosor...@gmail.com
>
>
> __
> 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] [tripleo] all you need to know for PTG TripleO-related topics

[Emilien Macchi]

If you use Google Calendar, you really want to use this one:
https://calendar.google.com/calendar/ical/c1g5npdrsd3p37ods24s19gg0g%40group.calendar.google.com/public/basic.ics

Or view in HTML here:
https://calendar.google.com/calendar/embed?src=c1g5npdrsd3p37ods24s19gg0g%40group.calendar.google.com&ctz=America/Denver

Which contains an updated agenda for TripleO related topics.

We'll track everything in this etherpad:
https://etherpad.openstack.org/p/tripleo-ptg-queens

I'm looking forward to seeing you folks!
Have safe trips,
-- 
Emilien Macchi

__
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] [panko][ceilometer][keystone] Support X-Is-Admin-Project

[Innus, Martins]

Hi,
Just getting started with OpenStack and one of the stumbling blocks so 
far is that unless I missed it, there is no way for the main admin user to 
request event data for all projects:

[root@srv-m10-05-02 keystone]# ceilometer event-list -q 
'event_type=compute.instance.create.start'
+++---++
| Message ID | Event Type | Generated | Traits |
+++---++
+++---++



Where there are definitely instances running and the user that created them has 
no issue seeing the events:

[minnus@srv-m10-05-02 ~]$ ceilometer  event-list -q 
'event_type=compute.instance.create.start' --limit 1
+--+---++---+
| Message ID   | Event Type| 
Generated  | Traits 
   |
+--+---++---+
| b7ce7652-9745-487d-9fcc-570c7c972080 | compute.instance.create.start | 
2017-08-29T15:37:39.707727 | 
+--+-+--+ |
|  |   |
| |   name   |   type  |  value

……


The fix seems to be something like the attached patch and setting the 
appropriate configs in keystone.conf.


One curious thing is that with the default keystone config, requests from all 
projects have "X-Is-Admin-Project: True”

If I set admin_project_domain_name and admin_project_name , only then do the 
non admin projects have the header set to False.

This is on:
 - Centos 7.3
 - Ocata
 - Panko backed by MariaDB.

Is this change something that would be accepted?

Thanks!

Martins



panko.patch
Description: panko.patch
__
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] [nova] [neutron] Adding neutron VIF NUMA locality support

[Mooney, Sean K]

> -Original Message-
> From: Stephen Finucane [mailto:sfinu...@redhat.com]
> Sent: Thursday, September 7, 2017 5:42 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Cc: Jakub Libosvar ; Karthik Sundaravel
> ; Mooney, Sean K 
> Subject: [nova] [neutron] Adding neutron VIF NUMA locality support
> 
> Hey,
> 
> NUMA locality matters as much for NICs used e.g for Open vSwitch as for
> SR-IOV devices. At the moment, nova support NUMA affinity for PCI
> passthrough devices and SR-IOV devices, but it makes no attempt to do
> the same for other NICs. In the name of NFV enablement, we should
> probably close this gap.
[Mooney, Sean K] I like this idea in general, that said in ovs-dpdk we modified
ovs to schedule the vhost-user port to be processed on a pmd that is on the same
Numa node as the vm and reallocate the vhsot user port memory where possible
To also have the same affinity. 
> 
> I have some ideas around how this could work, but they're fuzzy enough
> and involve exchanging os-vif objects between nova and neutron. This is
> probably the most difficult path as we've been trying to get os-vif
> objects over the nova-neutron wire for a while now, to no success.
[Mooney, Sean K] actually we have so poc code you should proably review
This topic.
https://blueprints.launchpad.net/os-vif/+spec/vif-port-profile
https://review.openstack.org/#/c/490829/ 
https://review.openstack.org/#/c/490819/ 
https://review.openstack.org/#/c/441590/
the first patch of the neutron side poc should be up before the ptg.

> 
> Anyone else keen on such a feature? Given that there are a significant
> amount of people from nova, neutron, and general NFV backgrounds at the
> PTG next week, we have a very good opportunity to talk about this
> (either in the nova- neutron sync, if that's not already full, or in
> some hallway somewhere).
[Mooney, Sean K] in terms of basic numa affinity this is not as important
With ovs-dpdk because we make best effort to fix it in ovs this is less pressing
Then it used to be. It is still important for other backbends but we need
Also have a mechanism to control numa affinity policy like 
 https://review.openstack.org/#/c/361140/ to not break existing deployments.

I have some taught about modeling network backbends
in placement and also passing traits requests for neutron that this would dove
tail with so would love to talk to anyone who is interested in this.
By modeling ovs and other network backend in placement and combining that
With traits and the nova-neutron negotiation protocol we support several
Advance usescase.

By the way  ovs-dpdk allow you to specify vhost-port rx/tx queue mapping 
to pmd which could give a nice performance boost if done correctly. It
might be worth extending os-vif to do that in the future though this could
equally be handeled by the neutron ovs l2 agent.
> 
> At this point in the day, this is probably very much a Rocky feature,
> but we could definitely put in whatever groundwork is necessary this
> cycle to make the work in Rocky as easy possible.
[Mooney, Sean K] I'm hoping we can get the nova neutron negotiation done in 
queens.
> 
> Cheers,
> Stephen
__
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] removing screen from devstack - RSN

[Walter Boring]

I completely agree with you here John.   I still prefer to use screen for
my devstack installs, it's just far far easier to use for development.
 systemd is a pain to use in comparison.
This is a major step backwards for developers.

:(

On Thu, Sep 7, 2017 at 1:29 PM, John Griffith 
wrote:

> Please don't, some of us have no issues with screen and use it extensively
> for debugging.  Unless there's a viable option using systemd I fail to
> understand why this is such a big deal.  I've been using devstack in screen
> for a long time without issue, and I still use rejoin that supposedly
> didn't work (without issue).
>
> I completely get the "run like customers" but in theory I'm not sure how
> screen makes it much different than what customers do, it's executing the
> same binary at the end of the day.  I'd also ask then is devstack no longer
> "dev" stack, but now a preferred method of install for running production
> clouds?  Anyway, I'd just ask to leave it as an option, unless there's
> equivalent options for things like using pdb etc.  It's annoying enough
> that we lost that capability for the API services, is there a possibility
> we can reconsider not allowing this an option?
>
> Thanks,
> John
>
> On Thu, Sep 7, 2017 at 7:31 AM, Davanum Srinivas 
> wrote:
>
>> w00t!
>>
>> On Thu, Sep 7, 2017 at 8:45 AM, Sean Dague  wrote:
>> > On 08/31/2017 06:27 AM, Sean Dague wrote:
>> >> The work that started last cycle to make devstack only have a single
>> >> execution mode, that was the same between automated QA and local, is
>> >> nearing it's completion.
>> >>
>> >> https://review.openstack.org/#/c/499186/ is the patch that will remove
>> >> screen from devstack (which was only left as a fall back for things
>> like
>> >> grenade during Pike). Tests are currently passing on all the gating
>> jobs
>> >> for it. And experimental looks mostly useful.
>> >>
>> >> The intent is to merge this in about a week (right before PTG). So, if
>> >> you have a complicated devstack plugin you think might be affected by
>> >> this (and were previously making jobs pretend to be grenade to keep
>> >> screen running), now is the time to run tests against this patch and
>> see
>> >> where things stand.
>> >
>> > This patch is in the gate and now merging, and with it devstack now has
>> > a single run mode, using systemd units, which is the same between test
>> > and development.
>> >
>> > Thanks to everyone helping with the transition!
>> >
>> > -Sean
>> >
>> > --
>> > Sean Dague
>> > http://dague.net
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>> Davanum Srinivas :: https://twitter.com/dims
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] removing screen from devstack - RSN

[Eric Fried]

John-

You're not the only one for whom the transition to systemd has been
painful.

However...

It *is* possible (some would argue just as easy) to do all things with
systemd that were done with screen.

For starters, have you seen [1] ?

Though looking at that again, I realize it could use a section on how
to do pdb - I'll propose something for that.  In the meantime, feel free
to find me in #openstack-dev and I can talk you through it.

[1] https://docs.openstack.org/devstack/latest/systemd.html

Thanks,
Eric Fried (efried)

On 09/07/2017 12:34 PM, John Griffith wrote:
> 
> 
> On Thu, Sep 7, 2017 at 11:29 AM, John Griffith  > wrote:
> 
> Please don't, some of us have no issues with screen and use it
> extensively for debugging.  Unless there's a viable option using
> systemd I fail to understand why this is such a big deal.  I've been
> using devstack in screen for a long time without issue, and I still
> use rejoin that supposedly didn't work (without issue).
> 
> I completely get the "run like customers" but in theory I'm not sure
> how screen makes it much different than what customers do, it's
> executing the same binary at the end of the day.  I'd also ask then
> is devstack no longer "dev" stack, but now a preferred method of
> install for running production clouds?  Anyway, I'd just ask to
> leave it as an option, unless there's equivalent options for things
> like using pdb etc.  It's annoying enough that we lost that
> capability for the API services, is there a possibility we can
> reconsider not allowing this an option?
> 
> Thanks,
> John
> 
> On Thu, Sep 7, 2017 at 7:31 AM, Davanum Srinivas  > wrote:
> 
> w00t!
> 
> On Thu, Sep 7, 2017 at 8:45 AM, Sean Dague  > wrote:
> > On 08/31/2017 06:27 AM, Sean Dague wrote:
> >> The work that started last cycle to make devstack only have a
> single
> >> execution mode, that was the same between automated QA and
> local, is
> >> nearing it's completion.
> >>
> >> https://review.openstack.org/#/c/499186/
>  is the patch that
> will remove
> >> screen from devstack (which was only left as a fall back for
> things like
> >> grenade during Pike). Tests are currently passing on all the
> gating jobs
> >> for it. And experimental looks mostly useful.
> >>
> >> The intent is to merge this in about a week (right before
> PTG). So, if
> >> you have a complicated devstack plugin you think might be
> affected by
> >> this (and were previously making jobs pretend to be grenade
> to keep
> >> screen running), now is the time to run tests against this
> patch and see
> >> where things stand.
> >
> > This patch is in the gate and now merging, and with it
> devstack now has
> > a single run mode, using systemd units, which is the same
> between test
> > and development.
> >
> > Thanks to everyone helping with the transition!
> >
> > -Sean
> >
> > --
> > Sean Dague
> > http://dague.net
> >
> >
> 
> __
> > 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 
> 
> 
> 
> 
> --
> Davanum Srinivas :: https://twitter.com/dims
> 
> 
> __
> 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 
> 
> 
> 
> ​FWIW I realize my opinion doesn't count here particularly since this
> already merged, BUT I also realize that it didn't count before it merged
> either as the response I was given was "I don't use debuggers".  It's
> unfortunate, perhaps I'm really the only one that has counter opinions
> on things, or maybe nobody else wants to speak up, or maybe just nobody
> cares.  Either way, it's a bit of a bu

Re: [openstack-dev] removing screen from devstack - RSN

[Sean McGinnis]

​FWIW I realize my opinion doesn't count here particularly since this 
already merged, BUT I also realize that it didn't count before it 
merged either as the response I was given was "I don't use 
debuggers".  It's unfortunate, perhaps I'm really the only one that 
has counter opinions on things, or maybe nobody else wants to speak 
up, or maybe just nobody cares.  Either way, it's a bit of a bummer 
and just another thing on the list.  ​




You are not alone. At the same time we are discussing ways to simplify 
things to ease the burden on development,

we are also making it more difficult, especially for newcomers.

I would have hoped we had come up with a solution for interactive 
debugging before we pulled the plug too. "Don't"

really doesn't seem like the right answer here.

Where was this plan discussed too? I must have missed the planning for 
this change.


Sean


__
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] removing screen from devstack - RSN

[John Griffith]

On Thu, Sep 7, 2017 at 11:29 AM, John Griffith 
wrote:

> Please don't, some of us have no issues with screen and use it extensively
> for debugging.  Unless there's a viable option using systemd I fail to
> understand why this is such a big deal.  I've been using devstack in screen
> for a long time without issue, and I still use rejoin that supposedly
> didn't work (without issue).
>
> I completely get the "run like customers" but in theory I'm not sure how
> screen makes it much different than what customers do, it's executing the
> same binary at the end of the day.  I'd also ask then is devstack no longer
> "dev" stack, but now a preferred method of install for running production
> clouds?  Anyway, I'd just ask to leave it as an option, unless there's
> equivalent options for things like using pdb etc.  It's annoying enough
> that we lost that capability for the API services, is there a possibility
> we can reconsider not allowing this an option?
>
> Thanks,
> John
>
> On Thu, Sep 7, 2017 at 7:31 AM, Davanum Srinivas 
> wrote:
>
>> w00t!
>>
>> On Thu, Sep 7, 2017 at 8:45 AM, Sean Dague  wrote:
>> > On 08/31/2017 06:27 AM, Sean Dague wrote:
>> >> The work that started last cycle to make devstack only have a single
>> >> execution mode, that was the same between automated QA and local, is
>> >> nearing it's completion.
>> >>
>> >> https://review.openstack.org/#/c/499186/ is the patch that will remove
>> >> screen from devstack (which was only left as a fall back for things
>> like
>> >> grenade during Pike). Tests are currently passing on all the gating
>> jobs
>> >> for it. And experimental looks mostly useful.
>> >>
>> >> The intent is to merge this in about a week (right before PTG). So, if
>> >> you have a complicated devstack plugin you think might be affected by
>> >> this (and were previously making jobs pretend to be grenade to keep
>> >> screen running), now is the time to run tests against this patch and
>> see
>> >> where things stand.
>> >
>> > This patch is in the gate and now merging, and with it devstack now has
>> > a single run mode, using systemd units, which is the same between test
>> > and development.
>> >
>> > Thanks to everyone helping with the transition!
>> >
>> > -Sean
>> >
>> > --
>> > Sean Dague
>> > http://dague.net
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>> Davanum Srinivas :: https://twitter.com/dims
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> ​FWIW I realize my opinion doesn't count here particularly since this
already merged, BUT I also realize that it didn't count before it merged
either as the response I was given was "I don't use debuggers".  It's
unfortunate, perhaps I'm really the only one that has counter opinions on
things, or maybe nobody else wants to speak up, or maybe just nobody
cares.  Either way, it's a bit of a bummer and just another thing on the
list.  ​
__
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] removing screen from devstack - RSN

[John Griffith]

Please don't, some of us have no issues with screen and use it extensively
for debugging.  Unless there's a viable option using systemd I fail to
understand why this is such a big deal.  I've been using devstack in screen
for a long time without issue, and I still use rejoin that supposedly
didn't work (without issue).

I completely get the "run like customers" but in theory I'm not sure how
screen makes it much different than what customers do, it's executing the
same binary at the end of the day.  I'd also ask then is devstack no longer
"dev" stack, but now a preferred method of install for running production
clouds?  Anyway, I'd just ask to leave it as an option, unless there's
equivalent options for things like using pdb etc.  It's annoying enough
that we lost that capability for the API services, is there a possibility
we can reconsider not allowing this an option?

Thanks,
John

On Thu, Sep 7, 2017 at 7:31 AM, Davanum Srinivas  wrote:

> w00t!
>
> On Thu, Sep 7, 2017 at 8:45 AM, Sean Dague  wrote:
> > On 08/31/2017 06:27 AM, Sean Dague wrote:
> >> The work that started last cycle to make devstack only have a single
> >> execution mode, that was the same between automated QA and local, is
> >> nearing it's completion.
> >>
> >> https://review.openstack.org/#/c/499186/ is the patch that will remove
> >> screen from devstack (which was only left as a fall back for things like
> >> grenade during Pike). Tests are currently passing on all the gating jobs
> >> for it. And experimental looks mostly useful.
> >>
> >> The intent is to merge this in about a week (right before PTG). So, if
> >> you have a complicated devstack plugin you think might be affected by
> >> this (and were previously making jobs pretend to be grenade to keep
> >> screen running), now is the time to run tests against this patch and see
> >> where things stand.
> >
> > This patch is in the gate and now merging, and with it devstack now has
> > a single run mode, using systemd units, which is the same between test
> > and development.
> >
> > Thanks to everyone helping with the transition!
> >
> > -Sean
> >
> > --
> > Sean Dague
> > http://dague.net
> >
> > 
> __
> > 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
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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] [all][api] POST /api-sig/news

[michael mccune]

Greetings OpenStack community,

This week's meeting was mainly focused on discussion of plans for the 
PTG and about improving the outreach efforts of the SIG.


The API-SIG will have a room on Monday and Tuesday at the PTG. In 
addition to the guided review process [6] we've mentioned before, 
there's an etherpad [5] where an agenda of topics is being planned. We 
will be sharing some of the time with people interested in SDKs and 
other issues related to consuming APIs. If there are gaps we will be 
performing live readings of mordred's version and service discovery epic 
[4].These readings may or may not involve hand puppets.  If you would 
like to propose a topic for the PTG, please add it to the aforementioned 
etherpad.


In addition to our discussion of events for the PTG, we also talked 
about how we can improve our outreach and messaging to the wider 
OpenStack community. This was predicated by a review of our email 
advertising the guided review process. Although we have talked about 
this topic and taken steps to advance the SIG in the past, a fresh take 
on this discussion revolved around the notion of reaching project teams 
earlier in their API design process. Starting after the PTG, the API-SIG 
will investigate reaching out to projects which are still incubating 
with the hope that interacting with these teams early in their lifecycle 
will be of maximum benefit.


# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

* Explain, simply, why extensions are bad
  https://review.openstack.org/#/c/491611/

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and 
service discovery

  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready 
for review)

  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address 
your concerns in an email to the OpenStack developer mailing list[1] 
with the tag "[api]" in the subject. In your email, you should include 
any relevant reviews, links, and comments to help guide the discussion 
of the specific challenge you are facing.


To learn more about the API WG mission and the work we do, see OpenStack 
API Working Group [2].


Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] 
http://specs.openstack.org/openstack/api-wg/guidelines/consuming-catalog.html

[5] https://etherpad.openstack.org/p/api-ptg-queens
[6] http://specs.openstack.org/openstack/api-wg/guidedreview.html
[7] https://bugs.launchpad.net/openstack-api-wg/+bug/1593310

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
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] [neutron] Adding neutron VIF NUMA locality support

[Stephen Finucane]

Hey,

NUMA locality matters as much for NICs used e.g for Open vSwitch as for SR-IOV
devices. At the moment, nova support NUMA affinity for PCI passthrough devices
and SR-IOV devices, but it makes no attempt to do the same for other NICs. In
the name of NFV enablement, we should probably close this gap.

I have some ideas around how this could work, but they're fuzzy enough and
involve exchanging os-vif objects between nova and neutron. This is probably
the most difficult path as we've been trying to get os-vif objects over the
nova-neutron wire for a while now, to no success.

Anyone else keen on such a feature? Given that there are a significant amount
of people from nova, neutron, and general NFV backgrounds at the PTG next
week, we have a very good opportunity to talk about this (either in the nova-
neutron sync, if that's not already full, or in some hallway somewhere).

At this point in the day, this is probably very much a Rocky feature, but we
could definitely put in whatever groundwork is necessary this cycle to make the
work in Rocky as easy possible.

Cheers,
Stephen

__
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] [kolla] [neutron] PTG cross-platform meetup possibility

[thomas.morin]

Vikram Hosakote (vhosakot), 2017-09-07 15:38:
> Would there be any interest in meeting with the Kolla team at the PTG
> to discuss neutron’s
> integration with containers and Kubernetes especially about the new
> networking
> technologies like VPP, fd.io, OpenDaylight, OVS-DPDK, OVN, service
> chaining (SFC), etc?
>  
> If yes, would Tuesday 2 pm work?  I’m thinking about an hour or two
> for the session.

If this happens I'm interested to follow.

-Thomas


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
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] [kolla] [neutron] PTG cross-platform meetup possibility

[Vikram Hosakote (vhosakot)]

Hi neutron team,

Would there be any interest in meeting with the Kolla team at the PTG to 
discuss neutron’s
integration with containers and Kubernetes especially about the new networking
technologies like VPP, fd.io, OpenDaylight, OVS-DPDK, OVN, service chaining 
(SFC), etc?

If yes, would Tuesday 2 pm work?  I’m thinking about an hour or two for the 
session.

Regards,
Vikram Hosakote
IRC:  vhosakot
__
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] [nova] [neutron] Should we continue providing FQDNs for instance hostnames?

[Stephen Finucane]

On Wed, 2017-09-06 at 15:06 +, Jeremy Stanley wrote:
> On 2017-09-06 10:40:14 +0100 (+0100), Stephen Finucane wrote:
> [...]
> > OK, and we do want to use a FQDN as the hostnames inside the
> > guest? That's my key question. Random ServerFault questions seems
> > to suggest no clear answer to this [1].
> 
> [...]
> 
> As a data point, the servers maintained by the Infra team are
> consistently built with their FQDN as the instance name itself, and
> then the hostname and domainname set from that value in order to
> avoid the dreaded "foo.novalocal" sorts of FQDNs prevalent in so
> many OpenStack environments. At least for us, having OpenStack
> specify the domain is more of a nuisance to be worked around than
> anything.

That's great feedback.

> You may also want to consider asking a similar question on the
> operators ML, or perhaps sending them a pointer to this discussion
> so you can get more real-world feedback.

Good call. I'll re-post this to the operators mailing list (with the above
point) and see what feedback I receive.

Cheers,
Stephen

__
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] [neutron][oslo.db] db retry madness

[Michael Bayer]

I'm trying to get a handle on neutron's retry decorators.I'm
assisting a developer in the networking_odl project who wishes to make
use of neutron's retry_if_session_inactive decorator.

The developer has run into several problems, including that
networking_odl methods here seem to accept a "session" directly,
rather than the "context" as is standard throughout neutron, and
retry_if_session_inactive assumes the context calling pattern.
Additionally, the retry_db_errors() decorator which is also used by
retry_if_session_inactive is doing a deepcopy operation on arguments,
which when applied to ORM-mapped entities, makes a copy of them which
are then detached from the Session and they fail to function beyond
that.

For context, the developer's patch is at:
https://review.openstack.org/#/c/500584/3

and the neutron features I'm looking at can be seen when they were
reviewed at: https://review.openstack.org/#/c/356530/22


So I have a bunch of questions, many are asking the same things: "is
networking_odl's pattern legacy or not?" and "is this retry decorator
buggy?"   There's overlap in these questions.  But "yes" / "no" to
each would still help me figure out that this is a giraffe and not a
duck :) ("does it have a long neck?" "does it quack?" etc)

1. since the retry_if_session_inactive decorator assumes functions
that receive a "context", what does it mean that networking_odl uses
functions that receive a "session" and not a "context" ?   Should
networking_odl be modified such that it accepts the same "context"
that Neutron passes around?

2. Alternatively, should the retry_if_session_inactive decorator be
modified (or a new decorator added) that provides the identical
behavior for functions that receive a "session" argument rather than a
"context" argument ?  (or should this be done anyway even if
networking_odl's pattern is legacy?)

3. I notice that the session.is_active flag is considered to be
meaningful.   Normally, this flag is of no use, as the enginefacade
pattern only provides for a Session that has had the begin() method
called.  However, it looks like in neutron_lib/context.py, the Context
class is providing for a default session
"db_api.get_writer_session()", which I would assume is how we get a
Session with is_active is false:

3a.  Is this a temporary measure to work around legacy patterns?
3b.  If 3a., is the pattern in use by networking_odl, receiving a
"session" and not "context", the specific legacy pattern in question?
3c.  if 3a and 3b, are we expecting all the various plugins to
start using "context" at some point ?  (and when they come to me with
breakage, I can push them in that direction?)

4. What is the bug we are fixing by using deepcopy() with the
arguments passed to the decorated function:

4a.  Is it strictly that simple mutable lists and dicts of simple
types (ints, strings, etc.) are preserved across retries, assuming the
receiving functions might be modifying them?

4b. Does this deepcopy() approach have any support for functions
that are being passed not just simple structures but ORM-mapped
objects?   Was this use case considered?

4c. Does Neutron's model base have any support for deepcopy()?  I
notice that the base classes in model_base do **not** seem to have a
__deepcopy__ present.  This would mean that this deepcopy() will
definitely break any ORM mapped objects because you need to use an
approach like what Nova uses for copy():
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L46
.  This would be why the developer's objects are all getting kicked
out of the session.   (this is the "is this a bug?" part)

4d. How frequent is the problem of mutable lists and dicts, and
should this complex and actually pretty expensive behavior be
optional, only for those functions that are known to receieve mutable
structures and change them in place?

__
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] [kolla] [cinder] [ironic] PTG cross-platform meetup possibility

[Vikram Hosakote (vhosakot)]

Sending the confirmed cross-project meets with the kolla community:

Monday with Triple-O at 2 pm
Monday with Cinder and Ironic at 4 pm

Regards,
Vikram Hosakote
IRC:  vhosakot

From: Jay S Bryant 
Reply-To: "jsbry...@electronicjungle.net" , 
"OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, August 31, 2017 at 1:43 PM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [kolla] [cinder] [ironic] PTG cross-platform 
meetup possibility


Rich,

I can make Monday at 4 pm work.  Conflicts with some Docs discussions but I can 
step out for a bit.

Thanks!

Jay



On 8/31/2017 8:25 AM, Richard Wellum wrote:
Hi,

How does Monday at 4pm sound? Kolla already has a cross-platform discussion 
with Triple-O at 2pm, so this would dovetail nicely.

Thanks,

||Rich

On Wed, Aug 30, 2017 at 2:48 PM Ivan Kolodyazhny 
mailto:e...@e0ne.info>> wrote:
Hi team,

I'm interested in cinder containerization too. It would be great if we can 
schedule our meetup after 3pm or even 4pm, It will increase my chances to 
attend it.

Thanks in advance.

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Wed, Aug 30, 2017 at 4:23 PM, Dmitry Tantsur 
mailto:dtant...@redhat.com>> wrote:
Hi!

I'm all for it. Monday sounds okay to me, though I'll have to manage some 
conflicts, of course.


On 08/29/2017 05:56 PM, Richard Wellum wrote:
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 about your teams 
interest and experiences in containerization and what you need from Kolla going 
forward.

I'm thinking an hour or two on Monday afternoon, the first day of the PTG?

Thanks,

||Rich

__
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: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] [keystone] [nova] [neutron] [cinder] [ironic] [glance] [swift] Baremetal/VM SIG PTG Schedule/Etherpad

[Lance Bragstad]

I spoke with John a bit today in IRC and we have a rough schedule worked
out for the Baremetal/VM SIG. All the sessions/ideas/carry-over topics
from Boston have been filtered into a schedule and is available in the
etherpad [0].

Each entry should have a "lead" to drive the discussion and a "goal" to
work towards. I took a stab at listing leads and goals accordingly, but
if you're more familiar with the topics, please adjust as necessary. If
you noticed a conflict with another session, feel free to respond here,
leave a comment in the etherpad, or ping me on IRC. I know it's a bit
late, but I'd like to have the schedule pretty well set by the weekend.

Thanks!


[0] https://etherpad.openstack.org/p/queens-PTG-vmbm

On 08/24/2017 03:34 PM, Lance Bragstad wrote:
> Hi all,
>
> Keystone has a few cross-project topics we'd like to share with a wider
> group, like the Baremetal/VM SIG. As a result, I attempted to dust off
> some of the Baremetal/VM sessions [0][1] from Boston and port the
> popular topics over to the etherpad for the PTG [2]. Maybe it will kick
> start some discussions before we get there?
>
> John has more insight into this than I do, but I'm curious if we plan to
> have a rough schedule for Monday and Tuesday? I'm happy to help
> coordinate or shuffle bits for the baremetal/VM group if ideas come up here.
>
>
> [0] https://etherpad.openstack.org/p/BOS-forum-operating-vm-and-baremetal
> [1] https://etherpad.openstack.org/p/BOS-forum-using-vm-and-baremetal
> [2] https://etherpad.openstack.org/p/queens-PTG-vmbm
>




signature.asc
Description: OpenPGP digital 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] [docs][neutron] checking link integrity in the gate

[Andreas Jaeger]

An easy way to check for broken links:

http://codesearch.openstack.org/?q=docs.openstack.org%2Fdeveloper&i=nope&files=&repos=

We moved everything out from docs.openstack.org/developer, any such link
in your code is outdated and needs updating,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] [charms] IRC meeting 11th September cancelled

[James Page]

Hi Team

I'm cancelling next Mondays IRC; we're (mostly) meeting for the PTG anyway
and can re-sync the following Monday.

Cheers

James
__
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] [sahara] Canceling meeting Sep 14th

[Telles Nobrega]

Hi saharans,

since most of us will be at the PTG, I'm canceling IRC meeting.

See you in Denver.
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat I 

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
__
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] removing screen from devstack - RSN

[Davanum Srinivas]

w00t!

On Thu, Sep 7, 2017 at 8:45 AM, Sean Dague  wrote:
> On 08/31/2017 06:27 AM, Sean Dague wrote:
>> The work that started last cycle to make devstack only have a single
>> execution mode, that was the same between automated QA and local, is
>> nearing it's completion.
>>
>> https://review.openstack.org/#/c/499186/ is the patch that will remove
>> screen from devstack (which was only left as a fall back for things like
>> grenade during Pike). Tests are currently passing on all the gating jobs
>> for it. And experimental looks mostly useful.
>>
>> The intent is to merge this in about a week (right before PTG). So, if
>> you have a complicated devstack plugin you think might be affected by
>> this (and were previously making jobs pretend to be grenade to keep
>> screen running), now is the time to run tests against this patch and see
>> where things stand.
>
> This patch is in the gate and now merging, and with it devstack now has
> a single run mode, using systemd units, which is the same between test
> and development.
>
> Thanks to everyone helping with the transition!
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [release][ptl] tools for creating new releases

[Dmitry Tantsur]

On 08/22/2017 02:34 PM, Doug Hellmann wrote:

Excerpts from Dmitry Tantsur's message of 2017-08-22 11:38:10 +0200:

On 08/22/2017 11:34 AM, Dmitry Tantsur wrote:

On 08/21/2017 09:15 PM, Doug Hellmann wrote:

Excerpts from Doug Hellmann's message of 2017-08-21 11:21:59 -0400:

Excerpts from Dmitry Tantsur's message of 2017-08-15 14:11:05 +0200:

On 08/08/2017 03:30 PM, Doug Hellmann wrote:

We realized recently that we haven't publicized some of the tools
in the releases repository very well. One tool that will be useful
this week as you prepare your release candidates is the 'new-release'
command, which edits a deliverable file to add a new release from
HEAD of the given branch, automatically computing the next verison
number based on the inputs.

Use the ``venv`` tox environment to run the tool, like this:

  $ tox -e venv -- new-release SERIES DELIVERABLE TYPE

The SERIES value should be the release series, such as "pike".

The DELIVERABLE value should be the deliverable name, such as
"oslo.config" or "cinder".

The TYPE value should be one of "bugfix", "feature", "major",
"milestone", or "rc".

If the most recent release of cinder during the pike series is
11.0.0.0b3 then running:

  $ tox -e venv -- new-release pike cinder rc


On systems with Python 3 by default this fails on installing
lazr.restfulclient.
I think we should add

basepython = python2

for now.


I wonder if you have an old copy of the releases repo. In master we
explicitly set basepython to python3 and lazr.restfulclient is no longer
a dependency.


Updated to latest HEAD, removed *.pyc files and .tox. Still getting:

Obtaining file:///home/dtantsur/Projects/releases
Requirement already up-to-date: pbr>=1.6 in
./.tox/list-changes/lib/python3.6/site-packages (from releases==0.0.1.dev3083)
Collecting lazr.restfulclient==0.13.1 (from releases==0.0.1.dev3083)
Using cached lazr.restfulclient-0.13.1.tar.gz
  Complete output from command python setup.py egg_info:
  Traceback (most recent call last):
File "", line 1, in 
File "/tmp/pip-build-hhi229rh/lazr.restfulclient/setup.py", line 19, in

  import ez_setup
File "/tmp/pip-build-hhi229rh/lazr.restfulclient/ez_setup.py", line 98
  except pkg_resources.VersionConflict, e:
  ^
  SyntaxError: invalid syntax

I cannot find where this dependency comes from, still investigating.


And here is what helped: rm -rf *.egg-info/

I suspect it was coming from stale directory releases.egg-info (currently we
have openstack_releases.egg-info instead). I'm not sure why it was picked..


Yes, that's odd, but I'm glad you found the problem.

I see you're running with python 3.6. I've only tested with 3.5 so far,
so I would appreciate bug reports or patches if you find issues.


So far so good. I haven't had any problems with doing Pike releases on it.



Doug

__
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] removing screen from devstack - RSN

[Sean Dague]

On 08/31/2017 06:27 AM, Sean Dague wrote:
> The work that started last cycle to make devstack only have a single
> execution mode, that was the same between automated QA and local, is
> nearing it's completion.
> 
> https://review.openstack.org/#/c/499186/ is the patch that will remove
> screen from devstack (which was only left as a fall back for things like
> grenade during Pike). Tests are currently passing on all the gating jobs
> for it. And experimental looks mostly useful.
> 
> The intent is to merge this in about a week (right before PTG). So, if
> you have a complicated devstack plugin you think might be affected by
> this (and were previously making jobs pretend to be grenade to keep
> screen running), now is the time to run tests against this patch and see
> where things stand.

This patch is in the gate and now merging, and with it devstack now has
a single run mode, using systemd units, which is the same between test
and development.

Thanks to everyone helping with the transition!

-Sean

-- 
Sean Dague
http://dague.net

__
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] [puppet] Add Mohammed Naser to cores

[Mohammed Naser]

Thank you for the kind words everyone! :)

On Tue, Sep 5, 2017 at 12:06 PM, Dmitry Tantsur  wrote:
> I think it's not unreasonable to give core rights to the PTL :)
>
>
> On 09/05/2017 05:42 PM, Alex Schultz wrote:
>>
>> Hey folks,
>>
>> I'm writing to ask that we add mnaser to the cores list for the puppet
>> modules.  He's been a user and contributor for some time and is also
>> the new PTL.  Let me know if there are any objections.
>>
>> Thanks,
>> -Alex
>>
>> __
>> 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] mod_wsgi support (pike bug?)

[Kevin Benton]

That's still going to be backwards-incompatible with the way it's been
shipped for quite a while now. Passing ENV vars or something to point to
specific config files is going to need to be explored.

On Wed, Sep 6, 2017 at 9:19 PM, Thomas Bechtold  wrote:

> Hi Kevin,
>
> On 04.09.2017 15:01, Kevin Benton wrote:
>
>> Yes, unfortunately I didn't make it back to the patch in time to adjust
>> devstack to dump all of the configuration into one file (instead of
>> /etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc).
>>
>
> You don't have to put everything into one file. oslo.config supports per
> service config files and conf.d dirs[1].
> So eg. dhcp_agent.ini could be put into 
> /etc/neutron/neutron-dhcp-agent.conf.d/foo.conf
> (it must end with .conf).
> Maybe that's more readable than a single huge config file?
>
> Best,
>
> Tom
>
> [1] https://docs.openstack.org/releasenotes/oslo.config/ocata.html#id2
>
>
__
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] [ptg][heat] Heat PTG + Virtual meetup Agenda

[Rico Lin]

Hi heat members

As we're going to have PTG in Denver(and online)
Here are schedules and Etherpads for it [1].

Encourage all to join us remotely if you can't make it to Denver!, we
welcome anyone shares their ideas, experiences, efforts, and stories to us
to help us make our design/implement better.

Attached an ics file, feel free to add it to your calendar

As we discussed in heat meeting, this Heat PTG will be a mixed format,
Physical PTG room + Virtual Online channel together.
The virtual link will share in [1], and if anything went wrong(like we have
to change room URL), we will update to etherpad as well. So keep update to
date with the etherpad.

Also please notice that we won't host team meeting next week.

[1] https://etherpad.openstack.org/p/heat-queens-ptg

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//www.marudot.com//iCal Event Maker
X-WR-CALNAME:Heat Session in Denver PTG
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:America/Denver
TZURL:http://tzurl.org/zoneinfo-outlook/America/Denver
X-LIC-LOCATION:America/Denver
BEGIN:DAYLIGHT
TZOFFSETFROM:-0700
TZOFFSETTO:-0600
TZNAME:MDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0600
TZOFFSETTO:-0700
TZNAME:MST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-1171862...@marudot.com
DTSTART;TZID="America/Denver":20170913T09
DTEND;TZID="America/Denver":20170913T093000
SUMMARY:Rolling upgrade session(Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Rolling upgrade session(Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-468483...@marudot.com
DTSTART;TZID="America/Denver":20170913T094000
DTEND;TZID="America/Denver":20170913T103000
SUMMARY:tooz integration session(Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:tooz integration session(Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-674863...@marudot.com
DTSTART;TZID="America/Denver":20170913T101000
DTEND;TZID="America/Denver":20170913T105000
SUMMARY:Cluster resource improvement session(Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Cluster resource improvement session(Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-2117674...@marudot.com
DTSTART;TZID="America/Denver":20170913T11
DTEND;TZID="America/Denver":20170913T12
SUMMARY:A horizon plugin for HOT creation in drag & drop session(Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:A horizon plugin for HOT creation in drag & drop session(Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-1265540...@marudot.com
DTSTART;TZID="America/Denver":20170913T133000
DTEND;TZID="America/Denver":20170913T142500
SUMMARY:Policy in Code session(Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Policy in Code session(Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-657695...@marudot.com
DTSTART;TZID="America/Denver":20170913T143000
DTEND;TZID="America/Denver":20170913T144000
SUMMARY:Team Photo (Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Team Photo (Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-384219...@marudot.com
DTSTART;TZID="America/Denver":20170914T09
DTEND;TZID="America/Denver":20170914T092000
SUMMARY:Federated Keystone and Heat session(Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Federated Keystone and Heat session(Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-772826...@marudot.com
DTSTART;TZID="America/Denver":20170914T093000
DTEND;TZID="America/Denver":20170914T095000
SUMMARY: Cross-stack reference session(Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION: Cross-stack reference session(Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20170907T101450Z
UID:20170907t101450z-563498...@marudot.com
DTSTART;TZID="America/Denver":20170914T10
DTEND;TZID="America/Denver":20170914T103000
SUMMARY:Breaking the stack barrier session(Heat-PTG)
DESCRIPTION:https://etherpad.openstack.org/p/heat-queens-ptg
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Breaking the stack barrier session(Heat-PTG)
TRIGGER:-PT5M
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20

Re: [openstack-dev] [nova] [placement] Modeling SR-IOV with nested resource providers

[Andrey Volkov]

Ed,

Thanks for the response.

I'm also interested how those models can be used from two points of view.

First, how I can request the desired configuration. I thought about
some anti-affinity logic based on traits in Placement, but probably
that's not a task for Placement. Solution Jay Pipes proposed [1] is to
make several requests to /allocation_candidates and then combine a new
request from responses.

Second, how complicated it would be to update resource provider structure
if some conditions are changed (port was connected to a different switch).
I agree that simple structure is preferable here, for me having PFs as
resource providers
and VFs as inventories with tags (third option in the previos post) is
closer
to reality than hierarchical resource providers. What do you think?

FYI Eric Fried started an etherpad about generic device management [2].

[1] http://paste.openstack.org/show/620456/
[2]
https://etherpad.openstack.org/p/nova-ptg-queens-generic-device-management


On Wed, Sep 6, 2017 at 11:17 PM, Ed Leafe  wrote:

> On Sep 5, 2017, at 10:02 AM, Andrey Volkov  wrote:
>
> > For example, I have SR-IOV PF with four ports (P_i), two of them are
> > connected to one switch (SW_1) and other two to another (SW_2). I
> > would like to get VFs from distinct ports connected to distinct
> > switches (more details can be found in spec [1]), how it can be
> > modeled with nested resource providers?
>
> You should make it as complicated as it needs to be, but no more. The
> first model nests one deep, while the second goes two levels deep, yet they
> both provide the same granularity for accessing the VFs, so I would go for
> the first. And I’m not sure that we will be able to get the “inherited”
> traits used in the second model implemented any time soon.
>
> -- 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
>



-- 
Thanks,

Andrey Volkov,
Software Engineer, Mirantis, Inc.
__
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] [infra][docs] Why Manila api-ref doc isn't published?

[jun zhong]

Thanks Jeremy Stanley, Anne Gentle and Eric Fried  for your perfect reply
on this question. thanks

2017-09-05 20:59 GMT+08:00 Eric Fried :

> Sigh.
>
> [3] https://review.openstack.org/#/c/495326/1/www/.htaccess@52
>
> On 09/05/2017 07:30 AM, Eric Fried wrote:
> > Agree with everything fungi has said here.
> >
> > Per
> > https://git.openstack.org/cgit/openstack/service-types-
> authority/tree/README.rst#n97
> > we want the official service type to be singular rather than plural.
> >
> > And per the doc migration movement, we want the API references to live
> > at standard URLs based on their official service type.
> >
> > So the official API reference should indeed be at [1], which it seems to
> > be, as you pointed out.
> >
> > However, I also agree with your point that there are obviously stale
> > links in the world pointing to the plural version, and adding a redirect
> > would be a good idea while those get cleaned up.  I have proposed [2]
> > for this.
> >
> > Please also note that, per my comment at [3], I feel we should be moving
> > toward a place where sources linking to API references should be
> > gleaning the URLs dynamically from the service-types-authority rather
> > than hardcoding them.
> >
> > [1] https://developer.openstack.org/api-ref/shared-file-system/
> > [2] https://review.openstack.org/#/c/500792/
> >
> > Thanks,
> > efried
> >
> > On 09/04/2017 01:24 PM, Jeremy Stanley wrote:
> >> On 2017-09-04 12:45:59 -0500 (-0500), Anne Gentle wrote:
> >>> I want to say there are a couple of in-progress patches to clear
> >>> this up.
> >>>
> >>> https://review.openstack.org/#/c/495326/
> >>> and
> >>> https://review.openstack.org/#/c/495887/
> >> [...]
> >>
> >> Only insofar as the service-types-authority change is switching to
> >> match the URL where the document is now being published, but this
> >> doesn't actually address all the places where the old URL is still
> >> being used. At least that confirms for me that the new URL really is
> >> the one we want, so maybe the old "shared-file-systems" name should
> >> be added as an alias for the "shared-file-system" service (giving us
> >> a redirect as I understand it) and then cleanup of various uses for
> >> the old URL can happen at everyone's convenience?
> >>
> >>
> >>
> >> 
> __
> >> 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:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [opensatck] [freezer] Looking for a worked intallation guide for freezer

[hanc...@iscas.ac.cn]

Hello,

Among the projects in OpenStack, freezer is the rare one who does the data 
backups and disaster recovery. This really attracts me on working on it.

However, I sufferred several pitfalls during the installation. The 
"installation guide" in the project wiki page shows the installation for the 
mitaka release? However, it did not help much even on a mitaka based openstack. 
I have spent a few days already, but the freezer-api even could not be 
installed and configured correctly. I also followed the guide from the official 
github. The similar result (failure) returns to me... It all happens on the 
"db-sync" or "db-init" steps... 

I wonder is there an up-to-date guide for the service installation anywhere? Or 
specifically for a release, like mitaka, but worked tutorial that can lead me 
to a successful installation?
Rare detailed information of this project can be found over the Internet. Hope 
anyone who can leave me a hint. I would be very appreciated. :)

PS: By the way, is the Swift a necessary service to guaranteeing freezer 
working properly?

Thanks,
Chao


__
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] Fwd: [Kolla] kolla-kubernetes production ready?

[Kim-Norman Sahm]

Hi,

does anybody know when kolla-kubernetes is ready for production?
is someone using kolla-kubernetes for production now?

regards
Kim


Kim-Norman Sahm
Cloud & Infrastructure(OCI)

noris network AG
Thomas-Mann-Straße 16-20
90471 Nürnberg
Deutschland

Tel +49 911 9352 1433
Fax +49 911 9352 100

kim-norman.s...@noris.de

https://www.noris.de - Mehr Leistung als Standard
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689










smime.p7s
Description: S/MIME cryptographic 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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Thierry Carrez]

Jeremy Stanley wrote:
> On 2017-09-01 09:51:36 +0200 (+0200), Thierry Carrez wrote:
> [...]
>> Yes, for a first batch I propose we clean up the following:
>>
>> python-congressclient 2015.1.0
>> python-congressclient 2015.1.0rc1
>> python-designateclient 2013.1.a8.g3a2a320
>> networking-hyperv 2015.1.0
> [...]
> 
> Are we waiting for any confirmation on this, or does a week of
> silence constitute tacit approval? Should I go ahead and delete
> these from PyPI now?

Yes please.

-- 
Thierry Carrez (ttx)

__
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