[openstack-dev] Tacker

[Ivan Lozgachev]

Hello everyone!

Could you please help me implement custom management driver?

At the moment I created
directory /opt/stack/tacker/tacker/vm/mgmt_drivers/nfvpilot/ and put there
__init__.py and nfvpilot.py driver implementation as it' done for example
for OpenWRT driver. But while creating my VNF I always get error

2015-10-20 10:33:28.409 TRACE tacker.api.v1.resource   File
"/opt/stack/tacker/tacker/vm/plugin.py", line 66, in mgmt_create_pre
2015-10-20 10:33:28.409 TRACE tacker.api.v1.resource device_dict,
plugin=self, context=context, device=device_dict)
2015-10-20 10:33:28.409 TRACE tacker.api.v1.resource   File
"/opt/stack/tacker/tacker/vm/plugin.py", line 62, in _invoke
2015-10-20 10:33:28.409 TRACE tacker.api.v1.resource
self._mgmt_driver_name(device_dict), method, **kwargs)
2015-10-20 10:33:28.409 TRACE tacker.api.v1.resource   File
"/opt/stack/tacker/tacker/common/driver_manager.py", line 74, in invoke
2015-10-20 10:33:28.409 TRACE tacker.api.v1.resource driver =
self._drivers[type_]
2015-10-20 10:33:28.409 TRACE tacker.api.v1.resource KeyError: u'nfvpilot'

How do I register my own driver to make it visible?
__
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.messaging] Why the needed version of kombu to support heartbeat is >=3.0.7

[Mehdi Abaakouk]

Le 2015-10-27 04:22, me,apporc a écrit :
But i found in the changelog history of kombu [1], heartbeat support 
was

added in version 2.5.0, so what's the point for ">= 3.0.7". Thanks.


The initial heartbeat implementation have some critical issues for 
oslo.messaging that was fixed since kombu 3.0.7 and py-amqp 1.4.0.


---
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

__
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] [magnum][kolla] Stepping down as a Magnum core reviewer

[大塚元央]

Hi Steve,

I'm very sad about your stepping down from Magnum core. Without your help,
I couldn't contribute to magnum project.
But kolla is also fantastic project.
I wish you the best of luck in kolla.

Best regards.
- Yuanying Otsuka

On Tue, Oct 27, 2015 at 00:39 Baohua Yang  wrote:

> Really a pity!
>
> We need more resources on the container part in OpenStack indeed, as so
> many new projects are just initiated.
>
> Community is not only about putting technologies together, but also
> putting technical guys together.
>
> Happy to see so many guys in the Tokyo Summit this afternoon.
>
> Let's take care of the opportunities to make good communications with each
> other.
>
> On Mon, Oct 26, 2015 at 8:17 AM, Steven Dake (stdake) 
> wrote:
>
>> Hey folks,
>>
>> It is with sadness that I find myself under the situation to have to
>> write this message.  I have the privilege of being involved in two of the
>> most successful and growing projects (Magnum, Kolla) in OpenStack.  I chose
>> getting involved in two major initiatives on purpose, to see if I could do
>> the job; to see if  I could deliver two major initiatives at the same
>> time.  I also wanted it to be a length of time that was significant – 1+
>> year.  I found indeed I was able to deliver both Magnum and Kolla, however,
>> the impact on my personal life has not been ideal.
>>
>> The Magnum engineering team is truly a world class example of how an Open
>> Source project should be constructed and organized.  I hope some young
>> academic writes a case study on it some day but until then, my gratitude to
>> the Magnum core reviewer team is warranted by the level of  their sheer
>> commitment.
>>
>> I am officially focusing all of my energy on Kolla going forward.  The
>> Kolla core team elected me as PTL (or more accurately didn’t elect anyone
>> else;) and I really want to be effective for them, especially in what I
>> feel is Kolla’s most critical phase of growth.
>>
>> I will continue to fight  for engineering resources for Magnum internally
>> in Cisco.  Some of these have born fruit already including the Heat
>> resources, the Horizon plugin, and of course the Networking plugin system.
>> I will also continue to support Magnum from a resources POV where I can do
>> so (like the fedora image storage for example).  What I won’t be doing is
>> reviewing Magnum code (serving as a gate), or likely making much technical
>> contribution to Magnum in the future.  On the plus side I’ve replaced
>> myself with many many more engineers from Cisco who should be much more
>> productive combined then I could have been alone ;)
>>
>> Just to be clear, I am not abandoning Magnum because I dislike the people
>> or the technology.  I think the people are fantastic! And the technology –
>> well I helped design the entire architecture!  I am letting Magnum grow up
>> without me as I have other children that need more direct attention.  I
>> think this viewpoint shows trust in the core reviewer team, but feel free
>> to make your own judgements ;)
>>
>> Finally I want to thank Perry Myers for influencing me to excel at
>> multiple disciplines at once.  Without Perry as a role model, Magnum may
>> have never happened (or would certainly be much different then it is
>> today). Being a solid hybrid engineer has a long ramp up time and is really
>> difficult, but also very rewarding.  The community has Perry to blame for
>> that ;)
>>
>> Regards
>> -steve
>>
>> __
>> 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 wishes!
> Baohua
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] Utility Based Scheduler documentation

[Rahul Nair]

Hi All,

As the the Utility Based Scheduler has been rewritten to simplify the
compute monitor plugin, can someone please give me pointers on how a montor
can be implemented using the new monitor interface to extend the UBS
framework, I was trying to implement a plugin based on the CPU queue
length, but seeing the changes to the interface, I am not sure how to
implement it. I couldn't not find documentation on the same in openstack
docs.

Any pointers would be very helpful.

Regards,
Rahul U Nair
__
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] Neutron Social Meetup in Tokyo

[Takashi Yamamoto]

hi,

On Tue, Oct 27, 2015 at 10:31 AM, Sukhdev Kapur  wrote:
> Hey Akihiro,
>
> Thanks for arranging this. I did not see any link to RSVP.
> I would love to attend this event - please add me to the list.

at this point just go to the venue is fine.

here's a RSVP link in case you still want to register for some reason.
http://neutrontokyo.app.rsvpify.com/

>
> Thanks
> -Sukhdev
>
>
> On Fri, Oct 23, 2015 at 9:23 AM, Akihiro Motoki  wrote:
>>
>> Hi Neutron folks,
>>
>> We are pleased to announce Neutron social meet-up in Tokyo.
>> Thanks Takashi and Hirofumi for the big help.
>>
>> I hope many of you will be there and enjoy the time.
>> If you have made RSVP, don't miss it!
>> We recommend  to join the beginning, but come and join us even if you
>> arrive late.
>>
>> 
>>
>> Thursday, Oct 29 19:00-22:00
>> Hokkaido (北海道 品川インターシティー店)
>>
>> Location:
>>
>> https://www.google.com/maps/d/edit?mid=zBFFkY6dvVno.kOTkyNjZ2oU0&usp=sharing
>> 5th floor at the "shop and restaurant building" (between A and B
>> buildings).
>> It is at the opposite side of JR Shinagawa Station from the Summit side.)
>>
>> Approximately it costs ~5000 (Japanese) Yen depending on the number of
>> folks who join.
>> Note that we have no sponsors.
>>
>> If you have any trouble in reaching there or some question, reach me
>> @ritchey98 on Twitter.
>>
>> 
>>
>> See you in Tokyo!
>> Akihiro
>>
>> __
>> 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] [Nova][Manila] Nova API to attach/detach file volume/share

[Sage Weil]

On Mon, 26 Oct 2015, Ben Swartzlander wrote:
> On 10/25/2015 01:25 PM, Sage Weil wrote:
> > Hi everyone,
> > 
> > We're currently working on an improved mechanism for plumbing file access
> > into a VM or container and in most cases some interaction and
> > configuration on the hypervisor/host is required to make it happen.  The
> > goal is to create something that generalizes beyond the current NFS and
> > CIFS-only assumptions that are baked into the current crop of Manila
> > drivers.
> > 
> > The current target is to use the new VSOCK zero-configuration sockets,
> > which I will be talking about at the summit on Wednesday:
> > 
> >   - mount distributed fs on host, export via knfsd to guest over VSOCK
> >   - run Ganesha with distributed fs FSAL on host, export to guest over VSOCK
> 
> NFS-over-vsock is a VERY interesting idea. I understood that it wasn't
> implemented yet in Linux... If that's no longer true then I'm excited to find
> a way to make it work.

There is a lot of enabling work, but Stefan Hajnoczi has patches in flight 
for qemu and the Linux NFS client+server, and Matt Benjamin is adding 
Ganesha support and will work on getting the needed nfs-utils changes in 
place.  It'll take a bit for this all to land upstream and in supported 
distros, but we think the overall stack in very promising!

The challenge, I suspect, will be getting Manila and Nova to orchestrate 
it properly...

If you're at the summit, I'll be talking a bit about this on Wednesday at 
4:40 (http://sched.co/4A03).

sage

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

[openstack-dev] [oslo.messaging] Why the needed version of kombu to support heartbeat is >=3.0.7

[me,apporc]

In this commit: https://review.openstack.org/#/c/12/, we set the
requirement of kombu to >=3.0.7 to support rabbit heartbeat.

But i found in the changelog history of kombu [1], heartbeat support was
added in version 2.5.0, so what's the point for ">= 3.0.7". Thanks.

[1]:
http://docs.celeryproject.org/projects/kombu/en/latest/changelog.html#version-2-5-0

-- 
Regards,
apporc
__
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] Migration state machine proposal.

[Chris Friesen]

On 10/26/2015 06:02 PM, Jay Pipes wrote:


I believe strongly that we should deprecate the existing migrate, resize, an
live-migrate APIs in favor of a single consolidated, consistent "move" REST API
that would have the following characteristics:

* No manual or wait-input states in any FSM graph


Sounds good.


* Removal of the term "resize" from the API entirely (the target resource sizing
is an attribute of the move operation, not a different type of API operation in
and of itself)


I disagree on this one.

As an end-user, if my goal is to take an existing instance and give it bigger 
disks, my first instinct isn't going to be to look at the "move" operation.  I'm 
going to look for "scale", or "resize", or something like that.


And if an admin wants to migrate an instance away from its current host, why 
would they want to change its disk size in the process?


I do think it makes sense to combine the external APIs for live and cold 
migration.  Those two are fundamentally similar, logically separated only by 
whether the instance stays running or not.


And I'm perfectly fine with having the internal implementation of all three 
share a code path, I just don't think it makes sense for the *external* API.



* Transition to a task-based API for poll-state requests. This means that in
order for a caller to determine the state of a VM the caller would call
something like GET /servers//tasks/ in order to see the history of
state changes or subtask operations for a particular request to move a VM

enstack.org/cgi-bin/mailman/listinfo/openstack-dev

Sounds good.

Chris

__
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] [Security] Meetup / Lunch

[Clark, Robert Graham]

We have two fishbowls sessions on Thursday with lunch in the middle. I know 
there are security talks going on around the same times, this was unavoidable.

Perhaps we could all meet up for lunch on thursday, maybe by the prince hotel 
pool? (Off the marketplace)

Looking forward to meeting up with those of you I haven’t already seen!

-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-dev] [watcher] architecture meeting in Tokyo

[Antoine Cabot]

Hi folks,

We will have an architecture session in the OpenStack Community Lounge at
2.30pm today.
https://etherpad.openstack.org/p/watcher-tokyo-architecture-session

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

Re: [openstack-dev] [kolla] Integrating kollacli as python-kollaclient

[Ryan Hallisey]

+1

I think it's an excellent addition to kolla.
I think this should help tremendously with usability and building better docs 
around how to use kolla.

-Ryan

> On Oct 23, 2015, at 5:33 PM, Harm Weites  wrote:
> 
> +1 this sort of stuff makes live a lot better :)
> 
> Swapnil Kulkarni schreef op 2015-10-23 07:08:
>> On Thu, Oct 22, 2015 at 3:50 AM, Steven Dake (stdake)
>>  wrote:
>>> Hello Folks,
>>> Oracle has developed a CLI tool for managing OpenStack Kolla
>>> clusters.  Several months ago at our midcycle, the topic was
>>> brought up an I suggested to go ahead and get started on the work. 
>>> We clearly didn't spend enough time discussing how it should be
>>> integrated into the code base or developed or even what its features
>>> should be, and that is my error.
>>> What ended up happening is sort of a code dump, which is not ideal,
>>> but I can only work so many 20 hour days ;)  I didn't believe our
>>> community had the bandwidth to deal with integrating a CLI directly
>>> into the tree while we were focused on our major objective of
>>> implementing Ansible deployment of OpenStack in Docker containers. 
>>> Possibly the wrong call, but it is what it is and it is my error,
>>> not Oracles.
>> I think user experience will of the one of the major milestones for
>> Kolla in Mitaka, e.g. user facing documentation, operator integration
>> etc. a CLI would be helpful in that.
>>> The code can be cloned from:
>>> git clone git://oss.oracle.com/git/openstack-kollacli.git [1]
>>> The code as is is very high quality but will likely need to go
>>> through alot of refactoring to ReST-ify it.  There are two major
>>> authors of the code, Borne Mace and Steve Noyes.
>>> I'd like a majority vote from the core team as to whether we should
>>> add this repository to our list of governed repositories in the
>>> OpenStack Kolla governance repository here:
>> hub.com/openstack/governance/blob/master/reference/projects.yaml#L1509
>>> [2]
>>> Consider this email a +1 vote from me.
>> +1 from me 
>>> A completely separate email thread and decision will be made by the
>>> community about core team membership changes to handle maintenance
>>> of the code.  Assuming this code is voted into Kolla's governance,
>>> I plan to propose Borne as a core reviewer, which will be open to
>>> core team vote as a separate act with our 3 +1 votes no vetos within
>>> 1 week period.  We will address that assuming a majority vote of
>>> the code merge wins.  Steve can follow the normal processes for
>>> joining the core team if he wishes (reviewing patches) - clearly his
>>> code contributions are there.  Borne already does some reviews, and
>>> although he isn't a top reviewer, he does have some contribution in
>>> this area making it into the top 10 for the Liberty cycle.
>>>  
>>> Kolla CLI Features:
>>> * dynamic ansible inventory manipulation via the host, group and
>>> service commands
>>> * ssh key push via the host setup command
>>> * ssh key validation via the host check command
>>> * ansible deployment via the deploy command
>>> * property viewing and modification with the property list, set and
>>> clear commands
>>> * cleanup of docker containers on a single, multiple or all hosts
>>> via the host destroy command
>>> * debug data collection via the dump command
>>> * configuration of openstack passwords via the password command
>>> * Lines of python = 2700
>>> * Lines of  test case code =  1800
>>> * ~ 200 commits
>>   ___
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe [3]
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> [4]
>> Links:
>> --
>> [1] http://oss.oracle.com/git/openstack-kollacli.git
>> [2]
>> hub.com/openstack/governance/blob/master/reference/projects.yaml#L1509
>> [3] http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> [4] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>   ___
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [cross-project] [docs] Cross-Project Docs Session

[Lana Brindley]

Hi everybody,

Just a reminder that there is a cross-project workshop at 2pm today with a 
focus on the documentation project: 
http://mitakadesignsummit.sched.org/event/f81293c41ef787f53361e408d15caae4#.Vi7fumQrIy4

I’ve started up the etherpad for the session 
(https://etherpad.openstack.org/p/mitaka-cross-project-documentation-team). The 
main thing I want to make sure we discuss is packaging, especially in light of 
the Liberty Install Doc for RDO, but feel free to add your own suggestions for 
topics as well :)

See you then,
Lana

Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia





signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Neutron Social Meetup in Tokyo

[Korzeniewski, Artur]

Hi,
Please count me in also. I’ll be happy to meet with you folks!

Regards,
Artur

From: Sukhdev Kapur [mailto:sukhdevka...@gmail.com]
Sent: Tuesday, October 27, 2015 2:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Neutron Social Meetup in Tokyo

Hey Akihiro,

Thanks for arranging this. I did not see any link to RSVP.
I would love to attend this event - please add me to the list.

Thanks
-Sukhdev


On Fri, Oct 23, 2015 at 9:23 AM, Akihiro Motoki 
mailto:amot...@gmail.com>> wrote:
Hi Neutron folks,

We are pleased to announce Neutron social meet-up in Tokyo.
Thanks Takashi and Hirofumi for the big help.

I hope many of you will be there and enjoy the time.
If you have made RSVP, don't miss it!
We recommend  to join the beginning, but come and join us even if you
arrive late.



Thursday, Oct 29 19:00-22:00
Hokkaido (北海道 品川インターシティー店)

Location:
https://www.google.com/maps/d/edit?mid=zBFFkY6dvVno.kOTkyNjZ2oU0&usp=sharing
5th floor at the "shop and restaurant building" (between A and B buildings).
It is at the opposite side of JR Shinagawa Station from the Summit side.)

Approximately it costs ~5000 (Japanese) Yen depending on the number of
folks who join.
Note that we have no sponsors.

If you have any trouble in reaching there or some question, reach me
@ritchey98 on Twitter.



See you in Tokyo!
Akihiro

__
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] Liberty packages for openSUSE and SLES available

[Thomas Bechtold]

Hi,

I already announced the availability of the RC packages a couple of
weeks ago and I'm pleased to announce the availability of stable
Liberty packages for openSUSE and SLES!
The packages are available on build.opensuse.org in the
Cloud:OpenStack:Liberty project[1].

Updates to the stable/liberty branches for the different service are
automatically tracked and tested via Tempest before the updates move
into the Cloud:OpenStack:Liberty buildservice project.

If you find issues, please do not hesitate to report them to
opensuse-
cloud at opensuse.org or to https://bugzilla.opensuse.org/

Thanks !

Have a lot of fun,
Tom


__
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] [astara] contributor meetup during Mitaka summit

[Adam Gandelman]

Should we shoot for a contributor meetup Friday in the developer lounge,
alongside the other project meetups?  Does this *not* work for anyone?  Is
afternoon better than the AM?  I propose we meet before lunch and carry on
into the afternoon if necessary.  Please jot your name down on the etherpad
[1] with preferences, we should finalize this today so we dont double book
ourselves

Cheers
Adam

[1] https://etherpad.openstack.org/p/akanda-mitaka-planning
__
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] [cinder] about the cinder /volumes and /volumes/detail sort APIs

[chenying]

Thanks. Duncan. It is clear to me. We will plan to update our porject code 
using new sort API.

Best regard.chenying(IRC) ying.c...@huawei.com

Date: Mon, 26 Oct 2015 14:06:58 +0200
From: duncan.tho...@gmail.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [cinder] about the cinder /volumes and 
/volumes/detail sort APIs

The deprecated API will be removed in some future release, though the date for 
that is not know. It is not advised to code against a deprecated API for this 
reason, and any existing code that operates against a deprecated API should be 
updated where possible.
That said, the deprecated code in question is small and self contained, so if 
you are aware of any project(s) that make use of it, please let us know and we 
can try to avoid removing it until those projects are fixed up.
On 26 Oct 2015 11:15, "chenying"  wrote:



hi Folks
I find that the v2 /volumes and /volumes/detail sort API has been updated  
to support multiple sort keys and sort directions using the single 'sort' 
parameterin this patch[1]. But this patch still supported old API using 
'sort_key' and 'sort_dir' parameters which have been deprecated. We did not 
stop supporting the old API.So I want to know will the deprecated old sort 
APIs supporting code be deleted in the future? Or 'sort_key' and 'sort_dir' 
parameters will still be supported forever.
[1]https://review.openstack.org/#/c/141914/
Best regard.chenying(IRC) ying.c...@huawei.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

Re: [openstack-dev] [heat] Shared code between server and client

[Zane Bitter]

On 23/10/15 05:35, Robert Collins wrote:

My 2c - if its a stable API in the client, and can be kept stable,
there's no problem.


+1


-Rob

On 23 October 2015 at 08:49, Jay Dobies  wrote:

I'm working on moving the functionality for merging environments from the
client into the server [1]. I've only superficially looked at
template_utils.py (in heatclient) but I'm guessing there is stuff in there I
will want to use server-side.

The server has a requirement on heatclient, but I'm not sure what the
convention is for using code in it. Can I directly call into a module in
heatclient/common from the server or is the client dependency only intended
to be used through the client-facing APIs?

[1] https://blueprints.launchpad.net/heat/+spec/multi-environments

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







__
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] Neutron Social Meetup in Tokyo

[Sukhdev Kapur]

Hey Akihiro,

Thanks for arranging this. I did not see any link to RSVP.
I would love to attend this event - please add me to the list.

Thanks
-Sukhdev


On Fri, Oct 23, 2015 at 9:23 AM, Akihiro Motoki  wrote:

> Hi Neutron folks,
>
> We are pleased to announce Neutron social meet-up in Tokyo.
> Thanks Takashi and Hirofumi for the big help.
>
> I hope many of you will be there and enjoy the time.
> If you have made RSVP, don't miss it!
> We recommend  to join the beginning, but come and join us even if you
> arrive late.
>
> 
>
> Thursday, Oct 29 19:00-22:00
> Hokkaido (北海道 品川インターシティー店)
>
> Location:
>
> https://www.google.com/maps/d/edit?mid=zBFFkY6dvVno.kOTkyNjZ2oU0&usp=sharing
> 5th floor at the "shop and restaurant building" (between A and B
> buildings).
> It is at the opposite side of JR Shinagawa Station from the Summit side.)
>
> Approximately it costs ~5000 (Japanese) Yen depending on the number of
> folks who join.
> Note that we have no sponsors.
>
> If you have any trouble in reaching there or some question, reach me
> @ritchey98 on Twitter.
>
> 
>
> See you in Tokyo!
> Akihiro
>
> __
> 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] [Tempest] where fwaas tempest tests should be?

[Ihar Hrachyshka]

> On 24 Oct 2015, at 21:25, Doug Wiegley  wrote:
> 
> 
>> On Oct 19, 2015, at 5:33 PM, Ihar Hrachyshka  wrote:
>> 
>>> On 16 Oct 2015, at 10:50, Takashi Yamamoto  wrote:
>>> 
>>> if i move fwaas tests from neutron to neutron-fwaas, [1]
>>> is there easy way to run them together with the rest of neutron api tests
>>> for gate-neutron-dsvm-api job?
>> 
>> Before we jump in to reflect current gating status-quo, do we have a 
>> definite answer why we want to keep the gate coupling in place? Can’t we 
>> leave the fwaas api job for fwaas repo only? Do we think core is unstable 
>> enough to justify additional coupling? Is core bad at handling backwards 
>> compatibility when it comes to (re)moving code that is unneeded for the core 
>> repo?
> 
> Core is absolutely dreadful at backwards compatibility (I’m talking recent 
> history here.) The co-gate is necessary to guard against that at the moment.

Interesting. Any details? Is it just a matter of some dumb code move/rename, or 
is it something really architectural, like single API manager for all services?

I wonder what we may do to make the difference for eventual breakage of the 
tie. Should we start collecting post-mortem details on breakage cases to start 
understanding where we lag?

Ihar


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] HenryG addition to the Neutron Drivers team

[Sukhdev Kapur]

Hey Kevin,

It was always Henry's fault - now we can formally blame him :-):-)

Excellent move!! Well deserved addition!!!

Congratulations Henry!!!

-Sukhdev


On Tue, Oct 20, 2015 at 10:49 PM, Kevin Benton  wrote:

> Excellent addition! Remember everyone, if the feature you want doesn't
> make it into Neutron, it's now Henry's fault. :)
>
> On Tue, Oct 20, 2015 at 8:14 PM, Armando M.  wrote:
>
>> Hi folks,
>>
>> Henry has been instrumental in many areas of the projects and his crazy
>> working hours makes even Kevin and I bow in awe.
>>
>> Jokes aside, I would like to announce HenryG as a new member of the
>> Neutron Drivers team.
>>
>> Having a propension to attendance, and desire to review of RFEs puts you
>> on the right foot to join the group, whose members are rotated regularly so
>> that everyone is given the opportunity to grow, and no-one burns out.
>>
>> The team [1] meets regularly on Tuesdays [2], and anyone is welcome to
>> attend.
>>
>> Please, join me in welcome Henry to the team.
>>
>> Cheers,
>> Armando
>>
>> [1]
>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
>> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
>>
>>
>> __
>> 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
>>
>>
>
>
> --
> Kevin Benton
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack 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] [NFV][Telco] Etherpad for 2 PM Tuesday working session @ OpenStack Summit

[Steve Gordon]

Hi all,

As you may or may not know we have a 40 minute working session today at 2 PM at 
OpenStack Summit in Sakura N-1 and N-2. I have created an etherpad for the 
session here:

https://etherpad.openstack.org/p/TYO-telcowg

Please add use cases or projects you would like to propose to try and form a 
group on and discuss once we are in the room - I have already added those for 
which we have existing proposals in gerrit. OPNFV members are welcome to come 
and discuss their projects and/or use cases in these breakouts as well, space 
permitting.

Thanks!

-Steve

__
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] Migration state machine proposal.

[Jay Pipes]

On 10/22/2015 11:13 AM, Tang Chen wrote:

On 10/22/2015 05:17 AM, Joshua Harlow wrote:

Overall I'm very much inclined to have three state machines (one
for each type), vs the mix-mash of all three into one state machine
(which causes the confusion around states in the first diagram in
that paste).


That is an idea. But I would prefer to have one single state machine
for migration, because resize and evacuate are reusing migration.
They can be in one state machine.


Evacuate does *not* migrate/move anything. Evacuate *rebuilds* VMs from 
their original source image.


I support Nikola in that I believe the different migration types should 
have different state machines entirely (but be as consistent as possible 
in the naming of terminal states like "finished" vs "done" etc)



It would be very helpful if the designer of the migration process
could share his idea. But if it is just some code modified by many
people many times, I think we should remove the confusing states and
give a easier, better state machine.


There isn't a designer of the migration process :( The original (crap, 
IMHO) API from Rackspace Cloud Servers API was used for the resize 
functionality in the compute API and it's been a source of confusion and 
frustration ever since. Relying on a manual confirmation or revert input 
from the user was and continues to be a horrible idea.


I believe strongly that we should deprecate the existing migrate, 
resize, an live-migrate APIs in favor of a single consolidated, 
consistent "move" REST API that would have the following characteristics:


* No manual or wait-input states in any FSM graph
* Removal of the term "resize" from the API entirely (the target 
resource sizing is an attribute of the move operation, not a different 
type of API operation in and of itself)
* Transition to a task-based API for poll-state requests. This means 
that in order for a caller to determine the state of a VM the caller 
would call something like GET /servers//tasks/ in order to 
see the history of state changes or subtask operations for a particular 
request to move a VM


Timofei Durakov (cc'd) has a blueprint for splitting the live-migration 
types into separate task classes here:


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

I think there's a lot of good ideas in that proposal. Please do have a 
look at it.


Best,
-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] [Nova][Manila] Nova API to attach/detach file volume/share

[Ben Swartzlander]

On 10/25/2015 01:25 PM, Sage Weil wrote:

Hi everyone,

We're currently working on an improved mechanism for plumbing file access
into a VM or container and in most cases some interaction and
configuration on the hypervisor/host is required to make it happen.  The
goal is to create something that generalizes beyond the current NFS and
CIFS-only assumptions that are baked into the current crop of Manila
drivers.

The current target is to use the new VSOCK zero-configuration sockets,
which I will be talking about at the summit on Wednesday:

  - mount distributed fs on host, export via knfsd to guest over VSOCK
  - run Ganesha with distributed fs FSAL on host, export to guest over VSOCK


NFS-over-vsock is a VERY interesting idea. I understood that it wasn't 
implemented yet in Linux... If that's no longer true then I'm excited to 
find a way to make it work.



(In short, VSOCK requires no configuration on the guest--so we can
continue to treat it as a black box--and only a simple network id
assignment on the host.  This reduces driver complexity, reduces the
potential for user error, and improves security.)

Or, the same can be done using a more configuration-intensive private
network:

  - mount distributed fs on host, export via knfsd to guest over private
host/guest network
  - run ganesha with distributed fs FSAL on host, export to guest over
private host/guest network

We are also interested in container use-cases (e.g., for Nova-managed
containers using lxc or nova-docker):

  - mount distributed fs on host, bind mount a volume/directory into the
guest/container namespace

 From a plumbing perspective, these approaches appear to be the most
attractive as far as efficiency and security.  When it comes to making
openstack actually orchestrate it, however, things get complicated (and
as a developer in a peripheral project I don't have the clearest view of
how things should work).

The problem is that in any of these scenarios, the default/naive strategy
of having Manila go poking around on the host machine is very fragile:

  - What if the host is down when the Manila configuration is made?
  - What if the VM is migrated to another host?
  - What if Manila doesn't understand what (the) Nova (driver) is doing?

For block volumes, there is a simple separation of roles: Cinder manages
the volumes themselves, and Nova attaches them to guests.  This means
there is some volume-related code in Nova, but it also means that that
code is running in a context where it can Do The Right Thing.  I believe
the same is true of Manila file volumes as well... as soon as
you look beyond the current assumption that all volumes must be
reached via a network file protocol (and usually a Neutron
network).

That is, we would love to see a new set of Nova APIs to attach and detach
a manila fs to the guest, along with a "get share info" call that returns
any details required for the user/tenant to do the final mount within the
guest.

This enables our new topologies:

  - Attach API might mount CephFS on the host and exportfs it over VSOCK to
the guest VM.  Get-info API would direct the user to mount -t nfs vsock:1/
with -o nfsvers=4.1,proto=vsock,clientaddr=N ..
  - Attach API might configure/start a Ganesha instance doing the same
  - Attach API might mount CephFS on the host and then mount --bind the
share to $guestroot/dev/manila/$shareid.  Get-info API would direct the
user to mount --bind /dev/manila/$shareid.

I suspect it would also clean up some existing Manila topologies (though
I'm not sure).  For example, the current the NFS-based Manila drivers will
help you configure a Neutron net that can access the storage server.  The
attach API might attach the guest to that same network.  (Maybe.. I'm
super fuzzy on how this stuff works!)

What do people (especially the Nova folks) think about this?  I would love
sit down with anyone to talk about this this week in Tokyo on either/both
the Nova and Manila side of the picture.

Thanks!
sage

__
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] [Manila] Share allow/deny by shared secret

[Ben Swartzlander]

On 10/21/2015 06:36 AM, John Spray wrote:

Hi,

(I wanted to put this in an email ahead of Tokyo, where I hope we'll
find time to discuss it.  This is a follow up to
http://osdir.com/ml/openstack-dev/2015-10/msg00381.html)

With the current code, there doesn't appear to be a proper way to
expose Ceph's native authentication system via Manila.  This is
because Ceph generates the shared secret needed to access a share, and
Manila doesn't give us a path to expose such a driver-originated
secret as part of a ShareInstanceMapping.

The NFS-style process that Manila expects is:
Caller> I know a credential (IP address, x509 certificate) and I want
you to authorize it
Driver> OK, I have stored that credential and you can now use it to
access the share.


This is accurate. Manila presumes the existence of an external 
authentication mechanism which servers can use to identify clients, so 
that Manila's role can be limited to telling the server which clients 
should have access.



The Ceph native process is more like:
Caller> I want to access this share
Driver> OK, I have generated a credential for you, here it is, you can
now use it to access the share

The important distinction is where the credential comes from.  Manila
expects it to come from the caller, Ceph expects to generate it for
the caller.


The problem with the above statement is that you don't define who "I" 
am. The Manila API client is all-powerful when it comes to modifying 
access rules, insofar as a tenant has the power to add/remove any rule 
from any share that that tenant owns. Obviously if  you have access to 
modify the access rules then you have de-facto access to all the shares. 
The purpose of the access-allow/deny APIs is to delegate access to 
shares to identities that exist outside of Manila, such as to IP 
addresses, to users, or to x509 principles. These things need to be 
named somehow so that the file system server, the client, and manila can 
all talk about the same set of identities.



To enable us to expose ceph native auth, I propose:
  * Add a "key" column to the ShareAccessMapping model
  * Enable drivers to optionally populate this from allow() methods
  * Expose this to API consumers: right to see a share mapping is the
right to see the key.

The security model is that the key is a secret, which Manila API users
(i.e. administrative functions) are allowed to see, and it is up to
them to selectively share the secret with guests.  The reason for
giving them allow/deny rather than just having a key per share is so
that the administrator can selectively revoke keys.


I don't see why the driver should be the place where secrets are 
generated. It seems equally valid for the caller of the Manila API to 
generate the secret himself, and to ask Manila to grant access to a 
share to anyone knowing that secret. This would fit the existing model, 
and more importantly, it would allow granting of shares to multiple 
users with different secrets. I don't see in the above proposal how to 
grant access to a share to both Alice and Bob without telling the same 
secret to both Alice and Bob. The problem that creates is that I can't 
revoke access to the share from Alice without also revoking access from 
Bob. Maybe I'm misreading what you wrote above about key revocation, but 
it sounds like you have 1 key per share, and you can revoke access to 
each share individually, but if you have multiple users you cannot 
distinguish between them.



The "key" column should be pretty short (255 chars is plenty) -- this
isn't meant for storing big things like PKI certificates, it's
specifically for shared secrets.

I don't know of any other drivers that would use this, but it is a
pretty generic concept in itself: "grant access by a shared key that
the storage system generates".


I'm not opposed to the idea of modifying the Manila API to make your use 
case possible, but I want to make sure there's not a better way to solve 
the problem first, and I also want to make sure that the we're solving 
the problem in the right way. Supporting multiple users accessing 
multiple shares is an important use case and I'm not clear on how this 
proposal addresses that.



Cheers,
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 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] vmware-nsx and multiple TZs

[Liz]

We are trying to use a single management cluster to support compute
clusters in multiple security zones (to reduce operational overhead).
Ideally we could use multiple transport zones so that we can't spin up a VM
in security zone A on a compute cluster in security zone B.

Has anyone run into this issue and had any luck in hacking nsx.ini to
support multiple vdn_scope_ids? I couldn't find any proposed changes that
would resolve this (but maybe I'm missing it).

It seems like an alternate way to "filter" this would be use a host
aggregate, but it seems a little convoluted to do it that way...

Thanks in advance!
Liz
__
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] [openstack-ansible][security] Creating a CA for openstack-ansible deployments?

[Major Hayden]

Hello there,

I've been researching some additional ways to secure openstack-ansible 
deployments and I backed myself into a corner with secure log transport.  The 
rsyslog client requires a trusted CA certificate to be able to send encrypted 
logs to rsyslog servers.  That's not a problem if users bring their own 
certificates, but it does become a problem if we use the self-signed 
certificates that we're creating within the various roles.

I'm wondering if we could create a role that creates a CA on the deployment 
host and then uses that CA to issue certificates for various services *if* a 
user doesn't specify that they want to bring their own certificates.  We could 
build the CA very early in the installation process and then use it to sign 
certificates for each individual service.  That would allow to have some 
additional trust in environments where deployers don't choose to bring their 
own certificates.

Does this approach make sense?

--
Major Hayden

__
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] [bandit] [glance] [openstack-ansible] [searchlight] Resigning from core reviewers teams

[Ian Cordasco]

Apologies for whatever happened with the formatting the first time I sent
this. I've tried to ensure that doesn't happen again:

Hi everyone,

Today I'm removing myself from the core reviewer (and driver) teams for
the 
following projects:

- Bandit
- Glance
- OpenStack Ansible
- Searchlight

Recent events both in my position at Rackspace and my personal life mean I
no 
longer have sufficient time to properly act as a core reviewer for these
projects. My personal life has suffered from attempts to continue to
uphold my 
responsibilities to OpenStack and the other open source projects I
develop, 
maintain, and direct. Changing responsibilities in my current role in the
last 
8-10 months mean that I don't have sufficient time during the normal
0900-1700 
period to accurately and thoroughly conduct reviews. I'm confident this is
only a temporary hiatus and that sometime next year, I will be able to
fully 
rejoin the OpenStack community.

If you have questions, concerns or serious objections, I'd be happy to
answer
them off the mailing list.

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

[openstack-dev] [bandit] [glance] [openstack-ansible] [searchlight] Resigning from core reviewers teams

[Ian Cordasco]

Hi everyone,

  
  


  
  

Today I'm removing myself from the core reviewer (and driver)
teams for the 
  
  

following projects:

  
  


  
  

- Bandit (bandit-core and transitively security-specs-core)
  
  

- Glance (glance-core and glance-specs-core)
  
  

- OpenStack Ansible (openstack-ansible-core)
  
  

- Searchlight (searchlight-core)

  
  


  
  

Recent events both in my position at Rackspace and my personal
life mean I no 
  
  

longer have sufficient time to properly act as a core reviewer for
these 
  
  

projects. My personal life has suffered from attempts to continue
to uphold my 
  
  

responsibilities to OpenStack and the other open source projects I
develop, 
  
  

maintain, and direct. Changing responsibilities in my current role
in the last 
  
  

8-10 months mean that I don't have sufficient time during the
normal 0900-1700 
  
  

period to accurately and thoroughly conduct reviews. I'm confident
this is 
  
  

only a temporary hiatus and that sometime next year, I will be
able to fully 
  
  

rejoin the OpenStack community.

  
  


  
  

If you have questions, concerns or serious objections, I'd be
happy to answer
  
  

them off the mailing list.

  
  


  
  

Cheers,
  
  

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] [Fuel] fuelmenu code freeze

[Vladimir Kozhukalov]

Dear colleagues,

I am glad to announce that fuel-web/fuelmenu directory has been deprecated.
Since now fuel-menu is a separate project.

Fuel-menu

   - Launchpad bug https://bugs.launchpad.net/fuel/+bug/1506885
   - project-config patch https://review.openstack.org/#/c/235177 (DONE)
   - pypi (DONE)
   - run_tests.sh https://review.openstack.org/#/c/235243/ (DONE)
   - rpm/deb specs https://review.openstack.org/#/c/235273/ (DONE)
   - fuel-ci verification jobs https://review.fuel-infra.org/12865 (DONE)
   - label jenkins slaves for verification (DONE)
   - directory freeze (DONE)
   - prepare upstream (DONE)
   - waiting for project-config patch to be merged (DONE)
   - .gitreview https://review.openstack.org/#/c/238434/ (DONE)
   - .gitignore https://review.openstack.org/238528 (DONE)
   - custom jobs parameters https://review.fuel-infra.org/13088 (DONE)
   - fix core group (DONE)
   - fuel-main https://review.openstack.org/#/c/238459/ (DONE)
   - packaging-ci https://review.fuel-infra.org/13181 (DONE)
   - MAINTAINERS https://review.openstack.org/238976 (DONE)
   - deprecate fuelmenu directory https://review.openstack.org/#/c/238972/
   (DONE)
   - remove old fuelmenu package (DONE???)




Vladimir Kozhukalov

On Fri, Oct 23, 2015 at 7:06 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> I'd like to update the status of the activity (moving fuelmenu to a
> separate repo).
>
>
>- Launchpad bug https://bugs.launchpad.net/fuel/+bug/1506885
>- project-config patch https://review.openstack.org/#/c/235177 (DONE)
>- pypi (DONE)
>- run_tests.sh https://review.openstack.org/#/c/235243/ (DONE)
>- rpm/deb specs https://review.openstack.org/#/c/235273/ (DONE)
>- fuel-ci verification jobs https://review.fuel-infra.org/12865 (DONE)
>- label jenkins slaves for verification (TODO CI-team)
>- directory freeze (DONE)
>- prepare upstream (DONE)
>- waiting for project-config patch to be merged (DONE)
>- .gitreview https://review.openstack.org/#/c/238434/ (DONE)
>- .gitignore https://review.openstack.org/238528 (ON REVIEW)
>- custom jobs parameters https://review.fuel-infra.org/13088 (ON
>REVIEW)
>- fix core group (DONE)
>- fuel-main https://review.openstack.org/#/c/238459/ (ON REVIEW)
>- packaging-ci (TODO)
>- MAINTAINERS https://review.openstack.org/238976 (ON REVIEW)
>- deprecate fuelmenu directory https://review.openstack.org/#/c/238972/
>(ON REVIEW)
>
> There are still some patches on review that you can help to get merged.
>
>
> Vladimir Kozhukalov
>
> On Tue, Oct 20, 2015 at 7:05 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Igor,
>>
>> Thank you for your help. I'd say ETA is today/tomorrow and depends on how
>> quickly this project-config patch [1] will be reviewed and merged. I'll ask
>> openstack-infra guys to do this ASAP.
>>
>> [1] https://review.openstack.org/#/c/235177
>>
>> Vladimir Kozhukalov
>>
>> On Tue, Oct 20, 2015 at 6:39 PM, Igor Kalnitsky 
>> wrote:
>>
>>> Hey Vladimir,
>>>
>>> That's awesome news. I blocked all fuelmenu patches [1] with a link to
>>> this thread. So don't worry, we won't merge them accidentally.
>>>
>>> BTW, could you provide any ETA when moving will be done?
>>>
>>> [1]
>>> https://review.openstack.org/#/q/project:openstack/fuel-web+file:%255Efuelmenu.*+status:open,n,z
>>>
>>> Thanks,
>>> Igor
>>>
>>> On Tue, Oct 20, 2015 at 5:58 PM, Vladimir Kozhukalov
>>>  wrote:
>>> > Dear colleagues,
>>> >
>>> > As you might know I'm working on splitting multiproject fuel-web
>>> repository
>>> > into several sub-projects. Fuelmenu is one of directories that are to
>>> be
>>> > moved to a separate git project.
>>> >
>>> > Checklist for this to happen is as follows:
>>> >
>>> > Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1506885
>>> > project-config patch https://review.openstack.org/#/c/235177 (ON
>>> REVIEW
>>> > WORKFLOW -1)
>>> > pypi project
>>> https://pypi.python.org/pypi?%3Aaction=pkg_edit&name=Fuel-menu
>>> > (DONE)
>>> > run_tests.sh https://review.openstack.org/#/c/235243/ (DONE)
>>> > rpm/deb specs https://review.openstack.org/#/c/235273/ (DONE)
>>> > fuel-ci verification jobs https://review.fuel-infra.org/12865 (ON
>>> REVIEW)
>>> > label jenkins slaves for verification jobs (ci team)
>>> > directory freeze (WE ARE HERE)
>>> > prepare upstream (TODO)
>>> > project-config (ON REVIEW)
>>> > fuel-main patch (TODO)
>>> > packaging-ci patch (TODO)
>>> > deprecate fuel-web/fuelmenu directory (TODO)
>>> >
>>> > Now we are at the point where we need to freeze fuel-web/fuelmenu
>>> directory.
>>> > So, I'd like to announce code freeze for this directory and all
>>> patches that
>>> > make changes in the directory and are currently on review will need to
>>> be
>>> > backported to the new git repository.
>>> >
>>> >
>>> > Vladimir Kozhukalov
>>> >
>>> >
>>> __
>>> > OpenStack Develop

Re: [openstack-dev] [magnum][kolla] Stepping down as a Magnum core reviewer

[Baohua Yang]

Really a pity!

We need more resources on the container part in OpenStack indeed, as so
many new projects are just initiated.

Community is not only about putting technologies together, but also putting
technical guys together.

Happy to see so many guys in the Tokyo Summit this afternoon.

Let's take care of the opportunities to make good communications with each
other.

On Mon, Oct 26, 2015 at 8:17 AM, Steven Dake (stdake) 
wrote:

> Hey folks,
>
> It is with sadness that I find myself under the situation to have to write
> this message.  I have the privilege of being involved in two of the most
> successful and growing projects (Magnum, Kolla) in OpenStack.  I chose
> getting involved in two major initiatives on purpose, to see if I could do
> the job; to see if  I could deliver two major initiatives at the same
> time.  I also wanted it to be a length of time that was significant – 1+
> year.  I found indeed I was able to deliver both Magnum and Kolla, however,
> the impact on my personal life has not been ideal.
>
> The Magnum engineering team is truly a world class example of how an Open
> Source project should be constructed and organized.  I hope some young
> academic writes a case study on it some day but until then, my gratitude to
> the Magnum core reviewer team is warranted by the level of  their sheer
> commitment.
>
> I am officially focusing all of my energy on Kolla going forward.  The
> Kolla core team elected me as PTL (or more accurately didn’t elect anyone
> else;) and I really want to be effective for them, especially in what I
> feel is Kolla’s most critical phase of growth.
>
> I will continue to fight  for engineering resources for Magnum internally
> in Cisco.  Some of these have born fruit already including the Heat
> resources, the Horizon plugin, and of course the Networking plugin system.
> I will also continue to support Magnum from a resources POV where I can do
> so (like the fedora image storage for example).  What I won’t be doing is
> reviewing Magnum code (serving as a gate), or likely making much technical
> contribution to Magnum in the future.  On the plus side I’ve replaced
> myself with many many more engineers from Cisco who should be much more
> productive combined then I could have been alone ;)
>
> Just to be clear, I am not abandoning Magnum because I dislike the people
> or the technology.  I think the people are fantastic! And the technology –
> well I helped design the entire architecture!  I am letting Magnum grow up
> without me as I have other children that need more direct attention.  I
> think this viewpoint shows trust in the core reviewer team, but feel free
> to make your own judgements ;)
>
> Finally I want to thank Perry Myers for influencing me to excel at
> multiple disciplines at once.  Without Perry as a role model, Magnum may
> have never happened (or would certainly be much different then it is
> today). Being a solid hybrid engineer has a long ramp up time and is really
> difficult, but also very rewarding.  The community has Perry to blame for
> that ;)
>
> Regards
> -steve
>
> __
> 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 wishes!
Baohua
__
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] Not able to launch based VM due to nova-network service.

[Matt Riedemann]

On 10/24/2015 10:26 AM, Rahul Arora wrote:

Hi Team,

I am working on ICEHOUSE release of Openstack.*I am able to launch VM
using KVM/QEMU utility.*

Now i *want to launch LXC based VM* using the same release.

But I am getting below error while launching LXC based VM.These errors
are in *nova-neutron service.*

self._get_networks_by_uuids(context, network_uuids)\n', '  File
"/usr/lib/python2.7/site-packages/nova/network/manager.py", line 1824,
in _get_networks_by_uuids\ncontext, network_uuids,
project_only=True)\n', '  File
"/usr/lib/python2.7/site-packages/nova/objects/base.py", line 110, in
wrapper\nargs, kwargs)\n', '  File
"/usr/lib/python2.7/site-packages/nova/conductor/rpcapi.py", line 425,
in object_class_action\nobjver=objver, args=args, kwargs=kwargs)\n',
'  File "/usr/lib/python2.7/site-packages/oslo/messaging/rpc/client.py",
line 150, in call\nwait_for_reply=True, timeout=timeout)\n', '  File
"/usr/lib/python2.7/site-packages/oslo/messaging/transport.py", line 90,
in _send\ntimeout=timeout)\n', '  File
"/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py", line
412, in send\nreturn self._send(target, ctxt, message,
wait_for_reply, timeout)\n', '  File
"/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py", line
405, in _send\nraise result\n', 'NoNetworksFound_Remote: No networks
defined.\nTraceback (most recent call last):\n\n  File
"/usr/lib/python2.7/site-packages/nova/conductor/manager.py", line 597,
in _object_dispatch\nreturn getattr(target, method)(context, *args,
**kwargs)\n\n  File
"/usr/lib/python2.7/site-packages/nova/objects/base.py", line 112, in
wrapper\nresult = fn(cls, context, *args, **kwargs)\n\n  File
"/usr/lib/python2.7/site-packages/nova/objects/network.py", line 183, in
get_by_uuids\nproject_only)\n\n  File
"/usr/lib/python2.7/site-packages/nova/db/api.py", line 965, in
network_get_all_by_uuids\nproject_only=project_only)\n\n  File
"/usr/lib/python2.7/site-packages/nova/db/sqlalchemy/api.py", line 164,
in wrapper\nreturn f(*args, **kwargs)\n\n  File
"/usr/lib/python2.7/site-packages/nova/db/sqlalchemy/api.py", line 2582,
in network_get_all_by_uuids\n   raise
exception.NoNetworksFound()\n\nNoNetworksFound: No networks defined.\n\n']

*Details of error.*
=

When i am creating network for the LXC VM.I am able to see the same
network using *neutron net-list* command,But i think this same network
nova is not able to access that's why i do *nova net-list* it shows
nothing(no network).Due to this,above error is coming.

Below are my nova and neutron configuration files.

*1. NOVA CONF*

[DEFAULT]
firewall_driver = nova.virt.firewall.NoopFirewallDriver
compute_driver = libvirt.LibvirtDriver
libvirt_cpu_mode = host-model
default_floating_pool = public
fixed_range =
force_dhcp_release = True
dhcpbridge_flagfile = /etc/nova/nova.conf
compute_scheduler_driver = nova.scheduler.filter_scheduler.FilterScheduler
rootwrap_config = /etc/nova/rootwrap.conf
api_paste_config = /etc/nova/api-paste.ini
allow_resize_to_same_host = true
auth_strategy = keystone
instances_path = /etc/nova/instances
debug = False
verbose = True
my_ip = 192.168.2.99
glance_host = 192.168.2.99
lock_path = /var/lock/nova/
libvirt_images_type = default

[libvirt]
virt_type = lxc


vnc_enabled = False
vncserver_listen =
novncproxy_base_url = http://:6080/vnc_auto.html
vncserver_proxyclient_address =

flat_interface = eth0
flat_network_bridge = br1
vlan_interface = eth0
public_interface = br1
network_manager = nova.network.manager.FlatDHCPManager
fixed_range =
force_dhcp_release = False
dhcpbridge = /usr/bin/nova-dhcpbridge

sql_connection = mysql://nova:NOVA_DBPASS@192.168.2.99/nova


rpc_backend = rabbit
rabbit_host = 192.168.2.99
rabbit_port = 5672

neutron_url = http://192.168.2.99:9696
network_api_class = nova.network.neutronv2.api.API
security_group_api = neutron
neutron_auth_strategy = keystone
neutron_admin_tenant_name = service
neutron_admin_username = neutron
neutron_admin_password = NEUTRON_PASS
neutron_admin_auth_url = http://192.168.2.99:35357/v2.0/
linuxnet_interface_driver = nova.network.NoopFirewallDriver

vif_plugging_timeout = 10
vif_plugging_is_fatal = False

instance_usage_audit=True
instance_usage_audit_period = hour
notify_on_state_change = vm_and_task_state
notification_driver = nova.openstack.common.notifier.rpc_notifier

libvirt_images_rbd_pool = cinder-volumes
libvirt_images_rbd_ceph_conf = /etc/ceph/ceph.conf
rbd_user = cinder-volume

service_neutron_metadata_proxy = true
neutron_metadata_proxy_shared_secret = ADMIN_PASS

[spice]
agent_enabled = True
enabled = True
html5proxy_base_url = http://:6082/spice_auto.html
keymap = en-us
server_listen =
server_proxyclient_address =

auth_strategy = keystone

[keystone_authtoken]
auth_uri = http://192.168.2.99:5000
auth_host = 192.168.2.99
auth_port = 35357
auth_protocol = http
admin_tenant_name = service
admin_use

[openstack-dev] [Senlin] Design summit meetup proposed schedule

[Qiming Teng]

Hi,

After consulting with ttx, we still cannot find a meeting room for a
meetup for Senlin developers. However, we can grab a table in the Prince
room on Friday morning, as suggested by ttx.

Location: Prince Room
Time: 09:00am - 12:00am

So, team, let's get tuned for a fruitful discussion. Topics to be
discussed include, but not limited to:

- API consistency
- Health management and engine stabilization
- Webhook v.s. Receiver
- Heat resource type support
- Engine housekeeping jobs

We will use the following etherpad for discussion:

https://etherpad.openstack.org/p/senlin-mitaka-meetup

Looking forward to meet you there!

Regards,
 Qiming


__
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] [Fuel] Bugs status for ui, python and library. And 'area-*' tags.

[Dmitry Pyzhov]

Vitaly,

because first goal is to make clear separation for bugs ownership.
'area-python' means 'this bug is tracked in python team statistics and it's
python leads job to push it forward'. You can use any other tags you want
to track ui-related bugs. Just don't use 'area-' prefix for that.

I've created a wiki page for tags explanation. Feel free to add tags that
are in use in your teams: https://wiki.openstack.org/wiki/Fuel/Bug_tags

On Fri, Oct 23, 2015 at 12:44 PM, Vitaly Kramskikh 
wrote:

> Dmitry,
>
> 2015-10-22 21:42 GMT+07:00 Dmitry Pyzhov :
>
>> Guys,
>>
>> 1) Bugs status
>>
>> Here is our current stats. Again I’ll show it in format “total (UI /
>> python / library)"
>>
>> Critical and high bugs: 52 (6/28/18). Last week it was 46 (1/23/22)
>> Medium, low and wishlist bugs: 196 (41/112/43). Last week it was 193
>> (47/104/42)
>> Features tracked as bug reports: 143. Last week we had 136. 111 are
>> marked with ‘feature’ tag and 32 covered by blueprints. Last week it was
>> 143 in total, 105 with 'feature' tag and 31 covered by blueprints.
>> Technical debt bugs: 106 (2/80/24). Last week it was 101 (1/77/23) in
>> total. Kinda huge and growing number. We’ve marked some of tech-debt bugs
>> as High because we think them pretty important. There are 10 (0/6/4). Last
>> week we had 9 (0/6/3)
>>
>> Not so inspiring numbers this week. We work hard both on fixing and
>> reporting new bugs. It is about 15 new high priority defects reported every
>> week. This is why second topic of my e-mail is important.
>>
>> 2) Area tags
>> I'm analysing what's going on with our bugs and Launchpad is awful tool
>> for bugs management. I've added new 'area' tags to all bugs in 8.0
>> milestone. You probably know it from Launchpad e-mail reports (:smile:).
>> I've tried to be as accurate as possible. We need these tags in order to
>> measure our bugs status precisely. I hope we will add these tags to our
>> triage process next week. Now you can try to use these tags and give some
>> feedback if the idea is useful or not. Later we'll work on making following
>> filters reliable.
>>
>> Python bugs: all
>> 
>> /open
>> 
>> (area-python tag)
>> Library bugs: all
>> 
>> /open
>> 
>> (area-library tag)
>> UI bugs: all
>> 
>> /open
>> 
>> (area-ui tag)
>> Octane bugs: all
>> 

Re: [openstack-dev] [magnum][kolla] Stepping down as a Magnum core reviewer

[Kai Qiang Wu]

Hi Stdake,

You really did a fantastic  job on Magnum, and your bright ideas and
thoughts help Magnum to grow. It was sad to hear your stepping down from
Magnum Core at the first time, However, after read your messages from
heart,  I think  you are following your heart. I will wish you new success
on more areas(include Kolla and many new coming projects :).



I want to think you for your help on me while in Magnum.  Thanks very
much :)


Wish you bigger and more bright future ! Looking forward to receive your
any thoughts on Magnum.



Thanks


Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193

Follow your heart. You are miracle!



From:   "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   26/10/2015 09:22 am
Subject:[openstack-dev] [magnum][kolla] Stepping down as a Magnum core
reviewer



Hey folks,

It is with sadness that I find myself under the situation to have to write
this message.  I have the privilege of being involved in two of the most
successful and growing projects (Magnum, Kolla) in OpenStack.  I chose
getting involved in two major initiatives on purpose, to see if I could do
the job; to see if  I could deliver two major initiatives at the same time.
I also wanted it to be a length of time that was significant �C 1+ year.  I
found indeed I was able to deliver both Magnum and Kolla, however, the
impact on my personal life has not been ideal.

The Magnum engineering team is truly a world class example of how an Open
Source project should be constructed and organized.  I hope some young
academic writes a case study on it some day but until then, my gratitude to
the Magnum core reviewer team is warranted by the level of  their sheer
commitment.

I am officially focusing all of my energy on Kolla going forward.  The
Kolla core team elected me as PTL (or more accurately didn’t elect anyone
else;) and I really want to be effective for them, especially in what I
feel is Kolla’s most critical phase of growth.

I will continue to fight  for engineering resources for Magnum internally
in Cisco.  Some of these have born fruit already including the Heat
resources, the Horizon plugin, and of course the Networking plugin system.
I will also continue to support Magnum from a resources POV where I can do
so (like the fedora image storage for example).  What I won’t be doing is
reviewing Magnum code (serving as a gate), or likely making much technical
contribution to Magnum in the future.  On the plus side I’ve replaced
myself with many many more engineers from Cisco who should be much more
productive combined then I could have been alone ;)

Just to be clear, I am not abandoning Magnum because I dislike the people
or the technology.  I think the people are fantastic! And the technology �C
well I helped design the entire architecture!  I am letting Magnum grow up
without me as I have other children that need more direct attention.  I
think this viewpoint shows trust in the core reviewer team, but feel free
to make your own judgements ;)

Finally I want to thank Perry Myers for influencing me to excel at multiple
disciplines at once.  Without Perry as a role model, Magnum may have never
happened (or would certainly be much different then it is today). Being a
solid hybrid engineer has a long ramp up time and is really difficult, but
also very rewarding.  The community has Perry to blame for that ;)

Regards
-steve
__
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] [magnum][kolla] Stepping down as a Magnum corereviewer

[Ton Ngo]

Hi Steve,
 It will certainly be a loss to not have your constant presence for
guidance.  Your sensible approach to solving hard problems has many times
given clarity to the solution.  I am sure many in the team takes you as a
role model, so I think from time to time we will likely approach you for
ideas.
Ton,



From:   "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   10/25/2015 05:22 PM
Subject:[openstack-dev] [magnum][kolla] Stepping down as a Magnum core
reviewer



Hey folks,

It is with sadness that I find myself under the situation to have to write
this message.  I have the privilege of being involved in two of the most
successful and growing projects (Magnum, Kolla) in OpenStack.  I chose
getting involved in two major initiatives on purpose, to see if I could do
the job; to see if  I could deliver two major initiatives at the same time.
I also wanted it to be a length of time that was significant – 1+ year.  I
found indeed I was able to deliver both Magnum and Kolla, however, the
impact on my personal life has not been ideal.

The Magnum engineering team is truly a world class example of how an Open
Source project should be constructed and organized.  I hope some young
academic writes a case study on it some day but until then, my gratitude to
the Magnum core reviewer team is warranted by the level of  their sheer
commitment.

I am officially focusing all of my energy on Kolla going forward.  The
Kolla core team elected me as PTL (or more accurately didn’t elect anyone
else;) and I really want to be effective for them, especially in what I
feel is Kolla’s most critical phase of growth.

I will continue to fight  for engineering resources for Magnum internally
in Cisco.  Some of these have born fruit already including the Heat
resources, the Horizon plugin, and of course the Networking plugin system.
I will also continue to support Magnum from a resources POV where I can do
so (like the fedora image storage for example).  What I won’t be doing is
reviewing Magnum code (serving as a gate), or likely making much technical
contribution to Magnum in the future.  On the plus side I’ve replaced
myself with many many more engineers from Cisco who should be much more
productive combined then I could have been alone ;)

Just to be clear, I am not abandoning Magnum because I dislike the people
or the technology.  I think the people are fantastic! And the technology –
well I helped design the entire architecture!  I am letting Magnum grow up
without me as I have other children that need more direct attention.  I
think this viewpoint shows trust in the core reviewer team, but feel free
to make your own judgements ;)

Finally I want to thank Perry Myers for influencing me to excel at multiple
disciplines at once.  Without Perry as a role model, Magnum may have never
happened (or would certainly be much different then it is today). Being a
solid hybrid engineer has a long ramp up time and is really difficult, but
also very rewarding.  The community has Perry to blame for that ;)

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

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

Re: [openstack-dev] [keystone] [nova] [cinder] Mitaka summit working session: Resource Federation for an Open Cloud

[George Silvis, III]

On 10/26/2015 02:36 PM, Sean McGinnis wrote:
> On Fri, Oct 23, 2015 at 03:52:51PM -0400, George Silvis, III wrote:
>> On 10/22/2015 02:13 PM, Iury Gregory wrote:
>>> Hi George, can you say day and hour for this working session? Thanks
>>
>> I'll present this at:
>>
>> https://mitakadesignsummit.sched.org/event/93adfa1e5a023bc37c4de0bf2a999862
>>
>> Tuesday, October 27, 5:30-6:10 PM.
>>
>> -George
>>
> 
> 
> Hey George,
> 
> Is this still the planned time for this session? That is the one
> timeslot where I know the majority of the Cinder core are doing a
> presentation together. I would not be able to attend.
> 
> Of course there are other Cinder folks that are not presenting, so I can
> catch up with any of them after the fact. But if there is any other
> reason for moving this working session, that might work better to get
> more of the team involved.
> 
> Thanks,
> Sean (smcginnis)

Plans have not changed yet, though yes, that time conflict is a serious
problem...

I doubt we'll be able to come up with another cross-project time.  Maybe
we can find a second slot to talk specifically about the implications
for Cinder, though.  As long as a couple of Cinder core make it to the
cross-project talk (to make sure we don't lose too much data by
splitting it up like this) I think that could be enough?

I'm open to alternative ideas.

Best,
George



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] [heat] Convergence plans

[Sergey Kraynev]

Anant, thank you for notification.
I will be happy to hear Kanagaraj.

__
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-compute][nova][libvirt] Extending Nova-Compute for image prefetching

[Alberto Geniola]

Hi all,

I'm glad to see much interest in this feature. I will prepare and submit
nova specs by the end of this week.
On Oct 23, 2015 5:47 PM, "Markus Zoeller"  wrote:

> Mathieu Gagné  wrote on 10/22/2015 08:08:07 PM:
> > > Could you maybe add a short explanation what the use case is? IOW,
> > > when and why do I (in whatever role) prefetch images?
> > >
> >
> > This previous OpenStack Summit presentation at Paris is a great example
> > of use case:
> > https://www.openstack.org/summit/openstack-paris-summit-2014/session-
> > videos/presentation/cold-start-booting-of-1000-vms-under-10-minutes
> >
> > --
> > Mathieu
>
> Thanks, that's a great presentation with impressive numbers. I wasn't
> aware that there could be the need to distribute new images such often.
>
> Regards, Markus Zoeller (markus_z)
>
>
> __
> 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] [cinder] about the cinder /volumes and /volumes/detail sort APIs

[Duncan Thomas]

The deprecated API will be removed in some future release, though the date
for that is not know. It is not advised to code against a deprecated API
for this reason, and any existing code that operates against a deprecated
API should be updated where possible.

That said, the deprecated code in question is small and self contained, so
if you are aware of any project(s) that make use of it, please let us know
and we can try to avoid removing it until those projects are fixed up.
On 26 Oct 2015 11:15, "chenying"  wrote:

> hi Folks
>
> I find that the v2 /volumes and /volumes/detail sort API has been
> updated
> to support multiple sort keys and sort directions using the single 'sort'
> parameter
> in this patch[1].
> But this patch still supported old API using 'sort_key' and 'sort_dir'
> parameters
> which have been deprecated. We did not stop supporting the old API.
> So I want to know will the deprecated old sort APIs supporting code be
> deleted
> in the future? Or 'sort_key' and 'sort_dir' parameters will still be
> supported forever.
>
> [1]https://review.openstack.org/#/c/141914/
>
> Best regard.
> chenying(IRC)
> ying.c...@huawei.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo.messaging][RPC][HA] describe failure modes in API docs

[Bogdan Dobrelya]

This is a continuation of the "next steps" topic [0].
I created a blueprint [1] and related etherpad [2] to describe failure
modes (timeouts, retrurn codes and so on) at least for the Oslo
messaging RPC API calls, which seem the most critical
point for app and the library devs.

As the end goal, an example [3] should describe a full list
of possible situations (considering the given failure modes). Instead of
a brief "Invoke a method and wait for a reply." Makes sense?

Thank you, Konstantin Kalin for clearly defined basic use cases.
If you think there are more, please describe them at the etherpad.

[0] http://lists.openstack.org/pipermail/openstack-dev/2015-June/067471.html
[1] https://goo.gl/0U5P9D
[2] https://etherpad.openstack.org/p/oslo.messaging.api.failure.modes
[3] http://goo.gl/G0uQPk

-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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] [heat] Convergence plans

[Anant Patil]

I will not be able to attend the Mitaka summit, but I have captured my
thought process in

https://etherpad.openstack.org/p/heat-convergence-mitaka

Kanagaraj Manickam will represent me there for these discussions.

Thanks & Regards,
Anant

__
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] [Fuel] Changing APIs and API versioning

[Sebastian Kalinowski]

2015-10-23 11:36 GMT+02:00 Igor Kalnitsky :

> Roman, Vitaly,
>
> You're both saying right things, and you guys bring a sore topic up again.
>
> The thing is that Nailgun's API isn't the best one.. but we're trying
> to improve it step-by-step, from release to release. We have so many
> things to reconsider and to fix that it'd require a huge effort to
> make backward compatible changes and support it. So we decided ignore
> backward compatibility for clients for awhile and consider our API as
> unstable.
>
> I agree with Roman that such changes must not be made secretly, and we
> should at least announce about them. Moreover, every core must think
> about consequences before approving them.
>
> So I propose to do the following things when backward incompatible
> change to API is required:
>
> * Announce this change in openstack-dev ML.
> * Wait 1 week before approving it, so anyone can prepare.
> * Change author has to work with QA in order make sure they are
> prepared for this change.
>
> Any thoughts?
>


+1.

Although there is one thing that you didn't mention (but probably everyone
know about it)
is to solve the issue with fuelclient not beign tested against changes in
nailgun.
We need not only run it for every change in nailgun (or for only those that
touch files under "api"
dir) but also cover more endpoints with fuelclient tests against real API,
not mocks, to discover
such issues earlier.


>
> Thanks,
> Igor
>
> On Wed, Oct 21, 2015 at 5:24 PM, Vitaly Kramskikh
>  wrote:
> > JFYI: (re-)start of this discussion was instigated by merge of this
> change
> > (and here is revert).
> >
> > And this is actually not the first time when we make backward
> incompatible
> > changes in our API. AFAIR, the last time it was also about the network
> > configuration handler. We decided not to consider our API frozen, make
> the
> > changes and break backward compatibility. So now is the time to
> reconsider
> > this.
> >
> > API backward compatibility is a must for good software, but we also need
> to
> > understand that introducing API versioning is not that easy and will
> > increase efforts needed to make new changes in nailgun.
> >
> > I'd go this way:
> >
> > Estimate the priority of introducing API versioning - maybe we have other
> > things we should invest our resources to
> > Estimate all the disadvantages this decision might have
> > Fix all the issues in the current API (like this one)
> > Implement API versioning support (yes, we don't have this mechanism yet,
> so
> > we can't just "bump API version" like Sergii suggested in another thread)
> > Consider the current API as frozen v1, so backward incompatible changes
> (or
> > maybe all the changes?) should go to v2
> >
> >
> > 2015-10-21 20:25 GMT+07:00 Roman Prykhodchenko :
> >>
> >> Hi folks,
> >>
> >> I’d like to touch the aspect of Fuel development process that seems to
> be
> >> as wrong as possible. That aspect is how we change the API.
> >>
> >> The issue is that in Fuel anyone can change API at any point of time
> >> without even warning the rest of the same component’s team. Relying on
> this
> >> kind of API is basically impossible. We constantly have problems when
> even
> >> components of Fuel stop working due to unexpected changes in the API.
> >> Thinking about another software that must be integrated with Fuel is
> hardly
> >> possible with the current approach.
> >>
> >> As for a grown-up project there is a strong need for Fuel in general and
> >> for Nailgun in particular to work on a policy for making changes to
> their
> >> APIs. Living in OpenStack ecosystem we must at least take a look how
> it’s
> >> done in its components and try to do something similar. After working
> with
> >> Nova, Keystone, Ironic and other components I would propose to start
> with
> >> the following: let’s not make any changes to the API. Instead, let’s
> create
> >> a new version of Nailgun’s API that will appear in Fuel 8.0 and make
> all the
> >> changes there. That is the thing that will instantaneously make lives of
> >> other components much easier, if we make it now.
> >>
> >> After doing the essential part let’s think about how we are going to
> live
> >> with that in the future. There are several APIs in Fuel, the rest of the
> >> email is only touching Nailgun’s REST API. I can see the things somehow
> like
> >> the following:
> >>
> >>  - Introduce API documentation by embedding Swagger and Swagger UI.
> >>The current approach when we leave API docs for documentation team is
> >> not effective. Swagger generates the documentation and resolves this
> issue.
> >>  - After releasing a version of Fuel, it’s API is called stable and
> frozen
> >> for any changes, unless they allign API to the documentation or
> >> documentation to the API.
> >>  - All changes to a stable APIs must be backported to the stable version
> >> of Fuel that introduced the corresponding API.
> >>  - In order to guarantee that a stable API is not changed, Jenkins jobs

Re: [openstack-dev] [cinder] meeting place for event Monday night in Tokyo ...

[M Ranga Swami Reddy]

How do we go to venue?
On Oct 25, 2015 10:58 AM, "Mike Perez"  wrote:

> On 15:54 Oct 21, Jay S. Bryant wrote:
>
> 
>
> > Not sure where the evening will take us, but we are planning to meet
> > by registration at the Convention Center.  Looking at the map, if I
> > am reading it properly, in front of the Huawei Community Lounge on
> > the first floor looks like a good place to meet that is right near
> > registration.  So, lets go for that.  :-)
>
> I know a place with local craft beer and pizza. The only time this week
> you'll
> probably have it in Tokyo with the other festivities happening.
>
> venue: http://bairdbeer.com/en/tap/nakameguro.html
> map: https://goo.gl/maps/umqvsjPag3S2
>
> I delegate someone to make reservations for 15 people.
>
> --
> Mike Perez
>
> __
> 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] [fuel] PTL & Component Leads elections

[Bartlomiej Piotrowski]

Congratulations!

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