← Back to team overview

fuel-dev team mailing list archive

Re: Documentation bug? Public addresses on all nodes

 

I think I have this document correct now -- I tried some fancier formatting
but ran into some formatting problems
with our tools.

We also need to recheck
http://docs.mirantis.com/openstack/fuel/master/operations.html#adding-redeploying-and-replacing-nodes
in conjunction with this.  When I use Fuel to add, say, Controller nodes to
the environment, does Fuel allocate additional Public
IP addresses for the new nodes or do I need to do that as part of adding
the nodes?

meg

On Mon, Sep 15, 2014 at 2:55 AM, Aleksey Kasatkin <akasatkin@xxxxxxxxxxxx>
wrote:

> Agree, it should be clear as much as possible.
>
> I can imagine three-column two-string table with columns: environment,
> Public IPs in HA mode, Public IPs in non-HA mode or
> two-column four-string one with columns: environment, Public IPs (HA,
> non-HA is separate strings).
>
> About terminology: let's name nodes by roles names we use to not confuse
> someone: cinder, ceph, mongo.
>
>
>
> Aleksey Kasatkin
>
>
> On Mon, Sep 15, 2014 at 12:35 PM, Meg McRoberts <mmcroberts@xxxxxxxxxxxx>
> wrote:
>
>> About the example...  I'm thinking that I should go back to the old
>> definition of the environment here,
>> then maybe present the information about the requisite number of IPs in a
>> table.
>>
>> And I need to figure out a way that isn't totally cumbersome to reflect
>> that one set of numbers is for
>> all 5.0.x environments, 5.1 Nova-network environments, and 5.1 Neutron
>> environments that specify
>> "Assign public network to all nodes".
>>
>> BTW, a terminology question: for a discussion like this, do you consider
>> Zabbix nodes to be separate
>> from Compute and Storage nodes?  What about MongoDB nodes?  Someone said
>> that a MongoDB node
>> is really a storage node.  I'm not sure...
>> meg
>>
>> On Mon, Sep 15, 2014 at 2:09 AM, Meg McRoberts <mmcroberts@xxxxxxxxxxxx>
>> wrote:
>>
>>> Thanks so much for clearing that up, Aleksey -- I did not understand
>>> that.
>>> I just modified the source -- I need to rework the example (which need to
>>> be examples now) but I marked it as Neutron (default behavior) for now.
>>>
>>> meg
>>>
>>> On Mon, Sep 15, 2014 at 1:10 AM, Aleksey Kasatkin <
>>> akasatkin@xxxxxxxxxxxx> wrote:
>>>
>>>> Please note that Public network is always allocated to all nodes in
>>>> case of Nova-Network:
>>>>
>>>>
>>>> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/objects/node.py#L152-154
>>>>
>>>> Changes affect Neutron-enabled deployments only.
>>>>
>>>>
>>>> Aleksey Kasatkin
>>>>
>>>>
>>>> On Sat, Sep 13, 2014 at 12:39 AM, Dmitry Borodaenko <
>>>> dborodaenko@xxxxxxxxxxxx> wrote:
>>>>
>>>>> Good point, we need to update this. Note that the special case is just
>>>>> for compute nodes with nova-network (HA vs non-HA is not relevant
>>>>> since it only impacts configuration of controllers, and they always
>>>>> are allocated public IP addresses).
>>>>>
>>>>> On Fri, Sep 12, 2014 at 1:41 PM, Meg McRoberts <
>>>>> mmcroberts@xxxxxxxxxxxx> wrote:
>>>>> > It looks like we need to update the documentation about Public and
>>>>> Floating
>>>>> > IPs:
>>>>> >
>>>>> >
>>>>> http://docs.mirantis.com/openstack/fuel/master/reference-architecture.html#public-and-floating-ip-address-requirements
>>>>> >
>>>>> > I think I should change, "Each deployed node requires one IP address
>>>>> from
>>>>> > the Public network"
>>>>> > to "Each controller and Zabbix node..." -- this applies to both Nova
>>>>> and
>>>>> > Neutron.
>>>>> >
>>>>> > I will also need to rework the example.
>>>>> >
>>>>> > What about the single-node HA-ready deployment?  Does that still
>>>>> need the
>>>>> > extra IP address?
>>>>> >
>>>>> > Thanks,
>>>>> > meg
>>>>> >
>>>>> > On Fri, Sep 12, 2014 at 11:38 AM, Dmitry Borodaenko
>>>>> > <dborodaenko@xxxxxxxxxxxx> wrote:
>>>>> >>
>>>>> >> For the reference, this was fixed under this bug:
>>>>> >> https://bugs.launchpad.net/fuel/+bug/1272349
>>>>> >>
>>>>> >> Here's a fuel-docs review updating the release notes for 5.1, I've
>>>>> >> added a note about this there:
>>>>> >> https://review.openstack.org/117672
>>>>> >>
>>>>> >> On Fri, Sep 12, 2014 at 1:07 AM, Aleksey Kasatkin
>>>>> >> <akasatkin@xxxxxxxxxxxx> wrote:
>>>>> >> > Yes, 'public' is not assigned to all nodes in case of Neutron.
>>>>> Though it
>>>>> >> > can
>>>>> >> > be assigned optionally. Documentation is to be fixed.
>>>>> >> >
>>>>> >> >
>>>>> >> > Aleksey Kasatkin
>>>>> >> >
>>>>> >> >
>>>>> >> > On Fri, Sep 12, 2014 at 10:41 AM, Jesse Pretorius
>>>>> >> > <jesse.pretorius@xxxxxxxxx> wrote:
>>>>> >> >>
>>>>> >> >> The release notes in master have this note under 'Other
>>>>> limitations':
>>>>> >> >>
>>>>> >> >> Deployments done through the Fuel UI create all of the networks
>>>>> on all
>>>>> >> >> servers even if they are not required by a specific role. For
>>>>> example,
>>>>> >> >> a
>>>>> >> >> Cinder node has VLANs created and addresses obtained from the
>>>>> public
>>>>> >> >> network.
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> I don't think that this is true for 5.1 onwards - there was some
>>>>> work
>>>>> >> >> done
>>>>> >> >> recently to change this behaviour... well, I think it's all
>>>>> merged now?
>>>>> >> >>
>>>>> >> >> --
>>>>> >> >> Mailing list: https://launchpad.net/~fuel-dev
>>>>> >> >> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>>>> >> >> Unsubscribe : https://launchpad.net/~fuel-dev
>>>>> >> >> More help   : https://help.launchpad.net/ListHelp
>>>>> >> >>
>>>>> >> >
>>>>> >> >
>>>>> >> > --
>>>>> >> > Mailing list: https://launchpad.net/~fuel-dev
>>>>> >> > Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>>>> >> > Unsubscribe : https://launchpad.net/~fuel-dev
>>>>> >> > More help   : https://help.launchpad.net/ListHelp
>>>>> >> >
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Dmitry Borodaenko
>>>>> >>
>>>>> >> --
>>>>> >> Mailing list: https://launchpad.net/~fuel-dev
>>>>> >> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>>>> >> Unsubscribe : https://launchpad.net/~fuel-dev
>>>>> >> More help   : https://help.launchpad.net/ListHelp
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dmitry Borodaenko
>>>>>
>>>>
>>>>
>>>
>>
>

Follow ups

References