Re: [openstack-dev] [heat]Heat error during devstack installation

[Rico Lin]

include Tacker PTL in this ML

2017-12-28 13:57 GMT+08:00 Eyal B :

> Hi
> I submitted a patch to fix this
> https://review.openstack.org/#/c/530109/
>
> Eyal
>
>
> On Dec 28, 2017 07:55, "Yatin Karel"  wrote:
>
>> Both vitrage and tacker are likely to fail as they are modifying
>> heat's policy.json in their devstack plugin.
>> See below:-
>>
>> tacker:- https://github.com/openstack/tacker/blob/master/devstack/lib
>> /tacker#L470-L474
>> vitrage:- https://github.com/openstack/vitrage/blob/master/devstack/pl
>> ugin.sh#L343-L358
>>
>>
>> Since policy.json is removed, they can not modify it, so for
>> overriding  rules they have to create their own policy.json or
>> policy.yaml for overridden rules and update heat.conf to use new
>> policy file.
>>
>>
>> Thanks and Regards
>> Yatin Karel
>>
>> On Thu, Dec 28, 2017 at 11:12 AM, Rico Lin 
>> wrote:
>> > Hi Minwook
>> >>
>> >> I get an error that can not find ‘/etc/heat/policy.json of heat ‘ while
>> >> installing devstack.
>> >>
>> >> These errors can occur during scripting for projects related to heat,
>> such
>> >> as tacker, vitrage, etc.
>> >>
>> >>
>> >>
>> >> Why do I get this error?
>> > We no longer have policy.json by default since [1].
>> > Can you share more logs from your devstack, will take a deep look.
>> >
>> >
>> >
>> > [1] https://review.openstack.org/#/c/505360/ricolin
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing 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]Heat error during devstack installation

[Eyal B]

Hi
I submitted a patch to fix this
https://review.openstack.org/#/c/530109/

Eyal


On Dec 28, 2017 07:55, "Yatin Karel"  wrote:

> Both vitrage and tacker are likely to fail as they are modifying
> heat's policy.json in their devstack plugin.
> See below:-
>
> tacker:- https://github.com/openstack/tacker/blob/master/devstack/
> lib/tacker#L470-L474
> vitrage:- https://github.com/openstack/vitrage/blob/master/devstack/
> plugin.sh#L343-L358
>
>
> Since policy.json is removed, they can not modify it, so for
> overriding  rules they have to create their own policy.json or
> policy.yaml for overridden rules and update heat.conf to use new
> policy file.
>
>
> Thanks and Regards
> Yatin Karel
>
> On Thu, Dec 28, 2017 at 11:12 AM, Rico Lin 
> wrote:
> > Hi Minwook
> >>
> >> I get an error that can not find ‘/etc/heat/policy.json of heat ‘ while
> >> installing devstack.
> >>
> >> These errors can occur during scripting for projects related to heat,
> such
> >> as tacker, vitrage, etc.
> >>
> >>
> >>
> >> Why do I get this error?
> > We no longer have policy.json by default since [1].
> > Can you share more logs from your devstack, will take a deep look.
> >
> >
> >
> > [1] https://review.openstack.org/#/c/505360/ricolin
> >
> > 
> __
> > OpenStack Development Mailing 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]Heat error during devstack installation

[Yatin Karel]

Both vitrage and tacker are likely to fail as they are modifying
heat's policy.json in their devstack plugin.
See below:-

tacker:- 
https://github.com/openstack/tacker/blob/master/devstack/lib/tacker#L470-L474
vitrage:- 
https://github.com/openstack/vitrage/blob/master/devstack/plugin.sh#L343-L358


Since policy.json is removed, they can not modify it, so for
overriding  rules they have to create their own policy.json or
policy.yaml for overridden rules and update heat.conf to use new
policy file.


Thanks and Regards
Yatin Karel

On Thu, Dec 28, 2017 at 11:12 AM, Rico Lin  wrote:
> Hi Minwook
>>
>> I get an error that can not find ‘/etc/heat/policy.json of heat ‘ while
>> installing devstack.
>>
>> These errors can occur during scripting for projects related to heat, such
>> as tacker, vitrage, etc.
>>
>>
>>
>> Why do I get this error?
> We no longer have policy.json by default since [1].
> Can you share more logs from your devstack, will take a deep look.
>
>
>
> [1] https://review.openstack.org/#/c/505360/ricolin
>
> __
> OpenStack Development Mailing 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]Heat error during devstack installation

[Rico Lin]

Hi Minwook
>
> I get an error that can not find ‘/etc/heat/policy.json of heat ‘ while
installing devstack.
>
> These errors can occur during scripting for projects related to heat,
such as tacker, vitrage, etc.
>
>
>
> Why do I get this error?
We no longer have policy.json by default since [1].
Can you share more logs from your devstack, will take a deep look.



[1] https://review.openstack.org/#/c/505360/ricolin
__
OpenStack Development Mailing 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]Heat error during devstack installation

[MinWookKim]

Hello Heat Team

I get an error that can not find '/etc/heat/policy.json of heat ' while
installing devstack.

These errors can occur during scripting for projects related to heat, such
as tacker, vitrage, etc.

 

Why do I get this error?



Please check the error.

Thank you.

Best Regards,

Minwook.

 

__
OpenStack Development Mailing 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] Re: About maridb 10.1 on kolla

[Xinliang Liu]

On 27 December 2017 at 20:25, Steven Dake (stdake)  wrote:
> Michal wanted to test on multinode.  Not sure if he ever got there.
>

Yep, hope someone can test on mutinode. Jeffrey4l also said to help test.

> Anyway - feel free to take over the patch.  Even though gerrit doesn't care
> about co-authors, co-authors might, and we want to keep a tidy history of
> authorship for CLA reasons, so please use the
>
> "Co-AUthored-by: first last " at the conclusion of your commit log.

Done, spilt into two patches:
https://review.openstack.org/#/c/529199/
https://review.openstack.org/#/c/468632/

Thanks very much.
Xinliang

>
> Thanks
>
>
> CHeers
> -steve
>
>
> On December 26, 2017 at 2:03:44 AM, Xinliang Liu (xinliang@linaro.org)
> wrote:
>
> On 26 December 2017 at 15:47, Xinliang Liu  wrote:
>> On 26 December 2017 at 15:38, Marcin Juszkiewicz
>>  wrote:
>>>
>>>
>>> 26.12.2017 08:05 "Xinliang Liu"  napisał(a):
>>>
>>> Hi Steven,
>>>
>>> I have tested your patch[1] that works for one node Debian MariaDB
>>> 10.1 deployment.
>>> But the whole change seems be not updated for long time. Your last
>>> updated patch 12 was in May.
>>>
>>>
>>> Xinliang: you can update patch in review too. Gerrit cares about
>>> change-id
>>> field and do not care about author. So refresh patch from review and send
>>> with "git review".
>>
>> OK. will update soon.
>
> Done.

__
OpenStack Development Mailing 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] about backup instance booted from volume

[Jaze Lee]

2017-12-28 10:56 GMT+08:00 Jaze Lee :
> Hello,
>This is the spec about backup a instance booted from volume, anyone
> who is interested on booted from volume can help to review this. Any
> suggestion is welcome.
The spec is here.
https://review.openstack.org/#/c/530214/2


Thanks a lot...
>
>
>
>
> --
> 谦谦君子



-- 
谦谦君子

__
OpenStack Development Mailing 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] Mixed service version CI testing

[Blair Bethwaite]

+1!

It may also be worth testing a step where Nova & Neutron remain at N-1.

On 20 December 2017 at 04:58, Matt Riedemann  wrote:
> During discussion in the TC channel today [1], we got talking about how
> there is a perception that you must upgrade all of the services together for
> anything to work, at least the 'core' services like
> keystone/nova/cinder/neutron/glance - although maybe that's really just
> nova/cinder/neutron?
>
> Anyway, I posit that the services are not as tightly coupled as some people
> assume they are, at least not since kilo era when microversions started
> happening in nova.
>
> However, with the way we do CI testing, and release everything together, the
> perception is there that all things must go together to work.
>
> In our current upgrade job, we upgrade everything to N except the
> nova-compute service, that remains at N-1 to test rolling upgrades of your
> computes and to make sure guests are unaffected by the upgrade of the
> control plane.
>
> I asked if it would be valuable to our users (mostly ops for this right?) if
> we had an upgrade job where everything *except* nova were upgraded. If
> that's how the majority of people are doing upgrades anyway it seems we
> should make sure that works.
>
> I figure leaving nova at N-1 makes more sense because nova depends on the
> other services (keystone/glance/cinder/neutron) and is likely the harder /
> slower upgrade if you're going to do rolling upgrades of your compute nodes.
>
> This type of job would not run on nova changes on the master branch, since
> those changes would not be exercised in this type of environment. So we'd
> run this on master branch changes to
> keystone/cinder/glance/neutron/trove/designate/etc.
>
> Does that make sense? Would this be valuable at all? Or should the opposite
> be tested where we upgrade nova to N and leave all of the dependent services
> at N-1?
>
> Really looking for operator community feedback here.
>
> [1]
> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-19.log.html#t2017-12-19T15:14:15
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Cheers,
~Blairo

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

Re: [openstack-dev] [nova] Boot from volume 's instance of rescueoperation

[李杰]

Yeah,good idea.Thanks for your suggestion.


 
 
-- Original --
From: "Jaze Lee"; 
Date: 2017年12月28日(星期四) 上午10:51
To: "OpenStack Developmen"; 
Subject: Re: [openstack-dev] [nova] Boot from volume 's instance of 
rescueoperation

 
2017-12-27 20:41 GMT+08:00 Jay Pipes :
> On 12/27/2017 05:34 AM, 李杰 wrote:
>>
>> Hi,all
>>
>> As we all known,Now the boot from volume 's instance of rescue
>> operation is invalid.
>> To solve it,I have two plans.
>> 1.I plan to use the rescue_image as the root disk,and then make
>> the original root volume as the second disk to create new domain,in other
>> words,the rescued instance is boot from image.Finally,the user can repair
>> the rescued instance.
>> 2.I plan to transform the rescue_image to a volume,then  make this
>> volume as the first disk,and make the original root volume as the second
>> disk to create new domain,in other words,the rescued instance is boot from
>> volume.Finally,the user can repair the rescued instance.
>> Can you give me some advice?Help in troubleshooting this issue
>> will be appreciated.
>
>
> Hi Rambo,
>
> I would not advise either of the above plans. This is yet another problem
> with boot-from-volume.
>
> A better use of your time would be to split the original giant volume into
> the operating system part and the application data part. Make the
> application data part into a normal non-bootable volume and use a regular
> operating system image as your root/boot partition.
>
> You can't build a palace on quicksand.

Actually, this is not a like what your said. I think we should judge
the type of instance.
If it is boot from image, then go original. If it is boot from volume,
then the image must be a
bootable volume.  This is more make sense.


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



-- 
谦谦君子

__
OpenStack Development Mailing 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] about backup instance booted from volume

[Jaze Lee]

Hello,
   This is the spec about backup a instance booted from volume, anyone
who is interested on booted from volume can help to review this. Any
suggestion is welcome.




-- 
谦谦君子

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

[openstack-dev] [neutron][neutron-lib]Service function defintion files

[Ian Wells]

Hey,

Can someone explain how the API definition files for several service
plugins ended up in neutron-lib?  I can see that they've been moved there
from the plugins themselves (e.g. networking-bgpvpn has
https://github.com/openstack/neutron-lib/commit/3d3ab8009cf435d946e206849e85d4bc9d149474#diff-11482323575c6bd25b742c3b6ba2bf17)
and that there's a stadium element to it judging by some earlier commits on
the same directory, but I don't understand the reasoning why such service
plugins wouldn't be self-contained - perhaps someone knows the history?

Thanks,
-- 
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] [nova] Boot from volume 's instance of rescue operation

[Jaze Lee]

2017-12-27 20:41 GMT+08:00 Jay Pipes :
> On 12/27/2017 05:34 AM, 李杰 wrote:
>>
>> Hi,all
>>
>> As we all known,Now the boot from volume 's instance of rescue
>> operation is invalid.
>> To solve it,I have two plans.
>> 1.I plan to use the rescue_image as the root disk,and then make
>> the original root volume as the second disk to create new domain,in other
>> words,the rescued instance is boot from image.Finally,the user can repair
>> the rescued instance.
>> 2.I plan to transform the rescue_image to a volume,then  make this
>> volume as the first disk,and make the original root volume as the second
>> disk to create new domain,in other words,the rescued instance is boot from
>> volume.Finally,the user can repair the rescued instance.
>> Can you give me some advice?Help in troubleshooting this issue
>> will be appreciated.
>
>
> Hi Rambo,
>
> I would not advise either of the above plans. This is yet another problem
> with boot-from-volume.
>
> A better use of your time would be to split the original giant volume into
> the operating system part and the application data part. Make the
> application data part into a normal non-bootable volume and use a regular
> operating system image as your root/boot partition.
>
> You can't build a palace on quicksand.

Actually, this is not a like what your said. I think we should judge
the type of instance.
If it is boot from image, then go original. If it is boot from volume,
then the image must be a
bootable volume.  This is more make sense.


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



-- 
谦谦君子

__
OpenStack Development Mailing 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] [trove]configuration will be removed after resize mysql replica with a new flavor

[王俊]

Hi,all
 When I resize mysql replica,trove will create a new configuration with 
new flavor,but It losts a step to attach replica template configuration whitch 
is excuted while replica instance is created.how to fixed?attach replica 
configuration again or remove the codes just like this link: 
https://review.openstack.org/#/c/477425


保密：本函仅供收件人使用，如阁下并非抬头标明的收件人，请您即刻删除本函，勿以任何方式使用及传播，并请您能将此误发情形通知发件人，谢谢！

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

[openstack-dev] [tripleo] CI promotion blockers

[Emilien Macchi]

Just a heads-up about what we've done the last days to make progress
and hopefully get a promotion this week:

- Disabling voting on scenario001, 002 and 003. They timeout too much,
we haven't figured out why yet but we'll look at it this week and next
week. Hopefully we can re-enable voting today or so.
- Kolla added Sensu support and it broke our container builds. It
should be fixed by https://review.openstack.org/#/c/529890/ and
https://review.openstack.org/530232
- Keystone removed _member_ role management, so we stopped using it
(only Member is enough): https://review.openstack.org/#/c/529849/
- Fixup MTU configuration for CI envs: https://review.openstack.org/#/c/527249
- Reduce memory for undercloud image convert:
https://review.openstack.org/#/c/530137/
- Remove policy.json default rules from Heat in THT:
https://review.openstack.org/#/c/530225

That's pretty all. Due to the lack of reviewers during the Christmas
time, we had to land some patches ourselves. If there is any problem
with one of them, please let us know. We're trying to maintain CI is
good shape this week and it's a bit of a challenge ;-)
-- 
Emilien Macchi

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

Re: [openstack-dev] [neutron] performance issue between virtual networks

[Armando M.]

On 27 December 2017 at 05:39, Kim-Norman Sahm  wrote:

> Hi,
>
> i've detected a performance issue by accessing an floating ip in a
> different openstack network (same tenant).
>
> example:
> i have one tenant with two internal networks.
> each network has its own vrouter which is connectet to the extnet.
> the physical network infrastructure is 10Gbit/s.
>
>  networkA
>VM1 --|   extnet
>  ||vrouter1||
>VM2 --|  |
> |---ext
>  networkB   |
>VM3 --|  |
>  ||vrouter2||
>VM4 --|
>
> VM1 -> VM2  ~8,6Gbit/s
> VM3 -> VM4  ~8,6GBit/s
> VM1 -> vrouter1 ~8.6GBit/s
> VM4 -> vrouter2 ~8,6GBit/s
> vrouter1 -> vrouter2 ~8,6Gbits
> VM1 -> VM4  ~2,5GBit/s
> VM1 -> vrouter2 ~2,5Gbit/s
>
> detected with iperf3
> it's an openstack newton environment with openvswitch 2.6.1
> VXLAN mtu is 8950 and 9000 for physical interfaces
>
> does anybody has an idea what could be the cause of the performance
> issue?
>

Is the router distributed?


>
> Best regards
> Kim
>
> __
> OpenStack Development Mailing 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] [cinder] Reminder there is now Meeting this week!

[Jay S Bryant]

Team,

Just a quick reminder that there is no meeting today (12/27/17) or next 
week (1/3/2017).


Hope you all have had a great Christmas and that you have a safe and 
wonderful New Year!


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] Mixed service version CI testing

[Curtis]

On Tue, Dec 19, 2017 at 10:58 AM, Matt Riedemann  wrote:
> During discussion in the TC channel today [1], we got talking about how
> there is a perception that you must upgrade all of the services together for
> anything to work, at least the 'core' services like
> keystone/nova/cinder/neutron/glance - although maybe that's really just
> nova/cinder/neutron?
>
> Anyway, I posit that the services are not as tightly coupled as some people
> assume they are, at least not since kilo era when microversions started
> happening in nova.
>
> However, with the way we do CI testing, and release everything together, the
> perception is there that all things must go together to work.
>
> In our current upgrade job, we upgrade everything to N except the
> nova-compute service, that remains at N-1 to test rolling upgrades of your
> computes and to make sure guests are unaffected by the upgrade of the
> control plane.
>
> I asked if it would be valuable to our users (mostly ops for this right?) if
> we had an upgrade job where everything *except* nova were upgraded. If
> that's how the majority of people are doing upgrades anyway it seems we
> should make sure that works.
>
> I figure leaving nova at N-1 makes more sense because nova depends on the
> other services (keystone/glance/cinder/neutron) and is likely the harder /
> slower upgrade if you're going to do rolling upgrades of your compute nodes.
>
> This type of job would not run on nova changes on the master branch, since
> those changes would not be exercised in this type of environment. So we'd
> run this on master branch changes to
> keystone/cinder/glance/neutron/trove/designate/etc.
>
> Does that make sense? Would this be valuable at all? Or should the opposite
> be tested where we upgrade nova to N and leave all of the dependent services
> at N-1?
>
> Really looking for operator community feedback here.

I'd def like to see something like this.

Thanks,
Curtis.

>
> [1]
> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-19.log.html#t2017-12-19T15:14:15
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Blog: serverascode.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-dev] [acceleration]No Cyborg Team Meeting this week

[Zhipeng Huang]

Hi,

As stated last time we will not have team meeting this week, and will
resume next Wed.

At the mean time however you are more than welcomed to review the open
patches and provide help on the current development process

-- 
Zhipeng (Howard) Huang

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

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

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

[openstack-dev] [neutron] performance issue between virtual networks

[Kim-Norman Sahm]

Hi,

i've detected a performance issue by accessing an floating ip in a
different openstack network (same tenant).

example:
i have one tenant with two internal networks.
each network has its own vrouter which is connectet to the extnet.
the physical network infrastructure is 10Gbit/s.

         networkA   
   VM1 --|   extnet
 ||vrouter1||
   VM2 --|  |
|---ext
 networkB   |
   VM3 --|  |
 ||vrouter2||
   VM4 --|

VM1 -> VM2  ~8,6Gbit/s
VM3 -> VM4  ~8,6GBit/s
VM1 -> vrouter1 ~8.6GBit/s
VM4 -> vrouter2 ~8,6GBit/s
vrouter1 -> vrouter2 ~8,6Gbits
VM1 -> VM4  ~2,5GBit/s
VM1 -> vrouter2 ~2,5Gbit/s

detected with iperf3
it's an openstack newton environment with openvswitch 2.6.1
VXLAN mtu is 8950 and 9000 for physical interfaces

does anybody has an idea what could be the cause of the performance
issue?

Best regards
Kim

__
OpenStack Development Mailing 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] No meeting today

[Чадин Александр]

Hello,

There will not be Watcher team meeting this week (27/12)
and the next one (03/01). Let’s meet on January 10.
Merry Christmas and Happy New Year!


Alex


signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing 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] Boot from volume 's instance of rescue operation

[Jay Pipes]

On 12/27/2017 05:34 AM, 李杰 wrote:

Hi,all

As we all known,Now the boot from volume 's instance of rescue 
operation is invalid.

To solve it,I have two plans.
1.I plan to use the rescue_image as the root disk,and then make 
the original root volume as the second disk to create new domain,in 
other words,the rescued instance is boot from image.Finally,the user can 
repair the rescued instance.
2.I plan to transform the rescue_image to a volume,then  make 
this volume as the first disk,and make the original root volume as the 
second disk to create new domain,in other words,the rescued instance is 
boot from volume.Finally,the user can repair the rescued instance.
Can you give me some advice?Help in troubleshooting this issue 
will be appreciated.


Hi Rambo,

I would not advise either of the above plans. This is yet another 
problem with boot-from-volume.


A better use of your time would be to split the original giant volume 
into the operating system part and the application data part. Make the 
application data part into a normal non-bootable volume and use a 
regular operating system image as your root/boot partition.


You can't build a palace on quicksand.

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

[openstack-dev] [kolla] Re: About maridb 10.1 on kolla

[Steven Dake (stdake)]

Michal wanted to test on multinode.  Not sure if he ever got there.

Anyway - feel free to take over the patch.  Even though gerrit doesn't care 
about co-authors, co-authors might, and we want to keep a tidy history of 
authorship for CLA reasons, so please use the

"Co-AUthored-by: first last " at the conclusion of your commit log.

Thanks


CHeers
-steve



On December 26, 2017 at 2:03:44 AM, Xinliang Liu 
(xinliang@linaro.org) wrote:

On 26 December 2017 at 15:47, Xinliang Liu  wrote:
> On 26 December 2017 at 15:38, Marcin Juszkiewicz
>  wrote:
>>
>>
>> 26.12.2017 08:05 "Xinliang Liu"  napisał(a):
>>
>> Hi Steven,
>>
>> I have tested your patch[1] that works for one node Debian MariaDB
>> 10.1 deployment.
>> But the whole change seems be not updated for long time. Your last
>> updated patch 12 was in May.
>>
>>
>> Xinliang: you can update patch in review too. Gerrit cares about change-id
>> field and do not care about author. So refresh patch from review and send
>> with "git review".
>
> OK. will update soon.

Done.
__
OpenStack Development Mailing 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] Fix the problem that volume-backed server rebuild

[李杰]

Hi,all


   I have solved the the problem that volume-backed server rebuild.Can you 
help me review https://review.openstack.org/#/c/528740/ ?
   Re:the related 
bp:https://blueprints.launchpad.net/nova/+spec/volume-backed-server-rebuild
   Can you give me some advice?Help in troubleshooting this issue will be 
appreciated.












Best Regards
Lijie__
OpenStack Development Mailing 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] Boot from volume 's instance of rescue operation

[李杰]

Hi,all


   As we all known,Now the boot from volume 's instance of rescue operation 
is invalid.
   To solve it,I have two plans.
   1.I plan to use the rescue_image as the root disk,and then make the 
original root volume as the second disk to create new domain,in other words,the 
rescued instance is boot from image.Finally,the user can repair the rescued 
instance.
   2.I plan to transform the rescue_image to a volume,then  make this 
volume as the first disk,and make the original root volume as the second disk 
to create new domain,in other words,the rescued instance is boot from 
volume.Finally,the user can repair the rescued instance.
   Can you give me some advice?Help in troubleshooting this issue will be 
appreciated.












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