Re: [openstack-dev] [nova] How can i check if an instance belongs to host-aggregate

[Ligong LG1 Duan]

Not sure what your use case is.
But basically, you can get the list of compute nodes belonging to one host 
aggregate and then, get the virtual instances on each compute nodes in the list.

Regards,
Ligong Duan


From: Pradeep Singh [mailto:ps4openst...@gmail.com]
Sent: Wednesday, March 29, 2017 4:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova] How can i check if an instance belongs to 
host-aggregate

Hello,

I want to filter out some instances(to avoid some operation on them) which are 
scheduled on  host-aggregates.

How can i filter out these instances from all instances list in my cloud.

Thanks in advance!!

Thanks,
Pradeep Singh
__
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] [tripleo][diskimage-builder] Status of diskimage-builder

[Ligong LG1 Duan]

I agree that the idea of DIB's becoming a component of Glance is a little crazy 
and there is big difference between creating images and storing them.
My initial thought on this is to create an ecosystem of images, where user can 
do anything that are related to images. Since Glance is a well-known project 
for storing images, it might be a good place to implement that.
I would be prefer DIB to be an independent project if it is impossible to 
become a part of Glance.

Regards,
Ligong Duan
 

-Original Message-
From: Ben Nemec [mailto:openst...@nemebean.com] 
Sent: Saturday, March 04, 2017 3:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tripleo][diskimage-builder] Status of 
diskimage-builder



On 03/03/2017 03:25 AM, Ligong LG1 Duan wrote:
> I am wondering whether DIB can become a component of Glance, as DIB is used 
> to create OS images and Glance to upload OS images.

I see a big difference between creating images and storing them.  I can't 
imagine Glance would have any interest in owning dib, nor do I think they 
should.

__
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] [tripleo][diskimage-builder] Status of diskimage-builder

[Ligong LG1 Duan]

I am wondering whether DIB can become a component of Glance, as DIB is used to 
create OS images and Glance to upload OS images.

Regards,
Ligong Duan 

-Original Message-
From: Matthew Thode [mailto:prometheanf...@gentoo.org] 
Sent: Friday, March 03, 2017 9:36 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tripleo][diskimage-builder] Status of 
diskimage-builder

On 03/02/2017 03:31 PM, Emilien Macchi wrote:
>>> 1) Move diskimage-builder into own (big tent?) project. Setup a new 
>>> PTL, etc.
> Let's move forward with this one if everybody agrees on that.
> 
> DIB folks: please confirm on this thread that you're ok to move out 
> DIB from TripleO and be an independent project.
> Also please decide if we want it part of the Big Tent or not (it will 
> require a PTL).
> 
>>> 2) Move diskimage-builder into openstack-infra (fungi PTL).
> I don't think Infra wants to carry this one.
> 
>>> 3) Keep diskimage-builder under tripleo (EmilienM PTL).
> We don't want to carry this one anymore for the reasons mentioned in 
> that thread.
> 

As a sometimes contributor to DIB for Gentoo stuff I'm fine with moving it out 
into it's own project under the big tent, with a PTL and all.

--
Matthew Thode (prometheanfire)


__
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] [tripleo] Fwd: Do you want to ask a project-specific question on the next User Survey?

[Ligong LG1 Duan]

I would like to ask:
· Which deployment tool of OpenStack are you using, TripleO or Fuel or 
Kolla or your customized tool?

Regards,
Ligong Duan

From: arkady.kanev...@dell.com [mailto:arkady.kanev...@dell.com]
Sent: Monday, January 09, 2017 12:30 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tripleo] Fwd: Do you want to ask a 
project-specific question on the next User Survey?

Suggest we request a question on life-cycle management tools, including 
TripleO, like upgrade, patching, etc. Not just deployment.
Arkady

From: Emilien Macchi [mailto:emil...@redhat.com]
Sent: Tuesday, January 03, 2017 8:08 AM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [tripleo] Fwd: Do you want to ask a project-specific 
question on the next User Survey?

(Happy new year folks!)

Forwarding Heidi's email to TripleO folks, so anyone can contribute to it.

Feel free to propose questions on:
https://etherpad.openstack.org/p/tripleo-user-survey-2017

The question with the more voting, will be proposed to the survey.
Please take 2 min and help on $topic, it will be very helpful.

Thanks,

-- Forwarded message --
From: Heidi Joy Tretheway 
mailto:heidi...@openstack.org>>
Date: Thu, Dec 22, 2016 at 4:58 PM
Subject: Do you want to ask a project-specific question on the next User Survey?
To: Jimmy McArthur mailto:ji...@openstack.org>>, Lauren 
Sell mailto:lau...@openstack.org>>
Greetings,

I wanted to offer you the opportunity to ask a question on the upcoming User 
Survey, which launches on or before Feb. 1. Each PTL of a project with 
significant adoption can submit one question. You can decide which audience to 
serve the question to - those who are USING, TESTING, or INTERESTED in your 
project (or some combination of these).

My hope is to gather as much information as possible to help you, and send it 
all raw, without commentary, in advance of the Project Team Gathering in late 
February.

The deadline to submit is Jan. 9.

Feel free to drop me a note if I can answer any questions for you!

Best,
Heidi Joy


[Image removed by sender. photo]

Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation
503 816 9769 | Skype: 
heidi.tretheway
[Image removed by sender.] [Image 
removed by sender.]   [Image removed by 
sender.] 







--
Emilien Macchi
__
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][heat][mistral][magnum] Manage Ironic resource in Orchestration.

[Ligong LG1 Duan]

I think it is a good idea to use OpenStack to manage the steps of 1) and 2).
Currently we are using Ansible playbook to implement 1) and 2) and then using 
Magnum to provision a container COE on baremetals. And it would be better if we 
use Heat or Mistral to implement the same but if we want to implement it in 
Heat, first we need to implement an IronicClient in Heat engine if there is no 
IronicClient in Heat. (I remember that there was a discussion on IronicClient 
in Heat but not sure whether it has been implemented.)

Regards,
Ligong Duan

From: Rico Lin [mailto:rico.lin.gua...@gmail.com]
Sent: Monday, December 12, 2016 4:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [ironic][heat][mistral][magnum] Manage Ironic resource 
in Orchestration.

Think about bare metal (ironic) deployment, we can do directly ironic call, or 
use nova to deploy.
Right now I have a spec about implemented Ironic resources [1] in Heat. 
Including Chassis, Port and some state setting feature for Node (including 
node-set-xxx). In heat team discussion, we tend to not implement Node 
deployment feature.

If we counting Ironic action into three parts:
1. Create the node in the ironic DB
2. Do a series of steps to get the node in a state where it's ready for 
deployment (this may include introspection via ironic-inspector, or just 
changing the state)
3. Select a node and drive a workflow that deploys an image on it.

We can do in Heat is to use Nova on (3) and hope someone already handles on (1) 
and (2). If we consider (1) and (2) also part of Heat resources, we can 
actually make entire management done in heat template.

The use case in my head was ironic+magnum case:
Ironic resource handles state we need, then through magnum resource, nova will 
deploy that baremetal node and config it as part of COE.

The open question is if heat really implemented such feature, who will benefit 
from it and how are they going to use it? We certainly don't want to implement 
something that no one will use it or not even think it's a good idea.
And which projects might be a good fit if it's not a good idea to do in heat?
We can also think about the possibility of implement it with putting it in Nova 
resource in heat if it's a baremetal case, Heat+Mistral, or just Mistral will 
do.
Any idea or use cases?


[1] https://review.openstack.org/#/c/393108
--
May The Force of OpenStack Be With You,


__
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