Just to make sure you saw it - here is the manual installation doc to help guide you through what needs to be implemented in a project like this.
https://docs.openstack.org/networking-ovn/latest/install/index.html On Thu, Aug 31, 2017 at 3:39 PM, Aakash Kt <[email protected]> wrote: > Hi James, > Thanks for the reply. This definitely cleared some thing up for me. > I would love to get started on this charm soon, and will be sure to drop > in weekly meeting or ask questions on IRC. > > Cheers, > Aakash > > > On Tue, Aug 29, 2017 at 1:56 PM, James Page <[email protected]> wrote: > >> Hi Aakash >> >> On Tue, 29 Aug 2017 at 05:09 Aakash Kt <[email protected]> wrote: >> >>> Hello all, >>> Resending this mail since I think there might have been some error >>> sending it the last time. >>> >>> I am looking to develop an openstack bundle which uses OVN as the >>> SDN. I have been reading : https://docs.openstack.org/c >>> harm-guide/latest/ >>> I have also read : https://docs.openstack.org/n >>> etworking-ovn/latest/install/index.html >>> >> >> Awesome; we chatted about this on IRC a few times but put off any >> concrete work until OVN 2.8.0 is released (soon). >> >> As far as I understand, this will require me to replace the >>> "neutron-openvswitch" charm in the openstack base bundle. However, I am not >>> able to exactly understand what all I will have to rewrite / replace to >>> make this work. >>> >> >> I think the new charm work is actually three charms (or maybe two) - >> neutron-ovn (replacing neutron-openvswitch alongside nova-compute >> deployments), neutron-api-ovn (providing the API only integration of the >> Neutron API to OVN), and probably an ovn charm for deployment of OVN >> itself, with relations <neutron-api-ovn> <-> <ovn> <-> <neutron-ovn> for >> propagation of configuration in deployments. The ODL charm set is similar >> is high level design (neutron-api-odl, odl-controller, openvswitch-odl). >> >> >>> Specifically, I need to make neutron work only as an API instead of the >>> full blown SDN. Also, in the above doc, its mentioned that we have to run >>> some setup on "controller nodes". How does the term "controller node" map >>> to the charm? >>> >> >> Controller nodes are one option for the charms, however components of the >> controller nodes are deployed inside LXD containers to provide separation >> between services. For example, you can dedicated three physical servers >> and then deploy the nova-cloud-controller, neutron-api, glance, keystone, >> cinder, ceilometer, heat etc.. charms in LXD containers onto those physical >> machines. So in the case of OVN, we'd look to deploy the ovn charm on >> these same physical servers. >> >> Hope that helps explain things a bit; if you want to drop into >> #openstack-charms to ask more questions please do, or you can join one of >> our weekly meetings and we can discuss further. We'd normally start a >> piece of work like this with a spec (http://specs.openstack.org/op >> enstack/charm-specs/); this topic is something we could discuss in a bit >> more detail at the PTG in Denver (I'll add an item to the agenda for the >> charms room). >> >> Cheers >> >> James >> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Russell Bryant
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
