date:20170705

Re: [Openstack] [OpenStack] [nova] How can I release PCI device resources without delete instance?

2017-07-05 Thread Eddie Yen

Thanks Kevin,

This is another good option to solve IP problem for me. I'll note this.

Eddie.

2017-07-06 11:10 GMT+08:00 Kevin Benton :

> As a stop gap for the IP problem, keep in mind that you can create a
> neutron port separately and boot the instance to it. Then when you delete
> the instance the port will remain and hold onto the IP so you can boot to
> it with a different instance later.
>
> On Jul 5, 2017 18:31, "Eddie Yen"  wrote:
>
>> Hi, thanks for reply first!
>>
>> After I tried shelve instance, yes it really release GPU resources.
>> But as Dinesh said, can't unshelve this instance if all GPUs occupied.
>>
>> Before known about shelve instance, I have do few approach.
>>
>> One is using "resize" the instance's flavor to non-GPU flavor, but can't
>> do this if all GPUs occupied.
>>
>> Another one is like Jay's recommend is that create instance as volume,
>> and delete instance but keep volume if this VM not going to use GPU.
>> Then re-create instance with previous volume and non-GPU flavor.
>> And yes, this approach have IP address problem that may cause application
>> atypical.
>>
>> I'll try how to make my application not to rely on a persistent IP.
>>
>> Thanks,
>> Eddie.
>>
>> 2017-07-05 19:36 GMT+08:00 Jay Pipes :
>>
>>> On 07/05/2017 04:18 AM, Eddie Yen wrote:
>>>
 Hi everyone,

 I'm using OpenStack Mitaka (which deployed from Fuel 9.2) and doing GPU
 things.

 I got a problem is I need to delete current instance which contains GPU
 to release device if I want assign GPU to another new instance temperately.

 I'll got "No valid host was found" if I creating new instance contains
 GPU flavor without delete present instance, even the instance is shutdown.

 Is there any way that I just shutdown the instance rather than delete
 it to release GPU device?

>>>
>>> As Dinesh mentioned you *can* use shelve for this, but frankly, I think
>>> the shelve API leads to more problems than it solves (see his response
>>> about needing to delete the new instance before unshelving).
>>>
>>> I'd recommend redesigning your application to be more cloud-native. In
>>> other words, separate operating system state from application state, use
>>> volumes for all persistent application state, and do not rely on a
>>> persistent IP address. [1]
>>>
>>> Once you've done that, you can just treat your VMs like cattle and
>>> terminate them.
>>>
>>> Best,
>>> -jay
>>>
>>> [1] Please note I did not use the word "container" in this description
>>> of cloud-native application.
>>>
>>> ___
>>> Mailing list: http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>> Post to : openstack@lists.openstack.org
>>> Unsubscribe : http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>>
>>
>>
>> ___
>> Mailing list: http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>>
>>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] OpenStack Operators Midcycle

2017-07-05 Thread Melvin Hillsman

Just a friendly reminder for those who are waking up on the other side of
the globe. Please take a moment to put some ideas for sessions in the
etherpad - https://etherpad.openstack.org/p/MEX-ops-meetup

Even if you are not able to make the midcycle, please take time to propose
sessions.

On Mon, Jul 3, 2017 at 7:40 AM, Melvin Hillsman 
wrote:

> Hey everyone,
>
> Happy 4th of July Eve! We have the upcoming Operator Midcycle in Mexico
> City, Mexico August 9-10th, 2017. Sign up via Eventbrite now*, space is
> limited* - https://www.eventbrite.com/e/mexico-city-openstack-
> operators-meetup-tickets-34989052197
>
> We are taking session ideas and need your help generating them. Right now
> we have Kubernetes, Containers, NFV, and few more -
> https://etherpad.openstack.org/p/MEX-ops-meetup
>
> --
> Kind regards
>
> OpenStack User Committee
> (Edgar, Jon, Melvin, Shamail, Shilla)
>


-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646

Learner | Ideation | Belief | Responsibility | Command
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] OpenStack Operators Midcycle

2017-07-05 Thread Melvin Hillsman

Just a friendly reminder for those who are waking up on the other side of
the globe. Please take a moment to put some ideas for sessions in the
etherpad - https://etherpad.openstack.org/p/MEX-ops-meetup

Even if you are not able to make the midcycle, please take time to propose
sessions.

On Mon, Jul 3, 2017 at 7:40 AM, Melvin Hillsman 
wrote:

> Hey everyone,
>
> Happy 4th of July Eve! We have the upcoming Operator Midcycle in Mexico
> City, Mexico August 9-10th, 2017. Sign up via Eventbrite now*, space is
> limited* - https://www.eventbrite.com/e/mexico-city-openstack-
> operators-meetup-tickets-34989052197
>
> We are taking session ideas and need your help generating them. Right now
> we have Kubernetes, Containers, NFV, and few more -
> https://etherpad.openstack.org/p/MEX-ops-meetup
>
> --
> Kind regards
>
> OpenStack User Committee
> (Edgar, Jon, Melvin, Shamail, Shilla)
>


-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646

Learner | Ideation | Belief | Responsibility | Command
__
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] [OpenStack] [nova] How can I release PCI device resources without delete instance?

2017-07-05 Thread Kevin Benton

As a stop gap for the IP problem, keep in mind that you can create a
neutron port separately and boot the instance to it. Then when you delete
the instance the port will remain and hold onto the IP so you can boot to
it with a different instance later.

On Jul 5, 2017 18:31, "Eddie Yen"  wrote:

> Hi, thanks for reply first!
>
> After I tried shelve instance, yes it really release GPU resources.
> But as Dinesh said, can't unshelve this instance if all GPUs occupied.
>
> Before known about shelve instance, I have do few approach.
>
> One is using "resize" the instance's flavor to non-GPU flavor, but can't
> do this if all GPUs occupied.
>
> Another one is like Jay's recommend is that create instance as volume, and
> delete instance but keep volume if this VM not going to use GPU.
> Then re-create instance with previous volume and non-GPU flavor.
> And yes, this approach have IP address problem that may cause application
> atypical.
>
> I'll try how to make my application not to rely on a persistent IP.
>
> Thanks,
> Eddie.
>
> 2017-07-05 19:36 GMT+08:00 Jay Pipes :
>
>> On 07/05/2017 04:18 AM, Eddie Yen wrote:
>>
>>> Hi everyone,
>>>
>>> I'm using OpenStack Mitaka (which deployed from Fuel 9.2) and doing GPU
>>> things.
>>>
>>> I got a problem is I need to delete current instance which contains GPU
>>> to release device if I want assign GPU to another new instance temperately.
>>>
>>> I'll got "No valid host was found" if I creating new instance contains
>>> GPU flavor without delete present instance, even the instance is shutdown.
>>>
>>> Is there any way that I just shutdown the instance rather than delete it
>>> to release GPU device?
>>>
>>
>> As Dinesh mentioned you *can* use shelve for this, but frankly, I think
>> the shelve API leads to more problems than it solves (see his response
>> about needing to delete the new instance before unshelving).
>>
>> I'd recommend redesigning your application to be more cloud-native. In
>> other words, separate operating system state from application state, use
>> volumes for all persistent application state, and do not rely on a
>> persistent IP address. [1]
>>
>> Once you've done that, you can just treat your VMs like cattle and
>> terminate them.
>>
>> Best,
>> -jay
>>
>> [1] Please note I did not use the word "container" in this description of
>> cloud-native application.
>>
>> ___
>> Mailing list: http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>>
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [Manila] Weekly meeting canceled

2017-07-05 Thread Ben Swartzlander

 I'm not able to chair the meeting tomorrow and nobody has offered to 
chair the meeting in my stead so the meeting is canceled. We will meet 
as normal week.


-Ben Swartzlander

__
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] Live Migration and LibVirt CPU Mode

2017-07-05 Thread Oisin O'Malley


>> The instance can also be migrated between 2 Westmere hosts.
>> As I outline in another email, I suspect (perhaps incorrectly) as the
>> VM has "cpu mode='host-model'" in its running config, libvirt may be 
>> comparing source and destination host CPUs and not guest and destination 
>> CPUs.
>
>Indeed it very much seems like it will look at the host cpu-model and not the 
>guest since it is complaining about Broadwell CPU features.
>The libvirt documentation also sort of suggests this is the case:
>https://libvirt.org/formatdomain.html#elementsCPU
>“Prior to libvirt 3.2.0 and QEMU 2.9.0 detection of the host CPU model via 
>QEMU is not supported. Thus the CPU configuration created using host-model may 
>not work as expected.”

I think this may only apply when initially booting VM with "cpu 
mode='host-model'", when it determines compatible CPU features. Though I may be 
wrong.

>You can have a look cheating your way around it.
>There is some code which removes the checks which you might be able to (ab)use:
>https://bugs.launchpad.net/nova/+bug/1588003

I don't think this will apply either as the error in the traceback is coming 
from LibVirt itself not Nova, which would imply Nova's pre-migration 
compatibility checks have passed and it attempted and failed to call LibVirt to 
migrate the VM.

nova-compute: Traceback (most recent call last):
nova-compute: File "/usr/lib/python2.7/site-packages/eventlet/hubs/hub.py", 
line 457, in fire_timers
nova-compute: timer()
nova-compute: File "/usr/lib/python2.7/site-packages/eventlet/hubs/timer.py", 
line 58, in __call__
nova-compute: cb(*args, **kw)
nova-compute: File "/usr/lib/python2.7/site-packages/eventlet/event.py", line 
168, in _do_send
nova-compute: waiter.switch(result)
nova-compute: File "/usr/lib/python2.7/site-packages/eventlet/greenthread.py", 
line 214, in main
nova-compute: result = function(*args, **kwargs)
nova-compute: File "/usr/lib/python2.7/site-packages/nova/utils.py", line 1066, 
in context_wrapper
nova-compute: return func(*args, **kwargs)
nova-compute: File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5911, in 
_live_migration_operation
nova-compute: instance=instance)
nova-compute: File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", 
line 220, in __exit__
nova-compute: self.force_reraise()
nova-compute: File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", 
line 196, in force_reraise
nova-compute: six.reraise(self.type_, self.value, self.tb)
nova-compute: File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5907, in 
_live_migration_operation
nova-compute: bandwidth=CONF.libvirt.live_migration_bandwidth)
nova-compute: File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py", line 568, in 
migrate
nova-compute: destination, params=params, flags=flags)
nova-compute: File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 
186, in doit
nova-compute: result = proxy_call(self._autowrap, f, *args, **kwargs)
nova-compute: File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 
144, in proxy_call
nova-compute: rv = execute(f, *args, **kwargs)
nova-compute: File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 
125, in execute
nova-compute: six.reraise(c, e, tb)
nova-compute: File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 
83, in tworker
nova-compute: rv = meth(*args, **kwargs)
nova-compute: File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1939, 
in migrateToURI3
nova-compute: if ret == -1: raise libvirtError ('virDomainMigrateToURI3() 
failed', dom=self)
nova-compute: libvirtError: unsupported configuration: guest and host CPU are 
not compatible: Host CPU does not provide required features: fma, x2apic, 
movbe, tsc-deadline, xs


>You might want to double-check if a (hard)-rebooted migrated (with the 
>host-model config) instances on the Broadwell compute node does not get a 
>Broadwell cpu before modifying this ;)

It doesn't, as the Broadwell hosts nova .conf has the following;

cpu_mode = custom
cpu_model = Westmere

Oisin O'Malley
Systems Engineer
Iocane Pty Ltd
763 South Road
Black Forest SA 5035

Office:+61 (8) 8413 1010
Fax:+61 (8) 8231 2050
Email:oisin.omal...@iocane.com.au
Web:www.iocane.com.au

Better for business

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [neutron] writable mtu

2017-07-05 Thread Ian Wells

OK, so I should read before writing...

On 5 July 2017 at 18:11, Ian Wells  wrote:

> On 5 July 2017 at 14:14, Ihar Hrachyshka  wrote:
>
>> Heya,
>>
>> we have https://bugs.launchpad.net/neutron/+bug/1671634 approved for
>> Pike that allows setting MTU for network on creation.
>
>
> This was actually in the very first MTU spec (in case no one looked),
> though it never got implemented.  The spec details a whole bunch of stuff
> about how to calculate whether the proposed MTU will fit within the encap,
> incidentally, and will reject network creations when it doesn't.
>

OK, even referenced in the bug, so apologies, we're all good.

So, I wonder if we can instead lay the ground for updatable MTU right
>> away, and allow_post: True from the start, even while implementing
>> create only as a phase-1. Then we can revisit the decision if needed
>> without touching api. What do you think?
>>
>
I think I misinterpreted: you'd enable all options and then deal with the
consequences in the backend code which has to implement one the of the
previously listed behaviours?  That seems sane to me provided the required
behaviours are documented somewhere where a driver implementer has to trip
over them.
-- 
Ian.
__
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] writable mtu

2017-07-05 Thread Ian Wells

On 5 July 2017 at 14:14, Ihar Hrachyshka  wrote:

> Heya,
>
> we have https://bugs.launchpad.net/neutron/+bug/1671634 approved for
> Pike that allows setting MTU for network on creation.

This was actually in the very first MTU spec (in case no one looked),
though it never got implemented.  The spec details a whole bunch of stuff
about how to calculate whether the proposed MTU will fit within the encap,
incidentally, and will reject network creations when it doesn't.

Note that the MTU attribute was intended to represent an MTU that will
definitely transit.  I guess no-one would actually rely on this, but to
clarify, it's not intended to indicate that bigger packets will be dropped,
only that smaller packets will not be dropped (which is the guarantee you
need for two VMs to talk to each other.  Thus the MTU doesn't need to be
increased just because the infrastructure MTU has become larger; it just
means that future networks can be created with larger MTUs from this point,
and the current MTU will still be valid.

This is also the MTU that all VMs on that network will be told, because
they need to use the same value to function.  If you change it, VMs after
the event will have problems talking to their earlier friends because they
will now disagree on MTU (and routers will have problems talking to at
least one of those sets).

(but not update,
> as per latest comment from Kevin there) I already see a use case to
> modify MTU for an existing network (for example, where you enable
> Jumbo frames for underlying infrastructure, and want to raise the
> ceiling; another special case is when you migrate between different
> encapsulation technologies, like in case of ml2/ovs to networking-ovn
> migration where the latter doesn't support VXLAN but Geneve only).
>

You look like you're changing the read-only segmentation type of the
network on this migration - presumably in the DB directly - so you're
changing non-writeable fields already.  Couldn't the MTU be changed in a
similarly offline manner?

That said: what will you do with existing VMs that have been told the MTU
of their network already?

Put a different way, a change to the infrastructure can affect MTUs in two
ways:

- I increase the MTU that a network can pass (by, for instance, increasing
the infrastructure of the encap).  I don't need to change its MTU because
VMs that run on it will continue to work.  I have no means to tell the VMs
they have a bigger MTU now, and whatever method I might use needs to be
100% certain to work or left-out VMs will become impossible to talk to, so
leaving the MTU alone is sane.
- I decrease the MTU that a network can pass (by, for instance, using an
encap with larger headers).  The network comprehensively breaks; VMs
frequently fail to communicate regardless of whether I change the network
MTU property, because running VMs have already learned their MTU value and,
again, there's no way to update their idea of what it is reliably.
Basically, this is not a migration that can be done with running VMs.

If I go and implement the RFE as-is, and later in Queens we pursue
> updating MTU for existing networks, we will have three extensions for
> the same thing.
>
> - net-mtu (existing read only attribute)
> - net-mtu-enhanced (allow write on create)
> - net-mtu-enhanced-enhanced (allow updates)
>
> Not to mention potential addition of per-port MTU that some folks keep
> asking for (and we keep pushing against so far).
>
> So, I wonder if we can instead lay the ground for updatable MTU right
> away, and allow_post: True from the start, even while implementing
> create only as a phase-1. Then we can revisit the decision if needed
> without touching api. What do you think?
>

It's trivially detectable that an MTU value can't be set at all, or can be
set initially but not changed.  Could we use that approach?  That way, we
don't need multiple extensions, the current one is sufficient (and - on the
assumption that you don't rely on 'read-only attribute' errors in normal
code, I think we can call this backward compatible).

> Another related question is, how do we expose both old and new
> extensions at the same time? I would imagine that implementations
> capable of writing to the mtu attribute would advertise both old and
> new extensions. Is it correct? Does neutron api layer allow for
> overlapping attribute maps?
>

Extension net-mtu: MTU attr exists, can't set MTU at all, passing an MTU
returns a bad argument error
Extension net-mtu: MTU attr exists, can set MTU on startup, failed (too
big) MTU values return a more specific MTU too big error
Extension net-mtu: MTU attr exists, can set after creation, setting MTU
after creation fails as for startup write (which it appears you already
have in mind)

-- 
Ian.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

Re: [openstack-dev] [all][tc] Wiki

2017-07-05 Thread Rochelle Grober

And I'd just like to point out, when was the last time you tried to find info 
contained in some etherpad on our etherpad server without having the etherpad's 
exact name?  Either searched for a specific etherpad or for info you knew was 
somewhere on an etherpad somewhere on the etherpad.openstack.org site?

If you have any tricks for that, I could really use them ;-)

--Rocky

Arkady Kanevsky wrote:
> Most of google searches will pickup wiki pages. So people will view wiki as
> the current state of projects.
> 
> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Monday, July 03, 2017 9:30 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][tc] Wiki
> 
> Flavio Percoco wrote:
> > On 03/07/17 13:58 +0200, Thierry Carrez wrote:
> >> Flavio Percoco wrote:
> >>> Sometimes I wonder if we still need to maintain a Wiki. I guess some
> >>> projects still use it but I wonder if the use they make of the Wiki
> >>> could be moved somewhere else.
> >>>
> >>> For example, in the TC we use it for the Agenda but I think that
> >>> could be moved to an etherpad. Things that should last forever
> >>> should be documented somewhere (project repos, governance repo in
> >>> the TC case) where we can actually monitor what goes in and easily
> >>> clean up.
> >>
> >> This is a complete tangent, but I'll bite :) We had a thorough
> >> discussion about that last year, summarized at:
> >>
> >> http://lists.openstack.org/pipermail/openstack-dev/2016-June/096481.h
> >> tml
> >>
> >> TL,DR; was that while most authoritative content should (and has been
> >> mostly) moved off the wiki, it's still useful as a cheap publication
> >> platform for teams and workgroups, somewhere between a git repository
> >> with a docs job and an etherpad.
> >>
> >> FWIW the job of migrating authoritative things off the wiki is still
> >> on-going. As an example, Thingee is spearheading the effort to move
> >> the "How to Contribute" page and other first pointers to a reference
> >> website (see recent thread about that).
> >
> > I guess the short answer is that we hope one day we won't need it. I
> > certainly do.
> >
> > What would happen if we make the wiki read-only? Would that break
> > peopl's workflow?
> >
> > Do we know what teams modify the wiki more often and what it is they
> > do there?
> 
> The data is publicly available (see recent changes on the wiki). Most ops
> workgroups heavily rely on the wiki, as well as a significant number of
> upstream project teams and workgroups. Developers are clearly not the
> main target.
> 
> You can dive back into the original analysis etherpad if you're interested:
> 
> https://etherpad.openstack.org/p/wiki-use-cases
> 
> Things that are stroked out are things we moved to reference websites since
> then.
> 
> --
> 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
__
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] [OpenStack] [nova] How can I release PCI device resources without delete instance?

2017-07-05 Thread Eddie Yen

Hi, thanks for reply first!

After I tried shelve instance, yes it really release GPU resources.
But as Dinesh said, can't unshelve this instance if all GPUs occupied.

Before known about shelve instance, I have do few approach.

One is using "resize" the instance's flavor to non-GPU flavor, but can't do
this if all GPUs occupied.

Another one is like Jay's recommend is that create instance as volume, and
delete instance but keep volume if this VM not going to use GPU.
Then re-create instance with previous volume and non-GPU flavor.
And yes, this approach have IP address problem that may cause application
atypical.

I'll try how to make my application not to rely on a persistent IP.

Thanks,
Eddie.

2017-07-05 19:36 GMT+08:00 Jay Pipes :

> On 07/05/2017 04:18 AM, Eddie Yen wrote:
>
>> Hi everyone,
>>
>> I'm using OpenStack Mitaka (which deployed from Fuel 9.2) and doing GPU
>> things.
>>
>> I got a problem is I need to delete current instance which contains GPU
>> to release device if I want assign GPU to another new instance temperately.
>>
>> I'll got "No valid host was found" if I creating new instance contains
>> GPU flavor without delete present instance, even the instance is shutdown.
>>
>> Is there any way that I just shutdown the instance rather than delete it
>> to release GPU device?
>>
>
> As Dinesh mentioned you *can* use shelve for this, but frankly, I think
> the shelve API leads to more problems than it solves (see his response
> about needing to delete the new instance before unshelving).
>
> I'd recommend redesigning your application to be more cloud-native. In
> other words, separate operating system state from application state, use
> volumes for all persistent application state, and do not rely on a
> persistent IP address. [1]
>
> Once you've done that, you can just treat your VMs like cattle and
> terminate them.
>
> Best,
> -jay
>
> [1] Please note I did not use the word "container" in this description of
> cloud-native application.
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] compute nova and cinder volume on CNA

2017-07-05 Thread rag.open....@openmailbox.org

Hi, regarding nova, I am not clear about fiber channel over ethernet 
functionality, if it is necessary to configure something more for fiber 
channel over ethernet on the compute side (we already configured fcoe 
utils, lldpd, etc),


Doubt:
In the compute node have to be installed cinder-volume and nova-compute?
For everything to work ok.

In our use example we use Dell SC4020 works:
For example with:

Installed cinder volume:
...
Default_volume_type = dellfc
Enabled_backends = dellfc
[Dellfc]
Volume_backend_name = dellfc
Volume_driver = 
cinder.volume.drivers.dell.dell_storagecenter_fc.DellStorageCenterFCDriver

.

In the compute node we use nova-compute and cinder-volume to connect to 
the storage and it works OK with FC, with FCOE we are not yet using it 
because we are trying to solve the BCM57810 CNA functionality with Linux 
to be able to use DCB it does not work).


Using nfs, zfs, gluster, we use a dedicated volume cinder node, and it 
works fine. The doubt arises FCOE.


I would appreciate if someone has a similar configuration and tell us 
the experience.


Thank you

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] [openstack-dev] [keystone] deprecating and removing tools/sample_data.sh

2017-07-05 Thread Colleen Murphy

On Wed, Jul 5, 2017 at 9:36 PM, Lance Bragstad  wrote:

> Hi all,
>
> Keystone has a script to perform some bootstrapping operations [0]. It's
> not really tested and its purpose has been superseded by using the
> `keystone-manage bootstrap` command. Based on codesearch, only
> openstack/rpm-packaging references the script [1].
>
It's not exactly superceded by `keystone-manage bootstrap` - in fact it
uses bootstrap as part of its data generation:

https://github.com/openstack/keystone/blob/82f60fe22c405829f8e5f6576f25cf3663b10f73/tools/sample_data.sh#L97



> Is anyone opposed to the removal of this script in favor of more
> supported and tested bootstrapping methods?
>
I haven't used this script in a while but I have found value in it in the
past. It would be great if it or something like it was gate tested.

Colleen

>
> Thanks,
>
>
> [0]
> https://github.com/openstack/keystone/blob/82f60fe22c405829f8e5f6576f25cf
> 3663b10f73/tools/sample_data.sh
> [1] http://codesearch.openstack.org/?q=sample_data.sh=nope==
>
>
>
> __
> 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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [keystone] deprecating and removing tools/sample_data.sh

2017-07-05 Thread Colleen Murphy

On Wed, Jul 5, 2017 at 9:36 PM, Lance Bragstad  wrote:

> Hi all,
>
> Keystone has a script to perform some bootstrapping operations [0]. It's
> not really tested and its purpose has been superseded by using the
> `keystone-manage bootstrap` command. Based on codesearch, only
> openstack/rpm-packaging references the script [1].
>
It's not exactly superceded by `keystone-manage bootstrap` - in fact it
uses bootstrap as part of its data generation:

https://github.com/openstack/keystone/blob/82f60fe22c405829f8e5f6576f25cf3663b10f73/tools/sample_data.sh#L97



> Is anyone opposed to the removal of this script in favor of more
> supported and tested bootstrapping methods?
>
I haven't used this script in a while but I have found value in it in the
past. It would be great if it or something like it was gate tested.

Colleen

>
> Thanks,
>
>
> [0]
> https://github.com/openstack/keystone/blob/82f60fe22c405829f8e5f6576f25cf
> 3663b10f73/tools/sample_data.sh
> [1] http://codesearch.openstack.org/?q=sample_data.sh=nope==
>
>
>
> __
> 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] [neutron] writable mtu

2017-07-05 Thread Ihar Hrachyshka

Heya,

we have https://bugs.launchpad.net/neutron/+bug/1671634 approved for
Pike that allows setting MTU for network on creation. (but not update,
as per latest comment from Kevin there) I already see a use case to
modify MTU for an existing network (for example, where you enable
Jumbo frames for underlying infrastructure, and want to raise the
ceiling; another special case is when you migrate between different
encapsulation technologies, like in case of ml2/ovs to networking-ovn
migration where the latter doesn't support VXLAN but Geneve only).

If I go and implement the RFE as-is, and later in Queens we pursue
updating MTU for existing networks, we will have three extensions for
the same thing.

- net-mtu (existing read only attribute)
- net-mtu-enhanced (allow write on create)
- net-mtu-enhanced-enhanced (allow updates)

Not to mention potential addition of per-port MTU that some folks keep
asking for (and we keep pushing against so far).

So, I wonder if we can instead lay the ground for updatable MTU right
away, and allow_post: True from the start, even while implementing
create only as a phase-1. Then we can revisit the decision if needed
without touching api. What do you think?

Another related question is, how do we expose both old and new
extensions at the same time? I would imagine that implementations
capable of writing to the mtu attribute would advertise both old and
new extensions. Is it correct? Does neutron api layer allow for
overlapping attribute maps?

Ihar

__
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] [FEMDC][MassivelyDistributed] Strawman proposal for message bus analysis

2017-07-05 Thread Paul-Andre Raymond

Thank you Matt,

This is very insightful. It helps.

The second link did not work for me.

In the presentation, it mentioned that the load consisted “Boot and List” 
operations through Rally. 
Did I understand well?
Were those hitting the Openstack UI?
Was keystone involved? Was it using Fernet or another sort of token?

Intuitively, I expected 
- the big driver for performance on mariadb would be authentication tokens. And 
fernet would allow to control that.
- The big driver for performance on rabbitmq would be ceilometer, and it is not 
clear from your presentation that any telemetry data hit the message queue.

Regards,

Paul-Andre



-Original Message-
From: Matthieu Simonin 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Saturday, July 1, 2017 at 4:42 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [FEMDC][MassivelyDistributed] Strawman proposal 
for message bus analysis

Hi Paul-André,

This was without ceilometer. Nova + Neutron were consuming a lot of 
connections.
Some charts are available in the Barcelona presentation[1] and the 
performance docs[2].
In the latter you'll find some telemetry related tests.

[1]: 
https://www.openstack.org/assets/presentation-media/Chasing-1000-nodes-scale.pdf
[2]: https://docs.openstack.org/developer/performance-docs/

Best,

Matt

- Mail original -
> De: "Paul-Andre Raymond" 
> À: "OpenStack Development Mailing List (not for usage questions)" 

> Envoyé: Vendredi 30 Juin 2017 18:42:04
> Objet: Re: [openstack-dev] [FEMDC][MassivelyDistributed] Strawman 
proposal for message bus analysis
> 
> Hi Matthieu,
> 
> You mentioned 15000 connections with 1000 compute nodes.
> Was that mostly Nova? Was ceilometer involved?
> I would be curious to know how much AMQP traffic is Control 
related
> (e.g. spinning up VMs) vs how much is telemetry related in a 
typical
> openstack deployment.
> Do we know that?
> 
> I have also left some comments in the doc.
> 
> Paul-Andre
> 
> 
> -Original Message-
> From: Matthieu Simonin 
> Reply-To: "OpenStack Development Mailing List (not for usage 
questions)"
> 
> Date: Wednesday, June 21, 2017 at 6:54 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [FEMDC][MassivelyDistributed] Strawman
> proposal for  message bus analysis
> 
> Hi Ken,
> 
> Thanks for starting this !
> I've made a first pass on the epad and left some notes and 
questions
> there.
> 
> Best,
> 
> Matthieu
> - Mail original -
> > De: "Ken Giusti" 
> > À: "OpenStack Development Mailing List (not for usage 
questions)"
> > 
> > Envoyé: Mercredi 21 Juin 2017 15:23:26
> > Objet: [openstack-dev] [FEMDC][MassivelyDistributed] Strawman
> > proposal formessage bus analysis
> > 
> > Hi All,
> > 
> > Andy and I have taken a stab at defining some test scenarios for
> > anal the
> > different message bus technologies:
> > 
> > https://etherpad.openstack.org/p/1BGhFHDIoi
> > 
> > We've started with tests for just the oslo.messaging layer to
> > analyze
> > throughput and latency as the number of message bus clients - 
and
> > the bus
> > itself - scale out.
> > 
> > The next step will be to define messaging oriented test 
scenarios
> > for an
> > openstack deployment.  We've started by enumerating a few of the
> > tools,
> > topologies, and fault conditions that need to be covered.
> > 
> > Let's use this epad as a starting point for analyzing messaging 
-
> > please
> > feel free to contribute, question, and criticize :)
> > 
> > thanks,
> > 
> > 
> > 
> > --
> > Ken Giusti  (kgiu...@gmail.com)
> > 
> > 
__
> > OpenStack Development

[Openstack-operators] [keystone] deprecating and removing tools/sample_data.sh

2017-07-05 Thread Lance Bragstad

Hi all,   

Keystone has a script to perform some bootstrapping operations [0]. It's
not really tested and its purpose has been superseded by using the
`keystone-manage bootstrap` command. Based on codesearch, only
openstack/rpm-packaging references the script [1].

Is anyone opposed to the removal of this script in favor of more
supported and tested bootstrapping methods?

Thanks,


[0]
https://github.com/openstack/keystone/blob/82f60fe22c405829f8e5f6576f25cf3663b10f73/tools/sample_data.sh
[1] http://codesearch.openstack.org/?q=sample_data.sh=nope==




signature.asc
Description: OpenPGP digital signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [keystone] deprecating and removing tools/sample_data.sh

2017-07-05 Thread Lance Bragstad

Hi all,   

Keystone has a script to perform some bootstrapping operations [0]. It's
not really tested and its purpose has been superseded by using the
`keystone-manage bootstrap` command. Based on codesearch, only
openstack/rpm-packaging references the script [1].

Is anyone opposed to the removal of this script in favor of more
supported and tested bootstrapping methods?

Thanks,


[0]
https://github.com/openstack/keystone/blob/82f60fe22c405829f8e5f6576f25cf3663b10f73/tools/sample_data.sh
[1] http://codesearch.openstack.org/?q=sample_data.sh=nope==




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] [nova] bug triage experimentation

2017-07-05 Thread Emilien Macchi

On Fri, Jun 23, 2017 at 9:52 AM, Sean Dague  wrote:
> The Nova bug backlog is just over 800 open bugs, which while
> historically not terrible, remains too large to be collectively usable
> to figure out where things stand. We've had a few recent issues where we
> just happened to discover upgrade bugs filed 4 months ago that needed
> fixes and backports.
>
> Historically we've tried to just solve the bug backlog with volunteers.
> We've had many a brave person dive into here, and burn out after 4 - 6
> months. And we're currently without a bug lead. Having done a big giant
> purge in the past
> (http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html)
> I know how daunting this all can be.
>
> I don't think that people can currently solve the bug triage problem at
> the current workload that it creates. We've got to reduce the smart
> human part of that workload.
>
> But, I think that we can also learn some lessons from what active github
> projects do.
>
> #1 Bot away bad states
>
> There are known bad states of bugs - In Progress with no open patch,
> Assigned but not In Progress. We can just bot these away with scripts.
> Even better would be to react immediately on bugs like those, that helps
> to train folks how to use our workflow. I've got some starter scripts
> for this up at - https://github.com/sdague/nova-bug-tools
>
> #2 Use tag based workflow
>
> One lesson from github projects, is the github tracker has no workflow.
> Issues are openned or closed. Workflow has to be invented by every team
> based on a set of tags. Sometimes that's annoying, but often times it's
> super handy, because it allows the tracker to change workflows and not
> try to change the meaning of things like "Confirmed vs. Triaged" in your
> mind.
>
> We can probably tag for information we know we need at lot easier. I'm
> considering something like
>
> * needs.system-version
> * needs.openstack-version
> * needs.logs
> * needs.subteam-feedback
> * has.system-version
> * has.openstack-version
> * has.reproduce
>
> Some of these a bot can process the text on and tell if that info was
> provided, and comment how to provide the updated info. Some of this
> would be human, but with official tags, it would probably help.
>
> #3 machine assisted functional tagging
>
> I'm playing around with some things that might be useful in mapping new
> bugs into existing functional buckets like: libvirt, volumes, etc. We'll
> see how useful it ends up being.
>
> #4 reporting on smaller slices
>
> Build some tooling to report on the status and change over time of bugs
> under various tags. This will help visualize how we are doing
> (hopefully) and where the biggest piles of issues are.
>
> The intent is the normal unit of interaction would be one of these
> smaller piles. Be they the 76 libvirt bugs, 61 volumes bugs, or 36
> vmware bugs. It would also highlight the rates of change in these piles,
> and what's getting attention and what is not.
>
>
> This is going to be kind of an ongoing experiment, but as we currently
> have no one spear heading bug triage, it seemed like a good time to try
> this out.
>
> Comments and other suggestions are welcomed. The tooling will have the
> nova flow in mind, but I'm trying to make it so it takes a project name
> as params on all the scripts, so anyone can use it. It's a little hack
> and slash right now to discover what the right patterns are.

I also believe that some of the scripts could be transformed into
native features of Storyboard where bugs could be auto-triaged
periodically without human intervention.
Maybe it would convince more OpenStack projects to leave Launchpad and
adopt Storyboard?
I would certainly one of those and propose such a change for TripleO &
related projects.

Thanks,

> -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



-- 
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

Re: [openstack-dev] [nova] bug triage experimentation

2017-07-05 Thread Emilien Macchi

On Wed, Jun 28, 2017 at 7:33 AM, Ben Nemec  wrote:
>
>
> On 06/23/2017 11:52 AM, Sean Dague wrote:
>>
>> The Nova bug backlog is just over 800 open bugs, which while
>> historically not terrible, remains too large to be collectively usable
>> to figure out where things stand. We've had a few recent issues where we
>> just happened to discover upgrade bugs filed 4 months ago that needed
>> fixes and backports.
>>
>> Historically we've tried to just solve the bug backlog with volunteers.
>> We've had many a brave person dive into here, and burn out after 4 - 6
>> months. And we're currently without a bug lead. Having done a big giant
>> purge in the past
>>
>> (http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html)
>> I know how daunting this all can be.
>>
>> I don't think that people can currently solve the bug triage problem at
>> the current workload that it creates. We've got to reduce the smart
>> human part of that workload.
>>
>> But, I think that we can also learn some lessons from what active github
>> projects do.
>>
>> #1 Bot away bad states
>>
>> There are known bad states of bugs - In Progress with no open patch,
>> Assigned but not In Progress. We can just bot these away with scripts.
>> Even better would be to react immediately on bugs like those, that helps
>> to train folks how to use our workflow. I've got some starter scripts
>> for this up at - https://github.com/sdague/nova-bug-tools
>
>
> Just saw the update on https://bugs.launchpad.net/nova/+bug/1698010 and I
> don't agree that assigned but not in progress is an invalid state.  If it
> persists for a period of time then sure, but to me assigning yourself a bug
> is a signal that you're working on it and nobody else needs to. Otherwise
> you end up with multiple people working a bug without realizing someone else
> already was.  I've seen that happen more than once.

I agree with you Ben. While I was running this query for old bug, I've
stopped so bugs after March of this year won't be modified (let me
know if that's the case, then I'll fix it).

A grace period of 7 days is a good idea maybe.

> Would it be possible to only un-assign such bugs if they've been in that
> state for a week?  At that point it seems safe to say the assignee has
> either moved on or that the bug is tricky and additional input would be
> useful anyway.
>
> Otherwise, big +1 to a bug bot.  I need to try running it against the ~700
> open TripleO bugs...
>
>
>>
>> #2 Use tag based workflow
>>
>> One lesson from github projects, is the github tracker has no workflow.
>> Issues are openned or closed. Workflow has to be invented by every team
>> based on a set of tags. Sometimes that's annoying, but often times it's
>> super handy, because it allows the tracker to change workflows and not
>> try to change the meaning of things like "Confirmed vs. Triaged" in your
>> mind.
>>
>> We can probably tag for information we know we need at lot easier. I'm
>> considering something like
>>
>> * needs.system-version
>> * needs.openstack-version
>> * needs.logs
>> * needs.subteam-feedback
>> * has.system-version
>> * has.openstack-version
>> * has.reproduce
>>
>> Some of these a bot can process the text on and tell if that info was
>> provided, and comment how to provide the updated info. Some of this
>> would be human, but with official tags, it would probably help.
>>
>> #3 machine assisted functional tagging
>>
>> I'm playing around with some things that might be useful in mapping new
>> bugs into existing functional buckets like: libvirt, volumes, etc. We'll
>> see how useful it ends up being.
>>
>> #4 reporting on smaller slices
>>
>> Build some tooling to report on the status and change over time of bugs
>> under various tags. This will help visualize how we are doing
>> (hopefully) and where the biggest piles of issues are.
>>
>> The intent is the normal unit of interaction would be one of these
>> smaller piles. Be they the 76 libvirt bugs, 61 volumes bugs, or 36
>> vmware bugs. It would also highlight the rates of change in these piles,
>> and what's getting attention and what is not.
>>
>>
>> This is going to be kind of an ongoing experiment, but as we currently
>> have no one spear heading bug triage, it seemed like a good time to try
>> this out.
>>
>> Comments and other suggestions are welcomed. The tooling will have the
>> nova flow in mind, but I'm trying to make it so it takes a project name
>> as params on all the scripts, so anyone can use it. It's a little hack
>> and slash right now to discover what the right patterns are.
>>
>> -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



-- 
Emilien Macchi

Re: [openstack-dev] [nova] bug triage experimentation

2017-07-05 Thread Emilien Macchi

On Wed, Jun 28, 2017 at 7:33 AM, Ben Nemec  wrote:
>
>
> On 06/23/2017 11:52 AM, Sean Dague wrote:
>>
>> The Nova bug backlog is just over 800 open bugs, which while
>> historically not terrible, remains too large to be collectively usable
>> to figure out where things stand. We've had a few recent issues where we
>> just happened to discover upgrade bugs filed 4 months ago that needed
>> fixes and backports.
>>
>> Historically we've tried to just solve the bug backlog with volunteers.
>> We've had many a brave person dive into here, and burn out after 4 - 6
>> months. And we're currently without a bug lead. Having done a big giant
>> purge in the past
>>
>> (http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html)
>> I know how daunting this all can be.
>>
>> I don't think that people can currently solve the bug triage problem at
>> the current workload that it creates. We've got to reduce the smart
>> human part of that workload.
>>
>> But, I think that we can also learn some lessons from what active github
>> projects do.
>>
>> #1 Bot away bad states
>>
>> There are known bad states of bugs - In Progress with no open patch,
>> Assigned but not In Progress. We can just bot these away with scripts.
>> Even better would be to react immediately on bugs like those, that helps
>> to train folks how to use our workflow. I've got some starter scripts
>> for this up at - https://github.com/sdague/nova-bug-tools
>
>
> Just saw the update on https://bugs.launchpad.net/nova/+bug/1698010 and I
> don't agree that assigned but not in progress is an invalid state.  If it
> persists for a period of time then sure, but to me assigning yourself a bug
> is a signal that you're working on it and nobody else needs to. Otherwise
> you end up with multiple people working a bug without realizing someone else
> already was.  I've seen that happen more than once.
>
> Would it be possible to only un-assign such bugs if they've been in that
> state for a week?  At that point it seems safe to say the assignee has
> either moved on or that the bug is tricky and additional input would be
> useful anyway.
>
> Otherwise, big +1 to a bug bot.  I need to try running it against the ~700
> open TripleO bugs...

I just tried, please send complains to me if I broke something.

Sean, the tool is really awesome and I was wondering if we could move
it to https://github.com/openstack-infra/release-tools so we
centralize the tools.

Thanks,

>
>>
>> #2 Use tag based workflow
>>
>> One lesson from github projects, is the github tracker has no workflow.
>> Issues are openned or closed. Workflow has to be invented by every team
>> based on a set of tags. Sometimes that's annoying, but often times it's
>> super handy, because it allows the tracker to change workflows and not
>> try to change the meaning of things like "Confirmed vs. Triaged" in your
>> mind.
>>
>> We can probably tag for information we know we need at lot easier. I'm
>> considering something like
>>
>> * needs.system-version
>> * needs.openstack-version
>> * needs.logs
>> * needs.subteam-feedback
>> * has.system-version
>> * has.openstack-version
>> * has.reproduce
>>
>> Some of these a bot can process the text on and tell if that info was
>> provided, and comment how to provide the updated info. Some of this
>> would be human, but with official tags, it would probably help.
>>
>> #3 machine assisted functional tagging
>>
>> I'm playing around with some things that might be useful in mapping new
>> bugs into existing functional buckets like: libvirt, volumes, etc. We'll
>> see how useful it ends up being.
>>
>> #4 reporting on smaller slices
>>
>> Build some tooling to report on the status and change over time of bugs
>> under various tags. This will help visualize how we are doing
>> (hopefully) and where the biggest piles of issues are.
>>
>> The intent is the normal unit of interaction would be one of these
>> smaller piles. Be they the 76 libvirt bugs, 61 volumes bugs, or 36
>> vmware bugs. It would also highlight the rates of change in these piles,
>> and what's getting attention and what is not.
>>
>>
>> This is going to be kind of an ongoing experiment, but as we currently
>> have no one spear heading bug triage, it seemed like a good time to try
>> this out.
>>
>> Comments and other suggestions are welcomed. The tooling will have the
>> nova flow in mind, but I'm trying to make it so it takes a project name
>> as params on all the scripts, so anyone can use it. It's a little hack
>> and slash right now to discover what the right patterns are.
>>
>> -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



-- 
Emilien Macchi

Re: [openstack-dev] [FEMDC] Use Cases

2017-07-05 Thread Paul-Andre Raymond

Following our discussion today, I have added a slide (see slide 11) in the 
google docs about  not underestimating the importance of networking for our use 
cases.
Specifically, to fully describe a use case, It would be useful to flesh out the 
following aspects.

The performance of a specific use case will depend specifically on how 
networking implementation is done in Edge Node.
1- Do we use Neutron or something else? (e.g. Tricircle)
2- Is networking in Edge node at L2, or is it done at L3?
3- Is there a need for encryption (between edge and central nodes)? Is there a 
performance impact (e.g. MTU)?
4- How is Control plane separated from User Plane?



This completes an action I took today.

Regards,

Paul-Andre



From: Paul-André Raymond 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, July 5, 2017 at 12:53 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [FEMDC] Use Cases

All,

I look forward to continue discussions on how to structure use cases during our 
FEMDC call today.

You will find some slides on google doc that describe my thinking.
https://docs.google.com/presentation/d/1sBczuC2Wu1d_misBmPahLPdvyhOI4QuVy129EHunuUM/edit#slide=id.g1f7f1a38ce_2_102


You will see in there that I feel a use case should include:


  1.  A Deployment Scenario (e.g. NFV or Edge or Federation)
  2.  A Service Use Case  (e.g. IOT, or Mobility or AR or …)
  3.  Openstack component distribution use case  (Regions or Cells or other)
  4.  User plane use case (e.g. Failure scenario)
  5.  Control Plane Use case (e.g. node commissioning or decommissioning)

Please let me know your comments.

Paul-Andre


__
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] weekly meetings on #tripleo

2017-07-05 Thread Ben Nemec

I don't have a particularly strong opinion one way or another (probably 
because I tend to skip most of the meetings lately anyway...), but some 
thoughts inline.


On 07/05/2017 11:56 AM, Emilien Macchi wrote:

After reading 
http://lists.openstack.org/pipermail/openstack-dev/2017-June/118899.html
- we might want to collect TripleO's community feedback on doing
weekly meetings on #tripleo instead of #openstack-meeting-alt.

I see some direct benefits:
- if you come up late in meetings, you could easily read backlog in #tripleo


Most people idle in the meeting channels anyway, so +0 on this one.


- newcomers not aware about the meeting channel wouldn't have to search for it


We generally announce meetings in #tripleo before starting, don't we?


- meeting would maybe get more activity and we would expose the
information more broadly


I guess this would preclude non-meeting related activity in #tripleo, 
which in my experience is a thing that happens pretty frequently during 
the meeting.  Whether that's a good thing or not is a matter of opinion. :-)




Any feedback on this proposal is welcome before we make any change (or not).

Thanks,



__
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] [ui] Integration testing in tripleo-ci

2017-07-05 Thread Ben Nemec

On 07/05/2017 10:21 AM, Emilien Macchi wrote:

On Wed, Jul 5, 2017 at 7:57 AM, Florian Fuchs wrote:

On Tue, Jul 4, 2017 at 7:48 PM, Emilien Macchi wrote:

On Fri, Jun 30, 2017 at 10:51 AM, Honza Pokorny wrote:

I'd like to write some integration tests for the TripleO UI. Simple
configuration checks, workflow tests, websocket tests, etc.

I had a quick look at the tripleo-ci [1] repository, and it wasn't
immediately obvious to me how to extend the existing infrastructure to
add something like this. It seems to me that the current way is just
"stick some shell script here and here". The tripleo.sh script is about
1,600 LOC and it look rather intimidating.

I'm looking for help or pointers on how to do this. Is there a standard
way of accomplishing this? Are there any helpers I should be aware of?
Is there any documentation beyond what is in the git tree?

Any help would be appreciated

I think we have 2 options here (which could also be mixed):

- Using tripleo-validatons and make sure we run it in CI.

+1 for using ansible playbooks to write UI tests. I just don't think
we should host the test playbooks in the tripleo-validations
repository, because IMO testing the UI is different to what the
tripleo-validations are doing.
That said, the UI tests could use the ansible inventory from
tripleo-validations -- which ends up in
/usr/bin/tripleo-ansible-inventory and is already being used by
playbooks other than tripleo-validations.

If tripleo-ui functional tests are written in Python, it makes a lot
of sense to write a Tempest plugin instead of using Ansible.

+1. This seems like an obvious place to take advantage of the framework
Tempest already has in place. These aren't intended as user-facing
tests so implementing them as validations would be a weird fit to me.

The major reason to me is consistency with how we test other services
in TripleO.

Whatever option we'll take, we'll need a new repository I think that
will contain the actual tests. There is a goal in Queens where Tempest
plugins are out of tree:
https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
If we take that path, we'll create a new repo for that.

The Ansible option would also be fine but we need to acknowledge the
fact tripleo-ui testing wouldn't be possible without deploying the
tripleo-validations bits.

Florian

- Write a tempest plugin for tripleo-ui (like Horizon has one:
https://github.com/openstack/tempest-horizon) (it could be
openstack/tempest-triploe-ui) for example. We could run the tempest
tests in the CI jobs (we're working on running Tempest on scenario
jobs, see efforts made in
https://trello.com/c/Z8jIillp/252-spec-out-the-work-required-to-run-tempest-on-the-tripleo-gating-jobs).

Please do not implement tests in tripleo-ci or quickstart, I think we
need a way to test it outside CI and include it directly in the
product.

Thanks,

Thanks!

Honza Pokorny

[1]: https://github.com/openstack-infra/tripleo-ci

__
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

--
Emilien Macchi

Re: [openstack-dev] [TripleO][keystone] Pt. 2 of Passing along some field feedback

2017-07-05 Thread Ben Nemec




On 07/04/2017 12:58 PM, Emilien Macchi wrote:

On Wed, Jun 28, 2017 at 3:47 PM, Lance Bragstad  wrote:



On 06/28/2017 02:29 PM, Fox, Kevin M wrote:

I think everyone would benefit from a read-only role for keystone out of the 
box. Can we get this into keystone rather then in the various distro's?

Yeah - I think that would be an awesome idea. John Garbutt had some good
work on this earlier in the cycle. Most of it was documented in specs
[0] [1]. FWIW - this will be another policy change that is going to have
cross-project effects. It's implementation or impact won't be isolated
to keystone if we want read-only roles out-of-the-box.


I just wanted to complete what Lance said with the ongoing
cross-project effort: we're close to approve
https://review.openstack.org/#/c/469954/ for Queens cycle, which means
projects would make some efforts on moving default policies into code
and documenting them.


Oh, that reminds me that the policy-in-code stuff came up on one of 
these calls too (since I first wrote the emails).  There was definitely 
a desire from the people on the call to have all the projects taking 
advantage of policy-in-code for the sake of consistency across all the 
OpenStack projects.  Otherwise it gets confusing to know whether you 
need a full policy file or just overrides.



I also think it would be great to solve this issue into projects
themselves and provide the option for operators.

The way it was done in TripleO (manage policy.json files with Puppet)
was temporary I guess, until we can use what will be done by projects.
Any feedback to make it better in the meanwhile is very welcome.


[0] https://review.openstack.org/#/c/427872/19
[1] https://review.openstack.org/#/c/428454/


Thanks,
Kevin

From: Ben Nemec [openst...@nemebean.com]
Sent: Wednesday, June 28, 2017 12:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [TripleO] Pt. 2 of Passing along some field feedback

A few weeks later than I had planned, but here's the other half of the
field feedback I mentioned in my previous email:

* They very emphatically want in-place upgrades to work when moving from
non-containerized to containerized.  I think this is already the plan,
but I told them I'd make sure development was aware of the desire.

* There was also great interest in contributing back some of the custom
templates that they've had to write to get advanced features working in
the field.  Here again we recommended that they start with an RFE so
things could be triaged appropriately.  I'm hoping we can find some
developer time to help polish and shepherd these things through the
review process.

* Policy configuration was discussed, and I pointed them at some recent
work we have done around that:
https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/api_policies.html
  I'm not sure it fully addressed their issues, but I suggested they
take a closer look and provide feedback on any ways it doesn't meet
their needs.

The specific use case they were looking at right now was adding a
read-only role.  They did provide me with a repo containing their
initial work, but unfortunately it's private to Red Hat so I can't share
it here.

* They wanted to be able to maintain separate role files instead of one
monolithic roles_data.yaml.  Apparently they have a pre-deploy script
now that essentially concatenates some individual files to get this
functionality.  I think this has already been addressed by
https://review.openstack.org/#/c/445687

* They've also been looking at ways to reorganize the templates in a
more intuitive fashion.  At first glance the changes seemed reasonable,
but they were still just defining the layout.  I don't know that they've
actually tried to use the reorganized templates yet and given the number
of relative paths in tht I suspect it may be a bigger headache than they
expect, but I thought it was interesting.  There may at least be
elements of this work that we can use to make the templates easier to
understand for deployers.

Thanks.

-Ben

__
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] [tripleo] weekly meetings on #tripleo

2017-07-05 Thread Juan Antonio Osorio

+1

On 5 Jul 2017 19:57, "Emilien Macchi"  wrote:

> After reading http://lists.openstack.org/pipermail/openstack-dev/2017-
> June/118899.html
> - we might want to collect TripleO's community feedback on doing
> weekly meetings on #tripleo instead of #openstack-meeting-alt.
>
> I see some direct benefits:
> - if you come up late in meetings, you could easily read backlog in
> #tripleo
> - newcomers not aware about the meeting channel wouldn't have to search
> for it
> - meeting would maybe get more activity and we would expose the
> information more broadly
>
> Any feedback on this proposal is welcome before we make any change (or
> not).
>
> Thanks,
> --
> 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 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] weekly meetings on #tripleo

2017-07-05 Thread Emilien Macchi

After reading 
http://lists.openstack.org/pipermail/openstack-dev/2017-June/118899.html
- we might want to collect TripleO's community feedback on doing
weekly meetings on #tripleo instead of #openstack-meeting-alt.

I see some direct benefits:
- if you come up late in meetings, you could easily read backlog in #tripleo
- newcomers not aware about the meeting channel wouldn't have to search for it
- meeting would maybe get more activity and we would expose the
information more broadly

Any feedback on this proposal is welcome before we make any change (or not).

Thanks,
-- 
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] [keystone] Queens PTG Planning

2017-07-05 Thread Lance Bragstad

Hey all,

I've started an etherpad [0] for us to collect topics and ideas for the
PTG in September. I hope to follow the same planning format as last
time. Everyone has the opportunity to add topics to the agenda and after
some time we'll group related topics and start building a formal schedule.

The etherpad has two lists. One for project-specific topics and one for
cross-project topics. As soon as we firm up the things we need to
collaborate on with other projects, I'll start coordinating with other
teams. These were the sessions we had to work around last time due to
schedules. We can sprinkle the project related topics in to fill the gaps.

Let me know if you have any questions.

Thanks!


[0] https://etherpad.openstack.org/p/keystone-queens-ptg




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] [tc][all][ptl] Most Supported Queens Goals and Improving Goal Completion

2017-07-05 Thread Lance Bragstad



On 06/30/2017 04:38 AM, Thierry Carrez wrote:
> Mike Perez wrote:
>> [...]
>> What do people think before we bikeshed on the name? Would having a
>> champion volunteer to each goal to help?
> It feels like most agree that having champions would help. Do we have
> any volunteer for the currently-proposed Pike goals ? As a reminder,
> those are:
>
> * Split Tempest plugins into separate repos/projects [1]
> * Move policy and policy docs into code [2]
I can champion the policy docs changes.
>
> [1]
> https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
> [2] https://review.openstack.org/#/c/469954/
>




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

[openstack-dev] [kolla] Today meeting cancelled due to lack of agenda

2017-07-05 Thread Michał Jastrzębski

Some time to kick start brains after 4th of July:)

Regards,
Michal
__
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] [ui] Integration testing in tripleo-ci

2017-07-05 Thread Emilien Macchi

On Wed, Jul 5, 2017 at 7:57 AM, Florian Fuchs  wrote:
> On Tue, Jul 4, 2017 at 7:48 PM, Emilien Macchi  wrote:
>> On Fri, Jun 30, 2017 at 10:51 AM, Honza Pokorny  wrote:
>>> I'd like to write some integration tests for the TripleO UI.  Simple
>>> configuration checks, workflow tests, websocket tests, etc.
>>>
>>> I had a quick look at the tripleo-ci [1] repository, and it wasn't
>>> immediately obvious to me how to extend the existing infrastructure to
>>> add something like this.  It seems to me that the current way is just
>>> "stick some shell script here and here".  The tripleo.sh script is about
>>> 1,600 LOC and it look rather intimidating.
>>>
>>> I'm looking for help or pointers on how to do this.  Is there a standard
>>> way of accomplishing this?  Are there any helpers I should be aware of?
>>> Is there any documentation beyond what is in the git tree?
>>>
>>> Any help would be appreciated
>>
>> I think we have 2 options here (which could also be mixed):
>>
>> - Using tripleo-validatons and make sure we run it in CI.
>
> +1 for using ansible playbooks to write UI tests. I just don't think
> we should host the test playbooks in the tripleo-validations
> repository, because IMO testing the UI is different to what the
> tripleo-validations are doing.
> That said, the UI tests could use the ansible inventory from
> tripleo-validations -- which ends up in
> /usr/bin/tripleo-ansible-inventory and is already being used by
> playbooks other than tripleo-validations.

If tripleo-ui functional tests are written in Python, it makes a lot
of sense to write a Tempest plugin instead of using Ansible.
The major reason to me is consistency with how we test other services
in TripleO.

Whatever option we'll take, we'll need a new repository I think that
will contain the actual tests. There is a goal in Queens where Tempest
plugins are out of tree:
https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
If we take that path, we'll create a new repo for that.


The Ansible option would also be fine but we need to acknowledge the
fact tripleo-ui testing wouldn't be possible without deploying the
tripleo-validations bits.

> Florian
>
>
>> - Write a tempest plugin for tripleo-ui (like Horizon has one:
>> https://github.com/openstack/tempest-horizon) (it could be
>> openstack/tempest-triploe-ui) for example. We could run the tempest
>> tests in the CI jobs (we're working on running Tempest on scenario
>> jobs, see efforts made in
>> https://trello.com/c/Z8jIillp/252-spec-out-the-work-required-to-run-tempest-on-the-tripleo-gating-jobs).
>>
>> Please do not implement tests in tripleo-ci or quickstart, I think we
>> need a way to test it outside CI and include it directly in the
>> product.
>>
>> Thanks,
>>
>>> Thanks!
>>>
>>> Honza Pokorny
>>>
>>> [1]: https://github.com/openstack-infra/tripleo-ci
>>>
>>> __
>>> 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
>>
>>
>>
>> --
>> 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 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



-- 
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

Re: [Openstack-operators] [User-committee] [publiccloud-wg] Reminder meeting PublicCloudWorkingGroup

2017-07-05 Thread Edgar Magana

Thanks for the reminder Tobias.

Edgar

From: Tobias Rydberg 
Date: Tuesday, July 4, 2017 at 10:43 PM
To: "user-commit...@lists.openstack.org" , 
"openstack-...@lists.openstack.org" , 
"openstack-operators@lists.openstack.org" 

Subject: [User-committee] [publiccloud-wg] Reminder meeting 
PublicCloudWorkingGroup

Hi everyone,

Don't forget todays meeting for the PublicCloudWorkingGroup.
1400 UTC in IRC channel #openstack-meeting-3

Etherpad: https://etherpad.openstack.org/p/publiccloud-wg

Goals: https://etherpad.openstack.org/p/SYDNEY_GOALS_publiccloud-wg

Talk to you this afternoon!
Tobias
tob...@citynetwork.se
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [User-committee] [publiccloud-wg] Reminder meeting PublicCloudWorkingGroup

2017-07-05 Thread Edgar Magana

Thanks for the reminder Tobias.

Edgar

From: Tobias Rydberg 
Date: Tuesday, July 4, 2017 at 10:43 PM
To: "user-commit...@lists.openstack.org" , 
"openstack-dev@lists.openstack.org" , 
"openstack-operat...@lists.openstack.org" 

Subject: [User-committee] [publiccloud-wg] Reminder meeting 
PublicCloudWorkingGroup

Hi everyone,

Don't forget todays meeting for the PublicCloudWorkingGroup.
1400 UTC in IRC channel #openstack-meeting-3

Etherpad: https://etherpad.openstack.org/p/publiccloud-wg

Goals: https://etherpad.openstack.org/p/SYDNEY_GOALS_publiccloud-wg

Talk to you this afternoon!
Tobias
tob...@citynetwork.se
__
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] [keystone] no policy meeting today

2017-07-05 Thread Lance Bragstad

Hey all,

Given the empty agenda [0] and the holiday, we will cancel the policy
meeting this week. We'll pick up again next week.

Thanks

[0] https://etherpad.openstack.org/p/keystone-policy-meeting




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] [tripleo] [ui] Integration testing in tripleo-ci

2017-07-05 Thread Florian Fuchs

On Tue, Jul 4, 2017 at 7:48 PM, Emilien Macchi  wrote:
> On Fri, Jun 30, 2017 at 10:51 AM, Honza Pokorny  wrote:
>> I'd like to write some integration tests for the TripleO UI.  Simple
>> configuration checks, workflow tests, websocket tests, etc.
>>
>> I had a quick look at the tripleo-ci [1] repository, and it wasn't
>> immediately obvious to me how to extend the existing infrastructure to
>> add something like this.  It seems to me that the current way is just
>> "stick some shell script here and here".  The tripleo.sh script is about
>> 1,600 LOC and it look rather intimidating.
>>
>> I'm looking for help or pointers on how to do this.  Is there a standard
>> way of accomplishing this?  Are there any helpers I should be aware of?
>> Is there any documentation beyond what is in the git tree?
>>
>> Any help would be appreciated
>
> I think we have 2 options here (which could also be mixed):
>
> - Using tripleo-validatons and make sure we run it in CI.

+1 for using ansible playbooks to write UI tests. I just don't think
we should host the test playbooks in the tripleo-validations
repository, because IMO testing the UI is different to what the
tripleo-validations are doing.
That said, the UI tests could use the ansible inventory from
tripleo-validations -- which ends up in
/usr/bin/tripleo-ansible-inventory and is already being used by
playbooks other than tripleo-validations.

Florian


> - Write a tempest plugin for tripleo-ui (like Horizon has one:
> https://github.com/openstack/tempest-horizon) (it could be
> openstack/tempest-triploe-ui) for example. We could run the tempest
> tests in the CI jobs (we're working on running Tempest on scenario
> jobs, see efforts made in
> https://trello.com/c/Z8jIillp/252-spec-out-the-work-required-to-run-tempest-on-the-tripleo-gating-jobs).
>
> Please do not implement tests in tripleo-ci or quickstart, I think we
> need a way to test it outside CI and include it directly in the
> product.
>
> Thanks,
>
>> Thanks!
>>
>> Honza Pokorny
>>
>> [1]: https://github.com/openstack-infra/tripleo-ci
>>
>> __
>> 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
>
>
>
> --
> 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 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] [acceleration]No Cyborg Team Meeting today

2017-07-05 Thread Zhipeng Huang

Even the longest OpenStack team meeting need a rest for independence day :)

However in the mean time please help review the open patches :)

We will resume next week

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] quickstart failing due to unresolved dependencies

2017-07-05 Thread Alex Schultz

On Mon, Jul 3, 2017 at 11:18 PM, Udi Kalifon  wrote:
> I'm trying to install Pike. The undercloud has versions:
> puppet-tripleo-7.1.1-0.20170627224658.f99b72a.el7.centos.noarch
> instack-undercloud-7.1.1-0.20170619172442.4de8226.el7.centos.noarch
>

I think you're missing, https://review.openstack.org/#/c/475352/
because your puppet-tripleo has
https://review.openstack.org/#/c/475387/ which removed that profile.
Update your instack-undercloud.

Thanks,
-Alex

>
>
> Regards,
> Udi Kalifon; Senior QE; RHOS-UI Automation
>
>
> On Mon, Jul 3, 2017 at 8:58 PM, Alex Schultz  wrote:
>>
>> On Sun, Jul 2, 2017 at 7:11 AM, Udi Kalifon  wrote:
>> > Hi.
>> >
>> > I tried to install the latest TripleO with quickstart, and it failed in
>> > the
>> > undercloud install. I logged in to the undercloud and checked the
>> > install
>> > log, and I see errors there like "ModuleLoader: module 'rabbitmq' has
>> > unresolved dependencies". I pasted the output here:
>> > http://paste.openstack.org/show/614247/
>> >
>> > Any help on how to fix this will be appreciated !
>>
>> It seems to have failed while trying to run puppet and it couldn't
>> find a specific class.
>>
>> 2017-07-02 12:37:12,614 INFO: Error: Evaluation Error: Error while
>> evaluating a Function Call, Could not find class
>> ::tripleo::profile::base::ui for undercloud at
>> /etc/puppet/manifests/puppet-stack-config.pp:585:3 on node undercloud
>>
>> What version are you deploying?  This may happen if there's an
>> mismatch between the instack-undercloud and the puppet-tripleo
>> packages
>>
>> Thanks,
>> -Alex
>>
>>
>> >
>> > Regards,
>> > Udi Kalifon
>> >
>> >
>> > __
>> > 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] [congress] Using congress to improve the consistency of configuration files.

2017-07-05 Thread pierre.cregut

This is the classical divide between workflows and business rule engines 
and we
think that both are useful. While the first are invaluable to make a 
system reach
a correct state, the second describe in a more declarative way what a 
correct
state is and can also be used as a global model of the set of correct 
configurations.
A workflow engine will bring you to a reproducible state but this state 
is correct only

because some rules have been verified beforehand. Workflows are also often
designed in silos. When you need to combine playbooks, interactions may 
lead to
unexpected problems. Testing is necessary but if you can capture 
invariants (types)

you will spend less time and get better confidence on your deployments.

The difference of roles already exist between an orchestrator such as 
Heat and

Congress. You could use Heat in such a way  templates only describe correct
configurations according to your policies and test your templates to 
ensure they
do follow your rules but you will still use Congress as the place to 
describe the

policy and a way to check compliance.

Because we have thousands of options with requirements that are not all
functionals and coming from different sources (project, vendors, 
security team,

global and local design, ops knowledge) we should try to find ways to make
knowledge explicit, declarative and composable rather than bury it in
imperative procedures. The bet is that formalized rules will be much easier
to capitalize on than informal documentation. May be in the future, a 
lot of

rules could be supplied directly by OpenStack projects when options are
defined as a companion to the informal help descriptions.

Regards,

Pierre Crégut


On 07/04/2017 05:17 PM, Clint Byrum wrote:

Excerpts from valentin.matton's message of 2017-07-04 15:29:25 +0200:

We would like to use congress to check the consistency of the
configuration files used by the various Openstack services on different
nodes.

Although installers do a great job for ensuring that the initial
definition of those files are correct, it may be necessary to tweak
those files on running instances
or to use templates that are out of the bounds of the pre-configured
use-cases. Then the administrator must modify the configuration without
any safety net.


While I'm sure this does still happen, you'd have to be living under a
rock to think that this is the state of the art.

I'm certain _most_ OpenStack installs are using automated configuration
management to assert their config file content. And if they're
practicing safe deploys, they also have integration tests to make sure
those modifications work properly.

Now, if Congress does in fact want to compete with Puppet / Chef /
Ansible / Salt / etc., I suppose that's Congress's choice. But just to
be clear: very few operators are doing what you suggest as the reason
to make Congress do this.






--
--

Orange Logo

*Pierre Crégut*
IMT/OLN/WTC/IEE/NAVI
tél. +33 (0)2 96 07 19 76
pierre.cre...@orange.com 


_

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

Re: [openstack-dev] [ironic][magnum][kolla][ansible][puppet][rally] removing SSH drivers from Ironic

2017-07-05 Thread Alex Schultz

On Wed, Jul 5, 2017 at 5:01 AM, Pavlo Shchelokovskyy
 wrote:
> Hi all,
>
> as mitaka branch was finally EOLed, Ironic team is going to proceed with
> removal of SSH-based power and management drivers for virtualized HW which
> were deprecated back in newton release.
>
> Since newton the virtualbmc-based simulation of IPMI-capable HW is
> officially supported, and we plan to switch all gates away from using *_ssh
> drivers and eventually remove those from the ironic code, most probably in
> Pike release.
>
> I've skimmed through the project-config/zuul/layout.yaml and found a number
> of projects that use some gate jobs with 'ironic' in the job name which are
> not defined in project-config/jenkins/jobs/ironic.yaml, those project are
> tagged in the subject of this message.
>
> While kolla, magnum, OSA and rally seem to have only non-voting jobs with
> ironic and thus should not be completely broken by removal of SSH drivers
> anyway, puppet-ironic seems to have a voting
> "puppet-openstack-integration-jobs-scenario002" job.
>

We're OK, we don't have the ssh driver[0] in our test job.  We also
had previously deprecated the ssh driver in puppet-ironic[1] so we can
remove it now that we're in Pike.

Thanks,
-Alex

[0] 
https://github.com/openstack/puppet-openstack-integration/blob/master/manifests/ironic.pp#L73
[1] https://review.openstack.org/#/c/446918/

> This message especially concerns deployment-specific projects that do not
> install ironic via DevStack in their gate jobs. To successfully install a
> working ironic which is capable to actually deploy nodes, such projects will
> have to incorporate some additional steps to setup virtualbmc-based HW
> simulation for baremetal nodes and configure nodes enrolled in ironic
> accordingly.
>
> If your project is mentioned, please ensure that any ironic-including gate
> jobs you use do not setup ironic with *_ssh drivers, and switch to other
> supported drivers if needed. Examples of necessary steps can be found in
> ironic's DevStack plugin and in the playbooks of openstack/bifrost project.
>
> For any questions please do not hesitate to contact ironic team, we'll be
> glad to help you.
>
> Best regards,
> --
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.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-operators] User Committee Election coming soon!

2017-07-05 Thread Shilla Saebi

Hello Everyone,



The OpenStack User Committee will be holding an election in August, per the
(UC) bylaws and charter
. The current
UC will serve until the elections in August. At that point, the current two
UC members who still have 6 months to serve get a 6-month seat, and an
election is run to determine the other three members. Candidates ranking 1st,
2nd, and 3rd will get a one-year seat. Voting for the 2017 UC members will
be granted to the Active User Contributors (AUC).




Open candidacy for the UC positions will be from July 31 - August 11, 05:59
UTC. Voting for the User Committee (UC) members will be open on August 14th and
will remain open until August 18, 11:59 UTC. Additional details and the
process for nomination can be found here
.



As a reminder, please see the community code of conduct (
http://www.openstack.org/legal/community-code-of-conduct/)



Please let me, or anyone from the UC know if you have any questions,
comments or concerns.



Thank you,



OpenStack User Committee

Shilla, Edgar, Jonathan, Melvin, Shamail
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [OpenStack-Infra] Request to EOL Puppet OpenStack Mitaka

2017-07-05 Thread Emilien Macchi

On Wed, Jul 5, 2017 at 5:29 AM, Emilien Macchi  wrote:
> On Wed, Jul 5, 2017 at 6:13 AM, Joshua Hesketh  
> wrote:
>> Hello Emilien,
>>
>> My apologies for not getting to this sooner. I've processed the list that
>> Tony put together which included the puppet repos. Please let me know if
>> I've missed anything.

Actually we missed something in the request: could you please EOL
puppet-ceph stable/hammer too?

Thanks again,

> It's perfect, thanks a lot for your help- :)
>
>> Cheers,
>> Josh
>>
>> On Wed, Jul 5, 2017 at 6:19 AM, Emilien Macchi  wrote:
>>>
>>> On Fri, Jun 23, 2017 at 12:19 AM, Emilien Macchi 
>>> wrote:
>>> > On Wed, Jun 21, 2017 at 6:42 PM, Jeremy Stanley 
>>> > wrote:
>>> >> On 2017-06-21 09:03:47 -0400 (-0400), Emilien Macchi wrote:
>>> >> [...]
>>> >>> Can anyone have a look please?
>>> >>> We would like to EOL Puppet OpenStack Mitaka.
>>>
>>> Hey it's me again :-)
>>> If someone has little time to help me on this process, I would buy
>>> him/her Canadian beers (some said they're better than US but I don't
>>> want to get in trouble here) at next summit in Vancouver.
>>>
>>> Thanks,
>>>
>>> >> It's not forgotten, Infra's just spread thin and some weeks
>>> >> (especially when lots of people go to conferences) it's about all we
>>> >> can do to keep the lights on. For larger non-urgent requests like
>>> >> this to be deprioritized and take more than a week to address is,
>>> >> unfortunately, not atypical.
>>> >>
>>> >> Making matters worse, I'll be mostly (if not completely) away from
>>> >> the computer for the next five days, so unless someone else gets to
>>> >> it before then I can't really commit to it until I'm around again
>>> >> either.
>>> >
>>> > Thanks for clarifying, and apologize, I didn't have the full context.
>>> > It's really fine to wait, there is no hurry, I just wanted to make
>>> > sure it would happen sometimes.
>>> >
>>> > Have a great time off and we'll see if someone can help on this task
>>> > later, but again nothing urgent.
>>> >
>>> > Cheers,
>>> >
>>> >> --
>>> >> Jeremy Stanley
>>> >>
>>> >> ___
>>> >> OpenStack-Infra mailing list
>>> >> OpenStack-Infra@lists.openstack.org
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>> >
>>> >
>>> >
>>> > --
>>> > Emilien Macchi
>>>
>>>
>>>
>>> --
>>> Emilien Macchi
>>>
>>> ___
>>> OpenStack-Infra mailing list
>>> OpenStack-Infra@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>>
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] (no subject)

2017-07-05 Thread Lawrence J. Albinson

Hi Andy,

Thank you. Yes, 15.1.6 seems good.

Kind regards, Lawrence

From: Andy McCrae
Sent: 04 July 2017 17:31
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] (no subject)

Hi Lawrence,

On 4 July 2017 at 12:29, Lawrence J. Albinson 
> wrote:
Dear Colleagues,

Before I go problem hunting, has anyone seen openstack-ansible builds failing 
at release 15.1.5 at the following point:

TASK [lxc_container_create : Create localhost config] **

with the error 'lxc-attach: command not found'?

The self-same environment is working fine at 15.1.3.

I've turned up nothing with searches. Any help greatly appreciated.

I know there were some issues created by changes to LXC and Ansible that look 
related to what you're seeing.
Although, I believed those were resolved - 
https://review.openstack.org/#/c/475438/
Looking at the patch that merged it seems this will only be in the latest 
release (which just got released!)
Try updating to 15.1.6 . and see if that resolves it, if not let us know.

Kind Regards,
Andy

__
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] [congress] Using congress to improve the consistency of configuration files. (OpenStack-dev Digest, Vol 63, Issue 5)

2017-07-05 Thread pierre.cregut

This is the classical divide between workflows and business rule
engines and we think that both are useful. While the first are
invaluable to make a system reach a correct state, the second
describe in a more declarative way what a correct state is and can
also be used as a global model of the set of correct
configurations. A workflow engine will bring you to a reproducible
state but this state is correct only because some rules have been
verified beforehand. Workflows are also often designed in silos.
When you need to combine playbooks, interactions may lead to
unexpected problems. Testing is necessary but if you can capture
invariants (types) you will spend less time and get better
confidence on your deployments.

The difference of roles already exist between an orchestrator such
as Heat and Congress. You could use Heat in such a way templates
only describe correct configurations according to your policies
and test your templates to ensure they do follow your rules but
you will still use Congress as the place to describe the policy
and a way to check compliance.

Because we have thousands of options with requirements that are
not all functionals and coming from different sources (project,
vendors, security team, global and local design, ops knowledge) we
should try to find ways to make knowledge explicit, declarative
and composable rather than bury it in imperative procedures. The
bet is that formalized rules will be much easier to capitalize on
than informal documentation. May be in the future, a lot of rules
could be supplied directly by OpenStack projects when options are
defined as a companion to the informal help descriptions.

Regards,

Pierre Crégut

On 07/04/2017 05:17 PM, Clint Byrum
wrote:

Excerpts from valentin.matton's message of 2017-07-04 15:29:25 +0200:

We would like to use congress to check the consistency of the
configuration files used by the various Openstack services on different
nodes.

Although installers do a great job for ensuring that the initial
definition of those files are correct, it may be necessary to tweak
those files on running instances
or to use templates that are out of the bounds of the pre-configured
use-cases. Then the administrator must modify the configuration without
any safety net.

While I'm sure this does still happen, you'd have to be living under a
rock to think that this is the state of the art.

I'm certain _most_ OpenStack installs are using automated configuration
management to assert their config file content. And if they're
practicing safe deploys, they also have integration tests to make sure
those modifications work properly.

Now, if Congress does in fact want to compete with Puppet / Chef /
Ansible / Salt / etc., I suppose that's Congress's choice. But just to
be clear: very few operators are doing what you suggest as the reason
to make Congress do this.

Pierre
Crégut
IMT/OLN/WTC/IEE/NAVI
tél. +33 (0)2 96 07 19 76
pierre.cre...@orange.com

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.

Re: [OpenStack-Infra] Request to EOL Puppet OpenStack Mitaka

2017-07-05 Thread Emilien Macchi

On Wed, Jul 5, 2017 at 6:13 AM, Joshua Hesketh  wrote:
> Hello Emilien,
>
> My apologies for not getting to this sooner. I've processed the list that
> Tony put together which included the puppet repos. Please let me know if
> I've missed anything.

It's perfect, thanks a lot for your help- :)

> Cheers,
> Josh
>
> On Wed, Jul 5, 2017 at 6:19 AM, Emilien Macchi  wrote:
>>
>> On Fri, Jun 23, 2017 at 12:19 AM, Emilien Macchi 
>> wrote:
>> > On Wed, Jun 21, 2017 at 6:42 PM, Jeremy Stanley 
>> > wrote:
>> >> On 2017-06-21 09:03:47 -0400 (-0400), Emilien Macchi wrote:
>> >> [...]
>> >>> Can anyone have a look please?
>> >>> We would like to EOL Puppet OpenStack Mitaka.
>>
>> Hey it's me again :-)
>> If someone has little time to help me on this process, I would buy
>> him/her Canadian beers (some said they're better than US but I don't
>> want to get in trouble here) at next summit in Vancouver.
>>
>> Thanks,
>>
>> >> It's not forgotten, Infra's just spread thin and some weeks
>> >> (especially when lots of people go to conferences) it's about all we
>> >> can do to keep the lights on. For larger non-urgent requests like
>> >> this to be deprioritized and take more than a week to address is,
>> >> unfortunately, not atypical.
>> >>
>> >> Making matters worse, I'll be mostly (if not completely) away from
>> >> the computer for the next five days, so unless someone else gets to
>> >> it before then I can't really commit to it until I'm around again
>> >> either.
>> >
>> > Thanks for clarifying, and apologize, I didn't have the full context.
>> > It's really fine to wait, there is no hurry, I just wanted to make
>> > sure it would happen sometimes.
>> >
>> > Have a great time off and we'll see if someone can help on this task
>> > later, but again nothing urgent.
>> >
>> > Cheers,
>> >
>> >> --
>> >> Jeremy Stanley
>> >>
>> >> ___
>> >> OpenStack-Infra mailing list
>> >> OpenStack-Infra@lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>> >
>> >
>> >
>> > --
>> > Emilien Macchi
>>
>>
>>
>> --
>> Emilien Macchi
>>
>> ___
>> OpenStack-Infra mailing list
>> OpenStack-Infra@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>



-- 
Emilien Macchi

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [Openstack] [OpenStack] [nova] How can I release PCI device resources without delete instance?

2017-07-05 Thread Jay Pipes


On 07/05/2017 04:18 AM, Eddie Yen wrote:

Hi everyone,

I'm using OpenStack Mitaka (which deployed from Fuel 9.2) and doing GPU 
things.


I got a problem is I need to delete current instance which contains GPU 
to release device if I want assign GPU to another new instance temperately.


I'll got "No valid host was found" if I creating new instance contains 
GPU flavor without delete present instance, even the instance is shutdown.


Is there any way that I just shutdown the instance rather than delete it 
to release GPU device?


As Dinesh mentioned you *can* use shelve for this, but frankly, I think 
the shelve API leads to more problems than it solves (see his response 
about needing to delete the new instance before unshelving).


I'd recommend redesigning your application to be more cloud-native. In 
other words, separate operating system state from application state, use 
volumes for all persistent application state, and do not rely on a 
persistent IP address. [1]


Once you've done that, you can just treat your VMs like cattle and 
terminate them.


Best,
-jay

[1] Please note I did not use the word "container" in this description 
of cloud-native application.


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [nova][placement] Add API Sample tests for Placement APIs

2017-07-05 Thread Chris Dent



Thanks for providing a bit more information on your goals, that
helps shape my answers a bit more usefully. See within.

On Wed, 5 Jul 2017, Shewale, Bhagyashri wrote:


So I'd say the api is verified. What is missing, and could be useful, is using those 
tests to get accurate and up to date representations of the JSON request and response 
bodies. If that's something we'd like to pursue as I said in my other message the 
'verbose' functionality that can be provided in gabbi->>based tests should be 
able to help.


I have checked with the 'verbose' functionality, but that doesn't verify the 
entire response, it's simply prints header and response on console.


That's correct. My suggestion to use the 'verbose' functionality was
if your main goal was to create samples to be used in documentation:
a suite of gabbi tests can run which output those samples as needed,
wherever they need to go.


On the current master code, few of the gabbi tests verify the entire response 
and the remaining verify’s only specific attributes from the response.


This is mostly intentional. It doesn't make sense to me that we
would verify serialization code at the level of API tests.

The difference you see in the extent to which each tests validates a
response is the result of different people writing the tests.


So instead of verifying each and every key-value pair from the response object, 
it would nice if gabbit can add a support to
accept response.json file and during execution of the test, it can verify 
whether all key-value pairs response.json file are matching with the actual 
response.


While I disagree with doing this (it makes the tests more fragile,
requires more pieces to be changed when things are changed, and tests
the serialization code in the api tests, rather than the API[1]) the
functionality that you're describing can easily exist in gabbi so if
you and others decide that it is useful it can be done, either in
gabbi itself or in a custom content handler[2]. Is it your
intent to compare the abstract nestable object represented by the
JSON, or the string? If it's the latter there's existing code out
there that does that[3] but that's probably not a good choice as it
will break as soon as the format of the JSON changes for some
reason.

(I'm happy to write the code that does full object comparison if we
decide it's desirable or help land a pull request.)

[1] From https://gabbi.readthedocs.io/en/latest/jsonpath.html
This is not a technique that should be used frequently as it can
lead to difficult to read tests and it also indicates that your
gabbi tests are being used to test your serializers and data
models, not just your API interactions.

[2] https://gabbi.readthedocs.io/en/latest/handlers.html
And an example:

[3] 
https://github.com/hogarthww/gabbi-tools/blob/master/src/gabbi_tools/response_handlers.py

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

Re: [openstack-dev] [all][tc] Turning TC/UC workgroups into OpenStack SIGs

2017-07-05 Thread Blair Bethwaite

On 27 June 2017 at 23:47, Sean Dague  wrote:
> I still think I've missed, or not grasped, during this thread how a SIG
> functions differently than a WG, besides name. Both in theory and practice.

I think for the most part SIG is just a more fitting moniker for some
of these groups. E.g. I would say the scientific-wg is really a SIG,
typically with a few loose sub-WGs at any time, but the bulk of the
active membership is largely people doing similar jobs and
deploying/using OpenStack for similar things across science/academia -
so we basically have a lot of "shop" to talk about, and sometimes that
is only peripherally related to OpenStack.

-- 
Cheers,
~Blairo

__
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] [ironic][magnum][kolla][ansible][puppet][rally] removing SSH drivers from Ironic

2017-07-05 Thread Pavlo Shchelokovskyy

Hi all,

as mitaka branch was finally EOLed, Ironic team is going to proceed with
removal of SSH-based power and management drivers for virtualized HW which
were deprecated back in newton release.

Since newton the virtualbmc-based simulation of IPMI-capable HW is
officially supported, and we plan to switch all gates away from using *_ssh
drivers and eventually remove those from the ironic code, most probably in
Pike release.

I've skimmed through the project-config/zuul/layout.yaml and found a number
of projects that use some gate jobs with 'ironic' in the job name which are
not defined in project-config/jenkins/jobs/ironic.yaml, those project are
tagged in the subject of this message.

While kolla, magnum, OSA and rally seem to have only non-voting jobs with
ironic and thus should not be completely broken by removal of SSH drivers
anyway, puppet-ironic seems to have a voting
"puppet-openstack-integration-jobs-scenario002" job.

This message especially concerns deployment-specific projects that do not
install ironic via DevStack in their gate jobs. To successfully install a
working ironic which is capable to actually deploy nodes, such projects
will have to incorporate some additional steps to setup virtualbmc-based HW
simulation for baremetal nodes and configure nodes enrolled in ironic
accordingly.

If your project is mentioned, please ensure that any ironic-including gate
jobs you use do not setup ironic with *_ssh drivers, and switch to other
supported drivers if needed. Examples of necessary steps can be found in
ironic's DevStack plugin and in the playbooks of openstack/bifrost project.

For any questions please do not hesitate to contact ironic team, we'll be
glad to help you.

Best regards,
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.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

Re: [openstack-dev] [User-committee] [all][tc] Turning TC/UC workgroups into OpenStack SIGs

2017-07-05 Thread Blair Bethwaite

On 27 June 2017 at 23:47, Thierry Carrez  wrote:
> Setting up a common ML for common discussions (openstack-sigs) will
> really help, even if there will be some pain setting them up and getting
> the right readership to them :)

It's worth a try! I agree it will probably take a while, and I would
still expect cross-posting to be allowed without being jumped on for
some time until the list admins can see that membership has reached a
reasonable level - not sure how you'd define that though...

-- 
Cheers,
~Blairo

__
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] [OpenStack] [nova] How can I release PCI device resources without delete instance?

2017-07-05 Thread Bhor, Dinesh

Hi Eddie,

One way to do this is to “shelve” the instance which will allow to use your PCI 
device for other instance.
But you won’t be able to “unshelve” the previous instance until you delete or 
unshelve the newly created instance.

NOTE:
Shelving will release all the resources associated to that instance if the 
config option shelved_offload_time is not -1.

Thanks and Regards,
Dinesh Bhor | App. Software Dev. Cnslt.
dinesh.b...@nttdata.com | VOIP. 8833.8395I | 
nttdata.com/americas
NTT DATA, Inc.
Consulting | Digital | Managed Services | Industry Solutions
Learn more:
[Description: Description: 
cid:image005.jpg@01D193F0.F70B44C0]

[Description: Description: 
cid:image009.jpg@01D193F0.F70B44C0]

[Description: Description: 
cid:image010.jpg@01D193F0.F70B44C0]

[Description: Description: 
cid:image011.jpg@01D193F0.F70B44C0]



From: Eddie Yen [mailto:missile0...@gmail.com]
Sent: Wednesday, July 05, 2017 1:49 PM
To: openstack@lists.openstack.org
Subject: [Openstack] [OpenStack] [nova] How can I release PCI device resources 
without delete instance?

Hi everyone,

I'm using OpenStack Mitaka (which deployed from Fuel 9.2) and doing GPU things.

I got a problem is I need to delete current instance which contains GPU to 
release device if I want assign GPU to another new instance temperately.

I'll got "No valid host was found" if I creating new instance contains GPU 
flavor without delete present instance, even the instance is shutdown.

Is there any way that I just shutdown the instance rather than delete it to 
release GPU device?


Many thanks,
Eddie.

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [horizon] [horizon-plugin] Raising Django version cap

2017-07-05 Thread Rob Cresswell (rcresswe)

If you want to install Django 1.11 and test it, that would be very helpful, 
even if its just to open bugs. I’m in the process of adding a non-voting job 
for 1.11 right now, so we should be able to move quickly.

Rob

On 5 Jul 2017, at 01:36, Adrian Turjak 
> wrote:

Great work!

Is there anything that can be done to help meet that July deadline and get 
1.11.x in? I'm more than happy to help with reviews or even fixes for newer 
Django in Horizon, and we should try and get others involved if it will help as 
I think this is a little urgent.

Running anything less than Django 1.11 leaves us in a weird spot because of the 
point where support ends for any versions below it.

Looking at the release timelines, if we don't get 1.11 in for Pike, we'll have 
released a version of Horizon that will be for an unsupported version of Django 
in about 6 months time (8 if deployers stick with django 1.8):
https://releases.openstack.org/pike/schedule.html
https://www.djangoproject.com/download/

It isn't as bad it could be, but it's an awkward situation to be in. 1.9 is no 
longer supported, 1.10 support stops at 2018, so realistically 1.8 is the only 
version to have Pike 'safe' until Queens thats not particularly great either. 
Getting 1.11 support in would be ideal.


On 05/07/17 03:01, Rob Cresswell wrote:
Hi everyone,

I've put up a patch to global-requirements to raise the Django cap to "<1.11", 
with the upper-constraint at "1.10.7" 
(https://review.openstack.org/#/c/480215). Depending on the remaining time, I'd 
quite like to move us to "1.11.x" before Requirements Freeze, which will fall 
around the 27th of July.

Rob



__
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-Infra] Request to EOL Puppet OpenStack Mitaka

2017-07-05 Thread Joshua Hesketh

Hello Emilien,

My apologies for not getting to this sooner. I've processed the list that
Tony put together which included the puppet repos. Please let me know if
I've missed anything.

Cheers,
Josh

On Wed, Jul 5, 2017 at 6:19 AM, Emilien Macchi  wrote:

> On Fri, Jun 23, 2017 at 12:19 AM, Emilien Macchi 
> wrote:
> > On Wed, Jun 21, 2017 at 6:42 PM, Jeremy Stanley 
> wrote:
> >> On 2017-06-21 09:03:47 -0400 (-0400), Emilien Macchi wrote:
> >> [...]
> >>> Can anyone have a look please?
> >>> We would like to EOL Puppet OpenStack Mitaka.
>
> Hey it's me again :-)
> If someone has little time to help me on this process, I would buy
> him/her Canadian beers (some said they're better than US but I don't
> want to get in trouble here) at next summit in Vancouver.
>
> Thanks,
>
> >> It's not forgotten, Infra's just spread thin and some weeks
> >> (especially when lots of people go to conferences) it's about all we
> >> can do to keep the lights on. For larger non-urgent requests like
> >> this to be deprioritized and take more than a week to address is,
> >> unfortunately, not atypical.
> >>
> >> Making matters worse, I'll be mostly (if not completely) away from
> >> the computer for the next five days, so unless someone else gets to
> >> it before then I can't really commit to it until I'm around again
> >> either.
> >
> > Thanks for clarifying, and apologize, I didn't have the full context.
> > It's really fine to wait, there is no hurry, I just wanted to make
> > sure it would happen sometimes.
> >
> > Have a great time off and we'll see if someone can help on this task
> > later, but again nothing urgent.
> >
> > Cheers,
> >
> >> --
> >> Jeremy Stanley
> >>
> >> ___
> >> OpenStack-Infra mailing list
> >> OpenStack-Infra@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> >
> >
> >
> > --
> > Emilien Macchi
>
>
>
> --
> Emilien Macchi
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [all][stable][ptls] Tagging mitaka as EOL

2017-07-05 Thread Joshua Hesketh

Hi all,

Very sorry for the delay on processing this request. I have now EOL'd
stable/mitaka branches for projects listed in [1].

If there are any mistakes it should be possible to restore the branch at
the correct position. Similarly please let me know if there were any
projects that should have been EOL'd but missed out.

Cheers,
Josh

[1] https://gist.githubusercontent.com/tbreeds/c99e62bf8da19
380e4eb130be8783be7/raw/6d02deb40e07516ce8fc529d2ba8c74af11a
5a6b/mitaka_eol_data.txt

On Thu, Jun 29, 2017 at 10:57 PM, Jeremy Stanley  wrote:

> On 2017-06-29 11:28:10 +1000 (+1000), Tony Breeds wrote:
> [...]
> > In the meantime we could look at adding permissions such that the Stable
> > PTL (Well actually I guess eventually it'd be the same bot that does the
> > release tagging) can push tags and abandon changes on all projects.
> >
> > Right now stable-maint-core can do that in a lot of projects but the
> > coverage isn't complete.
>
> Sure, we just need to set it in the global configuration instead of
> on a per-project basis.
>
> > That would allow us to make forward progress and reduce the task for the
> > infra team to deleting the branches.  It does of course introduce a
> > race where I could tag a branch as EOL and then that project merge
> > another change.  Can you think of a way to avoid that?
>
> Not a convenient one anyway... we could probably merge (hundreds of)
> ACL changes preventing approvals on that branch for the projects
> participating in the EOL process, but that's probably worse than
> accepting that there might be a patch or two created, reviewed and
> landed on some project between the EOL tag and branch deletion. The
> additional changes that merge after the tag won't effectively be
> reachable once the branch is gone anyway (you could hunt them down
> in Gerrit, but there's no longer a branch in Git containing them an
> they're not in the history of any tag at that point). It's probably
> neither common nor disruptive enough to be worth our concern.
> --
> Jeremy Stanley
>
> __
> 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] [QA][Nova] Special scenario tests

2017-07-05 Thread Ferenc Horváth

On Thu, Apr 27, 2017 at 11:56 PM, Matt Riedemann  
wrote:

On 4/21/2017 8:36 AM, Ferenc Horváth wrote:

Dear OpenStackerz,

I'd like to improve the coverage of the current test suite over some
special code parts in Nova.
My main target is to add a few scenarios [1] that would exercise the
AggregateMultiTenancyIsolation scheduler filter.
I'm also planning on adding new test cases for other filters and for
some libvirt related features [2] as well.

Unfortunately, [1] and [2] could not be merged into Tempest for various
reasons, hence I started working on functional tests in Nova.
However, since functional tests cannot be used to verify that a deployed
system behaves correctly, we still need end to end tests.
Therefore, I'm proposing a new Tempest test plug-in [3,4] that would be
the home of currently out of tree tests.
The idea is that these tests would run separately on a weekly basis to
not use too much resources, but the rest of the questions are still open.

Therefore, I'd appreciate any advice or review on this topic.

Thank You all in advance.

Best regards,
Ferenc Horváth

[1]https://review.openstack.org/#/c/374887/
[2]https://review.openstack.org/#/c/315786/
[3]https://review.openstack.org/#/c/448482/
[4]https://review.openstack.org/#/c/451227/



__

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

As discussed in the nova meeting today [1] I think some of this could
make sense as a Tempest plugin, or an in-tree functional test using
fixtures, or an in-tree dsvm integration style job that's not Tempest
but runs real tests against a live devstack configuration.

For the scheduler filter testing, I think that's something that is
totally doable with the in-tree functional tests using our fixtures.
You
don't need devstack for that since it's just testing the logic of the
scheduler filters. We have running services, database, and a live API
in
those tests, and external services like cinder/glance/neutron are
stubbed out. An example of a test like this is here [2]. I understand
you have some internal requirements for how these tests are performed
though, so I can't really help you there. Keep in mind if you do it
with
an in-tree functional test, it gets tested on every change and is
voting, whereas a periodic job is not and you only find out it's
broken
after we break it.

I think the best of both words would be to set up a 3pp CI to run the
extra tempest tests. This way the upstream CI doesn't have to spend
extra resources to run the tests but we could have e2e test coverage.
At the moment I don't think this will be realized in the near future.

So as a compromise we will provide filter tests in nova functional test
environment. I think hferenc already started adding such coverage.

You are correct, I added a scheduler filter test [1] to Nova's
functional test suite some time ago. It is ready for core review.
I'd appreciate any comments.



For testing the libvirt watchdog action we obviously need a real
deployment with running libvirt. I think you could do that as a
tempest
plugin or as an in-tree dsvm integration job, much like how the
novaclient functional tests work (those aren't tempest but they run
against a live devstack and execute real APIs via the nova CLI). The
downside is we don't have any dsvm-integration infrastructure setup in
Nova today, so you'd have to blaze that trail. But we've talked about
this as a need for a long time, so it'd be great if someone worked on
it. Alternatively it could be an in-tree Tempest plugin...but then we
can't test things like the libvirt image cache which is something we
could do with a dsvm-integration job I think, or the evacuate API
(we'd
have to run that in serial so it doesn't break other concurrently
running tests). Actually testing evacuate would be awesome though.

I think dsvm-integration-libvirt is a nice idea so we will look the
novaclient env to learn how that works and we will try to implement
something similar in nova tree.

I looked at how novaclient's functional test suite works.
As far as I understand there is a functional environment in tox
in which all the test cases are executed in a common dsvm job.
Obviously, the test cases are using the CLI to communicate
with devstack.

My current idea is that we could break down the problem to
at least three work items. So, from a (very) high-level view, we
will need the following things to implement the aforementioned
nova-integration environment:
1. A new tox environment, which will run test from a directory
(which might be /nova/tests/functional/integration for example).
2. A new dsvm job, which will execute only the new integration
environment.
3. Some way to communicate with devstack. In case of tempest
or novaclient this layer is already implemented,

[Openstack] [OpenStack] [nova] How can I release PCI device resources without delete instance?

2017-07-05 Thread Eddie Yen

Hi everyone,

I'm using OpenStack Mitaka (which deployed from Fuel 9.2) and doing GPU
things.

I got a problem is I need to delete current instance which contains GPU to
release device if I want assign GPU to another new instance temperately.

I'll got "No valid host was found" if I creating new instance contains GPU
flavor without delete present instance, even the instance is shutdown.

Is there any way that I just shutdown the instance rather than delete it to
release GPU device?


Many thanks,
Eddie.
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [kuryr] Nominate Kirill Zaitsev as kuryr-tempest-core reviewer

2017-07-05 Thread Liping Mao (limao)

+1

发件人: Irena Berezovsky 
答复: OpenStack List 
日期: 2017年7月5日 星期三 12:52
至: OpenStack List 
主题: Re: [openstack-dev] [kuryr] Nominate Kirill Zaitsev as kuryr-tempest-core 
reviewer

+1

On Wed, Jul 5, 2017 at 4:23 AM, Vikas Choudhary 
> wrote:
+1

On Tue, Jul 4, 2017 at 7:59 PM, Antoni Segura Puimedon 
> wrote:
On Tue, Jul 4, 2017 at 12:23 PM, Gal Sagie 
> wrote:
> +1
+1
>
> On Tue, Jul 4, 2017 at 12:28 PM, Daniel Mellado 
> >
> wrote:
>>
>> Hi Team,
>>
>> I wanted to nominate Kirill for kuryr-tempest-core reviewer. He's been a
>> great help from start both contributing and reviewing.
>>
>> Please voice your support or concerns if any
>>
>> Best!
>>
>> Daniel
>>
>> __
>> 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
>
>
>
>
> --
> Best Regards ,
>
> The G.
>
> __
> 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] [ceilometer]Understandig ceilometer

2017-07-05 Thread Gyorgy Szombathelyi

Hi Gordon,

Thanks for the explanations!

Br,
György

> -Original Message-
> From: gordon chung [mailto:g...@live.ca]
> Sent: 2017 július 4, kedd 23:58
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [ceilometer]Understandig ceilometer
> 
> 
> 
> On 04/07/17 05:14 AM, Gyorgy Szombathelyi wrote:
> > - I understand that there is no collector service now. I know the old 
> > pipeline
> was: compute-agent->notification-agent->collector->storage(gnocchi).
> > Now I assumed it should be compute-agent->storage(gnocchi).
> > However I found out it is a bit different: compute-agent->notification-
> agent->storage. Is it the intended behavior or just a configuration error on
> my side?
> >
> 
> there is no storage service now. ceilometer is just collection.
> 
> compute-agent->notification-agent->gnocchi is correct. there is no way
> to publish directly from polling agents to storage currently (not without
> hacking). i'm personally not against having polling agent push to gnocchi
> directory but it's just not there currently.
> 
> > - I found no gnocchi at the publishers, but it is still there at the
> > dispatchers. How is it used as a publisher? Just with some magic
> transformation, publishers: -gnocchi:// is translated into using the direct
> publisher?
> >
> 
> we haven't ported over gnocchi to publisher. it's still a dispatcher with a
> publisher alias. there is a work item for this and it's pretty simple, we just
> didn't do it (yet). i would think it will be done in Pike since we ideally 
> want to
> remove all dispatchers in Queen.
> 
> 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
__
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] Live Migration and LibVirt CPU Mode

2017-07-05 Thread Van Leeuwen, Robert

> The instance can also be migrated between 2 Westmere hosts.
> As I outline in another email, I suspect (perhaps incorrectly) as the VM has 
> "cpu mode='host-model'" in its running config, 
> libvirt may be comparing source and destination host CPUs and not guest and 
> destination CPUs.
 
Indeed it very much seems like it will look at the host cpu-model and not the 
guest since it is complaining about Broadwell CPU features.
The libvirt documentation also sort of suggests this is the case:
https://libvirt.org/formatdomain.html#elementsCPU
“Prior to libvirt 3.2.0 and QEMU 2.9.0 detection of the host CPU model via QEMU 
is not supported. Thus the CPU configuration created using host-model may not 
work as expected.”

You can have a look cheating your way around it.
There is some code which removes the checks which you might be able to (ab)use:
https://bugs.launchpad.net/nova/+bug/1588003

You might want to double-check if a (hard)-rebooted migrated (with the 
host-model config) instances on the Broadwell compute node does not get a 
Broadwell cpu before modifying this ;)

Cheers,
Robert van Leeuwen

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [docs][all][ptl] doc-migration status

2017-07-05 Thread Andreas Jaeger


For those projects using an Install Guide: Since it will be moved into
your normal doc tree, you cannot merge that change without disabling the
install-guide jobs.

I did this now for *all* projects with the following change to allow you
moving forward:

https://review.openstack.org/480375

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

Re: [Openstack] upgrade openstack

2017-07-05 Thread Markus Zoeller

On 04.07.2017 17:13, rag.open@openmailbox.org wrote:
> Hi, I have a doubt regarding the upgrade of openstack, it is possible to 
> upgrade from an old version or an updated one without going through the 
> intermediate versions.
> Example: kilo to newton
> Or it must be incremental kilo, liberty, mitaka, newton.
> 
> In my experience I always did them incrementally, but I wanted to know 
> if someone performed the process directly A-> D instead of A-B-C-> D.
> Thanks.
> 
> 
> 
> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 

AFAIK you still have to update from major version to major version. With
your example, this means: kilo -> liberty -> mitaka -> newton

For the sake of completeness, "Ocata" is the latest stable release (Feb.
2017) and "Pike" will be the next release (Aug. 2017):
https://releases.openstack.org/

The main reasons for this incremental update (IIUC):
* database schema updates (and sometimes data migration)
* deprecation/renaming of config options

For the config options I'd like to point you to the (little known)
tables of "New, updated, and deprecated config options":

* Nova - Kilo:

https://docs.openstack.org/kilo/config-reference/content/nova-conf-changes-kilo.html
* Nova - Liberty:

https://docs.openstack.org/liberty/config-reference/content/nova-conf-changes-liberty.html
* Nova - Mitaka: (note the change in the URLs 'style')

https://docs.openstack.org/mitaka/config-reference/tables/conf-changes/nova.html
* Nova - Newton:

https://docs.openstack.org/newton/config-reference/tables/conf-changes/nova.html
* Nova - Ocata:

https://docs.openstack.org/ocata/config-reference/tables/conf-changes/nova.html
* and so forth for the other projects ...


-- 
Regards, Markus Zoeller (markus_z)


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [nova][placement] Add API Sample tests for Placement APIs

2017-07-05 Thread Shewale, Bhagyashri

>>So I'd say the api is verified. What is missing, and could be useful, is 
>>using those tests to get accurate and up to date representations of the JSON 
>>request and response bodies. If that's something we'd like to pursue as I 
>>said in my other message the 'verbose' functionality that can be provided in 
>>gabbi->>based tests should be able to help.

I have checked with the 'verbose' functionality, but that doesn't verify the 
entire response, it's simply prints header and response on console.

On the current master code, few of the gabbi tests verify the entire response 
and the remaining verify’s only specific attributes from the response.

For example:

1. The test "update a resource provider" which is under 
"nova/tests/functional/api/openstack/placement/gabbits/resource-provider.yaml" 
does not check all the key-value pairs of "links" attribute, it only checks the 
"links[?rel = "self"].href".

Response return after update
{
  "links": [
{
  "href": "/resource_providers/8e8b14f1-1360-4b61-8ff0-aeefc73a1808",
  "rel": "self"
},
{
  "href": 
"/resource_providers/8e8b14f1-1360-4b61-8ff0-aeefc73a1808/inventories",
  "rel": "inventories"
},
{
  "href": "/resource_providers/8e8b14f1-1360-4b61-8ff0-aeefc73a1808/usages",
  "rel": "usages"
}
  ],
  "generation": 0,
  "uuid": "8e8b14f1-1360-4b61-8ff0-aeefc73a1808",
  "name": "new name"
}

2. The test "list one resource providers" under 
nova/tests/functional/api/openstack/placement/gabbits/resource-provider.yaml 
checks all the key-value pairs of response object.

Response return in case of list one resource providers

{
  "resource_providers": [
{
  "links": [
{
  "href": "/resource_providers/958f0cb7-8fa2-4521-95df-e4cff1cc0d07",
  "rel": "self"
},
{
  "href": 
"/resource_providers/958f0cb7-8fa2-4521-95df-e4cff1cc0d07/inventories",
  "rel": "inventories"
},
{
  "href": 
"/resource_providers/958f0cb7-8fa2-4521-95df-e4cff1cc0d07/usages",
  "rel": "usages"
}
  ],
  "name": "0e6980e1-501a-468c-9d9a-bce6caecffb3",
  "generation": 0,
  "uuid": "958f0cb7-8fa2-4521-95df-e4cff1cc0d07"
}
  ]
}

So instead of verifying each and every key-value pair from the response object, 
it would nice if gabbit can add a support to
accept response.json file and during execution of the test, it can verify 
whether all key-value pairs response.json file are matching with the actual 
response.

In the current master code, for a specific micro-version, if nova is returning 
extra parameters, then the gabbit test won't fail because it is only validating 
required attributes from the response.
I think, this issue can be handled once we do strict validation of actual 
response with the response.json.

Please let me know your thoughts of adding support in gabbi project to accept 
response.json file for each test.

Regards,
Bhagyashri Shewale

-Original Message-
From: Chris Dent [mailto:cdent...@anticdent.org] 
Sent: Friday, June 23, 2017 5:35 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][placement] Add API Sample tests for 
Placement APIs

On Thu, 22 Jun 2017, Shewale, Bhagyashri wrote:

>>> * who or what needs to consume these JSON samples?
> The users of placement API can rely on the request/response for different 
> supported placement versions based on some tests running on the OpenStack CI 
> infrastructure.
> Right now, most of the placement APIs are well documented and others are in 
> progress but there are no tests to verify these APIs.

Either we are misunderstanding each other, or you're not aware of what the 
gabbi tests are doing. They verify the placement API and provide extensive 
coverage of the entire placement HTTP framework, including the accuracy of 
response codes in edge cases not on the "happy path". Coverage is well over 90% 
for the group of files in nova/api/openstack/placement (except for the wsgi 
deployment script
itself) when the
nova/tests/functional/api/openstack/placement/test_placement_api.py
functionl tests runs all the gabbi files in 
nova/tests/functional/api/openstack/placement/gabbits/.

So I'd say the api is verified. What is missing, and could be useful, is using 
those tests to get accurate and up to date representations of the JSON request 
and response bodies. If that's something we'd like to pursue as I said in my 
other message the 'verbose' functionality that can be provided in gabbi-based 
tests should be able to help.

> We would like to write new functional test to consume these json samples to 
> verify each placement API for all supported versions.

Those gabbi files also test functionality at micorversion boundaries.

-- 
Chris Dent  ┬──┬◡ﾉ(° -°ﾉ)   https://anticdent.org/
freenode: cdent tw: @anticdent

Re: [openstack-dev] [mistral] External GUI for Mistral is now at github

2017-07-05 Thread Renat Akhmerov

Lingxian, good idea. Most likely, we’ll record it and share publicly.

Thanks

Renat Akhmerov
@Nokia

On 4 Jul 2017, 19:21 +0700, Lingxian Kong , wrote:
> That's awesome! It'd be better if there is a demo for introduction :-)
>
>
> Cheers,
> Lingxian Kong (Larry)
>
> > On Tue, Jul 4, 2017 at 9:48 PM, Shaanan, Guy (Nokia - IL/Kfar Sava) 
> >  wrote:
> > > Hi all,
> > >
> > > We are happy to announce “CloudFlow”- a Mistral Workflow Execution 
> > > Visualization tool, to help you debug and monitor in real time the 
> > > progress of executions.
> > >
> > > CloudFlow offers web based GUI and relies on Mistral REST API.
> > >
> > > CloudFlow source code is publicly available on github[1].
> > >
> > > With this move we can now leverage the project management options in 
> > > Github, like:
> > > * Projects[2] - managing the backlog, todos and in-progress tasks.
> > > * Issues[3] - for opening bugs and feature requests.
> > >
> > > Contributions should be made via a PR and code review, after an 
> > > appropriate task has been added to Projects or a bug has been opened.
> > >
> > > Currently the building and publishing of new versions is done manually 
> > > and will be automated in the future.
> > >
> > >
> > > [1] https://github.com/nokia/CloudFlow
> > > [2] https://github.com/nokia/CloudFlow/projects/1
> > > [3] https://github.com/nokia/CloudFlow/issues
> > >
> > > Thanks,
> > >
> > > -
> > > Guy Shaanan
> > > CI & Internal Tools
> > > Application & Analytics, Nokia
> > > 16 Atir Yeda St. Kfar-Saba 44643, ISRAEL
> > > T: +972 9 793 3013
> > > M: +972 52 536 2986
> > > guy.shaa...@nokia.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 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

61 matches

Mail list logo