There is documentation available here: http://docs.openstack.org/developer/ironic/deploy/install-guide.html
On Thu, Jun 5, 2014 at 1:25 AM, Jander lu <lhcxx0...@gmail.com> wrote: > Hi, Devvananda > > I searched a lot about the installation of Ironic, but there is little > metarial about this, there is only devstack with > ironic(http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html) > > is there any docs about how to deploy Ironic on production physical node > enviroment? > > thx > > > > 2014-05-30 1:49 GMT+08:00 Devananda van der Veen <devananda....@gmail.com>: >> >> On Wed, May 28, 2014 at 8:14 PM, Jander lu <lhcxx0...@gmail.com> wrote: >>> >>> Hi, guys, I have two confused part in Ironic. >>> >>> >>> >>> (1) if I use nova boot api to launch an physical instance, how does nova >>> boot command differentiate whether VM or physical node provision? From this >>> article, nova bare metal use "PlacementFilter" instead of FilterScheduler.so >>> does Ironic use the same method? >>> (http://www.mirantis.com/blog/baremetal-provisioning-multi-tenancy-placement-control-isolation/) >> >> >> That blog post is now more than three releases old. I would strongly >> encourage you to use Ironic, instead of nova-baremetal, today. To my >> knowledge, that PlacementFilter was not made publicly available. There are >> filters available for the FilterScheduler that work with Ironic. >> >> As I understand it, you should use host aggregates to differentiate the >> nova-compute services configured to use different hypervisor drivers (eg, >> nova.virt.libvirt vs nova.virt.ironic). >> >>> >>> >>> (2)does Ironic only support Flat network? If not, how does Ironic >>> implement tenant isolation in virtual network? say,if one tenant has two >>> vritual network namespace,how does the created bare metal node instance send >>> the dhcp request to the right namespace? >> >> >> Ironic does not yet perform tenant isolation when using the PXE driver, >> and should not be used in an untrusted multitenant environment today. There >> are other issues with untrusted tenants as well (such as firmware exploits) >> that make it generally unsuitable to untrusted multitenancy (though >> specialized hardware platforms may mitigate this). >> >> There have been discussions with Neutron, and work is being started to >> perform physical network isolation, but this is still some ways off. >> >> Regards, >> Devananda >> >> >> _______________________________________________ >> 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