Open Stack

With tags we can boot instances to a specified host aggregate.
But in case when we need boot instances to a specified host, available zone is a good approach.
Otherwise, we need to provide tagged flavors for each host. In real use I think it's quite impossible.

Best regards,
Leehom Li


From: Fawaz Mohammed <fawaz.moh.ibraheem at gmail.com<mailto:fawaz.moh.ibraheem at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Monday, August 22, 2016 at 4:43 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [NOVA] How boot an instance on specific compute with provider-network: physnet1


Cloud admin can add the necessary tags in the tenant flavors.

On Aug 22, 2016 12:00 AM, "Jay Pipes" <jaypipes at gmail.com<mailto:jaypipes at gmail.com>> wrote:
On 08/21/2016 03:24 PM, Fawaz Mohammed wrote:
I belive utilizing host aggregate is better than availability zone in
this case.

Users don't know anything about host aggregates. They are a cloud-admin-only way of grouping like compute resources together and the end user doesn't have any way of specifying a particular host aggregate when launching an instance.

Best,
-jay

On Aug 19, 2016 8:33 PM, "Leehom Li (feli5)" <feli5 at cisco.com<mailto:feli5 at cisco.com>
<mailto:feli5 at cisco.com<mailto:feli5 at cisco.com>>> wrote:

    Hi, All

    I used to use below command to boot an instance with a specified IP
    address to a
    Specified compute node.

    nova boot
    --image <image-id> \
    --flavor <flavor-id> \
    --nic net-id=<network-id>,v4-fixed-ip=<ip addr> \
    --availability-zone <AZ>:<host>
    <Name>



    May it helps.

    leehom

    On 8/17/16, 11:53 PM, "Géza Gémes" <geza.gemes at ericsson.com<mailto:geza.gemes at ericsson.com>
    <mailto:geza.gemes at ericsson.com<mailto:geza.gemes at ericsson.com>>> wrote:

    >On 08/17/2016 05:38 PM, Rick Jones wrote:
    >> On 08/17/2016 08:25 AM, Kelam, Koteswara Rao wrote:
    >>> Hi All,
    >>>
    >>> I have two computes
    >>>
    >>> Compute node 1:
    >>> 1. physnet3:br-eth0
    >>>
    >>> 2. physnet2: br-eth2
    >>>
    >>> Compute node 2:
    >>> 1. physnet3:br-eth0
    >>> 2. physnet1:br-eth1
    >>> 3. physnet2:br-eth2
    >>>
    >>> When I boot an instance with a network of provider-network physnet1,
    >>> nova is scheduling it on compute1 but there is no physnet1 on
    compute1
    >>> and it fails.
    >>>
    >>> Is there any mechanism/way to choose correct compute with correct
    >>> provider-network?
    >>
    >> Well, the --availability-zone option can be given a host name
    >> separated from an optional actual availability zone identifier by a
    >> colon:
    >>
    >> nova boot .. --availability-zone :hostname ...
    >>
    >> But specifying a specific host rather than just an availability zone
    >> requires the project to have forced_host (or is it force_host?)
    >> capabilities.  You could, perhaps, define the two computes to be
    >> separate availability zones to work around that.
    >>
    >> rick jones
    >>
    >>
    >>
    >>_________________________________________________________________________
    >>_
    >>
    >> OpenStack Development Mailing List (not for usage questions)
    >> Unsubscribe:
    >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
    <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
    >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
    >
    >Hi,
    >
    >Does it help if you boot your VMs, with pre-created neutron ports,
    >rather than a neutron network? I think nova is supposed to bind
    then and
    >failing that it shall rescedule the VM (up to the configured
    re-schedule
    >attempts (3 by default)). I think this is an area, where e.g. one
    of the
    >physnet would relate to an SRIOV PF the PciDeviceFilter would be
    able to
    >select the right host from beginning.
    >
    >Cheers,
    >
    >Geza
    >
    >
    >__________________________________________________________________________
    >OpenStack Development Mailing List (not for usage questions)
    >Unsubscribe:
    OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
    <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
    >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>


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



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160822/e14ed1c9/attachment.html>