Re: [openstack-dev] [fuel] What to do when a controller runs out of space

[Sergey Vasilenko]

On Fri, Oct 2, 2015 at 10:50 PM, Alex Schultz  wrote:

> So I was working on Bug 1493520 which is about what happens when a
> controller runs out of space. For this I came up with a solution[1] to
> leverage pacemaker to migrate services away from the controller when
> it runs out of space.
>

Yesterday, while we discuss about another bug, Dmitry Iliyn propose
following changes to haproxy service checker:
Checker for each service, covered by haproxy, should check also pacemaker
status on the target node.
If pacemaker not in the operate state (maintenance mode, fencing processed,
something another) Haproxy should mark
this endpoint as bad and do not use this endpoint.

IMHO this approach may be use and here.
As soon out of space detected, pacemaker should be switched to non-operate
mode.

If all openstack services will be controlled by pacemaker -- they will be
going down automatically by pacemaker.
Advantage of moving all openstack services into pacemaker -- one control
center for each service for whole cluster.
Services, controlled by pacemaker, may be just a OS services (init,
upstart, or something another) or an containered.

/sv
__
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] What to do when a controller runs out of space

[Sergey Vasilenko]

On Mon, Oct 5, 2015 at 12:22 PM, Eugene Nikanorov 
wrote:

> No pacemaker for os services, please.
> We'll be moving out neutron agents from pacemaker control in 8.0, other os
> services don't need it too.
>

could you please provide your arguments.


/sv
__
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] Blueprint to change (expand) traditional Ethernet interface naming schema in Fuel

[Sergey Vasilenko]

>
> >I would like to pay your attention to the changing interface naming
> >schema, which is proposed to be implemented in FuelA [1].A In brief,
> >Ethernet network interfaces may not be named as ethX, and there is a
> >reported bug about itA [2]
> >There are a lot of reasons to switch to the new naming schema, not
> only
> >because it has been used in CentOS 7 (and probably will be used in
> next
> >Ubuntu LTS), but becauseA new naming schema gave more predictable
> >interface namesA [3]. There is a reported bug related to the topicA
> [4]
>

L23network module is a interface naming scheme agnostic.
Only bridge and bond interface name protection found -- You can't call bond
or bridge like 'enp2s0', because this name reserved for NICs.



> You might be interested to look at the os-net-config tool - we faced this
> exact same issue with TripleO, and solved it via os-net-config, which
> provides abstractions for network configuration, including mapping device
> aliases (e.g "nic1") to real NIC names (e.g "em1" or whatever).
>
> https://github.com/openstack/os-net-config
>
>
It's interesting project. Proposed format for network configuration, so
interesting, but...
Project too young. And doesn't allow to configure some things, that
L23network already support.
Main problem of this project -- is a approach to change interface options
options. They doesn't use prefetch/flush mechanics as in the puppet. They
just executing commands for change, instead in most cases. Such approach
doesn't allow re-configure existing cloud properly, if one under production
load.

I can support config format from os-net-config as additional network scheme
format too, but, IMHO, this hierarchical format not so convenient as flat.

NIC mapping, in Nailgun, already implemented in the template-networking. If
wee need use it for another cases -- ask Alexey Kasatkin, please.

/sv
__
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] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands

[Sergey Vasilenko]

Hi, guys!

Now I observe potential-dangerous situation in the providers of
puppet-neutron module. I want share details, because not only
puppet-neutron module may be broken by warnings from Openstack CLI
utilities.


 After updating urllib3 library on my lab, commands like 'neutron net list'
began to throw warnings, like:

> root@node-2:~# neutron net-list
> /usr/lib/python2.7/dist-packages/urllib3/util/ssl_.py:90:
> InsecurePlatformWarning: A true SSLContext object is not available. This
> prevents urllib3 from configuring SSL appropriately and may cause certain
> SSL connections to fail. For more information, see
> https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning
> .
>   InsecurePlatformWarning
> /usr/lib/python2.7/dist-packages/urllib3/connection.py:251:
> SecurityWarning: Certificate has no `subjectAltName`, falling back to check
> for a `commonName` for now. This feature is being removed by major browsers
> and deprecated by RFC 2818. (See
> https://github.com/shazow/urllib3/issues/497 for details.)
>   SecurityWarning
>
> +--+---+---+
> | id   | name  | subnets
> |
>
> +--+---+---+
> | 9e1c0866-51f0-4659-8d5c-1c5d0843dab4 | net04_ext |
> 29c952ec-2a13-46fc-a8a1-6e2468a92a95 172.18.171.0/24  |
> | d70b399b-668b-4861-b092-4876ec65df60 | net04 |
> b87fbfd1-0e52-4ab6-8987-286ef0912d1f 192.168.111.0/24 |
>
> +--+---+---+
>

root@node-2:~#


Such urllib3 based warnings is only particular case. Warnings may appear by
another reason while call any Openstack utilities.

Such warnings lead to broke work of puppet-neutron manifests:

> 2015-10-20 16:42:11 +
> /Stage[main]/Main/Openstack::Network::Create_network[net04]/Neutron_network[net04]
> (info): Evaluated in 5.51 seconds
> 2015-10-20 16:42:11 + Puppet (debug): Prefetching neutron resources
> for neutron_subnet
> 2015-10-20 16:42:11 + Puppet (debug): Executing '/usr/bin/neutron
> subnet-list --format=csv --column=id --quote=none'
> 2015-10-20 16:42:13 + Puppet (debug): Executing '/usr/bin/neutron
> subnet-show --format=shell InsecurePlatformWarning'
> 2015-10-20 16:42:16 + Puppet::Type::Neutron_subnet::ProviderNeutron
> (notice): Unable to complete neutron request due to non-fatal error:
> "Execution of '/usr/bin/neutron subnet-show --format=shell
> InsecurePlatformWarning' returned 1:
> /usr/lib/python2.7/dist-packages/urllib3/util/ssl_.py:90:
> InsecurePlatformWarning: A true SSLContext object is not available. This
> prevents urllib3 from configuring SSL appropriately and may cause certain
> SSL connections to fail. For more information, see
> https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
> InsecurePlatformWarning
> /usr/lib/python2.7/dist-packages/urllib3/connection.py:251:
> SecurityWarning: Certificate has no `subjectAltName`, falling back to check
> for a `commonName` for now. This feature is being removed by major browsers
> and deprecated by RFC 2818. (See
> https://github.com/shazow/urllib3/issues/497 for details.)
>   SecurityWarningUnable to find subnet with name 'InsecurePlatformWarning'
> ". Retrying for 7 sec.

 .

Unable to find subnet with name 'InsecurePlatformWarning'
> ". Retrying for 0 sec.
> 2015-10-20 16:42:25 + Puppet (debug): Executing '/usr/bin/neutron
> subnet-show --format=shell InsecurePlatformWarning'
> 2015-10-20 16:42:27 + Puppet (err): Could not prefetch neutron_subnet
> provider 'neutron': Can't retrieve subnet-show because Neutron or Keystone
> API is not available.
> /etc/puppet/modules/neutron/lib/puppet/provider/neutron.rb:153:in
> `get_neutron_resource_attrs'
> /etc/puppet/modules/neutron/lib/puppet/provider/neutron_subnet/neutron.rb:24:in
> `block in instances'
> /etc/puppet/modules/neutron/lib/puppet/provider/neutron_subnet/neutron.rb:23:in
> `collect'
> /etc/puppet/modules/neutron/lib/puppet/provider/neutron_subnet/neutron.rb:23:in
> `instances'
> /etc/puppet/modules/neutron/lib/puppet/provider/neutron_subnet/neutron.rb:43:in
> `prefetch'
> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:277:in `prefetch'
> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:167:in
> `prefetch_if_necessary'
> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:67:in `block in evaluate'


This happens, because Puppet mixing stderr and stdout while execute shell
commands, like

> commands :neutron => 'neutron'

And code, like

>
> https://github.com/openstack/puppet-neutron/blob/master/lib/puppet/provider/neutron.rb#L134-L146

parses stderr output also. Part of warnings gets into incoming data.

IMHO this situation is potential dangerous for all puppet-openstack
modules..

/sv

Re: [openstack-dev] [Fuel] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands

[Sergey Vasilenko]

On Thu, Oct 22, 2015 at 6:16 AM, Matt Fischer  wrote:

> I thought we had code in other places that split out stderr and only
> logged it if there was an actual error but I cannot find the reference now.
> I think that matches the original proposal. Not sure I like idea #3.


Matthew, this topic not about SSL. ANY warnings, ANY output to stderr from
CLI may corrupt work of providers from puppet-* modules for openstack
components.

IMHO it's a very serious bug, that potential affect openstack puppet
modules.

I see 3 way for fix it:

   1. Long way. big patch to puppet core for add ability to collect stderr
   and stdout separately. But most of existing puppet providers waits that
   stderr and stdout was mixed when handle errors of execution (non-zero
   return code). Such patch will broke backward compatibility, if will be
   enabled by default.
   2. Middle way. We should write code for redefine 'commands' method. New
   commands should collect stderr and stdout separately, but if error happens
   return stderr (with ability access to stdout too).
   3. Short way. Modify existing providers to use json output instead
   plain-text or csv. JSON output may be separated from any garbage (warnings)
   slightly. I make this patch as example of this way:
   https://review.openstack.org/#/c/238156/ . Anyway json more formalized
   format for data exchange, than plain text.

IMHO way #1 is a best solution, but not easy.

/sv
__
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][puppet] Detached roles and globals.pp

[Sergey Vasilenko]

On Wed, Nov 11, 2015 at 1:41 PM, Daniel Depaoli <
daniel.depa...@create-net.org> wrote:

> Hi all.
> I'm starting to resolve the todo at these line[1]. To solve this I think
> to hardcoded the role in the file, for example:
>
> *$swift_proxies = get_nodes_hash_by_roles($network_metadata,
> ['primary-swift-proxy', 'swift-proxy']) ? {*
> *true => get_nodes_hash_by_roles($network_metadata,
> ['primary-swift-proxy', 'swift-proxy']),*
> *false => get_nodes_hash_by_roles($network_metadata,
> ['primary-controller', 'controller']),*
> *}*
>
>
> Is this the right way or do you suggest something more clean?
>

Function *get_nodes_hash_by_roles returns *hash*. *Provided above switch
shouldn't work. But this way is true.
IMHO list of roles name should be constructed before.


/sv
__
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][CI] recheck/reverify support for Fuel CI jobs

[Sergey Vasilenko]

On Fri, Nov 20, 2015 at 4:00 PM, Alexey Shtokolov 
wrote:

> Probably we should use another keyword for Fuel CI to prevent an extra
> load on the infrastructure? For example "refuel" or smth like this?


IMHO we should have ability to restart each one of two deployment tests.
Often happens, that one test passed, but another fails while ENV setting
up. Restart both tests for this case does not required.


/sv
__
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]

[Sergey Vasilenko]

Guys, it's a big and complicated architecture issue.

Issue, like this was carefully researched about month ago (while P***)

root case of issue:

   - Now we use OVS for build virtual network topology on each node.
   - OVS has performance degradation while pass huge of small network
   packets.
   - We can’t abandon using OVS entirely and forever, because it's a most
   popular Neutron solution.
   - We can’t abandon using OVS partial now, because low-level modules
   don’t ready yet for this. I start blueprint (
   
https://blueprints.launchpad.net/fuel/+spec/l23network-refactror-to-provider-based-resources)
   for aim possibility of combine using OVS for Neutron purposes and don't use
   it for management, storage, etc... purposes.

We, together with L2 support team, Neutron team, and another network
experts make tuning one of existing production-like env after deployment
and achieve following values on bonds of two 10G cards:

   - vm-to-vm speed (on different compute nodes): 2.56 Gbits/sec (GRE
   segmentation)
   - node-to-node speed: 17.6 Gbits/s

This values closely near with theoretical maximum for OVS 1.xx with GRE.
Some performance improvements may also achieved by upgrading open vSwitch
to the latest LTS (2.3.1 at this time) branch and using "megaflow" feature (
http://networkheresy.com/2014/11/13/accelerating-open-vswitch-to-ludicrous-speed/
).


After this research we concluded:


   - OVS can't pass huge of small packages without network performance
   degradation
   - for fix this we should re-design network topology on env nodes
   - even re-designed network topology can't fix this issue at all. Some
   network parameters, like mtu, disabling offloading for NICs, buffers,
   etc... can be tuned only on real environment.


My opinion — in FUEL we should add new (or extend existing network-checker)
component.  This component should testing network performance on real
customer’s pre-configured env by different (already defined) performance
test cases and recommend better setup BEFORE main deployment cycle run.

/sv
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] removing single mode

[Sergey Vasilenko]

+1 to replace simple to HA with one controller

/sv
__
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][Fuel-Library] Nominating Alex Schultz to Fuel-Library Core

[Sergey Vasilenko]

+1

/sv
__
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] Nominate Evgeniy Konstantinov for fuel-docs core

[Sergey Vasilenko]

+1


/sv
__
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][Fuel-Library] Nominating Alex Schultz to Fuel-Library Core

[Sergey Vasilenko]

+1

/sv
__
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][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Sergey Vasilenko]

+1


/sv
__
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] network_metadata hash keys on astute.yaml

[Sergey Vasilenko]

Keys should be immutable.

If keys are not immutable -- it can lead to the situation, when
network_metadata/nodes contains two records for same nodes (with same UID),
but with different information.

/sv
__
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] Ceph Public Network Setting

[Sergey Vasilenko]

>
>
> I notice that in OpenStack deployed by Fuel, Ceph public network is on
> management network.


As I know separating cuph/public and management networks in a scope of 7.0
release.


/sv
__
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][Fuel-Library] Nominate Aleksandr Didenko for fuel-library core

[Sergey Vasilenko]

+1
__
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] Fuel library CI changes due to transition to Kilo

[Sergey Vasilenko]

>
> Let's set three voting jobs:
>
>  - master.fuel-library.pkgs.UBUNTU.ha_nova_vlan
>  - master.fuel-library.pkgs.ubuntu.ha_neutron_vlan
>  - master.fuellib_review_pkgs_master_node
>
> and one non-voting:
>
>  master.fuel-library.pkgs.centos.ha_NEUTRON_vlan
>
> All of them based on latest ISO with Kilo support.


I agree with this plan.
__
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] NodeGroups vs network-templates and static routes

[Sergey Vasilenko]

On Thu, Jul 16, 2015 at 10:53 PM, Andrew Woodward  wrote:

> Regardless of computing all the routes, we need to compute same role, but
> multi-segement routes. In this case I see that nodegroups becomes
> redundant. It's only value is that it may be a simpler interface then
> templates but it imposes the old network topology which I could see people
> wanting to get away from.


I do not agree with unnecessary node groups.
Yes, move route calculation is a good idea and I think we should implement
it.

But removing node groups... When we will implement multi-rack feature we
will need some abstraction for store rack-specific attributes. Node groups
are seems appropriate for this role.

/sv
__
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] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

[Sergey Vasilenko]

+1
__
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] FF Exception request for Templates for Networking feature

[Sergey Vasilenko]

On Mon, Jul 27, 2015 at 1:10 PM, Evgeniy L  wrote:

> Currently network template uses ERB [1] style template language,
> but in fact it's Jinja [2], it was agreed to change it [3], no to confuse
> the user, with ERB which is in fact jinja and doesn't have any ERB
> features.
>

we have not so much syntax choices for  convenient templating. Network
temptales will be used by system administrators.
The '<%  %>' pair is a de-facto standart in this area. In the puppet world.
Not every system administrator will meaning ERB when seeing '<% %>' pair.
Another pairs (i.e. '<$ $>' , '<< >>', etc) looks more non-standart. Plenty
of syntax features are annoy and make usability of product less convenient.
I propose do not make extra essences on the clean area...

We never say in the docs about ERB. IMHO it's enough for leave '<%  %>' as
is.


/sv
__
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] FF Exception request for Templates for Networking feature

[Sergey Vasilenko]

On Tue, Jul 28, 2015 at 11:52 AM, Evgeniy L  wrote:

> Hi Alexander, I don't agree with your statements
>
> >> [1] - I just uses <% and %> to substitute values.
>
> It's what templating is about, you have some text preprocessor to
> substitute values.
>

Network templates feature don't mean any  "text preprocessor" actions. Only
value substitutions


> >> That is not ERB style template language.
>
> ERB uses the same syntax, hence it Is ERB style.
>

... hence it looks like ERB. not more.
Not only ruby used for programming. Non only EBD -- is template language. ;)


> >> [2] - We are not using Jinja templating (it is just yaml file, not html
> template), we are using Jinja placeholder substitution.
>
> We *are using* jinja templating (I don't understand why you mention here
> html),
> with all it's features and here is the proof [1].
>

We don't promise use Junja (or whatever) template language for this feature.
If some jinja features allowed for parsing Network template -- it's a bug.
We should check it and fix it.
Only value substitutions should allow in the network templates.


> >> [3] - Templates are for people who do not care about Jinja/ERB (maybe
> some familiar with Puppet/Chef), so no confusion.
>
> That is not correct, every template has it's own syntax, so people have to
> care about
> specific implementation i.e. Jinja or ERB, and there will be confusion
> when somebody will
> try to use ERB specific features, and she/he will fail because you hide
> Jinja under ERB
> syntax.
>

I, partially, agree with you. But please honored to following facts:
* In the deployers world used Jinja and ERB syntax.
* ERB used more often, because Ansible (I don't know another popular
deployers tools with Jinja templating) is to young.
* Plenty of syntax features is a really hell.

In the Network templates we don't suppose anything other than a simple
substitution variable values.
All logic of template processing implementing on Nailgun side. Now on the
template parsing, later -- on the network manipulation class.
Allowance of mix template language and Nailgun logic may lead to heavy
diagnostic issues.
Meantime I don't see any cases, where required something more, than
substitution.



/sv
__
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] FF Exception request for Templates for Networking feature

[Sergey Vasilenko]

>
> If we need only substitution, probably it's better to use standard
> templating
> in python [1], there is a way to redefine tokens, so you will be able to
> use
> <% %> syntax if you want to.
>
> [1] https://docs.python.org/2.6/library/string.html#template-strings
> 
> [2] http://pymotw.com/2/string/#advanced-templates
>

I think it's a better solution for this issue.

/sv
__
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] FF Exception request for Templates for Networking feature

[Sergey Vasilenko]

On Tue, Jul 28, 2015 at 7:13 PM, Aleksey Kasatkin 
wrote:

> Evgeniy, do we need to remove jinja before July 30th ?
>

I think -- not.
It just a bug, not a key-point of feature.


/sv
__
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] Get rid of fuelmenu

[Sergey Vasilenko]

On Wed, Jul 29, 2015 at 7:08 AM, Mike Scherbakov 
wrote:

> Looks like Fuel Menu can't solve this one. Is there workaround possible
> (even with worse UX)?


add to fuel-menu ability to load yaml file with network scheme.
However, I can't predict how serial console can live with zmodem (or
something else serial communication protocol) on the same serial port.




/sv
__
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][CI] CI on commit message

[Sergey Vasilenko]

-1 to Maciej
+1 to Sergii



/sv
__
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] Get rid of fuelmenu

[Sergey Vasilenko]

On Wed, Jul 29, 2015 at 12:01 PM, Sergii Golovatiuk <
sgolovat...@mirantis.com> wrote:

>
> add to fuel-menu ability to load yaml file with network scheme.
>> However, I can't predict how serial console can live with zmodem (or
>> something else serial communication protocol) on the same serial port.
>>
>
> Why should we overcomplicate fuel-menu? It's supposed for master node
> configuration only. All other networks can/must be configured later.
>

Can you propose another solution for fuel-menu alternative, that can be
used on serial consoles and be so convenient for usage?


/sv
__
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] [UI] Sorting and filtering of node list

[Sergey Vasilenko]

+1, sorting is should be...

Paginating may be too, but not activated by default.


/sv
__
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] Nominate Irina Povolotskaya for fuel-docs core

[Sergey Vasilenko]

+1


/sv

On Fri, Mar 27, 2015 at 5:31 PM, Anastasia Urlapova 
wrote:

> + 10
>
> On Fri, Mar 27, 2015 at 4:28 AM, Igor Zinovik 
> wrote:
>
>> +1
>>
>> On 26 March 2015 at 19:26, Fabrizio Soppelsa 
>> wrote:
>> > +1 definitely
>> >
>> >
>> > On 03/25/2015 10:10 PM, Dmitry Borodaenko wrote:
>> >>
>> >> Fuelers,
>> >>
>> >> I'd like to nominate Irina Povolotskaya for the fuel-docs-core team.
>> >> She has contributed thousands of lines of documentation to Fuel over
>> >> the past several months, and has been a diligent reviewer:
>> >>
>> >>
>> >>
>> http://stackalytics.com/?user_id=ipovolotskaya&release=all&project_type=all&module=fuel-docs
>> >>
>> >> I believe it's time to grant her core reviewer rights in the fuel-docs
>> >> repository.
>> >>
>> >> Core reviewer approval process definition:
>> >> https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>> >>
>> >
>> >
>> >
>> __
>> > 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
>>
>>
>>
>> --
>> Igor Zinovik
>> Deployment Engineer at Mirantis, Inc
>> izino...@mirantis.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] [Fuel] Nominate Andrey Skedzinskiy for fuel-qa(devops) core

[Sergey Vasilenko]

+1
__
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-dev] [Fuel] Beta milestone of Fuel 5.1 now available!

[Sergey Vasilenko]

On Wed, Aug 27, 2014 at 2:11 AM, David Easter  wrote:

> What’s New in Fuel 5.1?
>
>  The primary new features of Fuel 5.1 are:
>

* Compute, cinder, ceph nodes has no external (public) network interface
and don't get public IP addresses if it's not necessary.


/sv
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Waiting for Haproxy backends

[Sergey Vasilenko]

>
> Nor should it, IMO. Other than the Neutron dhcp-agent, all OpenStack
> services that run on a "controller node" are completely stateless.
> Therefore, I don't see any reason to use corosync/pacemaker for management
> of these resources.


I see following reasons for managing neutron agents by Pacemaker:

   - *co-location* between resources. For example, L3 and DHCP agents
   should be run only on nodes, that has properly work openvswitch (or another
   L2) agent. Then L2-agent works wrong -- L3 and DHCP agents should be
   stopped immediately. Because Neutron don't control this situation and can
   allocate some resources (router or subnet) to an agent.
   - extended *monitoring*.  Traditional OS init/upstart subsystem allow
   only simple status checking (may be exclude systemd). Now we have
   situation, for example with neutron agents, then some of agent pretends to
   well-working. But in really, do nothing. (unfortunately, openstack
   developed as is) Such agent should be immediately restarted. Our Neutron
   team now works on internal health-checking feature for agents, and I hope,
   that this will implemented in 6.1. For example we can make simple checking
   (pid found, process started) every 10sec, and more deep (RMQ connection,
   internal health-checking) -- mo rare.
   - No different business-logic for different OS. We can use one OCF
   script for Ubuntu, Centos, debian, etc...
   - handle cluster partitioning situation.



> haproxy should just spread the HTTP request load evenly across all API
> services and things should be fine, allowing haproxy's http healthcheck
> monitoring to handle the simple service status checks.
>

Just HTTP checking not enough. In the future will be better make more deep
checking personal for each openstack service.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Neutron ML2 Blueprints

[Sergey Vasilenko]

After review https://review.openstack.org/#/c/103280/ I have following
thoughts. This patch looks fine, but huge and has lot of changes in
deployment logic. Parallel teams work (vmware, melanox) depends on current
implementation of Neutron in FUEL. I have a some dreads, that they can’t
refactor his code in the short time remaining.

Implementation https://review.openstack.org/#/c/103280 has considerably
less changes in current code of FUEL. Teams from MElanox and VMware based
their work on current implementation of Neutron. Also this implementation
was already tested in most deployment modes.

On this basis, I suggest:

   - to merge https://review.openstack.org/#/c/103280 in fuel-5.1
   - To base Neutron implementation for 6.0 get
   https://review.openstack.org/#/c/103280/ and start working for adapt
   this for Juno Neutron.
   - Also we should discuss how to make HA-wrapper more pluggable.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Neutron ML2 Blueprints

[Sergey Vasilenko]

[1] fixed in https://review.openstack.org/#/c/107046/
Thanks for report a bug.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Nominate Ilya Kutukov for the fuel-web-core team

[Sergey Vasilenko]

+1

/sv
On Jun 9, 2016 09:24, "Julia Aranovich"  wrote:

> +1
>
> On Wed, Jun 8, 2016 at 8:52 PM Bulat Gaifullin 
> wrote:
>
>> Hey Fuelers,
>>
>> I'd like to nominate Ilya Kutukov for the fuel-web-core team.
>> Ilya`s doing good reviews with detailed feedback [1],
>> and has implemented custom graph execution engine for Fuel.
>> Also Ilya`s implemented new database models for storing deployment tasks
>> in Fuel.
>>
>>
>> Fuel Cores, please reply back with +1/-1.
>>
>> [1] http://stackalytics.com/report/contribution/fuel-web/90
>>
>>
>> Regards,
>> Bulat Gaifullin
>> Mirantis Inc.
>>
>> __
>> 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] [Fuel] Nominate Artur Svechnikov to the fuel-web-core team

[Sergey Vasilenko]

+1


/sv
__
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] Need Help in adding multiple External networks in Fuel 9.0

[Sergey Vasilenko]

>
> eth0 : Admin ( PXE), Management (101), Storage (102), Internal (1000-1030)
> eth1 : External ( Public )
> eth2 : None
>
> I am using *fuel 9.0* and i want to use provider network / Multiple
> external networks with fuel. i had vlan networks on *eth1* as below
>
> *eth1 : 192.168.200.0/24  ( Native ),
> 192.168.201.0/24  ( Trunk, 201 tagged ).
> 192.168.202.0/24  ( Trunk, 202 tagged )*
>
>
> How i can add other two networks( 201, 202 ) to my cloud as external
> network. appreciate anyone help on this.
>

For creating tagged vlans over external network you should:
1. modify /etc/neutron/plugin.ini to add vlan-range for physnet1, (ex:
network_vlan_ranges
= physnet1:201:202) and restart neutron-server on all controller nodes
2. Create additional floating networks by  Neutron API, ex: neutron
net-create floating201 --tenant-id=8a1d1a6f96db4beeb964a285e2a95413
 --router:external=true --provider:physical_network=physnet1
--provider:network_type=vlan --provider:segmentation_id=201
3. Create subnet for network above (ex: neutron subnet-create xxx1
--name=floating201_subnet --cidr=192.168.201.0/24
--network-id=8859c63e-c8e1-422c-9cda-d3e9d5ab6a20 --enable_dhcp=False
--gateway_ip=192.168.201.1)
4. Create router for handle SNAT:
# neutron router-create router201
--tenant-id=8a1d1a6f96db4beeb964a285e2a95413
# neutron router-gateway-set router201 floating201
# neutron router-interface-add router201 your_internal_net
__
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] Propose Denis Egorenko for fuel-library core

[Sergey Vasilenko]

+1


/sv
__
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-library] Nominate Stanislaw Bogatkin to fuel-library core

[Sergey Vasilenko]

+1
__
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] Nominate Ilya Kutukov for fuel-plugins-core

[Sergey Vasilenko]

+1
__
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