Re: [openstack-dev] [Fuel] Cache for packages on master node
On Tue, 2015-02-10 at 15:24 +0100, Tomasz Napierala wrote: Hi, We are currently redesigning our apporach to upstream distributions and obviusly we will need some cache system for packages on master node. It should work for deb and rpm packages, and be able to serve up to 200 nodes. I know we had bad experience in the past, can you guys share your thought on that? I just collected what was mentioned in other discussions: - approx - squid - apt-cacher-ng - ? As this should work for both .rpm/.deb packages, i think that squid (probably configured as transparent proxy, but not necessarily, we can explicitly set FMN as http/https proxy on deployed nodes) could be easiest to setup. http://codepoets.co.uk/2014/squid-3-4-x-with-ssl-for-debian-wheezy/ - example how to setup squid as transparent proxy also for https . -- regards jell __ 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] [webui] Setting one dns server address in ui.
On Wed, 2015-01-21 at 15:50 +0400, Vladimir Kuklin wrote: > Piotr, the easiest workaround is to patch neutron_subnet type to > perform munge operation that uses uniq function somewhere here: > https://github.com/stackforge/puppet-neutron/blob/master/lib/puppet/type/neutron_subnet.rb#L56-L60. > We would also appreciate if you filed a bug to Fuel launchpad. Filled bug lies under https://bugs.launchpad.net/fuel/+bug/1413182 link. -- Regards, jell __ 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] 10Gbe performance issue.
On Wed, 2015-01-21 at 10:53 +, Skamruk, Piotr wrote: > On Tue, 2015-01-20 at 17:41 +0100, Tomasz Napierala wrote: > >[...] > > How this was measured? VM to VM? Compute to compute? >[...] > Probably in ~30 minutes we also will have results on plain centos with > mirantis kernel, and on fuel deployed centos with plain centos kernel > (2.6.32 in both cases, but with different patchset subnumber). OK, our test were done little badly. On plain centos iperf were runned directly on physical interfaces, but under fuel deployed nodes... We ware using br-storage interfaces, which in real are openvs based. So this is not a kernel problem, but this is a single stream over ovs issue. So we will investigate this further... -- Regards, jell __ 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] [webui] Setting one dns server address in ui.
Hi. In time of environment setup, there is a place in webui to provide dns servers addresses on network tab, in neutron l3 configuration. There is no way to set only one address. Setting same ip in both input fields is permitted by webui, but later, in time of deploy - neutron called from puppet files fails to setup internal network (Net04 in my setup). If two addresses are mandatory, there should be check if they are different? Or should be there a way to setup only one address? -- Regards, jell __ 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] 10Gbe performance issue.
On Tue, 2015-01-20 at 17:41 +0100, Tomasz Napierala wrote: >[...] > How this was measured? VM to VM? Compute to compute? iperf between compute/ceph-compute/ceph nodes. > In any case, what is your deployment configuration, especially VLAND or GRE, > networking gear, etc. We have almost default setup from clean fuel 6.0, vlan based. We are doing iperf based on 82599ES 10-Gigabit SFP+ interfaces (used in our setup only for storage network) connected by fibre through Arista 7150. Results on centos 6.5 deployed from fuel: 0.0-10.0 sec 3.09 GBytes 2.65 Gbits/sec Results on centos 6.5 from official site: 0.0-10.0 sec 10.9 GBytes 9.38 Gbits/sec In both cases tests were done with default tcp window size - 19.3KByte. In both cases default mtu was with value 1500. Commands used in test (after adding iperf tool from rpm): on one node: iperf -s -p 8777 on other node: iperf -c ip_address_of_server_in_storage_network -p 8777 -t 10 (port 8777 is one of passed as ACCEPT in iptables setup from fuel) Differences are in kernel (from centos or from mirantis), values in /etc/sysctl.conf (plain or from mirantis) and probably in cgroups settings. Probably in ~30 minutes we also will have results on plain centos with mirantis kernel, and on fuel deployed centos with plain centos kernel (2.6.32 in both cases, but with different patchset subnumber). -- Regards, jell __ 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] Lack of additional setup on 10Gbit interfaces.
On mon, 2015-01-12 at 14:31 -0800, Dmitry Borodaenko wrote: > Hi Piotr, > > Thanks for writing up a detailed summary of the problem! At the > moment, we have a way to set MTU using Fuel CLI [0] and a blueprint to > add this functionality to Fuel Web UI [1] > > [0] > http://docs.mirantis.com/openstack/fuel/fuel-6.0/reference-architecture.html#adjust-the-network-configuration-via-cli > [1] https://blueprints.launchpad.net/fuel/+spec/set-mtu-for-interfaces Good point. I missed this. So from cli I can patch this before initial "deploy changes". Changing this on deployed environment is, or is not possible? btw. is there a way to force from fuel master node puppetsync on particular deployed environment? > > I'm not sure it's safe to assume that if you have a 10G NICs the rest > of your network is going to support jumbo frames, do you think simply > being able to set MTU explicitly (when you know for a fact that > particular MTU value works) would be good enough of a solution? Yes, I think that setting this should be based on user decision, and should be configurable per interface in some point of webui. -- jell __ 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] Lack of additional setup on 10Gbit interfaces.
Hi. I'm testing OpenStack setup set on our hardware with Fuel 6.0 and I found the problem with 10Gbit network interfaces configuration. Our setup uses Centos on deployed nodes - I didn't look how this situation looks from Ubuntu perspective, but looking on the fuel-library - there is probably the same effect. With default settings, nodes deployed by fuel have 2.6.32.xxx linux kernel, with 3.10 available and marked as "experimental". Under webui for deployment, network interfaces are correctly shown as running on 10Gbit, but... Maximal transfer rates which We could achieve were around 2.5Gbit/s. After some investigation I found that interfaces configured by /etc/sysconfig/network-scripts/ifcfg-* have set default MTU, no matter if particular interface is or is not 10Gbit. I did not searched how other than igxbe drivers works, but this particular under so old kernels in 10Gbit configuration requires MTU set to at least 9000 (to turn on jumbo frames - probably other drivers have similar requirement), to work properly. Manual adding (this is only simplification, this should be set more carefully): for f in /etc/sysconfig/network-scripts/ifcfg-* ; do echo "MTU=9000" >>$f ; done partially resolves this problem (partially, because under default 2.6.32.xxx still We do not have better than 6Gbit/s transfers in single stream, but situation is much better under mentioned above 3.10 kernel - We have full 10Gbit/s). Looking into fuel-library, l23network::l3::ifconfig have ability to also configure MTU, but this functionality looks unused in this situation. End user which buys setup with 10Gbit/s 82599 based network adapters expects that in default configuration "all should work as expected". From user perspective - actual situation is faulty. For this moment - not only in time of deploy he must select option marked as "experimental", but also he must patch deployed setup, and remember to patch in same way every one added in future physical node. So, what We can do to make end user happier? Could We in puppet files do something like: if interface_link == '10Gbit' and interface_driver == 'igxbe': set_mtu(9000) interface_driver could be readed from link name, from /sys/class/net//device/driver/module interface_link could be readed from ethtool | grep Speed Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN. Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited. __ 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
