[openstack-dev] [ironic] Stepping down as core

[Sam Betts (sambetts)]

As many of you will have seen on IRC, I've mostly been appearing AFK for the 
last couple of development cycles. Due to other tasks downstream most of my 
attention has been drawn away from upstream Ironic development. Going forward 
I'm unlikely to be as heavily involved with the Ironic project as I have been 
in the past, so I am stepping down as a core contributor to make way for those 
more involved and with more time to contribute.

That said I do not intend to disappear, Myself and my colleagues plan to 
continue to support the Cisco Ironic drivers, we just won't be so heavily 
involved in core ironic development and its worth noting that although I might 
appear AFK on IRC because my main focus is on other things, I always have an 
ear to the ground and direct pings will generally reach me.

I will be in Berlin for the OpenStack summit, so to those that are attending I 
hope to see you there.

The Ironic project has been (and I hope continues to be) an awesome place to 
contribute too, thank you

Sam Betts
sambetts

__
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][bifrost][sushy][ironic-inspector][ironic-ui][virtualbmc] sub-project/repository core reviewer changes

[Sam Betts (sambetts)]

+1

Sam

On 23/08/2018, 21:38, "Mark Goddard" 
mailto:m...@stackhpc.com>> wrote:

+1

On Thu, 23 Aug 2018, 20:43 Jim Rollenhagen, 
mailto:j...@jimrollenhagen.com>> wrote:
++


// jim

On Thu, Aug 23, 2018 at 2:24 PM, Julia Kreger 
mailto:juliaashleykre...@gmail.com>> wrote:
Greetings everyone!

In our team meeting this week we stumbled across the subject of
promoting contributors to be sub-project's core reviewers.
Traditionally it is something we've only addressed as needed or
desired by consensus with-in those sub-projects, but we were past due
time to take a look at the entire picture since not everything should
fall to ironic-core.

And so, I've taken a look at our various repositories and I'm
proposing the following additions:

For sushy-core, sushy-tools-core, and virtualbmc-core: Ilya
Etingof[1]. Ilya has been actively involved with sushy, sushy-tools,
and virtualbmc this past cycle. I've found many of his reviews and
non-voting review comments insightful and willing to understand. He
has taken on some of the effort that is needed to maintain and keep
these tools usable for the community, and as such adding him to the
core group for these repositories makes lots of sense.

For ironic-inspector-core and ironic-specs-core: Kaifeng Wang[2].
Kaifeng has taken on some hard problems in ironic and
ironic-inspector, as well as brought up insightful feedback in
ironic-specs. They are demonstrating a solid understanding that I only
see growing as time goes on.

For sushy-core: Debayan Ray[3]. Debayan has been involved with the
community for some time and has worked on sushy from early on in its
life. He has indicated it is near and dear to him, and he has been
actively reviewing and engaging in discussion on patchsets as his time
has permitted.

With any addition it is good to look at inactivity as well. It saddens
me to say that we've had some contributors move on as priorities have
shifted to where they are no longer involved with the ironic
community. Each person listed below has been inactive for a year or
more and is no longer active in the ironic community. As such I've
removed their group membership from the sub-project core reviewer
groups. Should they return, we will welcome them back to the community
with open arms.

bifrost-core: Stephanie Miller[4]
ironic-inspector-core: Anton Arefivev[5]
ironic-ui-core: Peter Peila[6], Beth Elwell[7]

Thanks,

-Julia

[1]: http://stackalytics.com/?user_id=etingof=marks
[2]: http://stackalytics.com/?user_id=kaifeng=marks
[3]: http://stackalytics.com/?user_id=deray=marks=all
[4]: http://stackalytics.com/?metric=marks=all_id=stephan
[5]: http://stackalytics.com/?user_id=aarefiev=marks
[6]: http://stackalytics.com/?metric=marks=all_id=ppiela
[7]: 
http://stackalytics.com/?metric=marks=all_id=bethelwell=ironic-ui

__
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] [ironic] Monthly bug day?

[Sam Betts (sambetts)]

100% on board with this, I think it was really productive!

Sam

On 23/04/2018, 15:44, "Jim Rollenhagen" 
> wrote:

On Mon, Apr 23, 2018 at 8:04 AM, Michael Turek 
> wrote:
Hey everyone!

We had a bug day about two weeks ago and it went pretty well! At last week's 
IRC meeting the idea of having one every month was thrown around.

What does everyone think about having Bug Day the first Thursday of every month?

I'd totally support a monthly bug day! I'm not sure Thursday is the best day 
for me but I may be able to make it work.

// jim
__
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] Nominating Hironori Shiina for ironic-core

[Sam Betts (sambetts)]

+1

On 09/02/2018, 04:36, "Shivanand Tendulker" 
> wrote:

+1

On Wed, Feb 7, 2018 at 11:53 AM, John Villalovos 
> wrote:
+1

On Mon, Feb 5, 2018 at 10:12 AM, Julia Kreger 
> wrote:
I would like to nominate Hironori Shiina to ironic-core. He has been
working in the ironic community for some time, and has been helping
over the past several cycles with more complex features. He has
demonstrated an understanding of Ironic's code base, mechanics, and
overall community style. His review statistics are also extremely
solid. I personally have a great deal of trust in his reviews.

I believe he would make a great addition to our team.

Thanks,

-Julia

__
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] [Ironic] Removal of tempest plugin code from openstack/ironic & openstack/ironic-inspector

[Sam Betts (sambetts)]

Quick update for third party CI owners, if you are using 
“DEVSTACK_GATE_TEMEPST_ALL_PLUGIN=1” in your CI you will need to disable that 
and use the TEMPEST_PLUGINS+= in your local config as described below to enable 
*only* the ironic-tempest-plugin. If you have …TEMPEST_ALL_PLUGIN=1 set it’ll 
load both versions of the tempest plugin (from ironic and 
ironic-tempest-plugin) in a non-deterministic order resulting in 
non-deterministic results from your CI.

Sam

On 19/12/2017, 16:54, "John Villalovos" 
> wrote:

Please feel free to reach out to me (jlvillal) on IRC (#openstack-ironic) or 
here if anyone has questions on how to transition over. For our Ironic jobs it 
was about a 4 line change per job.

See the openstack/ironic patch here: https://review.openstack.org/#/c/527730/

Basically need to bring in the openstack/ironic-tempest-plugin project
And then change TEMPEST_PLUGINS references to /opt/stack/new/ironic to 
/opt/stack/new/ironic-tempest-plugin:

-export DEVSTACK_LOCAL_CONFIG+=$'\n'"TEMPEST_PLUGINS+=' /opt/stack/new/ironic'"
+export DEVSTACK_LOCAL_CONFIG+=$'\n'"TEMPEST_PLUGINS+=' 
/opt/stack/new/ironic-tempest-plugin'"

On Tue, Dec 19, 2017 at 7:50 AM, 
> wrote:

Dell - Internal Use - Confidential
Dell Ironic Ci is failing on this patch because of that. With holidays and many 
on vacation, would appreciate some additional time to make the switch.
Thanks
Rajini

From: Ruby Loo [mailto:opensr...@gmail.com]
Sent: Tuesday, December 19, 2017 8:48 AM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Ironic] Removal of tempest plugin code from 
openstack/ironic & openstack/ironic-inspector



On Mon, Dec 18, 2017 at 11:29 PM, 
> wrote:
Thanks for response.
My recommendation is:
1. only allow patches into openstack/ironic-tempest-plugin
2. Give Ironic CI owners time period (3 weeks?) to switch their setup to only 
use openstack/ironic-tempest-plugin and not master and report back to Ironic CI 
team if it works for them. If yes, go ahead and switch if not, report back.
3. At the end of that time, if majority of Ironic CI site complete their  
transition to ironic-tempest-plugin we switch.

Thanks,
Arkady

I think this is reasonable. I cringe at knowingly doing something that will 
most likely break the third party CI when people are away and cannot address 
it. Also, apart from the danger that the third party CIs are running old 
versions of the tempest plugins (I doubt that we'll be doing major overhaul of 
that in the next 2+ weeks), the reason we have 3rd party CI is to make sure 
patches work against those HW. Having most or all of them being unavailable due 
to this breakage means that there won't be any feedback that someone's code 
would have broken 3rd party CI outside of the tempest changes.

John, don't you have a patch that removes the tempest plugin from master? Do 
most/all of the 3rd party CIs fail due to that? (Or is it not as simple as 
that?) Ah, yes, https://review.openstack.org/#/c/527733/ shows that all the 3rd 
party CI fail (although I don't know if it is due to that patch or if they were 
already failing prior to that).

--ruby

__
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] [ironic] How is the interface for tftpboot server typically configured on OVS ?

[Sam Betts (sambetts)]

There are multiple options for doing this, but I suggest avoiding manually 
plumbing anything into OVS as it can lead to some nastiness in the future.

My personal recommended way to do this is to create the provisioning network in 
neutron with a known VLAN and trunk it separately down to the ironic services.

To do this first exclude the chosen VLAN from the range of tenant provisionable 
VLANs, and then create the provisioning network in neutron with the 
--physical-network  and --segmentation-id  flags.

Next you need to create the subnet for that network, and we know that we need 
to run the ironic services (like TFTP on this network) so when you create the 
subnet you need to exclude some IP addresses from the allocation pool (these IP 
address will be statically assigned by us outside of neutron’s control) for 
example subnet CIDR 10.0.0.0/24, allocation-pool: 10.0.0.1, 10.0.0.250 will 
give us 4 IPs for ironic services.

Then on my Ironic services server I trunk the provisioning VLAN down on an 
interface that isn’t assigned to a bridge/given to neutron (normally I use the 
same network interface which is used for inter-service communication e.g. eth0 
when eth1 is assigned to neutron) and then create a VLAN sub-interface on that 
NIC e.g. eth0. and assign it one of the IP addresses I 
reserved from the allocation pool earlier.

The Ironic TFTP server, the Ironic API, and conductor for provisioning then 
operate over this IP address/network interface.

Then when I need to scale up our Ironic services, I can replicate the same 
trunk and sub-interface on each conductor server assigning a different one of 
the reserved IPs to each, letting our ironic services happily scale up 
horizontally as intended.

Sam

On 12/10/2017, 23:42, "Waines, Greg" 
> wrote:

Hey,

We are in the process of integrating OpenStack Ironic into our own OpenStack 
Distribution.

One of the areas that we cannot find a good description of is:
How is the interface for the tftpboot server typically configured on OVS ?

i.e.

· i know tftpboot server runs on the same node as ironic-conductor,

· i know tftpboot server needs to have an interface on the 
‘provisioning’ tenant network, and

· i know the tftpboot server IP address and the ‘provisioning’ network 
are configured in ironic.conf

· BUT

o   how is the interface on the ‘provisioning’ tenant network configured for 
tftpboot server ?

§  i.e. how is it configured on OVS ?

· assuming it would be an OVS virtual port that would be connected to
the ‘provisioning’ tenant network

§  i.e. how is this done upstream ?
e.g.

· is a TAP(?) interface configured ?
and

· is a Neutron Port configured on the ‘provisioning’ tenant network,
with a reserved IP Address from ‘provisioining’ tenant network’s subnet and
 a MAC address from TAP interface ?
and

· the L2-Agent manages the binding of the TAP Interface to the
‘provisioning’ tenant network within OVS ?

Can anybody point me to or provide a detailed description of how this is done 
upstream ?

thanks in advance,
Greg.
__
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] Proposing Shivanand Tendulker for ironic-core

[Sam Betts (sambetts)]

+1,

Sam

On 03/10/2017, 08:21, "tua...@vn.fujitsu.com" 
> wrote:

+1 , Yes, I definitely agree with you.

Regards
Tuan

From: Nisha Agarwal [mailto:agarwalnisha1...@gmail.com]
Sent: Tuesday, October 03, 2017 12:28 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [ironic] Proposing Shivanand Tendulker for 
ironic-core

+1

Regards
Nisha

On Mon, Oct 2, 2017 at 11:13 PM, Loo, Ruby 
> wrote:
+1, Thx Dmitry for the proposal and Shiv for doing all the work :D

--ruby

From: Dmitry Tantsur >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, October 2, 2017 at 10:17 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [ironic] Proposing Shivanand Tendulker for ironic-core

Hi all!
I would like to propose Shivanand (stendulker) to the core team.

His stats have been consistently high [1]. He has given a lot of insightful 
reviews recently, and his expertise in the iLO driver is also very valuable for 
the team.
As usual, please respond with your comments and objections.
Thanks,
Dmitry

[1] http://stackalytics.com/report/contribution/ironic-group/90

__
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



--
The Secret Of Success is learning how to use pain and pleasure, instead
of having pain and pleasure use you. If You do that you are in control
of your life. If you don't life controls 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

Re: [openstack-dev] [ironic] [release] [stable] pike release

[Sam Betts (sambetts)]

Quick reply with my thoughts in-line.

Sam

On 21/08/2017, 10:13, "Dmitry Tantsur"  wrote:

(adding the release and stable team just for their information)

Thanks Julia and everyone for handling this situation while I was out. More 
comments inline.

On 08/17/2017 07:13 PM, Julia Kreger wrote:
> Greetings everyone!
> 
> As some of you may have noticed, we released ironic 9.0.0 today. But
> wait! There is more!
> 
> We triggered this release due to a number of issues, one of which was
> that we learned that we needed the stable/pike branch for our grenade
> jobs to execute properly. This was not done previously because
> Ironic’s release model is incompatible with making release candidate
> releases.

Yep :( So, I think the lesson to learn is to create our stable/XXX branch 
at the 
same time as the other projects. We kind of knew that already, but did not 
anticipate such a huge breakage so quickly. I suggest we don't try it in 
Queens :)

Now, with that in place we still have two options:
1. A conservative one - make the branching the hard feature freeze, similar 
to 
other projects. We may start with a soft freeze at around M3, and just move 
into 
Queens when stable/queens is created. As that point, what is out - is out.
2. Alternative - continue making selected feature backports until the final 
freeze roughly one week before the final release. This kind of contradicts 
calling a branch "stable" though.

I don't have a strong opinion, but I'm slightly more in favor of the 
conservation option #1 to avoid confusing people and complicating the 
process.

Thoughts?

Personally, I think option 2 still makes sense, and it aligns us closely with 
the process in the other projects, the difference between us and them is that 
their branch is cut using a release candidate instead of a real release. The 
act of backporting things into the stable branch and then re-releasing is the 
same though.

Another alternative I wonder if we should consider is cutting our branch 
earlier in the cycle, when we make our first intermediary release, and then 
finding out if we can sync the branches at each release time instead of 
backporting everything. E.g. git checkout stable/X, git reset –hard 
origin/master or git rebase master, git push. Doing this will allow us to 
retain the git history and same commit ids from master to stable/X until master 
stops developing stable/X and moves on to stable/X+1. I think another advantage 
of this is it also allows people to find and use our latest intermediary 
releases easier. But I don’t know how nicely this would work with all the 
tooling etc the release team has in place.

> 
> Once we’ve confirmed that our grenade testing is passing, we will back
> port patches we had previously approved, but that had not landed, from
> master to stable/pike.

++ I've approved a few patches already, and will continue approving them 
today.

> 
> As a result, please anticipate Ironic’s official Pike release for this
> cycle to be 9.1.0, if the stars, gates, and job timeouts align with
> us.

Right, I think we will request it on Wednesday, to allow a bit more time to 
test 
our newly populated not-so-stable stable/pike :)

> 
> If there are any questions, please feel free to stop by
> #openstack-ironic. We have also been keeping our general purpose
> whiteboard[1] up to date, you can see our notes regarding our current
> plan starting at line 120, and notes regarding gate failures and
> issues starting at line 37.
> Thanks!
> 
> -Julia
> 
> [1]: https://etherpad.openstack.org/p/IronicWhiteBoard
> 
> __
> 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] [ironic] Looking for a good end-to-end demo of ironic integrated within openstack

[Sam Betts (sambetts)]

Information about the ironic deployment process including full workflows can be 
found here: 
https://docs.openstack.org/ironic/latest/user/index.html#deploy-process

Sam

On 28/07/2017, 12:49, "Waines, Greg" 
<greg.wai...@windriver.com<mailto:greg.wai...@windriver.com>> wrote:

thanks Sam

What’s the 100,000 foot view of how ironic manages the configuration of a 
baremetal server when it is booting an end-user’s OS image ?

e.g. my best guess so far from looking at ironic documentation


· ironic first deploys the ironic-python-agent to the server

o   ironic-python-agent

§  cleans up the bare metal server, e.g. wiping non-root disks, etc

§  performs inventory of bare metal server’s resources ... disks, NICs, memory, 
cpu, etc., and
reports this back to ironic conductor

· ??? ironic builds up some sort of ‘config drive’  containing 
configuration of the bare metal server based on
ironic launch parameters (flavor, attached networks, etc.) and the discovered 
inventory ???

· ??? ironic conductors DHCP/Boot Server somehow attaches the ‘config 
drive’ to the end-user OS as part of the
network booting ???

· ??? the end-user OS boots ... and thru some standard mechanism uses 
the ‘config drive’ to configure the bare metal
server as desired by ironic ???

Greg.


From: "Sam Betts (sambetts)" <sambe...@cisco.com>
Reply-To: "openstack-dev@lists.openstack.org" 
<openstack-dev@lists.openstack.org>
Date: Monday, July 24, 2017 at 12:26 PM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [ironic] Looking for a good end-to-end demo of 
ironic integrated within openstack

Hey Greg,

The Ironic deploy agent images are ramdisk images which include the 
ironic-python-agent https://docs.openstack.org/ironic-python-agent/latest/ 
Which is a tool build by the ironic team and used by ironic to deploy and 
cleanup the baremetal nodes.

The cirros images are just the default images loaded by devstack, I believe by 
default it downloads them from the cirros http://download.cirros-cloud.net

Sam

On 24/07/2017, 17:07, "Waines, Greg" 
<greg.wai...@windriver.com<mailto:greg.wai...@windriver.com>> wrote:

Hey Lucas,

Thanks for the pointer to this ironic devstack setup using VMs as baremetal 
servers.
I was able to follow the recipe and get this working and play with ironic.

Of course I’ve got some follow up questions.


Questions on the images:
stack@devstack-ironic:~/devstack$ glance image-list
+--++
| ID   | Name   |
+--++
| 8091821f-a731-409c-a2fe-8986be444937 | cirros-0.3.5-x86_64-disk   |
| 087602b0-32b8-4b0d-823d-e3880614368f | cirros-0.3.5-x86_64-uec|
| 44bda48e-e1a2-4680-9067-ceb5a3b0d150 | cirros-0.3.5-x86_64-uec-kernel |
| 2027800b-4310-4bdc-a003-d4925e116f47 | cirros-0.3.5-x86_64-uec-ramdisk|
| a47a03ca-e504-4f3a-a464-3a4815b89709 | ir-deploy-agent_ipmitool.initramfs |
| 8ae53801-de05-44e6-88d4-0e04738da9b7 | ir-deploy-agent_ipmitool.kernel|
+--++
stack@devstack-ironic:~/devstack$


· so ‘cirros-0.3.5-x86_64-disk’ is the normal typical default cirros 
image for VMs in devstack

· the ironic devstack config/setup must have setup these other images,
QUESTIONS:

o   how were the ‘cirros-0.3.5-x86_64-uec...’ images created ?

§  were they generated from cirros-0.3.5-x86_64-disk image using glance or an 
external tool ?

· e.g. https://docs.openstack.org/diskimage-builder/latest/  ???

§  or

§  were they downloaded from some cirros distribution site ?






o   the ‘ir-deploy-agent_ipmitool.initramfs/kernel’ images

§  what is the role of these images ?

§  (feel free to point me to a description of this in ironic documentation)

§  e.g.

· is it specific to the “test” environment of using VMs as fake bare 
metal servers ?

· is this image generic regardless of specific end-user image (cirros, 
ubuntu, centos, ...) being put on the bare metal server ?

· is this image being used for preparing / cleaning the bare metal 
server (e.g. wiping non-root disks, etc) ...
prior to putting on the end-user image ?


Greg.



From: Lucas Alvares Gomes <lucasago...@gmail.com>
Reply-To: "openstack-dev@lists.openstack.org" 
<openstack-dev@lists.openstack.org>
Date: Thursday, July 20, 2017 at 10:52 AM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [ironic] Looking for a good end-to-end demo of 
ironic integrated within openstack

Hi Greg,

> I’m an ironic newbie ...
>

First of, welcome to the community (-:

Re: [openstack-dev] [ironic] Looking for a good end-to-end demo of ironic integrated within openstack

[Sam Betts (sambetts)]

Hey Greg,

The Ironic deploy agent images are ramdisk images which include the 
ironic-python-agent https://docs.openstack.org/ironic-python-agent/latest/ 
Which is a tool build by the ironic team and used by ironic to deploy and 
cleanup the baremetal nodes.

The cirros images are just the default images loaded by devstack, I believe by 
default it downloads them from the cirros http://download.cirros-cloud.net

Sam

On 24/07/2017, 17:07, "Waines, Greg" 
> wrote:

Hey Lucas,

Thanks for the pointer to this ironic devstack setup using VMs as baremetal 
servers.
I was able to follow the recipe and get this working and play with ironic.

Of course I’ve got some follow up questions.


Questions on the images:
stack@devstack-ironic:~/devstack$ glance image-list
+--++
| ID   | Name   |
+--++
| 8091821f-a731-409c-a2fe-8986be444937 | cirros-0.3.5-x86_64-disk   |
| 087602b0-32b8-4b0d-823d-e3880614368f | cirros-0.3.5-x86_64-uec|
| 44bda48e-e1a2-4680-9067-ceb5a3b0d150 | cirros-0.3.5-x86_64-uec-kernel |
| 2027800b-4310-4bdc-a003-d4925e116f47 | cirros-0.3.5-x86_64-uec-ramdisk|
| a47a03ca-e504-4f3a-a464-3a4815b89709 | ir-deploy-agent_ipmitool.initramfs |
| 8ae53801-de05-44e6-88d4-0e04738da9b7 | ir-deploy-agent_ipmitool.kernel|
+--++
stack@devstack-ironic:~/devstack$


· so ‘cirros-0.3.5-x86_64-disk’ is the normal typical default cirros 
image for VMs in devstack

· the ironic devstack config/setup must have setup these other images,
QUESTIONS:

o   how were the ‘cirros-0.3.5-x86_64-uec...’ images created ?

§  were they generated from cirros-0.3.5-x86_64-disk image using glance or an 
external tool ?

· e.g. https://docs.openstack.org/diskimage-builder/latest/  ???

§  or

§  were they downloaded from some cirros distribution site ?




o   the ‘ir-deploy-agent_ipmitool.initramfs/kernel’ images

§  what is the role of these images ?

§  (feel free to point me to a description of this in ironic documentation)

§  e.g.

· is it specific to the “test” environment of using VMs as fake bare 
metal servers ?

· is this image generic regardless of specific end-user image (cirros, 
ubuntu, centos, ...) being put on the bare metal server ?

· is this image being used for preparing / cleaning the bare metal 
server (e.g. wiping non-root disks, etc) ...
prior to putting on the end-user image ?


Greg.



From: Lucas Alvares Gomes 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Thursday, July 20, 2017 at 10:52 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [ironic] Looking for a good end-to-end demo of 
ironic integrated within openstack

Hi Greg,

> I’m an ironic newbie ...
>

First of, welcome to the community (-:

> where can I find a good / relatively-current (e.g. PIKE) demo of Ironic
> integrated within OpenStack ?
>

I would recommend deploying it with DevStack on a VM and playing with it, you 
can follow this document in order to do it: 
https://docs.openstack.org/ironic/latest/contributor/dev-quickstart.html#deploying-ironic-with-devstack

Hope that helps,
Lucas
__
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] Routed Networks, flat driver and physical network awareness

[Sam Betts (sambetts)]

Thanks for the interest in Ironic routed networks support! I think some of our 
on-going work should solve the issues you’ve described here.

On the ironic service side the major feature required for routed networks 
support is physical network awareness, patches for this are progressing well 
and can be found here: https://review.openstack.org/#/q/topic:bug/1666009

This feature will allow ironic to be aware of which neutron physnet each 
baremetal node NIC is connected too, which lets us make intelligent decisions 
when mapping neutron ports to physical NICs on the baremetal server, and which 
provides us with required information to feed the segment to host mapping data 
into neutron.

The additional pieces which will be required to make routed networks work exist 
the new openstack/networking-baremetal repo, which is where we will be storing 
any neutron drivers and agents required to make ironic neutron networking 
operate correctly.

The first puzzle piece is a new ML2 driver which provides the functionality for 
binding baremetal vnic type ports into statically/manually configured (flat) 
networks:
https://review.openstack.org/#/c/448073/

With this driver, the flat network interface in Ironic will no longer 
incorrectly do the port binding for flat networks by binding the neutron port 
to the nova host that requested the ironic deploy, and instead it will be able 
to use the baremetal vnic type and set the binding host id to the ironic node 
uuid.

The second puzzle piece is to do with populating the host to physical network 
mapping information in neutron so that it can calculate the segment to host 
mapping information, that is done by using the neutron L2 agent RPC API to push 
this information up into neutron, and the current proposed solution for that 
can be found here: https://review.openstack.org/#/c/456235/

Once this is in place then neutron will be aware about which physical network 
segments each baremetal is plugged into and by populating nova placement’s API 
aggregates (like it does for normal nova compute hosts) will ensure that 
scheduling gives you a valid baremetal node when you request a baremetal 
instance on a routed network.

Any help and/or reviews of this work would be most appreciated, 

Sam Betts (sambetts)

On 28/06/2017, 10:31, "Harald Jensås" <hjen...@redhat.com> wrote:

Hi,

With the following Neutron patches recently merged, it is now possible
to provide DHCP service to instances on remote routed networks that
have a dhcp forwarder configured.

https://review.openstack.org/#/c/459861/
https://review.openstack.org/#/c/468744/ 
https://review.openstack.org/476477

This enables provisioning of baremetal machines on remote routed
networks as well. Removing the need to deploy ironic
conductor/inspector etc with local connection to each routed network
segment.

However with the flat driver this does not work, because the flat
driver bind neutron ports to the node running ironic-conductor service,
e.g 'nova_host_id'. Not to the actual baremetal node. (Ref: https://git
hub.com/openstack/ironic/blob/master/ironic/drivers/modules/network/fla
t.py#L64)

The result of binding to the 'nova_host_id' causes this error for
baremetal nodes on the remote routed network segment.

INFO ironic.conductor.task_manager [req-11f5c864-cc1a-49ee-b224-
a6695c1a9678 87f6dc660b1f43f79efa4355080e118c
6a8453039524487ca0bbf191cdc6317d - default default] Node f19ecc51-c8ec-
4d34-a349-206a5ae97ed2 moved to provision state "deploy fail
ed" from state "deploying"; target provision state is "active":
NetworkError: Unable to set binding:host_id for neutron port 5e674173-
32d9-4ec9-be2a-7f2b3aa02336. Error: Host ironic-
conductor.node.example.com is not connected to a segment where the
existing fixed_ips on port 5e6741
73-32d9-4ec9-be2a-7f2b3aa02336 will function given the routed network
topology.


I can workaround this by not binding the port:
$ sudo sed -i \
s/'binding:host_id': host_id/'binding:host_id': None/" \
ironic/drivers/modules/network/flat.py


I can see good progress on the phys-net aware spec. But with the flat
driver this will not help, as the nova_host_id is used for binding. Not
the ironic baremetal node uuid.


What would be a good way forward here?
 - Change the flat driver to not bind the port?
 - Change the flat driver to bind using the ironic node uuid, and rely
on phys-net info being populated in Neutron? (Requieres: baremetal
neutron agent https://review.openstack.org/#/c/456235/ + several
changes related to phys-net)
 - Another driver? 'flat-routed' that does one of the above?
 - Keep the flat driver, but register the ironic-conductor as a
separate host in neutron and populate phys-nets in neut

Re: [openstack-dev] [ironic] [tripleo] [dib] RFC: moving/transitioning the ironic-agent element to the ironic-python-agent tree

[Sam Betts (sambetts)]

I would like to suggest that we create a new repo for housing the tools 
required to build ironic python agent images: 
ironic-python-agent-builder(tooling). This would include, the DIB element, the 
existing coreos and tinyipa methods and hopefully in the future the buildroot 
method for creating IPA images.

The reason I propose a separation of tooling and IPA itself is that the tooling 
is mostly detached from which version of IPA is being built into the image, and 
often when we make changes to the tooling that change should be included in 
images built for all versions of IPA which involves us having to backport these 
changes to all currently maintained versions of IPA.

Hopefully having this as a separate repo will also simplify packaging for 
distros as they won’t need to include IPA itself with the tooling to build it.

I’m happy with the name ironic-python-agent for the element, I think that is 
more intuitive anyway.

An RFE or multiple might be useful for tracking this work.

Sam

On 22/05/2017, 13:40, "Dmitry Tantsur"  wrote:

Hi all!

Some time ago we discussed moving ironic-agent element that is used to 
build IPA 
to IPA tree itself. It got stuck, and I'd like to restart the discussion.

The reason for this move is to make the DIB element in question one of 
*official* ways to build IPA. This includes gating on both IPA and the 
element 
changes, which we currently don't do.

The primary concern IIRC was elements name clash. We can solve it by just 
renaming the element. The new one will be called "ironic-python-agent".

 From the packaging perspective, we'll create a new subpackage 
openstack-ironic-python-agent-elements (the RDO name, may differ for other 
distribution) that will only ship /usr/share/ironic-python-agent-elements 
with 
the ironic-python-agent element within it. To pick the new element, the 
consumers will have to add /usr/share/ironic-python-agent-elements to the 
ELEMENTS_PATH, and change the element name from ironic-agent to 
ironic-python-agent.

Please let me know what you think about the approach. If there are no 
objects, 
I'll work on this move in the coming weeks.

P.S.
Do we need an Ironic RFE for that?

__
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] [ironic] End-of-Ocata core team updates

[Sam Betts (sambetts)]

+1 to both, thanks for your contributions Vasyl and Mario!!! 

Sam 

On 17/02/2017, 09:40, "Dmitry Tantsur"  wrote:

Hi all!

I'd like to propose a few changes based on the recent contributor activity.

I have two candidates that look very good and pass the formal barrier of 3 
reviews a day on average [1].

First, Vasyl Saienko (vsaienk0). I'm pretty confident in him, his stats [2] 
are 
high, he's doing a lot of extremely useful work around networking and CI.

Second, Mario Villaplana (mariojv). His stats [3] are quite high too, he 
has 
been doing some quality reviews for critical patches in the Ocata cycle.

Active cores and interested contributors, please respond with your +-1 to 
these 
suggestions.

Unfortunately, there is one removal as well. Devananda, our team leader for 
several cycles since the very beginning of the project, has not been active 
on 
the project for some time [4]. I propose to (hopefully temporary) remove 
him 
from the core team. Of course, when (look, I'm not even saying "if"!) he 
comes 
back to active reviewing, I suggest we fast-forward him back. Thanks for 
everything Deva, good luck with your current challenges!

Thanks,
Dmitry

[1] http://stackalytics.com/report/contribution/ironic-group/90
[2] http://stackalytics.com/?user_id=vsaienko=marks
[3] http://stackalytics.com/?user_id=mario-villaplana-j=marks
[4] http://stackalytics.com/?user_id=devananda=marks

__
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] [ironic] New mascot design

[Sam Betts (sambetts)]

+100

On 06/02/2017, 12:32, "Dmitry Tantsur"  wrote:

On 02/06/2017 12:49 PM, Miles Gould wrote:
> On 01/02/17 21:38, Lucas Alvares Gomes wrote:
>> But, let me ask something, what the foundation really wants to achieve
>> with this ? Cause I think we are conflating two things here: A logo (or
>> brand) and a mascot.
>
> I think this is an excellent point. The constraints on logos make a lot 
of sense
> *for logos*, but it'll be very hard to achieve something like Pixie Boots 
within
> them. Could we perhaps use *two* images for different contexts?
>
> 1) a stylized logo, matching the guidelines, for use in "official" 
settings and
> anywhere that it will be seen alongside other projects' logos;
> 2) our existing Pixie Boots mascot, for use in "unofficial" settings 
(laptop
> stickers, T-shirts, chatbots, The Bear Metal Adventures of Pixie Boots 
webcomic
> series*, etc, etc).
>
> It'll be much easier to agree on image 1 if we don't reject every 
proposal for
> not capturing every nuance of image 2.
>
> If that makes sense, I have a suggestion for the next iteration of the 
logo, if
> one is needed: take the head from logo version 3.0. AFAICT, that meets 
all the
> objections raised so far:
>
>  - it's simple and logo-like,
>  - it's not holding any man-made objects,
>  - it's friendly,
>  - it has heavy-metal facial markings,
>  - it's not making any potentially-obscene gestures.
>
> It doesn't look exactly like Pixie Boots, but if we can carry on using 
Pixie in
> unofficial contexts, that shouldn't be a problem.

+100 to everything written here.

>
> Miles
>
> * In which Pixie Boots, sysadmin by day and rock musician by night, 
solves a
> series of increasingly baffling deployment problems using AWESOME DRUM 
SOLOS.
>
> __
> 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] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Sam Betts (sambetts)]

There are a couple of reasons we want to become an official OpenStack project.

From a project perspective, we want to be recognized that the project isn’t 
just a “public source” repo for Cisco’s drivers but is a community driven open 
source project for supporting Cisco hardware/software and we want to encourage 
community members that are using Cisco equipment to participate with us 
contributing to and helping improve the drivers.

Additionally, being “official” indicates a level of maturity which benefits us 
as a project by improving the public perception of our drivers, and also 
indicates to OpenStack users that OpenStack itself is mature and has support 
for existing technologies and physical equipment out of the box. We want to 
make the Cisco drivers visible/discoverable so that operators evaluating 
OpenStack for their use cases will easily be able to know if a driver for their 
equipment exists without digging around in git repos. 

In our current state (not an official project or under an official project) we 
can’t publish our existence, releases or docs to any official location on 
*.openstack.org which makes it difficult for those new to OpenStack to know we 
exist, or find any information on how to deploy/use Cisco equipment with 
OpenStack.

Sam

On 28/11/2016, 19:14, "Jay Pipes"  wrote:

On 11/28/2016 01:33 PM, Doug Hellmann wrote:
> I'm raising this as an issue because it's not just a hypothetical
> problem. The Cisco networking driver team, having been removed from
> the Neutron stadium, is asking for status as a separate official
> team [1]. I would very much like to find a way to say "yes, welcome
> (back)!"

These questions are to the Cisco networking team.

What value do *you* think you derive from being an official OpenStack 
project team?

What value do you believe OpenStack *users* would get from you being an 
official OpenStack project team?

If you are *not* accepted as an official OpenStack project team, what 
actual impact would that have on OpenStack users, if any?

Thanks in advance for your answers.

Best,
-jay

__
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-dev] [new][networking-cisco]

[Sam Betts (sambetts)]

The networking-cisco development team are grateful to announce the release of:

networking-cisco 4.0.0

This release is compatible with OpenStack Mitaka and Newton

Download the package from:

https://pypi.python.org/pypi/networking-cisco
__
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] [networking-cisco] Meeting Reminder, 11th Oct 2016

[Sam Betts (sambetts)]

Just a quick reminder that the first networking-cisco IRC meeting will be 
happening on #openstack-meeting-3 at 16:00 UTC.

See you there,

Sam

__
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] [networking-cisco] networking-cisco IRC meetings

[Sam Betts (sambetts)]

TL;DR networking-cisco IRC meetings will be held bi-weekly on 
#openstack-meeting-3 starting from 2016/10/11

With the results of the doodle poll, and some pointers from Steve and Jeremy 
(thanks guys for the info) I've successfully organised the time and place for 
the networking-cisco IRC meeting. Initially the plan was to hold the meeting 
weekly on the openstack-networking-cisco IRC channel, however it is encouraged 
that we use the openstack-meeting channels for these sort of meetings. So with 
that in mind I found us a slot on the openstack-meeting-3 channel when the 
majority of people who responded to the poll where available. The negative to 
having it at a time that is convenient for most people is that the it is a very 
popular time slot for holding meetings, so to fit around the other projects, we 
will hold our meeting bi-weekly instead of weekly. If this proves too irregular 
then we can reschedule at a later date.  I look forward to our first meeting, 
the details can be found here: 
https://wiki.openstack.org/wiki/Meetings/networking-cisco. Please add any 
topics you want to discuss to the agenda, and if you want to talk about 
networking-cisco between now and the first meeting I encourage people to join 
the #openstack-networking-cisco channel for day to day discussions about 
networking-cisco development.

Sam
__
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] ironic-inspector-core team update

[Sam Betts (sambetts)]

+1 from me! Thanks for the contributions Milan :D

Sam

On 26/09/2016 10:24, "Dmitry Tantsur"  wrote:

>Hi folks!
>
>As you probably know, Imre has decided to leave us for other challenges,
>so our 
>small core team has become even smaller. I'm removing him on his request.
>
>I suggest adding Milan Kovacik (milan or mkovacik on IRC) to the
>ironic-inspector-core team. He's been pretty active on ironic-inspector
>recently, doing meaningful reviews, and he's driving our HA work forward.
>
>Please vote with +1/-1. If no objections are recorded, the change will be
>in 
>effect next Monday.
>
>Thanks!
>
>__
>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] [networking-cisco] Poll to decide networking-cisco weekly meeting times

[Sam Betts (sambetts)]

My interpretation of the guidelines was that those channels are reserved for 
official OpenStack projects (projects included in governance projects.yaml) 
only, so until we regain that status I was planning on holding it in the 
project channel. If this isn't the case and we can use the openstack-meeting 
channels then that would be ideal for the reasons you've stated plus we have to 
move to them anyway once you are accepted into the governance project list so 
it would be one less thing to redo later. I will look into this further and if 
we can use the openstack-meeting channels then I'll aim to make that the home 
for our meetings.

Sam

On 20/09/2016 16:46, "Steven Dake (stdake)" 
<std...@cisco.com<mailto:std...@cisco.com>> wrote:

Sam,

Can this meeting instead be held in the normal openstack-meeting-1 -> 4 
channels?  Having one-off meetings in #openstack-networking-cisco is totally 
fine.  Having standing team meetings there is atypical of OpenStack projects.  
The main value of using the opentack-meeting-1-4 channels is that a lot of 
people are in those channels, and it is easy to ping an individual in a broadly 
represented channel for cross-project issues rather than a project-specific 
channel.

Regards
-steve


From: "Sam Betts (sambetts)" <sambe...@cisco.com<mailto:sambe...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, September 20, 2016 at 5:05 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [networking-cisco] Poll to decide networking-cisco 
weekly meeting times

For those interested in participating, we are setting up a weekly meeting to 
discuss the development and design of networking-cisco. This meeting will be 
held on the #openstack-networking-cisco channel. If you are interested please 
use the link below to provide which of the dates and times you are best for 
you. We will use this poll to ensure we organise a meeting which aligns best 
for the majority of attendees.

http://doodle.com/poll/huqedr8hac679c9y
NOTE: All the times are in UTC.

Sam
__
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] [networking-cisco] Poll to decide networking-cisco weekly meeting times

[Sam Betts (sambetts)]

For those interested in participating, we are setting up a weekly meeting to 
discuss the development and design of networking-cisco. This meeting will be 
held on the #openstack-networking-cisco channel. If you are interested please 
use the link below to provide which of the dates and times you are best for 
you. We will use this poll to ensure we organise a meeting which aligns best 
for the majority of attendees.

http://doodle.com/poll/huqedr8hac679c9y
NOTE: All the times are in UTC.

Sam
__
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] Driver removal policies - should we make it softer?

[Sam Betts (sambetts)]

On 19/08/2016 18:44, "Villalovos, John L" 
wrote:

>> -Original Message-
>> From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com]
>> Sent: Friday, August 19, 2016 7:15 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: [openstack-dev] [ironic] Driver removal policies - should we
>>make it
>> softer?
>> 
>> Hi Ironickers,
>> 
>> There was a big thread here[0] about Cinder, driver removal, and
>>standard
>> deprecation policy. If you haven't read through it yet, please do before
>> continuing here. :)
>> 
>> The outcome of that thread is summarized well here.[1]
>> 
>> I know that I previously had a different opinion on this, but I think we
>> should go roughly the same route, for the sake of the users.
>> 
>> 1) A ``supported`` flag for each driver that is True if and only if the
>>driver
>>is tested in infra or third-party CI (and meets our third party CI
>>requirements).
>> 2) If the supported flag is False for a driver, deprecation is implied
>>(and
>>a warning is emitted at load time). A driver may be removed per
>>standard
>>deprecation policies, with turning the supported flag False to start
>>the
>>clock.
>> 3) Add a ``enable_unsupported_drivers`` config option that allows
>>enabling
>>drivers marked supported=False. If a driver is in enabled_drivers,
>>has
>>supported=False, and enable_unsupported_drivers=False, ironic-
>> conductor
>>will fail to start. Setting enable_unsupported_drivers=True will
>>allow
>>ironic-conductor to start with warnings emitted.
>> 
>> It is important to note that (3) does still technically break the
>>standard
>> deprecation policy (old config may not work with new version of ironic).
>> However, this is a much softer landing than the original plan. FWIW, I
>>do
>> expect (but not hope!) this part will be somewhat contentious.
>> 
>> I'd like to hear thoughts and get consensus on this from the rest of the
>> ironic community, so please do reply whether you agree or disagree.
>> 
>> I'm happy to do the work required (update spec, code patches, doc
>>updates)
>> when we do come to agreement.
>> 
>> // jim
>> 
>> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-
>> August/101428.html
>> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-
>> August/101898.html
>
>Thanks Jim. This proposal makes sense to me. So put me into the agree
>camp.

+1 from me too

>
>__
>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] [ironic] network_interface, defaults, and explicitness

[Sam Betts (sambetts)]

On 01/08/2016 13:10, "Jim Rollenhagen"  wrote:

>Hey all,
>
>Our nova patch for networking[0] got stuck for a bit, because Nova needs
>to know which network interface is in use for the node, in order to
>properly set up the port.
>
>The code landed for network_interface follows the following order for
>what is actually used for the node:
>1) node.network_interface, if that is None:
>2) CONF.default_network_interface, if that isNone:
>3) flat, if using neutron DHCP
>4) noop, if not using neutron DHCP
>
>The API will return None for node.network_interface in the API (GET
>/v1/nodes/uuid). This won't work for Nova, because Nova can't know what
>CONF.default_network_interface is.
>
>I propose that if a network_interface is not sent in the node-create
>call, we write whatever the current default is, so that it is always set
>and not using an implicit value that could change.

+1 from me

>
>For nodes that exist before the upgrade, we do a database migration to
>set network_interface to CONF.default_network_interface (or if that's
>None, set to flat/noop depending on the DHCP provider).
>
>An alternative is to keep the existing behavior, but have the API return
>whatever interface is actually being used. This keeps the implicit
>behavior (which I don't think is good), and also doesn't provide a way
>to find out from the API if the interface is actually set, or if it's
>using the configurable default.
>
>I'm going to go ahead and execute on that plan now, do speak up if you
>have major objections to it.
>
>// jim
>
>[0] https://review.openstack.org/#/c/297895/
>
>__
>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-dev] [ironic] How should ironic and related project names be written?

[Sam Betts (sambetts)]

Its official OpenStack policy that project names be written in lower case, for 
example Ironic must always be written as ironic, however I was recently writing 
a spec for IPA, and was unsure how to approach writing IPAs name in full.
Discussing this with Dmitry on IRC, we decided it would be best brought to a 
wider audience on the ML because this affects any project that includes 
ironic's name in their name.

Ironic Python Agent
ironic Python Agent
ironic python agent
ironic-python-agent

I prefer a capitalised Ironic Python Agent name, because it lines up with the 
way we write the acronym, IPA, and makes it obvious its a name, however I'm 
unsure if this aligns with the OpenStack policy. If we need to lower case the 
whole of IPA's name, then I prefer we refer to it using including the dashes, 
so that it is obviously a project name.

A couple of other projects that also use ironic in the name:

Ironic Inspector
ironic Inspector
ironic inspector
Ironic-inspector

Ironic Lib
ironic Lib
ironic lib
ironic-lib

I would like to hear some opinions on whether we should always refer to the 
projects as they are written if you go to git.openstack.org (with dashes) or 
which of the above styles we're allowed, and prefer?

Sam
__
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] [ironic][nova] Indivisible Resource Providers

[Sam Betts (sambetts)]

While discussing the proposal to add resource_class' to Ironic nodes for 
interacting with the resource provider system in Nova with Jim on IRC, I voiced 
my concern about having a resource_class per node. My thoughts were that we 
could achieve the behaviour we require by every Ironic node resource provider 
having a "baremetal" resource class of which they can own a maximum of 1. 
Flavor's that are required to land on a baremetal node would then define that 
they require at least 1 baremetal resource, along with any other resources they 
require.  For example:

Resource Provider 1 Resources:
Baremetal: 1
RAM: 256
CPUs: 4

Resource Provider 2 Resources:
Baremetal: 1
RAM: 512
CPUs: 4

Resource Provider 3 Resources:
Baremetal: 0
RAM: 0
CPUs: 0

(Resource Provider 3 has been used, so it has zero resources left)

 Given the thought experiment it seems like this would work great with one 
exception, if you define 2 flavors:

Flavor 1 Required Resources:
Baremetal: 1
RAM: 256

Flavor 2 Required Resources:
Baremetal: 1
RAM: 512

Flavor 2 will only schedule onto Resource Provider 2 because it is the only 
resource provider that can provide the amount of resources required. However 
Flavor 1 could potentially end up landing on Resource Provider 2 even though it 
provides more RAM than is actually required. The Baremetal resource class would 
prevent a second node from ever being scheduled onto that resource provider, so 
scheduling more nodes doesn't result on 2 instance on the same node, but it is 
an inefficient use of resources.

To combat this inefficient use of resources, I wondered if it was possible to 
add a flag to a resource provider to define that it is an indivisible resource 
provider, which would prevent flavors that don't use up all the resources a 
provider provides from landing on that provider.

Sam


__
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][neutron][nova] Sync port state changes.

[Sam Betts (sambetts)]

On 26/07/2016 09:32, "John Garbutt"  wrote:

>On 22 July 2016 at 11:51, Vasyl Saienko  wrote:
>> Kevin, thanks for reply,
>>
>> On Fri, Jul 22, 2016 at 11:50 AM, Kevin Benton  wrote:
>>>
>>> Hi,
>>>
>>> Once you solve the issue of getting the baremetal ports to transition
>>>to
>>> the ACTIVE state, a notification will automatically be emitted to Nova
>>>of
>>> 'network-vif-plugged' with the port ID. Will ironic not have access to
>>>that
>>> event via Nova?
>>>
>> To solve issues of getting the baremetal ports to transition to the
>>ACTIVE
>> state we should do the following:
>>
>> Use FLAT network instead of VXLAN for Ironic gate jobs [3].
>> On Nova side set vnic_type to baremetal for Ironic hypervisor [0].
>> On Neutron side, perform fake 'baremetal' port binding [2] in case of
>>FLAT
>> network.
>>
>> We need to receive direct notifications from Neutron to Ironic, because
>> Ironic creates ports in provisioning network by his own.
>> Nova doesn't know anything about provisioning ports.
>>
>>> If not, Ironic could develop a service plugin that just listens for
>>>port
>>> update events and relays them to Ironic.
>>>
>>
>> I already prepared PoC [4] to Neutron that allows to send notifications
>>to
>> Ironic on port_update event.
>>
>> Reference:
>> [0] https://review.openstack.org/339143
>> [1] https://review.openstack.org/339129
>> [3] https://review.openstack.org/340695
>> [4] https://review.openstack.org/345211
>
>I prefer Kevin's idea of Nova always getting the vif events.
>
>Can't the ironic virt driver can pass on the event to ironic, if required?
>
>In the libvirt case, for example, the virt driver waits to start the
>instance until the networking has been setup. It feels like we might
>need that in the Ironic case as well?
>
>Or is that likely to all end up too messy?
>
>Thanks,
>John

This is potentially possible for the nova user's network ports, but Ironic
creates its own neutron ports in the Ironic provisioning and cleaning
networks to perform provisioning and cleaning for a node. Nova is never
aware of these ports as they have nothing to do with the tenant¹s
requested connectivity.

Sam

>
>>>
>>> On Tue, Jul 12, 2016 at 4:07 AM, Vasyl Saienko 
>>> wrote:

 Hello Community,

 I'm working to make Ironic be aware about  Neutron port state changes
 [0].
 The issue consists of two parts:

 Neutron ports for baremetal instances remain in DOWN state [1]. The
issue
 occurs because there is no mechanism driver that binds ports. To
solve it we
 need to create port with  vnic_type='baremetal' in Nova [2], and bind
in
 Neutron. New mechanism driver that supports baremetal vnic_type is
needed
 [3].

 Sync Neutron events with Ironic. According to Neutron architecture [4]
 mechanism drivers work synchronously. When the port is bound by ml2
 mechanism driver it becomes ACTIVE. While updating dhcp information
Neutron
 uses dhcp agent, which is asynchronous call. I'm confused here, since
ACTIVE
 port status doesn't mean that it operates (dhcp agent may fail to
setup
 port). The issue was solved by [5]. So starting from [5] when ML2
uses new
 port status update flow, port update is always asynchronous
operation. And
 the most efficient way is to implement callback mechanism between
Neutron
 and Ironic is like it's done for Neutron/Nova.

 Neutron/Nova/Ironic teams let me know your thoughts on this.


 Reference:
 [0] https://bugs.launchpad.net/ironic/+bug/1304673
 [1] https://bugs.launchpad.net/neutron/+bug/1599836
 [2] https://review.openstack.org/339143
 [3] https://review.openstack.org/#/c/339129/
 [4]
 
https://www.packtpub.com/sites/default/files/Article-Images/B04751_01.p
ng
 [5]
 
https://github.com/openstack/neutron/commit/b672c26cb42ad3d9a17ed049b50
6b5622601e891


 
___
___
 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] [ironic] How to handle defaults in driver composition reform?

[Sam Betts (sambetts)]

There have been several discussions brought about by new interface types and 
how they fit into the existing driver composition spec. Network and Volume 
connector interfaces are examples of two interfaces who’s implementations can 
depend highly on the environment they are being used in, as well as the piece 
of hardware they are being used with. For example the neutron network interface 
requires neutron to exist to operate.

The current solution for handling defaults with hardware_types removes much of 
the control from the deployer over which interfaces are enabled in their 
environment. For example:

- A deployer wants to use a hardware_type that specifies neutron as the default 
network_interface in a Ironic standalone deployment.
- As a deployer they know that the neutron network interface is not going to 
work but they can’t disable it because its a hardware_type default which are 
automatically enabled.
- This means that nodes can be created using that hardware_type with a known 
not to work interface implementation, and if not overridden during node 
creation the network_interface for that node will be automatically configured 
to use the neutron interface because its the default, resulting in a broken 
node by default.

To address this issue meetings and discussions on IRC considered several 
different solutions but all more or less resulted in either removing special 
case interfaces like network from the hardware_type, or treating these 
interfaces as special cases in some form or other with no default, or new 
config options to manage them.

After considering several different ways to handle hardware_type interfaces so 
that we can ensure that deployers maintain fine control over which interfaces 
are enabled in their environment, but continue to provide sane defaults for all 
the different types of interfaces for convenience of the user when enrolling 
nodes and also have all interface types defined in a consistent way for 
developers of hardware types. I would like to propose this solution:

- Remove single hardware_type default for all interface types
- Make hardware_type supported_FOO_interfaces a list of supported 
implementations in order of preference by that hardware type’s vendor
- Have Ironic resolve the possible_FOO_interfaces by intersecting 
enabled_FOO_interfaces with supported_FOO_interfaces maintaining the order of 
preference
- Use the first possible_FOO_interface as the default this hardware_type

An example of this in operation:

In the deployer’s environment, implementation RAR, HAH and GAR will work, BAR 
will not.
The deployer wants to enable two different hardware_types X and Y.

hardware_type X:
# BAR is recomended over RAR and RAR over GAR if available in this 
deployment
supported_FOO_interface: [BAR, RAR, GAR]

hardware_type Y:
supported_FOO_interface: [HAH]

The deployer knowing that BAR will not work, does not include BAR in the list 
of enabled_FOO_interfaces.

Deployers config file:
enabled_FOO_interfaces = RAR, HAH, GAR

The Ironic user creates a node using hardware_type X, but doesn’t specify any 
interfaces.

ironic node-create -d X

Ironic calculates prioritied list of possible interfaces:

possible_FOO_interfaces = [BAR, RAR, GAR] intersect [RAR, HAH, GAR]
  = [RAR, GAR]

Ironic creates node with the first interface out of ordered list of possible 
interfaces.

Node:
hardware_type: X
FOO_interfaces: RAR

The user now has a node with interfaces that are guaranteed by the deployer to 
work in this environment.

This solution does mean that based on which environment you enroll a node in 
you might get a different set of interfaces. So in order to find out which 
interface is going to be the default FOO_interface for this hardware_type in 
this environment, you can use the discovery API, which returns a 
default_FOO_interface field, and also the possible_FOO_interfaces, if you want 
to know which other interfaces are available to you.

I believe this is a good fit for treating all interfaces in a standardised way, 
please let me know your opinions so we can solve this issue in a way that is 
convenient for our users as well as keeps things consistent for developing core 
Ironic code, and hardware_types both in and out of tree.

Sam
__
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] why do we need setting network driver per node?

[Sam Betts (sambetts)]

Thanks for following up with this Devananda, I¹ve left a couple of
corrections to my proposal inline, unfortunately IRC isn¹t the best for
putting ideas this complex across :)

Sam

On 11/07/2016 21:57, "Devananda van der Veen" 
wrote:

>We spent the majority of today's weekly IRC meeting [1] discussing the
>finer
>points of this question. I agreed to post a summary of those to the list
>(it's
>below the break).
>
>tldr;
>
>* we don't know if network_interface should behave like other hardware
>interfaces, but...
>* we need to come to an agreement on it this week, so we can proceed with
>the
>network integration work.
>
>
>Background:
>
>- As proposed in the driver composition reform spec [2], each
>hardware_type
>class (eg, ilo_gen8) shall specify a set of allowable interface
>implementations
>(eg, noop, flat, neutron are all network_interfaces) for each interface
>type
>(eg, deploy_interface, power_interface, network_interface).
>- A hardware_type shall also indicate a default for each interface_type.
>(**
>this is what we debated ** )
>- There is no CONF option to specify a global default for each
>interface_type
>(eg, there is no CONF.default_power_interface setting, because it varies
>by
>hardware_type)
>- There will be a CONF option to enable ("allow") hardware classes and
>CONF
>options to enable ("allow") interface classes.
>
>
>Points raised in the meeting today:
>
>- in "most" cases, network_interface will depend more on the environment
>than a
>specific Node's hardware or out-of-band management device
>
>- in "exceptional" cases, a Node may only support specific
>network_interfaces
>(eg, certain Cisco hardware, a Blade enclosure)
>
>- maybe hardware_type should specify a default for some interfaces but not
>others? Example:
>  - the ilo_gen8 hardware class should specify power, deploy, and
>management
>interface defaults to ilo-specific interface classes
>  - but the operator should set the network interface as appropriate to
>their
>environment
>
>- if we were to force the operator to specify Node.network_interface (but
>not
>any other interface) when enrolling every node, this will be apoor
>experience.
>
>- we should add a global CONF setting to allow operators to set a default
>network interface for their environment.
>
>- words are hard. we shouldn't call network_interface an "interface" if it
>behaves differently than other interfaces.
>
>- we have two "types" of interfaces on drivers: hardware-types and
>environment-types. maybe we should treat them differently?
>
>- other things also depend on the environment (rather than the Node's
>hardware
>or BMC) such as deploy_interface and volume_interface.
>
>
>There was a proposal from sambetts towards the end of the meeting, which
>I've
>edited for clarity (please correct if I misunderstood any of your
>points). This
>seems to capture/address most of the points above and proposes a way
>forward,
>while keeping within the intent of our driver composition reform spec. It
>was
>the only clear suggestion during the meeting.
>
>- in-tree hardware_types declare supported_network_interfaces to be empty
>[4]
>and declare no default_network_interface

Your suggestion in [4] is what I meant, but I couldn¹t type fast enough in
the meeting. In-tree hardware_types will list support for
network_interfaces according to their vendor¹s preference (I expect for
most/all drivers that will at least be [noop, flat, neutron]). And if in
the future as a vendor I want to, for example, push my hardware specific
network interface in tree, then my Cisco drivers will gain an additional
network_interface in their supported_network_interfaces list, [noop, flat,
neutron, cisco].

>- we add a CONF option for default_network_interface, with a sane default
>value
>- this CONF option is validated on conductor load to be supported by all
>loaded
>hardware_types, and the conductor refuses to start if this CONF option is
>set to
>a value not supported by one or more enabled_hardware_types
>- if a(n out of tree) hardware_type declares a default_network_interface,
>this
>will take precedence over the CONF option

I believe that all hardware_types should specify their supported network
interfaces, but none should specify a default network interface, because
there is no way to define a sane default in the hardware_type without
knowing what environment its being deployed into.

>- a node created without specifying a network interface will check the
>hardware_type's supported_network_interfaces, and when that is empty,
>fall back
>to the CONF.default_network_interface, just as other interfaces fall back
>to the
>hardware_type's relevant default

A node created without specifying a specific network interface will get
the default specified by the CONF option, which we know is supported by
that hardware_type because of the validation on conductor start. Nodes
created with a network_interface specified work with the usual rules as
you've specified below.

>- 

Re: [openstack-dev] [ironic] Dell recheck command issue (was: UFCG OneView CI comments missing recheck command)

[Sam Betts (sambetts)]

Please  can we not reinvent our own standard for this, as mentioned in the 
other thread on this topic, there is an OpenStack standard for third party CI 
recheck commands that can be found in the third party CI docs: 
http://docs.openstack.org/infra/system-config/third_party.html#requirements

Third party Cis should respond to comments in the following formats:

recheck

 recheck
(Where  is replaced with the name of your third party CI.)

Sam

On 08/07/2016 17:16, "rajini_...@dell.com" 
> wrote:


Dell - Internal Use - Confidential
Sorry I wasn't aware that this is causing the whole pipeline to rerun. Will 
change it to "retest Dell"

-Rajini

-Original Message-
From: Dmitry Tantsur [mailto:dtant...@redhat.com]
Sent: Friday, July 08, 2016 10:10 AM
To: openstack-dev@lists.openstack.org
Cc: Ram, Rajini
Subject: [openstack-dev] [ironic] Dell recheck command issue (was: UFCG OneView 
CI comments missing recheck command)

I've noticed that Dell CI has the same problem: it uses "recheck Dell"
causing the whole check pipeline to rerun.

On 06/29/2016 02:23 AM, Villalovos, John L wrote:
>
>
>> -Original Message-
>> From: Thiago Paiva [mailto:thia...@lsd.ufcg.edu.br]
>> Sent: Tuesday, June 28, 2016 17:00
>> To: OpenStack Development Mailing List (not for usage questions)
>> Cc: ufcg-oneview...@lsd.ufcg.edu.br
>> Subject: Re: [openstack-dev] [ironic] UFCG OneView CI comments
>> missing recheck command
>>
>> Hi Jay,
>>
>> Sorry about that. The comment should be "recheck oneview" to test again.
>> I'll patch the failure message with instructions, thanks for the warning.
>
> I'm not sure "recheck oneview" is a good command because it will kick off the 
> master recheck. I would suggest something that will not trigger the normal 
> jobs to recheck.
>
> "retest oneview"?? Hopefully there is some standard for 3rd Party CI to use.
>
> And yes, please do put in the message the command to do a job recheck.
>
> John
> __
>  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] [ironic] UFCG OneView CI comments missing recheck command

[Sam Betts (sambetts)]

On the official OpenStack Third Party CI Documentation, it is a
requirement for third party Cis to respond to comments in the following
formats: 

recheck

 recheck
 
(Where  is replaced with the name of your third party CI.)

http://docs.openstack.org/infra/system-config/third_party.html#requirements

I don¹t think we should be creating a third party recheck comment style
specific to Ironic, this will just lead to inconstancies across different
OpenStack projects.

Sam

On 07/07/2016 08:04, "Watanabe, Isao"  wrote:

>Hello jlvillal, thiagop
>Hello krtaylor
>
>In Cinder, 3rd party CIs are asked to set their recheck keyword to "run
>XXX CI" (also Note it in the CI's Wiki), so that the infra CI will not
>get kicked.
>Maybe we can decide one for our Ironic, too, on the next Wednesday.
>
>Best regards,
>Watanabe.isao
>
>
>> -Original Message-
>> From: Villalovos, John L [mailto:john.l.villalo...@intel.com]
>> Sent: Wednesday, June 29, 2016 9:24 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Cc: ufcg-oneview...@lsd.ufcg.edu.br
>> Subject: Re: [openstack-dev] [ironic] UFCG OneView CI comments missing
>>recheck
>> command
>> 
>> 
>> 
>> > -Original Message-
>> > From: Thiago Paiva [mailto:thia...@lsd.ufcg.edu.br]
>> > Sent: Tuesday, June 28, 2016 17:00
>> > To: OpenStack Development Mailing List (not for usage questions)
>> > Cc: ufcg-oneview...@lsd.ufcg.edu.br
>> > Subject: Re: [openstack-dev] [ironic] UFCG OneView CI comments missing
>> > recheck command
>> >
>> > Hi Jay,
>> >
>> > Sorry about that. The comment should be "recheck oneview" to test
>>again.
>> > I'll patch the failure message with instructions, thanks for the
>>warning.
>> 
>> I'm not sure "recheck oneview" is a good command because it will kick
>>off the
>> master recheck. I would suggest something that will not trigger the
>>normal jobs
>> to recheck.
>> 
>> "retest oneview"??  Hopefully there is some standard for 3rd Party CI
>>to use.
>> 
>> And yes, please do put in the message the command to do a job recheck.
>> 
>> John
>> 
>>_
>>_
>> 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] [ironic] why do we need setting network driver per node?

[Sam Betts (sambetts)]

My use case is supporting mixed hardware environments with hardware that has 
greater network capabilities and hardware without these capabilities without 
limiting my all my equipment to the lowest common feature set. The use case I’m 
describing will have some nodes configured with the neutron multi-tenant driver 
(generic hardware, smart switch) and some nodes configured with a custom 
neutron multi-tenant+cisco magic network driver (cisco hardware, smart switch).

Perhaps a it’ll be clearer to understand why we need the driver in the patches 
if I give a description of the network drivers and why we’re adding them, and 
how I see the the current patches working in an upgrade scenario:

Flat
This matches the existing networking implementation in Ironic today, but with 
added validation on conductor start to ensure that Ironic is configured 
correctly (cleaning_network_uuid set) to support this feature.

None
This is what standalone users have been faking by setting the DHCP provider to 
None for a long time. The reason this worked before is because DHCP providers 
did more than just set DHCP options and actually started configuring the 
cleaning network, this job is now superseded by the network provider, so we 
need a true no-op driver for when configuring cleaning networks is deprecated 
out of the DHCP provider interface.

Neutron
Multi-tenant neutron network support

The problem I see is that the existing networking behaviour in Ironic is 
implicit and affected by different things (DHCP Provider, cleaning 
enabled/disabled etc, what driver I’ve configured on the node). I believe that 
the upgrade process can be handled in a sane way by doing a data migration as 
part of the upgrade and maintaining awareness about what configuration options 
a user has set and what that means their previous configuration actually was, 
for example:

DHCP Provider: None -> No neutron integration -> Configure existing nodes to 
None to match what they’ve actually been getting because of their configuration
DHCP Provider: Neutron -> Existing neutron integration -> Configure existing 
nodes to Flat to match what they’ve been getting because of their configuration

That was the easy part, to make existing nodes continue to work as before. Now 
we have to consider what happens when we create a new node in Ironic after 
we’ve upgraded, and I think that Ironic should behave as such:

DHCP Provider: None,  No network interface in request -> Still no expressed 
neutron integration -> Configure node to None because no neutron integration 
expressed
DHCP Provider: Neutron, No network interface in request -> Basic neutron 
integration implied by DHCP provider -> Configure node to Flat to match how 
Ironic works today
DHCP Provider: Neutron, network interface in request -> Basic neutron 
integration implied by DHCP provider, but network interface in request takes 
priority -> Configure node to requested network interface

I suggest we maintain this behaviour for at least a cycle to allow for people 
to upgrade and maintain current functionality and then we can work out what we 
want to do with DHCP providers and the default network interface configuration.

I personally hate the current DHCP provider concept and once we introduce the 
new network interfaces and deprecate cleaning from the existing DHCP providers 
I believe we should consider the DHCP provider's usefulness. We have to 
maintain the current driver interface as it is today for backward compatibility 
for those who have out of tree DHCP providers. But I believe that it is heavily 
tied to both the network interface you pick for a node, and also the PXE boot 
interface (we do not need DHCP options set for virtual media boot for example). 
I personally have been considering whether it should actually be configured has 
part of the driver_info when a node is configured for PXE boot or have the 
logic merged into the network interfaces itself.

Sam

On 28/06/2016 18:28, "Vladyslav Drok" 
> wrote:

Thanks for bringing this up Dmitry, here are my thoughts on this.

Another case is an out-of-tree network driver, that can basically do whatever 
an operator needs to, and may have some parameters defined in driver_info as is 
the case for most of other interfaces ironic drivers have.

I think neutron and flat drivers coexistence in the same deployment is 
unlikely, but neutron and none or flat and none seems to be valid case. As for 
nova, this might be as easy as adding an availability zone with nodes that have 
network isolation enabled.

Also, with all the driver composition work, I think we don't want to have some 
weird things like dhcp providers anymore and go further with interfaces. And if 
it is an interface, it should be considered as such (the basic spec containing 
most of the requirements is merged, and we can use it to make network interface 
as close to the spec as possible, while not going too far, as multitenancy 

[openstack-dev] [ironic] [ironic-python-agent] Broken functional tests

[Sam Betts (sambetts)]

This patch https://review.openstack.org/#/c/324909/ merged last night and
has broken the IPA functional tests.

To verify pull master and run "tox -r -e func" and it¹ll fail to run. If
you git checkout the commit before that one merged the same thing passes
successfully. 

Seeing this error has made me realise that we don¹t have a CI job to run
these functional tests on IPA so this isn¹t caught and highlighted in
gerrit for reviewers, is this on purpose or should we add a new one to
prevent this happening again?

Sam



__
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] Proposing two new cores

[Sam Betts (sambetts)]

Thanks everyone, I¹m super excited to continue my contribute to Ironic!

Sam

On 18/06/2016 16:25, "Jim Rollenhagen" <j...@jimrollenhagen.com> wrote:

>On Thu, Jun 16, 2016 at 11:12:31AM -0400, Jim Rollenhagen wrote:
>> Hi all,
>> 
>> I'd like to propose Jay Faulkner (JayF) and Sam Betts (sambetts) for the
>> ironic-core team.
>> 
>> Jay has been in the community as long as I have, has been IPA and
>> ironic-specs core for quite some time. His background is operations, and
>> he's getting good with Python. He's given great reviews for quite a
>> while now, and the number is steadily increasing. I think it's a
>> no-brainer.
>> 
>> Sam has been in the ironic community for quite some time as well, with
>> close ties to the neutron community as well. His background seems to be
>> in networking, he's got great python skills as well. His reviews are
>> super useful. He doesn't have quite as many as some people, but they are
>> always thoughtful, and he often catches things others don't. I do hope
>> to see more of his reviews.
>> 
>> Both Sam and Jay are to the point where I consider their +1 or -1 as
>> highly as any other core, so I think it's past time to allow them to +2
>> as well.
>> 
>> Current cores, please reply with your vote.
>
>9 out of 11 sounds like consensus to me. Welcome to the team, Jay and
>Sam! :)
>
>ironic-core membership:
>https://review.openstack.org/#/admin/groups/165,members
>
>As a note, the IPA core team was ironic-core plus Jay and Josh. We
>apparently forgot to remove Josh's core rights from IPA when he stopped
>working on ironic, so I've done that. Now that Jay is in ironic-core,
>I've consolidated things such that ironic-core is the review team for
>IPA.
>
>Patch for the IPA change is here: https://review.openstack.org/331425
>
>ironic-python-agent-core membership:
>https://review.openstack.org/#/admin/groups/307,members
>
>// jim
>
>> 
>> // jim
>> 
>> 
>>_
>>_
>> 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] [ironic] using ironic as a replacement for existing datacenter baremetal provisioning

[Sam Betts (sambetts)]

On 07/06/2016 23:59, "Kris G. Lindgren" 
> wrote:

Replying to a digest so sorry for the copy and pastes


>> There's also been discussion of ways we could do ad-hoc changes in RAID 
>> level,
>> based on flavor metadata, during the provisioning process (rather than ahead 
>> of
>> time) but no code has been done for this yet, AFAIK.
>
> I'm still pretty interested in it, because I agree with anything said
> above about building RAID ahead-of-time not being convenient. I don't
> quite understand how such a feature would look like, we might add it as
> a topic for midcycle.

This sounds like an interesting/acceptable way to handle this problem to me.  
Update the node to set the desired raid state from the flavor.

>> - Inspection is geared towards using a different network and dnsmasq

>> infrastructure than what is in use for ironic/neutron.  Which also means 
>> that in
>> order to not conflict with dhcp requests for servers in ironic I need to use
>> different networks.  Which also means I now need to handle swinging server 
>> ports
>> between different networks.
>> Inspector is designed to respond only to requests for nodes in the inspection
> phase, so that it *doesn't* conflict with provisioning of nodes by Ironic. 
> I've
> been using the same network for inspection and provisioning without issue -- 
> so
> I'm not sure what problem you're encountering here.

So I was mainly thinking about the use case of using inspector to onboard 
unknown hosts into ironic (though I see didn't mention that).  So in a 
datacenter we are always on boarding servers.  Right now we boot a linux agent 
that "inventories" the box and adds it to our management system as a node to be 
able to be consumed by a build request.  My understanding is that inspector 
supports this as of Mitaka.  However, the install guide for inspection states 
that you need to install its own dnsmasq instance for inspection.  To me this 
implies that this is suppose to be a separate network.  As if I have 2 dhcp 
servers running on the same L2 network I am going to get races between the 2 
dhcp servers for normal provisioning activities.  Especially if one dhcp server 
is configured to respond to everything (so that it can onboard unknown 
hardware) and the other only to specific hosts(ironic/neutron).  The only way 
that wouldn't be an issue is if both inspector and ironic/neutron are using the 
same dhcp servers.  Or am I missing something?

Ironic inspector handles this by managing Iptables as a firewall service to 
white/black list nodes, only allowing nodes that should be talking to the 
Inspector's dnsmasq instance to be served by it. This avoids any DHCP races 
between Ironic and Inspector.


___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy
__
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] versioning of IPA, it is time or is it?

[Sam Betts (sambetts)]

I personally think that we need IPA versioning, but not so that we can pin a 
version. We need versioning so that we can do more intelligent graceful 
degradation in Ironic without just watching for errors and guessing if a 
feature isn’t available. If we add a new feature in Ironic that requires a 
feature in IPA, then we should add code in Ironic that checks the version of 
IPA (either via an API or reported at lookup) and turns on/off that feature 
based on the version of IPA we’re talking to. Doing this would allow for both 
backwards and forward IPA version compatibility:

Old Ironic with newer IPA: Should just work
New Ironic with old IPA: Ironic should intelligently turn off unsupported 
features, with Warnings in the logs telling the operator if a feature is 
skipped.

Sam

From: Dmitry Tantsur >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, 2 June 2016 22:03
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [ironic] versioning of IPA, it is time or is it?


2 июня 2016 г. 10:19 PM пользователь "Loo, Ruby" 
> написал:
>
> Hi,
>
> I recently reviewed a patch [1] that is trying to address an issue with 
> ironic (master) talking to a ramdisk that has a mitaka IPA lurking around.
>
> It made me think that IPA may no longer be a teenager (yay, boo). IPA now has 
> a stable branch. I think it is time it grows up and acts responsibly. Ironic 
> needs to know which era of IPA it is talking to. Or conversely, does ironic 
> want to specify which microversion of IPA it wants to use? (Sorry, Dmitry, I 
> realize you are cringing.)

With versioning in place we'll have to fix one IPA version in ironic. Meaning, 
as soon as we introduce a new feature, we have to explicitly break 
compatibility with old ramdisk by requesting a version it does not support. 
Even if the feature itself is optional. Or we have to wait some long time 
before using new IPA features in ironic. I hate both options.

Well, or we can use some different versioning procedure :)

>
> Has anyone thought more than I have about this (i.e., more than 2ish minutes)?
>
> If the solution (whatever it is) is going to take a long time to implement, 
> is there anything we can do in the short term (ie, in this cycle)?
>
> --ruby
>
> [1] https://review.openstack.org/#/c/319183/
>
>
>
> __
> 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] [ironic] usage of ironic-lib

[Sam Betts (sambetts)]

I personally disagree with saying that if we wanted it make it usable by
projects other than ones in the Ironic umbrella it should go into oslo. I
think that non-ironic projects directly related to Ironic such as out of
tree drivers etc, should be able to utilise the code placed into
ironic-lib. 

Neutron are doing a very similar thing for all their drivers/extensions
they have broken out over the last 2 cycles,
http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-li
b.html. 

Making ironic-lib available to out of tree drivers etc also puts us into a
good position to begin the work to stabilise things like the driver API.
Neutron is making the rule that out of tree drivers shouldn¹t
inherit/import anything from the neutron core code base, only neutron-lib,
they are doing this to provide a stable interface that shouldn¹t be broken
by changes to neutron core. I think we could do the same, with in-tree
drivers dog-fooding the driver api we provide in ironic-lib.

Sam

On 16/05/2016 15:14, "Lucas Alvares Gomes"  wrote:

>Hi,
>
>Thanks for starting this discussion Ruby.
>
>On Mon, May 16, 2016 at 2:57 PM, Loo, Ruby  wrote:
>> Hi,
>>
>> A patch to ironic-lib made me wonder about what is our supported usage
>>of
>> ironic-lib. Or even the intent/scope of it. This patch changes a method,
>> Œbootable¹ parameter is removed and Œboot_flag¹ parameter is added [1].
>>
>> If this library/method is used by some out-of-tree thing (or even some
>> in-tree but outside of ironic), this will be a breaking change. If this
>> library is meant to be internal to ironic program itself, and to e.g.
>>only
>> be used by ironic and IPA, then that is different. I was under the
>> impression that it was a library and meant to be used by whatever, no
>> restrictions on what that whatever was. It would be WAY easier if we
>>limited
>> this for usage by only a few specified projects.
>>
>> What do people think?
>>
>
>I still believe that the ironic-lib project was designed to share code
>between the Ironic projects _only_. Otherwise, if it the code was
>supposed to be shared across multiple projects we should have put it
>in oslo instead.
>
>The governance description is a bit vague [0], it does say: "A python
>library of common ironic utilities.". Does it include out-of-tree
>ironic-related code? I would like to think that it does not. The fact
>that ( IIRC ) we never stated that this is a public library, there's
>no documentation of any methods/modules there, no release notes, no
>sample usages, etc... Makes it a bit unsuitable for 3rd party
>consumption.
>
>That said, I'm not totally against make this library suitable for a
>broader usage but this will require more thoughts on it and effort.
>
>[0] 
>https://github.com/openstack-infra/project-config/blob/920441f2fc02df89624
>5b53e6f18b4ea6a0252a0/gerrit/projects.yaml#L2193
>
>Cheers,
>Lucas
>
>__
>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] [ironic][nova][neutron][qa] Injecting code into grenade resource create phase

[Sam Betts (sambetts)]

Its easy enough to setup devstack today to use a flat neutron network
instead of faking it using the tenant networks which we don¹t support, I
do it in my third party CI for real hardware, if we can make it work for
fake BM VMs too would it solve this issue, or would grenade override that?

For reference these are the extra settings I have to add to make it work
for real hardware with no changes to the Ironic devstack plugin:

PUBLIC_INTERFACE={phys_interface}

Q_L3_ENABLED=False
Q_USE_PROVIDER_NETWORKING=True
OVS_PHYSICAL_BRIDGE=br-{phys_interface}
PHYSICAL_NETWORK=private # Because the ironic devstack plugin looks for a
network called "private"
PROVIDER_NETWORK_TYPE=³flat²

ENABLE_ISOLATED_METADATA=True


Sam Betts

On 12/05/2016 11:48, "Sean Dague"  wrote:

>On 05/11/2016 05:53 PM, Jim Rollenhagen wrote:
>> I've ran into a bit of a wedge working on ironic grenade tests.
>> 
>> In a normal dsvm run, the ironic setup taps the control plane into the
>> tenant network (as that's how it's currently intended to be deployed).
>> That code is here[0].
>> 
>> However, in a grenade run, during the resource create phase, a new
>> network is created. This happens in the neutron bits[1], and is used to
>> boot a server in the nova bits[2].
>> 
>> Since the control plane can't communicate with the machine on that
>> network, our ramdisk doesn't reach back to ironic after booting up, and
>> provisioning fails[3][4].
>> 
>> Curious if any grenade experts have thoughts on how we might be able to
>> set up that tap in between the neutron and nova resource creation.
>> 
>> One alternative I've considered is a method to have nova resource
>> creation not boot an instance, and replicate that functionality in the
>> ironic plugin, after we tap into that network.
>> 
>> I'm sure there's other alternatives here that I haven't thought of;
>> suggestions welcome. Thanks in advance. :)
>> 
>> // jim
>> 
>> [0] 
>>https://github.com/openstack/ironic/blob/95ff5badbdea0898d7877e6518939160
>>08561760/devstack/lib/ironic#L653
>> [1] 
>>https://github.com/openstack-dev/grenade/blob/fce63f40d21abea926d343e9cdd
>>d620e3f03684a/projects/50_neutron/resources.sh#L34
>> [2] 
>>https://github.com/openstack-dev/grenade/blob/fce63f40d21abea926d343e9cdd
>>d620e3f03684a/projects/60_nova/resources.sh#L79
>> [3] 
>>http://logs.openstack.org/65/311865/3/experimental/gate-grenade-dsvm-iron
>>ic/e635dec/logs/grenade.sh.txt.gz#_2016-05-10_18_10_03_648
>> [4] 
>>http://logs.openstack.org/65/311865/3/experimental/gate-grenade-dsvm-iron
>>ic/e635dec/logs/old/screen-ir-cond.txt.gz?level=WARNING
>
>Let me make sure I understand the crux of the issue: services may need
>to create additional custom networking in order for the rest of the
>resource flow to work correctly. Ironic definitely needs this because
>it's building up an interesting simulated network here for it's guests
>to live on.
>
>That feels like we need a new pre_create (or early_create) phase that
>ironic could hook into to do that same network create. I think the only
>question in my mind is whether neutrons network create here should move
>to early_create as well.
>
>Does ironic's ovs setup need to happen after the neutron create phase
>here, or does it just need to happen before nova?
>
>Does ironic need to overwrite the $net_id that gets passed to Nova later?
>
>   -Sean
>
>-- 
>Sean Dague
>http://dague.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


__
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] [inspector] Proposing Anton Arefiev (aarefiev) for ironic-inspector-core

[Sam Betts (sambetts)]

Congrats Anton!!! 

Sam

On 12/04/2016 10:52, "Dmitry Tantsur"  wrote:

>On 04/05/2016 12:24 PM, Dmitry Tantsur wrote:
>> Hi!
>>
>> I'd like to propose Anton to the ironic-inspector core reviewers team.
>> His stats are pretty nice [1], he's making meaningful reviews and he's
>> pushing important things (discovery, now tempest).
>>
>> Members of the current ironic-inspector-team and everyone interested,
>> please respond with your +1/-1. A lazy consensus will be applied: if
>> nobody objects by the next Tuesday, the change will be in effect.
>
>The change is in effect, congratulations! :)
>
>>
>> Thanks
>>
>> [1] http://stackalytics.com/report/contribution/ironic-inspector/60
>>
>> 
>>_
>>_
>> 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] [Ironic] Failed to update Neutron port

[Sam Betts (sambetts)]

Looking at the errors here it appears that everything is configured correctly 
in Ironic (mac addresses etc) because you are getting through the ramdisk boot 
and deploy successfully.

The error that is of real concern here is "Unauthorized: {"error": {"message": 
"The resource could not be found.", "code": 404, "title": "Not Found"}}" which 
seems to imply that something is wrong with the auth information given to 
Ironic and its failing to authenticate with Keystone as part of the neutron 
client. The resource could not be found error is thrown when it can’t find the 
tenant or user requested in the config file.

Sam


From: "Haomeng, Wang" >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, 11 April 2016 02:45
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Ironic] Failed to update Neutron port

Hi,

With my experence, for such "2016-04-08 16:31:38.690 31893 ERROR 
ironic.dhcp.neutron [-] Failed to update Neutron port 
7fb98457-90e6-43be-a353-f03ea1959912." issue, some cases are that root cause is 
we did not register baremetal's mac into ironic, so neutron can not bind mac 
for baremetal dhcp/pxe, and set DHCP BOOT option for port, so run below command 
if it is missing:


ironic port-create -n $NODE_UUID -a $MAC_ADDRESS


Good luck!


On Fri, Apr 8, 2016 at 10:00 PM, Senthilprabu Shanmugavel 
> wrote:
Hello,

I am deploying an ARMv8 board using Ironic integrated with Openstack Liberty on 
Ubuntu 12.04 host. I am using fake_pxe driver and doing the power on manually. 
Deploy image created from disk image creator tool

Nova boot starts the deployment, deployment image is booted, ironic-agent is 
able to communicate with ironic conductor. After this, scsi connection is 
established, I can see this in syslog in ironic conductor node


Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.620364] scsi host10: 
iSCSI Initiator over TCP/IP
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.885579] scsi 10:0:0:0: 
RAID  IET  Controller   0001 PQ: 0 ANSI: 5
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.886404] scsi 10:0:0:0: 
Attached scsi generic sg2 type 12
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.887088] scsi 10:0:0:1: 
Direct-Access IET  VIRTUAL-DISK 0001 PQ: 0 ANSI: 5
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.888157] sd 10:0:0:1: 
Attached scsi generic sg3 type 0
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.888490] sd 10:0:0:1: 
[sdc] 15240576 512-byte logical blocks: (7.80 GB/7.26 GiB)
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.889114] sd 10:0:0:1: 
[sdc] Write Protect is off
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.889118] sd 10:0:0:1: 
[sdc] Mode Sense: 69 00 10 08
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.889462] sd 10:0:0:1: 
[sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.894611]  sdc: unknown 
partition table
Apr  8 16:31:35 lionfish-ocp-controller kernel: [13.896728] sd 10:0:0:1: 
[sdc] Attached SCSI disk
Apr  8 16:31:35 lionfish-ocp-controller iscsid: Connection4:0 to [target: 
iqn.2008-10.org.openstack:5044c5ab-a4f5-4ba1-9e3d-01a0cc9bb9e0, portal: 
192.168.2.161,3260] through [iface: default] is operational now

On my node console, I see below messages

root@ubuntu:~# SysRq : Emergency Sync
SysRq : Power Off
reboot: Power down

I think this is triggered by scsi driver (also seen in ironic conductor syslog) 
but node did not reboot due to known problem. So I powered off manually and 
powered on.

Apr  8 16:31:38 lionfish-ocp-controller kernel: [16.290404] sd 10:0:0:1: 
[sdc] Synchronizing SCSI cache
Apr  8 16:31:38 lionfish-ocp-controller iscsid: Connection4:0 to [target: 
iqn.2008-10.org.openstack:5044c5ab-a4f5-4ba1-9e3d-01a0cc9bb9e0, portal: 
192.168.2.161,3260] through [iface: default] is shutdown.

So far looks good. I was expecting user image download via scsi is successful 
and should be booted after going down.

By then ironic conductor log says deployment failed due to neutron failing to 
set DHCP BOOT option for port.


2016-04-08 16:31:14.229 31893 INFO ironic.drivers.modules.agent_base_vendor 
[req-c1e50ceb-1e11-47ea-9260-e30a2f10605d - - - - -] Initial lookup for node 
5044c5ab-a4f5-4ba1-9e3d-01a0cc9bb9e0 succeeded, agent is running and waiting 
for commands
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron [-] Failed to update 
Neutron port 7fb98457-90e6-43be-a353-f03ea1959912.
2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron Traceback (most recent 
call last):
2016-04-08 16:31:38.690 31893 ERROR 

Re: [openstack-dev] [ironic] [inspector] Proposing Anton Arefiev (aarefiev) for ironic-inspector-core

[Sam Betts (sambetts)]

+1 from me too :D 

Sam 

On 05/04/2016 17:45, "Jim Rollenhagen"  wrote:

>+1 from me :)
>
>// jim 
>
>> On Apr 5, 2016, at 03:24, Dmitry Tantsur  wrote:
>> 
>> Hi!
>> 
>> I'd like to propose Anton to the ironic-inspector core reviewers team.
>>His stats are pretty nice [1], he's making meaningful reviews and he's
>>pushing important things (discovery, now tempest).
>> 
>> Members of the current ironic-inspector-team and everyone interested,
>>please respond with your +1/-1. A lazy consensus will be applied: if
>>nobody objects by the next Tuesday, the change will be in effect.
>> 
>> Thanks
>> 
>> [1] http://stackalytics.com/report/contribution/ironic-inspector/60
>> 
>> 
>>_
>>_
>> 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] [Ironic] Clarifications about ThirdParty CI deadlines

[Sam Betts (sambetts)]

I'll try to answer your questions as best I can. As I understand it, "receive 
events" means that you can listen to the gerrit stream and take an action when 
for example a new patch is uploaded or a recheck comment is left etc. Initially 
we encourage people to get their CI listening to the ci-sandbox project for 
testing and making sure comments are pushed correctly etc, but once testing is 
complete and your happy to start receiving events from openstack/ironic you can 
switch over to that, there isn't a requirement to keep posting in the sandbox.


Sam

From: Thiago Paiva >
Reply-To: "OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)" 
>
Date: Monday, 7 March 2016 19:48
To: "OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)" 
>
Subject: [openstack-dev] [Ironic] Clarifications about ThirdParty CI deadlines

Hello folks,

My project is in need of some clarifications about the deadlines for the CI 
deployment on [1]. If you can kindly answer these questions to help us consider 
changes on our sprint planning to address the community requirements, would be 
very very helpful:

1) In the point 2, what do we mean by "receive events"? Is is about reading 
from the event stream of Gerrit and take the appropriate actions? Act upon 
"check experimental" or "check " comments are considered valid to 
fulfill this requirement?

2) We are a little confused with the phrase "post comments in the sandbox". By 
that we mean commenting on the "openstack-infra/ci-sandbox" project? Do we need 
to keep commenting on sandbox even when we have already set-up the job to read 
events and comment results for the "openstack/ironic" project?


Thank you,


[1] https://wiki.openstack.org/wiki/Ironic/Testing#Third_Party_CI_Requirements

Thiago Paiva Brito
Lead Software Engineer
OneView Drivers for Openstack Ironic
__
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] midcycle voice channel is 7777

[Sam Betts (sambetts)]

 is working for the Thursday midcycle session so we are moving back to
that channel.

Sam

On 17/02/2016 15:19, "Jim Rollenhagen"  wrote:

>So, someone has injected their hold music into 7778. We've now moved to
>7779, sorry for the trouble :(
>
>// jim
>
>On Wed, Feb 17, 2016 at 07:01:22AM -0800, Jim Rollenhagen wrote:
>> Hi,
>> 
>> We've moved the midcycle to channel 7778 on the infra conferencing
>> system - something is wrong with  (no audio coming through).
>> 
>> /me lets infra know as well
>> 
>> // jim
>> 
>> 
>>_
>>_
>> 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] [ironic] [tripleo] [stable] Phasing out old Ironic ramdisk and its gate jobs

[Sam Betts (sambetts)]

My preference is option 4, however with a slight difference, and that is
that we only apply the DIB cap to the job that¹s testing the bash ramdisk.
We can say that the bash ramdisk is deprecated in liberty and will not be
receiving any further updates, so we¹re capping the DIB version, but
because the IPA ramdisks are LTS then we will keep testing latest DIB for
those. WDYT?

Sam

On 17/02/2016 11:27, "Dmitry Tantsur"  wrote:

>Hi everyone!
>
>Yesterday on the Ironic midcycle we agreed that we would like to remove
>support for the old bash ramdisk from our code and gate. This, however,
>pose a problem, since we still support Kilo and Liberty. Meaning:
>
>1. We can't remove gate jobs completely, as they still run on
>Kilo/Liberty.
>2. Then we should continue to run our job on DIB, as DIB does not have
>stable branches.
>3. Then we can't remove support from Ironic master as well, as it would
>break DIB job :(
>
>I see the following options:
>
>1. Wait for Kilo end-of-life (April?) before removing jobs and code.
>This means that the old ramdisk will essentially be supported in Mitaka,
>but we'll remove gating on stable/liberty and stable/mitaka very soon.
>Pros: it will happen soon. Cons: in theory we do support the old ramdisk
>on Liberty, so removing gates will end this support prematurely.
>
>2. Wait for Liberty end-of-life. This means that the old ramdisk will
>essentially be supported in Mitaka and Newton. We should somehow
>communicate that it's not official and can be dropped at any moment
>during stable branches life time. Pros: we don't drop support of the
>bash ramdisk on any branch where we promised to support it. Cons: people
>might assume we still support the old ramdisk on Mitaka/Newton; it will
>also take a lot of time.
>
>3. Do it now, recommend Kilo users to switch to IPA too. Pros: it
>happens now, no confusing around old ramdisk support in Mitaka and
>later. Cons: probably most Kilo users (us included) are using the bash
>ramdisk, meaning we can potentially break them when landing changes on
>stable/kilo.
>
>4. Upper-cap DIB in stable/{kilo,liberty} to the current release, then
>remove gates from Ironic master and DIB, leaving them on Kilo and
>Liberty. Pros: we can remove old ramdisk support right now. Cons: DIB
>bug fixes won't affect kilo and liberty any more.
>
>5. The same as #4, but only on Kilo.
>
>As gate on stable/kilo is not working right now, and end-of-life is
>quickly approaching, I see number 3 as a pretty viable option anyway. We
>probably won't land any more changes on Kilo, so no use in keeping gates
>on it. Liberty is still a concern though, as the old ramdisk was only
>deprecated in Liberty.
>
>What do you all think? Did I miss any options?
>
>Cheers,
>Dmitry
>
>__
>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] [ironic] [inspector] Auto discovery extension for Ironic Inspector

[Sam Betts (sambetts)]

What Yuiko has described makes a lot of sense, and from that perspective 
perhaps instead of us defining what driver a node should and shouldn't be using 
a config file, we should just provide a guide to using the inspector rules for 
this and maybe some prewritten rules that can set the driver and driver info 
etc fields for different cases?

Then the work flow would be, default to Fake driver because we don't need any 
special info for that, however if a rule detects that its IPMIable by making 
sure that the IPMI address is valid or something, then it can set the driver to 
an ipmitool one and then set the password and username based on either a 
retrieved field or values defined in the rule itself.

WDYT?

Sam
__
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] [OSC] Quick poll: OpenStackClient command for provision action

[Sam Betts (sambetts)]

I think all the filtering etc that exists on the current CLI should move over 
to OSC, I personally find things like --fields super useful.


+1 to removing "chassis show --nodes" and making it part of node list.


+1 to deploy, instead of activate. Jim also suggested provision. WDYT?


I'd only chosen boot and shutdown because they were the only 1 word synonyms I 
could think of for power on and power off, if everyone else is happy with 
poweron and poweroff, then so am I :) I'm also not sure what to do about 
maintenance mode, maybe something like quarantine and unquarantine? I quite 
like ignore, as its descriptive of whats actually happening, but I'm unsure of 
the best antonym for it, I was thinking acknowledge or something like that.


Heres a revised list of commands based on everyone's suggestions so far:


openstack baremetal [node/driver/chassis/port] list [For ports --node, For 
nodes --chassis]

openstack baremetal [node/driver/chassis/port] show UUID [For nodes --states, 
For driver --properties]


openstack baremetal [node/chassis/port] create

openstack baremetal [node/chassis/port] update UUID

openstack baremetal [node/chassis/port] delete UUID


openstack baremetal node provide UUID

openstack baremetal node deploy UUID

openstack baremetal node rebuild UUID

openstack baremetal node inspect UUID

openstack baremetal node validate UUID

openstack baremetal node manage UUID

openstack baremetal node abort UUID

openstack baremetal node poweron UUID

openstack baremetal node poweroff UUID

openstack baremetal node reboot UUID


openstack baremetal node ignore UUID

openstack baremetal node acknowledge UUID


openstack baremetal node console [--enable, --disable] UUID

openstack baremetal node boot-device [--supported, --set CDROM, PXE, DISK] UUID


openstack baremetal [node/driver] vendor NAME_OR_UUID METHOD


WDYT?


Sam
__
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] [OSC] Quick poll: OpenStackClient command for provision action

[Sam Betts (sambetts)]

Openstack baremetal provision provide or -provide Just doesn't feel right to 
me, it feels like I am typing more that I need to and it feels like I'm telling 
it to do the same action twice.

I would much rather see:

Openstack baremetal provide UUID
Openstack baremetal activate UUID
Openstack baremetal delete UUID
Openstack baremetal rebuild UUID
Openstack baremetal inspect UUID
Openstack baremetal manage UUID
Openstack baremetal abort UUID

And for power:

Openstack baremetal boot UUID
Openstack beremetal shutdown UUID
Openstack baremetal reboot UUID

WDYT?

Sam

From: "Haomeng, Wang" >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, 10 November 2015 10:49
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command 
for provision action


How about below format?

#openstack baremetal   

Example:

#openstack baremetal provision provide 
#openstack baremetal power on/off  

I think it is easy to understand and remember:)



On Tue, Nov 10, 2015 at 6:17 PM, Pavlo Shchelokovskyy 
> wrote:
Hi,
I like the last variant by Lucas, and agree we need to ensure the CLI interface 
is consistent between power and provision commands.

Best regards,


On Tue, Nov 10, 2015 at 12:00 PM Lucas Alvares Gomes 
> wrote:
> It's still not 100% consistent, "power" is a noun, "provision" is a verb.
> Not sure it matters, though, adding OSC folks so that they can weigh in.
>

"provision" can also be a noun [1]. But since the OSC syntax suggest
having a verb we could have something like:

$ openstack baremetal set power --on | --off 
$ openstack baremetal set provision --provide | --active | ... 

[1] http://www.thefreedictionary.com/provision

__
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
--
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.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

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

[Sam Betts (sambetts)]

So you would end up with a set of commands that look like this:

Openstack baremetal [node/driver/chassis] list
Openstack baremetal port list [-node uuid] <- replicate node-port-list

Openstack baremetal [node/port/driver] show UUID
Openstack baremetal chassis show [-nodes] UUID  <- replicate chassis-node-list

Openstack baremetal [node/chassis/port] create
Openstack baremetal [node/chassis/port] update UUID
Openstack baremetal [node/chassis/port] delete UUID

Openstack baremetal [node/chassis] provide UUID
Openstack baremetal [node/chassis] activate UUID
Openstack baremetal [node/chassis] rebuild UUID
Openstack baremetal [node/chassis] inspect UUID
Openstack baremetal [node/chassis] manage UUID
Openstack baremetal [node/chassis] abort UUID
Openstack baremetal [node/chassis] boot UUID
Openstack baremetal [node/chassis] shutdown UUID
Openstack baremetal [node/chassis] reboot UUID

Openstack baremetal node maintain [-done] UUID
Openstack baremetal node console [-enable, -disable] UUID <- With no parameters 
this acts like node-get-console, otherwise acts like node-set-console-mode
Openstack baremetal node boot-device [-supported, -PXE, -CDROM, etc] UUID <- 
With no parameters this acts like node-get-boot-device, -supported makes it act 
like node-get-supported-boot-devices, and with a type of boot device passed in 
it’ll act like node-set-boot-device

Openstack baremetal [node/driver] passthru

WDYT? I think I’ve covered most of what exists in the Ironic CLI currently.

Sam

From: "Haomeng, Wang" <wanghaom...@gmail.com<mailto:wanghaom...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, 10 November 2015 11:41
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command 
for provision action

Hi Sam,

Yes, I understand your format is：

#openstack baremetal  

so these can cover all 'node' operations however if we want to cover support 
port/chassis/driver and more ironic resources, so how about below proposal?

#openstack baremetal   

The resource/target can be one item in following list:

node
port
chassis
driver
...

Make sense?




On Tue, Nov 10, 2015 at 7:25 PM, Sam Betts (sambetts) 
<sambe...@cisco.com<mailto:sambe...@cisco.com>> wrote:
Openstack baremetal provision provide or -provide Just doesn’t feel right to 
me, it feels like I am typing more that I need to and it feels like I’m telling 
it to do the same action twice.

I would much rather see:

Openstack baremetal provide UUID
Openstack baremetal activate UUID
Openstack baremetal delete UUID
Openstack baremetal rebuild UUID
Openstack baremetal inspect UUID
Openstack baremetal manage UUID
Openstack baremetal abort UUID

And for power:

Openstack baremetal boot UUID
Openstack beremetal shutdown UUID
Openstack baremetal reboot UUID

WDYT?

Sam

From: "Haomeng, Wang" <wanghaom...@gmail.com<mailto:wanghaom...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, 10 November 2015 10:49
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command 
for provision action


How about below format?

#openstack baremetal   

Example:

#openstack baremetal provision provide 
#openstack baremetal power on/off  

I think it is easy to understand and remember:)



On Tue, Nov 10, 2015 at 6:17 PM, Pavlo Shchelokovskyy 
<pshchelokovs...@mirantis.com<mailto:pshchelokovs...@mirantis.com>> wrote:
Hi,
I like the last variant by Lucas, and agree we need to ensure the CLI interface 
is consistent between power and provision commands.

Best regards,


On Tue, Nov 10, 2015 at 12:00 PM Lucas Alvares Gomes 
<lucasago...@gmail.com<mailto:lucasago...@gmail.com>> wrote:
> It's still not 100% consistent, "power" is a noun, "provision" is a verb.
> Not sure it matters, though, adding OSC folks so that they can weigh in.
>

"provision" can also be a noun [1]. But since the OSC syntax suggest
having a verb we could have something like:

$ openstack baremetal set power --on | --off 
$ openstack baremetal set provision --provide | --active | ... 

[1] http://www.thefreedictionary.com/provision

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?su

[openstack-dev] [ironic] [inspector] Auto discovery extension for Ironic Inspector

[Sam Betts (sambetts)]

Auto discovery is a topic which has been discussed a few times in the past for

Ironic, and its interesting to solve because its a bit of a chicken and egg

problem. The ironic inspector allows us to inspect nodes that we don't know

the mac addresses for yet, to do this we run a global DHCP PXE rule that will

respond to all mac addresses and PXE boot any machine that requests it,

this means its possible for machines that we haven't been asked to

inspect to boot into the inspector ramdisk and send their information to

inspector's API. To prevent this data from being processed further by

inspector if its a machine we shouldn't care about, we do a node lookup. If the 
data

fails this node lookup we used to drop this data and continue no further, in

release 2.0.0 we added a hook point to intercept this state called the Node Not

Found hook point which allows us to run some python code at this point in

processing before failing and dropping the inspection data. Something we've

discussed as a use for this hook point is, enrolling a node that fails the

lookup into Ironic, and then having inspector continue to process the

inspection data as we would for any other node that had inspection requested

for it, this allows us to auto-discover unknown nodes into Ironic.


If this auto discovery hook was enabled this would be the flow when inspector

receives inspection data from the inspector ramdisk:


- Run pre-process on the inspection data to sanitise the data and ready it for

  the rest of the process


- Node lookup using fields from the inspection data:

  - If in inspector node cache return node info


  - If not in inspector node cache and but is in ironic node database, fail

inspection because its a known node and inspection hasn't been requested

for it.


  - If not in inspector node cache or ironic node database, enroll the node in

ironic and return node info


- Process inspection data


The remaining question for this idea is how to handle the driver settings for

each node that we discover, we've currently discussed 3 different options:


1. Enroll the node in ironic using the fake driver, and leave it to the operator

   to set the driver type and driver info before they move the node from enroll

   to manageable.


2. Allow for the default driver and driver info information to be set in the

   ironic inspector configuration file, this will be set on every node that is

   auto discovered. Possible config file example:


   [autodiscovery]

   driver = pxe_ipmitool

   address_field = 

   username_field = 

   password_field = 


3. A possibly vendor specific option that was suggested at the summit was to

   provide an ability to look up out of band credentials from an external CMDB.


The first option is technically possible using the second option, by setting

the driver to fake and leaving the driver info blank.


With IPMI based drivers most IPMI related information can be retrieved from the

node by the inspector ramdisk, however for non-ipmi based drivers such as the

cimc/ucs drivers this information isn't accessible from an in-band OS command.


A problem with option 2 is that it can not account for a mixed driver

environment.


We have also discussed for IPMI based drivers inspector could set a new

randomly generated password on to the freshly discovered node, with the idea

being fresh hardware often comes with a default password, and if you used

inspector to discover it then it could set a unique password on it and

automatically make ironic aware of that.


We're throwing this idea out onto the mailer because we'd like to get feedback

from the community to see if this would be useful for people using inspector,

and to see if people have any opinions on what the right way to handle the node

driver settings is.


Sam (sambetts)

__
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] [ironic] [inspector] [neutron] DHCP Options on Neutron networks

[Sam Betts (sambetts)]

For the ironic inspector to be able to inspect nodes that we don't know the

mac addresses for we have to run a DHCP rule that will respond to all mac

addresses for PXE booting the inspector ramdisk. In order to provide this

functionality right now we are running our own instance of dnsmasq,

configuring it independently and manually plumbing it into OpenStack. At the

summit we discussed that we would like to move away from managing our own DHCP

server and would like to take advantage of the existing DHCP server implemented

by neutron. However this would require being able to set global/wildcard DHCP

rules in neutron which I'm aware isn't possible right now, as DHCP options are

only set on ports.


A solution that we came up with would be the ability to set DHCP options on a

neutron network which would apply to any machine that made a DHCP request in

that network, however if any DHCP options were set on a port they would

override the network level options. This way we could setup a PXE option at

the network level for PXE booting any machine in that network that requests it.


We'd like to get some opinions on this idea from the neutron team, we think

that if implemented correctly there could be uses for it outside of the

inspector use case. We look forward to any feedback.


Sam (sambetts)
__
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] Suggestion to split install guide

[Sam Betts (sambetts)]

Looking at what they¹re building for Neutron,
http://docs.openstack.org/networking-guide, they have a quite fine grain
splitting of their guide with a large contents page that helps find things
easily. My personal issues with the current ironic guide all comes down to
navigation, the current Table of contents system is unpleasant to use,
splitting the guide into multiple pages will help this to a degree because
it¹ll reduce the amount of times I end up either using Ctrl-F or scrolling
back to the top to look at the contents, but I think it would be nice to
have a reworked contents page.

As a side note I don¹t know about other people but I prefer the styling of
the Neutron guide, but is that something that we even have a choice in?

Sam

On 14/09/2015 15:00, "Dmitry Tantsur"  wrote:

>On 09/14/2015 03:54 PM, Ruby Loo wrote:
>>
>>
>> On 11 September 2015 at 04:56, Dmitry Tantsur > > wrote:
>>
>> Hi all!
>>
>> Our install guide is huge, and I've just approved even more text for
>> it. WDYT about splitting it into "Basic Install Guide", which will
>> contain bare minimum for running ironic and deploying instances, and
>> "Advanced Install Guide", which will the following things:
>> 1. Using Bare Metal service as a standalone service
>> 2. Enabling the configuration drive (configdrive)
>> 3. Inspection
>> 4. Trusted boot
>> 5. UEFI
>>
>> Opinions?
>>
>>
>> Thanks for bringing this up Dmitry. Any idea whether there is some sort
>> of standard format/organization of install guides for the other
>> OpenStack projects?
>
>Not sure
>
> > And/or maybe we should ask Ops folks (non developers
>> :-))
>
>Fair enough. I've proposed basic vs advanced split based on what we did
>for TripleO downstream, which was somewhat user-driven.
>
>>
>> --ruby
>>
>>
>> 
>>_
>>_
>> 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] [Ironic] [Inspector] Addition to ironic-inspector-core: Sam Betts

[Sam Betts (sambetts)]

Thanks everyone, proud to be on the team!

Sam

On 25/08/2015 12:32, Lucas Alvares Gomes lucasago...@gmail.com wrote:

Congrats! Well deserved

On Tue, Aug 25, 2015 at 12:24 PM, Yuiko Takada
yuikotakada0...@gmail.com wrote:
 Sam, congrats and welcome!


 Yuiko Takada

 2015/08/25 19:53、Dmitry Tantsur dtant...@redhat.com のメッセージ:

 Hi all!

 Please join me in welcoming Sam to our team! He has been doing very
smart reviews recently, was contributing core features and expressed
clear interest in the ironic-inspector project.

 Thanks and welcome!

 

__
 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


__
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] Let's talk about API versions

[Sam Betts (sambetts)]

After reading through this thread as a whole, I¹d like to summarise my
thoughts so far: 

* I've noticed all these discussions revolve around existing people using
the API, and seem to ignore that most new users of the API don¹t care how
it used to work, and just want the full feature set without having to
opt-in². 

* While I was reading the thread, I realised how much I hate calling the
client a client, I don¹t think we should think of it as a client (like a
messaging or mail client) because it distances it from the actual API, I
see it as a python API hook and as an API command line interface that you
would build clients with. The level of abstraction should be just enough
but not so much that it feels like a separate thing from the REST API. So
if we solve the problem for the REST API then I think the python and
command line should expose it in the same way. And I personally feel that
explicit is the way forward, and if you don¹t specify a version we should
error, provide no default, and no fall back, for those who don¹t want to
use a specific version or are happy with whatever they are given, we
should provide keywords that can be given instead of a version such as
³latest², ³given or something to that effect. In this situation everyone
knows what they are getting.

- Sam

On 29/07/2015 10:01, Lucas Alvares Gomes lucasago...@gmail.com wrote:

 1. yes
 2. no -- the client should default to the minimum supported version.
We got
 that wrong previously, and that's what is hurting us now.

 So if we do this, simply shipping the code doesn't break anyone. Nobody
 has disagreed on this yet, best I can tell.


We would still need a deprecation period here if we want to have the
client to default to the minimum supported version again. People using
the client may be relying on the features up to version 1.9 (which is
the pinned one right now).

__
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] [Ironic] disambiguating the term discovery

[Sam Betts (sambetts)]

I agree with Devananda's definition of Œhardware discovery¹ and other
tools similar to Ironic use the term discovery in this way, however I have
found that these other tools often bundle the gathering of the system
properties together with the discovery of the hardware as a single step
from a user perspective. I also agree that in Ironic there needs to be a
separate term for that (at least from a dev perspective) and I think
Lucas¹s suggestion of Œhardware interrogation¹ or something like Œhardware
inventory¹ would be more explanatory at first glance than Œintrospection¹.

- Sam



On 21/10/2014 09:52, Lucas Alvares Gomes lucasago...@gmail.com wrote:

+1 for the separation

I already gave up of the term discovery as you can see on the DRAC
Hardware Introspection[1] spec, I also don't think that
introspection is the best word for that (we already use the world
cloud for OpenStack so it can't get more confusing than that).
Perhaps interrogation would be another term for that.

[1] https://review.openstack.org/#/c/125920

Cheers,
Lucas

On Tue, Oct 21, 2014 at 8:49 AM, Dmitry Tantsur dtant...@redhat.com
wrote:
 On 10/21/2014 02:11 AM, Devananda van der Veen wrote:

 Hi all,

 I was reminded in the Ironic meeting today that the words hardware
 discovery are overloaded and used in different ways by different
 people. Since this is something we are going to talk about at the
 summit (again), I'd like to start the discussion by building consensus
 in the language that we're going to use.

 So, I'm starting this thread to explain how I use those two words, and
 some other words that I use to mean something else which is what some
 people mean when they use those words. I'm not saying my words are the
 right words -- they're just the words that make sense to my brain
 right now. If someone else has better words, and those words also make
 sense (or make more sense) then I'm happy to use those instead.

 So, here are rough definitions for the terms I've been using for the
 last six months to disambiguate this:

 hardware discovery
 The process or act of identifying hitherto unknown hardware, which is
 addressable by the management system, in order to later make it
 available for provisioning and management.

 hardware introspection
 The process or act of gathering information about the properties or
 capabilities of hardware already known by the management system.

 I generally agree with this separation, though it brings some troubles
to
 me, as I'm used to calling discovery what you called introspection
(it
 was not the case this summer, but now I changed my mind). And the term
 discovery is baked into the.. hmm.. introspection service that I've
 written [1].

 So I would personally prefer to leave discovery as in discovery of
 hardware properties, though I realize that introspection may be a
better
 name.

 [1] https://github.com/Divius/ironic-discoverd



 Why is this disambiguation important? At the last midcycle, we agreed
 that hardware discovery is out of scope for Ironic -- finding new,
 unmanaged nodes and enrolling them with Ironic is best left to other
 services or processes, at least for the forseeable future.

 However, introspection is definitely within scope for Ironic. Even
 though we couldn't agree on the details during Juno, we are going to
 revisit this at the Kilo summit. This is an important feature for many
 of our current users, and multiple proof of concept implementations of
 this have been done by different parties over the last year.

 It may be entirely possible that no one else in our developer
 community is using the term introspection in the way that I've
 defined it above -- if so, that's fine, I can stop calling that
 introspection, but I don't know a better word for the thing that is
 find-unknown-hardware.

 Suggestions welcome,
 Devananda


 P.S.

 For what it's worth, googling for hardware discovery yields several
 results related to identifying unknown network-connected devices and
 adding them to inventory systems, which is the way that I'm using the
 term right now, so I don't feel completely off in continuing to say
 discovery when I mean find unknown network devices and add them to
 Ironic.

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



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

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


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

Re: [openstack-dev] Usage of @author tags in the header of Python files

[Sam Betts (sambetts)]

On 08/10/2014 10:39, Ihar Hrachyshka ihrac...@redhat.com wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/10/14 09:30, Christian Berendt wrote:
 After proposing a change to Horizon to remove the @author tags from
 the header of Python files
 (https://review.openstack.org/#/c/126656/) Matthias Runge proposed
 to discuss this first on the mailing list.
 
 Is it necessary to track the authorship of a file inside the file
 using @author tags?

Git is a lot better in attributing authorship, so for me, @author tags
are just a waste of precious disk bytes and cpu cycles.

+1 


 
 The copyright statement itself is unchanged and intact after the
 removal of the @author tags.
 
 The copyright statement is not addicted to the authorship of a file
 so it should be safe to remove the @author tags.
 
 The @author tag is not used in other projects. Neutron removed all
 @author tags some time ago and there are no @author tags e.g. in
 Nova, or Cinder. There are even local hacking checks in Nova, and
 Neutron to not use @author tags.
 
 Christian.
 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUNQZZAAoJEC5aWaUY1u572BEIALXeJDUKp7LLp7Vsw7n3LkhQ
kDjUf/wm0ySNQ8+VLGzaI0BTGhCN4QlrCfdiRXjwI1AYMMcf7DLKGA9pah1hcoEq
xn2uiFce3qGp6KVIbKldVLBfzYTQlDnGBb/uGdrIT3WOyYC6Cj1LNte1AcrNgFLc
x/eDmsQUWp3cvGJReiEW7Gqtmo0DQHswwD70D4NS//nZKSIildeM5ucWpHgtI9k1
PsRNZDHr2Pyg2JRD0eEakW0nt5VICa1vOoCmsOCbVjluwU3XBXgsejHM2fbSeSNp
HnppdogRuZ+30xg9Ij+WbuX5FwMIRc+UTNVektqSkQa582/DcMpMTi/ySLmTH6U=
=33KY
-END PGP SIGNATURE-

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


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