Re: [openstack-dev] [Ironic][Neutron] Integration status

[Haomeng, Wang]

Got the guide I want -
https://github.com/openstack/networking-generic-switch/blob/master/doc/source/dev/dev-quickstart.rst

Thanks


On Mon, Apr 18, 2016 at 10:33 AM, Haomeng, Wang <wanghaom...@gmail.com>
wrote:

> Hi Vasy,
>
> I am interested with this ironic-neutron integration to support VLAN, so
> can you help to share some doc/guide/steps for me, and let me try also?
>
> Thanks
> Haomeng
>
>
>
> On Thu, Mar 31, 2016 at 9:20 PM, Jim Rollenhagen <j...@jimrollenhagen.com>
> wrote:
>
>> On Thu, Mar 31, 2016 at 03:37:53PM +0300, Vasyl Saienko wrote:
>> > Hello Community,
>> >
>> > I'm happy to announce that new experimental job
>> > 'ironic-multitenant-network' is stabilized and working. This job allows
>> to
>> > test Ironic multitenancy patches at the gates with help of
>> > networking-generic-switch [1]. Unfortunately depends-on doesn't work for
>> > python-ironicclient [2] since it is installed from pip. There is
>> workaround
>> > for it [3].
>>
>> This is so awesome. Amazing work here by everyone involved. \o/
>>
>> > The full list of patches is [4].
>> >  I'm kindly asking to review them as Ironic multitenancy is very
>> desirable
>> > feature by Ironic customers in Newton release.
>>
>> +1. I'd love to get this stuff in the ironic tree before the summit, and
>> have the Nova stuff at least ready to land by then.
>>
>> I'll be trying to review this today/tomorrow, hoping others can do the
>> same. :)
>>
>> // jim
>>
>> > [1] https://github.com/openstack/networking-generic-switch
>> > [2] https://review.openstack.org/206144/
>> > [3] https://review.openstack.org/296432/
>> > [4]
>> >
>> https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1526403
>> >
>> > Sincerely,
>> > Vasyl Saienko
>>
>> >
>> __
>> > 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][Neutron] Integration status

[Haomeng, Wang]

Hi Vasy,

I am interested with this ironic-neutron integration to support VLAN, so
can you help to share some doc/guide/steps for me, and let me try also?

Thanks
Haomeng



On Thu, Mar 31, 2016 at 9:20 PM, Jim Rollenhagen 
wrote:

> On Thu, Mar 31, 2016 at 03:37:53PM +0300, Vasyl Saienko wrote:
> > Hello Community,
> >
> > I'm happy to announce that new experimental job
> > 'ironic-multitenant-network' is stabilized and working. This job allows
> to
> > test Ironic multitenancy patches at the gates with help of
> > networking-generic-switch [1]. Unfortunately depends-on doesn't work for
> > python-ironicclient [2] since it is installed from pip. There is
> workaround
> > for it [3].
>
> This is so awesome. Amazing work here by everyone involved. \o/
>
> > The full list of patches is [4].
> >  I'm kindly asking to review them as Ironic multitenancy is very
> desirable
> > feature by Ironic customers in Newton release.
>
> +1. I'd love to get this stuff in the ironic tree before the summit, and
> have the Nova stuff at least ready to land by then.
>
> I'll be trying to review this today/tomorrow, hoping others can do the
> same. :)
>
> // jim
>
> > [1] https://github.com/openstack/networking-generic-switch
> > [2] https://review.openstack.org/206144/
> > [3] https://review.openstack.org/296432/
> > [4]
> >
> https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1526403
> >
> > Sincerely,
> > Vasyl Saienko
>
> >
> __
> > 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

[Haomeng, Wang]

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 <
senthilprab...@gmail.com> 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 ironic.dhcp.neutron   File
> "/usr/lib/python2.7/dist-packages/ironic/dhcp/neutron.py", line 126, in
> update_port_dhcp_opts
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron
> _build_client(token).update_port(port_id, port_req_body)
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron   File
> "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 102,
> in with_params
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron ret =
> self.function(instance, *args, **kwargs)
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron   File
> "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 562,
> in update_port
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron return
> self.put(self.port_path % (port), body=body)
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron   File
> "/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 302,
> in put
> 2016-04-08 16:31:38.690 31893 ERROR ironic.dhcp.neutron
> headers=headers, params=params)
> 2016-04-08 16:31:38.690 

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

[Haomeng, Wang]

+1 from me, and congrats!

On Wed, Apr 6, 2016 at 12:45 AM, 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] Remember to follow RFE process

[Haomeng, Wang]

Thanks Ruby to point this out.

On Thu, Mar 3, 2016 at 3:25 PM, Haomeng, Wang <wanghaom...@gmail.com> wrote:

> Hi Ruby,
>
> Yes, just noticed that RFE is in 'Wishlist' status now, sorry for missing
> the bug status yesterday, so we need to follow the process, and I will help
> to revert the patch and get it back to review again once the REF is
> reviewed.
>
> -- Haomeng
>
>
>
> On Thu, Mar 3, 2016 at 3:07 AM, Ruby Loo <rlooya...@gmail.com> wrote:
>
>> Hi,
>>
>> Ironic'ers, please remember to follow the RFE process; especially the
>> cores.
>>
>> I noticed that a patch [1] got merged yesterday. The patch was associated
>> with an RFE [2] that hadn't been approved yet :-( What caught my eye was
>> that the commit message didn't describe the actual API change so I took a
>> quick look at the (RFE) bug and it wasn't documented there either.
>>
>> As a reminder, the RFE process is documented [3].
>>
>> Spec cores need to try to be more timely wrt specs (I admit, I am
>> guilty). And folks, especially cores, ought to take more care when
>> reviewing. Although I do feel like there are too many things that a
>> reviewer needs to keep in mind.
>>
>> Should we revert the patch [1] for now? (Disclaimer. I haven't looked at
>> the patch itself. But I don't think I should have to, to know what the API
>> change is.)
>>
>> --ruby
>>
>>
>> [1] https://review.openstack.org/#/c/264005/
>> [2] https://bugs.launchpad.net/ironic/+bug/1530626
>> [3]
>> http://docs.openstack.org/developer/ironic/dev/code-contribution-guide.html#adding-new-features
>>
>> __
>> 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] Remember to follow RFE process

[Haomeng, Wang]

Hi Ruby,

Yes, just noticed that RFE is in 'Wishlist' status now, sorry for missing
the bug status yesterday, so we need to follow the process, and I will help
to revert the patch and get it back to review again once the REF is
reviewed.

-- Haomeng



On Thu, Mar 3, 2016 at 3:07 AM, Ruby Loo  wrote:

> Hi,
>
> Ironic'ers, please remember to follow the RFE process; especially the
> cores.
>
> I noticed that a patch [1] got merged yesterday. The patch was associated
> with an RFE [2] that hadn't been approved yet :-( What caught my eye was
> that the commit message didn't describe the actual API change so I took a
> quick look at the (RFE) bug and it wasn't documented there either.
>
> As a reminder, the RFE process is documented [3].
>
> Spec cores need to try to be more timely wrt specs (I admit, I am guilty).
> And folks, especially cores, ought to take more care when reviewing.
> Although I do feel like there are too many things that a reviewer needs to
> keep in mind.
>
> Should we revert the patch [1] for now? (Disclaimer. I haven't looked at
> the patch itself. But I don't think I should have to, to know what the API
> change is.)
>
> --ruby
>
>
> [1] https://review.openstack.org/#/c/264005/
> [2] https://bugs.launchpad.net/ironic/+bug/1530626
> [3]
> http://docs.openstack.org/developer/ironic/dev/code-contribution-guide.html#adding-new-features
>
> __
> 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] [ironic] Picking an official name for a subproject (ironic-inspector in this case)

[Haomeng, Wang]

+1 for baremetal-inspection

On Fri, Dec 4, 2015 at 11:25 PM, Julien Danjou  wrote:

> On Fri, Dec 04 2015, Dmitry Tantsur wrote:
>
> > Do you register all 3 in keystone? What do you use as service types?
>
> Yes: metering, alarming and metric.
>
> --
> Julien Danjou
> # Free Software hacker
> # https://julien.danjou.info
>
> __
> 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

[Haomeng, Wang]

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> 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> 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

[Haomeng, Wang]

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>
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>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> 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>
> 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> 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> 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
>
>
__
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 two new core reviewers

[Haomeng, Wang]

+2 for both, counts! Vladyslav and John.

On Sun, Oct 11, 2015 at 8:53 AM, Chris K  wrote:

> +1 for both so +2 :)
>
> -Chris
>
> On Fri, Oct 9, 2015 at 4:26 PM, Jay Faulkner  wrote:
>
>> +1
>>
>> 
>> From: Jim Rollenhagen 
>> Sent: Thursday, October 8, 2015 2:47 PM
>> To: openstack-dev@lists.openstack.org
>> Subject: [openstack-dev] [ironic] Nominating two new core reviewers
>>
>> Hi all,
>>
>> I've been thinking a lot about Ironic's core reviewer team and how we
>> might
>> make it better.
>>
>> I'd like to grow the team more through trust and mentoring. We should be
>> able to promote someone to core based on a good knowledge of *some* of
>> the code base, and trust them not to +2 things they don't know about. I'd
>> also like to build a culture of mentoring non-cores on how to review, in
>> preparation for adding them to the team. Through these pieces, I'm hoping
>> we can have a few rounds of core additions this cycle.
>>
>> With that said...
>>
>> I'd like to nominate Vladyslav Drok (vdrok) for the core team. His reviews
>> have been super high quality, and the quantity is ever-increasing. He's
>> also started helping out with some smaller efforts (full tempest, for
>> example), and I'd love to see that continue with larger efforts.
>>
>> I'd also like to nominate John Villalovos (jlvillal). John has been
>> reviewing a ton of code and making a real effort to learn everything,
>> and keep track of everything going on in the project.
>>
>> Ironic cores, please reply with your vote; provided feedback is positive,
>> I'd like to make this official next week sometime. Thanks!
>>
>> // 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
>
>
__
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, switching to 2x +2 rule

[Haomeng, Wang]

Congrats Yuiko! +2:)

On Wed, Jul 1, 2015 at 6:09 PM, Yuiko Takada yuikotakada0...@gmail.com
wrote:

 Thanks for all the support!!
 I will do my best to meet the expectations of you.
 Let's make Ironic Inspector better and better together.

 As our core team grows, I'd like us to try to stick with 2x +2 rules. Up
 to now it was mostly Dmitry approves everything rule, now let us make
 sure we have at least 2 +2 on a patch before merging it, unless it's
 critical for release or fixing gate. Don't wait for me to W+1 if you see
 that patch already has 2x +2.

 I'd ask the core team to review all the incoming patches. Once our
 devstack gate is finally working, review will be a lot easier.

 Nice :) +2!


 Best Regards,
 Yuiko Takada


 2015-07-01 17:56 GMT+09:00 Dmitry Tantsur dtant...@redhat.com:

 Hi all!

 Please welcome Yuiko Takada to ironic-inspector-core team. Yuiko has been
 with the team for some time already. She did substantial work on porting
 ironic-inspector to Oslo libraries and on our new devstack gate job.

 Thanks Yuiko, it's a pleasure to work with you.

 As our core team grows, I'd like us to try to stick with 2x +2 rules. Up
 to now it was mostly Dmitry approves everything rule, now let us make
 sure we have at least 2 +2 on a patch before merging it, unless it's
 critical for release or fixing gate. Don't wait for me to W+1 if you see
 that patch already has 2x +2.

 I'd ask the core team to review all the incoming patches. Once our
 devstack gate is finally working, review will be a lot easier.

 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


__
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] [magnum] Proposing Kai Qiang Wu (Kennan) for Core for Magnum

[Haomeng, Wang]

GRATZ, Kai Qiang!

On Sun, Jun 7, 2015 at 7:59 AM, Steven Dake (stdake) std...@cisco.com
wrote:

  Kennan,

  Welcome to the magnum-core team!

  Regards
 -steve


   From: Steven Dake std...@cisco.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Saturday, May 30, 2015 at 10:56 PM
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [magnum] Proposing Kai Qiang Wu (Kennan) for
 Core for Magnum

   Hi core team,

  Kennan (Kai Qiang Wu’s nickname) has really done a nice job in Magnum
 contributions.  I would like to propose Kennan for the core reviewer team.
 I don’t think we necessarily need more core reviewers on Magnum, but Kennan
 has demonstrated a big commitment to Magnum and is a welcome addition in my
 opinion.

  For the lifetime of the project, Kennan has contributed 8% of the
 reviews, and 8% of the commits.  Kennan is also active in IRC.  He meets my
 definition of what a core developer for Magnum should be.

  Consider my proposal to be a +1 vote.

  Please vote +1 to approve or vote –1 to veto.  A single –1 vote acts as
 a veto, meaning Kennan would not be approved for the core team.  I believe
 we require 3 +1 core votes presently, but since our core team is larger now
 then when we started, I’d like to propose at our next team meeting we
 formally define the process by which we accept new cores post this proposal
 for Magnum into the magnum-core group and document it in our wiki.

  I’ll leave voting open for 1 week until June 6th to permit appropriate
 time for the core team to vote.  If there is a unanimous decision or veto
 prior to that date, I’ll close voting and make the appropriate changes in
 gerrit as appropriate.

  Thanks
 -steve


 __
 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][oslo] Stepping down from oslo-ironic liaison

[Haomeng, Wang]

Thank you Ghe! Miss you!

On Wed, May 27, 2015 at 9:04 AM, Tan, Lin lin@intel.com wrote:
 Hi Doug and guys,

 I would like to work as oslo-ironic liasison to sync Ironic with Oslo.
 I will attend the regular Oslo meeting for sure. My IRC name is lintan, and 
 Launchpad id is tan-lin-good

 Thanks

 Tan

 -Original Message-
 From: Doug Hellmann [mailto:d...@doughellmann.com]
 Sent: Tuesday, May 26, 2015 9:17 PM
 To: openstack-dev
 Subject: Re: [openstack-dev] [Ironic][oslo] Stepping down from oslo-ironic 
 liaison

 Excerpts from Ghe Rivero's message of 2015-05-25 09:45:47 -0700:
 My focus on the Ironic project has been decreasing in the last cycles,
 so it's about time to relinquish my position as a oslo-ironic liaison
 so new contributors can take over it and help ironic to be the vibrant
 project it is.

 So long, and thanks for all the fish,

 Ghe Rivero

 Thanks for your help as liaison, Ghe, the Oslo team appreciates your effort!

 Doug

 __
 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] Nominating David Shrewsbury to ironic-core

[Haomeng, Wang]

+1:)

On Sun, Jul 13, 2014 at 2:59 AM, Lucas Alvares Gomes
lucasago...@gmail.com wrote:
 +1 !

 On Fri, Jul 11, 2014 at 11:50 PM, Devananda van der Veen
 devananda@gmail.com wrote:
 Hi all!

 While David (Shrews) only began working on Ironic in earnest four months
 ago, he has been working on some of the tougher problems with our Tempest
 coverage and the Nova-Ironic interactions. He's also become quite active
 in reviews and discussions on IRC, and demonstrated a good understanding of
 the challenges facing Ironic today. I believe he'll also make a great
 addition to the core team.

 Below are his stats for the last 90 days.

 Cheers,
 Devananda

 +--+---++
 | Reviewer | Reviews   -2  -1  +1  +2  +A+/- % |
 Disagreements* |
 +--+---++

 30
 | dshrews  |  470  11  36   0   076.6% |7 (
 14.9%)  |

 60
 | dshrews  |  910  14  77   0   084.6% |   15 (
 16.5%)  |

 90
 | dshrews  | 1210  21 100   0   082.6% |   16 (
 13.2%)  |


 ___
 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] [Ironic] Nominating Jim Rollenhagen to ironic-core

[Haomeng, Wang]

+1:)


On Sun, Jul 13, 2014 at 3:00 AM, Lucas Alvares Gomes
lucasago...@gmail.com wrote:
 +1 !

 On Fri, Jul 11, 2014 at 11:50 PM, Devananda van der Veen
 devananda@gmail.com wrote:
 Hi all!

 It's time to grow the team :)

 Jim (jroll) started working with Ironic at the last mid-cycle, when teeth
 became ironic-python-agent. In the time since then, he's jumped into Ironic
 to help improve the project as a whole. In the last few months, in both
 reviews and discussions on IRC, I have seen him consistently demonstrate a
 solid grasp of Ironic's architecture and its role within OpenStack,
 contribute meaningfully to design discussions, and help many other
 contributors. I think he will be a great addition to the core review team.

 Below are his review stats for Ironic, as calculated by the
 openstack-infra/reviewstats project with local modification to remove
 ironic-python-agent, so we can see his activity in the main project.

 Cheers,
 Devananda

 +--+---++
 | Reviewer | Reviews   -2  -1  +1  +2  +A+/- % |
 Disagreements* |
 +--+---++

 30
 |  jimrollenhagen  |  290   8  21   0   072.4% |5 (
 17.2%)  |

 60
 |  jimrollenhagen  |  760  16  60   0   078.9% |   13 (
 17.1%)  |

 90
 |  jimrollenhagen  | 1060  27  79   0   074.5% |   25 (
 23.6%)  |

 180
 |  jimrollenhagen  | 1570  41 116   0   073.9% |   35 (
 22.3%)  |



 ___
 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] [Ironic][Ceilometer]bp:send-data-to-ceilometer

[Haomeng, Wang]

Hi Wanyen,

Thanks for your input first, I have worked out solution 1 enhanced
version, that is very flexible framework from our Ironic part, will
not change any data returned by 'ipmitool' command and just format
them as JSON string and sent to ceilometer, this should be the final
solution, will implement it with python code in our Ironic.

The solution 1 enhanced version is:

We run the ipmitool command with 'sdr -v' options, so we get details
for each sensor, see the command line and out put as below link:
http://paste.openstack.org/show/63267/

Our Ironic will parse these output to JSON string by 'Sensor Type',
check the JSON string which will be sent to Ceilometer:
http://paste.openstack.org/show/63276/

So from our Ironic part, we will support all sensors which returned
from 'ipmitool sdr -v' command, that is flexible framework I think.
For this my testing case result, we get a lot of below sensor types,
including 'Fan', 'Voltage', 'Temperature' these three common sensors:

['Cable / Interconnect', 'Physical Security', 'System Firmwares',
'Temperature', 'Drive Slot / Bay', 'Battery', 'Unknown (0xC1)',
'Memory', 'Power Supply', 'System Event', 'Module / Board', 'Version
Change', 'Fan', 'Voltage', 'Event Logging Disabled', 'Critical
Interrupt', 'Watchdog', 'Processor', 'Entity Presence']

However, from Ceilometer part, have to define the 'Meter' data model
with these JSON input from our Ironic, so for first version, I think
our Ceilometer will support 'Fan', 'Voltage', 'Temperature' first, and
will check with Ceilometer team guys how to model/map these ipmi
sensor data as ceilometer resource-meter-samples and support more
flexibility to accomodate more sensors like our Ironic:)

Thanks
Haomeng




On Sat, Feb 8, 2014 at 6:20 AM, Hsu, Wan-Yen wan-yen@hp.com wrote:
Haomeng wrote:



Ok, will implement the bp based on the first solution, thanks.





   I believe solution 2 is more flexible and it allows hardware to report
 additional sensors than solution 1.  However, if there is a desire to define
 specific sensor categories as proposed by solution 1,  then please add an
 extra-sensors data structure with key+ value pairs to allow different
 hardware to report additional sensors such as average wattage, critical
 upper temperature threshold,  network, and memory sensors, ...etc.  Thanks!





 Regards,

 Wanyen










 ___
 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] [Ironic][Ceilometer]bp:send-data-to-ceilometer

[Haomeng, Wang]

Hi Wanyen,

Thanks for your input first, I have worked out solution 1 enhanced
version, that is very flexible framework from our Ironic part, will
not change any data returned by 'ipmitool' command and just format
them as JSON string and sent to ceilometer, I think this should be the
final solution, I will implement it with python code in our Ironic.

The solution 1 enhanced version is:

We run the ipmitool command with 'sdr -v' options, so we get details
for each sensor, see the command line and out put as below link:
http://paste.openstack.org/show/63267/

Our Ironic will parse these output to JSON string by 'Sensor Type',
check the JSON string which will be sent to Ceilometer:
http://paste.openstack.org/show/63276/

So from our Ironic part, we will support all sensors which returned
from 'ipmitool sdr -v' command, that is flexible framework I think.
For this my testing case result, we get a lot of below sensor types,
including 'Fan', 'Voltage', 'Temperature' these three common sensors:

['Cable / Interconnect', 'Physical Security', 'System Firmwares',
'Temperature', 'Drive Slot / Bay', 'Battery', 'Unknown (0xC1)',
'Memory', 'Power Supply', 'System Event', 'Module / Board', 'Version
Change', 'Fan', 'Voltage', 'Event Logging Disabled', 'Critical
Interrupt', 'Watchdog', 'Processor', 'Entity Presence']

However, from Ceilometer part, have to define the 'Meter' data model
with these JSON input from our Ironic, so for first version, I think
our Ceilometer will support 'Fan', 'Voltage', 'Temperature' first, and
will check with Ceilometer team guys how to model/map these ipmi
sensor data as ceilometer resource-meter-samples and support more
flexibility to accomodate more sensors like our Ironic:)

Thanks
Haomeng





On Sat, Feb 8, 2014 at 6:20 AM, Hsu, Wan-Yen wan-yen@hp.com wrote:
Haomeng wrote:



Ok, will implement the bp based on the first solution, thanks.





   I believe solution 2 is more flexible and it allows hardware to report
 additional sensors than solution 1.  However, if there is a desire to define
 specific sensor categories as proposed by solution 1,  then please add an
 extra-sensors data structure with key+ value pairs to allow different
 hardware to report additional sensors such as average wattage, critical
 upper temperature threshold,  network, and memory sensors, ...etc.  Thanks!





 Regards,

 Wanyen










 ___
 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] [Ironic] January review redux

[Haomeng, Wang]

+1 for both:)


On Wed, Feb 5, 2014 at 6:08 PM, Yuriy Zveryanskyy
yzveryans...@mirantis.com wrote:
 On 02/04/2014 09:42 PM, Devananda van der Veen wrote:

 So, I'd like to nominate the following two additions to the ironic-core
 team:

 Max Lobur
 https://review.openstack.org/#/q/reviewer:mlobur%2540mirantis.com+project:openstack/ironic,n,z

 Roman Prykhodchenko
 https://review.openstack.org/#/q/reviewer:rprikhodchenko%2540mirantis.com+project:openstack/ironic,n,z


 +1 for both



 ___
 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] [Ironic][Ceilometer]bp:send-data-to-ceilometer

[Haomeng, Wang]

Hi,

I am working on this ironic bp -
https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer,
worked out solutions as below, can you help to review, welcome your
comments:

We will call ipmi command/api to get sensor data(sensor name, sensor
current value, min/max value, status etc) and try to sent to
ceilometer collector via notification bus(call rpc_notifier.notify()
api to send the ipmi data message) with ironic periodic task, I have
two proposed ironic-ceilometer integration solutions about the data to
be sent to ceilometer:

Solution 1 - sent the ipmi data to ceilometer by ipmi sensor category
in specific, the meter names vary clear for ceilometer, that is
pre-defined already:

Common field:
timestamp
publisher_id
message_id
resource-id #the ironic node-uuid

Category:
FanSpeed
Voltage
Temperature

Meter Names:
fanspeed, fanspeed.min, fanspeed.max, fanspeed.status
voltage, voltage.min, voltage.max, voltage.status
temperature, temperature.min, temperature.max, temperature.status

An message example with one ipmi node sensor data:

message = {
'event_type': 'ipmidata',
'timestamp': '2013-12-1706: 12: 11.554607',
'user_id': 'admin',
'publisher_id': 'ipmidata-os26-control01.localdomain',
'message_id:' '3eca2746-9d81-42cd-b0b3-4bdec52e109x',
'tenant_id: 'c1921aa2216846919269a17978408476',
'instance_uuid: '96e11f69-f12a-485e-abfa-526cd04169c4' # nova
instance uuid
'id': '1329998e8183419794507cd6f0cc121a' # node's uuid
'payload': {
'fanspeed': {
'FAN 1': {
'current_value': '4652',
'min_value': '4200',
'max_value': '4693',
'status': 'ok'
}
'FAN 2': {
'current_value': '4322',
'min_value': '4210',
'max_value': '4593',
'status': 'ok'
},
'voltage': {
'Vcore': {
'current_value': '0.81',
'min_value': '0.80',
'max_value': '0.85',
'status': 'ok'
},
'3.3VCC': {
'current_value': '3.36',
'min_value': '3.20',
'max_value': '3.56',
'status': 'ok'
},
...
}
}

Solution 2- sent the ipmi data to ceilometer on the common sensor
meter level, we have one 'sensor' as common meter, so all the sensor
data will have more detail level to define the sensor name and
attributes - current/min/max/status values:

Common field:
timestamp
publisher_id
message_id

Common sensor meter name:
sensor

An message example with one ipmi node sensor data:

message = {
'event_type': 'ipmidata',
'timestamp': '2013-12-1706: 12: 11.554607',
'user_id': 'admin',
'publisher_id': 'ipmidata-os26-control01.localdomain',
'message_id:' '3eca2746-9d81-42cd-b0b3-4bdec52e109x',
'tenant_id: 'c1921aa2216846919269a17978408476',
'instance_uuid: '96e11f69-f12a-485e-abfa-526cd04169c4' # nova
instance uuid
'id': '1329998e8183419794507cd6f0cc121a' # node's uuid
'payload': {
'FAN 1': {
'current_value': '4652',
'min_value': '4200',
'max_value': '4693',
'status': 'ok'
}
'FAN 2': {
'current_value': '4322',
'min_value': '4210',
'max_value': '4593',
'status': 'ok'
},
'Vcore': {
'current_value': '0.81',
'min_value': '0.80',
'max_value': '0.85',
'status': 'ok'
},
'3.3VCC': {
'current_value': '3.36',
'min_value': '3.20',
'max_value': '3.56',
'status': 'ok'
},
...
}
}

And we have existing patch in ceilometer 'Add ipmi inspector' -
https://review.openstack.org/#/c/51828, it is Abandoned, but I think
we should have same patch/bp in ceilometer to handle the ipmi data
message sent out from ironic. Once the solution is confirmed and
finalized, I will work with ceilometer team to do the testing to
verify if our solution working or not.


Thanks
Haomeng

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