date:20160302

Re: [openstack-dev] [ironic] Remember to follow RFE process

2016-03-02 Thread Haomeng, Wang

Thanks Ruby to point this out.

On Thu, Mar 3, 2016 at 3:25 PM, Haomeng, Wang  wrote:

> Hi Ruby,
>
> Yes, just noticed that RFE is in 'Wishlist' status now, sorry for missing
> the bug status yesterday, so we need to follow the process, and I will help
> to revert the patch and get it back to review again once the REF is
> reviewed.
>
> -- Haomeng
>
>
>
> On Thu, Mar 3, 2016 at 3:07 AM, Ruby Loo  wrote:
>
>> Hi,
>>
>> Ironic'ers, please remember to follow the RFE process; especially the
>> cores.
>>
>> I noticed that a patch [1] got merged yesterday. The patch was associated
>> with an RFE [2] that hadn't been approved yet :-( What caught my eye was
>> that the commit message didn't describe the actual API change so I took a
>> quick look at the (RFE) bug and it wasn't documented there either.
>>
>> As a reminder, the RFE process is documented [3].
>>
>> Spec cores need to try to be more timely wrt specs (I admit, I am
>> guilty). And folks, especially cores, ought to take more care when
>> reviewing. Although I do feel like there are too many things that a
>> reviewer needs to keep in mind.
>>
>> Should we revert the patch [1] for now? (Disclaimer. I haven't looked at
>> the patch itself. But I don't think I should have to, to know what the API
>> change is.)
>>
>> --ruby
>>
>>
>> [1] https://review.openstack.org/#/c/264005/
>> [2] https://bugs.launchpad.net/ironic/+bug/1530626
>> [3]
>> http://docs.openstack.org/developer/ironic/dev/code-contribution-guide.html#adding-new-features
>>
>> __
>> 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] [ironic] Remember to follow RFE process

2016-03-02 Thread Haomeng, Wang

Hi Ruby,

Yes, just noticed that RFE is in 'Wishlist' status now, sorry for missing
the bug status yesterday, so we need to follow the process, and I will help
to revert the patch and get it back to review again once the REF is
reviewed.

-- Haomeng



On Thu, Mar 3, 2016 at 3:07 AM, Ruby Loo  wrote:

> Hi,
>
> Ironic'ers, please remember to follow the RFE process; especially the
> cores.
>
> I noticed that a patch [1] got merged yesterday. The patch was associated
> with an RFE [2] that hadn't been approved yet :-( What caught my eye was
> that the commit message didn't describe the actual API change so I took a
> quick look at the (RFE) bug and it wasn't documented there either.
>
> As a reminder, the RFE process is documented [3].
>
> Spec cores need to try to be more timely wrt specs (I admit, I am guilty).
> And folks, especially cores, ought to take more care when reviewing.
> Although I do feel like there are too many things that a reviewer needs to
> keep in mind.
>
> Should we revert the patch [1] for now? (Disclaimer. I haven't looked at
> the patch itself. But I don't think I should have to, to know what the API
> change is.)
>
> --ruby
>
>
> [1] https://review.openstack.org/#/c/264005/
> [2] https://bugs.launchpad.net/ironic/+bug/1530626
> [3]
> http://docs.openstack.org/developer/ironic/dev/code-contribution-guide.html#adding-new-features
>
> __
> 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] VM could not get IP from dhcp server

2016-03-02 Thread Ptacek, MichalX

Hi Jingting,

just few general hints (probably already checked):

-  security group rules in openstack (check both igress, egress, ….) – 
it’s quite common that after deployment it’s have to be modified

-  Iptables / fw ? – check if some packets are dropped

-  Cross-check if vlan is properly configured on physical interfaces

-  If you use tunnels, ensure that both IP’s are on bridges not on 
ported NIC’s

Best regards,
Michal

From: 康敬亭 [mailto:jingt...@unitedstack.com]
Sent: Thursday, March 03, 2016 4:20 AM
To: openstack-dev 
Subject: [openstack-dev] [Neutron] VM could not get IP from dhcp server

Hi guys:

I have openstack Liberty(linuxbridge + vxlan) installed, and the vm could not 
get IP from dhcp server.

Troubleshooting:
Using tcpdump can get dhcp discover packet on physical NIC on network node, but 
can't get it on vxlan port(vxlan-100) on network node.
In opposite direction, Sending arp broadcast  in dhcp namespace, and we can get 
packet on vxlan port(vxlan-100) but can't get packet on physical NIC.

However, we find port 8472 is being listened. Meanwhile all 
interfaces(vxlan-100, physical NIC) are up and running.

What could be the reason for the issue? Any comments are appreciated.

BR,
Jingting
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
__
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] [fuel] Fuel 9.0/Mitaka is now in Feature Freeze

2016-03-02 Thread Dmitry Borodaenko

Feature Freeze [0] for Fuel 9.0/Mitaka is now in effect. From this
moment and until stable/mitaka branch is created at Soft Code Freeze,
please do not merge feature related changes that have not received a
feature freeze exception.

[0] https://wiki.openstack.org/wiki/FeatureFreeze

We will discuss all outstanding feature freeze exception requests in our
weekly IRC meeting tomorrow [1]. If that discussion takes longer than
the 1 hour time slot we have booked on #openstack-meeting-alt, we'll
move the discussion to #fuel-dev and finish it there.

[1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda

The list of exceptions requested so far is exceedingly long and it is
likely that most of these exceptions will be rejected. If you want your
exception to be approved, please have the following information ready
for the meeting:

1) Link to design spec in fuel-specs, spec review status;

2) Links to all outstanding commits for the feature;

3) Dependencies between your change and other features: what will be
broken or useless if your change is not merged, what else has to be
merged for your change to work;

4) Analysis of impact and risks mitigation plan: which components are
affected by the change, what can break, how can impact be verified, how
can the change be isolated;

5) Status of test coverage: what can be tested, what's covered by
automated tests, what's been tested so far (with links to test results).

-- 
Dmitry Borodaenko

__
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][cinder] Limits on volume read throughput?

2016-03-02 Thread Philipp Marek

Hi Preston,

 
> The benchmark scripts are in:
> 
>   https://github.com/pbannister/openstack-bootstrap
in case that might help, here are a few notes and hints about doing 
benchmarks for the DRDB block device driver:

http://blogs.linbit.com/p/897/benchmarking-drbd/

Perhaps there's something interesting for you.


> Found that if I repeatedly scanned the same 8GB volume from the physical
> host (with 1/4TB of memory), the entire volume was cached in (host) memory
> (very fast scan times).
If the iSCSI target (or QEMU, for direct access) is set up to use buffer 
cache, yes.
Whether you really want that is up to discussion - it might be much more 
beneficial to move that RAM from the Hypervisor to the VM, which should 
then be able to do more efficient caching of the filesystem contents that 
it should operate on.


> Scanning the same volume from within the instance still gets the same
> ~450MB/s that I saw before. 
Hmmm, with iSCSI inbetween that could be the TCP memcpy limitation.

> The "iostat" numbers from the instance show ~44 %iowait, and ~50 %idle.
> (Which to my reading might explain the ~50% loss of performance.) Why so
> much idle/latency?
> 
> The in-instance "dd" CPU use is ~12%. (Not very interesting.)
Because your "dd" testcase will be single-threaded, io-depth 1.
And that means synchronous access, each IO has to wait for the preceeding 
one to finish...


> Not sure from where the (apparent) latency comes. The host iSCSI target?
> The QEMU iSCSI initiator? Onwards...
Thread scheduling, inter-CPU cache trashing (if the iSCSI target is on 
a different physical CPU package/socket than the VM), ...


Benchmarking is a dark art.


__
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] VM could not get IP from dhcp server

2016-03-02 Thread 康敬亭

Hi guys:


I have openstack Liberty(linuxbridge + vxlan) installed, and the vm could not 
get IP from dhcp server. 


Troubleshooting: 
Using tcpdump can get dhcp discover packet on physical NIC on network node, but 
can't get it on vxlan port(vxlan-100) on network node.
In opposite direction, Sending arp broadcast  in dhcp namespace, and we can get 
packet on vxlan port(vxlan-100) but can't get packet on physical NIC.


However, we find port 8472 is being listened. Meanwhile all 
interfaces(vxlan-100, physical NIC) are up and running.


What could be the reason for the issue? Any comments are appreciated.


BR,
Jingting__
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] config options help text improvement: current status

2016-03-02 Thread Matt Riedemann

On 3/2/2016 11:45 AM, Markus Zoeller wrote:

TL;DR: From ~600 nova specific config options are:
~140 at a central location with an improved help text
~220 options in open reviews (currently on hold)
~240 options todo

Background
==
Nova has a lot of config options. Most of them weren't well
documented and without looking in the code you probably don't
understand what they do. That's fine for us developers but the ops
had more problems with the interface we provide for them [1]. After
the Mitaka summit we came to the conclusion that this should be
improved, which is currently in progress with blueprint [2].

Current Status
==
After asking on the ML for help [3] the progress improved a lot.
The goal is clear now and we know how to achieve it. The organization
is done via [4] which also has a section of "odd config options".
This section is important for a later step when we want do deprecate
config options to get rid of unnecessary ones.

As we reached the Mitaka-3 milestone we decided to put the effort [5]
on hold to stabilize the project and focus the review effort on bug
fixes. When the Newton cycle opens, we can continue the work. The
current result can be seen in the sample "nova.conf" file generated
after each commit [6]. The appendix at the end of this post shows an
example.

All options we have will be treated that way and moved to a central
location at "nova/conf/". That's the central location which hosts
now the interface to the ops. It's easier to get an overview now.
The appendix shows how the config options were spread at the beginning
and how they are located now.

I initially thought that we have around 800 config options in Nova
but I learned meanwhile that we import a lot from other libs, for
example from "oslo.db" and expose them as Nova options. We have around
600 Nova specific config options, and ~140 are already treaded like
described above and ca. 220 are in the pipeline of open reviews.
Which leaves us ~240 which are not looked at yet.

Outlook
===
The numbers of the beginning of this ML post make me believe that we
can finish the work in the upcoming Newton cycle. "Finished" means
here:
* all config options we provide to our ops have proper and usable docs
* we have an understanding which options don't make sense anymore
* we know which options should get stronger validation to reduce errors

I'm looking forward to it :)

Thanks
==
I'd like to thank all the people who are working on this and making
this possible. A special thanks goes to Ed Leafe, Esra Celik and
Stephen Finucane. They put a tremendous amount of work in it.

References:
===
[1]
http://lists.openstack.org/pipermail/openstack-operators/2016-January/009301.html
[2] https://blueprints.launchpad.net/nova/+spec/centralize-config-options
[3]
http://lists.openstack.org/pipermail/openstack-dev/2015-December/081271.html
[4] https://etherpad.openstack.org/p/config-options
[5] Gerrit reviews for this topic:
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/centralize-config-options
[6] The sample config file which gets generated after each commit:
http://docs.openstack.org/developer/nova/sample_config.html

Appendix

Example of the help text improvement
---
As an example, compare the previous documentation of the scheduler
option "scheduler_tracks_instance_changes".
Before we started:

# Determines if the Scheduler tracks changes to instances to help
# with its filtering decisions. (boolean value)
#scheduler_tracks_instance_changes = true

After the improvement:

# The scheduler may need information about the instances on a host
# in order to evaluate its filters and weighers. The most common
# need for this information is for the (anti-)affinity filters,
# which need to choose a host based on the instances already running
# on a host.
#
# If the configured filters and weighers do not need this information,
# disabling this option will improve performance. It may also be
# disabled when the tracking overhead proves too heavy, although
# this will cause classes requiring host usage data to query the
# database on each request instead.
#
# This option is only used by the FilterScheduler and its subclasses;
# if you use a different scheduler, this option has no effect.
#
# * Services that use this:
#
# ``nova-scheduler``
#
# * Related options:
#
# None
# (boolean value)
#scheduler_tracks_instance_changes = true

The spread of config options in the tree

We started with this in November 2015. It's the Nova project tree and
the numbers behind the package name are the numbers of config options
declared in that package (config options declared in sub-packages are
not accumulated).

1 2 >

1 - 100 of 157 matches

Mail list logo