[onap-discuss] Proposal for list split of onap-discuss

2017-04-20 Thread Aimee Ukasick
The idea of a mailing list for each project and working group makes me
shudder and quake uncontrollably. It's an infra and end user nightmare!

There are many messages in openstack-dev and opnfv-tech-discuss with
multiple projects/working groups in the subject line. With one mailing
list for each project and working group, a single email affecting
multiple projects would have to be sent to several mailing lists.
Tracking replies becomes a nightmare - what if a user sends a reply but
not to all the mailing lists? How are recipients supposed to know a
reply was not made to all of the "to" lists? Some days it's hard enough
keeping track of a thread on a single mailing list - please let's not
add a layer of complexity by having to keep track of a single subject
sent to multiple project email lists.

-
Aimee Ukasick
Open Source Engagement OPNFV, OpenStack, ONAP
IRC: aimeeu

On 04/20/2017 02:29 PM, Gildas Lanilis wrote:
> Let me share my experience with mailing list per project:
> Even though developers requested for specific mailing list, they hate it. Why:
> 
> 1.   They had to register in all the mailing lists. Too cumbersome.  So 
> most of them did not register
> 
> 2.   As they did not register in mailing list, other folks took the habit 
> to add them separately in To or Cc. And then the Moderator?s misery started.
> 
> 3.   The list of folks added separately to the mailing list grew quickly 
> and hit the max allowed by Linux Foundation (10 recipients). Thus requiring 
> the Moderator to review and accept the message. Impact: delay on the 
> responses.
> 
> 4.   As the folks were not systematically in the mailing list but still 
> used it (by pressing Reply All), by policy (to avoid spam) Linux Foundation 
> requested the Moderator to again review and accept the message. Impact: delay 
> on the responses.
> 
> I start liking the Topic. It requires a bit of discipline but it makes things 
> working better for all who can enjoy the art of filtering.
> 
> Thanks,
> Gildas
> 
> From: onap-discuss-bounces at lists.onap.org [mailto:onap-discuss-bounces at 
> lists.onap.org] On Behalf Of SULLIVAN, BRYAN L
> Sent: Thursday, April 20, 2017 11:38 AM
> To: Ed Warnicke; Andrew Grimberg
> Cc: onap-discuss
> Subject: Re: [onap-discuss] Proposal for list split of onap-discuss
> 
> The flip side (just to be considered in the supporting infra) is that it?s 
> not hard for projects to become disconnected when segregated. 
> Needing/managing many project email list subscriptions inhibits the ability 
> to easily keep an overview of how things are progressing across projects. Of 
> course at some point, the firehose becomes unmanageable and the demands of 
> focus require segregation.
> 
> But some infra support can address the limitations of project-specific lists:
> 
> -  Mail subscription system (e.g. http://lists.onap.org) support for 
> a ?auto-subscribe to all? option for those who want it.
> 
> -  Mail archive system that supports an effective search, e.g. the 
> W3C system: https://www.w3.org/Search/Mail/Public/
> 
> o   Mailman is woefully inadequate for this. Some services exist that could 
> possibly be used for this, e.g. http://openstack.markmail.org/search/?q= 
> works well for me, for OpenStack in general.
> 
> o   Note that you can also just subscribe using some email service ala Gmail 
> or Hotmail, that provides a search feature that works for you. That can 
> completely solve your corporate inbox issue, given that you?re allowed to use 
> non-corporate email services for open source work.
> 
> If we want to create project-specific lists, I recommend that the LF work on 
> the two supporting infra capabilities above, or include workarounds such as 
> above in developer intros/FAQs.
> 
> Thanks,
> Bryan Sullivan | AT&T
> 
> From: onap-discuss-bounces at lists.onap.org [mailto:onap-discuss-bounces at 
> lists.onap.org] On Behalf Of Ed Warnicke
> Sent: Thursday, April 20, 2017 10:46 AM
> To: Andrew Grimberg 
> Cc: onap-discuss 
> Subject: Re: [onap-discuss] Proposal for list split of onap-discuss
> 
> I hit a situation just yesterday where there was literally no reasonable way 
> to address a sub-community of openstack because they have
> a giant monster mailer, and thus there was no reasonable way to address the 
> interested subcommunity.
> 
> Monster mega lists suppress conversation.  Give each project their own space 
> for their community to talk.
> 
> Ed
> 
> On Thu, Apr 20, 2017 at 10:34 AM, Andrew Grimberg  linuxfoundation.org<mailto:agrimberg at linuxfoundation.org>> wrote:
> On 04/20/2017 09:46 AM, Ed Warnicke wrote:
>> Josef,
>>
>> I couldn't agree mor

[onap-discuss] Proposal for list split of onap-discuss

2017-04-20 Thread Aimee Ukasick
On 04/20/2017 02:44 PM, Ed Warnicke wrote:
> Thinking outloud... it almost feels like mailing lists as a tool are no
> longer a good fit to the need.
> 
> Is there another tool we could consider using?
> 
I personally like the idea of a discussion bulletin board/forum where
developers can ask for help and discuss ideas. Late last year, OPNFV
created a tech-discuss forum, but there has been little activity in it.
Developers seem to prefer email and IRC. Maybe using a forum would catch
on if the forum were created at inception instead of a couple of years
into the life of the project.


[1] https://techdiscuss.opnfv.org/

-

Aimee Ukasick
Open Source Engagement OPNFV, OpenStack, ONAP
IRC: aimeeu









[onap-discuss] Proposal for list split of onap-discuss

2017-04-20 Thread Aimee Ukasick
+1
Right now, the onap-discuss mailing list has 5 topics [1]:
admin
development
infrastructure
installation
users

People mailing the onap-discuss would need to create subject lines that
can be filtered, as we do OpenStack, OPNFV, and many other Open Source
communities [2].
ONAP examples:
[onap-discuss][admin]
[onap-discuss][development]
[onap-discuss][installation]
[onap-discuss][infrastructure]
[onap-discuss][users]

Also, the topic feature of mailman needs to be configured for individual
projects, ie:
demo
dcae
mso

Examples of project-specific subject lines:
[onap-discuss][demo]
[onap-discuss][dcae]
[onap-discuss][mso]

Users can then subscribe to specific filters as we all choosing to
receive emails that do not match a filter.

[1] https://lists.onap.org/mailman/options/onap-discuss
[2] https://wiki.openstack.org/wiki/MailingListEtiquette

Andy Grimberg - do you where I create a ticket to have projects added to
the onap-discuss top categories?

-
Aimee Ukasick
Open Source Engagement OPNFV, OpenStack, ONAP
IRC: aimeeu

On 04/20/2017 08:46 AM, Andrew Grimberg wrote:
> On 04/20/2017 03:16 AM, Josef Reisinger wrote:
>> Folks,
>>
>> good to see this huge activity on the list .. but honestly, it starts to
>> become overwhelming. What do you think about splitting the discussion
>> list in per-domain lists, i.e.
>> o onap-install for all topics regarding installation in openstack
>> (vanilla/rackspace)
>> o onap-admin for admin related task, if users in the portal are missing
>> etc...
>> o onap-develop for the ones interesting to develop onap core functions
>> o onap-users for the ones finally creating services using onap.
>>
>> I know there will be overlap here and there  - what's the view of the
>> community?
> 
> One of the things we've seen with our various communities is that the
> more mailing lists that they have the harder and more confusing it is
> for someone new to know where to send their questions and thus they end
> up cross-spamming to far more lists than they really need which ends up
> seeing the other lists getting a lot of chatter that they really don't need.
> 
> Instead of splitting the list, I would suggest that using the topic
> feature of mailman until we have a truly relevant need to split out a
> particular topic to its own list.
> 
> To help this along I've added a few topics to the list.
> 
> I'll see about adding information to the ONAP wiki, but in the mean time
> here [0] is some documentation from the OpenDaylight wiki on topics.
> 
> Topics just now added to the list are:
> 
> [admin]
> [devel]
> [infrastructure] or [infra]
> [install]
> [user] or [users]
> 
> At a very minimum if folks start using topics, even if they aren't
> specifically defined then it becomes easier for people to write mail
> filters to handle bringing mail that is more relevant to them into a
> more visible or manageable location.
> 
> -Andy-
> 
> [0] https://wiki.opendaylight.org/view/Communication
> 
> 
> 
> ___
> onap-discuss mailing list
> onap-discuss at lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
> 

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.onap.org/pipermail/onap-discuss/attachments/20170420/f45d13ec/attachment.sig>


[onap-discuss] Modelling discussion on Friday May 5th

2017-04-20 Thread Aimee Ukasick
A video bridge would be helpful also to be able to see shared materials
and/or whiteboard notes. Google Hangouts or something from Zoom?

Thanks.

Aimee Ukasick
Open Source Engagement OPNFV, OpenStack, ONAP
IRC: aimeeu

On 04/20/2017 07:46 AM, JANA, RITTWIK  (RITTWIK) wrote:
> Sure, we can setup an audio bridge for remote participants also. Thx
> Rittwik
> 
> 
> 
> Sent via the Samsung Galaxy S? 5 ACTIVE?, an AT&T 4G LTE smartphone
> 
> 
>  Original message 
> From: Anit Lohtia 
> Date: 4/20/17 7:51 AM (GMT-05:00)
> To: "denghui (L)" , onap-tsc at lists.onap.org, 
> onap-discuss at lists.onap.org
> Cc: "JANA, RITTWIK (RITTWIK)" 
> Subject: RE: Modelling discussion on Friday May 5th
> 
> Deng and Rittwik,
> 
> Will you able to set up an audio bridge for remote participants?
> 
> Thanks,
> 
> Anit
> 
> From: onap-discuss-bounces at lists.onap.org [mailto:onap-discuss-bounces at 
> lists.onap.org] On Behalf Of denghui (L)
> Sent: Thursday, April 20, 2017 3:35 AM
> To: denghui (L) ; onap-tsc at lists.onap.org; 
> onap-discuss at lists.onap.org
> Cc: JANA, RITTWIK (RITTWIK) 
> Subject: [onap-discuss] Modelling discussion on Friday May 5th
> 
> Hello all
> 
> We are happy to let you know that we are hosting a modeling session on 
> Friday, May 5th, AT&T Lab.
> 9:00-10:30 Shitao moderate: TOSCA NFV Profile
> 10:30-12:00 Rittwik moderate: AT&T Parser
> 13:30-16:00 DengHui moderate: Modelling & Opendeployment
> 
> Please kindly help to let us know if you are interested in joining us, so 
> that we can book a proper meeting room for our discussion
> 
> Best regards,
> 
> Rittwik & DENG Hui
> 
> Disclaimer:  This message and the information contained herein is proprietary 
> and confidential and subject to the Tech Mahindra policy statement, you may 
> review the policy at 
> http://www.techmahindra.com/Disclaimer.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.techmahindra.com_Disclaimer.html&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=g5seXX3-KPJ0bcoceVG5gqff_wk_0SftsTa5nghpRfQ&m=SVu9CpFCLjvoUMVOnaD-z5M06m57-MQtgt7Ch8Lw4Gc&s=JeNrJMmKiQF9VpyN2t-rksphXQeMq1T0_5YjmI7tApU&e=>
>  externally 
> http://tim.techmahindra.com/tim/disclaimer.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__tim.techmahindra.com_tim_disclaimer.html&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=g5seXX3-KPJ0bcoceVG5gqff_wk_0SftsTa5nghpRfQ&m=SVu9CpFCLjvoUMVOnaD-z5M06m57-MQtgt7Ch8Lw4Gc&s=2wQ3DiBw5T7hjJesbJShDrKHBPfzoA93Rlp76tbAdDw&e=>
>  internally within TechMahindra.
> 
> 
> 
> 
> ___
> onap-discuss mailing list
> onap-discuss at lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
> 


[onap-discuss] [demo] Minimum Resources for ONAP Demo?

2017-04-14 Thread Aimee Ukasick
Hi all - I have an all-virtual OPNFV Apex (Triple-O) installation
(OpenStack Newton) running on an Intel Intel(R) Xeon(R) CPU E5-2699 v4 @
2.20GHz server with 22 cores and 128 GB RAM.

Creation of the ONAP stack failed with:

Create_Failed: Resource CREATE failed: Forbidden: resources.sdc_vm:
Quota exceeded for cores: Requested 8, but already used 14 of 20 cores

What is the minimum hardware/resource configuration needed to create the
ONAP stack? I couldn't find anything documented on the wiki. I know
Release 1 is only supported on Rackspace infrastructure, but I'm having
trouble locating detailed resource requirements for the Rackspace public
cloud as well. Any help is appreciated.

Also, what environments has the demo been deployed on other than
Rackspace? It's my understanding that the vanilla OpenStack Heat
template deploys successfully on Mitaka, so can you tell me what Mitaka
installation you're using (Canonical, RDO, Mirantis, ?) and the physical
hardware configuration?

Thanks in advance.

-- 
Aimee Ukasick
Open Source Engagement OPFNV, OpenStack, ONAP
IRC: aimeeu


[onap-discuss] [demo] ONAP Demo Vanilla OpenStack - .env values questions

2017-04-10 Thread Aimee Ukasick
Thanks Daniel and Marco.
I am using the qcow cloud images, but I'm also using newer versions of
OpenStack - Newton, Ocata, or the Pike master branch of OpenStack
installer projects.
I'll double check that Heat is correctly configured to use Glance and
keep plugging away until I can get the demo deployed.

Aimee Ukasick
Open Source Engagement OPFNV, OpenStack, ONAP

On 04/07/2017 03:26 PM, ROSE, DANIEL V wrote:
> Aimee,
> 
> 'does not validate glance.image' generally in my experience means heat cannot 
> find a type of that name (ie heat Is not correctly setup to use glance) not 
> that there is anything wrong with the image per se. I suspect you could 
> confirm this by using heat to spin up anything (like the cirros test image or 
> something). 
> 
> But to be more specific on the images, you need something like the 64 bit 
> cloud images (which are in qcow2 format if you use kvm) from 
> https://cloud-images.ubuntu.com/releases/14.04/release/ 
> and 
> https://cloud-images.ubuntu.com/releases/16.04/release/
> 
> 
> Thanks,
> Daniel Rose
> ECOMP / ONAP
> com.att.ecomp
> 732-420-7308
> 
> -Original Message-
> From: onap-discuss-bounces at lists.onap.org [mailto:onap-discuss-bounces at 
> lists.onap.org] On Behalf Of PLATANIA, MARCO
> Sent: Friday, April 07, 2017 3:15 PM
> To: Aimee Ukasick ; onap-discuss at 
> lists.onap.org
> Subject: Re: [onap-discuss] [demo] ONAP Demo Vanilla OpenStack - .env values 
> questions
> 
> *** Security Advisory: This Message Originated Outside of AT&T ***.
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
> 
> Hello Aimee,
> 
> 
> 
> Ubuntu 14.04 and 16.04 are the two Operating Systems that we are using in 
> ONAP. The image name is parametrized in the heat template and environment 
> file, as you pointed out. This is necessary because private OpenStack 
> deployments may have different image names for the same Operating Systems. 
> These names are chosen by users, as such we don?t have any control over them 
> and we can?t make any assumption.
> 
> 
> 
> As such, the names that you will need to use for ubuntu_***_image depend on 
> your specific OpenStack deployment.
> 
> 
> 
> I tried to search the problem that you experienced on the web, and it seems 
> that it can be related to many things, from incorrect installation of 
> glance.image contraints to bugs in some older OpenStack release. The Heat 
> template has been tested with OpenStack Mitaka, heat_template_version: 
> 2015-10-15.
> 
> 
> 
> You may also try to use the image ID instead of the name, and see if that 
> works.
> 
> 
> 
> Thanks,
> 
> Marco
> 
> 
> 
> 
> 
> On 4/7/17, 2:43 PM, "onap-discuss-bounces at lists.onap.org on behalf of 
> Aimee Ukasick"  aimeeu.opensource at gmail.com> wrote:
> 
> 
> 
> Hi all - I'm trying to get the demo running on upstream OpenStack. I'm
> 
> using the onap_openstack.env and onap_openstack.yaml files pulled today
> 
> (Friday 7 April 13:00 US CDT).
> 
> My question is what the value should be for ubuntu_***_image keys in
> 
> onap_openstack.env.
> 
> 
> 
> The demo README file L137-138 states:
> 
> ubuntu_1404_image: PUT THE UBUNTU 14.04 IMAGE NAME HERE
> 
> ubuntu_1604_image: PUT THE UBUNTU 16.04 IMAGE NAME HERE
> 
> 
> 
> I have the following images created:
> 
> root at 6a06e46ee4a8:/tmp/osclient# openstack image list -f json
> 
> [
> 
>   {
> 
> "Status": "active",
> 
> "ID": "ea2d9961-5634-4db0-a685-1a3e4cb0459f",
> 
> "Name": "cirros-0.3.5-x86_64-disk"
> 
>   },
> 
>   {
> 
> "Status": "active",
> 
> "ID": "307e0b0a-c10b-4001-a83a-939e6442d324",
> 
> "Name": "trusty-server-cloudimg-amd64-disk1"
> 
>   },
> 
>   {
> 
> "Status": "active",
> 
> "ID": "6b2485f0-5490-4cbd-9be7-af194d3cbc26",
> 
> "Name": "xenial-server-cloudimg-amd64-disk1"
> 
>   }
> 
> ]
> 
> 
> 
> So in my onap_openstack.env I put:
> 
> 
> 
> ubuntu_1404_image: trusty-server-cloudimg-amd64-disk1
> 
> 
> 
> ubuntu_1604_image: xenial-server-cloudimg-amd64-disk1
> 
> 
> 
> When I try to create the stack:
> 
> root at 6a06e46ee4a8:/tmp/osclient# openstack stack create ONAP -t
> 
> onap_openstack.yaml 

[onap-discuss] [demo] ONAP Demo Vanilla OpenStack - .env values questions

2017-04-07 Thread Aimee Ukasick
Hi all - I'm trying to get the demo running on upstream OpenStack. I'm
using the onap_openstack.env and onap_openstack.yaml files pulled today
(Friday 7 April 13:00 US CDT).
My question is what the value should be for ubuntu_***_image keys in
onap_openstack.env.

The demo README file L137-138 states:
ubuntu_1404_image: PUT THE UBUNTU 14.04 IMAGE NAME HERE
ubuntu_1604_image: PUT THE UBUNTU 16.04 IMAGE NAME HERE

I have the following images created:
root at 6a06e46ee4a8:/tmp/osclient# openstack image list -f json
[
  {
"Status": "active",
"ID": "ea2d9961-5634-4db0-a685-1a3e4cb0459f",
"Name": "cirros-0.3.5-x86_64-disk"
  },
  {
"Status": "active",
"ID": "307e0b0a-c10b-4001-a83a-939e6442d324",
"Name": "trusty-server-cloudimg-amd64-disk1"
  },
  {
"Status": "active",
"ID": "6b2485f0-5490-4cbd-9be7-af194d3cbc26",
"Name": "xenial-server-cloudimg-amd64-disk1"
  }
]

So in my onap_openstack.env I put:

ubuntu_1404_image: trusty-server-cloudimg-amd64-disk1

ubuntu_1604_image: xenial-server-cloudimg-amd64-disk1

When I try to create the stack:
root at 6a06e46ee4a8:/tmp/osclient# openstack stack create ONAP -t
onap_openstack.yaml -e onap_openstack.env

ERROR: Property error: : resources.dcae_c_vm.properties.image: :
"trusty-server-cloudimg-amd64-disk1" does not validate glance.image
(constraint not found)

ERROR: Property error: : resources.mso_vm.properties.image: :
"xenial-server-cloudimg-amd64-disk1" does not validate glance.image
(constraint not found)

and so on

---

What am I doing wrong? What values should be used for ubuntu_***_image?

Also, what version of OpenStack was the vanilla OpenStack Heat templated
tested against? Maybe there have been changes between the tested version
and the one I'm using.

Thanks in advance!



Aimee Ukasick