15:01:10 <jmorgan1> #startmeeting OPNFV Infra Work Group
15:01:10 <collabot> Meeting started Wed Aug 10 15:01:10 2016 UTC.  The chair is jmorgan1. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:10 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:01:10 <collabot> The meeting name has been set to 'opnfv_infra_work_group'
15:01:23 <jmorgan1> #topic role call
15:01:29 <jmorgan1> #info Jack Morgan
15:02:21 <bramwelt> #info Trevor Bramwell
15:02:28 <ulik> #info Uli Kleber
15:02:46 <ulik> I am still on another meeting with audio. Will join audio later.
15:02:47 <fdegir> #info Fatih Degirmenci
15:02:51 <ChrisPriceAB> #info Chris price
15:04:16 <DanSmithEricsson> #info Dan Smith
15:05:20 <jmorgan1> #topic opens
15:24:06 <fdegir> I think what Daniel explains is similar to what I written
15:24:09 <fdegir> https://wiki.opnfv.org/display/INF/Lab+as+a+Service#LabasaService-LaaSFlowProposal
15:28:37 <Julien-zte> #info Julien
15:29:18 <jmorgan1> #topic Pharos specification
15:29:22 <DanSmithEricsson> I took it from you stuff.. i think its all great work, but i would think we are better served by getting the bigger picture a bit clear before we give sub-project tasks... cause if we do it bottom up we are going to arrive at a point where we have to do interface mediation (to get stuff to talk) and i think we would be better served by setting the concrete vision of what we want ot get fore the end of the year for example
15:31:12 <jmorgan1> #info Aric networking needs some help and points out some errors
15:33:56 <jmorgan1> #Action Aric to post something to the mailing list for input from the community
15:35:35 <jmorgan1> #info Daniel points out that the specification should be very generic in its definitions
15:42:16 <ChrisPriceAB> #info all rendered documents are presented in HTML form on the artifect.opnfv.org links, they can be imported or linked to from the wiki.
15:42:25 <ChrisPriceAB> #undo
15:42:33 <ChrisPriceAB> #info all rendered documents are presented in HTML form on the artifacts.opnfv.org links, they can be imported or linked to from the wiki.
15:42:56 <DanSmithEricsson> hey tehre.
15:43:04 <aricg> is there something not here?: http://artifacts.opnfv.org/pharos/docs/index.html
15:43:08 <DanSmithEricsson> well. it seems that the PHAROS SPEC thta was released and documented for ARNO and B are not longer there
15:43:19 <DanSmithEricsson> cause the original diagras of our specification are now gone
15:43:28 <DanSmithEricsson> the new specification goes into far too much detail and is not generic
15:43:51 <DanSmithEricsson> in fact, it outlines installing CENTOS - which is a deployment task and should be seperated from a Specification
15:44:14 <DanSmithEricsson> meaning a "specificatoin" is a model /example - it doesnt include actions, tasks to "do thing" its of a picture to compare against
15:44:19 <ChrisPriceAB> #link http://artifacts.opnfv.org/pharos/docs/specification/index.html the pharos spec on master
15:44:32 <aricg> ChrisPriceAB: https://global.gotomeeting.com/join/773318405
15:44:39 <DanSmithEricsson> and as we have said from the start of OPNFV - no comments on speed, hw type, breakdown or density.. just nodes, interfaces and fabric.
15:45:38 <ChrisPriceAB> made it there thanks aricg
15:46:36 <jmorgan1> I lost audio
15:46:50 <jmorgan1> need to logout and login
15:46:56 <jmorgan1> can someone take over the meeting?
15:52:37 <aricg> fking gotomeeting..
15:52:42 <DanSmithEricsson> ok.. well the meeting droped
15:52:46 <DanSmithEricsson> to answer the last question
15:52:51 <ChrisPriceAB> lol, Jack had to go and he took us with him.  :)
15:52:52 <Julien-zte> dropped all of us:)
15:52:58 <DanSmithEricsson> eash installer erleeased their installed version of how to do deployments
15:53:03 <DanSmithEricsson> per installer per scenario
15:53:14 <DanSmithEricsson> these are all derived first from the pharos spec
15:53:28 <lylavoie> Did everyone else just get dropped from the GoTo?
15:53:31 <DanSmithEricsson> the pharos grouup shoult NOT (imho) being saying "how to do things"
15:53:44 <bramwelt> I think keeping the Pharos spec generic and as simple as possible is good, but what should exist it examples or documentation for community members to gauge what the minimum hardware requirements are they need to have.
15:53:47 <DanSmithEricsson> that is derived directly from PHAROS spec, then augmented per installer per scneario
15:54:01 <DanSmithEricsson> for deployment types/ expamples - these are owned by uinstallers
15:54:08 <DanSmithEricsson> who release their recommended deployment types
15:54:09 <aricg> It would be good to have both a generic overview, and some user stories, as bramwelt was saying.
15:54:14 <DanSmithEricsson> and these types are all based off a common PAHROS spec
15:54:25 <DanSmithEricsson> otherwise the PHAROS starts doing.. FOr ApEX with XYZ, you need
15:54:29 <DanSmithEricsson> for FUEL wiht XYZ you needd
15:54:35 <DanSmithEricsson> and that is not what i think we want to position pharos to be
15:54:50 <DanSmithEricsson> pharos should provide generic hw/infratructure topologies that are common demoninators
15:55:00 <DanSmithEricsson> of all the current scnerio useages
15:55:06 <lylavoie> I would suggest Pharos specifies a set of minimums for the Jump and Nodes, I.E. CPU horsepower, RAM, min disk space (and type if needs SSD vs. Spinning metal), and the minimum needs for the network (i.e. how many nics, and some speeds).
15:55:11 <DanSmithEricsson> when a new one comes up , then a spec CR change need to be touched
15:55:24 <DanSmithEricsson> the minimum requipremnts to run openstack itself, also change per insatller
15:55:36 <lylavoie> I think the switch sizes scales based on the number of nodes (the minimum number should also be specified)
15:55:39 <DanSmithEricsson> so the PHAROS spec is generic enough to encompass all installers.
15:55:45 <Julien-zte> for installers, we also hope to use generic configuration. in the future I hope the same configuration hardware(meet with pharos spec) will be supported by all the installers
15:55:46 <DanSmithEricsson> again - we dont specific size of deploymetn
15:55:51 <DanSmithEricsson> we specify either a nested steup
15:55:55 <DanSmithEricsson> opr a Baremetal HA setupw
15:55:57 <DanSmithEricsson> with 5 nodes
15:56:00 <DanSmithEricsson> and that is what is tested agin
15:56:08 <DanSmithEricsson> what happens whe they install a 48node system with our spe
15:56:13 <DanSmithEricsson> and it doesnt work beyong 10 nodes
15:56:16 <DanSmithEricsson> cause we havent tested it
15:56:20 <DanSmithEricsson> but we said it in our spec?
15:56:23 <DanSmithEricsson> how will that work?
15:56:34 <jmorgan1> ok, coming back online. one second...
15:57:01 <Julien-zte> we can list the requriment of ports for switch(using something formula?)
15:57:11 <DanSmithEricsson> there is no formula
15:57:13 <DanSmithEricsson> cause it depend
15:57:18 <DanSmithEricsson> for the spec
15:57:30 <DanSmithEricsson> we know tht each deployment much provide the basic Ostack networks (5 of thme)
15:57:37 <DanSmithEricsson> they need to be tagged or untagged depending on installer
15:57:37 <Julien-zte> yes, we can no in the future
15:57:57 <DanSmithEricsson> i dont think that as a pharos group we should be touching on specifying deployment size
15:58:00 <DanSmithEricsson> and how to setup HW
15:58:12 <DanSmithEricsson> its not like we can support deployment types (have a standrad to work against).
15:58:21 <Julien-zte> does 5 nodes is our specification?
15:58:28 <DanSmithEricsson> so if we say " you need 2 48 ports switches, x number of servers, etc) then we are precluindg a spe
15:58:30 <Julien-zte> then we can focus on this
15:58:30 <DanSmithEricsson> yes - it does
15:58:44 <DanSmithEricsson> and there were lots of diagrams and pictures outlining the server
15:58:45 <DanSmithEricsson> the netowrks
15:58:51 <DanSmithEricsson> and the interfactions in a generic manner
15:58:53 <DanSmithEricsson> since that is what we test
15:59:06 <DanSmithEricsson> to change this an dsay " ow we are going to provide BoM for a new lab" for epople to borrow
15:59:25 <DanSmithEricsson> especially when its not something that we actually test ouselves (we dont do a full 16 blades, 100% switch test)
15:59:31 <DanSmithEricsson> takes us to a scarey place i think
15:59:42 <DanSmithEricsson> <i cant get back into the GTM>
15:59:42 <jmorgan1> meting back online
15:59:47 <lylavoie> Danial, I don't see how specifying a minimum rules out the lager deployments
16:00:15 <Julien-zte> gtm is ok now
16:00:25 <DanSmithEricsson> how is a 49 port switch with 1G or 10G nic defintion a minimum
16:00:32 <DanSmithEricsson> we have a minimum in place that was documented
16:00:42 <DanSmithEricsson> the pharos sepc is 5 nodes, with the incs and nodes defined with a minim RAM/CPU and such
16:00:50 <DanSmithEricsson> that has been set for a while.. so if that is to change then that is fine as well
16:01:19 <DanSmithEricsson> but its important to understand that we then a) unhook this from what we actually test and b) we appar to define more than a generic topology - we are defined a deployment type
16:01:44 <lylavoie> Danial, I'm not talking about what is there now, I suggesting we define the minimum as what should be there and update the pages to reflect that
16:01:47 <DanSmithEricsson> if you are generic then its "X number of server w/ minimum Ostack requirements" + Y number of NICs (based on the OPNFV Network schema we outlined) + etc
16:01:56 <DanSmithEricsson> very good..
16:02:03 <DanSmithEricsson> im just saying that its there already
16:02:10 <DanSmithEricsson> the "minimum" and has been for 3 years now
16:02:35 <DanSmithEricsson> and if we are going to change that to specify Swiotch sizes, hw and deployment choice (HA/ SA)then we need to make sure that it filters down to the INstallers
16:02:50 <DanSmithEricsson> since they have used our original spec as how they have built their testing and deployments
16:03:04 <DanSmithEricsson> so the PHAROS spec above all else should match what our develped and CI/CD is tesing on
16:03:11 <DanSmithEricsson> and not be a specification away from that at all
16:03:13 <jmorgan1> sorry, we didn't have time to go over JIRA stuff.
16:03:28 <DanSmithEricsson> no sweat.
16:03:35 <DanSmithEricsson> i tihnk that perhaps a review of the overall goal is needed first
16:03:45 <DanSmithEricsson> we have alto of theads running and they are going in differnet directions
16:03:52 <jmorgan1> i did notice there was a change to the jira default workflow
16:03:55 <DanSmithEricsson> my JIRA stuff would have brought up more questions today
16:04:04 <DanSmithEricsson> there should have been nothing to default
16:04:10 <DanSmithEricsson> since all work was done in a example project
16:04:25 <jmorgan1> "in progress" is not "request analysis"
16:04:27 <DanSmithEricsson> and nothing outside of the LABEREQ - so if there was a change to anythign current in operation then it wasnt done by me
16:04:35 <DanSmithEricsson> I dont use In progress.
16:04:45 <DanSmithEricsson> can you provide the link to what you are looking at?
16:04:48 <jmorgan1> but i think your change affected all projects
16:04:52 <DanSmithEricsson> i shoudl not have
16:05:01 <DanSmithEricsson> since i worked soley in LABREQ project and that flow
16:05:08 <DanSmithEricsson> and in fact, i double checked all the flows afterwards
16:05:10 <jmorgan1> for "in progess" so mentioning it
16:05:15 <Julien-zte> yeh, I find most of the projects are changed the procedure
16:05:21 <DanSmithEricsson> what pages?
16:05:25 <DanSmithEricsson> ARic - can you help me chase that?
16:05:34 <aricg> DanSmithEricsson: yes
16:05:37 <DanSmithEricsson> since i did a workflow development in LABREQ project
16:05:46 <DanSmithEricsson> this should not (and i made sure) have bled into anything else.
16:05:54 <aricg> DanSmithEricsson: I will double check
16:05:57 <DanSmithEricsson> (agin - probably another reason to have a sandbox)
16:06:09 <jmorgan1> take a look at https://jira.opnfv.org/browse/PHAROS-65
16:06:12 <DanSmithEricsson> i mean, the edits are all incremented so if it did bleee,d we can roll it back
16:06:38 <jmorgan1> it shows "request analysis" in stead of "in progress"
16:06:48 <jmorgan1> we might need Aric to take a look
16:06:57 <jmorgan1> should be easy to adjust/fix
16:07:03 <DanSmithEricsson> yup
16:07:07 <DanSmithEricsson> ok.. i think i see what you mean
16:07:31 <DanSmithEricsson> ya.. that is strange.. it shouldnt have propagated that .. in the end i think the issue is the "allow all to transition".
16:07:54 <DanSmithEricsson> anyway-  that text is a label, so we can fix it - or i can just wipe the LAQREQ stuff out and revert as you like
16:08:04 <jmorgan1> right, jira is good like that
16:08:11 <DanSmithEricsson> and we can tackle this a differente way once we have had a chance to review all the initiaves
16:08:12 <jmorgan1> just wanted to point it out
16:08:37 <DanSmithEricsson> since to be honest, my presentation for the JIRA flow will need to have some of the other items (booking tool) sorts
16:08:46 <DanSmithEricsson> its a good point jack -Aric and I will try to fix
16:08:51 <jmorgan1> also, you might take a look at this filter
16:08:59 <jmorgan1> https://jira.opnfv.org/issues/?jql=filter%3D11136%20
16:09:16 <DanSmithEricsson> ?
16:09:19 <jmorgan1> some items that might eventual move to this infra project
16:09:38 <jmorgan1> or lab requests tickets in the pharos jira project
16:10:34 <jmorgan1> i added a "lab_request" label to tickets that fall into that category for easy clean up on our side
16:11:50 <DanSmithEricsson> ok..
16:12:02 <jmorgan1> thanks
16:12:06 <DanSmithEricsson> well i think that we have about 10 different ways we are trying to approach everything
16:12:28 <DanSmithEricsson> i have a JIRA way for lab requests (second iteratoin) you are adding tags, we have th ebooking tool and we have the othr labs
16:12:47 <DanSmithEricsson> the idea i though was working towards a Booking tool, for a common place for all requests
16:13:12 <DanSmithEricsson> and then hooking that ito JIRA for tracking or tracing, and then evenutally to a BarMetal controller (that will do the blades and switch setup ) on demand.. a
16:13:19 <jmorgan1> i just added the "lab_request" label to help me sort those jira tickets in the pharos project that might go to infra jira project
16:13:28 <jmorgan1> i don't plan to use it long term
16:13:44 <DanSmithEricsson> ad i think the vision is still there. however im not convinced that doing this with 20initative at the same time and meeting together in the middle is the rigt approach.. but letsse ee
16:13:46 <jmorgan1> sounds good to me
16:14:12 <DanSmithEricsson> have your meeting next week - lets find out what happenned to the 2 yeasr of specification that we have provided.. that informatino needs to be found caue its what we have all built from (in our docs)
16:14:27 <DanSmithEricsson> so if that is gone - and we are doing a 'new specificino", then i think we are going to have some issue
16:14:32 <DanSmithEricsson> have a nice day
16:14:39 <jmorgan1> right, you too
16:15:12 <jmorgan1> #endmeeting