[openstack-dev] [kolla] Mitaka Midcycle scheduling voting

[Steven Dake (stdake)]

Hey folks,

Please vote on the days of the Kolla midcycle you can attend.  From that data I 
will select a date that works best for people that wish to attend the midcycle.

Coffee will be provided in the mornings.
Soda will be provided all day.
Lunch will be provided by Servosity both days (yay thanks Servosity)

The Summit is hosted at the Bank of America building in Greenville, South 
Carolina.

The voting is here:

http://doodle.com/poll/rhtdkr9srruffwzw

I will close voting January 4th.

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] [Fuel] Merge Freeze for cutting stable/8.0 branch

[Dmitry Borodaenko]

Yes, you can merge any commits that do not change Fuel's dependencies.
On Dec 25, 2015 01:15, "Vitaly Kramskikh"  wrote:

> Aleksandra,
>
> What are "base packages"? Can we merge to fuel-web?
>
> 2015-12-24 18:01 GMT+03:00 Aleksandra Fedorova :
>
>> Hi, everyone,
>>
>> we merged all versioning patches so now Fuel master is versioned as Fuel
>> 9.0.
>>
>> Merge freeze is lifted.
>>
>> Please note:
>>
>> * Fuel master is now open but only for changes which are still
>> compatible with 8.0 base repositories.
>>
>> All Base OS and OpenStack packages including those that are Fuel
>> dependencies are currently copied from 8.0 repo and freezed. Please
>> don't yet merge Fuel changes which require update in base packages.
>>
>> * All bug fixes needs to be merged in master first and then
>> cherry-picked to stable/8.0 branch
>>
>> On Thu, Dec 24, 2015 at 3:40 PM, Roman Vyalov 
>> wrote:
>> > Aleksandra,
>> > we dont have problems with inconsistent 9.0 repositories. But we found
>> the
>> > problem with process of building our ISO[0].
>> > It floating bug, but we found the main problem and solve it today
>> >
>> > [0] https://bugs.launchpad.net/fuel/+bug/1529073
>> >
>> > On Thu, Dec 24, 2015 at 5:14 AM, Aleksandra Fedorova
>> >  wrote:
>> >>
>> >> Hi, here is the status update:
>> >>
>> >> - we created stable/8.0 branch in all repositories;
>> >> - Fuel CI [1] is updated with 8.0 triggers and jobs, fuel-library
>> >> tests are working on pre-SCF ISO image still;
>> >> - 8.0 ISO builds are switched to stable/8.0 branch, see [2] for the
>> first
>> >> run;
>> >> - development focus in Launchpad has been switched to mitaka(9.0)
>> series
>> >> [3]
>> >>
>> >> If you file a bug for 8.0 release, please make sure you explicitly
>> >> target it to 8.0.x series additionally to the mitaka series which it
>> >> gets by default.
>> >>
>> >> Remaining tasks:
>> >>
>> >>   due to several issues caused by pre-SCF merge rush, we don't yet
>> >> have a working ISO for version bumps patches [4]
>> >>
>> >> Therefore we are still in Merge Freeze, as we need to stabilize master
>> >> before moving forward.
>> >>
>> >> Latest blocker for the merge - inconsistent 9.0 mirrors. Build team
>> >> will look into it, and I'll post an update with more information.
>> >>
>> >> [1] https://ci.fuel-infra.org
>> >> [2]
>> https://ci.fuel-infra.org/view/ISO/job/8.0-community.all/185/console
>> >> [3] https://launchpad.net/fuel/mitaka
>> >> [4] https://review.openstack.org/#/q/topic:8.0-scf
>> >>
>> >> On Wed, Dec 23, 2015 at 10:48 AM, Aleksandra Fedorova
>> >>  wrote:
>> >> > Hi Fuelers,
>> >> >
>> >> > SCF has been declared [1] and we start creating stable/8.0 branch in
>> >> > all projects.
>> >> >
>> >> > Please don't merge anything both to master and to stable/8.0 until we
>> >> > verify Infra and CI readiness.
>> >> >
>> >> > List of projects affected:
>> >> >
>> >> >   fuel-main
>> >> >   fuel-agent
>> >> >   fuel-astute
>> >> >   fuel-library
>> >> >   fuel-menu
>> >> >   fuel-ostf
>> >> >   fuel-qa
>> >> >   fuel-upgrade
>> >> >   fuel-web
>> >> >   shotgun
>> >> >   python-fuelclient
>> >> >   network-checker
>> >> >   fuel-nailgun-agent
>> >> >   fuel-mirror
>> >> >
>> >> > Use #fuel-infra or #fuel-dev IRC channels for questions.
>> >> >
>> >> > [1]
>> >> >
>> http://lists.openstack.org/pipermail/openstack-dev/2015-December/082939.html
>> >> >
>> >> > --
>> >> > Aleksandra Fedorova
>> >> > Fuel CI Team Lead
>> >> > bookwar
>> >>
>> >>
>> >>
>> >> --
>> >> Aleksandra Fedorova
>> >> CI Team Lead
>> >> bookwar
>> >>
>> >>
>> __
>> >> OpenStack Development Mailing 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
>> >
>>
>>
>>
>> --
>> Aleksandra Fedorova
>> CI Team Lead
>> bookwar
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> Mirantis, Inc.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [cinder] [nova] whether the ServiceGroup in Cinder is necessary

[hao wang]

hi, Janice

This idea seems to me that is useful to detect the state of
cinder-volume process more quickly, but I feel there is another issue
that if the back-end device go to fail you still
can't keep cloud in ha or create volume successfully since the service
is up but device is down.

So, what I want to say is we maybe need to consider to detect and
report the device state priority[1] and then consider to improve
service if we need that.

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

2015-12-28 9:18 GMT+08:00  :
>> Hmm, I see. There's this spec[1] that was discussed in the past with a
>> similar proposal. There's a SPEC with some other points on the discussion, I
>> think Janice
>> forgot to mention.
>
>> Erlon
>
>> [1] https://review.openstack.org/#/c/176233/
>> [2] https://review.openstack.org/#/c/258968/
>
>> On Tue, Dec 22, 2015 at 12:16 PM, Michał Dulko 
>> wrote:
>> On 12/22/2015 01:29 PM, Erlon Cruz wrote:
>> > Hi Li,
>> >
>> > Can you give a quick background on servicegroups (or links to. The
>> > spec you linked only describe the process on Nova to change from what
>> > they are using to tooz)? Also, what are the use cases and benefits of
>> > using this?
>> >
>> > Erlon
>> >
>
>> This is simply and idea to be able to use something more sophisticated
>> than DB heartbeats to monitor services states. With Tooz implemented for
>> that we would be able to use for example ZooKeeper to know about service
>> failure in a matter of seconds instead of around a minute. This would
>> shrink the window in which c-sch doesn't-know-yet that c-vol failed and
>> sends RPC messages to a service that will never answer. I think there
>> are more use cases related to service monitoring and failover.
>
>> Service groups isn't probably a correct name for proposed enhancement -
>> we have this concept somehow implemented, but proposed idea seems to be
>> related to making it pluggable.
>
>
> Hi Erlon and Michal,
> Sorry for response you so late.
>
> The Cinder ServiceGroup is used for getting the state of services
> quickly.
> use case such as:
>1) As an admin, I want to know each cinder service state, so that
> I can take some
>actions to keep cloud in high availability if any service is
> down.
>2) As an user, I want my volumes not to be scheduled to failed
> cinder-volume
>instances.
> My colleague and I, have posted the specs[1] of ServiceGroup in
> Cinder.
>
> Janice
>
> [1] https://review.openstack.org/#/c/258968/
>
>
>
>
> 发件人: Erlon Cruz 
> 收件人: "OpenStack Development Mailing List (not for usage questions)"
> ,
> 日期: 2015/12/23 04:04
> 主题:Re: [openstack-dev] [cinder] [nova] whether the ServiceGroup in
> Cinder is necessary
> 
>
>
>
> Hmm, I see. There's this spec[1] that was discussed in the past with a
> similar proposal. There's a SPEC with some other points on the discussion, I
> think Janice forgot to mention.
>
> Erlon
>
> [1] https://review.openstack.org/#/c/176233/
> [2] https://review.openstack.org/#/c/258968/
>
> On Tue, Dec 22, 2015 at 12:16 PM, Michał Dulko 
> wrote:
> On 12/22/2015 01:29 PM, Erlon Cruz wrote:
>> Hi Li,
>>
>> Can you give a quick background on servicegroups (or links to. The
>> spec you linked only describe the process on Nova to change from what
>> they are using to tooz)? Also, what are the use cases and benefits of
>> using this?
>>
>> Erlon
>>
>
> This is simply and idea to be able to use something more sophisticated
> than DB heartbeats to monitor services states. With Tooz implemented for
> that we would be able to use for example ZooKeeper to know about service
> failure in a matter of seconds instead of around a minute. This would
> shrink the window in which c-sch doesn't-know-yet that c-vol failed and
> sends RPC messages to a service that will never answer. I think there
> are more use cases related to service monitoring and failover.
>
> Service groups isn't probably a correct name for proposed enhancement -
> we have this concept somehow implemented, but proposed idea seems to be
> related to making it pluggable.
>
> __
> OpenStack Development Mailing 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
>
>
>
> 
> ZTE Information Security Notice: The information contained in 

[openstack-dev] [Neutron][Dragonflow] - IRC Meeting today (12/28) - 0900 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting today (Monday, 12/28) at 0900 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/dragonflow/2015/dragonflow.2015-12-21-09.00.html


Please update the agenda if you have any subject you would like to discuss
about.

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

Re: [openstack-dev] [cinder] [nova] whether the ServiceGroup in Cinder is necessary

[li . yuanzhen]

> Hmm, I see. There's this spec[1] that was discussed in the past with a 
similar proposal. There's a SPEC with some other points on the discussion, 
I think Janice 
> forgot to mention.

> Erlon

> [1] https://review.openstack.org/#/c/176233/
> [2] https://review.openstack.org/#/c/258968/

> On Tue, Dec 22, 2015 at 12:16 PM, Michał Dulko  
wrote:
> On 12/22/2015 01:29 PM, Erlon Cruz wrote:
> > Hi Li,
> >
> > Can you give a quick background on servicegroups (or links to. The
> > spec you linked only describe the process on Nova to change from what
> > they are using to tooz)? Also, what are the use cases and benefits of
> > using this?
> >
> > Erlon
> >

> This is simply and idea to be able to use something more sophisticated
> than DB heartbeats to monitor services states. With Tooz implemented for
> that we would be able to use for example ZooKeeper to know about service
> failure in a matter of seconds instead of around a minute. This would
> shrink the window in which c-sch doesn't-know-yet that c-vol failed and
> sends RPC messages to a service that will never answer. I think there
> are more use cases related to service monitoring and failover.

> Service groups isn't probably a correct name for proposed enhancement -
> we have this concept somehow implemented, but proposed idea seems to be
> related to making it pluggable.


Hi Erlon and Michal,
Sorry for response you so late.
 
The Cinder ServiceGroup is used for getting the state of services 
quickly.
use case such as:
   1) As an admin, I want to know each cinder service state, so 
that I can take some
   actions to keep cloud in high availability if any service is 
down.
   2) As an user, I want my volumes not to be scheduled to failed 
cinder-volume
   instances.
My colleague and I, have posted the specs[1] of ServiceGroup in 
Cinder.

Janice

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




发件人: Erlon Cruz 
收件人: "OpenStack Development Mailing List (not for usage 
questions)" , 
日期:   2015/12/23 04:04
主题:   Re: [openstack-dev] [cinder] [nova] whether the ServiceGroup in 
Cinder is necessary



Hmm, I see. There's this spec[1] that was discussed in the past with a 
similar proposal. There's a SPEC with some other points on the discussion, 
I think Janice forgot to mention.

Erlon

[1] https://review.openstack.org/#/c/176233/
[2] https://review.openstack.org/#/c/258968/

On Tue, Dec 22, 2015 at 12:16 PM, Michał Dulko  
wrote:
On 12/22/2015 01:29 PM, Erlon Cruz wrote:
> Hi Li,
>
> Can you give a quick background on servicegroups (or links to. The
> spec you linked only describe the process on Nova to change from what
> they are using to tooz)? Also, what are the use cases and benefits of
> using this?
>
> Erlon
>

This is simply and idea to be able to use something more sophisticated
than DB heartbeats to monitor services states. With Tooz implemented for
that we would be able to use for example ZooKeeper to know about service
failure in a matter of seconds instead of around a minute. This would
shrink the window in which c-sch doesn't-know-yet that c-vol failed and
sends RPC messages to a service that will never answer. I think there
are more use cases related to service monitoring and failover.

Service groups isn't probably a correct name for proposed enhancement -
we have this concept somehow implemented, but proposed idea seems to be
related to making it pluggable.

__
OpenStack Development Mailing 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



ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing 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] [senlin] Midcycle meetup (2016-01-11/12)

[Qiming Teng]

Dear all,

Wish you all a merry christmas and a happy new year.

Senlin team is planning a mid-cycle meetup next month in Beijing. Well,
it goes beyond just a meetup between developers. We are inviting some
users to share their real-life use cases and requirements.

IBM Research China Lab will host the event. Please find the schedule
etherpad here: https://etherpad.openstack.org/p/senlin-mitaka-midcycle

Any comments/suggestions are welcomed. We are looking forward to see you
guys.

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] [Neutron] [Dragonflow] Support configuration of DB clusters

[shihanzhang]

good suggestion！



At 2015-12-25 19:07:10, "Li Ma"  wrote:
>Hi all, currently, we only support db_ip and db_port in the
>configuration file. Some DB SDK supports clustering, like Zookeeper.
>You can specify a list of nodes when client application starts to
>connect to servers.
>
>I'd like to implement this feature, specifying ['ip1:port',
>'ip2:port', 'ip3:port'] list in the configuration file. If only one
>server exists, just set it to ['ip1:port'].
>
>Any suggestions?
>
>-- 
>
>Li Ma (Nick)
>Email: skywalker.n...@gmail.com
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] [nova] whether the ServiceGroup in Cinder is necessary

[li . yuanzhen]

Hi hao wang,

Firstly, I agree with you that healthy backend is a requirement for 
creating 
volumes, as the same as service-up. So, monitor the state of backend is 
useful.

While, ServiceGroup is only used for detecting state of service quickly, 
So whether
backend is up or not is not taken into consideration for ServiceGroup.

So, I think there is no priority between them. 

Thank you.
Janice



> hi, Janice
>
> This idea seems to me that is useful to detect the state of
> cinder-volume process more quickly, but I feel there is another issue
> that if the back-end device go to fail you still
> can't keep cloud in ha or create volume successfully since the service
> is up but device is down.
> 
> So, what I want to say is we maybe need to consider to detect and
> report the device state priority[1] and then consider to improve
> service if we need that.

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


ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing 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] [Dragonflow] Support configuration of DB clusters

[Li Ma]

My intention is to pass db-host-list (maybe it is defined in the conf
file) to db backend drivers. I find that there's '**args' available
[1], but it seems not working due to [2].

I suggest to use a simpler method to allow user-defined configuration that is
removing db_ip and db_port parameters and directly passing cfg.CONF
object to db backend driver.

In db_api.py, it should be:
def initialize(self, config):
self.config = config

In api_nb.py, it should be:
def initialize(self):
self.driver.initialize(cfg.CONF) <-- from oslo_config

As a result, let db backend developers choose which parameter to use.

[1] 
https://github.com/openstack/dragonflow/blob/master/dragonflow/db/db_api.py#L21
[2] 
https://github.com/openstack/dragonflow/blob/master/dragonflow/db/api_nb.py#L74-L75

On Mon, Dec 28, 2015 at 9:12 AM, shihanzhang  wrote:
>
> good suggestion！
>
>
> At 2015-12-25 19:07:10, "Li Ma"  wrote:
>>Hi all, currently, we only support db_ip and db_port in the
>>configuration file. Some DB SDK supports clustering, like Zookeeper.
>>You can specify a list of nodes when client application starts to
>>connect to servers.
>>
>>I'd like to implement this feature, specifying ['ip1:port',
>>'ip2:port', 'ip3:port'] list in the configuration file. If only one
>>server exists, just set it to ['ip1:port'].
>>
>>Any suggestions?
>>
>>--
>>
>>Li Ma (Nick)
>>Email: skywalker.n...@gmail.com
>>
>>__
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Li Ma (Nick)
Email: skywalker.n...@gmail.com

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