From amuller at redhat.com Sun Mar 2 12:53:48 2014 From: amuller at redhat.com (Assaf Muller) Date: Sun, 2 Mar 2014 07:53:48 -0500 (EST) Subject: [Rdo-list] VXLAN support In-Reply-To: <53106087.70409@lip.pt> References: <53106087.70409@lip.pt> Message-ID: <1614690510.11960164.1393764828604.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Guys... > > I would like to send a couple of questions regarding VXLAN support in RDO. > > Let me summary the context: > > 1) The documentation regarding VXLAN is available here: > http://openstack.redhat.com/Using_VXLAN_Tenant_Networks > > 2) The previous link says that VXLAN will be supported in RDO after > solving the following bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1021778 > > 3) The previous bug seems to be already solved in > openstack-packstack-2013.2.1-0.23.dev979.el6ost. > > Now the question: > > I have installed openstack-packstack-2013.2.1-0.29.dev956.el6.noarch > (higher than previous fixed version) so VXLAN should be natively > supported. However I do not find any documentation on how to change the > answers file. There are some recipes where you start by deploying a GRE > configuration and that change manually some items to support VXLAN. > However, if VXLAN is already supported in RDO then it should be > configured directly from the answers file. Is there some documentation > on that topic? > Hi Goncalo, Check out: https://bugzilla.redhat.com/show_bug.cgi?id=1066519#c5 In short, ML2 + VXLAN + Packstack doesn't seem to work off the bat. You can track that bug to see when it's fixed. In the mean while, you can use the original guide you linked (Installing with GRE and moving manually to VXLAN). > TIA > Cheers > Goncalo > > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > From kchamart at redhat.com Mon Mar 3 04:17:05 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Mon, 3 Mar 2014 09:47:05 +0530 Subject: [Rdo-list] Open-Source Software Products Users Contacts Release Q1 In-Reply-To: References: Message-ID: <20140303041705.GA13520@tesla.redhat.com> On Fri, Feb 28, 2014 at 03:44:59PM -0500, Katy Thomas wrote: [. . .] > > > Would you be interested in acquiring our open-source software products users > list with the updated count and verified contacts? The list has been > recently verified in Fourth week of January is ready to use and this > information database can be helpful for your email marketing campaign, > tele-marketing campaign and other marketing campaign initiatives for > unlimited usages. Your email is not relevant at all to this list. Please refrain from sending such emails to community mailing lists. > Could we talk more? No. -- /kashyap From mburns at redhat.com Tue Mar 4 14:56:12 2014 From: mburns at redhat.com (Mike Burns) Date: Tue, 04 Mar 2014 09:56:12 -0500 Subject: [Rdo-list] RDO Weekly Meeting Minutes -- 2014-03-04 Message-ID: <5315E98C.9060309@redhat.com> Minutes: http://meetbot.fedoraproject.org/rdo/2014-03-04/rdo.2014-03-04-13.59.html Minutes (text): http://meetbot.fedoraproject.org/rdo/2014-03-04/rdo.2014-03-04-13.59.txt Log: http://meetbot.fedoraproject.org/rdo/2014-03-04/rdo.2014-03-04-13.59.log.html ======================== #rdo: RDO weekly meeting ======================== Meeting started by mburned at 13:59:30 UTC. The full logs are available at http://meetbot.fedoraproject.org/rdo/2014-03-04/rdo.2014-03-04-13.59.log.html . Meeting summary --------------- * Agenda (mburned, 13:59:34) * LINK: https://etherpad.openstack.org/p/rdo_community_manager_sync (mburned, 13:59:47) * Test Day (mburned, 14:00:29) * set for March 19-20 (mburned, 14:00:43) * LINK: https://fedoraproject.org/wiki/Test_Day:2014-03-19_RDO (mburned, 14:01:10) * LINK: https://fedoraproject.org/wiki/Test_Day:2014-03-19_RDOMetadata (mburned, 14:01:30) * based on OpenStack IceHouse M3 (mburned, 14:01:49) * M3 is March 6 (mburned, 14:02:15) * Feature Freeze for IceHouse is today (March 4) (mburned, 14:02:34) * those links to the wiki page for general info and metadata page which the Fedora Test Day app uses to create test forms (mburned, 14:03:04) * need to import current list of tests to metadata page (mburned, 14:03:29) * LINK: http://testdays.qa.fedoraproject.org/testdays/show_event?event_id=16 (kashyap, 14:03:33) * rbowen working on correcting/updating the information (mburned, 14:03:58) * LINK: https://wiki.openstack.org/wiki/Icehouse_Release_Schedule (mburned, 14:05:53) * ACTION: rbowen to ask for help updating test info once existing stuff is added (mburned, 14:06:37) * pixelb confirms packages for M3 should be ready for March 19 Test Day (mburned, 14:09:14) * Hangouts (mburned, 14:10:01) * Test Day (revisited) (mburned, 14:10:39) * pixelb would like additional coverage of marconi and savanna (mburned, 14:12:11) * marconi basic tests already linked on the RDO wiki (mburned, 14:12:38) * savanna basic tests already linked on the RDO wiki (pixelb, 14:13:06) * savanna basic tests already linked on the RDO wiki (mburned, 14:13:42) * hope to have marconi packaged for test day (mburned, 14:13:46) * would also be good to have testing for the OFI stuff, but unclear if that will be ready in time (mburned, 14:14:39) * Hangouts (mburned, 14:15:20) * LINK: http://openstack.redhat.com/Hangouts (mburned, 14:15:27) * larsks did a hangout on the 27th (mburned, 14:15:45) * LINK: https://plus.google.com/events/cm9ff549vmsim737lj7hopk4gao (mburned, 14:16:08) * ~30 people watched live (mburned, 14:16:17) * Flavio Percoco will give a hangout on Marconi March 27, 10am EST (rbowen, 14:17:34) * LINK: https://plus.google.com/events/ckjhm8rggnqvrnspftna845kubk (rbowen, 14:17:46) * rbowen has learned a lot about scheduling Hangouts and organizing them ahead of time which will improve statistics and organizing all hangouts afterwards (mburned, 14:19:14) * also, we will investigate hosting the recordings on the rdo site as well (mburned, 14:20:06) * to enable offline viewing (mburned, 14:20:43) * if you're interested in hosting a Hangout, please get in touch with rbowen or check out the hangouts etherpad (mburned, 14:21:56) * LINK: https://etherpad.openstack.org/p/rdo_hangouts (mburned, 14:21:58) * Newsletter (mburned, 14:23:16) * March Newsletter to go out today (mburned, 14:24:12) * looking for topics for April Newsletter now (mburned, 14:24:29) * LINK: https://etherpad.openstack.org/p/rdo_apr_2014_newsletter (mburned, 14:24:38) * focus of April's newsletter will likely be on OpenStack Summit (mburned, 14:25:02) * please let rbowen know if you have topics (mburned, 14:25:21) * Events (mburned, 14:26:29) * we're not scheduled to be at anything in March (mburned, 14:26:46) * in April, the only really relevant conference is Red Hat Summit (mburned, 14:27:16) * numerous demos planned around OpenStack (primarily RHELOSP, I think) (mburned, 14:27:44) * there is supposed to be an RDO booth as well (mburned, 14:28:19) * 6 different demos planned for the RDO booth (mburned, 14:29:28) * more details to follow (mburned, 14:29:35) * Openstack Summit takes place in May (12-16) (mburned, 14:30:49) * we will have a booth with demo screen (mburned, 14:31:20) * schedule of talks are still being finalized (mburned, 14:31:41) * currently no plans to be at FISL (week before Openstack Summit) (mburned, 14:35:02) * LinuxCon Japan (May 20-22) is a possibility for an RDO booth, but not decided yet (mburned, 14:35:34) * if you know of any local meetups/hangouts/local conferences, please mention on the rdo mailing list (mburned, 14:39:39) * Bug Triage/CentOS Cloud SIG (mburned, 14:41:57) * not much new here, SIG is quiet (mburned, 14:42:14) * bug triage happening consistently, but we're between meetings at the moment (mburned, 14:42:28) * Forum (mburned, 14:42:49) * we're at 47 unanswered this morning (mburned, 14:43:31) * ACTION: need to get abandoned ones closed (mburned, 14:46:01) * rbowen and larsks will work on closing the abandoned posts (mburned, 14:47:04) * ACTION: rbowen to start wiki page of "subject matter experts" who are willing to have ask.openstack.org questions assigned to them. (rbowen, 14:50:02) * and only list IRC nicks there to minimize spam for the SMEs (mburned, 14:50:38) * Other Topics (mburned, 14:52:58) Meeting ended at 14:54:12 UTC. Action Items ------------ * rbowen to ask for help updating test info once existing stuff is added * need to get abandoned ones closed * rbowen to start wiki page of "subject matter experts" who are willing to have ask.openstack.org questions assigned to them. Action Items, by person ----------------------- * rbowen * rbowen to ask for help updating test info once existing stuff is added * rbowen to start wiki page of "subject matter experts" who are willing to have ask.openstack.org questions assigned to them. * **UNASSIGNED** * need to get abandoned ones closed People Present (lines said) --------------------------- * mburned (106) * rbowen (85) * kashyap (24) * larsks (9) * pixelb (7) * DV (5) * zodbot (4) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From rbowen at redhat.com Tue Mar 4 14:57:43 2014 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 04 Mar 2014 09:57:43 -0500 Subject: [Rdo-list] [Rdo-newsletter] RDO Newsletter: March 2014 Message-ID: <5315E9E7.5090603@redhat.com> Hi again, and thanks for being part of the RDO community. We've got a number of events coming up, and various ways you can get involved in the RDO project, as well as the upstream OpenStack community, but first, a little bit about what's happened since the last time I wrote. February events Last week, Lars Kellogg-Stedman hosted a Google Hangout in which he talked about standing up a multi-node OpenStack installation using RDO and Packstack. You can watch that presentation at https://plus.google.com/events/cm9ff549vmsim737lj7hopk4gao and the slides from the presentation, including cut-and-paste command lines to reproduce the setup yourself, can be found at http://goo.gl/Yvmd0P Other past RDO hangouts can be seen at http://openstack.redhat.com/Hangouts along with announcements of upcoming ones. When last I wrote, I was in Belgium attending FOSDEM. That event was fantastic, and a little overwhelming, with over 5000 Free/Libre/OpenSource Software enthusiasts descending on the University of Brussels to celebrate and learn about various software projects and the issues surrounding them. While there, I interviewed Ohad Levy, who works on deploying OpenStack with The Foreman, about his work. Unfortunately, I managed to turn off the recorder before we started talking, and I have nothing to show for it. We'll be having that conversation again over the phone in the coming days, and I'll publish that on the RDO website. Additionally, I attended Configuration Management Camp - http://cfgmgmtcamp.eu/ - and Infrastructure.next - http://lanyrd.com/2014/infranext/ - in Ghent, which focused on issues that are important to us in the OpenStack world - configuration management, automation, and monitoring. Last weekend, RDO had a table at SCaLE - the Southern California Linux Expo - http://www.socallinuxexpo.org/blog/scale-12x - where we had steady traffic through the whole event, with people telling us how much they love RDO, and other folks asking a lot of great questions about OpenStack, and where it fits into the larger cloud ecosystem, including projects like oVirt and OpenShift, who were our neighbors in our booth. Upcoming events We are planning our next RDO Test Days on March 19th and 20th. We'll be testing the third Icehouse milestone in preparation for the final release of Icehouse on April 17th. You can find more about the test day, and sign up to participate, at http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_3 We'll be hosting another Google Hangout on Thursday, March 27th. Flavio Percoco will be telling us about the Marconi project - https://wiki.openstack.org/wiki/Marconi - what it is, what the plans are for the coming releases, and how you can get involved in the development of this new piece of OpenStack infrastructure. That event will be streamed live (and available recorded afterwards) at https://plus.google.com/events/ckjhm8rggnqvrnspftna845kubk and you can add it to your calendar there to get a reminder closer to the event. Finally, don't forget that the OpenStack Summit is just around the corner - May 12-16th in Atlanta, Georgia, USA. The vote has just closed for what sessions will be presented there - many thanks to those of you who voted - and now the selection process starts, with track chairs putting together the schedule from the sessions that did well in that process. We should see the schedule published in the coming month, and then it's off to Atlanta. We hope to see you there. Red Hat will have a booth there, featuring demos of RDO as well as our commercial OpenStack offering. We'd love to see you there - get your tickets early to take advantage of the early bird rates. Stats It's always fun to look at the statistics around OpenStack. They shift so quickly, even from hour to hour, and it's exciting to watch the progress of the project by the numbers. One great place to find statistics is the Stackalytics site - http://www.stackalytics.com/ - where you can watch contributions by company, by module, by release, or by individual contributor. Something I find particularly interesting, as a writer, is that the second most active module within the ecosystem is the openstack-manuals project. 7% of contributions are to the documentation, second only to nova. For RDO-specific statistics, we have http://openstack.redhat.com/stats/ which was put together by Bitergia, the same company that does the Stackalytics site. Here you can track who's involved in the wiki, the mailing lists, and the development of the code. Get Involved As always, a few reminders of how you can get involved in the RDO project. The wiki, at http://openstack.redhat.com/Docs , is one of the best ways you can share your experience with the rest of the RDO community. Articles about getting various scenarios working, corrections or addenda to existing articles, or suggestions for articles that you'd like to see written, are all a great help to people trying to run OpenStack. If you have questions, or if you want to help answer other people's questions, go to http://ask.openstack.org/ where there are questions from all over the OpenStack community - not just RDO users - and answers from experts on a variety of aspects of OpenStack. This is the best place to ask your questions, or to find other people who have already asked your question and received answers and advice. If mailing lists are more to your liking, the rdo-list mailing list is the place to ask your questions and help other folks out with theirs. You can sign up for the list, or make alterations to your subscription, at http://www.redhat.com/mailman/listinfo/rdo-list And finally, you can adjust your subscription to this newsletter, or invite your colleagues, at http://www.redhat.com/mailman/listinfo/rdo-newsletter Thanks again for being part of the RDO community. We look forward to seeing your contributions. -- Rich Bowen, for the RDO community rbowen at redhat.com http://openstack.redhat.com/ @rdocommunity _______________________________________________ Rdo-newsletter mailing list Rdo-newsletter at redhat.com https://www.redhat.com/mailman/listinfo/rdo-newsletter From pchalupa at redhat.com Tue Mar 4 15:10:06 2014 From: pchalupa at redhat.com (Petr Chalupa) Date: Tue, 04 Mar 2014 16:10:06 +0100 Subject: [Rdo-list] [OFI] Orchestration <-> Wizard Integration Message-ID: <5315ECCE.5000003@redhat.com> Hello guys, I would like to start discussion about how the integration of Orchestration and Wizard will look like. The parts are: 1. Collecting the configuration of OS (OpenStack) infrastructure 2. Configuring Foreman's HostGroups and other stuff based on that configuration 3. Orchestrate the provisioning of the whole OS infrastructure in the right order using configured HostGroups and Dynflow. I am thinking that 1. and 2. will be part of the Wizard and 3. will be the orchestration's job. I am assuming that 2. is ?simple function using seed data and user-provided configuration that creates configured HostGroups. Meaning it does not need any of the workflow engine stuff that Dynflow provides. If so then developing these in parallel and connecting them later should be quite easy. I and Martyn can simulate the OS infrastructure provisioning with blank hosts for now. Petr From sgordon at redhat.com Tue Mar 4 17:20:45 2014 From: sgordon at redhat.com (Steve Gordon) Date: Tue, 4 Mar 2014 12:20:45 -0500 (EST) Subject: [Rdo-list] [Neutron] Fwd: Icehouse with Neutron and ML2 on RHEL In-Reply-To: References: <6F92F704-41E4-436D-8884-F47A015E7401@rackspace.com> <776F9832-AFB6-438F-AD85-748005CB473D@rackspace.com> Message-ID: <1575789333.26368109.1393953645344.JavaMail.zimbra@redhat.com> Hi all, I got some feedback about some issues with Icehouse RDO packages, specifically the Neutron ones and the way they handle (or don't handle) the database. Are these issues we are aware of/tracking? Matt is using the EL6 builds at the moment. We are hanging out in #openstack-docs on Freenode if you need any more info from Matt (Sam-I-Am on IRC). Thanks, Steve ----- Forwarded Message ----- > FYI... > > ---------- Forwarded message ---------- > From: Phil Hopkins > Date: Sat, Mar 1, 2014 at 8:13 PM > Subject: Re: Icehouse with Neutron and ML2 on RHEL > To: Matt Kassawara > Cc: Carl Perry , Edgar Magana , > Nick Chase > > > Very interesting, something is broke bad there. There should be a new > build of the packages this week. Lets hope that fixes this.problem. > > Phil > > Sent from my iPhone > > On Mar 1, 2014, at 8:29 PM, "Matt Kassawara" wrote: > > The following tables appear after starting neutron-server with a fresh > database: > > mysql> show tables; > +---------------------+ > | Tables_in_neutron | > +---------------------+ > | agents | > | ml2_gre_allocations | > | ml2_gre_endpoints | > | networks | > | quotas | > | securitygroups | > +---------------------+ > 6 rows in set (0.00 sec) > > The log shows plenty of errors regarding missing database information. I'm > particularly curious about this one: > > 2014-03-01 18:58:55.133 2877 INFO neutron.db.api [-] Database registration > exception: (OperationalError) (1005, "Can't create table > 'neutron.networkdhcpagentbindings' (errno: 150)") '\nCREATE TABLE > networkdhcpagentbindings (\n\tnetwork_id VARCHAR(36) NOT NULL, > \n\tdhcp_agent_id VARCHAR(36) NOT NULL, \n\tPRIMARY KEY (network_id, > dhcp_agent_id), \n\tFOREIGN KEY(network_id) REFERENCES networks (id) ON > DELETE CASCADE, \n\tFOREIGN KEY(dhcp_agent_id) REFERENCES agents (id) ON > DELETE CASCADE\n)ENGINE=InnoDB\n\n' () > > Interestingly, trying this SQL command manually also fails: > > mysql> create table networkdhcpagentbindings (network_id varchar(36) not > null, dhcp_agent_id varchar(36) not null, primary key (network_id, > dhcp_agent_id), foreign key(network_id) references networks (id) on delete > cascade, foreign key(dhcp_agent_id) references agents (id) on delete > cascade ) engine=InnoDB; > ERROR 1005 (HY000): Can't create table 'neutron.networkdhcpagentbindings' > (errno: 150) > > However, it works without "engine=InnoDB" appended at the end which leads > me to some sort of referential integrity problem... or I'm mistyping > something. :) > > mysql> show engine innodb status; > LATEST FOREIGN KEY ERROR > ------------------------ > 140301 19:24:40 Error in foreign key constraint of table > neutron/networkdhcpagentbindings: > foreign key(dhcp_agent_id) references agents (id) on delete cascade) > engine=InnoDB: > Cannot resolve table name close to: > (id) on delete cascade) engine=InnoDB > > In comparison, here's the neutron database tables from my functional > Ubuntu installation: > > mysql> show tables; > +---------------------------+ > | Tables_in_neutron | > +---------------------------+ > | agents | > | allowedaddresspairs | > | dnsnameservers | > | externalnetworks | > | extradhcpopts | > | floatingips | > | ipallocationpools | > | ipallocations | > | ipavailabilityranges | > | ml2_gre_allocations | > | ml2_gre_endpoints | > | ml2_network_segments | > | ml2_port_bindings | > | networkdhcpagentbindings | > | networks | > | ports | > | quotas | > | routerl3agentbindings | > | routerroutes | > | routers | > | securitygroupportbindings | > | securitygrouprules | > | securitygroups | > | subnetroutes | > | subnets | > +---------------------------+ > 25 rows in set (0.00 sec) > > > > On Sat, Mar 1, 2014 at 6:46 PM, Phil Hopkins > wrote: > > > I was thinking nova not neutron. Try dropping the neutron database, > > recreate it and restart the neutron-server service. > > > > That should rebuild the tables. Check and see if they are created. If so > > then see if the error reoccurs. > > > > Also see if any errors show up when the neutron-server service is > > restarted. Maybe it is having trouble creating the database tables. > > > > Phil > > > > Sent from my iPhone > > > > On Mar 1, 2014, at 7:00 PM, "Matt Kassawara" wrote: > > > > I did that a few times. Unlike the other similar utilities, > > neutron-db-manage doesn't offer a "sync" command. > > > > > > On Sat, Mar 1, 2014 at 5:52 PM, Phil Hopkins > > wrote: > > > >> You might try rerunning the db sync to ensure the database tables are > >> built correctly. > >> > >> Phil > >> > >> Sent from my iPhone > >> > >> On Mar 1, 2014, at 6:21 PM, "Matt Kassawara" > >> wrote: > >> > >> Fresh. > >> > >> > >> On Sat, Mar 1, 2014 at 5:19 PM, Phil Hopkins > >> wrote: > >> > >>> Was this a fresh install or an upgrade? > >>> > >>> Phil > >>> > >>> Sent from my iPhone > >>> > >>> On Mar 1, 2014, at 5:04 PM, "Matt Kassawara" > >>> wrote: > >>> > >>> If you thought getting Icehouse with Neutron/ML2 working on Ubuntu > >>> took some effort, the RHEL situation appears much worse. All of the > >>> Neutron > >>> daemons spew database errors about missing tables and/or inability to > >>> create them. > >>> > >>> For example: > >>> > >>> [root at hst-osctl8 neutron]# neutron net-list > >>> Request Failed: internal server error while processing your request. > >>> > >>> From the server log... > >>> > >>> 2014-03-01 15:37:07.970 2584 INFO urllib3.connectionpool [-] Starting > >>> new HTTP connection (1): hst-osctl8 > >>> 2014-03-01 15:37:08.133 2584 ERROR neutron.api.v2.resource > >>> [req-9ec4eec0-bf1b-4720-af03-fbdba6a03c14 None] index failed > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource Traceback > >>> (most recent call last): > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File > >>> "/usr/lib/python2.6/site-packages/neutron/api/v2/resource.py", line 84, > >>> in > >>> resource > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource result = > >>> method(request=request, **args) > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File > >>> "/usr/lib/python2.6/site-packages/neutron/api/v2/base.py", line 279, in > >>> index > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource return > >>> self._items(request, True, parent_id) > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File > >>> "/usr/lib/python2.6/site-packages/neutron/api/v2/base.py", line 233, in > >>> _items > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource obj_list > >>> = obj_getter(request.context, **kwargs) > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File > >>> "/usr/lib/python2.6/site-packages/neutron/plugins/ml2/plugin.py", line > >>> 367, > >>> in get_networks > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource limit, > >>> marker, page_reverse) > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File > >>> "/usr/lib/python2.6/site-packages/neutron/db/db_base_plugin_v2.py", line > >>> 1029, in get_networks > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource > >>> page_reverse=page_reverse) > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File > >>> "/usr/lib/python2.6/site-packages/neutron/db/db_base_plugin_v2.py", line > >>> 196, in _get_collection > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource items = > >>> [dict_func(c, fields) for c in query] > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File > >>> "/usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py", > >>> line 2227, in __iter__ > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource return > >>> self._execute_and_instances(context) > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File > >>> "/usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py", > >>> line 2242, in _execute_and_instances > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource result = > >>> conn.execute(querycontext.statement, self._params) > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File > >>> "/usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py", > >>> line 1449, in execute > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource params) > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File > >>> "/usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py", > >>> line 1584, in _execute_clauseelement > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource > >>> compiled_sql, distilled_params > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File > >>> "/usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py", > >>> line 1698, in _execute_context > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource context) > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File > >>> "/usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py", > >>> line 1691, in _execute_context > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource context) > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File > >>> "/usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/engine/default.py", > >>> line 331, in do_execute > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource > >>> cursor.execute(statement, parameters) > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File > >>> "/usr/lib64/python2.6/site-packages/MySQLdb/cursors.py", line 173, in > >>> execute > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource > >>> self.errorhandler(self, exc, value) > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource File > >>> "/usr/lib64/python2.6/site-packages/MySQLdb/connections.py", line 36, in > >>> defaulterrorhandler > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource raise > >>> errorclass, errorvalue > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource > >>> ProgrammingError: (ProgrammingError) (1146, "Table > >>> 'neutron.externalnetworks' doesn't exist") 'SELECT networks.tenant_id AS > >>> networks_tenant_id, networks.id AS networks_id, networks.name AS > >>> networks_name, networks.status AS networks_status, > >>> networks.admin_state_up > >>> AS networks_admin_state_up, networks.shared AS networks_shared, > >>> externalnetworks_1.network_id AS externalnetworks_1_network_id \nFROM > >>> networks LEFT OUTER JOIN externalnetworks ON networks.id = > >>> externalnetworks.network_id LEFT OUTER JOIN externalnetworks AS > >>> externalnetworks_1 ON networks.id = externalnetworks_1.network_id' () > >>> 2014-03-01 15:37:08.133 2584 TRACE neutron.api.v2.resource > >>> > >>> Although I haven't needed to use it before, I poked around at various > >>> permutations of neutron-db-manage, all of which failed with various SQL > >>> errors. I also dissected the functional neutron-server package on Ubuntu > >>> and found no post-installation script calls to neutron-db-manage. On a > >>> related note, Steve Gordon told me that RH should release icehouse-3 > >>> packages this week which might address this issue. > >>> > >>> > >> > > > -- Steve Gordon, RHCE Product Manager, Red Hat Enterprise Linux OpenStack Platform Red Hat Canada (Toronto, Ontario) From rdo-info at redhat.com Tue Mar 4 18:28:07 2014 From: rdo-info at redhat.com (RDO Forum) Date: Tue, 4 Mar 2014 18:28:07 +0000 Subject: [Rdo-list] [RDO] RDO March Newsletter Message-ID: <000001448e5a5183-15ad5739-1e4a-4bf6-85a4-0cf0a0d9726c-000000@email.amazonses.com> rbowen started a discussion. RDO March Newsletter --- Follow the link below to check it out: http://openstack.redhat.com/forum/discussion/968/rdo-march-newsletter Have a great day! From pbrady at redhat.com Tue Mar 4 18:28:39 2014 From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Tue, 04 Mar 2014 18:28:39 +0000 Subject: [Rdo-list] [package announce] Icehouse-b2 EL7 packages Message-ID: <53161B57.8080402@redhat.com> The RDO Icehouse repositories have been updated to include the EL7 package set. To install please follow the standard packstack quick start procedure, on an EL7 based system: http://openstack.redhat.com/QuickStartDevelRelease Release notes: ceilometer Install often doesn't complete due to http://bugzilla.redhat.com/1066408 "mongodb service init returns OK even if service is not operational yet" Workaround is to rerun packstack with the --answer-file=... option cinder Version is icehouse milestone 1 due to missing dependencies from python-taskflow need by milestone 2. This will be updated over the next few days nagios Nagios support is not installed as currently nagios-plugins aren't available in epel7, as due to be replaced with: monitoring-plugins: https://bugzilla.redhat.com/1059281 openstack-swift-account SELinux is preventing this service from binding to a port https://bugzilla.redhat.com/1004881 From lhh at redhat.com Tue Mar 4 21:09:20 2014 From: lhh at redhat.com (Lon Hohberger) Date: Tue, 04 Mar 2014 16:09:20 -0500 Subject: [Rdo-list] [package announce] Icehouse-b2 EL7 packages In-Reply-To: <53161B57.8080402@redhat.com> References: <53161B57.8080402@redhat.com> Message-ID: <53164100.4040502@redhat.com> On 03/04/2014 01:28 PM, P?draig Brady wrote: > The RDO Icehouse repositories have been updated to include the EL7 package set. Awesome news, P?draig! /me trots off to install On SELinux - I recommend to people who want to test this release to run with it in permissive mode and contribute AVCs in the form of bugzillas[1]: - turn selinux in to permissive mode (setenforce 0) - file bugzillas with audit trails for separate services (if possible) against openstack-selinux in RDO bugzilla Note that we use openstack-selinux as a catch-all for testing, but many bugzillas will be moved to selinux-policy in EL7. -- Lon 1. http://openstack.redhat.com/SELinux_issues From shake.chen at gmail.com Wed Mar 5 05:57:24 2014 From: shake.chen at gmail.com (Shake Chen) Date: Wed, 5 Mar 2014 13:57:24 +0800 Subject: [Rdo-list] Bug for multinode deploy with packstack In-Reply-To: <20140227134755.GB7658@redhat.com> References: <20140227053343.GB25995@tesla.redhat.com> <20140227134755.GB7658@redhat.com> Message-ID: Hi Lars I watch your mutil node video careful , use packstack run again and find the problem. I think is bug for RDO the video ip is control 10.15.0.7 network 10.15.0.5 compute 10.15.0.2,10.15.0.4 when Lars login network node (10.15.0.5) show the iptables rules, (the pic is come from Lar video.) [image: Inline image 1] have 3 iptabes rules. I think the last rule -A INPUT -s 10.15.0.5/32 show change to -A INPUT -s 10.15.0.7/32 otherwise, I can not login Dashboard. show can not connect to neutron. On Thu, Feb 27, 2014 at 9:47 PM, Lars Kellogg-Stedman wrote: > On Thu, Feb 27, 2014 at 05:06:49PM +0800, Shake Chen wrote: > > I have found many bug about mutinode setup and try to report it. > > Note that at 10AM Eastern *today* (2/27), I'll be giving an RDO > hangout on multinode installs with packstack. Details are here: > > http://openstack.redhat.com/Hangouts > > I'll be running through a complete install, including a number of > post-install configuration steps. > > Cheers, > > -- > Lars Kellogg-Stedman | larsks @ irc > Cloud Engineering / OpenStack | " " @ twitter > > -- Shake Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Snap1.png Type: image/png Size: 428966 bytes Desc: not available URL: From jtomasek at redhat.com Wed Mar 5 13:59:00 2014 From: jtomasek at redhat.com (Jiri Tomasek) Date: Wed, 05 Mar 2014 14:59:00 +0100 Subject: [Rdo-list] [OFI] Orchestration <-> Wizard Integration In-Reply-To: <5315ECCE.5000003@redhat.com> References: <5315ECCE.5000003@redhat.com> Message-ID: <53172DA4.8030504@redhat.com> On 03/04/2014 04:10 PM, Petr Chalupa wrote: > Hello guys, > > I would like to start discussion about how the integration of > Orchestration and Wizard will look like. > > The parts are: > 1. Collecting the configuration of OS (OpenStack) infrastructure > 2. Configuring Foreman's HostGroups and other stuff based on that > configuration > 3. Orchestrate the provisioning of the whole OS infrastructure in the > right order using configured HostGroups and Dynflow. > > I am thinking that 1. and 2. will be part of the Wizard and 3. will be > the orchestration's job. > > I am assuming that 2. is ?simple function using seed data and > user-provided configuration that creates configured HostGroups. > Meaning it does not need any of the workflow engine stuff that Dynflow > provides. > > If so then developing these in parallel and connecting them later > should be quite easy. I and Martyn can simulate the OS infrastructure > provisioning with blank hosts for now. > > Petr > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list Hey, Regarding the wizard, I have been looking around for rails solutions and Wicked gem [1] seems like something we could use for steps 1 and 2. As you said, we basically need form with several steps that gets validated and submitted. I am not sure if Foreman already uses some kind of wizard which we might use instead of Wicked. Please let me know if there is something like that. [1] http://railscasts.com/episodes/346-wizard-forms-with-wicked?view=asciicast Jirka From hbrock at redhat.com Wed Mar 5 14:58:29 2014 From: hbrock at redhat.com (Hugh O. Brock) Date: Wed, 5 Mar 2014 09:58:29 -0500 Subject: [Rdo-list] [OFI] Orchestration <-> Wizard Integration In-Reply-To: <5315ECCE.5000003@redhat.com> References: <5315ECCE.5000003@redhat.com> Message-ID: <20140305145828.GA3873@redhat.com> On Tue, Mar 04, 2014 at 04:10:06PM +0100, Petr Chalupa wrote: > Hello guys, > > I would like to start discussion about how the integration of > Orchestration and Wizard will look like. > > The parts are: > 1. Collecting the configuration of OS (OpenStack) infrastructure > 2. Configuring Foreman's HostGroups and other stuff based on that > configuration > 3. Orchestrate the provisioning of the whole OS infrastructure in > the right order using configured HostGroups and Dynflow. > > I am thinking that 1. and 2. will be part of the Wizard and 3. will > be the orchestration's job. > > I am assuming that 2. is ?simple function using seed data and > user-provided configuration that creates configured HostGroups. > Meaning it does not need any of the workflow engine stuff that > Dynflow provides. > > If so then developing these in parallel and connecting them later > should be quite easy. I and Martyn can simulate the OS > infrastructure provisioning with blank hosts for now. Hi Petr. Yes, you are absolutely correct on this. There won't actually be any interaction between the staypuft plugin and the workflow until the user pushes the "deploy" button. So we should be able to develop in parallel with no problem. --H -- == Hugh Brock, hbrock at redhat.com == == Senior Engineering Manager, Cloud Engineering == == Tuskar: Elastic Scaling for OpenStack == == http://github.com/tuskar == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From daniel at speichert.pl Wed Mar 5 14:59:42 2014 From: daniel at speichert.pl (Daniel Speichert) Date: Wed, 05 Mar 2014 09:59:42 -0500 Subject: [Rdo-list] Question about Neutron Security Groups Message-ID: <53173BDE.1030207@speichert.pl> Hello, I have a problem with Neutron security groups and I hoped you could provide some ideas. I have two different cloud installation based on OpenStack Havana, they both use Neutron setup with multiple tenants and routers. First cloud is based on Ubuntu and has both Neutron and Nova security groups enabled (a mistake in configuraiton, I did not add "firewall_driver=nova.virt.firewall.NoopFirewallDriver" to nova.conf. On its compute nodes it has neutron-openvswitch-* iptables chains and nova-instance* chains. Rules from all of these chains seem to get hits and security groups work properly. This cloud uses GRE tunnels. Second cloud is based on CentOS 6.5 with RDO. It has the same Neutron setup and nova security groups disabled and "security_group_api=neutron". It does not have iptables chains nova-instance* but neutron chains are properly applied. None of these chains get any hits at all and all traffic to instances is allowed. This cloud used VXLANs but I switched to GRE which did not help. On both clouds there are no additional iptables rules besides the ones generated by OpenStack - I flushed all the rules and chains and forced sync by adding a security group rule. Do you have any idea why security groups don't work, i.e. the chains don't get traffic? It seems to me that the rules in chains neutron-openvswi-FORWARD and neutron-openvswi-INPUT don't get any hits at all on my second cloud installation. -- Best Regards, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hbrock at redhat.com Wed Mar 5 15:15:10 2014 From: hbrock at redhat.com (Hugh O. Brock) Date: Wed, 5 Mar 2014 10:15:10 -0500 Subject: [Rdo-list] [rhos-dev] [OFI] Wireframes and UI related question In-Reply-To: References: <4091091.87xDjMmrtM@edna> <3063984.qFYDqimYqG@edna> Message-ID: <20140305151510.GB3873@redhat.com> On Wed, Mar 05, 2014 at 09:50:31AM -0500, Liz Blanchard wrote: > > On Mar 5, 2014, at 5:47 AM, Marek Hulan wrote: > > > On Wednesday 05 of March 2014 10:59:53 Marek Hulan wrote: > >> Hello, > > Hi Marek, > > Great questions. I will do my best to answer them. Thanks for jumping in Liz -- more below. Taking this to rdo-list and foreman-dev... > >> I have a few questions regarding latest wireframes I found here [1]. I think > >> page 6 describes assignment of various services to hostgroups which would > >> allow user to define custom layout. Is that page intended for post-April > >> work? Is the selection of Deployment layout on page 5 only layout > >> configuration we'll support for April drop? > > Right. We decided to only allow the user to select to add optional services to host groups for this first release. This is the only thing that they can customize with respect to host groups for April. > > Hugh - Would you confirm this? Should we instead just tell the user which services will be included for each host group (including optional ones)? In fact, I would suggest we allow *no* customization of the services-per-hostgroups for April, unless it turns out to be INCREDIBLY EASY. We are targeting two tightly defined reference architectures (distributed 3-node, and distributed-plus-HA 5+-node) for which the services will be predefined. I think we need to limit the April offering to that and plan to add limited service-per-node configuration for June. > >> > >> Looking at page 7 and 8, do we want to display all possible configuration > >> options (class parameters) of a given service (puppet module) to user? Or > >> should we display just most important (probably the case) and leave rest > >> hidden or even under some "advanced" link? > > The goal of the wizard is just to display the important parameters to the user. This way they can quickly get through the wizard and have an OpenStack environment up and running. Later, they could go into the settings and update any parameter that they need to. We may need to pull in more settings than those shown in the wireframes if we identify others that are crucial for first time set-up. Also, the goal is to have smart defaults for all of these parameters so that the user would be able to just click through if they don?t want to change anything and the deployment would kick off. Yeah, absolutely right Liz. It's an important UX exercise to get the right set of parameters in the UI, and a further coding exercise to set the rest via hidden defaults. We *don't* want to allow configuration of every conceivable value right now. > >> > >> Last but not least, if we have parameters which values are limited by some > >> fixed set (e.g. hypervisor can be KVM, QEMU, VCENTER or Driver Backend) do > >> we need to use both - radio buttons and select box instead of one field > >> type? Is there some rule (e.g. number of possible values) for this? I'm > >> asking because I think we should generate forms based on parameter > >> attributes we have in DB so I'd like to know what attributes are we missing > >> at the moment. > > Great question. Typically radio buttons would be used for two values and then a drop-down would be used for 3+. I think in the example you point out (KVM, QEMU, VCENTER) this is a tricky one because if the user hasn?t selected to use Neutron networking, they won?t see the VCENTER option. So technically the wireframes should show a drop down in this case, but if there were only two options here, I?d expect a radio button. Thoughts on this? For the moment I want to stay away from form generation, for the reasons I described above (and in general because we have great UX designers, who are much more capable than autogenerated forms :D). Over time, I do think it could be useful to have metadata that describes the parameters we want to collect and the type of widget that should be used to collect them (the decision on that should be UX-driven, not automated), and that metadata could be used to generate the form. But let's not attempt that for April. > >> > >> [1] > >> http://file.bos.redhat.com/~lsurette/RHOS/2014-03-03_ofi-ui_wireframes.pdf > > > > Adding [OFI] tag that I missed in subject so people using filters will see > > this. > > Thanks for raising these questions, it's very timely. Take care, --Hugh -- == Hugh Brock, hbrock at redhat.com == == Senior Engineering Manager, Cloud Engineering == == Tuskar: Elastic Scaling for OpenStack == == http://github.com/tuskar == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From jtomasek at redhat.com Wed Mar 5 15:23:41 2014 From: jtomasek at redhat.com (=?UTF-8?Q?Jirka_Tom=C3=A1=C5=A1ek?=) Date: Wed, 5 Mar 2014 07:23:41 -0800 (PST) Subject: [Rdo-list] [OFI] Orchestration <-> Wizard Integration In-Reply-To: <5315ECCE.5000003@redhat.com> References: <5315ECCE.5000003@redhat.com> Message-ID: <42bd9df8-30d0-4273-9cbf-dcc3d08d7a91@googlegroups.com> Dne ?ter?, 4. b?ezna 2014 16:10:06 UTC+1 Petr Chalupa napsal(a): > > Hello guys, > > I would like to start discussion about how the integration of > Orchestration and Wizard will look like. > > The parts are: > 1. Collecting the configuration of OS (OpenStack) infrastructure > 2. Configuring Foreman's HostGroups and other stuff based on that > configuration > 3. Orchestrate the provisioning of the whole OS infrastructure in the > right order using configured HostGroups and Dynflow. > > I am thinking that 1. and 2. will be part of the Wizard and 3. will be > the orchestration's job. > > I am assuming that 2. is ?simple function using seed data and > user-provided configuration that creates configured HostGroups. Meaning > it does not need any of the workflow engine stuff that Dynflow provides. > > If so then developing these in parallel and connecting them later should > be quite easy. I and Martyn can simulate the OS infrastructure > provisioning with blank hosts for now. > > Petr > > Hey, Regarding the wizard, I have been looking around for rails solutions and Wicked gem [1] seems like something we could use for steps 1 and 2. As you said, we basically need form with several steps that gets validated and submitted. I am not sure if Foreman already uses some kind of wizard which we might use instead of Wicked. Please let me know if there is something like that. [1] http://railscasts.com/episodes/346-wizard-forms-with-wicked?view=asciicast Jirka -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at redhat.com Wed Mar 5 15:24:48 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Wed, 5 Mar 2014 10:24:48 -0500 Subject: [Rdo-list] Bug for multinode deploy with packstack In-Reply-To: References: <20140227053343.GB25995@tesla.redhat.com> <20140227134755.GB7658@redhat.com> Message-ID: <20140305152448.GB11639@redhat.com> On Wed, Mar 05, 2014 at 01:57:24PM +0800, Shake Chen wrote: > I watch your mutil node video careful , use packstack run again and find > the problem. I think is bug for RDO I think you may be correct. My demo environment did not have a default firewall enabled, so problems like this would not have shown up. I'm going to re-deploy things today and double check the behavior, and if I can confirm the problem I'll open a bug against RDO. Thanks, -- Lars -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mhulan at redhat.com Wed Mar 5 16:46:03 2014 From: mhulan at redhat.com (Marek Hulan) Date: Wed, 05 Mar 2014 17:46:03 +0100 Subject: [Rdo-list] [foreman-dev] Re: [OFI] Orchestration <-> Wizard Integration In-Reply-To: <42bd9df8-30d0-4273-9cbf-dcc3d08d7a91@googlegroups.com> References: <5315ECCE.5000003@redhat.com> <42bd9df8-30d0-4273-9cbf-dcc3d08d7a91@googlegroups.com> Message-ID: <9707731.2dibXEbb8j@edna> On Wednesday 05 of March 2014 07:23:41 Jirka Tom??ek wrote: > Dne ?ter?, 4. b?ezna 2014 16:10:06 UTC+1 Petr Chalupa napsal(a): > > Hello guys, > > > > I would like to start discussion about how the integration of > > Orchestration and Wizard will look like. > > > > The parts are: > > 1. Collecting the configuration of OS (OpenStack) infrastructure > > 2. Configuring Foreman's HostGroups and other stuff based on that > > configuration > > 3. Orchestrate the provisioning of the whole OS infrastructure in the > > right order using configured HostGroups and Dynflow. > > > > I am thinking that 1. and 2. will be part of the Wizard and 3. will be > > the orchestration's job. > > > > I am assuming that 2. is ?simple function using seed data and > > user-provided configuration that creates configured HostGroups. Meaning > > it does not need any of the workflow engine stuff that Dynflow provides. > > > > If so then developing these in parallel and connecting them later should > > be quite easy. I and Martyn can simulate the OS infrastructure > > provisioning with blank hosts for now. > > > > Petr > > Hey, > > Regarding the wizard, I have been looking around for rails solutions and > Wicked gem [1] seems like something we could use for steps 1 and 2. As you > said, we basically need form with several steps that gets validated and > submitted. > > I am not sure if Foreman already uses some kind of wizard which we might > use instead of Wicked. Please let me know if there is something like that. > > [1] > http://railscasts.com/episodes/346-wizard-forms-with-wicked?view=asciicast > > Jirka Foreman does not use any 3rd party wizard tool. You can see wizard when you create new taxonomy (location or organization) or a good example could be foreman_setup plugin [1]. So we use own helpers for that. Wicked gem seems handy and have no extra dependencies so it should be easy to package. Code looks good, my only concern was hardcoded I18n for translations. I'm not sure whether it's problem or not, will look at that tomorrow. [1] https://github.com/theforeman/foreman_setup/blob/master/app/controllers/foreman_setup/provisioners_controller.rb -- Marek From jtomasek at redhat.com Wed Mar 5 18:56:22 2014 From: jtomasek at redhat.com (=?UTF-8?Q?Jirka_Tom=C3=A1=C5=A1ek?=) Date: Wed, 5 Mar 2014 10:56:22 -0800 (PST) Subject: [Rdo-list] [foreman-dev] Re: [OFI] Orchestration <-> Wizard Integration In-Reply-To: <9707731.2dibXEbb8j@edna> References: <5315ECCE.5000003@redhat.com> <42bd9df8-30d0-4273-9cbf-dcc3d08d7a91@googlegroups.com> <9707731.2dibXEbb8j@edna> Message-ID: <59cc0c19-e0c2-4cfb-b2cc-69db85e03177@googlegroups.com> Dne st?eda, 5. b?ezna 2014 17:46:03 UTC+1 Marek Hul?n napsal(a): > > On Wednesday 05 of March 2014 07:23:41 Jirka Tom??ek wrote: > > Dne ?ter?, 4. b?ezna 2014 16:10:06 UTC+1 Petr Chalupa napsal(a): > > > Hello guys, > > > > > > I would like to start discussion about how the integration of > > > Orchestration and Wizard will look like. > > > > > > The parts are: > > > 1. Collecting the configuration of OS (OpenStack) infrastructure > > > 2. Configuring Foreman's HostGroups and other stuff based on that > > > configuration > > > 3. Orchestrate the provisioning of the whole OS infrastructure in the > > > right order using configured HostGroups and Dynflow. > > > > > > I am thinking that 1. and 2. will be part of the Wizard and 3. will be > > > the orchestration's job. > > > > > > I am assuming that 2. is ?simple function using seed data and > > > user-provided configuration that creates configured HostGroups. > Meaning > > > it does not need any of the workflow engine stuff that Dynflow > provides. > > > > > > If so then developing these in parallel and connecting them later > should > > > be quite easy. I and Martyn can simulate the OS infrastructure > > > provisioning with blank hosts for now. > > > > > > Petr > > > > Hey, > > > > Regarding the wizard, I have been looking around for rails solutions and > > Wicked gem [1] seems like something we could use for steps 1 and 2. As > you > > said, we basically need form with several steps that gets validated and > > submitted. > > > > I am not sure if Foreman already uses some kind of wizard which we might > > use instead of Wicked. Please let me know if there is something like > that. > > > > [1] > > > http://railscasts.com/episodes/346-wizard-forms-with-wicked?view=asciicast > > > > Jirka > > Foreman does not use any 3rd party wizard tool. You can see wizard when > you > create new taxonomy (location or organization) or a good example could be > foreman_setup plugin [1]. So we use own helpers for that. > > Wicked gem seems handy and have no extra dependencies so it should be easy > to > package. Code looks good, my only concern was hardcoded I18n for > translations. > I'm not sure whether it's problem or not, will look at that tomorrow. > > [1] > > https://github.com/theforeman/foreman_setup/blob/master/app/controllers/foreman_setup/provisioners_controller.rb > > -- > Marek > As it seems that the wizard is going to be just a large form without need of saving data during the process the process, we can try to split it into fieldsets(wizard steps) and hide/show the steps with jquery. I'd like to look into that tomorrow. Jirka -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at speichert.pl Wed Mar 5 18:58:20 2014 From: daniel at speichert.pl (Daniel Speichert) Date: Wed, 05 Mar 2014 13:58:20 -0500 Subject: [Rdo-list] Question about Neutron Security Groups In-Reply-To: <53173BDE.1030207@speichert.pl> References: <53173BDE.1030207@speichert.pl> Message-ID: <531773CC.2090708@speichert.pl> Answering my own question: I found out why rules were not working. There were no "firewall bridges" on compute nodes to which the rules would apply. The reason for it was that compute nodes in nova.conf used the new: libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtGenericVIFDriver instead of the old and deprecated: libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver The latter one was used by my old cloud and therefore everything was working. The fixed for me right now is to use the deprecated driver which forces creation of "firewall bridges". However, as I understand, the GenericVIFDriver should create the bridge if an appropriate meta information exists. This information should exists if security groups are used but it is not happening. Is there any extra configuration required to make GenericVIFDriver create bridges? I am sure it is possible as the other drivers are removed in Icehouse. Best Regards, Daniel On 3/5/2014 9:59 AM, Daniel Speichert wrote: > Hello, > > I have a problem with Neutron security groups and I hoped you could > provide some ideas. > > I have two different cloud installation based on OpenStack Havana, > they both use Neutron setup with multiple tenants and routers. > > First cloud is based on Ubuntu and has both Neutron and Nova security > groups enabled (a mistake in configuraiton, I did not add > "firewall_driver=nova.virt.firewall.NoopFirewallDriver" to nova.conf. > On its compute nodes it has neutron-openvswitch-* iptables chains and > nova-instance* chains. > Rules from all of these chains seem to get hits and security groups > work properly. This cloud uses GRE tunnels. > > Second cloud is based on CentOS 6.5 with RDO. It has the same Neutron > setup and nova security groups disabled and > "security_group_api=neutron". It does not have iptables chains > nova-instance* but neutron chains are properly applied. None of these > chains get any hits at all and all traffic to instances is allowed. > This cloud used VXLANs but I switched to GRE which did not help. > > On both clouds there are no additional iptables rules besides the ones > generated by OpenStack - I flushed all the rules and chains and forced > sync by adding a security group rule. > > Do you have any idea why security groups don't work, i.e. the chains > don't get traffic? It seems to me that the rules in chains > neutron-openvswi-FORWARD and neutron-openvswi-INPUT don't get any hits > at all on my second cloud installation. > -- > Best Regards, > Daniel > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Wed Mar 5 20:54:38 2014 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 05 Mar 2014 15:54:38 -0500 Subject: [Rdo-list] Testing tool for upcoming test day Message-ID: <53178F0E.9080509@redhat.com> With assistance from Kashyap and the fine folks on #fedora-admin, we'll be using the Fedora Test Day tools for the upcoming test day. I'm in the process of populating it with the existing test cases, and wanted to let you all know about it so that you can create necessary accounts, poke around on it, and help me get the necessary test cases in there. This will also make it a lot easier to set things up for the next run-through on this. The test day app is at http://testdays.qa.fedoraproject.org/testdays/show_event?event_id=16 This is where you will see what tests need to be done, read the instructions for each, and enter your results from each as you go along. It's also where we'll see everyone's results at the end of the day. The Fedora Test Day page for this test day is at http://fedoraproject.org/wiki/Test_Day:2014-03-19_RDO This is for folks that participate in the Fedora testing world, who might stumble across our event and do some testing of their own. Hey, it could happen. And https://fedoraproject.org/wiki/Test_Day:2014-03-19_RDOMetadata is the metadata page that lists the test cases. This is where you can edit/add/remove test cases if you want to help me with that, or if you have things that you'd like to see tested. The format of this page matters, since it's parsed by the test day app, so please follow the examples when you make changes. -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From lars at redhat.com Wed Mar 5 22:57:38 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Wed, 5 Mar 2014 17:57:38 -0500 Subject: [Rdo-list] Bug for multinode deploy with packstack In-Reply-To: References: <20140227053343.GB25995@tesla.redhat.com> <20140227134755.GB7658@redhat.com> Message-ID: <20140305225738.GA7454@redhat.com> On Wed, Mar 05, 2014 at 01:57:24PM +0800, Shake Chen wrote: > I watch your mutil node video careful , use packstack run again and find > the problem. I think is bug for RDO I've submitted a fix for this upstream: https://bugs.launchpad.net/packstack/+bug/1288447 This should eventually make it into RDO. The Red Hat bug on this issue is here: https://bugzilla.redhat.com/show_bug.cgi?id=1073100 -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From shake.chen at gmail.com Thu Mar 6 06:21:01 2014 From: shake.chen at gmail.com (Shake Chen) Date: Thu, 6 Mar 2014 14:21:01 +0800 Subject: [Rdo-list] Bug for multinode deploy with packstack In-Reply-To: <20140305225738.GA7454@redhat.com> References: <20140227053343.GB25995@tesla.redhat.com> <20140227134755.GB7658@redhat.com> <20140305225738.GA7454@redhat.com> Message-ID: Hi Lars Thanks for confirm the bug. the other module have same bug, like cinder.heat, glance 172.18.1.12 controller 172.18.1.13 network 172.18.1.14 compute 172.18.1.15 compute 172.18.1.16 cinder storage 172.18.1.17 heat 172.18.1.18 glance The system "network" runs neutron-server and neutron-*-agent; the system "controller" runs everything other than nova-compute glance and cinder, including Horizon. I use the newest packstack for test # rpm -qa | grep packstack openstack-packstack-2013.2.1-0.32.dev987.el6.noarch After packstack finishes, the iptables rules on "cinder" look like this: # iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -s 172.18.1.14/32 -p tcp -m multiport --dports 3260,8776 -m comment --comment "001 cinder incoming 172.18.1.14" -j ACCEPT -A INPUT -s 172.18.1.15/32 -p tcp -m multiport --dports 3260,8776 -m comment --comment "001 cinder incoming 172.18.1.15" -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited the iptables also have no rule let horizon access the cinder. the iptables rules on "heat" look like this: # iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited no any iptables rules. so in horizon ,can not access heat. the iptables rules on "glance" look like this: # iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -s 172.18.1.14/32 -p tcp -m multiport --dports 9292 -m comment --comment "001 glance incoming 172.18.1.14" -j ACCEPT -A INPUT -s 172.18.1.15/32 -p tcp -m multiport --dports 9292 -m comment --comment "001 glance incoming 172.18.1.15" -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited also have same problem.the iptables also have no rule let horizon access the glance.. On Thu, Mar 6, 2014 at 6:57 AM, Lars Kellogg-Stedman wrote: > On Wed, Mar 05, 2014 at 01:57:24PM +0800, Shake Chen wrote: > > I watch your mutil node video careful , use packstack run again and find > > the problem. I think is bug for RDO > > I've submitted a fix for this upstream: > > https://bugs.launchpad.net/packstack/+bug/1288447 > > This should eventually make it into RDO. The Red Hat bug on this > issue is here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1073100 > > -- > Lars Kellogg-Stedman | larsks @ irc > Cloud Engineering / OpenStack | " " @ twitter > > -- Shake Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: From shake.chen at gmail.com Thu Mar 6 06:25:00 2014 From: shake.chen at gmail.com (Shake Chen) Date: Thu, 6 Mar 2014 14:25:00 +0800 Subject: [Rdo-list] Bug for multinode deploy with packstack In-Reply-To: <20140305225738.GA7454@redhat.com> References: <20140227053343.GB25995@tesla.redhat.com> <20140227134755.GB7658@redhat.com> <20140305225738.GA7454@redhat.com> Message-ID: Hi Lars Thanks for confirm the bug. the other module have same bug, like cinder.heat, glance 172.18.1.12 controller 172.18.1.13 network 172.18.1.14 compute 172.18.1.15 compute 172.18.1.16 cinder storage 172.18.1.17 heat 172.18.1.18 glance The system "network" runs neutron-server and neutron-*-agent; the system "controller" runs everything other than nova-compute glance and cinder, including Horizon. I use the newest packstack for test # rpm -qa | grep packstack openstack-packstack-2013.2.1-0.32.dev987.el6.noarch After packstack finishes, the iptables rules on "cinder" look like this: # iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -s 172.18.1.14/32 -p tcp -m multiport --dports 3260,8776 -m comment --comment "001 cinder incoming 172.18.1.14" -j ACCEPT -A INPUT -s 172.18.1.15/32 -p tcp -m multiport --dports 3260,8776 -m comment --comment "001 cinder incoming 172.18.1.15" -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited the iptables also have no rule let horizon access the cinder. the iptables rules on "heat" look like this: # iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited no any iptables rules. so in horizon ,can not access heat. the iptables rules on "glance" look like this: # iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -s 172.18.1.14/32 -p tcp -m multiport --dports 9292 -m comment --comment "001 glance incoming 172.18.1.14" -j ACCEPT -A INPUT -s 172.18.1.15/32 -p tcp -m multiport --dports 9292 -m comment --comment "001 glance incoming 172.18.1.15" -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited also have same problem.the iptables also have no rule let horizon access the glance.. On Thu, Mar 6, 2014 at 6:57 AM, Lars Kellogg-Stedman wrote: > On Wed, Mar 05, 2014 at 01:57:24PM +0800, Shake Chen wrote: > > I watch your mutil node video careful , use packstack run again and find > > the problem. I think is bug for RDO > > I've submitted a fix for this upstream: > > https://bugs.launchpad.net/packstack/+bug/1288447 > > This should eventually make it into RDO. The Red Hat bug on this > issue is here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1073100 > > -- > Lars Kellogg-Stedman | larsks @ irc > Cloud Engineering / OpenStack | " " @ twitter > > -- Shake Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhulan at redhat.com Thu Mar 6 11:49:56 2014 From: mhulan at redhat.com (Marek Hulan) Date: Thu, 06 Mar 2014 12:49:56 +0100 Subject: [Rdo-list] [foreman-dev] Re: [OFI] Orchestration <-> Wizard Integration In-Reply-To: <59cc0c19-e0c2-4cfb-b2cc-69db85e03177@googlegroups.com> References: <5315ECCE.5000003@redhat.com> <9707731.2dibXEbb8j@edna> <59cc0c19-e0c2-4cfb-b2cc-69db85e03177@googlegroups.com> Message-ID: <3261498.nqikRvtfTa@edna> On Wednesday 05 of March 2014 10:56:22 Jirka Tom??ek wrote: > Dne st?eda, 5. b?ezna 2014 17:46:03 UTC+1 Marek Hul?n napsal(a): > > On Wednesday 05 of March 2014 07:23:41 Jirka Tom??ek wrote: > > > Dne ?ter?, 4. b?ezna 2014 16:10:06 UTC+1 Petr Chalupa napsal(a): > > > > Hello guys, > > > > > > > > I would like to start discussion about how the integration of > > > > Orchestration and Wizard will look like. > > > > > > > > The parts are: > > > > 1. Collecting the configuration of OS (OpenStack) infrastructure > > > > 2. Configuring Foreman's HostGroups and other stuff based on that > > > > configuration > > > > 3. Orchestrate the provisioning of the whole OS infrastructure in the > > > > right order using configured HostGroups and Dynflow. > > > > > > > > I am thinking that 1. and 2. will be part of the Wizard and 3. will be > > > > the orchestration's job. > > > > > > > > I am assuming that 2. is ?simple function using seed data and > > > > user-provided configuration that creates configured HostGroups. > > > > Meaning > > > > > > it does not need any of the workflow engine stuff that Dynflow > > > > provides. > > > > > > If so then developing these in parallel and connecting them later > > > > should > > > > > > be quite easy. I and Martyn can simulate the OS infrastructure > > > > provisioning with blank hosts for now. > > > > > > > > Petr > > > > > > Hey, > > > > > > Regarding the wizard, I have been looking around for rails solutions and > > > Wicked gem [1] seems like something we could use for steps 1 and 2. As > > > > you > > > > > said, we basically need form with several steps that gets validated and > > > submitted. > > > > > > I am not sure if Foreman already uses some kind of wizard which we might > > > use instead of Wicked. Please let me know if there is something like > > > > that. > > > > > [1] > > > > http://railscasts.com/episodes/346-wizard-forms-with-wicked?view=asciicast > > > > > Jirka > > > > Foreman does not use any 3rd party wizard tool. You can see wizard when > > you > > create new taxonomy (location or organization) or a good example could be > > foreman_setup plugin [1]. So we use own helpers for that. > > > > Wicked gem seems handy and have no extra dependencies so it should be easy > > to > > package. Code looks good, my only concern was hardcoded I18n for > > translations. > > I'm not sure whether it's problem or not, will look at that tomorrow. > > > > [1] > > > > https://github.com/theforeman/foreman_setup/blob/master/app/controllers/fo > > reman_setup/provisioners_controller.rb > As it seems that the wizard is going to be just a large form without need > of saving data during the process the process, we can try to split it into > fieldsets(wizard steps) and hide/show the steps with jquery. I'd like to > look into that tomorrow. I think it's generally better to save step1 before continue with step2 so you don't have to start again when your browser crashes (or user closes tab, session expires or whatever). Anyway depending on what way we decide to implement - wicked seems as a good candidate for persisted wizard, I18n is used only for steps name translating (which is handy when you need translated routes) but that's probably not our case, so I18n hardcoding is not an issue. -- Marek From rbowen at redhat.com Thu Mar 6 16:08:02 2014 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 06 Mar 2014 11:08:02 -0500 Subject: [Rdo-list] Hangout: Flavio Percoco and Marconi - March 27th Message-ID: <53189D62.5030903@redhat.com> On March 27, 10am EST (http://tm3.org/marconihangout in your timezone), Flavio Percoco will be presenting a Google Hangout on the Marconi project. You can attend this presentation at https://plus.google.com/events/ckjhm8rggnqvrnspftna845kubk and if you can't make it to that time, it will be permanently archived there after the event. If you indicate your intent to attend on that page, you'll receive a reminder closer to the event. I'll also be sending a reminder here. -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From pchalupa at redhat.com Thu Mar 6 16:54:08 2014 From: pchalupa at redhat.com (Petr Chalupa) Date: Thu, 06 Mar 2014 17:54:08 +0100 Subject: [Rdo-list] [OFI] data model reusing Foreman's AR models Message-ID: <5318A830.1050609@redhat.com> Hi guys, After yesterdays IRC talk we (Marek and Petr) started to look at OFI models design. Unfortunately I haven't received any email with link to that so we jumped in quite late. Anyway we've tried to decode as much information as possible about staypuft model from etherpad [1]. Here's ER diagram we were able to construct from those information. Our main concern is that we are recreating models that are already present in Foreman. We understand Astapor issue that it was very hard for user understand all Foreman specifics so now we try to do it Openstack way and use Foreman as provisioning and configuration backend. However we still think that we should built on top of existing and tested models and just create a new easy to use and intuitive UI. inecas: +1 on reusing the Foreman model: the foreman model seems to have most of the things to support what is required, building something custom means: * duplication of what is already there * writing throw-away code, that nobody except the OFI itself will use: the power of Foreman is in the community: building it on the Foreman model (and enhancing it when needed) means the same work will be used outside of OFI with all the benefits that come with it I would like to avoid doing that, especially when it doesn't seem that much work to use the existing model So what we propose is following DB schema: Each deployment is contained under an Organization for separation. Which also means that same Foreman instance could be normally used when user leaves the wizard. Left side is ER model right side is representing relationships between Hostgroups instances. The one called 'Deploy' is lets say an common parent Hostgroup for all other hostgroups in the deployment. 'Deploy' allows sharing of configuration to the other hostgroups. Other hostgroups are representing Roles (like controller, compute, etc.) Basically we'd map: OpenStackDeployment -> Organization OpenStackLayout -> organization's parameter OpenStackRole -> Hostgroup (*) OpenStackService -> N/A (at least for April) OpenStackSeviceParam -> LookupKey (aka Smart Variable) OpenStackDeployService -> N/A OpenStackDeployServiceParam -> LookupKey (aka Smart Variable Value) OpenStackDeployRole -> assignment of Host to Hostgroup (*) At the moment, the only thing that's missing is that Foreman 1.4.1 does not allow us to set one hostgroup to be used in two parent hostgroups (one service in two roles). This is going to change in 1.5 when ConfigRoles will be merged. We suppose to use quickstack modules for April version so we still have just puppet classes on role level (not on service level) and therefore we won't allow user to customize services in roles. Since we need this post April we can stick with current Foreman model. Later we could either back-port ConfigRoles or base on newer Foreman. Benefits we see by reusing foreman models + we save work on need to model everything again + we save work on writing logic that will copy all (Deploy)Service/Role (Deploy)ServiceParameters values to Hostgroup/LookupKey/LookupValue + ability to turn off the wizard plugin (something like removing the training wheels) and keeping the Foreman instance still usable Cons - people may spend some time to better understand existing Foreman code inecas: that should be under Pros, and by people I don't mean the actual users of OFI, but its developers Potential concerns we understood from yesterday 1. too foreman specific 2. need of doing some business logic before Deploy is triggered 3. writing some easy UI around existing models is bigger pain that creating new objects from scratch 4. to able to delay host provisioning until whole deployment is configured Our answers to those 1. this is just about building new UI that we'll need anyway and re-labeling (we already have Smart Variable which in fact is LookupKey model), we could use STI or composition to modify Foreman objects behavior if they are too restricting 2. It's easy to extend Dynflow process with a plugin injecting any additional steps into the deployment process. 3. if this really becomes a problem we could always wrap existing models by some other classes 4. If the hosts are kept in unmanaged state nothing gets applied to them. Until orchestration takes over and switches them to managed state. Are we sure that we need to allow user to prepare changes to an existing-deployment-configuration and then apply them all at the same time in April? I think we can postpone this for later and keep Foreman's behavior for now that changes made to a hostgroup are immediately applied. [1]: http://etherpad.corp.redhat.com/staypuft-model-design-notes Looking forward to your feedback Petr and Marek. -------------- next part -------------- A non-text attachment was scrubbed... Name: model A.jpg Type: image/jpeg Size: 804467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: model B.jpg Type: image/jpeg Size: 880246 bytes Desc: not available URL: From rbowen at redhat.com Thu Mar 6 16:57:40 2014 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 06 Mar 2014 11:57:40 -0500 Subject: [Rdo-list] Call for papers: OpenStack Israel - June 2, 2014 Message-ID: <5318A904.2040603@redhat.com> The call for papers for OpenStack Israel is now open. The page doesn't specify a closing date for the CFP. http://www.openstack-israel.org/#!copy-of-call-for-papers/cu3y -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From sseago at redhat.com Thu Mar 6 18:22:11 2014 From: sseago at redhat.com (Scott Seago) Date: Thu, 06 Mar 2014 13:22:11 -0500 Subject: [Rdo-list] [OFI] data model reusing Foreman's AR models In-Reply-To: <5318A830.1050609@redhat.com> References: <5318A830.1050609@redhat.com> Message-ID: <5318BCD3.1040207@redhat.com> On 03/06/2014 11:54 AM, Petr Chalupa wrote: > Hi guys, > > After yesterdays IRC talk we (Marek and Petr) started to look at OFI > models design. Unfortunately I haven't received any email with link to > that so we jumped in quite late. Anyway we've tried to decode as much > information as possible about staypuft model from etherpad [1]. Here's > ER diagram we were able to construct from those information. > > > > Our main concern is that we are recreating models that are already > present in Foreman. We understand Astapor issue that it was very hard > for user understand all Foreman specifics so now we try to do it > Openstack way and use Foreman as provisioning and configuration > backend. However we still think that we should built on top of > existing and tested models and just create a new easy to use and > intuitive UI. > > inecas: +1 on reusing the Foreman model: the foreman model seems to > have most of the things to support what is required, building > something custom means: > * duplication of what is already there > * writing throw-away code, that nobody except the OFI itself will > use: the power of Foreman is in the community: building it on the > Foreman model (and enhancing it when needed) means the same work will > be used outside of OFI with all the benefits that come with it > I would like to avoid doing that, especially when it doesn't seem that > much work to use the existing model > > So what we propose is following DB schema: > > > > Each deployment is contained under an Organization for separation. > Which also means that same Foreman instance could be normally used > when user leaves the wizard. > > Left side is ER model right side is representing relationships between > Hostgroups instances. The one called 'Deploy' is lets say an common > parent Hostgroup for all other hostgroups in the deployment. 'Deploy' > allows sharing of configuration to the other hostgroups. Other > hostgroups are representing Roles (like controller, compute, etc.) > > Basically we'd map: > OpenStackDeployment -> Organization > OpenStackLayout -> organization's parameter > OpenStackRole -> Hostgroup (*) > OpenStackService -> N/A (at least for April) > OpenStackSeviceParam -> LookupKey (aka Smart Variable) > OpenStackDeployService -> N/A > OpenStackDeployServiceParam -> LookupKey (aka Smart Variable Value) > OpenStackDeployRole -> assignment of Host to Hostgroup (*) > > At the moment, the only thing that's missing is that Foreman 1.4.1 > does not allow us to set one hostgroup to be used in two parent > hostgroups (one service in two roles). This is going to change in 1.5 > when ConfigRoles will be merged. We suppose to use quickstack modules > for April version so we still have just puppet classes on role level > (not on service level) and therefore we won't allow user to customize > services in roles. Since we need this post April we can stick with > current Foreman model. Later we could either back-port ConfigRoles or > base on newer Foreman. > > Benefits we see by reusing foreman models > + we save work on need to model everything again > + we save work on writing logic that will copy all > (Deploy)Service/Role (Deploy)ServiceParameters values to > Hostgroup/LookupKey/LookupValue > + ability to turn off the wizard plugin (something like removing the > training wheels) and keeping the Foreman instance still usable > > Cons > - people may spend some time to better understand existing Foreman code > inecas: that should be under Pros, and by people I don't mean the > actual users of OFI, but its developers > > Potential concerns we understood from yesterday > 1. too foreman specific > 2. need of doing some business logic before Deploy is triggered > 3. writing some easy UI around existing models is bigger pain that > creating new objects from scratch > 4. to able to delay host provisioning until whole deployment is > configured > > Our answers to those > 1. this is just about building new UI that we'll need anyway and > re-labeling (we already have Smart Variable which in fact is LookupKey > model), we could use STI or composition to modify Foreman objects > behavior if they are too restricting > 2. It's easy to extend Dynflow process with a plugin injecting any > additional steps into the deployment process. > 3. if this really becomes a problem we could always wrap existing > models by some other classes > 4. If the hosts are kept in unmanaged state nothing gets applied to > them. Until orchestration takes over and switches them to managed state. > > Are we sure that we need to allow user to prepare changes to an > existing-deployment-configuration and then apply them all at the same > time in April? I think we can postpone this for later and keep > Foreman's behavior for now that changes made to a hostgroup are > immediately applied. > > [1]: http://etherpad.corp.redhat.com/staypuft-model-design-notes > > Looking forward to your feedback Petr and Marek. > Thanks for the writeup. I had a few comments/concerns around some things that this proposal may not address as-is, but perhaps can be tweaked to cover it. Also, if we do adopt this approach, I wonder if we'll need to do so with perhaps some additional plugin models to handle some of the bits that may not be describable with only foreman object types. Anyway, here are the concerns -- let me know what you think: 1) I'm not seeing any distinction between default objs (i.e. OpenStackRole) and per-deployment values (OpenStackDeployRole) -- we'd need to solve this before allowing multiple deployments. In my model the initial set of default roles and values 2) What are the consequences of no services in April? This also means we will have no per-service params, so there are UI implications (i.e. instead of breaking down params by service in each role, we have one list of per-role settings) 3) Will LookupKey allow us to set other metadata (ui widget type, etc -- or would we need to extend this model with a shadow table type model -- i.e. OpenStackLookupKey with a 1-to-1 relationship with the foreman one to include extra elements we need for UI generation. 4) The new suggestion layout seems to have some issues: OrganizationParameter makes it seem like it belongs to an organization. Layout is a general model/object, which exists from seed data load before the first org is created. It's mapped to a list of OpenStackRoles/HostGroups in seeds.rb, so a) it needs to be able to be created before an Organization (and be associated with more than one post-April) b) we need to be able to associate Layouts/OrganizationParameters with OpenStackRoles/HostGroups in a many-to-many manner in seeds.rb Scott From sseago at redhat.com Thu Mar 6 18:34:36 2014 From: sseago at redhat.com (Scott Seago) Date: Thu, 06 Mar 2014 13:34:36 -0500 Subject: [Rdo-list] [OFI] data model reusing Foreman's AR models In-Reply-To: <5318BCD3.1040207@redhat.com> References: <5318A830.1050609@redhat.com> <5318BCD3.1040207@redhat.com> Message-ID: <5318BFBC.6060106@redhat.com> On 03/06/2014 01:22 PM, Scott Seago wrote: > On 03/06/2014 11:54 AM, Petr Chalupa wrote: >> Hi guys, >> >> After yesterdays IRC talk we (Marek and Petr) started to look at OFI >> models design. Unfortunately I haven't received any email with link >> to that so we jumped in quite late. Anyway we've tried to decode as >> much information as possible about staypuft model from etherpad [1]. >> Here's ER diagram we were able to construct from those information. >> >> >> >> Our main concern is that we are recreating models that are already >> present in Foreman. We understand Astapor issue that it was very hard >> for user understand all Foreman specifics so now we try to do it >> Openstack way and use Foreman as provisioning and configuration >> backend. However we still think that we should built on top of >> existing and tested models and just create a new easy to use and >> intuitive UI. >> >> inecas: +1 on reusing the Foreman model: the foreman model seems to >> have most of the things to support what is required, building >> something custom means: >> * duplication of what is already there >> * writing throw-away code, that nobody except the OFI itself will >> use: the power of Foreman is in the community: building it on the >> Foreman model (and enhancing it when needed) means the same work will >> be used outside of OFI with all the benefits that come with it >> I would like to avoid doing that, especially when it doesn't seem >> that much work to use the existing model >> >> So what we propose is following DB schema: >> >> >> >> Each deployment is contained under an Organization for separation. >> Which also means that same Foreman instance could be normally used >> when user leaves the wizard. >> >> Left side is ER model right side is representing relationships >> between Hostgroups instances. The one called 'Deploy' is lets say an >> common parent Hostgroup for all other hostgroups in the deployment. >> 'Deploy' allows sharing of configuration to the other hostgroups. >> Other hostgroups are representing Roles (like controller, compute, etc.) >> >> Basically we'd map: >> OpenStackDeployment -> Organization >> OpenStackLayout -> organization's parameter >> OpenStackRole -> Hostgroup (*) >> OpenStackService -> N/A (at least for April) >> OpenStackSeviceParam -> LookupKey (aka Smart Variable) >> OpenStackDeployService -> N/A >> OpenStackDeployServiceParam -> LookupKey (aka Smart Variable Value) >> OpenStackDeployRole -> assignment of Host to Hostgroup (*) >> >> At the moment, the only thing that's missing is that Foreman 1.4.1 >> does not allow us to set one hostgroup to be used in two parent >> hostgroups (one service in two roles). This is going to change in 1.5 >> when ConfigRoles will be merged. We suppose to use quickstack modules >> for April version so we still have just puppet classes on role level >> (not on service level) and therefore we won't allow user to customize >> services in roles. Since we need this post April we can stick with >> current Foreman model. Later we could either back-port ConfigRoles or >> base on newer Foreman. >> >> Benefits we see by reusing foreman models >> + we save work on need to model everything again >> + we save work on writing logic that will copy all >> (Deploy)Service/Role (Deploy)ServiceParameters values to >> Hostgroup/LookupKey/LookupValue >> + ability to turn off the wizard plugin (something like removing the >> training wheels) and keeping the Foreman instance still usable >> >> Cons >> - people may spend some time to better understand existing Foreman code >> inecas: that should be under Pros, and by people I don't mean the >> actual users of OFI, but its developers >> >> Potential concerns we understood from yesterday >> 1. too foreman specific >> 2. need of doing some business logic before Deploy is triggered >> 3. writing some easy UI around existing models is bigger pain that >> creating new objects from scratch >> 4. to able to delay host provisioning until whole deployment is >> configured >> >> Our answers to those >> 1. this is just about building new UI that we'll need anyway and >> re-labeling (we already have Smart Variable which in fact is >> LookupKey model), we could use STI or composition to modify Foreman >> objects behavior if they are too restricting >> 2. It's easy to extend Dynflow process with a plugin injecting any >> additional steps into the deployment process. >> 3. if this really becomes a problem we could always wrap existing >> models by some other classes >> 4. If the hosts are kept in unmanaged state nothing gets applied to >> them. Until orchestration takes over and switches them to managed state. >> >> Are we sure that we need to allow user to prepare changes to an >> existing-deployment-configuration and then apply them all at the same >> time in April? I think we can postpone this for later and keep >> Foreman's behavior for now that changes made to a hostgroup are >> immediately applied. >> >> [1]: http://etherpad.corp.redhat.com/staypuft-model-design-notes >> >> Looking forward to your feedback Petr and Marek. >> > Thanks for the writeup. I had a few comments/concerns around some > things that this proposal may not address as-is, but perhaps can be > tweaked to cover it. Also, if we do adopt this approach, I wonder if > we'll need to do so with perhaps some additional plugin models to > handle some of the bits that may not be describable with only foreman > object types. > > Anyway, here are the concerns -- let me know what you think: Replying to my own message with some quick ideas on how we would might them: > > 1) I'm not seeing any distinction between default objs (i.e. > OpenStackRole) and > per-deployment values (OpenStackDeployRole) -- we'd need to solve this > before allowing multiple deployments. In my model the initial set > of default > roles and values Create a "Default Deployment Organization" in seeds.rb and "default" HostGroups for each role. When creating an actual deployment, copy these over. > 2) What are the consequences of no services in April? This also means > we will have no per-service params, so there are UI implications > (i.e. instead of breaking down params by service in each role, we > have one list of per-role settings) no answer here, as it's a requirements question, not an impl one. > 3) Will LookupKey allow us to set other metadata (ui widget type, > etc -- or would we need to extend this model with a shadow table type > model -- i.e. OpenStackLookupKey with a 1-to-1 relationship with the > foreman one to include extra elements we need for UI generation. See workaround in the suggestion itself: Create OpenstackLookupKey model with link to foreman LookupKey and extra metadata. > 4) The new suggestion layout seems to have some issues: > OrganizationParameter makes it seem like it belongs to an > organization. Layout is a general model/object, which exists from > seed data load before the first org is created. It's mapped to a > list of OpenStackRoles/HostGroups in seeds.rb, so > a) it needs to be able to be created before an Organization (and be > associated with more than one post-April) > b) we need to be able to associate Layouts/OrganizationParameters > with OpenStackRoles/HostGroups in a many-to-many manner in seeds.rb > This probably also needs custom plugin modeling linked to foreman model. Scott > Scott > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list From hbrock at redhat.com Thu Mar 6 19:14:38 2014 From: hbrock at redhat.com (Hugh O. Brock) Date: Thu, 6 Mar 2014 14:14:38 -0500 Subject: [Rdo-list] [OFI] data model reusing Foreman's AR models In-Reply-To: <5318A830.1050609@redhat.com> References: <5318A830.1050609@redhat.com> Message-ID: <20140306191438.GF3873@redhat.com> On Thu, Mar 06, 2014 at 05:54:08PM +0100, Petr Chalupa wrote: > Hi guys, > > After yesterdays IRC talk we (Marek and Petr) started to look at OFI > models design. Unfortunately I haven't received any email with link > to that so we jumped in quite late. Anyway we've tried to decode as > much information as possible about staypuft model from etherpad [1]. > Here's ER diagram we were able to construct from those information. Hey Petr and Marek. First of all I really appreciate the effort you have put into understanding the problem we're trying to solve and trying to work out the best way to solve it with existing Foreman data structures. Unfortunately there are a couple of important bits of the model that you missed that will make it considerably more difficult to implement using stock Foreman data structures. (I think Scott has already outlined some of these bits.) In particular, an OpenStackLayout is actually an entire reference architecture (think HA vs. non-HA vs -- later -- HA-with-separate-neutron-networker vs. HA-with-one-node-per-service) that will map to a set of roles, which in turn contain 1..n services. (This is a change we made from the original model he put together). In this sense an OpenStackLayout is a kind of template that we will, on deployment, *realize* by the creation and provisioning of hostgroups. For this reason, I think there is quite substantial value in modeling the layout as an entirely separate data structure from the hostgroups that we will generate in the deploy stage. For these reasons, I would like to press forward with Scott's original approach for now. If we arrive post-April and we decide we want to refactor to use more Foreman-centric data structures, let's revisit it at that time. Take care, --Hugh > > > > Our main concern is that we are recreating models that are already > present in Foreman. We understand Astapor issue that it was very > hard for user understand all Foreman specifics so now we try to do > it Openstack way and use Foreman as provisioning and configuration > backend. However we still think that we should built on top of > existing and tested models and just create a new easy to use and > intuitive UI. > > inecas: +1 on reusing the Foreman model: the foreman model seems to > have most of the things to support what is required, building > something custom means: > * duplication of what is already there > * writing throw-away code, that nobody except the OFI itself will > use: the power of Foreman is in the community: building it on the > Foreman model (and enhancing it when needed) means the same work > will be used outside of OFI with all the benefits that come with it > I would like to avoid doing that, especially when it doesn't seem > that much work to use the existing model > > So what we propose is following DB schema: > > > > Each deployment is contained under an Organization for separation. > Which also means that same Foreman instance could be normally used > when user leaves the wizard. > > Left side is ER model right side is representing relationships > between Hostgroups instances. The one called 'Deploy' is lets say an > common parent Hostgroup for all other hostgroups in the deployment. > 'Deploy' allows sharing of configuration to the other hostgroups. > Other hostgroups are representing Roles (like controller, compute, > etc.) > > Basically we'd map: > OpenStackDeployment -> Organization > OpenStackLayout -> organization's parameter > OpenStackRole -> Hostgroup (*) > OpenStackService -> N/A (at least for April) > OpenStackSeviceParam -> LookupKey (aka Smart Variable) > OpenStackDeployService -> N/A > OpenStackDeployServiceParam -> LookupKey (aka Smart Variable Value) > OpenStackDeployRole -> assignment of Host to Hostgroup (*) > > At the moment, the only thing that's missing is that Foreman 1.4.1 > does not allow us to set one hostgroup to be used in two parent > hostgroups (one service in two roles). This is going to change in > 1.5 when ConfigRoles will be merged. We suppose to use quickstack > modules for April version so we still have just puppet classes on > role level (not on service level) and therefore we won't allow user > to customize services in roles. Since we need this post April we can > stick with current Foreman model. Later we could either back-port > ConfigRoles or base on newer Foreman. > > Benefits we see by reusing foreman models > + we save work on need to model everything again > + we save work on writing logic that will copy all > (Deploy)Service/Role (Deploy)ServiceParameters values to > Hostgroup/LookupKey/LookupValue > + ability to turn off the wizard plugin (something like removing the > training wheels) and keeping the Foreman instance still usable > > Cons > - people may spend some time to better understand existing Foreman code > inecas: that should be under Pros, and by people I don't mean the > actual users of OFI, but its developers > > Potential concerns we understood from yesterday > 1. too foreman specific > 2. need of doing some business logic before Deploy is triggered > 3. writing some easy UI around existing models is bigger pain that > creating new objects from scratch > 4. to able to delay host provisioning until whole deployment is configured > > Our answers to those > 1. this is just about building new UI that we'll need anyway and > re-labeling (we already have Smart Variable which in fact is > LookupKey model), we could use STI or composition to modify Foreman > objects behavior if they are too restricting > 2. It's easy to extend Dynflow process with a plugin injecting any > additional steps into the deployment process. > 3. if this really becomes a problem we could always wrap existing > models by some other classes > 4. If the hosts are kept in unmanaged state nothing gets applied to > them. Until orchestration takes over and switches them to managed > state. > > Are we sure that we need to allow user to prepare changes to an > existing-deployment-configuration and then apply them all at the > same time in April? I think we can postpone this for later and keep > Foreman's behavior for now that changes made to a hostgroup are > immediately applied. > > [1]: http://etherpad.corp.redhat.com/staypuft-model-design-notes > > Looking forward to your feedback Petr and Marek. > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list -- == Hugh Brock, hbrock at redhat.com == == Senior Engineering Manager, Cloud Engineering == == Tuskar: Elastic Scaling for OpenStack == == http://github.com/tuskar == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From mhulan at redhat.com Thu Mar 6 20:19:30 2014 From: mhulan at redhat.com (Marek Hulan) Date: Thu, 6 Mar 2014 15:19:30 -0500 (EST) Subject: [Rdo-list] [foreman-dev] Re: [OFI] data model reusing Foreman's AR models In-Reply-To: <20140306191438.GF3873@redhat.com> References: <5318A830.1050609@redhat.com> <20140306191438.GF3873@redhat.com> Message-ID: <61840273.9245264.1394137170276.JavaMail.zimbra@redhat.com> Hello, we haven't mentioned layout as a specific entity yet because we think we don't need it for first version. In fact we think we'll use quickstack modules, so layouts are just simple groups of roles (for first version) and can be hardcoded. But we would like to introduce a layout entity later, this is something that foreman does not have yet. -- Marek ----- Original Message ----- > From: "Hugh O. Brock" > To: "Petr Chalupa" > Cc: "foreman-dev" , rdo-list at redhat.com > Sent: Thursday, March 6, 2014 8:14:38 PM > Subject: [foreman-dev] Re: [Rdo-list] [OFI] data model reusing Foreman's AR models > > On Thu, Mar 06, 2014 at 05:54:08PM +0100, Petr Chalupa wrote: > > Hi guys, > > > > After yesterdays IRC talk we (Marek and Petr) started to look at OFI > > models design. Unfortunately I haven't received any email with link > > to that so we jumped in quite late. Anyway we've tried to decode as > > much information as possible about staypuft model from etherpad [1]. > > Here's ER diagram we were able to construct from those information. > > Hey Petr and Marek. First of all I really appreciate the effort you have > put into understanding the problem we're trying to solve and trying to > work out the best way to solve it with existing Foreman data > structures. > > Unfortunately there are a couple of important bits of the model that you > missed that will make it considerably more difficult to implement using > stock Foreman data structures. (I think Scott has already outlined some > of these bits.) In particular, an OpenStackLayout is actually an entire > reference architecture (think HA vs. non-HA vs -- later -- > HA-with-separate-neutron-networker vs. HA-with-one-node-per-service) > that will map to a set of roles, which in turn contain 1..n > services. (This is a change we made from the original model he put > together). In this sense an OpenStackLayout is a kind of template that > we will, on deployment, *realize* by the creation and provisioning of > hostgroups. For this reason, I think there is quite substantial value in > modeling the layout as an entirely separate data structure from the > hostgroups that we will generate in the deploy stage. > > For these reasons, I would like to press forward with Scott's original > approach for now. If we arrive post-April and we decide we want to > refactor to use more Foreman-centric data structures, let's revisit it > at that time. > > Take care, > --Hugh > > > > > > > > > Our main concern is that we are recreating models that are already > > present in Foreman. We understand Astapor issue that it was very > > hard for user understand all Foreman specifics so now we try to do > > it Openstack way and use Foreman as provisioning and configuration > > backend. However we still think that we should built on top of > > existing and tested models and just create a new easy to use and > > intuitive UI. > > > > inecas: +1 on reusing the Foreman model: the foreman model seems to > > have most of the things to support what is required, building > > something custom means: > > * duplication of what is already there > > * writing throw-away code, that nobody except the OFI itself will > > use: the power of Foreman is in the community: building it on the > > Foreman model (and enhancing it when needed) means the same work > > will be used outside of OFI with all the benefits that come with it > > I would like to avoid doing that, especially when it doesn't seem > > that much work to use the existing model > > > > So what we propose is following DB schema: > > > > > > > > Each deployment is contained under an Organization for separation. > > Which also means that same Foreman instance could be normally used > > when user leaves the wizard. > > > > Left side is ER model right side is representing relationships > > between Hostgroups instances. The one called 'Deploy' is lets say an > > common parent Hostgroup for all other hostgroups in the deployment. > > 'Deploy' allows sharing of configuration to the other hostgroups. > > Other hostgroups are representing Roles (like controller, compute, > > etc.) > > > > Basically we'd map: > > OpenStackDeployment -> Organization > > OpenStackLayout -> organization's parameter > > OpenStackRole -> Hostgroup (*) > > OpenStackService -> N/A (at least for April) > > OpenStackSeviceParam -> LookupKey (aka Smart Variable) > > OpenStackDeployService -> N/A > > OpenStackDeployServiceParam -> LookupKey (aka Smart Variable Value) > > OpenStackDeployRole -> assignment of Host to Hostgroup (*) > > > > At the moment, the only thing that's missing is that Foreman 1.4.1 > > does not allow us to set one hostgroup to be used in two parent > > hostgroups (one service in two roles). This is going to change in > > 1.5 when ConfigRoles will be merged. We suppose to use quickstack > > modules for April version so we still have just puppet classes on > > role level (not on service level) and therefore we won't allow user > > to customize services in roles. Since we need this post April we can > > stick with current Foreman model. Later we could either back-port > > ConfigRoles or base on newer Foreman. > > > > Benefits we see by reusing foreman models > > + we save work on need to model everything again > > + we save work on writing logic that will copy all > > (Deploy)Service/Role (Deploy)ServiceParameters values to > > Hostgroup/LookupKey/LookupValue > > + ability to turn off the wizard plugin (something like removing the > > training wheels) and keeping the Foreman instance still usable > > > > Cons > > - people may spend some time to better understand existing Foreman code > > inecas: that should be under Pros, and by people I don't mean the > > actual users of OFI, but its developers > > > > Potential concerns we understood from yesterday > > 1. too foreman specific > > 2. need of doing some business logic before Deploy is triggered > > 3. writing some easy UI around existing models is bigger pain that > > creating new objects from scratch > > 4. to able to delay host provisioning until whole deployment is configured > > > > Our answers to those > > 1. this is just about building new UI that we'll need anyway and > > re-labeling (we already have Smart Variable which in fact is > > LookupKey model), we could use STI or composition to modify Foreman > > objects behavior if they are too restricting > > 2. It's easy to extend Dynflow process with a plugin injecting any > > additional steps into the deployment process. > > 3. if this really becomes a problem we could always wrap existing > > models by some other classes > > 4. If the hosts are kept in unmanaged state nothing gets applied to > > them. Until orchestration takes over and switches them to managed > > state. > > > > Are we sure that we need to allow user to prepare changes to an > > existing-deployment-configuration and then apply them all at the > > same time in April? I think we can postpone this for later and keep > > Foreman's behavior for now that changes made to a hostgroup are > > immediately applied. > > > > [1]: http://etherpad.corp.redhat.com/staypuft-model-design-notes > > > > Looking forward to your feedback Petr and Marek. > > > > > > > _______________________________________________ > > Rdo-list mailing list > > Rdo-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > -- > == Hugh Brock, hbrock at redhat.com == > == Senior Engineering Manager, Cloud Engineering == > == Tuskar: Elastic Scaling for OpenStack == > == http://github.com/tuskar == > > "I know that you believe you understand what you think I said, but I?m > not sure you realize that what you heard is not what I meant." > --Robert McCloskey > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > From hbrock at redhat.com Thu Mar 6 20:46:46 2014 From: hbrock at redhat.com (Hugh O. Brock) Date: Thu, 6 Mar 2014 15:46:46 -0500 Subject: [Rdo-list] [foreman-dev] Re: [OFI] data model reusing Foreman's AR models In-Reply-To: <61840273.9245264.1394137170276.JavaMail.zimbra@redhat.com> References: <5318A830.1050609@redhat.com> <20140306191438.GF3873@redhat.com> <61840273.9245264.1394137170276.JavaMail.zimbra@redhat.com> Message-ID: <20140306204646.GK3873@redhat.com> On Thu, Mar 06, 2014 at 03:19:30PM -0500, Marek Hulan wrote: > Hello, > > we haven't mentioned layout as a specific entity yet because we think we don't > need it for first version. In fact we think we'll use quickstack modules, > so layouts are just simple groups of roles (for first version) and can be > hardcoded. But we would like to introduce a layout entity later, this is something > that foreman does not have yet. Hmm... I have to tell you guys, I'm really skeptical about changing the direction. I like the idea of a plugin with OpenStack-specific models that sits on top of the Foreman data structures. While I'm all for doing something that is reusable later in Foreman, I have a feeling we're talking about another week of work to get that modeling done... on a plugin that I want to be largely code complete *in two weeks*. I've asked Scott to go ahead and start implementing the design we've already worked out. If you guys can show me how we can get to the same point he's aiming for using a different model, in two weeks, then I'm willing to look at it... but even then I'm not sure it makes sense. Moreover I can't afford to wait for anything here, right now, that is in any way tied to a future feature in Foreman. We have to work with what we have right now. If you guys want I'm happy to talk further on this tomorrow morning, let me know. Take care, --Hugh > > ----- Original Message ----- > > From: "Hugh O. Brock" > > To: "Petr Chalupa" > > Cc: "foreman-dev" , rdo-list at redhat.com > > Sent: Thursday, March 6, 2014 8:14:38 PM > > Subject: [foreman-dev] Re: [Rdo-list] [OFI] data model reusing Foreman's AR models > > > > On Thu, Mar 06, 2014 at 05:54:08PM +0100, Petr Chalupa wrote: > > > Hi guys, > > > > > > After yesterdays IRC talk we (Marek and Petr) started to look at OFI > > > models design. Unfortunately I haven't received any email with link > > > to that so we jumped in quite late. Anyway we've tried to decode as > > > much information as possible about staypuft model from etherpad [1]. > > > Here's ER diagram we were able to construct from those information. > > > > Hey Petr and Marek. First of all I really appreciate the effort you have > > put into understanding the problem we're trying to solve and trying to > > work out the best way to solve it with existing Foreman data > > structures. > > > > Unfortunately there are a couple of important bits of the model that you > > missed that will make it considerably more difficult to implement using > > stock Foreman data structures. (I think Scott has already outlined some > > of these bits.) In particular, an OpenStackLayout is actually an entire > > reference architecture (think HA vs. non-HA vs -- later -- > > HA-with-separate-neutron-networker vs. HA-with-one-node-per-service) > > that will map to a set of roles, which in turn contain 1..n > > services. (This is a change we made from the original model he put > > together). In this sense an OpenStackLayout is a kind of template that > > we will, on deployment, *realize* by the creation and provisioning of > > hostgroups. For this reason, I think there is quite substantial value in > > modeling the layout as an entirely separate data structure from the > > hostgroups that we will generate in the deploy stage. > > > > For these reasons, I would like to press forward with Scott's original > > approach for now. If we arrive post-April and we decide we want to > > refactor to use more Foreman-centric data structures, let's revisit it > > at that time. > > > > Take care, > > --Hugh > > > > > > > > > > > > > > Our main concern is that we are recreating models that are already > > > present in Foreman. We understand Astapor issue that it was very > > > hard for user understand all Foreman specifics so now we try to do > > > it Openstack way and use Foreman as provisioning and configuration > > > backend. However we still think that we should built on top of > > > existing and tested models and just create a new easy to use and > > > intuitive UI. > > > > > > inecas: +1 on reusing the Foreman model: the foreman model seems to > > > have most of the things to support what is required, building > > > something custom means: > > > * duplication of what is already there > > > * writing throw-away code, that nobody except the OFI itself will > > > use: the power of Foreman is in the community: building it on the > > > Foreman model (and enhancing it when needed) means the same work > > > will be used outside of OFI with all the benefits that come with it > > > I would like to avoid doing that, especially when it doesn't seem > > > that much work to use the existing model > > > > > > So what we propose is following DB schema: > > > > > > > > > > > > Each deployment is contained under an Organization for separation. > > > Which also means that same Foreman instance could be normally used > > > when user leaves the wizard. > > > > > > Left side is ER model right side is representing relationships > > > between Hostgroups instances. The one called 'Deploy' is lets say an > > > common parent Hostgroup for all other hostgroups in the deployment. > > > 'Deploy' allows sharing of configuration to the other hostgroups. > > > Other hostgroups are representing Roles (like controller, compute, > > > etc.) > > > > > > Basically we'd map: > > > OpenStackDeployment -> Organization > > > OpenStackLayout -> organization's parameter > > > OpenStackRole -> Hostgroup (*) > > > OpenStackService -> N/A (at least for April) > > > OpenStackSeviceParam -> LookupKey (aka Smart Variable) > > > OpenStackDeployService -> N/A > > > OpenStackDeployServiceParam -> LookupKey (aka Smart Variable Value) > > > OpenStackDeployRole -> assignment of Host to Hostgroup (*) > > > > > > At the moment, the only thing that's missing is that Foreman 1.4.1 > > > does not allow us to set one hostgroup to be used in two parent > > > hostgroups (one service in two roles). This is going to change in > > > 1.5 when ConfigRoles will be merged. We suppose to use quickstack > > > modules for April version so we still have just puppet classes on > > > role level (not on service level) and therefore we won't allow user > > > to customize services in roles. Since we need this post April we can > > > stick with current Foreman model. Later we could either back-port > > > ConfigRoles or base on newer Foreman. > > > > > > Benefits we see by reusing foreman models > > > + we save work on need to model everything again > > > + we save work on writing logic that will copy all > > > (Deploy)Service/Role (Deploy)ServiceParameters values to > > > Hostgroup/LookupKey/LookupValue > > > + ability to turn off the wizard plugin (something like removing the > > > training wheels) and keeping the Foreman instance still usable > > > > > > Cons > > > - people may spend some time to better understand existing Foreman code > > > inecas: that should be under Pros, and by people I don't mean the > > > actual users of OFI, but its developers > > > > > > Potential concerns we understood from yesterday > > > 1. too foreman specific > > > 2. need of doing some business logic before Deploy is triggered > > > 3. writing some easy UI around existing models is bigger pain that > > > creating new objects from scratch > > > 4. to able to delay host provisioning until whole deployment is configured > > > > > > Our answers to those > > > 1. this is just about building new UI that we'll need anyway and > > > re-labeling (we already have Smart Variable which in fact is > > > LookupKey model), we could use STI or composition to modify Foreman > > > objects behavior if they are too restricting > > > 2. It's easy to extend Dynflow process with a plugin injecting any > > > additional steps into the deployment process. > > > 3. if this really becomes a problem we could always wrap existing > > > models by some other classes > > > 4. If the hosts are kept in unmanaged state nothing gets applied to > > > them. Until orchestration takes over and switches them to managed > > > state. > > > > > > Are we sure that we need to allow user to prepare changes to an > > > existing-deployment-configuration and then apply them all at the > > > same time in April? I think we can postpone this for later and keep > > > Foreman's behavior for now that changes made to a hostgroup are > > > immediately applied. > > > > > > [1]: http://etherpad.corp.redhat.com/staypuft-model-design-notes > > > > > > Looking forward to your feedback Petr and Marek. > > > > > > > > > > > > _______________________________________________ > > > Rdo-list mailing list > > > Rdo-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > > > -- > > == Hugh Brock, hbrock at redhat.com == > > == Senior Engineering Manager, Cloud Engineering == > > == Tuskar: Elastic Scaling for OpenStack == > > == http://github.com/tuskar == > > > > "I know that you believe you understand what you think I said, but I?m > > not sure you realize that what you heard is not what I meant." > > --Robert McCloskey > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- == Hugh Brock, hbrock at redhat.com == == Senior Engineering Manager, Cloud Engineering == == Tuskar: Elastic Scaling for OpenStack == == http://github.com/tuskar == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From mhulan at redhat.com Thu Mar 6 21:24:27 2014 From: mhulan at redhat.com (Marek Hulan) Date: Thu, 6 Mar 2014 16:24:27 -0500 (EST) Subject: [Rdo-list] [OFI] data model reusing Foreman's AR models In-Reply-To: <5318D577.8020708@redhat.com> References: <5318BFBC.6060106@redhat.com> <5318D577.8020708@redhat.com> Message-ID: <757789817.9264164.1394141067151.JavaMail.zimbra@redhat.com> Hello Scott, we appreciate reviewing our design and your feedback. I'm sending answers below in text. >> Anyway, here are the concerns -- let me know what you think: > Replying to my own message with some quick ideas on how we would might > them: >> >> 1) I'm not seeing any distinction between default objs (i.e. >> OpenStackRole) and >> per-deployment values (OpenStackDeployRole) -- we'd need to solve this >> before allowing multiple deployments. In my model the initial set >> of default >> roles and values > Create a "Default Deployment Organization" in seeds.rb and "default" > HostGroups for each role. > When creating an actual deployment, copy these over. Yes we are thinking the same. Having template hostgroups and clone them to create an actual deplyment of OpenStack. >> 2) What are the consequences of no services in April? This also means >> we will have no per-service params, so there are UI implications >> (i.e. instead of breaking down params by service in each role, we >> have one list of per-role settings) > no answer here, as it's a requirements question, not an impl one. Out thinking is to add only what is realy needed for April. Roles <-> Services relation is given by Astapor modules so we figured we do not need model for them yet. Parameters can be organized by a Ruby hash using metaprograming no need fo actual AR model. This can be improved later as soon as we need it and this approach would not limit us doing that. >> 3) Will LookupKey allow us to set other metadata (ui widget type, >> etc -- or would we need to extend this model with a shadow table type >> model -- i.e. OpenStackLookupKey with a 1-to-1 relationship with the >> foreman one to include extra elements we need for UI generation. > See workaround in the suggestion itself: Create OpenstackLookupKey model > with link to foreman LookupKey and extra metadata. LookupKeys already have most of these. They have type (so we can create widget based on that), default value, even validations (only regexp and list of possible values) and description (inline help). We could just add visibility_condition maybe few others. It's easy to add functionality to models in plugins using concerns (mixins), we already have some plugins doing this. Or if it's too much changes we can always use STI or wrap it by another object (composition) or as you suggest add some new object with 1-to-1 mapping. Also since Foreman itself would benefit from loading more of these metadata from puppet modules we could share the effort here. But for first version I think it's ok to have all of them in seed. >> 4) The new suggestion layout seems to have some issues: >> OrganizationParameter makes it seem like it belongs to an >> organization. Layout is a general model/object, which exists from OrganizationParameter mentioned on the picture is existing class in Foreman, it's a child of Parameter and it is used to set global parameters for puppet classes. Each organization has it's parameters specific to the given OS deployment. Also if parameter is set here (like global password for all services according to wireframes), Foreman allows us to reuse this value in LookupKey matcher which means you can set value based on this organization parameter. You can also set these values based on organization parameters. Btw same works for default values. >> seed data load before the first org is created. It's mapped to a >> list of OpenStackRoles/HostGroups in seeds.rb, so Since for April we support only HA and noHA which are not that much different from each other we are thinking to add a model for Layout later and for now just use predefined host-groups and copy them. >> a) it needs to be able to be created before an Organization (and be >> associated with more than one post-April) >> b) we need to be able to associate Layouts/OrganizationParameters >> with OpenStackRoles/HostGroups in a many-to-many manner in seeds.rb We are afraid that this can only leads to problems when the layout definitions or its parts are shared between deployments. If something changes other deplyments may be affected accidentally. So just copying the template hostgroup is faster (no additional models) and safer. Feel free to ask any further question, we'll be happy for any (even negative) feedback. Thank you, -- Marek From pchalupa at redhat.com Thu Mar 6 21:24:31 2014 From: pchalupa at redhat.com (Petr Chalupa) Date: Thu, 06 Mar 2014 22:24:31 +0100 Subject: [Rdo-list] [foreman-dev] Re: [OFI] data model reusing Foreman's AR models In-Reply-To: <20140306204646.GK3873@redhat.com> References: <5318A830.1050609@redhat.com> <20140306191438.GF3873@redhat.com> <61840273.9245264.1394137170276.JavaMail.zimbra@redhat.com> <20140306204646.GK3873@redhat.com> Message-ID: <5318E78F.6060708@redhat.com> On 06.03.14 21:46, Hugh O. Brock wrote: > On Thu, Mar 06, 2014 at 03:19:30PM -0500, Marek Hulan wrote: >> Hello, >> >> we haven't mentioned layout as a specific entity yet because we think we don't >> need it for first version. In fact we think we'll use quickstack modules, >> so layouts are just simple groups of roles (for first version) and can be >> hardcoded. But we would like to introduce a layout entity later, this is something >> that foreman does not have yet. > > Hmm... I have to tell you guys, I'm really skeptical about changing the > direction. I like the idea of a plugin with OpenStack-specific models > that sits on top of the Foreman data structures. While I'm all for doing > something that is reusable later in Foreman, I have a feeling we're > talking about another week of work to get that modeling done... on a > plugin that I want to be largely code complete *in two weeks*. > > I've asked Scott to go ahead and start implementing the design we've > already worked out. If you guys can show me how we can get to the same > point he's aiming for using a different model, in two weeks, then I'm > willing to look at it... but even then I'm not sure it makes > sense. Moreover I can't afford to wait for anything here, right now, > that is in any way tied to a future feature in Foreman. We have to work > with what we have right now. > > If you guys want I'm happy to talk further on this tomorrow morning, let > me know. > > Take care, > --Hugh Our main motivation is not to things reusable later by Foreman, but we think we could actually save some time. Re-usability is just nice side-effect. If Scott thinks there's no benefit of using existing Foreman models we don't insist on our design for sure. We've already finished answers for Scott's comments so we are sending in parallel, we'll try to make this discussion as short as possible. Petr > >> >> ----- Original Message ----- >>> From: "Hugh O. Brock" >>> To: "Petr Chalupa" >>> Cc: "foreman-dev" , rdo-list at redhat.com >>> Sent: Thursday, March 6, 2014 8:14:38 PM >>> Subject: [foreman-dev] Re: [Rdo-list] [OFI] data model reusing Foreman's AR models >>> >>> On Thu, Mar 06, 2014 at 05:54:08PM +0100, Petr Chalupa wrote: >>>> Hi guys, >>>> >>>> After yesterdays IRC talk we (Marek and Petr) started to look at OFI >>>> models design. Unfortunately I haven't received any email with link >>>> to that so we jumped in quite late. Anyway we've tried to decode as >>>> much information as possible about staypuft model from etherpad [1]. >>>> Here's ER diagram we were able to construct from those information. >>> >>> Hey Petr and Marek. First of all I really appreciate the effort you have >>> put into understanding the problem we're trying to solve and trying to >>> work out the best way to solve it with existing Foreman data >>> structures. >>> >>> Unfortunately there are a couple of important bits of the model that you >>> missed that will make it considerably more difficult to implement using >>> stock Foreman data structures. (I think Scott has already outlined some >>> of these bits.) In particular, an OpenStackLayout is actually an entire >>> reference architecture (think HA vs. non-HA vs -- later -- >>> HA-with-separate-neutron-networker vs. HA-with-one-node-per-service) >>> that will map to a set of roles, which in turn contain 1..n >>> services. (This is a change we made from the original model he put >>> together). In this sense an OpenStackLayout is a kind of template that >>> we will, on deployment, *realize* by the creation and provisioning of >>> hostgroups. For this reason, I think there is quite substantial value in >>> modeling the layout as an entirely separate data structure from the >>> hostgroups that we will generate in the deploy stage. >>> >>> For these reasons, I would like to press forward with Scott's original >>> approach for now. If we arrive post-April and we decide we want to >>> refactor to use more Foreman-centric data structures, let's revisit it >>> at that time. >>> >>> Take care, >>> --Hugh >>> >>>> >>>> >>>> >>>> Our main concern is that we are recreating models that are already >>>> present in Foreman. We understand Astapor issue that it was very >>>> hard for user understand all Foreman specifics so now we try to do >>>> it Openstack way and use Foreman as provisioning and configuration >>>> backend. However we still think that we should built on top of >>>> existing and tested models and just create a new easy to use and >>>> intuitive UI. >>>> >>>> inecas: +1 on reusing the Foreman model: the foreman model seems to >>>> have most of the things to support what is required, building >>>> something custom means: >>>> * duplication of what is already there >>>> * writing throw-away code, that nobody except the OFI itself will >>>> use: the power of Foreman is in the community: building it on the >>>> Foreman model (and enhancing it when needed) means the same work >>>> will be used outside of OFI with all the benefits that come with it >>>> I would like to avoid doing that, especially when it doesn't seem >>>> that much work to use the existing model >>>> >>>> So what we propose is following DB schema: >>>> >>>> >>>> >>>> Each deployment is contained under an Organization for separation. >>>> Which also means that same Foreman instance could be normally used >>>> when user leaves the wizard. >>>> >>>> Left side is ER model right side is representing relationships >>>> between Hostgroups instances. The one called 'Deploy' is lets say an >>>> common parent Hostgroup for all other hostgroups in the deployment. >>>> 'Deploy' allows sharing of configuration to the other hostgroups. >>>> Other hostgroups are representing Roles (like controller, compute, >>>> etc.) >>>> >>>> Basically we'd map: >>>> OpenStackDeployment -> Organization >>>> OpenStackLayout -> organization's parameter >>>> OpenStackRole -> Hostgroup (*) >>>> OpenStackService -> N/A (at least for April) >>>> OpenStackSeviceParam -> LookupKey (aka Smart Variable) >>>> OpenStackDeployService -> N/A >>>> OpenStackDeployServiceParam -> LookupKey (aka Smart Variable Value) >>>> OpenStackDeployRole -> assignment of Host to Hostgroup (*) >>>> >>>> At the moment, the only thing that's missing is that Foreman 1.4.1 >>>> does not allow us to set one hostgroup to be used in two parent >>>> hostgroups (one service in two roles). This is going to change in >>>> 1.5 when ConfigRoles will be merged. We suppose to use quickstack >>>> modules for April version so we still have just puppet classes on >>>> role level (not on service level) and therefore we won't allow user >>>> to customize services in roles. Since we need this post April we can >>>> stick with current Foreman model. Later we could either back-port >>>> ConfigRoles or base on newer Foreman. >>>> >>>> Benefits we see by reusing foreman models >>>> + we save work on need to model everything again >>>> + we save work on writing logic that will copy all >>>> (Deploy)Service/Role (Deploy)ServiceParameters values to >>>> Hostgroup/LookupKey/LookupValue >>>> + ability to turn off the wizard plugin (something like removing the >>>> training wheels) and keeping the Foreman instance still usable >>>> >>>> Cons >>>> - people may spend some time to better understand existing Foreman code >>>> inecas: that should be under Pros, and by people I don't mean the >>>> actual users of OFI, but its developers >>>> >>>> Potential concerns we understood from yesterday >>>> 1. too foreman specific >>>> 2. need of doing some business logic before Deploy is triggered >>>> 3. writing some easy UI around existing models is bigger pain that >>>> creating new objects from scratch >>>> 4. to able to delay host provisioning until whole deployment is configured >>>> >>>> Our answers to those >>>> 1. this is just about building new UI that we'll need anyway and >>>> re-labeling (we already have Smart Variable which in fact is >>>> LookupKey model), we could use STI or composition to modify Foreman >>>> objects behavior if they are too restricting >>>> 2. It's easy to extend Dynflow process with a plugin injecting any >>>> additional steps into the deployment process. >>>> 3. if this really becomes a problem we could always wrap existing >>>> models by some other classes >>>> 4. If the hosts are kept in unmanaged state nothing gets applied to >>>> them. Until orchestration takes over and switches them to managed >>>> state. >>>> >>>> Are we sure that we need to allow user to prepare changes to an >>>> existing-deployment-configuration and then apply them all at the >>>> same time in April? I think we can postpone this for later and keep >>>> Foreman's behavior for now that changes made to a hostgroup are >>>> immediately applied. >>>> >>>> [1]: http://etherpad.corp.redhat.com/staypuft-model-design-notes >>>> >>>> Looking forward to your feedback Petr and Marek. >>>> >>> >>> >>> >>>> _______________________________________________ >>>> Rdo-list mailing list >>>> Rdo-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >>> >>> -- >>> == Hugh Brock, hbrock at redhat.com == >>> == Senior Engineering Manager, Cloud Engineering == >>> == Tuskar: Elastic Scaling for OpenStack == >>> == http://github.com/tuskar == >>> >>> "I know that you believe you understand what you think I said, but I?m >>> not sure you realize that what you heard is not what I meant." >>> --Robert McCloskey >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "foreman-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to foreman-dev+unsubscribe at googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups "foreman-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe at googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. > From inecas at redhat.com Fri Mar 7 08:55:09 2014 From: inecas at redhat.com (Ivan Necas) Date: Fri, 7 Mar 2014 03:55:09 -0500 (EST) Subject: [Rdo-list] [foreman-dev] Re: [OFI] data model reusing Foreman's AR models In-Reply-To: <20140306191438.GF3873@redhat.com> References: <5318A830.1050609@redhat.com> <20140306191438.GF3873@redhat.com> Message-ID: <1759965271.564364.1394182509630.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On Thu, Mar 06, 2014 at 05:54:08PM +0100, Petr Chalupa wrote: > > Hi guys, > > > > After yesterdays IRC talk we (Marek and Petr) started to look at OFI > > models design. Unfortunately I haven't received any email with link > > to that so we jumped in quite late. Anyway we've tried to decode as > > much information as possible about staypuft model from etherpad [1]. > > Here's ER diagram we were able to construct from those information. > > Hey Petr and Marek. First of all I really appreciate the effort you have > put into understanding the problem we're trying to solve and trying to > work out the best way to solve it with existing Foreman data > structures. > > Unfortunately there are a couple of important bits of the model that you > missed that will make it considerably more difficult to implement using > stock Foreman data structures. (I think Scott has already outlined some > of these bits.) In particular, an OpenStackLayout is actually an entire > reference architecture (think HA vs. non-HA vs -- later -- > HA-with-separate-neutron-networker vs. HA-with-one-node-per-service) > that will map to a set of roles, which in turn contain 1..n > services. (This is a change we made from the original model he put > together). In this sense an OpenStackLayout is a kind of template that > we will, on deployment, *realize* by the creation and provisioning of > hostgroups. For this reason, I think there is quite substantial value in > modeling the layout as an entirely separate data structure from the > hostgroups that we will generate in the deploy stage. > > For these reasons, I would like to press forward with Scott's original > approach for now. If we arrive post-April and we decide we want to > refactor to use more Foreman-centric data structures, let's revisit it > at that time. I'm supporting the approach of reusing the Foreman modeles where it makes sense (and a lot of things in the original model can be IMO modeled quite easily with what's already done in Foreman) because, even if it might not look like that, it should be less work since all of it is already being used in production environment. I understand the need for the setup and realization phase being separated, but introducing new models is just one way of solving that. I have no big issues with Openstack Roles and Services for the purposes of the wizard and they could really speed up its creation. However, having the Deployment Roles and Deployment Services and Deployment Service Params seems quite odd to me, as I don't see added value in those models as opposed to hostgroups, global and smart parameters. But it might be just lack my understanding and I will be happy for somebody bringing more more lights on the benefits of those. On the other hand, using the things we already have in Foreman for the deployment phase allows working on the orchestration without having the wizard ready to be used (if we agree what the artifacts of the wizard will be). Anyway, I would encourage looking into the Foreman advances features around smart parameters, organizations etc. before modeling those things from scratch. Just my $0.02 -- Ivan > > Take care, > --Hugh > > > > > > > > > Our main concern is that we are recreating models that are already > > present in Foreman. We understand Astapor issue that it was very > > hard for user understand all Foreman specifics so now we try to do > > it Openstack way and use Foreman as provisioning and configuration > > backend. However we still think that we should built on top of > > existing and tested models and just create a new easy to use and > > intuitive UI. > > > > inecas: +1 on reusing the Foreman model: the foreman model seems to > > have most of the things to support what is required, building > > something custom means: > > * duplication of what is already there > > * writing throw-away code, that nobody except the OFI itself will > > use: the power of Foreman is in the community: building it on the > > Foreman model (and enhancing it when needed) means the same work > > will be used outside of OFI with all the benefits that come with it > > I would like to avoid doing that, especially when it doesn't seem > > that much work to use the existing model > > > > So what we propose is following DB schema: > > > > > > > > Each deployment is contained under an Organization for separation. > > Which also means that same Foreman instance could be normally used > > when user leaves the wizard. > > > > Left side is ER model right side is representing relationships > > between Hostgroups instances. The one called 'Deploy' is lets say an > > common parent Hostgroup for all other hostgroups in the deployment. > > 'Deploy' allows sharing of configuration to the other hostgroups. > > Other hostgroups are representing Roles (like controller, compute, > > etc.) > > > > Basically we'd map: > > OpenStackDeployment -> Organization > > OpenStackLayout -> organization's parameter > > OpenStackRole -> Hostgroup (*) > > OpenStackService -> N/A (at least for April) > > OpenStackSeviceParam -> LookupKey (aka Smart Variable) > > OpenStackDeployService -> N/A > > OpenStackDeployServiceParam -> LookupKey (aka Smart Variable Value) > > OpenStackDeployRole -> assignment of Host to Hostgroup (*) > > > > At the moment, the only thing that's missing is that Foreman 1.4.1 > > does not allow us to set one hostgroup to be used in two parent > > hostgroups (one service in two roles). This is going to change in > > 1.5 when ConfigRoles will be merged. We suppose to use quickstack > > modules for April version so we still have just puppet classes on > > role level (not on service level) and therefore we won't allow user > > to customize services in roles. Since we need this post April we can > > stick with current Foreman model. Later we could either back-port > > ConfigRoles or base on newer Foreman. > > > > Benefits we see by reusing foreman models > > + we save work on need to model everything again > > + we save work on writing logic that will copy all > > (Deploy)Service/Role (Deploy)ServiceParameters values to > > Hostgroup/LookupKey/LookupValue > > + ability to turn off the wizard plugin (something like removing the > > training wheels) and keeping the Foreman instance still usable > > > > Cons > > - people may spend some time to better understand existing Foreman code > > inecas: that should be under Pros, and by people I don't mean the > > actual users of OFI, but its developers > > > > Potential concerns we understood from yesterday > > 1. too foreman specific > > 2. need of doing some business logic before Deploy is triggered > > 3. writing some easy UI around existing models is bigger pain that > > creating new objects from scratch > > 4. to able to delay host provisioning until whole deployment is configured > > > > Our answers to those > > 1. this is just about building new UI that we'll need anyway and > > re-labeling (we already have Smart Variable which in fact is > > LookupKey model), we could use STI or composition to modify Foreman > > objects behavior if they are too restricting > > 2. It's easy to extend Dynflow process with a plugin injecting any > > additional steps into the deployment process. > > 3. if this really becomes a problem we could always wrap existing > > models by some other classes > > 4. If the hosts are kept in unmanaged state nothing gets applied to > > them. Until orchestration takes over and switches them to managed > > state. > > > > Are we sure that we need to allow user to prepare changes to an > > existing-deployment-configuration and then apply them all at the > > same time in April? I think we can postpone this for later and keep > > Foreman's behavior for now that changes made to a hostgroup are > > immediately applied. > > > > [1]: http://etherpad.corp.redhat.com/staypuft-model-design-notes > > > > Looking forward to your feedback Petr and Marek. > > > > > > > _______________________________________________ > > Rdo-list mailing list > > Rdo-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > -- > == Hugh Brock, hbrock at redhat.com == > == Senior Engineering Manager, Cloud Engineering == > == Tuskar: Elastic Scaling for OpenStack == > == http://github.com/tuskar == > > "I know that you believe you understand what you think I said, but I?m > not sure you realize that what you heard is not what I meant." > --Robert McCloskey > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > From elobatocs at gmail.com Fri Mar 7 09:15:34 2014 From: elobatocs at gmail.com (Daniel Lobato) Date: Fri, 7 Mar 2014 10:15:34 +0100 Subject: [Rdo-list] [foreman-dev] Re: [OFI] data model reusing Foreman's AR models In-Reply-To: <1759965271.564364.1394182509630.JavaMail.zimbra@redhat.com> References: <5318A830.1050609@redhat.com> <20140306191438.GF3873@redhat.com> <1759965271.564364.1394182509630.JavaMail.zimbra@redhat.com> Message-ID: I'd have to vouch for building on Foreman models too. It seems like there are already many responsibilities that Foreman models cover already and are easily mapped. Moreover, the work of finding the equivalences with the Openstack models has already more or less been done from what I read above too. I think we're basically going to rewrite a large portion of what Foreman already provides if we start using many new models. Also we get proven integration with Dynflow for free, if it gets hairy we can use composition as stated on the first post. Another important reason is I think development pace should significantly increase since a portion of the team already knows and has worked with these models, and we can explain to newcomers how to use them to build Staypuft. On Fri, Mar 7, 2014 at 9:55 AM, Ivan Necas wrote: > > > ----- Original Message ----- > > On Thu, Mar 06, 2014 at 05:54:08PM +0100, Petr Chalupa wrote: > > > Hi guys, > > > > > > After yesterdays IRC talk we (Marek and Petr) started to look at OFI > > > models design. Unfortunately I haven't received any email with link > > > to that so we jumped in quite late. Anyway we've tried to decode as > > > much information as possible about staypuft model from etherpad [1]. > > > Here's ER diagram we were able to construct from those information. > > > > Hey Petr and Marek. First of all I really appreciate the effort you have > > put into understanding the problem we're trying to solve and trying to > > work out the best way to solve it with existing Foreman data > > structures. > > > > Unfortunately there are a couple of important bits of the model that you > > missed that will make it considerably more difficult to implement using > > stock Foreman data structures. (I think Scott has already outlined some > > of these bits.) In particular, an OpenStackLayout is actually an entire > > reference architecture (think HA vs. non-HA vs -- later -- > > HA-with-separate-neutron-networker vs. HA-with-one-node-per-service) > > that will map to a set of roles, which in turn contain 1..n > > services. (This is a change we made from the original model he put > > together). In this sense an OpenStackLayout is a kind of template that > > we will, on deployment, *realize* by the creation and provisioning of > > hostgroups. For this reason, I think there is quite substantial value in > > modeling the layout as an entirely separate data structure from the > > hostgroups that we will generate in the deploy stage. > > > > For these reasons, I would like to press forward with Scott's original > > approach for now. If we arrive post-April and we decide we want to > > refactor to use more Foreman-centric data structures, let's revisit it > > at that time. > > I'm supporting the approach of reusing the Foreman modeles where it makes > sense (and a lot of things in the original model can be IMO modeled quite > easily with what's already done in Foreman) because, even if it might not > look like that, it should be less work since all of it is already being > used in production environment. > > I understand the need for the setup and realization phase being separated, > but introducing new models is just one way of solving that. I have no big > issues with Openstack Roles and Services for the purposes of the wizard > and they > could really speed up its creation. > > However, having the Deployment Roles and Deployment Services and > Deployment Service > Params seems quite odd to me, as I don't see added value in those models > as opposed to hostgroups, global and smart parameters. But it might be just > lack my understanding and I will be happy for somebody bringing more > more lights on the benefits of those. > > On the other hand, using the things we already have in Foreman > for the deployment phase allows working on the orchestration without having > the wizard ready to be used (if we agree what the artifacts of the wizard > will be). > > Anyway, I would encourage looking into the Foreman advances features around > smart parameters, organizations etc. before modeling those things from > scratch. > > Just my $0.02 > > -- Ivan > > > > > Take care, > > --Hugh > > > > > > > > > > > > > > Our main concern is that we are recreating models that are already > > > present in Foreman. We understand Astapor issue that it was very > > > hard for user understand all Foreman specifics so now we try to do > > > it Openstack way and use Foreman as provisioning and configuration > > > backend. However we still think that we should built on top of > > > existing and tested models and just create a new easy to use and > > > intuitive UI. > > > > > > inecas: +1 on reusing the Foreman model: the foreman model seems to > > > have most of the things to support what is required, building > > > something custom means: > > > * duplication of what is already there > > > * writing throw-away code, that nobody except the OFI itself will > > > use: the power of Foreman is in the community: building it on the > > > Foreman model (and enhancing it when needed) means the same work > > > will be used outside of OFI with all the benefits that come with it > > > I would like to avoid doing that, especially when it doesn't seem > > > that much work to use the existing model > > > > > > So what we propose is following DB schema: > > > > > > > > > > > > Each deployment is contained under an Organization for separation. > > > Which also means that same Foreman instance could be normally used > > > when user leaves the wizard. > > > > > > Left side is ER model right side is representing relationships > > > between Hostgroups instances. The one called 'Deploy' is lets say an > > > common parent Hostgroup for all other hostgroups in the deployment. > > > 'Deploy' allows sharing of configuration to the other hostgroups. > > > Other hostgroups are representing Roles (like controller, compute, > > > etc.) > > > > > > Basically we'd map: > > > OpenStackDeployment -> Organization > > > OpenStackLayout -> organization's parameter > > > OpenStackRole -> Hostgroup (*) > > > OpenStackService -> N/A (at least for April) > > > OpenStackSeviceParam -> LookupKey (aka Smart Variable) > > > OpenStackDeployService -> N/A > > > OpenStackDeployServiceParam -> LookupKey (aka Smart Variable Value) > > > OpenStackDeployRole -> assignment of Host to Hostgroup (*) > > > > > > At the moment, the only thing that's missing is that Foreman 1.4.1 > > > does not allow us to set one hostgroup to be used in two parent > > > hostgroups (one service in two roles). This is going to change in > > > 1.5 when ConfigRoles will be merged. We suppose to use quickstack > > > modules for April version so we still have just puppet classes on > > > role level (not on service level) and therefore we won't allow user > > > to customize services in roles. Since we need this post April we can > > > stick with current Foreman model. Later we could either back-port > > > ConfigRoles or base on newer Foreman. > > > > > > Benefits we see by reusing foreman models > > > + we save work on need to model everything again > > > + we save work on writing logic that will copy all > > > (Deploy)Service/Role (Deploy)ServiceParameters values to > > > Hostgroup/LookupKey/LookupValue > > > + ability to turn off the wizard plugin (something like removing the > > > training wheels) and keeping the Foreman instance still usable > > > > > > Cons > > > - people may spend some time to better understand existing Foreman code > > > inecas: that should be under Pros, and by people I don't mean the > > > actual users of OFI, but its developers > > > > > > Potential concerns we understood from yesterday > > > 1. too foreman specific > > > 2. need of doing some business logic before Deploy is triggered > > > 3. writing some easy UI around existing models is bigger pain that > > > creating new objects from scratch > > > 4. to able to delay host provisioning until whole deployment is > configured > > > > > > Our answers to those > > > 1. this is just about building new UI that we'll need anyway and > > > re-labeling (we already have Smart Variable which in fact is > > > LookupKey model), we could use STI or composition to modify Foreman > > > objects behavior if they are too restricting > > > 2. It's easy to extend Dynflow process with a plugin injecting any > > > additional steps into the deployment process. > > > 3. if this really becomes a problem we could always wrap existing > > > models by some other classes > > > 4. If the hosts are kept in unmanaged state nothing gets applied to > > > them. Until orchestration takes over and switches them to managed > > > state. > > > > > > Are we sure that we need to allow user to prepare changes to an > > > existing-deployment-configuration and then apply them all at the > > > same time in April? I think we can postpone this for later and keep > > > Foreman's behavior for now that changes made to a hostgroup are > > > immediately applied. > > > > > > [1]: http://etherpad.corp.redhat.com/staypuft-model-design-notes > > > > > > Looking forward to your feedback Petr and Marek. > > > > > > > > > > > > _______________________________________________ > > > Rdo-list mailing list > > > Rdo-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > > > -- > > == Hugh Brock, hbrock at redhat.com == > > == Senior Engineering Manager, Cloud Engineering == > > == Tuskar: Elastic Scaling for OpenStack == > > == http://github.com/tuskar == > > > > "I know that you believe you understand what you think I said, but I'm > > not sure you realize that what you heard is not what I meant." > > --Robert McCloskey > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Daniel Lobato @elobatoss blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kimbyeonggi at gmail.com Mon Mar 10 01:40:32 2014 From: kimbyeonggi at gmail.com (BYEONG-GI KIM) Date: Mon, 10 Mar 2014 10:40:32 +0900 Subject: [Rdo-list] About multi node deployment set up. Message-ID: Hi. I'm getting started learning OpenStack, and decided to install it by following multi node deployment. I'm considering connecting the OpenStack with OpenFlow Controller, but I was barely able to find related information for it. Actually, I could not find any doccumentation or guide of Packstack installation for multi node set up. Could anybody recommend me some references for the installation? Thanks in advance. Best regards Byeong-Gi Kim -------------- next part -------------- An HTML attachment was scrubbed... URL: From kchamart at redhat.com Mon Mar 10 06:49:18 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Mon, 10 Mar 2014 12:19:18 +0530 Subject: [Rdo-list] About multi node deployment set up. In-Reply-To: References: Message-ID: <20140310064236.GA25362@tesla.pnq.redhat.com> On Mon, Mar 10, 2014 at 10:40:32AM +0900, BYEONG-GI KIM wrote: > Hi. > > I'm getting started learning OpenStack, and decided to install it by > following multi node deployment. If you're _just_ getting started and haven't done any OpenStack installs before, I'd suggest to start small (with only the required OpenStack services including networking) and then try to expand as you get things working. > > I'm considering connecting the OpenStack with OpenFlow Controller, but I > was barely able to find related information for it. > > Actually, I could not find any doccumentation or guide of Packstack > installation for multi node set up. Could anybody recommend me some > references for the installation? Here's[1] some information on setting up Packstack with multi nodes. To deploy RDO using Foreman (this is more recommended for multi node installs), refer to this guide[2]. In the context of OpenStack Networking, here's[3] a recommended article to read to understand what's happening under the hood. I myself have not used OpenFlow, but here's some details[4] of OpenFlow in the context of OpenDaylight and RDO. [1] http://openstack.redhat.com/GettingStartedHavana_w_GRE [2] http://openstack.redhat.com/Deploying_RDO_using_Foreman [3] http://openstack.redhat.com/Networking_in_too_much_detail [4] http://openstack.redhat.com/OpenDaylight_intergration -- /kashyap From kchamart at redhat.com Mon Mar 10 09:06:40 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Mon, 10 Mar 2014 14:36:40 +0530 Subject: [Rdo-list] About multi node deployment set up. In-Reply-To: <20140310064236.GA25362@tesla.pnq.redhat.com> References: <20140310064236.GA25362@tesla.pnq.redhat.com> Message-ID: <20140310090640.GB25362@tesla.pnq.redhat.com> On Mon, Mar 10, 2014 at 12:19:18PM +0530, Kashyap Chamarthy wrote: > On Mon, Mar 10, 2014 at 10:40:32AM +0900, BYEONG-GI KIM wrote: [. . .] > > Actually, I could not find any doccumentation or guide of Packstack > > installation for multi node set up. Could anybody recommend me some > > references for the installation? > > Here's[1] some information on setting up Packstack with multi nodes. Forgot to note - recently Lars did a Google Hangout of RDO multi-node setup with Packstack here http://oddbit.com/rdo-hangout-multinode-packstack-slides/ -- /kashyap From ak at cloudssky.com Mon Mar 10 19:46:45 2014 From: ak at cloudssky.com (Arash Kaffamanesh) Date: Mon, 10 Mar 2014 20:46:45 +0100 Subject: [Rdo-list] Deploying RDO using Foreman Message-ID: Hi, I posted a question regarding "Deploying RDO using Foreman" to ask.openstack.org and thanks to Keshyap and Rich which engaged me to proceed further, I updated the thread here: https://ask.openstack.org/en/question/12104/deploying-rdo-using-foreman/ The post might be too long, here some more information about the reason behind my question and some more questions: I'm trying to learn Foreman for installing OpenStack and use it to deploy RDO on top of RDO to provide some kind of OpenStack training / webinars and later to run the whole thing on 6-8 bare metal machines and use it to deploy OpenShift and write a tutorial about the whole thing and post it on the RDO site, LinkedIn, etc. About our BASE RDO environment: Our RDO based 3 node environment is thanks to the latest update very stable and very fast now and I've to thank all of you smart guys for doing such a great work! Our environment uses VLAN and the Foreman RDO installation shall use GRE and Qemu (or LXC / Docker) to let us play with the whole thing and write a tutorial about the whole thing. So my questions: Does the Foreman installation on top of a virtualized environment work at all? (I guess yes) Could a VLAN based BASE-Install be a problem to succeed with this scenario (to have GRE on top of VLAN)? (I guess no) Has someone tried such a scenario before? (I guess yes) Could I use LXC / Docker instead Qemu? Thanks in advance for any help / advice! Arash -------------- next part -------------- An HTML attachment was scrubbed... URL: From kchamart at redhat.com Tue Mar 11 04:23:35 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Tue, 11 Mar 2014 09:53:35 +0530 Subject: [Rdo-list] Deploying RDO using Foreman In-Reply-To: References: Message-ID: <20140311042335.GA27412@tesla.redhat.com> On Mon, Mar 10, 2014 at 08:46:45PM +0100, Arash Kaffamanesh wrote: > Hi, > > I posted a question regarding "Deploying RDO using Foreman" to > ask.openstack.org and thanks to Keshyap and Rich which engaged me to > proceed further, I updated the thread here: > > https://ask.openstack.org/en/question/12104/deploying-rdo-using-foreman/ > > The post might be too long, here some more information about the reason > behind my question and some more questions: > > I'm trying to learn Foreman for installing OpenStack and use it to deploy > RDO on top of RDO to provide some kind of OpenStack training / webinars and > later to run the whole thing on 6-8 bare metal machines and use it to > deploy OpenShift and write a tutorial about the whole thing and post it on > the RDO site, LinkedIn, etc. > > About our BASE RDO environment: > Our RDO based 3 node environment is thanks to the latest update very stable > and very fast now and I've to thank all of you smart guys for doing such a > great work! > > Our environment uses VLAN and the Foreman RDO installation shall use GRE > and Qemu (or LXC / Docker) to let us play with the whole thing and write a > tutorial about the whole thing. > > So my questions: > Does the Foreman installation on top of a virtualized environment work at > all? (I guess yes) Yes, technically, it should work. Refer to my previous email on this list[1] for some URLs on Foreman. > Could a VLAN based BASE-Install be a problem to succeed with this scenario > (to have GRE on top of VLAN)? (I guess no) Only way to know with certainity - to try it. > Has someone tried such a scenario before? (I guess yes) > Could I use LXC / Docker instead Qemu? There's active work on upstream for Docker support, so you ought to experiment and carefully note down observations, filing bugs along the way. And, it depends on _what_ you want to do with the LXC/Docker setup. If it's just to try it out, there's decent resources on the inter-webs. > > Thanks in advance for any help / advice! > Arash [1] https://www.redhat.com/archives/rdo-list/2014-March/msg00037.html -- /kashyap From pchalupa at redhat.com Tue Mar 11 12:07:34 2014 From: pchalupa at redhat.com (Petr Chalupa) Date: Tue, 11 Mar 2014 13:07:34 +0100 Subject: [Rdo-list] [OFI] Members list In-Reply-To: <20140226122031.GB2952@redhat.com> References: <530DB43B.1010306@redhat.com> <20140226122031.GB2952@redhat.com> Message-ID: <531EFC86.6040507@redhat.com> Hi guys, please fill your row in members table at http://projects.theforeman.org/projects/ofi/wiki/Members. There are still 4 people missing. Thanks, Petr On 26.02.14 13:20, Hugh O. Brock wrote: > On Wed, Feb 26, 2014 at 10:30:35AM +0100, Petr Chalupa wrote: >> Hi, >> >> I've added table of the all members to our wiki at >> http://projects.theforeman.org/projects/ofi/wiki/Members. I think >> it'll quite useful to have basic information (as name, irc, >> timezone, component) at one place. Please fill in your details. >> >> Petr >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list > > Thanks Petr, great idea. > > --Hugh > From hbrock at redhat.com Tue Mar 11 13:07:28 2014 From: hbrock at redhat.com (Hugh O. Brock) Date: Tue, 11 Mar 2014 14:07:28 +0100 Subject: [Rdo-list] Deploying RDO using Foreman In-Reply-To: <20140311042335.GA27412@tesla.redhat.com> References: <20140311042335.GA27412@tesla.redhat.com> Message-ID: <20140311130726.GF18124@redhat.com> On Tue, Mar 11, 2014 at 09:53:35AM +0530, Kashyap Chamarthy wrote: > On Mon, Mar 10, 2014 at 08:46:45PM +0100, Arash Kaffamanesh wrote: > > Hi, > > > > I posted a question regarding "Deploying RDO using Foreman" to > > ask.openstack.org and thanks to Keshyap and Rich which engaged me to > > proceed further, I updated the thread here: > > > > https://ask.openstack.org/en/question/12104/deploying-rdo-using-foreman/ > > > > The post might be too long, here some more information about the reason > > behind my question and some more questions: > > > > I'm trying to learn Foreman for installing OpenStack and use it to deploy > > RDO on top of RDO to provide some kind of OpenStack training / webinars and > > later to run the whole thing on 6-8 bare metal machines and use it to > > deploy OpenShift and write a tutorial about the whole thing and post it on > > the RDO site, LinkedIn, etc. > > > > About our BASE RDO environment: > > Our RDO based 3 node environment is thanks to the latest update very stable > > and very fast now and I've to thank all of you smart guys for doing such a > > great work! > > > > Our environment uses VLAN and the Foreman RDO installation shall use GRE > > and Qemu (or LXC / Docker) to let us play with the whole thing and write a > > tutorial about the whole thing. > > > > So my questions: > > Does the Foreman installation on top of a virtualized environment work at > > all? (I guess yes) > > Yes, technically, it should work. Refer to my previous email on > this list[1] for some URLs on Foreman. > > > Could a VLAN based BASE-Install be a problem to succeed with this scenario > > (to have GRE on top of VLAN)? (I guess no) > > Only way to know with certainity - to try it. > > > Has someone tried such a scenario before? (I guess yes) > > Could I use LXC / Docker instead Qemu? > > There's active work on upstream for Docker support, so you ought to > experiment and carefully note down observations, filing bugs along the > way. > > And, it depends on _what_ you want to do with the LXC/Docker setup. If > it's just to try it out, there's decent resources on the inter-webs. > Hi there. It's also worth mentioning that we are actively working on improving the OpenStack installation process with Foreman, including adding a better UI and some workflow components to stage deployments. Watch this list for details as they emerge. --Hugh -- == Hugh Brock, hbrock at redhat.com == == Senior Engineering Manager, Cloud Engineering == == Tuskar: Elastic Scaling for OpenStack == == http://github.com/tuskar == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From rbowen at redhat.com Tue Mar 11 13:47:15 2014 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 11 Mar 2014 09:47:15 -0400 Subject: [Rdo-list] Weekly IRC RDO community meeting 2014-03-11 Message-ID: <531F13E3.8090100@redhat.com> Thanks to everyone who participated in the IRC meeting this morning. A reminder: we do this every Tuesday morning at 9am Eastern US time. Minutes: http://meetbot.fedoraproject.org/rdo/2014-03-11/rdo.2014-03-11-13.02.html Minutes (text): http://meetbot.fedoraproject.org/rdo/2014-03-11/rdo.2014-03-11-13.02.txt Log: http://meetbot.fedoraproject.org/rdo/2014-03-11/rdo.2014-03-11-13.02.log.html ===================== #rdo: RDO weekly sync ===================== Meeting started by mburned at 13:02:07 UTC. The full logs are available at http://meetbot.fedoraproject.org/rdo/2014-03-11/rdo.2014-03-11-13.02.log.html . Meeting summary --------------- * LINK: https://etherpad.openstack.org/p/rdo_community_manager_sync (rbowen, 13:02:24) * Test Day (rbowen, 13:03:17) * Test day stuff in the Fedora Test Day app for easier test reporting (rbowen, 13:04:32) * LINK: http://testdays.qa.fedoraproject.org/testdays/show_event?event_id=16 (rbowen, 13:04:34) * metadata can be edited there too (rbowen, 13:04:43) * LINK: https://fedoraproject.org/wiki/Test_Day:2014-03-19_RDOMetadata (rbowen, 13:04:52) * test day scheduled for March 10-20 (mburned, 13:09:42) * rbowen has added a lot of test cases to the test day app (mburned, 13:10:40) * some cleanup still needed (consistent naming, consistent order for different OSes, etc) (mburned, 13:11:01) * some need some additional content (mburned, 13:11:08) * some packages for milestone 3 exist already for rawhide/f21 (mburned, 13:11:54) * EPEL-7 is WIP (mburned, 13:12:26) * AGREED: we should concentrate on epel7/epel6/f20 in that order (fedora rawhide not a priority at this time) (mburned, 13:16:43) * ACTION: mburns to produce icehouse livecds as soon as packages are ready (mburned, 13:18:35) * ACTION: rbowen to send reminders of the test day (mburned, 13:19:10) * Hangout (mburned, 13:21:00) * next hangout set for March 27 (mburned, 13:21:13) * topic is Marconi, host is flaper87 (mburned, 13:21:29) * LINK: https://plus.google.com/events/ckjhm8rggnqvrnspftna845kubk (rbowen, 13:21:49) * April Newsletter (rbowen, 13:23:22) * LINK: https://etherpad.openstack.org/p/rdo_apr_2014_newsletter (mburned, 13:23:34) * Looking for topics if there's anything you want to say in that. (rbowen, 13:23:34) * Engineer interviews (mburned, 13:24:35) * interview with ohadlevy should be posted later today (mburned, 13:24:50) * other interviews in the works (mburned, 13:25:05) * if interested, please contact rbowen (mburned, 13:25:17) * Upcoming Events (rbowen, 13:26:11) * April: RH Summit -- booth (mburned, 13:26:24) * mburns will be in attendance (mburned, 13:26:35) * multiple demos lined up (mburned, 13:26:51) * OpenStack summit in May (mburned, 13:27:44) * RDO will have a booth (mburned, 13:28:02) * rbowen is a track chair for "Getting Started" (mburned, 13:28:14) * will likely reuse some of the same demos from RH Summit at Openstack Summit (mburned, 13:28:46) * LinuxCon Japan also in May (mburned, 13:29:13) * RDO will have a booth/table (mburned, 13:29:20) * rbowen and red_trela will be in attendance at the booth (mburned, 13:29:47) * a CentOS dojo will likely also happen and LinuxCon Japan (mburned, 13:30:39) * Bug triage (mburned, 13:31:35) * 16 open bugs as of a few hours ago (mburned, 13:32:29) * 3 are security related, being handled by security experts (mburned, 13:34:26) * other bugs going through normal triage (mburned, 13:35:59) * Forum (mburned, 13:36:13) * 38 open questions (mburned, 13:37:13) * lot of work done last week answering and closing abandoned questions (mburned, 13:37:50) * closed about 20 last week (mburned, 13:37:59) * approx 20 more opened during that time (mburned, 13:38:09) * need some better stat tracking (mburned, 13:38:18) * rbowen to investigate what else we can track (mburned, 13:39:53) * other topics (mburned, 13:39:58) Meeting ended at 13:40:31 UTC. Action Items ------------ * mburns to produce icehouse livecds as soon as packages are ready * rbowen to send reminders of the test day Action Items, by person ----------------------- * rbowen * rbowen to send reminders of the test day * **UNASSIGNED** * mburns to produce icehouse livecds as soon as packages are ready People Present (lines said) --------------------------- * mburned (67) * rbowen (56) * kashyap (29) * zodbot (6) * red_trela (4) * morazi (3) * flaper87 (2) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrist at redhat.com Tue Mar 11 13:50:07 2014 From: jrist at redhat.com (Jason Rist) Date: Tue, 11 Mar 2014 07:50:07 -0600 Subject: [Rdo-list] [OFI] Members list In-Reply-To: <531EFC86.6040507@redhat.com> References: <530DB43B.1010306@redhat.com> <20140226122031.GB2952@redhat.com> <531EFC86.6040507@redhat.com> Message-ID: <531F148F.2080209@redhat.com> On 03/11/2014 06:07 AM, Petr Chalupa wrote: > Hi guys, > > please fill your row in members table at > http://projects.theforeman.org/projects/ofi/wiki/Members. There are > still 4 people missing. > > Thanks, Petr > > On 26.02.14 13:20, Hugh O. Brock wrote: >> On Wed, Feb 26, 2014 at 10:30:35AM +0100, Petr Chalupa wrote: >>> Hi, >>> >>> I've added table of the all members to our wiki at >>> http://projects.theforeman.org/projects/ofi/wiki/Members. I think >>> it'll quite useful to have basic information (as name, irc, >>> timezone, component) at one place. Please fill in your details. >>> >>> Petr >>> >>> _______________________________________________ >>> Rdo-list mailing list >>> Rdo-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list >> >> Thanks Petr, great idea. >> >> --Hugh >> > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list Also keep in mind Daylight Savings Time. -J -- Jason E. Rist Senior Software Engineer OpenStack Management UI Red Hat, Inc. +1.720.256.3933 Freenode: jrist github/identi.ca: knowncitizen From rdo-info at redhat.com Tue Mar 11 15:18:24 2014 From: rdo-info at redhat.com (RDO Forum) Date: Tue, 11 Mar 2014 15:18:24 +0000 Subject: [Rdo-list] [RDO] Podcast: Ohad Levy on RDO and the Foreman Message-ID: <00000144b1b9244c-098b252d-679a-4c23-b9bd-c7e7386a6dbd-000000@email.amazonses.com> rbowen started a discussion. Podcast: Ohad Levy on RDO and the Foreman --- Follow the link below to check it out: http://openstack.redhat.com/forum/discussion/969/podcast-ohad-levy-on-rdo-and-the-foreman Have a great day! From jeckersb at redhat.com Tue Mar 11 18:46:40 2014 From: jeckersb at redhat.com (John Eckersberg) Date: Tue, 11 Mar 2014 14:46:40 -0400 Subject: [Rdo-list] RabbitMQ via Packstack instructions Message-ID: <878usga7zj.fsf@redhat.com> I've updated the RDO wiki[1] with the latest instructions to install with rabbitmq messaging using packstack. Right now it uses packstack from source. Once the rabbitmq bits land in the RDO repo I'll update the instructions to reflect it. [1] http://openstack.redhat.com/RabbitMQ From rbowen at rcbowen.com Tue Mar 11 19:24:44 2014 From: rbowen at rcbowen.com (Rich Bowen) Date: Tue, 11 Mar 2014 15:24:44 -0400 Subject: [Rdo-list] Reminder: RDO Test Day March 19-20 Message-ID: <531F62FC.1070503@rcbowen.com> A reminder: We'll be doing an RDO test day for the Icehouse Milestone 3, next week, March 19-20. This time around we're using the Fedora Test Day infrastructure, to make it easier to report your test results. Details about the test day are in the RDO wiki at http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_3 The test cases that you'll want to run are listed at http://testdays.qa.fedoraproject.org/testdays/show_event?event_id=16 and that's also the interface where you'll enter your test results as you go. If you'd like to help augment the list of tests, and the instructions that go with them, those can be edited at https://fedoraproject.org/wiki/Test_Day:2014-03-19_RDOMetadata or you can send updated directly to me. If you'd like to help get the word out via Twitter, Facebook, Google+ or whatever, you'll probably want to use the first of those three URLs. You could, for example, tweet: Join us to help test the @RDOCommunity packaging of the @OpenStack Icehouse Milestone 3, March 19 and 20 - http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_3 (Thanks for helping us get the word out.) -- Rich Bowen - rbowen at rcbowen.com - @rbowen http://apachecon.com/ - @apachecon From pmyers at redhat.com Wed Mar 12 13:28:12 2014 From: pmyers at redhat.com (Perry Myers) Date: Wed, 12 Mar 2014 09:28:12 -0400 Subject: [Rdo-list] RabbitMQ via Packstack instructions In-Reply-To: <878usga7zj.fsf@redhat.com> References: <878usga7zj.fsf@redhat.com> Message-ID: <532060EC.1030400@redhat.com> On 03/11/2014 02:46 PM, John Eckersberg wrote: > I've updated the RDO wiki[1] with the latest instructions to install > with rabbitmq messaging using packstack. Right now it uses packstack > from source. Once the rabbitmq bits land in the RDO repo I'll update > the instructions to reflect it. > > [1] http://openstack.redhat.com/RabbitMQ When will the new version of Packstack hit Havana and Icehouse RDO repos? From mmagr at redhat.com Wed Mar 12 13:35:05 2014 From: mmagr at redhat.com (Martin Magr) Date: Wed, 12 Mar 2014 14:35:05 +0100 Subject: [Rdo-list] RabbitMQ via Packstack instructions In-Reply-To: <532060EC.1030400@redhat.com> References: <878usga7zj.fsf@redhat.com> <532060EC.1030400@redhat.com> Message-ID: <53206289.2050602@redhat.com> On 03/12/2014 02:28 PM, Perry Myers wrote: > On 03/11/2014 02:46 PM, John Eckersberg wrote: >> I've updated the RDO wiki[1] with the latest instructions to install >> with rabbitmq messaging using packstack. Right now it uses packstack >> from source. Once the rabbitmq bits land in the RDO repo I'll update >> the instructions to reflect it. >> >> [1] http://openstack.redhat.com/RabbitMQ > When will the new version of Packstack hit Havana and Icehouse RDO repos? Hi Perry, RabbitMQ patch is merged in master branch, so if it is required, I can create Icehouse build tomorrow. For Havana the patch needs to be backported first (CC'ed Ivan). Regards, Martin -- Martin M?gr Openstack Red Hat Czech cell: +420-775-291-585 irc: mmagr @ #brno, #cloud, #rhos-dev, #rhos-users From pchalupa at redhat.com Wed Mar 12 14:26:27 2014 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 12 Mar 2014 15:26:27 +0100 Subject: [Rdo-list] [OFI] ER diagram Message-ID: <53206E93.5090709@redhat.com> Hi, I wanted to understand the current model better so I've generated ER diagram from Scott's PR https://github.com/theforeman/staypuft/pull/12. see http://projects.theforeman.org/projects/ofi/wiki/DB_Model How to: add `gem 'rails-erd'` and execute `rake erd only='Staypuft::Deployment,Staypuft::DeploymentHostgroup,Staypuft::HostgroupRole,Staypuft::Layout,Staypuft::LayoutRole,Staypuft::Role,Staypuft::RoleClass,Staypuft::RoleService,Staypuft::Service,Staypuft::ServiceClass,Hostgroup,Puppetclass' attributes='foreign_keys,content' orientation=vertical filetype=dot` then `dot -Tsvg erd.dot > erd.svg` Petr From kchamart at redhat.com Wed Mar 12 14:36:10 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Wed, 12 Mar 2014 20:06:10 +0530 Subject: [Rdo-list] Current state of RDO bugs Message-ID: <20140312143610.GA6574@tesla.pnq.redhat.com> Heya, I was just doing some RDO bug scrub, and as of writing this here's the current state of affairs: - NEW, ASSIGNED, or ON_DEV : 138 bugs - MODFIEID, POST, or ON_QA : 91 bugs - VERIFIED : 4 bugs Here's[1] all the bugs, plain text formatted. That's the script I used[2]. On a related note, next community bug triage is on upcoming Wednesday (19-MAR-2014), if you have some spare cycles, please join us on #rdo. [1] http://kashyapc.fedorapeople.org/virt/openstack/bugzilla/rdo-bug-status/all-rdo-bugs-12-03-2014.txt [2] http://kashyapc.fedorapeople.org/virt/openstack/bugzilla/query-all-rdo-bugs.bash -- /kashyap From sgordon at redhat.com Wed Mar 12 14:41:17 2014 From: sgordon at redhat.com (Steve Gordon) Date: Wed, 12 Mar 2014 10:41:17 -0400 (EDT) Subject: [Rdo-list] RDO Forum OpenID In-Reply-To: <897145236.33674511.1394635218978.JavaMail.zimbra@redhat.com> Message-ID: <926416416.33675734.1394635277996.JavaMail.zimbra@redhat.com> Hi all, I haven't been able to access the RDO forum using my Google ID for quite some time, when I click the button on http://openstack.redhat.com/forum/entry/signin?Target=http://openstack.redhat.com/Main_Page I get this: Provider is required. UniqueID is required. The connection data has not been verified. Is this a known issue or am I just special? Thanks, Steve From rbowen at redhat.com Wed Mar 12 15:07:18 2014 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 12 Mar 2014 11:07:18 -0400 Subject: [Rdo-list] RDO Forum OpenID In-Reply-To: <926416416.33675734.1394635277996.JavaMail.zimbra@redhat.com> References: <926416416.33675734.1394635277996.JavaMail.zimbra@redhat.com> Message-ID: <53207826.7040707@redhat.com> On 03/12/2014 10:41 AM, Steve Gordon wrote: > Hi all, > > I haven't been able to access the RDO forum using my Google ID for quite some time, when I click the button on http://openstack.redhat.com/forum/entry/signin?Target=http://openstack.redhat.com/Main_Page I get this: > > Provider is required. > UniqueID is required. > The connection data has not been verified. > > Is this a known issue or am I just special? oAuth authentication is indeed broken. There's a patch available, which, when applied, makes the entire site throw 500 errors. I'm trying to get to the bottom of of this so that we can fix it permanently. -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From mhulan at redhat.com Wed Mar 12 15:58:06 2014 From: mhulan at redhat.com (Marek Hulan) Date: Wed, 12 Mar 2014 16:58:06 +0100 Subject: [Rdo-list] [OFI] Initial foreman provisioning setup design Message-ID: <1414912.Vq1H7BWHan@edna> Hello I uploaded the design of two ways how can we setup provisioning in foreman. I think we are deciding between option A and B, others are just not to forget them. Me and Dan prefer option A but I'd like to hear your opinions. You can read the design here [1]. Let me know if anything is unclear. [1] https://github.com/ares/OFI/blob/install_design/doc/staypuft_foreman_init.md -- Marek From ichavero at redhat.com Thu Mar 13 03:24:35 2014 From: ichavero at redhat.com (Ivan Chavero) Date: Wed, 12 Mar 2014 23:24:35 -0400 (EDT) Subject: [Rdo-list] RabbitMQ via Packstack instructions In-Reply-To: <53206289.2050602@redhat.com> References: <878usga7zj.fsf@redhat.com> <532060EC.1030400@redhat.com> <53206289.2050602@redhat.com> Message-ID: <1291757530.14368053.1394681075848.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Martin Magr" > To: "Perry Myers" > Cc: "John Eckersberg" , rdo-list at redhat.com, "Alvaro Ortega" , "Ivan > Chavero" > Sent: Wednesday, March 12, 2014 6:35:05 AM > Subject: Re: [Rdo-list] RabbitMQ via Packstack instructions > > On 03/12/2014 02:28 PM, Perry Myers wrote: > > On 03/11/2014 02:46 PM, John Eckersberg wrote: > >> I've updated the RDO wiki[1] with the latest instructions to install > >> with rabbitmq messaging using packstack. Right now it uses packstack > >> from source. Once the rabbitmq bits land in the RDO repo I'll update > >> the instructions to reflect it. > >> > >> [1] http://openstack.redhat.com/RabbitMQ I've read the wiki and if you're doing an allinone install you can also set the amqp server from the command line like this: packstack --allinone --amqp-server=rabbitmq --use-epel=y i've added this to the wiki, hope it helps. > > When will the new version of Packstack hit Havana and Icehouse RDO repos? > Hi Perry, > > RabbitMQ patch is merged in master branch, so if it is required, I can > create Icehouse build tomorrow. For Havana the patch needs to be > backported first (CC'ed Ivan). > > Regards, > Martin > > -- > > Martin M?gr > Openstack > Red Hat Czech > > cell: +420-775-291-585 > irc: mmagr @ #brno, #cloud, #rhos-dev, #rhos-users > > From pchalupa at redhat.com Thu Mar 13 15:42:54 2014 From: pchalupa at redhat.com (Petr Chalupa) Date: Thu, 13 Mar 2014 16:42:54 +0100 Subject: [Rdo-list] [OFI] Orchestration - proof of concept in PR Message-ID: <5321D1FE.1040305@redhat.com> Hi, I've opened PR "Orchestration of OpenStack deployment POC" at https://github.com/theforeman/staypuft/pull/18 today containing working Proof of concept of OpenStack deployment orchestration. More information can be found in https://github.com/pitr-ch/OFI/blob/orchestration/doc/orchestration.md Please check the Assumptions section (https://github.com/pitr-ch/OFI/blob/orchestration/doc/orchestration.md#assumptions) that there are no problems there. I'll appreciate your feedback, please comment in the PR. Attaching some images showing the progress in current ForemanTasks's task-list and dynflow console. Petr -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-03-13 at 16.24.15.png Type: image/png Size: 104227 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-03-13 at 16.39.52.png Type: image/png Size: 61731 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-03-13 at 16.39.58.png Type: image/png Size: 57726 bytes Desc: not available URL: From xzhao at bnl.gov Thu Mar 13 19:24:05 2014 From: xzhao at bnl.gov (Xin Zhao) Date: Thu, 13 Mar 2014 15:24:05 -0400 Subject: [Rdo-list] can't access quantum API from network host Message-ID: <532205D5.7060405@bnl.gov> Hello, I am re-installing a multi-host grizzly cluster, using quantum/OVS. One thing strange is that quantum commands, like "quantum net-list", fail to run on the network host, returned "403 Forbidden" error message. But using the same admin credential, the quantum commands work from the controller node. It used to work before, with my previous install. Should I be worried about it ? Any suggestions on where to start to debug this? Thanks, Xin From lars at redhat.com Thu Mar 13 21:49:19 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Thu, 13 Mar 2014 17:49:19 -0400 Subject: [Rdo-list] can't access quantum API from network host In-Reply-To: <532205D5.7060405@bnl.gov> References: <532205D5.7060405@bnl.gov> Message-ID: <20140313214919.GF11426@redhat.com> On Thu, Mar 13, 2014 at 03:24:05PM -0400, Xin Zhao wrote: > One thing strange is that quantum commands, like "quantum net-list", fail to > run on the network host, returned "403 Forbidden" error message. But using > the same admin credential, the quantum commands work from the controller > node. Are you certain the you're using the same credentialson the network host? I would start by comparing all the OS_ environments in your environment on the controller with those on your network host (not just the username/password, but also the value of OS_AUTH_URL). You could watch both /var/log/neutron/server.log and /var/log/keystone/keystone.log to see if there are any corresponding errors that shed light on the problem. You can run the client with --debug to make sure it's talking to what you think it's talking to. -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From xzhao at bnl.gov Thu Mar 13 22:37:14 2014 From: xzhao at bnl.gov (Xin Zhao) Date: Thu, 13 Mar 2014 18:37:14 -0400 Subject: [Rdo-list] can't access quantum API from network host In-Reply-To: <20140313214919.GF11426@redhat.com> References: <532205D5.7060405@bnl.gov> <20140313214919.GF11426@redhat.com> Message-ID: <5322331A.1090801@bnl.gov> On 3/13/2014 5:49 PM, Lars Kellogg-Stedman wrote: > On Thu, Mar 13, 2014 at 03:24:05PM -0400, Xin Zhao wrote: >> One thing strange is that quantum commands, like "quantum net-list", fail to >> run on the network host, returned "403 Forbidden" error message. But using >> the same admin credential, the quantum commands work from the controller >> node. > Are you certain the you're using the same credentialson the network > host? I would start by comparing all the OS_ environments in your > environment on the controller with those on your network host (not > just the username/password, but also the value of OS_AUTH_URL). > > You could watch both /var/log/neutron/server.log and > /var/log/keystone/keystone.log to see if there are any corresponding > errors that shed light on the problem. > > You can run the client with --debug to make sure it's talking to what > you think it's talking to. > The debug option (-v) does help, there is a proxy in the middle that blocked the curl command to the controller from the network host. Now it works. Thanks! Xin From inecas at redhat.com Fri Mar 14 10:36:33 2014 From: inecas at redhat.com (Ivan Necas) Date: Fri, 14 Mar 2014 06:36:33 -0400 (EDT) Subject: [Rdo-list] [foreman-dev] [OFI] Orchestration - proof of concept in PR In-Reply-To: <5321D1FE.1040305@redhat.com> References: <5321D1FE.1040305@redhat.com> Message-ID: <1321047129.4015391.1394793393257.JavaMail.zimbra@redhat.com> Awesome! -- Ivan ----- Original Message ----- > Hi, > > I've opened PR "Orchestration of OpenStack deployment POC" at > https://github.com/theforeman/staypuft/pull/18 today containing working > Proof of concept of OpenStack deployment orchestration. > > More information can be found in > https://github.com/pitr-ch/OFI/blob/orchestration/doc/orchestration.md > > Please check the Assumptions section > (https://github.com/pitr-ch/OFI/blob/orchestration/doc/orchestration.md#assumptions) > that there are no problems there. > > I'll appreciate your feedback, please comment in the PR. > > Attaching some images showing the progress in current ForemanTasks's > task-list and dynflow console. > > Petr > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > From ak at cloudssky.com Fri Mar 14 18:09:14 2014 From: ak at cloudssky.com (Arash Kaffamanesh) Date: Fri, 14 Mar 2014 19:09:14 +0100 Subject: [Rdo-list] [foreman-dev] [OFI] Orchestration - proof of concept in PR In-Reply-To: <1321047129.4015391.1394793393257.JavaMail.zimbra@redhat.com> References: <5321D1FE.1040305@redhat.com> <1321047129.4015391.1394793393257.JavaMail.zimbra@redhat.com> Message-ID: Ivan, I don't agree, it's "More Than Awesome"! Many thanks to Petr and the whole foreman dev group for such a great work! Best, Arash On Fri, Mar 14, 2014 at 11:36 AM, Ivan Necas wrote: > Awesome! > > -- Ivan > > ----- Original Message ----- > > Hi, > > > > I've opened PR "Orchestration of OpenStack deployment POC" at > > https://github.com/theforeman/staypuft/pull/18 today containing working > > Proof of concept of OpenStack deployment orchestration. > > > > More information can be found in > > https://github.com/pitr-ch/OFI/blob/orchestration/doc/orchestration.md > > > > Please check the Assumptions section > > ( > https://github.com/pitr-ch/OFI/blob/orchestration/doc/orchestration.md#assumptions > ) > > that there are no problems there. > > > > I'll appreciate your feedback, please comment in the PR. > > > > Attaching some images showing the progress in current ForemanTasks's > > task-list and dynflow console. > > > > Petr > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe at googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at andrewklau.com Sun Mar 16 12:02:25 2014 From: andrew at andrewklau.com (Andrew Lau) Date: Sun, 16 Mar 2014 23:02:25 +1100 Subject: [Rdo-list] Installing RDO w/ Foreman + icehouse and ml2 plugin Message-ID: Hi all, So far, I've been successful with the following setup on havana, but icehouse had issue as below: 1x Controller 2x Compute + Network + Gluster I forked the astapor repo so I can run the compute + networker in the same module, along with a few other tweaks. [1] So far everything is working, I plan on uploading my notes in a few days but I've run into a few issues which I'm hoping someone could help: - When using the icehouse repo, the controller hostgroup will install but httpd will fail with 'no listening sockets available, shutting down, Unable to open logs'. There were no selinux denies, or anything else in the log files. - From a brief look at the manifest and trial and error, it looks like the ml2 plugin does have some support in the quickstack files. It however fails at the neutron-db-manage. Manual steps: [2] Error Output: [3] I'm aware there's a few new projects going on to bridge the foreman and rdo integration, I like the current foreman setup because it's very customizable, but the key flaws are too many options. ie. if I'm using VLANs, I don't want to see tunnel options etc. Thanks, Andrew. [1] https://github.com/andrewklau/astapor [2] http://openstack.redhat.com/ML2_plugin [3] http://www.fpaste.org/85834/94970823/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From morazi at redhat.com Sun Mar 16 15:53:34 2014 From: morazi at redhat.com (Mike Orazi) Date: Sun, 16 Mar 2014 11:53:34 -0400 Subject: [Rdo-list] Installing RDO w/ Foreman + icehouse and ml2 plugin In-Reply-To: References: Message-ID: <5325C8FE.5080303@redhat.com> Andrew, See a few comments inline below, but first thanks for giving the foreman installer a shot. It looks like you have had a good amount of success and made some good discoveries along the way! I really appreciate the fact that you have gotten so far & the feedback on areas where you are running into issues. Thanks, Mike On 03/16/2014 08:02 AM, Andrew Lau wrote: > Hi all, > > So far, I've been successful with the following setup on havana, but > icehouse had issue as below: > 1x Controller > 2x Compute + Network + Gluster > > I forked the astapor repo so I can run the compute + networker in the > same module, along with a few other tweaks. [1] > Nice -- this is one variation that a lot of people seem interested in. We'd probably have to give some thought on how to fold things together but I bet it would be a good candidate for further discussion and potential inclusion at some point in the future. > So far everything is working, I plan on uploading my notes in a few days > but I've run into a few issues which I'm hoping someone could help: > > - When using the icehouse repo, the controller hostgroup will install > but httpd will fail with 'no listening sockets available, shutting down, > Unable to open logs'. There were no selinux denies, or anything else in > the log files. > > - >From a brief look at the manifest and trial and error, it looks like > the ml2 plugin does have some support in the quickstack files. It > however fails at the neutron-db-manage. Manual steps: [2] > Error Output: [3] The team has been working to track down the remaining issues in neutron-db-manage. John Eckersberg (added to the message to make sure he sees this) is eck or jeckersb on irc and is likely a good person to coordinate with in terms of the foreman side of the equation. He has been working with some neutron folks to try to run this down. > > I'm aware there's a few new projects going on to bridge the foreman and > rdo integration, I like the current foreman setup because it's very > customizable, but the key flaws are too many options. ie. if I'm using > VLANs, I don't want to see tunnel options etc. > Yes! A lot of the present work can be broken down into 2 bits. The quickstack work proper to make several reasonably easy to deploy cloud examples + a good amount of usability work that is presently just getting started to help weave things together a lot more elegantly for end-user consumption. A lot of the "I'm using VLAN please don't bother showing me params that apply only to tunnel solutions" falls into that latter set of work. > Thanks, > Andrew. > > [1] https://github.com/andrewklau/astapor > [2] http://openstack.redhat.com/ML2_plugin > [3] http://www.fpaste.org/85834/94970823/ > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > From andrew at andrewklau.com Mon Mar 17 10:19:19 2014 From: andrew at andrewklau.com (Andrew Lau) Date: Mon, 17 Mar 2014 21:19:19 +1100 Subject: [Rdo-list] Installing RDO w/ Foreman + icehouse and ml2 plugin In-Reply-To: <5325C8FE.5080303@redhat.com> References: <5325C8FE.5080303@redhat.com> Message-ID: Hi Mike, A few extra discoveries and notes, both icehouse and havana aren't including the admin_hosts override after the install. I need to re-import the puppet classes, override the admin_hosts variable in the controller/compute sections and then update the variable in the hostgroup settings. I'm confused, why this is used if there's already priv and pub host. Further notes inline. On Mon, Mar 17, 2014 at 2:53 AM, Mike Orazi wrote: > Andrew, > > See a few comments inline below, but first thanks for giving the foreman > installer a shot. It looks like you have had a good amount of success > and made some good discoveries along the way! > > I really appreciate the fact that you have gotten so far & the feedback > on areas where you are running into issues. > > Thanks, > Mike > > > > On 03/16/2014 08:02 AM, Andrew Lau wrote: > > Hi all, > > > > So far, I've been successful with the following setup on havana, but > > icehouse had issue as below: > > 1x Controller > > 2x Compute + Network + Gluster > > > > I forked the astapor repo so I can run the compute + networker in the > > same module, along with a few other tweaks. [1] > > > > Nice -- this is one variation that a lot of people seem interested in. > We'd probably have to give some thought on how to fold things together > but I bet it would be a good candidate for further discussion and > potential inclusion at some point in the future. > It would be a nice concept if the modules could be integrated as nested hostgroups, it would just be a matter of having to some how remove the duplicate class calls when they get nested. > > > So far everything is working, I plan on uploading my notes in a few days > > but I've run into a few issues which I'm hoping someone could help: > > > > - When using the icehouse repo, the controller hostgroup will install > > but httpd will fail with 'no listening sockets available, shutting down, > > Unable to open logs'. There were no selinux denies, or anything else in > > the log files. > The "Listen 0.0.0.0:80" in /etc/http/conf/httpd.conf some how does not get added, I noticed in the havana modules, it would keep removing and adding this. I recall seeing somewhere this related to puppetlabs/apache. So havana it works, icehouse no.. > > > > - >From a brief look at the manifest and trial and error, it looks like > > the ml2 plugin does have some support in the quickstack files. It > > however fails at the neutron-db-manage. Manual steps: [2] > > Error Output: [3] > > The team has been working to track down the remaining issues in > neutron-db-manage. John Eckersberg (added to the message to make sure > he sees this) is eck or jeckersb on irc and is likely a good person to > coordinate with in terms of the foreman side of the equation. He has > been working with some neutron folks to try to run this down. > I look forward to hearing from him. > > > > > I'm aware there's a few new projects going on to bridge the foreman and > > rdo integration, I like the current foreman setup because it's very > > customizable, but the key flaws are too many options. ie. if I'm using > > VLANs, I don't want to see tunnel options etc. > > > > Yes! A lot of the present work can be broken down into 2 bits. The > quickstack work proper to make several reasonably easy to deploy cloud > examples + a good amount of usability work that is presently just > getting started to help weave things together a lot more elegantly for > end-user consumption. A lot of the "I'm using VLAN please don't bother > showing me params that apply only to tunnel solutions" falls into that > latter set of work. > > > > Thanks, > > Andrew. > > > > [1] https://github.com/andrewklau/astapor > > [2] http://openstack.redhat.com/ML2_plugin > > [3] http://www.fpaste.org/85834/94970823/ > > > > > > > > _______________________________________________ > > Rdo-list mailing list > > Rdo-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Yogesh.Bhanu at consol.de Mon Mar 17 12:17:45 2014 From: Yogesh.Bhanu at consol.de (Yogesh Bhanu) Date: Mon, 17 Mar 2014 13:17:45 +0100 Subject: [Rdo-list] neutron Flatnetwork config with two nics port status is always down Message-ID: <5326E7E9.4030609@consol.de> Hi , I have a two node setup with two nics: eth0 -- Intranet - br-ex eth1 -- Management - br-int Node1 acts as: Controller Network Storage Compute Node2 acts as: Compute I have followed the guidelines of using packstack with vlan and modifying /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini to: [OVS] tenant_network_type=none enable_tunneling=False integration_bridge=br-int network_vlan_ranges = physnet1 bridge_mappings = physnet1:br-ex vxlan_udp_port=4789 - restart the neutron-server service - define a network/subnet neutron net-create vm-ext --shared --provider:network_type flat --provider:physical_network physnet1 neutron subnet-create --name vm-ext-intra --gateway 192.168.10.1 --dns-nameserver 192.168.10.0 --allocation-pool start=192.168.10.231,end=192.168.10.249 vm-ext 192.168.10.0/24 neutron subnet-update vm-ext-intra --enable_dhcp False - I can start a VM instance but I'm not able to access the VMs from my Intranet. - IP gets associated with the VM but the port status is alwaysdown Question: Is it possible to set the port status Up and if yes How? neutron port-show 824fc086-841d-48af-906b-ceeb3ea83510 +-----------------------+-----------------------------------------------------------------------------------+ | Field | Value | +-----------------------+-----------------------------------------------------------------------------------+ | admin_state_up | True | | allowed_address_pairs | | | binding:capabilities | {"port_filter": true} | | binding:host_id | rhc02 | | binding:vif_type | ovs | | device_id | 08ebc2b6-1500-4140-82e2-4acec52e4cac | | device_owner | compute:None | | extra_dhcp_opts | | | fixed_ips | {"subnet_id": "2f45cc95-05d8-4d8e-bb0a-e21884a9df2a", "ip_address": "192.168.10.231"} | | id | 824fc086-841d-48af-906b-ceeb3ea83510 | | mac_address | fa:16:3e:a2:a2:05 | | name | | | network_id | 2a981f3a-2df1-4d53-bfcb-4750902400ca | | security_groups | fa6850a7-cf87-447e-b83d-1f99b9eef94a | | status | DOWN | | tenant_id | c620b9e73cd24d52b1a0c4b9803d056f | +-----------------------+-----------------------------------------------------------------------------------+ Thanks in advance From kchamart at redhat.com Mon Mar 17 14:29:55 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Mon, 17 Mar 2014 19:59:55 +0530 Subject: [Rdo-list] Etherpad for RDO test day (19,20-MAR-2014) Message-ID: <20140317142955.GB1070@tesla.pnq.redhat.com> Heya, Here's[1] an etherpad where I'm trying to capture ad-hoc notes/known-issues/bugs for the upcoming test days. We can turn this into a wiki-page probably if there are enough number of issues. Currently it has a section on how to capture Neutron debug information. NOTE: If you've added a lot of content, don't forget to save a revision (the star mark). [1] https://etherpad.openstack.org/p/rdo_test_day_mar_2014 -- /kashyap From xzhao at bnl.gov Mon Mar 17 19:09:49 2014 From: xzhao at bnl.gov (Xin Zhao) Date: Mon, 17 Mar 2014 15:09:49 -0400 Subject: [Rdo-list] metadata service issue Message-ID: <5327487D.7040001@bnl.gov> Hello, On my newly installed grizzly testbed, which has one controller, one network host (quantum/ovs) and one compute node, there is an issue with metadata service: From the instance, its routing table looks like this: [root at host-172-16-0-8 ~]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 172.16.0.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0 0.0.0.0 172.16.0.1 0.0.0.0 UG 0 0 0 eth0 And metadata service is not reachable, the curl command complains about "no route to 169.254.169.254". After deleting the 169.254.0.0/16 entry from the routing table, the metadata service works. Why would quantum append the 169.254.0.0 route into the routing table of the VM instance ? I have enable_isolated_metadata set to False in the dhcp_agent.ini. Thanks, Xin From jeckersb at redhat.com Mon Mar 17 19:00:31 2014 From: jeckersb at redhat.com (John Eckersberg) Date: Mon, 17 Mar 2014 15:00:31 -0400 Subject: [Rdo-list] Installing RDO w/ Foreman + icehouse and ml2 plugin In-Reply-To: References: Message-ID: <877g7smz00.fsf@redhat.com> Andrew Lau writes: > - From a brief look at the manifest and trial and error, it looks like the > ml2 plugin does have some support in the quickstack files. It however fails > at the neutron-db-manage. Manual steps: [2] > Error Output: [3] > > [1] https://github.com/andrewklau/astapor > [2] http://openstack.redhat.com/ML2_plugin > [3] http://www.fpaste.org/85834/94970823/ I haven't tried Foreman+ML2 on Icehouse yet, but I've seen several weird database issues caused by tables using the myisam engine instead of innodb. A quick workaround to try is... cat < /etc/mysql/conf.d/innodb.cnf [mysqld] default-storage-engine = innodb EOF service mysqld restart mysql -e 'drop database neutron; create database neutron;' Then rerun neutron-db-manage. That'll default all the tables to use innodb. The 1000 byte key length limit is a constraint of MyISAM. InnoDB has a similar constraint but it appears more generous. How many bytes a field actually takes up in the key length seems to depend on the encoding and maybe some other stuff that I'm not sure offhand. However this test shows switching engines very well may fix that particular error: mysql> create table test (field1 VARCHAR(512) NOT NULL, field2 VARCHAR(512) NOT NULL, PRIMARY KEY(field1, field2)) ENGINE=MyISAM; ERROR 1071 (42000): Specified key was too long; max key length is 1000 bytes mysql> create table test (field1 VARCHAR(512) NOT NULL, field2 VARCHAR(512) NOT NULL, PRIMARY KEY(field1, field2)) ENGINE=InnoDB; Query OK, 0 rows affected (0.04 sec) Hope that helps, John From lars at redhat.com Mon Mar 17 20:23:59 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Mon, 17 Mar 2014 16:23:59 -0400 Subject: [Rdo-list] metadata service issue In-Reply-To: <5327487D.7040001@bnl.gov> References: <5327487D.7040001@bnl.gov> Message-ID: <20140317202359.GA16006@redhat.com> On Mon, Mar 17, 2014 at 03:09:49PM -0400, Xin Zhao wrote: > After deleting the 169.254.0.0/16 entry from the routing table, the metadata > service works. > > Why would quantum append the 169.254.0.0 route into the routing table of the > VM instance ? I have enable_isolated_metadata set to False in the > dhcp_agent.ini. Odds are that quantum is not responsible for this route. It is common for some operating systems to add this route by default in order to permit access to "zeroconf" addresses (https://en.wikipedia.org/wiki/Zero-configuration_networking#Address_selection). On RedHat-ish distributions, you can ensure that your interface configuration files contain: NOZEROCONF=yes This is best placed into /etc/sysconfig/network. I'm not sure what the equivalent process looks like for Ubuntu. -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From sgordon at redhat.com Mon Mar 17 22:37:17 2014 From: sgordon at redhat.com (Steve Gordon) Date: Mon, 17 Mar 2014 18:37:17 -0400 (EDT) Subject: [Rdo-list] Reminder: RDO Test Day March 19-20 In-Reply-To: <531F62FC.1070503@rcbowen.com> References: <531F62FC.1070503@rcbowen.com> Message-ID: <983076500.1568268.1395095837025.JavaMail.zimbra@redhat.com> ----- Original Message ----- > A reminder: We'll be doing an RDO test day for the Icehouse Milestone 3, > next week, March 19-20. > > This time around we're using the Fedora Test Day infrastructure, to make > it easier to report your test results. > > Details about the test day are in the RDO wiki at > http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_3 When can we expect to see M-3 packages starting to hit the repository if we want to try and catch any show stoppers that might negatively impact the value of test day? Thanks, Steve From andrew at andrewklau.com Mon Mar 17 23:41:22 2014 From: andrew at andrewklau.com (Andrew Lau) Date: Tue, 18 Mar 2014 10:41:22 +1100 Subject: [Rdo-list] Installing RDO w/ Foreman + icehouse and ml2 plugin In-Reply-To: <877g7smz00.fsf@redhat.com> References: <877g7smz00.fsf@redhat.com> Message-ID: On Tue, Mar 18, 2014 at 6:00 AM, John Eckersberg wrote: > Andrew Lau writes: > > - From a brief look at the manifest and trial and error, it looks like > the > > ml2 plugin does have some support in the quickstack files. It however > fails > > at the neutron-db-manage. Manual steps: [2] > > Error Output: [3] > > > > [1] https://github.com/andrewklau/astapor > > [2] http://openstack.redhat.com/ML2_plugin > > [3] http://www.fpaste.org/85834/94970823/ > > I haven't tried Foreman+ML2 on Icehouse yet, but I've seen several weird > database issues caused by tables using the myisam engine instead of > innodb. A quick workaround to try is... > > cat < /etc/mysql/conf.d/innodb.cnf > [mysqld] > default-storage-engine = innodb > EOF > > service mysqld restart > > mysql -e 'drop database neutron; create database neutron;' > > Then rerun neutron-db-manage. That'll default all the tables to use > innodb. > > The 1000 byte key length limit is a constraint of MyISAM. InnoDB has a > similar constraint but it appears more generous. How many bytes a field > actually takes up in the key length seems to depend on the encoding and > maybe some other stuff that I'm not sure offhand. However this test > shows switching engines very well may fix that particular error: > > mysql> create table test (field1 VARCHAR(512) NOT NULL, field2 > VARCHAR(512) NOT NULL, PRIMARY KEY(field1, field2)) ENGINE=MyISAM; > ERROR 1071 (42000): Specified key was too long; max key length is 1000 > bytes > mysql> create table test (field1 VARCHAR(512) NOT NULL, field2 > VARCHAR(512) NOT NULL, PRIMARY KEY(field1, field2)) ENGINE=InnoDB; > Query OK, 0 rows affected (0.04 sec) > > Hi John, Thanks for that suggestion, it got me passed that first step and into another error :D sqlalchemy.exc.ProgrammingError: (ProgrammingError) (1146, "Table 'neutron_ml2.agents' doesn't exist") 'ALTER TABLE agents ADD CONSTRAINT uniq_agents0agent_type0host UNIQUE (agent_type, host)' () Which seems to be very similar to this BZ here: https://bugzilla.redhat.com/show_bug.cgi?id=1061378 Cheers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeckersb at redhat.com Tue Mar 18 01:58:23 2014 From: jeckersb at redhat.com (John Eckersberg) Date: Mon, 17 Mar 2014 21:58:23 -0400 Subject: [Rdo-list] Installing RDO w/ Foreman + icehouse and ml2 plugin In-Reply-To: References: <877g7smz00.fsf@redhat.com> Message-ID: <871ty0mfnk.fsf@redhat.com> Andrew Lau writes: > Hi John, > > Thanks for that suggestion, it got me passed that first step and into > another error :D > sqlalchemy.exc.ProgrammingError: (ProgrammingError) (1146, "Table > 'neutron_ml2.agents' doesn't exist") 'ALTER TABLE agents ADD CONSTRAINT > uniq_agents0agent_type0host UNIQUE (agent_type, host)' () > > Which seems to be very similar to this BZ here: > https://bugzilla.redhat.com/show_bug.cgi?id=1061378 Yep, I ran across that today as well. https://bugzilla.redhat.com/show_bug.cgi?id=1017281#c30 That one-line patch fixes the agents table. John From andrew at andrewklau.com Tue Mar 18 02:07:57 2014 From: andrew at andrewklau.com (Andrew Lau) Date: Tue, 18 Mar 2014 13:07:57 +1100 Subject: [Rdo-list] Installing RDO w/ Foreman + icehouse and ml2 plugin In-Reply-To: <871ty0mfnk.fsf@redhat.com> References: <877g7smz00.fsf@redhat.com> <871ty0mfnk.fsf@redhat.com> Message-ID: On Tue, Mar 18, 2014 at 12:58 PM, John Eckersberg wrote: > Andrew Lau writes: > > Hi John, > > > > Thanks for that suggestion, it got me passed that first step and into > > another error :D > > sqlalchemy.exc.ProgrammingError: (ProgrammingError) (1146, "Table > > 'neutron_ml2.agents' doesn't exist") 'ALTER TABLE agents ADD CONSTRAINT > > uniq_agents0agent_type0host UNIQUE (agent_type, host)' () > > > > Which seems to be very similar to this BZ here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1061378 > > Yep, I ran across that today as well. > > https://bugzilla.redhat.com/show_bug.cgi?id=1017281#c30 > > That one-line patch fixes the agents table. > > That came up in my search, but I wasn't sure how to apply that patch. Do you know if it made it into the new test day build? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kchamart at redhat.com Tue Mar 18 12:37:44 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Tue, 18 Mar 2014 18:07:44 +0530 Subject: [Rdo-list] Reminder: RDO Test Day March 19-20 In-Reply-To: <983076500.1568268.1395095837025.JavaMail.zimbra@redhat.com> References: <531F62FC.1070503@rcbowen.com> <983076500.1568268.1395095837025.JavaMail.zimbra@redhat.com> Message-ID: <20140318123744.GC13112@tesla.pnq.redhat.com> On Mon, Mar 17, 2014 at 06:37:17PM -0400, Steve Gordon wrote: > ----- Original Message ----- > > A reminder: We'll be doing an RDO test day for the Icehouse Milestone 3, > > next week, March 19-20. > > > > This time around we're using the Fedora Test Day infrastructure, to make > > it easier to report your test results. > > > > Details about the test day are in the RDO wiki at > > http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_3 > > When can we expect to see M-3 packages starting to hit the repository > if we want to try and catch any show stoppers that might negatively > impact the value of test day? Unfortunately, we just realized, due to Fedora Copr build system issues (Fedora infra folks are debugging), it's most likely test day will be delayed to 25/26th March. P?draig will send another note soon I guess. -- /kashyap From rbowen at redhat.com Tue Mar 18 15:35:40 2014 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 18 Mar 2014 11:35:40 -0400 Subject: [Rdo-list] RDO Icehouse milestone 3 test day, March 25th, 26th Message-ID: <532867CC.6000803@redhat.com> As Kashyap mentioned earlier today, there were some failures in the build system that have brought us to decide to reschedule the test day for next week, when we can be assured of more solid packages, and a more successful, productive test day experience. As before, the relevant URLs are: The full test day information is at http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_3 The test day tool is at http://testdays.qa.fedoraproject.org/testdays/show_event?event_id=16 where you can see what tests need to be done, and leave your notes. If you wish to add more tests, or enhance the instructions for an existing test, both of these are in wikis, and can be edited directly. The testcases are listed at https://fedoraproject.org/wiki/Test_Day:2014-03-19_RDOMetadata (Required a Fedora account, as we're using their test infrastructure for this.) and the test instructions are linked next to each test case. If you want to help get the word out about our rescheduling, please RT the tweet from @RDOCommunity, or tweet: Come help test the @RDOCommunity #openstack packages. Test day rescheduled for March 25, 26. http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_3 Thanks! -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From ak at cloudssky.com Wed Mar 19 14:24:16 2014 From: ak at cloudssky.com (Arash Kaffamanesh) Date: Wed, 19 Mar 2014 15:24:16 +0100 Subject: [Rdo-list] Deploying RDO using Foreman In-Reply-To: <20140311130726.GF18124@redhat.com> References: <20140311042335.GA27412@tesla.redhat.com> <20140311130726.GF18124@redhat.com> Message-ID: Hello together, I'm proceeding with this installation and I'm facing a strange problem with openvswitch on the controller node which has been reported here too: https://ask.openstack.org/en/question/10228/neutron-ovs-error-on-controller/ If I do a ovs-vsctl show, I'm getting: [root at controller ~]# ovs-vsctl show 2014-03-16T04:40:26Z|00001|reconnect|WARN|unix:/var/run/openvswitch/db.sock: connection attempt failed (No such file or directory) ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection failed (No such file or directory) And in /var/log/neutron/openvswitch-agent.log I can see: 2014-03-15 23:22:37.296 3084 INFO neutron.common.config [-] Logging enabled! 2014-03-15 23:22:37.296 3084 ERROR neutron.plugins.openvswitch.agent.ovs_neutron_agent [-] Tunneling cannot be enabled without a valid local_ip. Agent terminated! It seems that on the controller the ovs neutron agent doesn't like my "local_ip". But on the compute and network node ovs-vsctl show works: [root at neutron ~]# ovs-vsctl show 6093f101-4bac-4e30-afc6-545f8f3dc6a1 Bridge br-int Port br-int Interface br-int type: internal Bridge br-tun Port br-tun Interface br-tun type: internal ovs_version: "1.11.0" And here is my ifconfig on the controller node: [root at controller ~]# ifconfig eth0 Link encap:Ethernet HWaddr FA:16:3E:80:BC:FB inet addr:10.0.0.6 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::f816:3eff:fe80:bcfb/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6523 errors:0 dropped:0 overruns:0 frame:0 TX packets:4982 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1317111 (1.2 MiB) TX bytes:849191 (829.2 KiB) eth1 Link encap:Ethernet HWaddr FA:16:3E:0B:AF:9A inet addr:10.0.1.5 Bcast:10.0.1.255 Mask:255.255.255.0 inet6 addr: fe80::f816:3eff:fe0b:af9a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:336 (336.0 b) TX bytes:546 (546.0 b) eth2 Link encap:Ethernet HWaddr FA:16:3E:45:8E:FD inet addr:10.0.2.5 Bcast:10.0.2.255 Mask:255.255.255.0 inet6 addr: fe80::f816:3eff:fe45:8efd/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:336 (336.0 b) TX bytes:566 (566.0 b) Any ideas? Thanks! Arash Mit freundlichen Gr??en, Arash Kaffamanesh Like | Follow | Build your CloudSite with OpenCms OCCX on ProfitBricks *________________**____________* *Arash Kaffamanesh* *Clouds Sky GmbH* *Im Mediapark 4C* *50760 K?ln* T.: +49 221 379 90 680 M.: +49 177 880 77 34 www.cloudssky.com *_________________**___________* On Tue, Mar 11, 2014 at 2:07 PM, Hugh O. Brock wrote: > On Tue, Mar 11, 2014 at 09:53:35AM +0530, Kashyap Chamarthy wrote: > > On Mon, Mar 10, 2014 at 08:46:45PM +0100, Arash Kaffamanesh wrote: > > > Hi, > > > > > > I posted a question regarding "Deploying RDO using Foreman" to > > > ask.openstack.org and thanks to Keshyap and Rich which engaged me to > > > proceed further, I updated the thread here: > > > > > > > https://ask.openstack.org/en/question/12104/deploying-rdo-using-foreman/ > > > > > > The post might be too long, here some more information about the reason > > > behind my question and some more questions: > > > > > > I'm trying to learn Foreman for installing OpenStack and use it to > deploy > > > RDO on top of RDO to provide some kind of OpenStack training / > webinars and > > > later to run the whole thing on 6-8 bare metal machines and use it to > > > deploy OpenShift and write a tutorial about the whole thing and post > it on > > > the RDO site, LinkedIn, etc. > > > > > > About our BASE RDO environment: > > > Our RDO based 3 node environment is thanks to the latest update very > stable > > > and very fast now and I've to thank all of you smart guys for doing > such a > > > great work! > > > > > > Our environment uses VLAN and the Foreman RDO installation shall use > GRE > > > and Qemu (or LXC / Docker) to let us play with the whole thing and > write a > > > tutorial about the whole thing. > > > > > > So my questions: > > > Does the Foreman installation on top of a virtualized environment work > at > > > all? (I guess yes) > > > > Yes, technically, it should work. Refer to my previous email on > > this list[1] for some URLs on Foreman. > > > > > Could a VLAN based BASE-Install be a problem to succeed with this > scenario > > > (to have GRE on top of VLAN)? (I guess no) > > > > Only way to know with certainity - to try it. > > > > > Has someone tried such a scenario before? (I guess yes) > > > Could I use LXC / Docker instead Qemu? > > > > There's active work on upstream for Docker support, so you ought to > > experiment and carefully note down observations, filing bugs along the > > way. > > > > And, it depends on _what_ you want to do with the LXC/Docker setup. If > > it's just to try it out, there's decent resources on the inter-webs. > > > > Hi there. It's also worth mentioning that we are actively working on > improving the OpenStack installation process with Foreman, including > adding a better UI and some workflow components to stage > deployments. Watch this list for details as they emerge. > > --Hugh > > > -- > == Hugh Brock, hbrock at redhat.com == > == Senior Engineering Manager, Cloud Engineering == > == Tuskar: Elastic Scaling for OpenStack == > == http://github.com/tuskar == > > "I know that you believe you understand what you think I said, but I?m > not sure you realize that what you heard is not what I meant." > --Robert McCloskey > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at rcbowen.com Wed Mar 19 15:10:54 2014 From: rbowen at rcbowen.com (Rich Bowen) Date: Wed, 19 Mar 2014 11:10:54 -0400 Subject: [Rdo-list] Networking questions - ask.openstack.org Message-ID: <5329B37E.5050603@rcbowen.com> I'm trying to get caught up on the backlog of unanswered questions on ask.openstack.org, and could use some help on a few of these, if anyone has some time to help out. https://ask.openstack.org/en/question/10087/cant-get-ip-when-i-working-with-ml2-gre/ - can't get IP when I working with ml2 GRE https://ask.openstack.org/en/question/10091/network-neutron-configuration-for-instances-with-public-ip-addresses/ - network / neutron configuration for instances with public ip addresses https://ask.openstack.org/en/question/10271/getting-only-single-echo-reply-from-vm-from-outside-or-inside-network/ - Getting only single echo reply from VM, from outside or inside network https://ask.openstack.org/en/question/10290/how-to-enable-grevxlanvlanflat-network-at-one-cloud-at-the-same-time/ - How to enable gre/vxlan/vlan/flat network at one cloud at the same time ? There's more, if you have more time, but these are the oldest, and it would be nice to get some of them resolved, and with sufficient detail that people with related questions might be able to work things out on their own from the answers. -- Rich Bowen - rbowen at rcbowen.com - @rbowen http://apachecon.com/ - @apachecon From lars at redhat.com Wed Mar 19 15:29:14 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Wed, 19 Mar 2014 11:29:14 -0400 Subject: [Rdo-list] Markdown in comments on ask.openstack.org Message-ID: <20140319152914.GB17794@redhat.com> Hello everyone, I've opened a launchpad ticket requesting ask.openstack.org enable markdown processing in comments (so that one can leave comments that include links or things like `command` or `/path/literals`). If you think this is a good idea, please feel free to comment here: https://bugs.launchpad.net/openstack-community/+bug/1261771 Even if you don't think it's a good idea, I guess. Participate! :) -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From ak at cloudssky.com Wed Mar 19 16:20:04 2014 From: ak at cloudssky.com (Arash Kaffamanesh) Date: Wed, 19 Mar 2014 17:20:04 +0100 Subject: [Rdo-list] Deploying RDO using Foreman In-Reply-To: References: <20140311042335.GA27412@tesla.redhat.com> <20140311130726.GF18124@redhat.com> Message-ID: Hi again, openvswitch was not running: [root at controller ~]# /etc/init.d/openvswitch status ovsdb-server is not running ovs-vswitchd is not running but if I start it, then I can't access the VM anymore: [root at controller ~]# /etc/init.d/openvswitch start Starting ovsdb-server [ OK ] Configuring Open vSwitch system IDs [ OK ] Inserting openvswitch module [ OK ] Starting ovs-vswitchd [ OK ] Enabling remote OVSDB managers [ OK ] [root at controller ~]# Any ideas? Thanks! On Wed, Mar 19, 2014 at 3:24 PM, Arash Kaffamanesh wrote: > Hello together, > > I'm proceeding with this installation and I'm facing a strange problem > with openvswitch on the controller node which has been reported here too: > > > https://ask.openstack.org/en/question/10228/neutron-ovs-error-on-controller/ > > If I do a ovs-vsctl show, I'm getting: > > [root at controller ~]# ovs-vsctl show > 2014-03-16T04:40:26Z|00001|reconnect|WARN|unix:/var/run/openvswitch/db.sock: > connection attempt failed (No such file or directory) > ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection failed > (No such file or directory) > > And in /var/log/neutron/openvswitch-agent.log I can see: > > 2014-03-15 23:22:37.296 3084 INFO neutron.common.config [-] Logging > enabled! > 2014-03-15 23:22:37.296 3084 ERROR > neutron.plugins.openvswitch.agent.ovs_neutron_agent [-] Tunneling cannot be > enabled without a valid local_ip. Agent terminated! > > It seems that on the controller the ovs neutron agent doesn't like my > "local_ip". > But on the compute and network node ovs-vsctl show works: > > [root at neutron ~]# ovs-vsctl show > 6093f101-4bac-4e30-afc6-545f8f3dc6a1 > Bridge br-int > Port br-int > Interface br-int > type: internal > Bridge br-tun > Port br-tun > Interface br-tun > type: internal > ovs_version: "1.11.0" > > > And here is my ifconfig on the controller node: > > [root at controller ~]# ifconfig > eth0 Link encap:Ethernet HWaddr FA:16:3E:80:BC:FB > inet addr:10.0.0.6 Bcast:10.0.0.255 Mask:255.255.255.0 > inet6 addr: fe80::f816:3eff:fe80:bcfb/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:6523 errors:0 dropped:0 overruns:0 frame:0 > TX packets:4982 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:1317111 (1.2 MiB) TX bytes:849191 (829.2 KiB) > > eth1 Link encap:Ethernet HWaddr FA:16:3E:0B:AF:9A > inet addr:10.0.1.5 Bcast:10.0.1.255 Mask:255.255.255.0 > inet6 addr: fe80::f816:3eff:fe0b:af9a/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:8 errors:0 dropped:0 overruns:0 frame:0 > TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:336 (336.0 b) TX bytes:546 (546.0 b) > > eth2 Link encap:Ethernet HWaddr FA:16:3E:45:8E:FD > inet addr:10.0.2.5 Bcast:10.0.2.255 Mask:255.255.255.0 > inet6 addr: fe80::f816:3eff:fe45:8efd/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:8 errors:0 dropped:0 overruns:0 frame:0 > TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:336 (336.0 b) TX bytes:566 (566.0 b) > > > Any ideas? > > Thanks! > Arash > > Mit freundlichen Gr??en, > Arash Kaffamanesh > > Like | Follow > | Build your CloudSite with OpenCms OCCX on ProfitBricks > > *________________**____________* > > *Arash Kaffamanesh* > > * Clouds Sky GmbH* > > *Im Mediapark 4C* > > > *50760 K?ln* > T.: +49 221 379 90 680 > M.: +49 177 880 77 34 > www.cloudssky.com > *_________________**___________* > > > > On Tue, Mar 11, 2014 at 2:07 PM, Hugh O. Brock wrote: > >> On Tue, Mar 11, 2014 at 09:53:35AM +0530, Kashyap Chamarthy wrote: >> > On Mon, Mar 10, 2014 at 08:46:45PM +0100, Arash Kaffamanesh wrote: >> > > Hi, >> > > >> > > I posted a question regarding "Deploying RDO using Foreman" to >> > > ask.openstack.org and thanks to Keshyap and Rich which engaged me to >> > > proceed further, I updated the thread here: >> > > >> > > >> https://ask.openstack.org/en/question/12104/deploying-rdo-using-foreman/ >> > > >> > > The post might be too long, here some more information about the >> reason >> > > behind my question and some more questions: >> > > >> > > I'm trying to learn Foreman for installing OpenStack and use it to >> deploy >> > > RDO on top of RDO to provide some kind of OpenStack training / >> webinars and >> > > later to run the whole thing on 6-8 bare metal machines and use it to >> > > deploy OpenShift and write a tutorial about the whole thing and post >> it on >> > > the RDO site, LinkedIn, etc. >> > > >> > > About our BASE RDO environment: >> > > Our RDO based 3 node environment is thanks to the latest update very >> stable >> > > and very fast now and I've to thank all of you smart guys for doing >> such a >> > > great work! >> > > >> > > Our environment uses VLAN and the Foreman RDO installation shall use >> GRE >> > > and Qemu (or LXC / Docker) to let us play with the whole thing and >> write a >> > > tutorial about the whole thing. >> > > >> > > So my questions: >> > > Does the Foreman installation on top of a virtualized environment >> work at >> > > all? (I guess yes) >> > >> > Yes, technically, it should work. Refer to my previous email on >> > this list[1] for some URLs on Foreman. >> > >> > > Could a VLAN based BASE-Install be a problem to succeed with this >> scenario >> > > (to have GRE on top of VLAN)? (I guess no) >> > >> > Only way to know with certainity - to try it. >> > >> > > Has someone tried such a scenario before? (I guess yes) >> > > Could I use LXC / Docker instead Qemu? >> > >> > There's active work on upstream for Docker support, so you ought to >> > experiment and carefully note down observations, filing bugs along the >> > way. >> > >> > And, it depends on _what_ you want to do with the LXC/Docker setup. If >> > it's just to try it out, there's decent resources on the inter-webs. >> > >> >> Hi there. It's also worth mentioning that we are actively working on >> improving the OpenStack installation process with Foreman, including >> adding a better UI and some workflow components to stage >> deployments. Watch this list for details as they emerge. >> >> --Hugh >> >> >> -- >> == Hugh Brock, hbrock at redhat.com == >> == Senior Engineering Manager, Cloud Engineering == >> == Tuskar: Elastic Scaling for OpenStack == >> == http://github.com/tuskar == >> >> "I know that you believe you understand what you think I said, but I?m >> not sure you realize that what you heard is not what I meant." >> --Robert McCloskey >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ak at cloudssky.com Wed Mar 19 17:21:51 2014 From: ak at cloudssky.com (Arash Kaffamanesh) Date: Wed, 19 Mar 2014 18:21:51 +0100 Subject: [Rdo-list] Deploying RDO using Foreman In-Reply-To: References: <20140311042335.GA27412@tesla.redhat.com> <20140311130726.GF18124@redhat.com> Message-ID: Hi again, "ovs-vsctl show " works now :-) I started openvswitch over the horizon console, created the br-ex interface and plugged it into eth0. What I don't understand is, why I can't login through the br-ex interface into the controller node from outside, but I can login from the compute node through the eth1 network (management network). If I reboot the controller and watch it during reboot, I can see the famous issue with the metadata request error (no route to host). I guess I've to adjust the routing table (?): [root at controller ~]# ovs-vsctl show 8e8a6f2f-1b41-4bfc-a95e-dee5039be55b Bridge br-ex Port "eth0" Interface "eth0" Port br-ex Interface br-ex type: internal ovs_version: "1.11.0" [root at controller ~]# cat /etc/sysconfig/network-scripts/ifcfg-br-ex DEVICE=br-ex DEVICETYPE=ovs TYPE=OVSBridge BOOTPROTO=static IPADDR=10.0.0.6 NETMASK=255.255.255.0 GATEWAY=10.0.0.1 #DOMAIN=mydomain.com DNS1=8.8.8.8 #DNS2=192.168.10.111 ONBOOT=yes DEFROUTE=yes [root at controller ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 TYPE=OVSPort DEVICETYPE=ovs OVS_BRIDGE=br-ex ONBOOT=yes #PROMISC=yes [root at controller ~]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 br-ex 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 1004 0 0 eth2 169.254.0.0 0.0.0.0 255.255.0.0 U 1006 0 0 br-ex 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 br-ex On Wed, Mar 19, 2014 at 5:20 PM, Arash Kaffamanesh wrote: > Hi again, > > openvswitch was not running: > > [root at controller ~]# /etc/init.d/openvswitch status > ovsdb-server is not running > ovs-vswitchd is not running > > but if I start it, then I can't access the VM anymore: > > [root at controller ~]# /etc/init.d/openvswitch start > Starting ovsdb-server [ OK ] > Configuring Open vSwitch system IDs [ OK ] > Inserting openvswitch module [ OK ] > Starting ovs-vswitchd [ OK ] > Enabling remote OVSDB managers [ OK ] > [root at controller ~]# > > Any ideas? > > Thanks! > > On Wed, Mar 19, 2014 at 3:24 PM, Arash Kaffamanesh wrote: > >> Hello together, >> >> I'm proceeding with this installation and I'm facing a strange problem >> with openvswitch on the controller node which has been reported here too: >> >> >> https://ask.openstack.org/en/question/10228/neutron-ovs-error-on-controller/ >> >> If I do a ovs-vsctl show, I'm getting: >> >> [root at controller ~]# ovs-vsctl show >> 2014-03-16T04:40:26Z|00001|reconnect|WARN|unix:/var/run/openvswitch/db.sock: >> connection attempt failed (No such file or directory) >> ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection failed >> (No such file or directory) >> >> And in /var/log/neutron/openvswitch-agent.log I can see: >> >> 2014-03-15 23:22:37.296 3084 INFO neutron.common.config [-] Logging >> enabled! >> 2014-03-15 23:22:37.296 3084 ERROR >> neutron.plugins.openvswitch.agent.ovs_neutron_agent [-] Tunneling cannot be >> enabled without a valid local_ip. Agent terminated! >> >> It seems that on the controller the ovs neutron agent doesn't like my >> "local_ip". >> But on the compute and network node ovs-vsctl show works: >> >> [root at neutron ~]# ovs-vsctl show >> 6093f101-4bac-4e30-afc6-545f8f3dc6a1 >> Bridge br-int >> Port br-int >> Interface br-int >> type: internal >> Bridge br-tun >> Port br-tun >> Interface br-tun >> type: internal >> ovs_version: "1.11.0" >> >> >> And here is my ifconfig on the controller node: >> >> [root at controller ~]# ifconfig >> eth0 Link encap:Ethernet HWaddr FA:16:3E:80:BC:FB >> inet addr:10.0.0.6 Bcast:10.0.0.255 Mask:255.255.255.0 >> inet6 addr: fe80::f816:3eff:fe80:bcfb/64 Scope:Link >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:6523 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:4982 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:1000 >> RX bytes:1317111 (1.2 MiB) TX bytes:849191 (829.2 KiB) >> >> eth1 Link encap:Ethernet HWaddr FA:16:3E:0B:AF:9A >> inet addr:10.0.1.5 Bcast:10.0.1.255 Mask:255.255.255.0 >> inet6 addr: fe80::f816:3eff:fe0b:af9a/64 Scope:Link >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:8 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:1000 >> RX bytes:336 (336.0 b) TX bytes:546 (546.0 b) >> >> eth2 Link encap:Ethernet HWaddr FA:16:3E:45:8E:FD >> inet addr:10.0.2.5 Bcast:10.0.2.255 Mask:255.255.255.0 >> inet6 addr: fe80::f816:3eff:fe45:8efd/64 Scope:Link >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:8 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:1000 >> RX bytes:336 (336.0 b) TX bytes:566 (566.0 b) >> >> >> Any ideas? >> >> Thanks! >> Arash >> >> Mit freundlichen Gr??en, >> Arash Kaffamanesh >> >> Like | Follow >> | Build your CloudSite with OpenCms OCCX on ProfitBricks >> >> *________________**____________* >> >> *Arash Kaffamanesh* >> >> * Clouds Sky GmbH* >> >> *Im Mediapark 4C* >> >> >> *50760 K?ln* >> T.: +49 221 379 90 680 >> M.: +49 177 880 77 34 >> www.cloudssky.com >> * _________________**___________* >> >> >> >> On Tue, Mar 11, 2014 at 2:07 PM, Hugh O. Brock wrote: >> >>> On Tue, Mar 11, 2014 at 09:53:35AM +0530, Kashyap Chamarthy wrote: >>> > On Mon, Mar 10, 2014 at 08:46:45PM +0100, Arash Kaffamanesh wrote: >>> > > Hi, >>> > > >>> > > I posted a question regarding "Deploying RDO using Foreman" to >>> > > ask.openstack.org and thanks to Keshyap and Rich which engaged me to >>> > > proceed further, I updated the thread here: >>> > > >>> > > >>> https://ask.openstack.org/en/question/12104/deploying-rdo-using-foreman/ >>> > > >>> > > The post might be too long, here some more information about the >>> reason >>> > > behind my question and some more questions: >>> > > >>> > > I'm trying to learn Foreman for installing OpenStack and use it to >>> deploy >>> > > RDO on top of RDO to provide some kind of OpenStack training / >>> webinars and >>> > > later to run the whole thing on 6-8 bare metal machines and use it to >>> > > deploy OpenShift and write a tutorial about the whole thing and post >>> it on >>> > > the RDO site, LinkedIn, etc. >>> > > >>> > > About our BASE RDO environment: >>> > > Our RDO based 3 node environment is thanks to the latest update very >>> stable >>> > > and very fast now and I've to thank all of you smart guys for doing >>> such a >>> > > great work! >>> > > >>> > > Our environment uses VLAN and the Foreman RDO installation shall use >>> GRE >>> > > and Qemu (or LXC / Docker) to let us play with the whole thing and >>> write a >>> > > tutorial about the whole thing. >>> > > >>> > > So my questions: >>> > > Does the Foreman installation on top of a virtualized environment >>> work at >>> > > all? (I guess yes) >>> > >>> > Yes, technically, it should work. Refer to my previous email on >>> > this list[1] for some URLs on Foreman. >>> > >>> > > Could a VLAN based BASE-Install be a problem to succeed with this >>> scenario >>> > > (to have GRE on top of VLAN)? (I guess no) >>> > >>> > Only way to know with certainity - to try it. >>> > >>> > > Has someone tried such a scenario before? (I guess yes) >>> > > Could I use LXC / Docker instead Qemu? >>> > >>> > There's active work on upstream for Docker support, so you ought to >>> > experiment and carefully note down observations, filing bugs along the >>> > way. >>> > >>> > And, it depends on _what_ you want to do with the LXC/Docker setup. If >>> > it's just to try it out, there's decent resources on the inter-webs. >>> > >>> >>> Hi there. It's also worth mentioning that we are actively working on >>> improving the OpenStack installation process with Foreman, including >>> adding a better UI and some workflow components to stage >>> deployments. Watch this list for details as they emerge. >>> >>> --Hugh >>> >>> >>> -- >>> == Hugh Brock, hbrock at redhat.com == >>> == Senior Engineering Manager, Cloud Engineering == >>> == Tuskar: Elastic Scaling for OpenStack == >>> == http://github.com/tuskar == >>> >>> "I know that you believe you understand what you think I said, but I?m >>> not sure you realize that what you heard is not what I meant." >>> --Robert McCloskey >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kchamart at redhat.com Thu Mar 20 04:44:48 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Thu, 20 Mar 2014 10:14:48 +0530 Subject: [Rdo-list] Markdown in comments on ask.openstack.org In-Reply-To: <20140319152914.GB17794@redhat.com> References: <20140319152914.GB17794@redhat.com> Message-ID: <20140320044448.GE24455@tesla.redhat.com> On Wed, Mar 19, 2014 at 11:29:14AM -0400, Lars Kellogg-Stedman wrote: > Hello everyone, > > I've opened a launchpad ticket requesting ask.openstack.org enable > markdown processing in comments (so that one can leave comments that > include links or things like `command` or `/path/literals`). > > If you think this is a good idea, please feel free to comment here: > > https://bugs.launchpad.net/openstack-community/+bug/1261771 Excellent -- Markdown support for comments is now added! Thanks, Lars. -- /kashyap From kchamart at redhat.com Thu Mar 20 08:29:47 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Thu, 20 Mar 2014 13:59:47 +0530 Subject: [Rdo-list] Current state of RDO bugs In-Reply-To: <20140312143610.GA6574@tesla.pnq.redhat.com> References: <20140312143610.GA6574@tesla.pnq.redhat.com> Message-ID: <20140320082947.GA14878@tesla.pnq.redhat.com> On Wed, Mar 12, 2014 at 08:06:10PM +0530, Kashyap Chamarthy wrote: > Heya, > > I was just doing some RDO bug scrub, and as of writing this here's the > current state of affairs: > > - NEW, ASSIGNED, or ON_DEV : 138 bugs > - MODFIEID, POST, or ON_QA : 91 bugs > - VERIFIED : 4 bugs As of today, status of RDO bugs[1], 20-MAR-2014: - NEW, ASSIGNED, or ON_DEV : 135 bugs - MODFIEID, POST, or ON_QA : 92 bugs - VERIFIED : 4 bugs About managing stale bugs, how about this: we could set NEEDINFO on reporter, and if there's no response in a month (or so?), close the bug with resolution INSUFFICIENT_DATA. And add a note to reopen the bug if the reporter can reproduce it again. (i.e. if you file a bug, you are expected to proactively keep track of it, provide information/test with new builds. Okay, I admit that's 100% true in only utopian world, but we can strive to stay diligent. :-) ) Comments/thoughts on this are welcome. [1] http://kashyapc.fedorapeople.org/virt/openstack/bugzilla/rdo-bug-status/all-rdo-bugs-20-03-2014.txt -- /kashyap From rbowen at redhat.com Thu Mar 20 13:16:50 2014 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 20 Mar 2014 09:16:50 -0400 Subject: [Rdo-list] Markdown in comments on ask.openstack.org In-Reply-To: <20140320044448.GE24455@tesla.redhat.com> References: <20140319152914.GB17794@redhat.com> <20140320044448.GE24455@tesla.redhat.com> Message-ID: <532AEA42.20902@redhat.com> On 03/20/2014 12:44 AM, Kashyap Chamarthy wrote: > On Wed, Mar 19, 2014 at 11:29:14AM -0400, Lars Kellogg-Stedman wrote: >> Hello everyone, >> >> I've opened a launchpad ticket requesting ask.openstack.org enable >> markdown processing in comments (so that one can leave comments that >> include links or things like `command` or `/path/literals`). >> >> If you think this is a good idea, please feel free to comment here: >> >> https://bugs.launchpad.net/openstack-community/+bug/1261771 > Excellent -- Markdown support for comments is now added! > > Thanks, Lars. > > Wow. That was fast. Thanks, Lars. -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From rbowen at redhat.com Thu Mar 20 15:36:02 2014 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 20 Mar 2014 11:36:02 -0400 Subject: [Rdo-list] RDO Forum OpenID In-Reply-To: <926416416.33675734.1394635277996.JavaMail.zimbra@redhat.com> References: <926416416.33675734.1394635277996.JavaMail.zimbra@redhat.com> Message-ID: <532B0AE2.6090006@redhat.com> On 03/12/2014 10:41 AM, Steve Gordon wrote: > Hi all, > > I haven't been able to access the RDO forum using my Google ID for quite some time, when I click the button on http://openstack.redhat.com/forum/entry/signin?Target=http://openstack.redhat.com/Main_Page I get this: > > Provider is required. > UniqueID is required. > The connection data has not been verified. > > Is this a known issue or am I just special? > I finally got the Google ID login working again. Unfortunately, I had to disable the BotStop plugin to make it work, which was what we used to block some of the spam we were getting. So now I'm trying to fix that. But meanwhile you can log in with Google IDs again. --Rich -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From rbowen at redhat.com Thu Mar 20 15:40:57 2014 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 20 Mar 2014 11:40:57 -0400 Subject: [Rdo-list] RDO Forum OpenID In-Reply-To: <532B0AE2.6090006@redhat.com> References: <926416416.33675734.1394635277996.JavaMail.zimbra@redhat.com> <532B0AE2.6090006@redhat.com> Message-ID: <532B0C09.1000400@redhat.com> On 03/20/2014 11:36 AM, Rich Bowen wrote: > > On 03/12/2014 10:41 AM, Steve Gordon wrote: >> Hi all, >> >> I haven't been able to access the RDO forum using my Google ID for >> quite some time, when I click the button on >> http://openstack.redhat.com/forum/entry/signin?Target=http://openstack.redhat.com/Main_Page >> I get this: >> >> Provider is required. >> UniqueID is required. >> The connection data has not been verified. >> >> Is this a known issue or am I just special? >> > > I finally got the Google ID login working again. Unfortunately, I had > to disable the BotStop plugin to make it work, which was what we used > to block some of the spam we were getting. So now I'm trying to fix > that. But meanwhile you can log in with Google IDs again. > Ok, fixed. We should be good now. Sorry that took so many months. --Rich -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From ak at cloudssky.com Thu Mar 20 18:04:20 2014 From: ak at cloudssky.com (Arash Kaffamanesh) Date: Thu, 20 Mar 2014 19:04:20 +0100 Subject: [Rdo-list] Keystone dies after 1 - 3 days, can't login into horizon dashboard Message-ID: Hello together, Posted this to aoo: https://ask.openstack.org/en/question/25637/rdo-keystone-dies-after-1-3-days-cant-login-into-horizon-dashboard/ Any ideas? Thanks! Arash -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Fri Mar 21 14:33:12 2014 From: rbowen at redhat.com (Rich Bowen) Date: Fri, 21 Mar 2014 10:33:12 -0400 Subject: [Rdo-list] Reminder: OpenStack Icehouse M3 test day, March 25th, 26th Message-ID: <532C4DA8.1090109@redhat.com> Remember to join us on #rdo on Freenode, next week, Tuesday and Wednesday, for the OpenStack Icehouse Milestone 3 RDO test day. As before, the relevant URLs are: The full test day information is at http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_3 The test day tool is at http://testdays.qa.fedoraproject.org/testdays/show_event?event_id=16 where you can see what tests need to be done, and leave your notes. If you wish to add more tests, or enhance the instructions for an existing test, both of these are in wikis, and can be edited directly. The testcases are listed at https://fedoraproject.org/wiki/Test_Day:2014-03-19_RDOMetadata (Required a Fedora account, as we're using their test infrastructure for this.) and the test instructions are linked next to each test case. If you want to help get the word out about our rescheduling, please RT the tweet from @RDOCommunity, or tweet: Come help test the @RDOCommunity #openstack packages. Test day rescheduled for March 25, 26. http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_3 Thanks! -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From pchalupa at redhat.com Mon Mar 24 08:47:22 2014 From: pchalupa at redhat.com (Petr Chalupa) Date: Mon, 24 Mar 2014 09:47:22 +0100 Subject: [Rdo-list] [OFI] Astapor puppet module 'guru' missing Message-ID: <532FF11A.7040707@redhat.com> Good morning, preparing of the demo last week showed that we are missing someone who would truly knows how to use Astapor puppet modules and how to configure them. Do we have somebody on the team or who should we contact? Thanks, Petr. From hbrock at redhat.com Mon Mar 24 10:04:52 2014 From: hbrock at redhat.com (Hugh O. Brock) Date: Mon, 24 Mar 2014 06:04:52 -0400 Subject: [Rdo-list] [OFI] Astapor puppet module 'guru' missing In-Reply-To: <532FF11A.7040707@redhat.com> References: <532FF11A.7040707@redhat.com> Message-ID: <20140324100452.GL15942@redhat.com> On Mon, Mar 24, 2014 at 09:47:22AM +0100, Petr Chalupa wrote: > Good morning, > > preparing of the demo last week showed that we are missing someone > who would truly knows how to use Astapor puppet modules and how to > configure them. Do we have somebody on the team or who should we > contact? Hello Petr. Funnily enough, Jordan O'Mara, who wrote Astapor, was with us in Brno last week... Having said that I think it is Jay Guiditta and Crag Wolfe who are the experts at this point. --Hugh -- == Hugh Brock, hbrock at redhat.com == == Senior Engineering Manager, Cloud Engineering == == Tuskar: Elastic Scaling for OpenStack == == http://github.com/tuskar == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From jrist at redhat.com Mon Mar 24 15:51:52 2014 From: jrist at redhat.com (Jason Rist) Date: Mon, 24 Mar 2014 09:51:52 -0600 Subject: [Rdo-list] [OFI] Recap from last week Message-ID: <53305498.2080508@redhat.com> A bunch of us got together in Brno, CZ and cranked through some of the core needs for the OpenStack Foreman Installer, AKA Staypuft! Some big progress: 1.) Using 'wicked' gem, we got much of the wizard tied together, creating underlying relevant OpenStack hostgroups, made each step tie with one another, and created a relevant deployment model upon completion of the 3rd step. This also includes listing deployments (currently only 1), and the ability to delete a deployment and associated hostgroups. 2.) mtaylor, mhulan and pchalupa made huge progress on the DynFlow orchestration of the OpenStack deployment, to the point of successfully launching a (mis-configured) OpenStack deployment that was able to be opened in a browser. 3.) Big demo that we did on Friday showing our progress. If interested, I can post the DynFlow video (ogv) somewhere. Thanks from the Staypuft team, Jason -- Jason E. Rist Senior Software Engineer OpenStack Management UI Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/identi.ca: knowncitizen From ALLAN.L.ST.GEORGE at leidos.com Mon Mar 24 16:39:36 2014 From: ALLAN.L.ST.GEORGE at leidos.com (St. George, Allan L.) Date: Mon, 24 Mar 2014 16:39:36 +0000 Subject: [Rdo-list] Compute nodes instances aren't obtaining DHCP addresses Message-ID: We currently have a multi-compute node stack (controller, network, block storage & 3 compute nodes.) Upon spawning an instance, it resizes to match the flavor, then it attempts to obtain an ip address for eth0 prior to cloud-init. The process failes. The network node (rdo3) /var/log/nova/scheduler.log is reporting... 2014-03-20 12:57:45.265 26619 ERROR nova.scheduler.filter_scheduler [req-d371cbd0-2a55-451a-ae5a-59ba30137ab8 a85956a2380648259bfc13293376847c 5942763cd7e34ee0bfd792300fbdc019] [instance: e9c85cad-7a60-4a31-a2f2-5747f302d24a] Error from last host: rdo4.ciso.leidos.com (node rdo4.ciso.leidos.com): [u'Traceback (most recent call last):\n', u' File "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 1043, in _build_instance\n set_access_ip=set_access_ip)\n', u' File "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 1426, in _spawn\n LOG.exception(_(\'Instance failed to spawn\'), instance=instance)\n', u' File "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 1423, in _spawn\n block_device_info)\n', u' File "/usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py", line 2091, in spawn\n block_device_info, context=context)\n', u' File "/usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py", line 3249, in _create_domain_and_network\n domain = self._create_domain(xml, instance=instance, power_on=power_on)\n', u' File "/usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py", line 3192, in _create_domain\n domain.XMLDesc(0))\n', u' File "/usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py", line 3187, in _create_domain\n domain.createWithFlags(launch_flags)\n', u' File "/usr/lib/python2.6/site-packages/eventlet/tpool.py", line 179, in doit\n result = proxy_call(self._autowrap, f, *args, **kwargs)\n', u' File "/usr/lib/python2.6/site-packages/eventlet/tpool.py", line 139, in proxy_call\n rv = execute(f,*args,**kwargs)\n', u' File "/usr/lib/python2.6/site-packages/eventlet/tpool.py", line 77, in tworker\n rv = meth(*args,**kwargs)\n', u' File "/usr/lib64/python2.6/site-packages/libvirt.py", line 708, in createWithFlags\n if ret == -1: raise libvirtError (\'virDomainCreateWithFlags() failed\', dom=self)\n', u"libvirtError: internal error Process exited while reading console log output: char device redirected to /dev/pts/1\nqemu-kvm: -netdev tap,ifname=tap8ebf8a93-46,script=,id=hostnet0: Device 'tap' could not be initialized\n\n"] Compute nodes (rdo1/3/4) /var/log/neutron/openvswitch-agent.log are reporting... 2014-03-20 14:41:06.289 3695 ERROR neutron.agent.linux.ovsdb_monitor [-] Error received from ovsdb monitor: ovsdb-client: unix:/var/run/openvswitch/db.sock: receive failed (End of file) Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akshik at outlook.com Tue Mar 25 04:48:00 2014 From: akshik at outlook.com (Akshik DBK) Date: Tue, 25 Mar 2014 10:18:00 +0530 Subject: [Rdo-list] Are there any Citrix CPBM like tool for OpenStack Message-ID: Hi, I came across the Citrix CPBM tools. Though there are OpenStack plugins available from CPBM. I would like to know if there are any such offering from RDO. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ukalifon at redhat.com Tue Mar 25 09:59:30 2014 From: ukalifon at redhat.com (Udi Kalifon) Date: Tue, 25 Mar 2014 05:59:30 -0400 (EDT) Subject: [Rdo-list] Test day bug: ERROR : 'CONFIG_PROVISION_DEMO_FLOATRANGE' In-Reply-To: <875625149.2878071.1395741047796.JavaMail.zimbra@redhat.com> Message-ID: <1076927067.2881175.1395741570668.JavaMail.zimbra@redhat.com> Hi. If you are trying to do a packstack install with multiple nodes, there is a bug in packstack that you need to work around. See below for details. Description of problem: When running a multi-node packstack install, you get: 2014-03-25 11:15:41::INFO::shell::78::root:: [10.8.0.50] Executing script: echo $HOME 2014-03-25 11:15:41::ERROR::run_setup::907::root:: Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/packstack/installer/run_setup.py", line 891, in main single_step_install(options) File "/usr/lib/python2.6/site-packages/packstack/installer/run_setup.py", line 690, in single_step_install _main(answerfilepath) File "/usr/lib/python2.6/site-packages/packstack/installer/run_setup.py", line 574, in _main runSequences() File "/usr/lib/python2.6/site-packages/packstack/installer/run_setup.py", line 553, in runSequences controller.runAllSequences() File "/usr/lib/python2.6/site-packages/packstack/installer/setup_controller.py", line 84, in runAllSequences sequence.run(self.CONF) File "/usr/lib/python2.6/site-packages/packstack/installer/core/sequences.py", line 96, in run step.run(config=config) File "/usr/lib/python2.6/site-packages/packstack/installer/core/sequences.py", line 43, in run raise SequenceError(str(ex)) SequenceError: 'CONFIG_PROVISION_DEMO_FLOATRANGE' Version-Release number of selected component (if applicable): Using RDO test day version of M-3: openstack-packstack-2014.1.1-0.4.dev1018.el6.noarch How reproducible: 100% Steps to Reproduce: 1. Run for example: packstack --install-hosts 10.8.0.50,10.8.0.53 Actual results: ERROR : 'CONFIG_PROVISION_DEMO_FLOATRANGE' Please check log file /var/tmp/packstack/20140325-111530-hJiaOR/openstack-setup.log for more information Expected results: In the answers file, it should be: CONFIG_PROVISION_DEMO=n Additional info: To work around this issue, set CONFIG_PROVISION_DEMO=n in the answers file Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1080369 Regards, Udi Kalifon. From ukalifon at redhat.com Tue Mar 25 10:11:01 2014 From: ukalifon at redhat.com (Udi Kalifon) Date: Tue, 25 Mar 2014 06:11:01 -0400 (EDT) Subject: [Rdo-list] Fwd: Test day bug: ERROR : 'CONFIG_PROVISION_DEMO_FLOATRANGE' In-Reply-To: <1076927067.2881175.1395741570668.JavaMail.zimbra@redhat.com> References: <1076927067.2881175.1395741570668.JavaMail.zimbra@redhat.com> Message-ID: <1637910560.2884421.1395742261748.JavaMail.zimbra@redhat.com> Please note: the workaround stated in the bug below (setting CONFIG_PROVISION_DEMO=n) doesn't work.... ----- Forwarded Message ----- From: "Udi Kalifon" To: rdo-list at redhat.com Sent: Tuesday, March 25, 2014 11:59:30 AM Subject: Test day bug: ERROR : 'CONFIG_PROVISION_DEMO_FLOATRANGE' Hi. If you are trying to do a packstack install with multiple nodes, there is a bug in packstack that you need to work around. See below for details. Description of problem: When running a multi-node packstack install, you get: 2014-03-25 11:15:41::INFO::shell::78::root:: [10.8.0.50] Executing script: echo $HOME 2014-03-25 11:15:41::ERROR::run_setup::907::root:: Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/packstack/installer/run_setup.py", line 891, in main single_step_install(options) File "/usr/lib/python2.6/site-packages/packstack/installer/run_setup.py", line 690, in single_step_install _main(answerfilepath) File "/usr/lib/python2.6/site-packages/packstack/installer/run_setup.py", line 574, in _main runSequences() File "/usr/lib/python2.6/site-packages/packstack/installer/run_setup.py", line 553, in runSequences controller.runAllSequences() File "/usr/lib/python2.6/site-packages/packstack/installer/setup_controller.py", line 84, in runAllSequences sequence.run(self.CONF) File "/usr/lib/python2.6/site-packages/packstack/installer/core/sequences.py", line 96, in run step.run(config=config) File "/usr/lib/python2.6/site-packages/packstack/installer/core/sequences.py", line 43, in run raise SequenceError(str(ex)) SequenceError: 'CONFIG_PROVISION_DEMO_FLOATRANGE' Version-Release number of selected component (if applicable): Using RDO test day version of M-3: openstack-packstack-2014.1.1-0.4.dev1018.el6.noarch How reproducible: 100% Steps to Reproduce: 1. Run for example: packstack --install-hosts 10.8.0.50,10.8.0.53 Actual results: ERROR : 'CONFIG_PROVISION_DEMO_FLOATRANGE' Please check log file /var/tmp/packstack/20140325-111530-hJiaOR/openstack-setup.log for more information Expected results: In the answers file, it should be: CONFIG_PROVISION_DEMO=n Additional info: To work around this issue, set CONFIG_PROVISION_DEMO=n in the answers file Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1080369 Regards, Udi Kalifon. From rdo-info at redhat.com Tue Mar 25 18:50:56 2014 From: rdo-info at redhat.com (RDO Forum) Date: Tue, 25 Mar 2014 18:50:56 +0000 Subject: [Rdo-list] [RDO] Red Hat Summit, April 14th-17th, San Francisco Message-ID: <00000144fa94bfcc-b47a3dcf-79a0-44ce-8334-9b452992e108-000000@email.amazonses.com> rbowen started a discussion. Red Hat Summit, April 14th-17th, San Francisco --- Follow the link below to check it out: http://openstack.redhat.com/forum/discussion/970/red-hat-summit-april-14th-17th-san-francisco Have a great day! From rbowen at redhat.com Wed Mar 26 14:08:28 2014 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 26 Mar 2014 10:08:28 -0400 Subject: [Rdo-list] OpenStack Marconi hangout TOMORROW Message-ID: <5332DF5C.9030909@redhat.com> Just a reminder: Flavio Percoco will be presenting a hangout on OpenStack Marconi tomorrow morning at 10:00 Eastern US time. The details of that presentation are at https://plus.google.com/events/ckjhm8rggnqvrnspftna845kubk The presentation will be streamed live on YouTube, but if you can't make it at that time, you can watch it at that same URL at your convenience afterwards. We'll be on #rdo-hangout on the Freenode IRC network for questions and comments during the presentation. -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From yrabl at redhat.com Wed Mar 26 15:37:05 2014 From: yrabl at redhat.com (Yogev Rabl) Date: Wed, 26 Mar 2014 11:37:05 -0400 (EDT) Subject: [Rdo-list] fail to launch instances in fedora 20 In-Reply-To: <461277151.4339502.1395848125209.JavaMail.zimbra@redhat.com> Message-ID: <288904781.4341020.1395848225431.JavaMail.zimbra@redhat.com> Hi, Earlier I've opened a bug: Bug 1081015 - failed to launch an instance from ISO image . This is an urgent issue and it looks like a problem with the qpid that cause the (I think). Can someone have a look in the bug and give another opinion? thanks, Yogev. From rdo-info at redhat.com Wed Mar 26 16:11:13 2014 From: rdo-info at redhat.com (RDO Forum) Date: Wed, 26 Mar 2014 16:11:13 +0000 Subject: [Rdo-list] [RDO] RDO at OpenStack Summit Message-ID: <00000144ff28e22f-97b3493c-40c9-4eae-8549-1af4490d6609-000000@email.amazonses.com> rbowen started a discussion. RDO at OpenStack Summit --- Follow the link below to check it out: http://openstack.redhat.com/forum/discussion/971/rdo-at-openstack-summit Have a great day! From chandankumar.093047 at gmail.com Wed Mar 26 16:56:16 2014 From: chandankumar.093047 at gmail.com (chandan kumar) Date: Wed, 26 Mar 2014 22:26:16 +0530 Subject: [Rdo-list] Mongodb error while installing RDO icehouse-3 through packstack on F20 Message-ID: Hello, I am trying to deploy RDO icehouse-3 using packstack on fedora 20. Below is the screen error log of packstack: 10.65.193.94_osclient.pp: [ DONE ] 10.65.193.94_horizon.pp: [ DONE ] 10.65.193.94_provision.pp: [ DONE ] Applying 10.65.193.94_mongodb.pp 10.65.193.94_mongodb.pp: [ ERROR ] Applying Puppet manifests [ ERROR ] ERROR : Error appeared during Puppet run: 10.65.193.94_mongodb.pp Error: Failed to parse template mongodb/mongodb.conf.erb: You will find full trace in log /var/tmp/packstack/20140326-215159-urZtup/manifests/10.65.193.94_mongodb.pp.log Please check log file /var/tmp/packstack/20140326-215159-urZtup/openstack-setup.log for more information Additional information: * Time synchronization installation was skipped. Please note that unsynchronized time on server instances might be problem for some OpenStack components. * Did not create a cinder volume group, one already existed * File /root/keystonerc_admin has been created on OpenStack client host 10.65.193.94. To use the command line tools you need to source the file. * To access the OpenStack Dashboard browse to http://10.65.193.94/dashboard . Please, find your login credentials stored in the keystonerc_admin in your home directory. Below is the output of /var/tmp/packstack/20140326-215159-urZtup/manifests/10.65.193.94_mongodb.pp.log [root at dhcp193-94 ~]# cat /var/tmp/packstack/20140326-215159-urZtup/manifests/10.65.193.94_mongodb.pp.log Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera defaults Error: Failed to parse template mongodb/mongodb.conf.erb: Filepath: /var/tmp/packstack/2425ebe0f2c143b3a52ed7d9756fc237/modules/mongodb/templates/mongodb.conf.erb Line: 10 Detail: undefined method `join' for "10.65.193.94":String at /var/tmp/packstack/2425ebe0f2c143b3a52ed7d9756fc237/modules/mongodb/manifests/server/config.pp:65 on node dhcp193-94.pnq.redhat.com Error: Failed to parse template mongodb/mongodb.conf.erb: Filepath: /var/tmp/packstack/2425ebe0f2c143b3a52ed7d9756fc237/modules/mongodb/templates/mongodb.conf.erb Line: 10 Detail: undefined method `join' for "10.65.193.94":String at /var/tmp/packstack/2425ebe0f2c143b3a52ed7d9756fc237/modules/mongodb/manifests/server/config.pp:65 on node dhcp193-94.pnq.redhat.com To fix that, i have installed mongodb-server and started it and again run the packstack file. After that still getting the same error. Can someone suggest me someone workaround for this? Thanks, Chandan Kumar From lars at redhat.com Thu Mar 27 04:01:18 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Thu, 27 Mar 2014 00:01:18 -0400 Subject: [Rdo-list] Mongodb error while installing RDO icehouse-3 through packstack on F20 In-Reply-To: References: Message-ID: <20140327040118.GB9058@redhat.com> On Wed, Mar 26, 2014 at 10:26:16PM +0530, chandan kumar wrote: > Error: Failed to parse template mongodb/mongodb.conf.erb: I ran into this also, and it turns out to be a bug in the mongodb puppet module. I've opened the issue upstream and submitted a patch to correct it: https://bugs.launchpad.net/packstack/+bug/1297984 -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From chandankumar.093047 at gmail.com Thu Mar 27 05:29:41 2014 From: chandankumar.093047 at gmail.com (chandan kumar) Date: Thu, 27 Mar 2014 10:59:41 +0530 Subject: [Rdo-list] Mongodb error while installing RDO icehouse-3 through packstack on F20 In-Reply-To: <20140327040118.GB9058@redhat.com> References: <20140327040118.GB9058@redhat.com> Message-ID: Hello, On Thu, Mar 27, 2014 at 9:31 AM, Lars Kellogg-Stedman wrote: > On Wed, Mar 26, 2014 at 10:26:16PM +0530, chandan kumar wrote: >> Error: Failed to parse template mongodb/mongodb.conf.erb: > > I ran into this also, and it turns out to be a bug in the mongodb > puppet module. I've opened the issue upstream and submitted a patch > to correct it: > > https://bugs.launchpad.net/packstack/+bug/1297984 > > -- > Lars Kellogg-Stedman | larsks @ irc > Cloud Engineering / OpenStack | " " @ twitter > Thank you lars for fixing the issue. With Regards, Chandan Kumar From andrew at andrewklau.com Thu Mar 27 10:18:18 2014 From: andrew at andrewklau.com (Andrew Lau) Date: Thu, 27 Mar 2014 21:18:18 +1100 Subject: [Rdo-list] Timed out waiting for nova-conductor. w/ icehouse-3 and foreman Message-ID: Hi, I tried to deploy RDO icehouse-3 using foreman on CentOS 6.5, previously I had success with Havana and icehouse-2 Everything went smoothly, and quite a few of the issues I had with icehouse-2 were gone! The only non-puppet task I had to do was on the controller: cat < /etc/mysql/conf.d/innodb.cnf [mysqld] default-storage-engine = innodb EOF service mysqld restart mysql -e 'drop database neutron; create database neutron;' However, I've hit a blocker with nova compute not showing up into the controller. The only thing useful I can find in the nova-compute logs, " Timed out waiting for nova-conductor. Is it running? Or did this service start before nova-conductor? " Both nova-compute (on the compute) and nova-conductor (on the controller) said "AMQP connected" after a service restart, so I'm not sure what's gone wrong here. Suggestions? Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at andrewklau.com Thu Mar 27 10:20:40 2014 From: andrew at andrewklau.com (Andrew Lau) Date: Thu, 27 Mar 2014 21:20:40 +1100 Subject: [Rdo-list] Timed out waiting for nova-conductor. w/ icehouse-3 and foreman In-Reply-To: References: Message-ID: Some extra info, I bundle compute+networking into one hostgroup, again worked fine in havana and icehouse-2 The interesting thing to note, Neutron on the compute node seems to show up fine. I see the l3-agent, dhcp, ovs etc. under the system info tab. On Thu, Mar 27, 2014 at 9:18 PM, Andrew Lau wrote: > Hi, > > I tried to deploy RDO icehouse-3 using foreman on CentOS 6.5, previously I > had success with Havana and icehouse-2 > > Everything went smoothly, and quite a few of the issues I had with > icehouse-2 were gone! > > The only non-puppet task I had to do was on the controller: > > cat < /etc/mysql/conf.d/innodb.cnf > [mysqld] > default-storage-engine = innodb > EOF > > service mysqld restart > > mysql -e 'drop database neutron; create database neutron;' > > However, I've hit a blocker with nova compute not showing up into the > controller. The only thing useful I can find in the nova-compute logs, > > " > Timed out waiting for nova-conductor. Is it running? Or did this service > start before nova-conductor? > " > > Both nova-compute (on the compute) and nova-conductor (on the controller) > said "AMQP connected" after a service restart, so I'm not sure what's gone > wrong here. > > Suggestions? > > Thanks, > Andrew > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ALLAN.L.ST.GEORGE at leidos.com Thu Mar 27 20:37:42 2014 From: ALLAN.L.ST.GEORGE at leidos.com (St. George, Allan L.) Date: Thu, 27 Mar 2014 20:37:42 +0000 Subject: [Rdo-list] Firewall issue/error when spawning instances on compute node Message-ID: Currently running RDO/Havana deployed via Foreman on a multi-compute node stack (Controller, Neutron, and three Nova-Compute servers) When spawning an instance, it correctly spawns and reports/registers to the Foreman dashboard. The problem is that the hypervisor/compute-node that is hosting the instance will then begin to report: Level Resource message err Puppet Could not prefetch firewall provider 'iptables': Invalid address from IPAddr.new: FA:16:3E:67:64:A4 err /Firewall[001 nova compute incoming] Could not evaluate: Invalid address from IPAddr.new: FA:16:3E:67:64:A4 err /Firewall[002 vxlan udp] Could not evaluate: Invalid address from IPAddr.new: FA:16:3E:67:64:A4 When the instance is deleted, the error will disappear also. Any assistance/insight would be appreciated. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at andrewklau.com Thu Mar 27 22:36:47 2014 From: andrew at andrewklau.com (Andrew Lau) Date: Fri, 28 Mar 2014 09:36:47 +1100 Subject: [Rdo-list] Timed out waiting for nova-conductor. w/ icehouse-3 and foreman In-Reply-To: References: Message-ID: Disregard that, my kickstart files were still pointing to the havana repo. It's all working now :) On Thu, Mar 27, 2014 at 9:20 PM, Andrew Lau wrote: > Some extra info, > > I bundle compute+networking into one hostgroup, again worked fine in > havana and icehouse-2 > > The interesting thing to note, Neutron on the compute node seems to show > up fine. I see the l3-agent, dhcp, ovs etc. under the system info tab. > > > On Thu, Mar 27, 2014 at 9:18 PM, Andrew Lau wrote: > >> Hi, >> >> I tried to deploy RDO icehouse-3 using foreman on CentOS 6.5, previously >> I had success with Havana and icehouse-2 >> >> Everything went smoothly, and quite a few of the issues I had with >> icehouse-2 were gone! >> >> The only non-puppet task I had to do was on the controller: >> >> cat < /etc/mysql/conf.d/innodb.cnf >> [mysqld] >> default-storage-engine = innodb >> EOF >> >> service mysqld restart >> >> mysql -e 'drop database neutron; create database neutron;' >> >> However, I've hit a blocker with nova compute not showing up into the >> controller. The only thing useful I can find in the nova-compute logs, >> >> " >> Timed out waiting for nova-conductor. Is it running? Or did this service >> start before nova-conductor? >> " >> >> Both nova-compute (on the compute) and nova-conductor (on the controller) >> said "AMQP connected" after a service restart, so I'm not sure what's gone >> wrong here. >> >> Suggestions? >> >> Thanks, >> Andrew >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at andrewklau.com Thu Mar 27 23:08:15 2014 From: andrew at andrewklau.com (Andrew Lau) Date: Fri, 28 Mar 2014 10:08:15 +1100 Subject: [Rdo-list] Firewall issue/error when spawning instances on compute node In-Reply-To: References: Message-ID: Hi, I saw this issue too, I was just about to report it. If I understand correctly, this is because of the openvswitch iptables rules which are created (for security groups?) `service iptables status` ... Chain neutron-openvswi-s0ec3eb58-0 (1 references) num target prot opt source destination 1 RETURN all -- 10.0.0.12 0.0.0.0/0 MAC FA:16:3E:2E:B7:E3 2 DROP all -- 0.0.0.0/0 0.0.0.0/0 .... In your case, the MAC address is different -- FA:16:3E:67:64:A4 This issue also appears on icehouse w/ foreman, so it looks like it may be the puppet modules at fault here Andrew. On Fri, Mar 28, 2014 at 7:37 AM, St. George, Allan L. < ALLAN.L.ST.GEORGE at leidos.com> wrote: > Currently running RDO/Havana deployed via Foreman on a multi-compute > node stack (Controller, Neutron, and three Nova-Compute servers) > > > > When spawning an instance, it correctly spawns and reports/registers to > the Foreman dashboard. > > > > The problem is that the hypervisor/compute-node that is hosting the > instance will then begin to report: > > > > *Level* > > *Resource* > > *message* > > *err* > > Puppet > > Could not prefetch firewall provider 'iptables': Invalid address from > IPAddr.new: FA:16:3E:67:64:A4 > > *err* > > /Firewall[001 nova compute incoming] > > Could not evaluate: Invalid address from IPAddr.new: FA:16:3E:67:64:A4 > > *err* > > /Firewall[002 vxlan udp] > > Could not evaluate: Invalid address from IPAddr.new: FA:16:3E:67:64:A4 > > > > When the instance is deleted, the error will disappear also. > > > > Any assistance/insight would be appreciated. > > > > Thank you. > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kimi.zhang at nsn.com Fri Mar 28 10:08:12 2014 From: kimi.zhang at nsn.com (Zhang, Kimi (NSN - FI/Espoo)) Date: Fri, 28 Mar 2014 10:08:12 +0000 Subject: [Rdo-list] Multicast does not work with ML2/VxLAN In-Reply-To: References: Message-ID: <90CF2062F86FD8498897037C7FBBC088086CB808@SGSIMBX001.nsn-intra.net> Hi, I am trying ML2/VXLAN on RDO Havana 2013.2.2 on CentOS 6.5 in a 3-nodes setup. OVS version is 1.11.0. I enable multicast by setting vxlan_group = 239.1.1.1 in /etc/neutron/plugins/ml2/ml2_conf.ini. But from the tcpdump, I find the VM broadcast traffic still goes via multiple unicast packages between OVS agent nodes. How to make that multicast really work ? My ml2_confi.ini: [ml2] type_drivers = vxlan tenant_network_types = vxlan mechanism_drivers = openvswitch [ml2_type_flat] [ml2_type_vlan] [ml2_type_gre] [ml2_type_vxlan] vni_ranges = 1001:2000 vxlan_group = 239.1.1.1 [database] sql_connection = mysql://neutron:83105f1d6ded47cc at 10.142.0.101/neutron_ml2 [securitygroup] firewall_driver = dummy_value_to_enable_security_groups_in_server My ovs_neutron_plugin.ini on every OVS agent node: [OVS] vxlan_udp_port=4789 tunnel_type=vxlan tunnel_id_ranges=1001:2000 tenant_network_type=vxlan local_ip=10.142.255.101 #This varies on different node enable_tunneling=True [AGENT] tunnel_types = vxlan polling_interval=2 [SECURITYGROUP] firewall_driver=neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver Kimi From morazi at redhat.com Fri Mar 28 12:30:07 2014 From: morazi at redhat.com (Mike Orazi) Date: Fri, 28 Mar 2014 08:30:07 -0400 Subject: [Rdo-list] Timed out waiting for nova-conductor. w/ icehouse-3 and foreman In-Reply-To: References: Message-ID: <53356B4F.8050803@redhat.com> On 03/27/2014 06:36 PM, Andrew Lau wrote: > Disregard that, my kickstart files were still pointing to the havana > repo. It's all working now :) > Glad to hear this got resolved! Thanks for kicking the tires, the initial report, and the update. I really appreciate your involvement as it is helping us improve daily. - Mike > On Thu, Mar 27, 2014 at 9:20 PM, Andrew Lau > wrote: > > Some extra info, > > I bundle compute+networking into one hostgroup, again worked fine in > havana and icehouse-2 > > The interesting thing to note, Neutron on the compute node seems to > show up fine. I see the l3-agent, dhcp, ovs etc. under the system > info tab. > > > On Thu, Mar 27, 2014 at 9:18 PM, Andrew Lau > wrote: > > Hi, > > I tried to deploy RDO icehouse-3 using foreman on CentOS 6.5, > previously I had success with Havana and icehouse-2 > > Everything went smoothly, and quite a few of the issues I had > with icehouse-2 were gone! > > The only non-puppet task I had to do was on the controller: > > cat < /etc/mysql/conf.d/innodb.cnf > [mysqld] > default-storage-engine = innodb > EOF > > service mysqld restart > > mysql -e 'drop database neutron; create database neutron;' > > However, I've hit a blocker with nova compute not showing up > into the controller. The only thing useful I can find in the > nova-compute logs, > > " > Timed out waiting for nova-conductor. Is it running? Or did this > service start before nova-conductor? > " > > Both nova-compute (on the compute) and nova-conductor (on the > controller) said "AMQP connected" after a service restart, so > I'm not sure what's gone wrong here. > > Suggestions? > > Thanks, > Andrew > > > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > From sgordon at redhat.com Fri Mar 28 21:54:19 2014 From: sgordon at redhat.com (Steve Gordon) Date: Fri, 28 Mar 2014 17:54:19 -0400 (EDT) Subject: [Rdo-list] New and improved OpenStack User Survey! In-Reply-To: <293005337.7585949.1396043549370.JavaMail.zimbra@redhat.com> Message-ID: <1936705219.7586626.1396043659855.JavaMail.zimbra@redhat.com> Hi all, Just a quick note to highlight that the OpenStack User Survey is back and better than ever with a few extra sections in response to feedback from previous rounds. This data helps the community shape OpenStack so if you are an OpenStack deployer, operator, user, or application developer be sure to head over and have your say: https://www.openstack.org/user-survey/ Thanks, Steve From andrew at andrewklau.com Sat Mar 29 00:06:37 2014 From: andrew at andrewklau.com (Andrew Lau) Date: Sat, 29 Mar 2014 11:06:37 +1100 Subject: [Rdo-list] Firewall issue/error when spawning instances on compute node In-Reply-To: References: Message-ID: I opened a BZ here https://bugzilla.redhat.com/show_bug.cgi?id=1082188 Did you also run into this issue too, https://bugzilla.redhat.com/show_bug.cgi?id=1082187 On Sat, Mar 29, 2014 at 2:00 AM, St. George, Allan L. < ALLAN.L.ST.GEORGE at leidos.com> wrote: > I can confirm that I have the same issue on the hypervisor/nova-compute > node that is hosting the instance... > > Chain neutron-openvswi-sd7933aba-f (1 references) > num target prot opt source destination > 1 RETURN all -- 10.0.0.6 0.0.0.0/0 MAC > FA:16:3E:67:64:A4 > 2 DROP all -- 0.0.0.0/0 0.0.0.0/0 > > > How do we get someone to look at the problem for patching? This > obviously wasn't identified and was carried over to the new build. > > - Allan > > ------------------------------ > > Hi, > > I saw this issue too, I was just about to report it. > > If I understand correctly, this is because of the openvswitch iptables > rules which are created (for security groups?) > > `service iptables status` > ... > Chain neutron-openvswi-s0ec3eb58-0 (1 references) > num target prot opt source destination > 1 RETURN all -- 10.0.0.12 0.0.0.0/0 MAC > FA:16:3E:2E:B7:E3 > 2 DROP all -- 0.0.0.0/0 0.0.0.0/0 > .... > > In your case, the MAC address is different -- FA:16:3E:67:64:A4 > > This issue also appears on icehouse w/ foreman, so it looks like it may > be the puppet modules at fault here > > Andrew. > > > On Fri, Mar 28, 2014 at 7:37 AM, St. George, Allan L. < > ALLAN.L.ST.GEORGE at leidos.com> wrote: > >> Currently running RDO/Havana deployed via Foreman on a multi-compute >> node stack (Controller, Neutron, and three Nova-Compute servers) >> >> >> >> When spawning an instance, it correctly spawns and reports/registers to >> the Foreman dashboard. >> >> >> >> The problem is that the hypervisor/compute-node that is hosting the >> instance will then begin to report: >> >> >> >> *Level* >> >> *Resource* >> >> *message* >> >> *err* >> >> Puppet >> >> Could not prefetch firewall provider 'iptables': Invalid address from >> IPAddr.new: FA:16:3E:67:64:A4 >> >> *err* >> >> /Firewall[001 nova compute incoming] >> >> Could not evaluate: Invalid address from IPAddr.new: FA:16:3E:67:64:A4 >> >> *err* >> >> /Firewall[002 vxlan udp] >> >> Could not evaluate: Invalid address from IPAddr.new: FA:16:3E:67:64:A4 >> >> >> >> When the instance is deleted, the error will disappear also. >> >> >> >> Any assistance/insight would be appreciated. >> >> >> >> Thank you. >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at andrewklau.com Sat Mar 29 00:14:20 2014 From: andrew at andrewklau.com (Andrew Lau) Date: Sat, 29 Mar 2014 11:14:20 +1100 Subject: [Rdo-list] Timed out waiting for nova-conductor. w/ icehouse-3 and foreman In-Reply-To: <53356B4F.8050803@redhat.com> References: <53356B4F.8050803@redhat.com> Message-ID: On Fri, Mar 28, 2014 at 11:30 PM, Mike Orazi wrote: > On 03/27/2014 06:36 PM, Andrew Lau wrote: > > Disregard that, my kickstart files were still pointing to the havana > > repo. It's all working now :) > > > > Glad to hear this got resolved! > > Thanks for kicking the tires, the initial report, and the update. I > really appreciate your involvement as it is helping us improve daily. > > - Mike > > Pleasure! I've added my notes to the test-day app, I meant to open a report for just CentOS 6.5 but some reason it has duplicated across to the other reports. Hope I didn't break something.. > > On Thu, Mar 27, 2014 at 9:20 PM, Andrew Lau > > wrote: > > > > Some extra info, > > > > I bundle compute+networking into one hostgroup, again worked fine in > > havana and icehouse-2 > > > > The interesting thing to note, Neutron on the compute node seems to > > show up fine. I see the l3-agent, dhcp, ovs etc. under the system > > info tab. > > > > > > On Thu, Mar 27, 2014 at 9:18 PM, Andrew Lau > > wrote: > > > > Hi, > > > > I tried to deploy RDO icehouse-3 using foreman on CentOS 6.5, > > previously I had success with Havana and icehouse-2 > > > > Everything went smoothly, and quite a few of the issues I had > > with icehouse-2 were gone! > > > > The only non-puppet task I had to do was on the controller: > > > > cat < /etc/mysql/conf.d/innodb.cnf > > [mysqld] > > default-storage-engine = innodb > > EOF > > > > service mysqld restart > > > > mysql -e 'drop database neutron; create database neutron;' > > > > However, I've hit a blocker with nova compute not showing up > > into the controller. The only thing useful I can find in the > > nova-compute logs, > > > > " > > Timed out waiting for nova-conductor. Is it running? Or did this > > service start before nova-conductor? > > " > > > > Both nova-compute (on the compute) and nova-conductor (on the > > controller) said "AMQP connected" after a service restart, so > > I'm not sure what's gone wrong here. > > > > Suggestions? > > > > Thanks, > > Andrew > > > > > > > > > > > > _______________________________________________ > > Rdo-list mailing list > > Rdo-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ALLAN.L.ST.GEORGE at leidos.com Mon Mar 31 11:29:06 2014 From: ALLAN.L.ST.GEORGE at leidos.com (St. George, Allan L.) Date: Mon, 31 Mar 2014 11:29:06 +0000 Subject: [Rdo-list] Firewall issue/error when spawning instances on compute node In-Reply-To: References: , Message-ID: Sorry, not using Horizon. Currently just trying to get a reliable OpenStack deployment via Foreman. What I am experiencing is neutron-dhcp-agent will occasionally stop assigning addresses to spawning instances and I'll have to restart the service. Nothing is noted in the log. - Allan ________________________________ From: Andrew Lau [andrew at andrewklau.com] Sent: Friday, March 28, 2014 8:06 PM To: St. George, Allan L.; rdo-list at redhat.com Subject: Re: [Rdo-list] Firewall issue/error when spawning instances on compute node I opened a BZ here https://bugzilla.redhat.com/show_bug.cgi?id=1082188 Did you also run into this issue too, https://bugzilla.redhat.com/show_bug.cgi?id=1082187 On Sat, Mar 29, 2014 at 2:00 AM, St. George, Allan L. > wrote: I can confirm that I have the same issue on the hypervisor/nova-compute node that is hosting the instance... Chain neutron-openvswi-sd7933aba-f (1 references) num target prot opt source destination 1 RETURN all -- 10.0.0.6 0.0.0.0/0 MAC FA:16:3E:67:64:A4 2 DROP all -- 0.0.0.0/0 0.0.0.0/0 How do we get someone to look at the problem for patching? This obviously wasn't identified and was carried over to the new build. - Allan ________________________________ Hi, I saw this issue too, I was just about to report it. If I understand correctly, this is because of the openvswitch iptables rules which are created (for security groups?) `service iptables status` ... Chain neutron-openvswi-s0ec3eb58-0 (1 references) num target prot opt source destination 1 RETURN all -- 10.0.0.12 0.0.0.0/0 MAC FA:16:3E:2E:B7:E3 2 DROP all -- 0.0.0.0/0 0.0.0.0/0 .... In your case, the MAC address is different -- FA:16:3E:67:64:A4 This issue also appears on icehouse w/ foreman, so it looks like it may be the puppet modules at fault here Andrew. On Fri, Mar 28, 2014 at 7:37 AM, St. George, Allan L. > wrote: Currently running RDO/Havana deployed via Foreman on a multi-compute node stack (Controller, Neutron, and three Nova-Compute servers) When spawning an instance, it correctly spawns and reports/registers to the Foreman dashboard. The problem is that the hypervisor/compute-node that is hosting the instance will then begin to report: Level Resource message err Puppet Could not prefetch firewall provider 'iptables': Invalid address from IPAddr.new: FA:16:3E:67:64:A4 err /Firewall[001 nova compute incoming] Could not evaluate: Invalid address from IPAddr.new: FA:16:3E:67:64:A4 err /Firewall[002 vxlan udp] Could not evaluate: Invalid address from IPAddr.new: FA:16:3E:67:64:A4 When the instance is deleted, the error will disappear also. Any assistance/insight would be appreciated. Thank you. _______________________________________________ Rdo-list mailing list Rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list -------------- next part -------------- An HTML attachment was scrubbed... URL: