Re: [openstack-dev] Kingbird UX for Horizon

[Goutham Pratapa]

Hi Beth,

It's perfectly fine Kingbird is for multi-region cloud environments.
https://wiki.openstack.org/wiki/Kingbird

and coming to the horizon thanks for the suggestions I will definitely post
questions in Openstack-horizon and get my doubts or issues solved in-case
of any.

Thanks
Goutham Pratapa.

On Fri, Sep 15, 2017 at 9:51 AM, Beth Elwell 
wrote:

> Hi Goutham,
>
> I apologise I have not come across Kingbird before but will be interested
> to find out more about it!
>
> To me the UX looks good but I don’t have enough exposure to what Kingbird
> is to know if it represents what you will need from a UI. Horizon has lots
> of templates and examples of how to build modals and buttons etc as per
> your current mocks so please do look at current examples and ask in
> #openstack-horizon if you need any help or advise at all. That will save
> you work and ensure the UI is consistent and we don’t have lots of
> duplicate code and ways of making the same sort of things that could prove
> to be confusing for future developers. As I say though, you are always
> welcome in channel and there will always be someone around to help you out
> and point you in the right direction.
>
> Hope that helps!
> Beth
>
>
> On 14 Sep 2017, at 00:24, Goutham Pratapa 
> wrote:
>
> HI all,
>
> Attached are the expected UX screens for Kingbird's horizon please feel
> free to provide feedback on this.
>
>
> P.S: *Images are drawn using paint and we will follow all the OpenStack
> Horizon standards when we develop*
>
> --
> Cheers !!!
> Goutham Pratapa
> ___
> ___
> 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
>
>


-- 
Cheers !!!
Goutham Pratapa
__
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] Kingbird UX for Horizon

[Beth Elwell]

Hi Goutham,

I apologise I have not come across Kingbird before but will be interested to 
find out more about it!

To me the UX looks good but I don’t have enough exposure to what Kingbird is to 
know if it represents what you will need from a UI. Horizon has lots of 
templates and examples of how to build modals and buttons etc as per your 
current mocks so please do look at current examples and ask in 
#openstack-horizon if you need any help or advise at all. That will save you 
work and ensure the UI is consistent and we don’t have lots of duplicate code 
and ways of making the same sort of things that could prove to be confusing for 
future developers. As I say though, you are always welcome in channel and there 
will always be someone around to help you out and point you in the right 
direction.

Hope that helps!
Beth


> On 14 Sep 2017, at 00:24, Goutham Pratapa  wrote:
> 
> HI all,
> 
> Attached are the expected UX screens for Kingbird's horizon please feel free 
> to provide feedback on this.
> 
> 
> P.S: Images are drawn using paint and we will follow all the OpenStack 
> Horizon standards when we develop
> 
> -- 
> Cheers !!!
> Goutham Pratapa
> __
> 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] 答复: Re: [senlin] Meeting for Queens Goal

[liu.xuefeng1]

Me too. I'll attend both if time permits.







原始邮件



发件人： 
收件人： 
日 期 ：2017年09月15日 08:43
主 题 ：Re: [openstack-dev] [senlin] Meeting for Queens Goal





I'll attend both if time permits.

- Qiming
On Thu, Sep 14, 2017 at 06:58:38PM +0800, YUAN RUIJIE wrote:
> Hi Senlin Core Team,
> 
> We are going to have a meetup to discuss the goal & features we want to
> implement in Queens cycle. As we discussed during the latest weekly
> meeting, we have the follow options:
> 
> 1. Have a virtual meeting by some meeting softwares
> 2. Organize a Meetup in middle Oct, since the National Day is coming.
> 
> Suggestions are welcomed,
> 
> Sincerely,
> ruijie

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


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

[openstack-dev] [mogan] python-moganclient 0.1.0 released

[Zhenguo Niu]

hi all,

python-moganclient 0.1.0 released.

Tarball: http://tarballs.openstack.org/python-moganclient/
PYPI: https://pypi.python.org/pypi/python-moganclient/

-- 
Best Regards,
Zhenguo Niu
__
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] 答复: Re: [senlin] How to delete cluster in the state of'DELEING'

[Qiming Teng]

Vote for '--force'. Status update operation smells an overkill in this
case.

- Qiming
On Wed, Sep 13, 2017 at 01:37:44PM +0800, Lee Yi wrote:
> --force will be better, in my opinion.
> 
> On Wed, Sep 13, 2017 at 1:23 PM,  wrote:
> 
> > You killed mysql? Okay ...
> >
> > Seems we need to add a "--force" parameter to the delete operation.
> >
> > - Qiming
> >
> > On Tue, Sep 12, 2017 at 09:14:25PM +0800, Lee Yi wrote:
> > > When deleting a cluster named 'server_cluster', I
> > shutdown mysql service.
> > > And then the status of cluster will be 'DELETING' forever, like follow:
> > >
> > > {0}nbsp;openstack cluster list
> > > +--++--+
> > > --+--+
> > > | id   | name   | status   | created_at
> > | updated_at
> > >   |
> > > +--++--+
> > > --+--+
> > > | 672d043f | server_cluster | DELETING | 2017-09-12T10:52:16Z |
> > > 2017-09-12T11:16:15Z |
> > > +--++--+
> > > --+--+
> > >
> > > I can't  delete it again, because:
> > >
> > > {0}nbsp;openstack cluster delete server_cluster
> > > Are you sure you want to delete this cluster(s) [y/N]?y
> > >  server_cluster: failed due to 'HttpException: The
> > cluster 'server_cluster'
> > > is in status DELETING. (HTTP 409) (Request-ID:
> > > req-42eeda10-9055-40c2-b690-5627ac555922),
> > > The cluster 'server_cluster' is in status DELETING.'
> > >
> > > And the action is in WAITING status:
> > >
> > > {0}nbsp;openstack cluster action show d36fc6b5-ac5e-
> > 460e-85dc-afdb680f3242
> >
> > > +---+--+
> > > | Field | Value|
> > > +---+--+
> > > | action| CLUSTER_DELETE   |
> > > | cause | RPC Request  |
> > > | created_at| 2017-09-12T11:16:15Z |
> > > | depended_by   |  |
> > > | depends_on| d0f6e1c0-491f-4318-9cc2-41ae2028b99f |
> > > | domain_id | None |
> > > | end_at| None |
> > > | id| d36fc6b5-ac5e-460e-85dc-afdb680f3242 |
> > > | inputs| {}   |
> > > | interval  | -1   |
> > > | location  | None |
> > > | name  | cluster_delete_672d043f  |
> > > | outputs   | {}   |
> > > | owner_id  | 9dd42d67-f0c6-4199-8c4f-15f3cd88683b |
> > > | project_id| 3adeed30eb694bdd98257b294120e595 |
> > > | start_at  | 1505214976.0 |
> > > | status| WAITING  |
> > > | status_reason | Waiting for depended actions.|
> > > | target_id | 672d043f-ef7b-4a7a-a41a-176a9929296e |
> > > | timeout   | 3600 |
> > > | updated_at| None |
> > > | user_id   | 4b805d08ec1644ef8f69078ddd59941c |
> > > +---+--+
> > >
> > > What can I do about this cluster, and how to delete it again.
> > >
> > > Obviously, I can modify the code (
> > > https://github.com/openstack/senlin/blob/master/
> > senlin/engine/service.py#L878-L881)
> > > to support to delete the cluster again, but I don't
> > think it's the best way.
> > >
> > > The same problems exist  when do other actions.
> > >
> > > Any suggestion?
> >
> > > __
> > 


__
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] [Zun] Propose change of the core team

[Qiming Teng]

+1 on both.

On Thu, Sep 14, 2017 at 01:58:48PM +, Hongbin Lu wrote:
> Hi all,
> 
> I propose the following change of the Zun core reviewer team.
> 
> + Kien Nguyen (kiennt2609)
> - Aditi Sharma (adi-sky17)
> 
> Kien has been contributing to the Zun project for a few months. His 
> contributions include proposing high-quality codes, providing helpful code 
> reviews, participating team discussion at weekly team meeting and IRC, etc. 
> He is the one who setup the multi-node job in the CI and the job is up and 
> running now. I think his contribution is significant which qualifies him to 
> be a core reviewer. Aditi is a member of the initial core team but becomes 
> inactive for a while.
> 
> Core reviewers, please cast your vote on this proposal.
> 
> Best regards,
> Hongbin


__
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] [senlin] Meeting for Queens Goal

[Qiming Teng]

I'll attend both if time permits.

- Qiming
On Thu, Sep 14, 2017 at 06:58:38PM +0800, YUAN RUIJIE wrote:
> Hi Senlin Core Team,
> 
> We are going to have a meetup to discuss the goal & features we want to
> implement in Queens cycle. As we discussed during the latest weekly
> meeting, we have the follow options:
> 
> 1. Have a virtual meeting by some meeting softwares
> 2. Organize a Meetup in middle Oct, since the National Day is coming.
> 
> Suggestions are welcomed,
> 
> Sincerely,
> ruijie

> __
> 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] [oslo][barbican][sahara] start RPC service before launcher wait?

[Adam Spiers]

Hi Ken,

Thanks a lot for the analysis, and sorry for the slow reply!
Comments inline...

Ken Giusti  wrote:
> Hi Adam,
> 
> I think there's a couple of problems here.
> 
> Regardless of worker count, the service.wait() is called before
> service.start().  And from looking at the oslo.service code, the 'wait()'
> method is call after start(), then again after stop().  This doesn't match
> up with the intended use of oslo.messaging.server.wait(), which should only
> be called after .stop().

Hmm, so are you saying that there might be a bug in oslo.service's
usage of oslo.messaging, and that this Sahara bugfix was the wrong
approach too?

https://review.openstack.org/#/c/280741/1/sahara/cli/sahara_engine.py

> Perhaps a bigger issue is that in the multi threaded case all threads
> appear to be calling start, wait, and stop on the same instance of the
> service (oslo.messaging rpc server).  At least that's what I'm seeing in my
> muchly reduced test code:
> 
> https://paste.fedoraproject.org/paste/-73zskccaQvpSVwRJD11cA
> 
> The log trace shows multiple calls to start, wait, stop via different
> threads to the same TaskServer instance:
> 
> https://paste.fedoraproject.org/paste/dyPq~lr26sQZtMzHn5w~Vg
> 
> Is that expected?

Unfortunately in the interim, your pastes seem to have vanished - any
chance you could repaste them?

Thanks,
Adam

> On Mon, Jul 31, 2017 at 9:32 PM, Adam Spiers  wrote:
> > Ken Giusti  wrote:
> >> On Mon, Jul 31, 2017 at 10:01 AM, Adam Spiers  wrote:
> >>> I recently discovered a bug where barbican-worker would hang on
> >>> shutdown if queue.asynchronous_workers was changed from 1 to 2:
> >>>
> >>>https://bugs.launchpad.net/barbican/+bug/1705543
> >>>
> >>> resulting in a warning like this:
> >>>
> >>>WARNING oslo_messaging.server [-] Possible hang: stop is waiting for
> >>> start to complete
> >>>
> >>> I found a similar bug in Sahara:
> >>>
> >>>https://bugs.launchpad.net/sahara/+bug/1546119
> >>>
> >>> where the fix was to call start() on the RPC service before making the
> >>> launcher wait() on it, so I ported the fix to Barbican, and it seems
> >>> to work fine:
> >>>
> >>>https://review.openstack.org/#/c/485755
> >>>
> >>> I noticed that both projects use ProcessLauncher; barbican uses
> >>> oslo_service.service.launch() which has:
> >>>
> >>>if workers is None or workers == 1:
> >>>launcher = ServiceLauncher(conf, restart_method=restart_method)
> >>>else:
> >>>launcher = ProcessLauncher(conf, restart_method=restart_method)
> >>>
> >>> However, I'm not an expert in oslo.service or oslo.messaging, and one
> >>> of Barbican's core reviewers (thanks Kaitlin!) noted that not many
> >>> other projects start the task before calling wait() on the launcher,
> >>> so I thought I'd check here whether that is the correct fix, or
> >>> whether there's something else odd going on.
> >>>
> >>> Any oslo gurus able to shed light on this?
> >>>
> >>
> >> As far as an oslo.messaging server is concerned, the order of operations
> >> is:
> >>
> >> server.start()
> >> # do stuff until ready to stop the server...
> >> server.stop()
> >> server.wait()
> >>
> >> The final wait blocks until all requests that are in progress when stop()
> >> is called finish and cleanup.
> >
> > Thanks - that makes sense.  So the question is, why would
> > barbican-worker only hang on shutdown when there are multiple workers?
> > Maybe the real bug is somewhere in oslo_service.service.ProcessLauncher
> > and it's not calling start() correctly?

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

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Wan-yen Hsu]

>>* Nisha is raising the question about whether or not we're making
*>>* incorrect assumptions about how people are using nova/ironic and they
*>>* want to use the non-Exact filters for VCPU/MEMORY_MB/DISK_GB, which as
*>>* far as I have ever heard is not recommended/supported upstream as it can
*>>* lead to resource tracking issues in Nova that eventually lead to
*>>* scheduling failures later because of the scheduler thinking a node is
*>>* available for more than one instance when it's really not.
*
>This came up in the Nova PTG room yesterday and I wanted to reply on the
>thread with what I understood about it, for those who weren't in the
>session. In general, it's recommended to use the exact filters (1 flavor
>per Ironic node hardware config) as there's no concept of partially
>claiming a baremetal node.

>But, with the old non-exact filters, you _could_ get away with creating
>fewer flavors than you have hardware configs and get "fuzzy matching" on
>Ironic nodes, to get nodes whose configs are "close enough" but not
>exact. This might be helpful in situations where you have some oddball
>configs you don't want to have separate flavors for.
>I was thinking, if it's possible to assign more than one resource class
>to an Ironic node, maybe you could get similar behavior to the old
>non-exact filters. So if you have an oddball config, you could tag it as
>multiple resource classes that it's "close enough" to for a match. But
>I'm not sure whether it's possible for an Ironic node to be tagged with
>more than one resource class.


>* Nisha is raising the question about whether or not we're making
*>* incorrect assumptions about how people are using nova/ironic and they
*>* want to use the non-Exact filters for VCPU/MEMORY_MB/DISK_GB, which as
*>* far as I have ever heard is not recommended/supported upstream as it can
*>* lead to resource tracking issues in Nova that eventually lead to
*>* scheduling failures later because of the scheduler thinking a node is
*>* available for more than one instance when it's really not.
*
 The concern I have with one single custom resource class for an
Ironic node is that it takes away some of the options that were
available before, such as scheduling based on resource quantity and
non-exact match filters (RamFilter, DiskFilter, and CoreFilter).  Nova
scheduling becomes too restrictive for Ironic.

  I know some users are using these options before Pike with no
issues.   Therefore, it's a mystery to me whether the non-exact filter
for Ironic really has issues.  Even if it has problems, it seems to me
there are ways to address the problem. For instance, Ironic virt
driver can report a node is not available if it's in active state (if
it hasn't done so), or report all resources are consumed when a node
is claimed.   Alternatively, Nova scheduler can report all resources
are consumed for an Ironic node if Nova is willing to make such
change.  Thanks!



On Thu, Sep 7, 2017 at 12:48 PM, Nisha Agarwal 
wrote:

> Hi Ironic Operators,
>
> From Pike, ironic nodes get scheduled based on just the resource class
> from nova. Do you guys see any concerns over this "rigid resource class
> only ironic scheduling"?
>
> To be more specific, at your datacentre/production environment what all
> filters are configured in nova.conf (configuration file for nova) for
> scheduling an ironic node? Do you use RamFilter/DiskFilter/CoreFilter in
> the "use_baremetal_filters" for ironic nodes scheduling from nova?
>
> Thanks and Regards
> Nisha
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
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][ptg] QA Team social evening

[Andrea Frittoli]

Hello,

the plan for tonight is to meet at 6:15 in the lobby.
>From there we can take uber to the Art museum downtown
I didn't book a place, we I didn't book a place - we can walk around and
find a place for drinks & food.

See you later!

andrea

On Mon, Sep 11, 2017 at 1:17 PM Andrea Frittoli 
wrote:

> The best days according to the doodle are Wed or Thu,
> Since Wed there's an official PTG evening event, I'll book a place for
> Thursday.
>
> andrea
>
> On Wed, Aug 30, 2017 at 3:29 PM Andrea Frittoli 
> wrote:
>
>> Hello,
>>
>>
>> I'd like to propose a social evening for the folks who will attend QA
>> sessions at the PTG in Denver.
>>
>> I prepared a doodle [0] so if you're interested please vote :)
>>
>>
>> I added the link to the main QA etherpad [1] as well.
>>
>> If you know a good place to go for food or drinks please add it to the
>> etherpad as well.
>>
>>
>> Andrea
>>
>>
>> [0] https://doodle.com/poll/84mwxxbrtsmsaw4x
>>
>> [1] https://etherpad.openstack.org/p/qa-queens-ptg
>> 
>>
>>
__
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] Should we be using subprocess32?

[Tony Breeds]

On Tue, Sep 12, 2017 at 11:29:22AM -0700, Joshua Harlow wrote:
> Hi folks,
> 
> I know there is a bunch of usage of subprocess in openstack and especially
> since there is heavy usage of python 2.7 it made me wonder if we should try
> to move to subprocess32 to avoid some of the bugs that seem to exist (maybe
> distributors backported them?):
> 
> For example a major one (seems to be):
> 
> - https://github.com/google/python-subprocess32/commit/6ef1fea55
> 
> """Popen.wait() is now thread safe so that multiple
> 
>   threads may be calling wait() or poll() on a Popen instance at the same
> time
>   without losing the Popen.returncode value.
> """
> 
> That one concerns me slightly, because I know that certain openstack
> projects do use threads (and not eventlet monkey-patched green-thread
> hybrids).
> 
> TLDR; should we (could we?) switch?

We could.  It wouldn't be hard to propose a change to the requirements
repo and that could be used to test what breaks.

As to should we I'm not convinced.  It does give us a slightly more
modern subprocess module but it hasn't been updated in nearly 2 years.
I get that it's a backport from 3.3 which isn't getting updated but ...

Also it means adding something like:
if os.name == 'posix' and sys.version_info[0] < 3:
import subprocess32 as subprocess
else:
import subprocess

All over the place which isn't so great.

So overall I'm not certain it's worth it.

Yours Tony.


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

[openstack-dev] [acceleration]Cyborg Denver PTG Quick Recap

[Zhipeng Huang]

Hi Team,

We had a really productive week at Denver, and here's a brief summary I
wrote. Please feel free to chime in if any details got wrong.

Please refer to the "Notes" section at
https://etherpad.openstack.org/p/cyborg-queens-ptg . Keep up the good work
and let's start for Queens.

-- 
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] [all][deployment][kolla][tripleo][osa] Service diagnostics task force

[Vikram Hosakote (vhosakot)]

Beautiful goal!

I want to do this ☺

Regards,
Vikram Hosakote
IRC:  vhosakot

From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, September 13, 2017 at 5:45 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [all][deployment][kolla][tripleo][osa] Service 
diagnostics task force

Hello my dearest of communities,

During deployment tools session on PTG we discussed need for deep
health checking and metering of running services. It's very relevant
in context of containers (especially k8s) and HA. Things like
watchdog, heartbeats or exposing relative metrics (I don't want to get
into design here, suffice to say it's non-trivial problem to solve).

We would like to start a "task force", few volunteers from both
deployment tool side (ops, ha) and project dev teams. We would like to
design together a proper health check mechanism for one of projects to
create best practices and design, that later could be implemented in
all other services.

We would to ask for volunteer project team to join us and spearhead this effort.

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

__
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] Denver Team Dinner

[Sukhdev Kapur]

+1


On Tue, Sep 12, 2017 at 4:23 PM, Miguel Lavalle  wrote:

> Dear Neutrinos,
>
> Our social event will take place on Thursday September 12th at 7:30pm. The
> venue is going to be https://www.famousdaves.com/Denver-Stapleton. It is
> located 0.4 miles from the Renaissance Hotel, which translates to an easy 9
> minutes walk.
>
> I have a reservation for a group of 30 people under my name. Please
> respond to this message with your attendance confirmation by Wednesday
> night, so I can get a more accurate head count.
>
> Looking forward to see y'all Thursday night
>
> Best regards
>
> Miguel
>
> __
> 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] Debugging TripleO Ceph-Ansible Deployments

[John Fulton]

I blogged a guide on $subject if anyone wants to test the new method
to deploy Ceph

 http://blog.johnlikesopenstack.com/2017/09/debug-tripleo-ceph-ansible.html

  John

__
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] CLI extensions for the undercloud

[Ricardo Noriega De Soto]

Hello guys,

After integrating BGPVPN and L2GW Neutron drivers in TripleO, I've realized
I always have to jump to the overcloud controller (and copy-pasting the
overcloudrc file) in order to use the CLI extensions such "neutron
l2-gateway list".

I'd like to know what's the current strategy on other services and if it's
possible to use those extensions from the undercloud. From the UX
perspective it would be much appreciated! :-)

If so, any guideline for that??

Thanks

-- 
Ricardo Noriega

Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
Red Hat
irc: rnoriega @freenode
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova][cinder] Is there interest in an admin-api to refresh volume connection info?

[Matt Riedemann]

On 9/13/2017 9:52 AM, Arne Wiebalck wrote:



On 13 Sep 2017, at 16:52, Matt Riedemann  wrote:

On 9/13/2017 3:24 AM, Arne Wiebalck wrote:

I’m reviving this thread to check if the suggestion to address potentially 
stale connection
data by an admin command (or a scheduled task) made it to the planning for one 
of the
upcoming releases?


It hasn't, but we're at the PTG this week so I can throw it on the list of 
topics.



That’d be great, thanks!

--
Arne Wiebalck
CERN IT



We talked about this at the PTG today, notes are in the Cinder etherpad 
[1], search for "API to refresh volume connection info".


We agreed that we don't need a new admin level API. We are already 
processing block device info in several operations that involve 
rebuilding the VM, such as cold migrate/resize, stop/start, 
suspend/resume, and rebuild. There is a little flag in those code paths 
which already exists to refresh the connection information for each 
block device mapping. We agreed to just change those code paths to set 
that flag to True to refresh the connection information per BDM. We also 
said we wouldn't fail the operation if the refresh fails for whatever 
reason, like if Cinder fails. This would not be a backportable change 
and will have a release note, but it's much more automatic than needing 
to add an entirely new API. If you want/need to refresh volume 
connection information without disruption, you'd have to live migrate 
the server instance.


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

--

Thanks,

Matt

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

Re: [openstack-dev] [Openstack-operators] [nova][cinder] Is there interest in an admin-api to refresh volume connection info?

[Matt Riedemann]

On 9/13/2017 10:31 AM, Morgenstern, Chad wrote:

I have been studying how to perform failover operations with Cinder --failover. 
 Nova is not aware of the failover event. Being able to refresh the connection 
state especially for Nova would come in very handy, especially in admin level 
dr scenarios.

I'm attaching the blog I wrote on the subject:
http://netapp.io/2017/08/09/cinder-cheesecake-things-to-consider/


I'm not aware of the host failover feature in Cinder, but you're correct 
that there is no event listener on the nova side for this happening.


You could build something like this into the os-server-external-events 
API in Nova:


https://developer.openstack.org/api-ref/compute/#create-external-events-os-server-external-events

That is used today for Cinder to trigger a swap volume or volume extend 
operation in Nova. It would require a microversion and spec in nova, but 
it doesn't seem that hard to do, depending on what you need to do on the 
nova side. With the new 3.27 Cinder attachments APIs, it seems it could 
just be an attachment delete/create operation, but would we also need to 
disconnect old/connect new connections in os-brick?


--

Thanks,

Matt

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

Re: [openstack-dev] git review -d + git rebase changing author?

[Jeremy Stanley]

On 2017-09-14 18:16:03 + (+), Jeremy Stanley wrote:
> On 2017-09-14 12:01:54 -0600 (-0600), Matt Riedemann wrote:
> [...]
> > I figured out the pattern when this happens to change the author.
> > 
> > 1. git review -d
> > 2. git rebase -i master
> > 3. 
> > 4. fix merge conflict
> > 5. git add 
> > 6. git commit
> > 7. git rebase --continue
> > 
> > It's the merge conflict + git commit during the rebase that changes the
> > author for me.
> 
> You ought to be able to completely skip #6 above. Continuing the
> rebase (at least in the releases of Git I use) will amend the commit
> correctly and give you the ability to adjust the commit message when
> it does so.

Also, I'll just put this here...

https://docs.openstack.org/infra/manual/developers.html#rebasing-a-commit

-- 
Jeremy Stanley


signature.asc
Description: 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] git review -d + git rebase changing author?

[Jeremy Stanley]

On 2017-09-14 12:01:54 -0600 (-0600), Matt Riedemann wrote:
[...]
> I figured out the pattern when this happens to change the author.
> 
> 1. git review -d
> 2. git rebase -i master
> 3. 
> 4. fix merge conflict
> 5. git add 
> 6. git commit
> 7. git rebase --continue
> 
> It's the merge conflict + git commit during the rebase that changes the
> author for me.

You ought to be able to completely skip #6 above. Continuing the
rebase (at least in the releases of Git I use) will amend the commit
correctly and give you the ability to adjust the commit message when
it does so.
-- 
Jeremy Stanley


signature.asc
Description: 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] [all][deployment][kolla][tripleo][osa] Service diagnostics task force

[Surya Prakash Singh]

I am also in.

---
Thanks
Surya

-Original Message-
From: Gema Gomez [mailto:g...@ggomez.me] 
Sent: Thursday, September 14, 2017 11:43 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [all][deployment][kolla][tripleo][osa] Service 
diagnostics task force

I'd like to join this effort!

Cheers,
Gema

On 13/09/17 17:45, Michał Jastrzębski wrote:
> Hello my dearest of communities,
> 
> During deployment tools session on PTG we discussed need for deep 
> health checking and metering of running services. It's very relevant 
> in context of containers (especially k8s) and HA. Things like 
> watchdog, heartbeats or exposing relative metrics (I don't want to get 
> into design here, suffice to say it's non-trivial problem to solve).
> 
> We would like to start a "task force", few volunteers from both 
> deployment tool side (ops, ha) and project dev teams. We would like to 
> design together a proper health check mechanism for one of projects to 
> create best practices and design, that later could be implemented in 
> all other services.
> 
> We would to ask for volunteer project team to join us and spearhead this 
> effort.
> 
> 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
> 

__
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] git review -d + git rebase changing author?

[Matt Riedemann]

On 7/17/2017 6:31 PM, melanie witt wrote:

On Tue, 18 Jul 2017 09:22:31 +0900, Ghanshyam Mann wrote:

Yes, this is same case when we do fetch patch set using git checkout,
i do not think its something to do with gite review -d.


Doing that shouldn't change the author, at least in my experience. I 
constantly 'git fetch' or 'git review -d ' to fetch a patch, 
update it, and push a new revision. When I do that, the author stays the 
same but it shows me as the "Committer".


I have seen the behavior Matt describes happen to other people though 
and I would guess it has something to do with the rebase. Though I feel 
like I've also rebased other people's changes and it didn't change the 
Author, it only changed the Committer to me.


-melanie

__
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


I figured out the pattern when this happens to change the author.

1. git review -d
2. git rebase -i master
3. 
4. fix merge conflict
5. git add 
6. git commit
7. git rebase --continue

It's the merge conflict + git commit during the rebase that changes the 
author for me.


--

Thanks,

Matt

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

Re: [openstack-dev] [all][deployment][kolla][tripleo][osa] Service diagnostics task force

[Gema Gomez]

I'd like to join this effort!

Cheers,
Gema

On 13/09/17 17:45, Michał Jastrzębski wrote:
> Hello my dearest of communities,
> 
> During deployment tools session on PTG we discussed need for deep
> health checking and metering of running services. It's very relevant
> in context of containers (especially k8s) and HA. Things like
> watchdog, heartbeats or exposing relative metrics (I don't want to get
> into design here, suffice to say it's non-trivial problem to solve).
> 
> We would like to start a "task force", few volunteers from both
> deployment tool side (ops, ha) and project dev teams. We would like to
> design together a proper health check mechanism for one of projects to
> create best practices and design, that later could be implemented in
> all other services.
> 
> We would to ask for volunteer project team to join us and spearhead this 
> effort.
> 
> 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
> 

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

Re: [openstack-dev] [Openstack-operators] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[melanie witt]

On Thu, 14 Sep 2017 11:15:26 -0600, Ed Leafe wrote:

On Sep 14, 2017, at 10:30 AM, melanie witt  wrote:


I was thinking, if it's possible to assign more than one resource class to an Ironic 
node, maybe you could get similar behavior to the old non-exact filters. So if you have 
an oddball config, you could tag it as multiple resource classes that it's "close 
enough" to for a match. But I'm not sure whether it's possible for an Ironic node to 
be tagged with more than one resource class.


On the placement side, having an ironic node with two resource classes such as 
RC1 and RC2, would mean that the ResourceProvider (the ironic node) would have 
two inventory records: one for RC1, and another for RC2. When a request for a 
flavor specifying one of these classes is handled, only the one class’s 
inventory would be consumed. Placement would think that the node still had one 
of the other resource class available, and would include that if another 
request for that class is received, which would then fail as the node is 
already in use.


Okay, so it's not possible to have one Ironic node with one inventory 
record be classified as two different resource classes. Never mind that 
idea then.


Thanks for pointing that out.

-melanie




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

Re: [openstack-dev] [Openstack-operators] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Ed Leafe]

On Sep 14, 2017, at 10:30 AM, melanie witt  wrote:
> 
> I was thinking, if it's possible to assign more than one resource class to an 
> Ironic node, maybe you could get similar behavior to the old non-exact 
> filters. So if you have an oddball config, you could tag it as multiple 
> resource classes that it's "close enough" to for a match. But I'm not sure 
> whether it's possible for an Ironic node to be tagged with more than one 
> resource class.

On the placement side, having an ironic node with two resource classes such as 
RC1 and RC2, would mean that the ResourceProvider (the ironic node) would have 
two inventory records: one for RC1, and another for RC2. When a request for a 
flavor specifying one of these classes is handled, only the one class’s 
inventory would be consumed. Placement would think that the node still had one 
of the other resource class available, and would include that if another 
request for that class is received, which would then fail as the node is 
already in use.

-- Ed Leafe






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

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Boris Pavlovic]

Jay,

OK, I'll bite.


This doesn't sound like a constructive discussion. Bye Bye.

Best regards,
Boris Pavlovic

On Thu, Sep 14, 2017 at 8:50 AM, Jay Pipes  wrote:

> OK, I'll bite.
>
> On 09/13/2017 08:56 PM, Boris Pavlovic wrote:
>
>> Jay,
>>
>> All that you say exactly explains the reason why more and more companies
>> are leaving OpenStack.
>>
>
> All that I say? The majority of what I was "saying" was actually asking
> you to back up your statements with actual proof points instead of making
> wild conjectures.
>
> Companies and actually end users care only about their things and how can
>> they get their job done. They want thing that they can run and support
>> easily and that resolves their problems.
>>
>
> No disagreement from me. That said, I fail to see what the above statement
> has to do with anything I wrote.
>
> They initially think that it's a good idea to take a OpenStack as a
>> Framework and build sort of product on top of it because it's so open and
>> large and everybody uses...
>>
>
> End users of OpenStack don't "build sort of product on top". End users of
> OpenStack call APIs or use Horizon to launch VMs, create networks, volumes,
> and whatever else those end users need for their own use cases.
>
> Soon they understand that OpenStack has very complicated operations
>> because it's not designed to be a product but rather framework and that the
>> complexity of running OpenStack is similar to development in house solution
>> and as time is spend they have only few options: move to public cloud or
>> some other private cloud solution...
>>
>
> Deployers of OpenStack use the method of installing and configuring
> OpenStack that matches best their cultural fit, experience and level of
> comfort with underlying technologies and vendors (packages vs. source vs.
> images, using a vendor distribution vs. going it alone, Chef vs. Puppet vs.
> Ansible vs. SaltStack vs. Terraform, etc). The way they configure OpenStack
> services is entirely dependent on the use cases they wish to support for
> their end users. And, to repeat myself, there is NO SINGLE USE CASE for
> infrastructure services like OpenStack. Therefore there is zero chance for
> a "standard deployment" of OpenStack becoming a reality.
>
> Just like there are myriad ways of deploying and configuring OpenStack,
> there are myriad ways of deploying and configuring k8s. Why? Because
> deploying and configuring highly distributed systems is a hard problem to
> solve. And maintaining and operating those systems is an even harder
> problem to solve.
>
> We as a community can continue saying that the current OpenStack approach
>> is the best
>>
>
> Nobody is saying that the current OpenStack approach is the best. I
> certainly have never said this. All that I have asked is that you actually
> back up your statements with proof points that demonstrate how and why a
> different approach to building software will lead to specific improvements
> in quality or user experience.
>
> and keep loosing customers/users/community, or change something
>> drastically, like bring technical leadership to OpenStack Foundation
>> that is going to act like benevolent dictator that focuses OpenStack
>> effort on shrinking uses cases, redesigning architecture and moving
>> to the right direction...
>>
>
> What *specifically* is the "right direction" for OpenStack to take?
> Please, as I asked you in the original response, provide actual details
> other than "we should have a monolithic application". Provide an argument
> as to how and why *your* direction is "right" for every user of OpenStack.
>
> When you say "technical leadership", what specifically are you wanting to
> see?
>
>
>> I know this all sounds like a big change, but let's be honest current
>> situation doesn't look healthy...
>> By the way, almost all successful projects in open source have benevolent
>> dictator and everybody is OK with that's how things works...
>>
>
> Who is the benevolent dictator of k8s? Who is the benevolent dictator of
> MySQL? Of PostgreSQL? Of etcd?
>
> You have a particularly myopic view of what "successful" is for open
> source, IMHO.
>
> Awesome news. I will keep this in mind when users (like GoDaddy) ask
>> Nova to never break anything ever and keep behaviour like scheduler
>> retries that represent giant technical debt.
>>
>> I am writing here on my behalf (using my personal email, if you haven't
>> seen), are we actually Open Source? or Enterprise Source?
>>
>> More over I don't think that what you say is going to be an issue for
>> GoDaddy, at least soon, because we still can't upgrade, because it's NP
>> complete problem (even if you run just core projects), which is what my
>> email was about, and I saw the same stories in bunch of other companies.
>>
>
> You continue to speak in hyperbole and generalizations. What
> *specifically* about your recommendations will improve the upgrade ability
> and story for OpenStack?
>
>  

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[melanie witt]

On Thu, 7 Sep 2017 14:57:24 -0500, Matt Riedemann wrote:

Some more background information is in the ironic spec here:

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

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


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



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


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


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



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


This came up in the Nova PTG room yesterday and I wanted to reply on the 
thread with what I understood about it, for those who weren't in the 
session. In general, it's recommended to use the exact filters (1 flavor 
per Ironic node hardware config) as there's no concept of partially 
claiming a baremetal node.


But, with the old non-exact filters, you _could_ get away with creating 
fewer flavors than you have hardware configs and get "fuzzy matching" on 
Ironic nodes, to get nodes whose configs are "close enough" but not 
exact. This might be helpful in situations where you have some oddball 
configs you don't want to have separate flavors for.
I was thinking, if it's possible to assign more than one resource class 
to an Ironic node, maybe you could get similar behavior to the old 
non-exact filters. So if you have an oddball config, you could tag it as 
multiple resource classes that it's "close enough" to for a match. But 
I'm not sure whether it's possible for an Ironic node to be tagged with 
more than one resource class.


-melanie

__
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] [k8s][deployment][kolla-kubernetes][magnum][kuryr][qa][api] Proposal for SIG-K8s

[Chris Hoge]

This Friday, September 15 at the PTG we will be hosting an organizational
meeting for SIG-K8s. More information on the proposal, meeting time, and
remote attendance is in the openstack-sigs mailing list [1].

Thanks,
Chris Hoge
Interop Engineer
OpenStack Foundation

[1] 
http://lists.openstack.org/pipermail/openstack-sigs/2017-September/51.html
__
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] [placement] Modeling SR-IOV with nested resource providers

[Jay Pipes]

On 09/13/2017 03:01 PM, Chris Dent wrote:

On Wed, 13 Sep 2017, Jay Pipes wrote:

We still need a way to represent a request to placement to find 
allocation candidates for like resources, though. As you pointed out, 
I've thought about using multiple requests to placement from the 
conductor or scheduler. We could also do something like this:


GET 
/allocation_candidates?resources=VCPU:1,MEMORY_MB:1024=SRIOV_NET_VF:1=CUSTOM_PHYSNET_A,CUSTOM_SWITCH_1=SRIOV_NET_VF:1=CUSTOM_PHYSNET_A,CUSTOM_SWITCH_2 



To clarify, this translates to:

* give me one compute node with 1 VCPU and 1024 MEMORY_MB that has
* 2 vf
   * both on physnet A
   * one on switch 1
   * one on switch 2


Yup, zactly.

-jay

__
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] [ptg] Simplification in OpenStack

[Jay Pipes]

OK, I'll bite.

On 09/13/2017 08:56 PM, Boris Pavlovic wrote:

Jay,

All that you say exactly explains the reason why more and more companies 
are leaving OpenStack.


All that I say? The majority of what I was "saying" was actually asking 
you to back up your statements with actual proof points instead of 
making wild conjectures.


Companies and actually end users care only about their things and how 
can they get their job done. They want thing that they can run and 
support easily and that resolves their problems.


No disagreement from me. That said, I fail to see what the above 
statement has to do with anything I wrote.


They initially think that it's a good idea to take a OpenStack as a 
Framework and build sort of product on top of it because it's so open 
and large and everybody uses...


End users of OpenStack don't "build sort of product on top". End users 
of OpenStack call APIs or use Horizon to launch VMs, create networks, 
volumes, and whatever else those end users need for their own use cases.


Soon they understand that OpenStack has very complicated operations 
because it's not designed to be a product but rather framework and that 
the complexity of running OpenStack is similar to development in house 
solution and as time is spend they have only few options: move to public 
cloud or some other private cloud solution...


Deployers of OpenStack use the method of installing and configuring 
OpenStack that matches best their cultural fit, experience and level of 
comfort with underlying technologies and vendors (packages vs. source 
vs. images, using a vendor distribution vs. going it alone, Chef vs. 
Puppet vs. Ansible vs. SaltStack vs. Terraform, etc). The way they 
configure OpenStack services is entirely dependent on the use cases they 
wish to support for their end users. And, to repeat myself, there is NO 
SINGLE USE CASE for infrastructure services like OpenStack. Therefore 
there is zero chance for a "standard deployment" of OpenStack becoming a 
reality.


Just like there are myriad ways of deploying and configuring OpenStack, 
there are myriad ways of deploying and configuring k8s. Why? Because 
deploying and configuring highly distributed systems is a hard problem 
to solve. And maintaining and operating those systems is an even harder 
problem to solve.


We as a community can continue saying that the current OpenStack 
approach is the best


Nobody is saying that the current OpenStack approach is the best. I 
certainly have never said this. All that I have asked is that you 
actually back up your statements with proof points that demonstrate how 
and why a different approach to building software will lead to specific 
improvements in quality or user experience.



and keep loosing customers/users/community, or change something
drastically, like bring technical leadership to OpenStack Foundation
that is going to act like benevolent dictator that focuses OpenStack
effort on shrinking uses cases, redesigning architecture and moving
to the right direction...


What *specifically* is the "right direction" for OpenStack to take? 
Please, as I asked you in the original response, provide actual details 
other than "we should have a monolithic application". Provide an 
argument as to how and why *your* direction is "right" for every user of 
OpenStack.


When you say "technical leadership", what specifically are you wanting 
to see?




I know this all sounds like a big change, but let's be honest current 
situation doesn't look healthy...
By the way, almost all successful projects in open source have 
benevolent dictator and everybody is OK with that's how things works...


Who is the benevolent dictator of k8s? Who is the benevolent dictator of 
MySQL? Of PostgreSQL? Of etcd?


You have a particularly myopic view of what "successful" is for open 
source, IMHO.



Awesome news. I will keep this in mind when users (like GoDaddy) ask
Nova to never break anything ever and keep behaviour like scheduler
retries that represent giant technical debt.

I am writing here on my behalf (using my personal email, if you haven't 
seen), are we actually Open Source? or Enterprise Source?


More over I don't think that what you say is going to be an issue for 
GoDaddy, at least soon, because we still can't upgrade, because it's NP 
complete problem (even if you run just core projects), which is what my 
email was about, and I saw the same stories in bunch of other companies.


You continue to speak in hyperbole and generalizations. What 
*specifically* about your recommendations will improve the upgrade 
ability and story for OpenStack?



Yes, let's definitely go the opposite direction of microservices and
loosely coupled domains which is the best practices of software
development over the last two decades. While we're at it, let's
rewrite OpenStack projects in COBOL.

I really don't want to answer on this provocation, because it shifts the 
focus from major topic. 

[openstack-dev] [glance] Queens PTG: Wednesday summary

[Brian Rosmaita]

For those who couldn't attend, here's a quick synopsis of what was
discussed yesterday.

Please consult the etherpad for each session for details.  Feel free
to put questions/comments on the etherpads, and then put an item on
the agenda for the weekly meeting on Thursday 21 September, and we'll
continue the discussion.


Strategic plan for Glance (Q, R, S, T, U)
-
https://etherpad.openstack.org/p/glance-queens-ptg-strategic-plan

No major surprises here, but some things to note:
- Q will be focused on completing interoperable image import and
making 2.6 the CURRENT API version
- The Images v1 API will be removed in Q (necessary condition is 2.6
becoming current, though)
- The Glance Registry API v1 will be removed in Q (necessary condition
is removal of Images v1 API)
- The Glance Registry API v2 will be DEPRECATED in Q and scheduled for
removal in S


Interoperable image import: where we are now and what testing needs to be added
---
https://etherpad.openstack.org/p/glance-queens-ptg-iir-testing

Basically, we need a lot more tests.  Abhishek is going to run a
coverage analysis to give us a list of items to work on.  Everyone is
going to investigate what QA resources are available, and we'll
discuss how to divide up the work at the September 28 Glance meeting.


Can the v1 API be removed in Queens?

https://etherpad.openstack.org/p/glance-queens-ptg-remove-v1-API

Yes, it can!  Assuming other goals are met, namely:
- implementing a safe 'copy-from' import-method (i.e., completing the
2.6 API and making it current).  ("Safe" copy-from addresses
OSSN-0078).
- removing any remaining Images API v1 tempest tests
- notify the Horizon team that the Images API v1 is scheduled for
removal in Queens

Plans for the python-glanceclient are:
- announce deprecation of Images v1 API support
- Q release of glanceclient will be the last one with v1 support
- Images API v1 support will be removed from the python-glanceclient in R
- notify OSC team about this timeline
- notify Shade team (though I don't think they use the glanceclient)


Community goal: policy-in-code: where we are

https://etherpad.openstack.org/p/glance-queens-ptg-policy-in-code

The conclusion of the discussion is that the proposed advantages to
this effort don't appear to apply to Glance, but it's a bit late to
bring that up now.  The primary advantage will be documentation of the
policies, which will eat reviewer time, but it will be good to do
(though inconvenient given the size of the development team right
now).

A complicating factor is that Glance also allows the use of policies
to define property protections.  We'll have to improve the
documentation around this feature.


Remove show_image_locations config option
-
https://etherpad.openstack.org/p/glance-queens-ptg-remove-sml-config-opt

The show_image_locations config option was deprecated in Newton and
scheduled for removal in Ocata.  It has become problematic to remove
this option because of OSSN-0065, as it gives operators a one-step way
to make sure the exploit described in that OSSN doesn't apply to their
installation (rather than properly configuring 3 related policies).

One suggestion is to rename the policy to something like
'insecure_location_access' (default value False) and then it will be a
bit more clear to operators what the config option allows.


Interoperable image import: next steps
--
https://etherpad.openstack.org/p/glance-queens-ptg-iir-next-steps

See the etherpad for the list of to-do items for Queens.


Adding microversion support to the Glance APIs
--
https://etherpad.openstack.org/p/glance-queens-ptg-microversions

Matt Treinish led an interesting discussion of why Glance should do
this.  We'll revisit this after the 2.6 API becomes CURRENT and the
Images API v1 has been removed.



See the scheduling etherpad for what we'll be discussing on Thursday:
https://etherpad.openstack.org/p/glance-queens-ptg

__
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] [Zun] Propose change of the core team

[Hongbin Lu]

Hi all,

I propose the following change of the Zun core reviewer team.

+ Kien Nguyen (kiennt2609)
- Aditi Sharma (adi-sky17)

Kien has been contributing to the Zun project for a few months. His 
contributions include proposing high-quality codes, providing helpful code 
reviews, participating team discussion at weekly team meeting and IRC, etc. He 
is the one who setup the multi-node job in the CI and the job is up and running 
now. I think his contribution is significant which qualifies him to be a core 
reviewer. Aditi is a member of the initial core team but becomes inactive for a 
while.

Core reviewers, please cast your vote on this proposal.

Best regards,
Hongbin

__
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] [tricircle] [ptg] PTG reminder

[Vega Cai]

Hello folks,

Just to remind that the PTG of Tricircle team will be held on Sep 15th,
from 9:00 am to 17:00 pm(UTC+8). We will discuss our topics in this
etherpad page[1] and #openstack-tricircle channel, so you can join the
discussion via etherpad and IRC. Also, please feel free to add topic to the
etherpad page.

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

BR
Zhiyuan Cai

-- 
BR
Zhiyuan
__
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] [octavia][heat] Octavia deployment with Heat

[Rabi Mishra]

On Thu, Sep 14, 2017 at 6:05 PM, Lingxian Kong  wrote:

> BTW, may I ask if Heat(master) already supports Octavia V2 API? If no, is
> there anyone working on that or it's on the TODO list? Thanks!
>
>
I think the current support is limited to neutron LBaaS v2.0  extension[1].
Looks like Octavia v2.0 API [2] is a superset of that.

No, we don't have anyone working on it atm.

[1]
https://developer.openstack.org/api-ref/network/v2/index.html#load-balancer-as-a-service

[2] https://developer.openstack.org/api-ref/load-balancer/v2/index.html

>
> Cheers,
> Lingxian Kong (Larry)
>
> On Thu, Sep 14, 2017 at 6:11 PM,  wrote:
>
>> Hello,
>>
>>
>>
>> Are there any plans to fix this in Heat?
>>
>>
>>
>> Thank you,
>>
>> Mihaela Balas
>>
>>
>>
>> *From:* Rabi Mishra [mailto:ramis...@redhat.com]
>> *Sent:* Wednesday, July 26, 2017 3:43 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [octavia][heat] Octavia deployment with
>> Heat
>>
>>
>>
>> On Wed, Jul 26, 2017 at 5:34 PM,  wrote:
>>
>> Hello,
>>
>>
>>
>> Is Octavia (Ocata version) supposed to work with Heat (tested with Newton
>> version) deployment? I launch a Heat stack trying to deploy a load balancer
>> with a single listener/pool and two members. While the Heat shows status
>> COMPLETE and the Neutron shows all objects as created, Octavia creates the
>> listener, the pool but with a single member (instead of two).
>>
>> Another example: I launch a Heat stack trying to deploy a load balancer
>> with a multiple listeners/pools each having two members. The results is
>> that Heat shows status COMPLETE and the Neutron shows all objects as
>> created, Octavia creates the listeners, but only some of the pools and for
>> those pool creates only one member or none.
>>
>> In the Octavia log I could see only these type of errors:
>>
>>
>>
>> Sounds like https://bugs.launchpad.net/heat/+bug/1632054.
>>
>> We just check provisioning_status of the loadbalancer when adding members
>> and mark the resource as CREATE_COMPLETE.  I think octavia had added
>> provisioning_status for all top level objects like listener etc[1], but I
>> don't think those attributes are available with lbaasv2 api for us to check.
>>
>> [1] https://review.openstack.org/#/c/372791/
>>
>>
>>
>> 2017-07-26 08:12:08.639 1 INFO octavia.api.v1.controllers.member
>> [req-749be397-dd63-4fb6-9d86-b717f6d59e3d -
>> 989bbadfe4134722b478ca799217833e - default default] Member cannot be
>> created or modified because the Load Balancer is in an immutable state
>>
>> 2017-07-26 08:12:08.698 1 DEBUG wsme.api 
>> [req-749be397-dd63-4fb6-9d86-b717f6d59e3d
>> - 989bbadfe4134722b478ca799217833e - default default] Client-side error:
>> Load Balancer b12a29db-81d0-451a-af9c-d563b636bf01 is immutable and
>> cannot be updated. format_exception /opt/octavia/lib/python2.7/sit
>> e-packages/wsme/api.py:222
>>
>>
>>
>> I think what happens is that it takes some time until the configuration
>> is updated on an amphora and during that time the Load Balancer is in
>> UPDATE state and new configuration cannot be added.
>>
>>
>>
>> Is this scenario validated or it is still work in progress?
>>
>>
>>
>> Thanks,
>>
>> Mihaela Balas
>>
>>
>>
>>
>>
>> _
>>
>>
>>
>> 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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _
>>
>> Ce message et ses pieces jointes peuvent contenir des informations 
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans 

Re: [openstack-dev] [octavia][heat] Octavia deployment with Heat

[Lingxian Kong]

BTW, may I ask if Heat(master) already supports Octavia V2 API? If no, is
there anyone working on that or it's on the TODO list? Thanks!


Cheers,
Lingxian Kong (Larry)

On Thu, Sep 14, 2017 at 6:11 PM,  wrote:

> Hello,
>
>
>
> Are there any plans to fix this in Heat?
>
>
>
> Thank you,
>
> Mihaela Balas
>
>
>
> *From:* Rabi Mishra [mailto:ramis...@redhat.com]
> *Sent:* Wednesday, July 26, 2017 3:43 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [octavia][heat] Octavia deployment with
> Heat
>
>
>
> On Wed, Jul 26, 2017 at 5:34 PM,  wrote:
>
> Hello,
>
>
>
> Is Octavia (Ocata version) supposed to work with Heat (tested with Newton
> version) deployment? I launch a Heat stack trying to deploy a load balancer
> with a single listener/pool and two members. While the Heat shows status
> COMPLETE and the Neutron shows all objects as created, Octavia creates the
> listener, the pool but with a single member (instead of two).
>
> Another example: I launch a Heat stack trying to deploy a load balancer
> with a multiple listeners/pools each having two members. The results is
> that Heat shows status COMPLETE and the Neutron shows all objects as
> created, Octavia creates the listeners, but only some of the pools and for
> those pool creates only one member or none.
>
> In the Octavia log I could see only these type of errors:
>
>
>
> Sounds like https://bugs.launchpad.net/heat/+bug/1632054.
>
> We just check provisioning_status of the loadbalancer when adding members
> and mark the resource as CREATE_COMPLETE.  I think octavia had added
> provisioning_status for all top level objects like listener etc[1], but I
> don't think those attributes are available with lbaasv2 api for us to check.
>
> [1] https://review.openstack.org/#/c/372791/
>
>
>
> 2017-07-26 08:12:08.639 1 INFO octavia.api.v1.controllers.member
> [req-749be397-dd63-4fb6-9d86-b717f6d59e3d - 989bbadfe4134722b478ca799217833e
> - default default] Member cannot be created or modified because the Load
> Balancer is in an immutable state
>
> 2017-07-26 08:12:08.698 1 DEBUG wsme.api 
> [req-749be397-dd63-4fb6-9d86-b717f6d59e3d
> - 989bbadfe4134722b478ca799217833e - default default] Client-side error:
> Load Balancer b12a29db-81d0-451a-af9c-d563b636bf01 is immutable and
> cannot be updated. format_exception /opt/octavia/lib/python2.7/
> site-packages/wsme/api.py:222
>
>
>
> I think what happens is that it takes some time until the configuration is
> updated on an amphora and during that time the Load Balancer is in UPDATE
> state and new configuration cannot be added.
>
>
>
> Is this scenario validated or it is still work in progress?
>
>
>
> Thanks,
>
> Mihaela Balas
>
>
>
>
>
> _
>
>
>
> 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
>
> _
>
> 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 
> 

[openstack-dev] [senlin] Meeting for Queens Goal

[YUAN RUIJIE]

Hi Senlin Core Team,

We are going to have a meetup to discuss the goal & features we want to
implement in Queens cycle. As we discussed during the latest weekly
meeting, we have the follow options:

1. Have a virtual meeting by some meeting softwares
2. Organize a Meetup in middle Oct, since the National Day is coming.

Suggestions are welcomed,

Sincerely,
ruijie
__
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] Denver Team Dinner

[Michael Johnson]

+1 Miguel, thanks for putting this together!

Michael

On Wed, Sep 13, 2017 at 9:09 PM, Akihiro Motoki  wrote:
> +1 thanks for organizing this
>
> 2017-09-12 17:23 GMT-06:00 Miguel Lavalle :
>> Dear Neutrinos,
>>
>> Our social event will take place on Thursday September 12th at 7:30pm. The
>> venue is going to be https://www.famousdaves.com/Denver-Stapleton. It is
>> located 0.4 miles from the Renaissance Hotel, which translates to an easy 9
>> minutes walk.
>>
>> I have a reservation for a group of 30 people under my name. Please respond
>> to this message with your attendance confirmation by Wednesday night, so I
>> can get a more accurate head count.
>>
>> Looking forward to see y'all Thursday night
>>
>> Best regards
>>
>> Miguel
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] Kingbird UX for Horizon

[Goutham Pratapa]

HI all,

Attached are the expected UX screens for Kingbird's horizon please feel
free to provide feedback on this.


P.S: *Images are drawn using paint and we will follow all the OpenStack
Horizon standards when we develop*

-- 
Cheers !!!
Goutham Pratapa
__
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] [octavia][heat] Octavia deployment with Heat

[mihaela.balas]

Hello,

Are there any plans to fix this in Heat?

Thank you,
Mihaela Balas

From: Rabi Mishra [mailto:ramis...@redhat.com]
Sent: Wednesday, July 26, 2017 3:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [octavia][heat] Octavia deployment with Heat

On Wed, Jul 26, 2017 at 5:34 PM, 
> wrote:
Hello,

Is Octavia (Ocata version) supposed to work with Heat (tested with Newton 
version) deployment? I launch a Heat stack trying to deploy a load balancer 
with a single listener/pool and two members. While the Heat shows status 
COMPLETE and the Neutron shows all objects as created, Octavia creates the 
listener, the pool but with a single member (instead of two).
Another example: I launch a Heat stack trying to deploy a load balancer with a 
multiple listeners/pools each having two members. The results is that Heat 
shows status COMPLETE and the Neutron shows all objects as created, Octavia 
creates the listeners, but only some of the pools and for those pool creates 
only one member or none.
In the Octavia log I could see only these type of errors:

Sounds like https://bugs.launchpad.net/heat/+bug/1632054.
We just check provisioning_status of the loadbalancer when adding members and 
mark the resource as CREATE_COMPLETE.  I think octavia had added 
provisioning_status for all top level objects like listener etc[1], but I don't 
think those attributes are available with lbaasv2 api for us to check.

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

2017-07-26 08:12:08.639 1 INFO octavia.api.v1.controllers.member 
[req-749be397-dd63-4fb6-9d86-b717f6d59e3d - 989bbadfe4134722b478ca799217833e - 
default default] Member cannot be created or modified because the Load Balancer 
is in an immutable state
2017-07-26 08:12:08.698 1 DEBUG wsme.api 
[req-749be397-dd63-4fb6-9d86-b717f6d59e3d - 989bbadfe4134722b478ca799217833e - 
default default] Client-side error: Load Balancer 
b12a29db-81d0-451a-af9c-d563b636bf01 is immutable and cannot be updated. 
format_exception /opt/octavia/lib/python2.7/site-packages/wsme/api.py:222

I think what happens is that it takes some time until the configuration is 
updated on an amphora and during that time the Load Balancer is in UPDATE state 
and new configuration cannot be added.

Is this scenario validated or it is still work in progress?

Thanks,
Mihaela Balas



_



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

_

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