[openstack-dev] Error connecting to gerrit - issue with gerrit and launchpad username mismatch?

2016-03-13 Thread Lee Calcote 
Does anyone know if the fact that my usernames are different across these 
systems will cause an error when authenticating to gerrit?

I receive this error when running a git review from within an openstack 
repository I just cloned:

$ git review Could not connect to gerrit. Enter your gerrit username: lecalcot 
Trying again with 
ssh://lecal...@review.openstack.org:29418/openstack/openstack-manuals.git 
 We don't know where your gerrit is. Please 
manually create a remote named "gerrit" and try again. Could not connect to 
gerrit at 
ssh://lecal...@review.openstack.org:29418/openstack/openstack-manuals.git 
Traceback (most recent call last): File "/usr/local/bin/git-review", line 11, 
in  sys.exit(main()) File 
"/Library/Python/2.7/site-packages/git_review/cmd.py", line 1534, in main 
sys.exit(e.EXIT_CODE) AttributeError: 'GitReviewException' object has no 
attribute 'EXIT_CODE'

I'm able to ssh -p 29418 lecal...@review.openstack.org gerrit version and 
receive the current version of gerrit back, so I have both network connectivity 
and a valid SSH key.

My gerrit username is "lecalcot". My launchpad username is "lcalcote”.

Thanks,
Lee

1] 
https://ask.openstack.org/en/question/89483/error-connecting-to-gerrit-issue-with-gerrit-and-launchpad-username-mismatch/__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources

2015-12-16 Thread Lee Calcote 
Food for thought - there is a cost to FIPs (in the case of public IP 
addresses), security groups (to a lesser extent, but in terms of the 
computation of many hundreds of them), etc. Administrators may wish to enforce 
quotas on a variety of resources that are direct costs or indirect costs (e.g. 
# of bays, where a bay consists of a number of multi-VM / multi-host pods and 
services, which consume CPU, mem, etc.).

If Magnum quotas are brought forward, they should govern (enforce quota) on 
Magnum-specific constructs only, correct? Resources created by Magnum COEs 
should be governed by existing quota policies governing said resources (e.g. 
Nova and vCPUs).

Lee

> On Dec 16, 2015, at 1:56 PM, Tim Bell  wrote:
> 
>> -Original Message-
>> From: Clint Byrum [mailto:cl...@fewbar.com ]
>> Sent: 15 December 2015 22:40
>> To: openstack-dev > >
>> Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum
>> Resources
>> 
>> Hi! Can I offer a counter point?
>> 
>> Quotas are for _real_ resources.
>> 
> 
> The CERN container specialist agrees with you ... it would be good to
> reflect on the needs given that ironic, neutron and nova are policing the
> resource usage. Quotas in the past have been used for things like key pairs
> which are not really real.
> 
>> Memory, CPU, disk, bandwidth. These are all _closely_ tied to things that
> cost
>> real money and cannot be conjured from thin air. As such, the user being
>> able to allocate 1 billion or 2 containers is not limited by Magnum, but
> by real
>> things that they must pay for. If they have enough Nova quota to allocate
> 1
>> billion tiny pods, why would Magnum stop them? Who actually benefits from
>> that limitation?
>> 
>> So I suggest that you not add any detailed, complicated quota system to
>> Magnum. If there are real limitations to the implementation that Magnum
>> has chosen, such as we had in Heat (the entire stack must fit in memory),
>> then make that the limit. Otherwise, let their vcpu, disk, bandwidth, and
>> memory quotas be the limit, and enjoy the profit margins that having an
>> unbound force multiplier like Magnum in your cloud gives you and your
>> users!
>> 
>> Excerpts from Vilobh Meshram's message of 2015-12-14 16:58:54 -0800:
>>> Hi All,
>>> 
>>> Currently, it is possible to create unlimited number of resource like
>>> bay/pod/service/. In Magnum, there should be a limitation for user or
>>> project to create Magnum resource, and the limitation should be
>>> configurable[1].
>>> 
>>> I proposed following design :-
>>> 
>>> 1. Introduce new table magnum.quotas
>>> ++--+--+-+-++
>>> 
>>> | Field  | Type | Null | Key | Default | Extra  |
>>> 
>>> ++--+--+-+-++
>>> 
>>> | id | int(11)  | NO   | PRI | NULL| auto_increment |
>>> 
>>> | created_at | datetime | YES  | | NULL||
>>> 
>>> | updated_at | datetime | YES  | | NULL||
>>> 
>>> | deleted_at | datetime | YES  | | NULL||
>>> 
>>> | project_id | varchar(255) | YES  | MUL | NULL||
>>> 
>>> | resource   | varchar(255) | NO   | | NULL||
>>> 
>>> | hard_limit | int(11)  | YES  | | NULL||
>>> 
>>> | deleted| int(11)  | YES  | | NULL||
>>> 
>>> ++--+--+-+-++
>>> 
>>> resource can be Bay, Pod, Containers, etc.
>>> 
>>> 
>>> 2. API controller for quota will be created to make sure basic CLI
>>> commands work.
>>> 
>>> quota-show, quota-delete, quota-create, quota-update
>>> 
>>> 3. When the admin specifies a quota of X number of resources to be
>>> created the code should abide by that. For example if hard limit for Bay
> is 5
>> (i.e.
>>> a project can have maximum 5 Bay's) if a user in a project tries to
>>> exceed that hardlimit it won't be allowed. Similarly goes for other
>> resources.
>>> 
>>> 4. Please note the quota validation only works for resources created
>>> via Magnum. Could not think of a way that Magnum to know if a COE
>>> specific utilities created a resource in background. One way could be
>>> to see the difference between whats stored in magnum.quotas and the
>>> information of the actual resources created for a particular bay in
> k8s/COE.
>>> 
>>> 5. Introduce a config variable to set quotas values.
>>> 
>>> If everyone agrees will start the changes by introducing quota
>>> restrictions on Bay creation.
>>> 
>>> Thoughts ??
>>> 
>>> 
>>> -Vilobh
>>> 
>>> [1] https://blueprints.launchpad.net/magnum/+spec/resource-quota
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for

Re: [openstack-dev] [magnum] Networking Subteam Meetings

2015-11-05 Thread Lee Calcote 
It seems integration of the SocketPlane acquisition has come to fruition in 1.9…

Lee

> On Nov 5, 2015, at 1:18 PM, Daneyon Hansen (danehans)  
> wrote:
> 
> All,
> 
> I apologize for issues with today's meeting. My calendar was updated to 
> reflect daylight savings and displayed an incorrect meeting start time. This 
> issue is now resolved. We will meet on 11/12 at 18:30 UTC. The meeting has 
> been pushed back 30 minutes from our usual start time. This is because Docker 
> is hosting a Meetup [1] to discuss the new 1.9 networking features. I 
> encourage everyone to attend the Meetup.
> 
> [1] http://www.meetup.com/Docker-Online-Meetup/events/226522306/ 
> 
> [2] 
> https://wiki.openstack.org/wiki/Meetings/Containers#Container_Networking_Subteam_Meeting
>  
> 
> 
> Regards,
> Daneyon Hansen
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Troubleshooting cross-project comms

2015-11-04 Thread Lee Calcote 
Especially given the pervasiveness of discussion topics. +1

Lee

> On Nov 4, 2015, at 12:44 PM, Brad Topol  wrote:
> 
> +1 That's an extremely good suggestion!!!
> 
> --Brad
> 
> 
> Brad Topol, Ph.D.
> IBM Distinguished Engineer
> OpenStack
> (919) 543-0646
> Internet: bto...@us.ibm.com
> Assistant: Kendra Witherspoon (919) 254-0680
> 
> Sean McGinnis ---11/04/2015 10:36:22 AM---On Wed, Nov 04, 2015 
> at 07:30:51AM -0500, Sean Dague wrote: > On 10/28/2015 07:15 PM, Anne Gentle 
> wr
> 
> From: Sean McGinnis 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 11/04/2015 10:36 AM
> Subject: Re: [openstack-dev] Troubleshooting cross-project comms
> 
> 
> 
> 
> On Wed, Nov 04, 2015 at 07:30:51AM -0500, Sean Dague wrote:
> > On 10/28/2015 07:15 PM, Anne Gentle wrote:
> > 
> > Has anyone considered using #openstack-dev, instead of a new meeting
> > room? #openstack-dev is mostly a ghost town at this point, and deciding
> > that instead it would be the dedicated cross project space, including
> > meetings support, might be interesting.
> > 
> > -Sean
> 
> +1 - That makes a lot of sense to me.
> 
> > 
> > -- 
> > Sean Dague
> > http://dague.net 
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> > 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Murano] Should we move to #openstack-murano ?

2015-07-17 Thread Lee Calcote 
+1, Kate.

Lee
-- 
Lee Calcote
Director, Software Engineering | Cloud Systems and Solutions
Seagate Technology | 10200 S. De Anza Blvd., Cupertino, CA 95014
(W) 408-658-1861 (C) 512-810-2771 (T) @lcalcote

 On Jul 17, 2015, at 11:26 AM, Victor Ryzhenkin vryzhen...@mirantis.com 
 wrote:
 
 Hi, Kate!
 
 So I have a question: should we move to #openstack-murano?
 
 I think it’s a good idea, since it’s more obvious to go to #openstack-murano 
 if one needs help with murano.
 
 I like this idea. Strong +1 to it.
 
 -- 
 Victor Ryzhenkin
 Junior QA Engeneer
 freerunner on #freenode
 
 Включено 17 июля 2015 г. в 19:23:36, Ekaterina Chernova 
 (efedor...@mirantis.com mailto:efedor...@mirantis.com) написал:
 
 Hi guys!
 
 Currently Murano holds the #murano IRC channel.
 
 But all openstack projects have the openstack- prefix in their channel’s 
 name.
 
 So I have a question: should we move to #openstack-murano?
 
 I think it’s a good idea, since it’s more obvious to go to #openstack-murano 
 if one needs help with murano.
 
 Do you know if anybody tried to get help at #openstack-murano and discovered 
 that this is not the official Murano channel ?
 
 Would it be hard to migrate from one channel to another?
 
 Regards,
 Kate.
 __ 
 OpenStack Development Mailing List (not for usage questions) 
 Unsubscribe: openstack-dev-requ...@lists.openstack.org 
 mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org 
 mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddevd=AwICAgc=IGDlg0lD0b-nebmJJ0Kp8Ar=I3cSIvyDkys1wUZdtxxtF5qxRkoDWv_Y7wNzrd3ReMUm=adKlfMyngJxcdIXIPM9W6VVMLHMA9FDNtEbjRiBSJv0s=1mjbCcPOcrLy18LVat6mo3EXOX-1qEM87rnAnp83H5ce=
  
 https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddevd=AwICAgc=IGDlg0lD0b-nebmJJ0Kp8Ar=I3cSIvyDkys1wUZdtxxtF5qxRkoDWv_Y7wNzrd3ReMUm=adKlfMyngJxcdIXIPM9W6VVMLHMA9FDNtEbjRiBSJv0s=1mjbCcPOcrLy18LVat6mo3EXOX-1qEM87rnAnp83H5ce=
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Solum Design Session at OpenStack Summit

2014-10-29 Thread Lee Calcote (lecalcot) 
Noted. Looking forward to the face time.

Lee

On 10/29/14, 9:30 AM, Adrian Otto adrian.o...@rackspace.com wrote:

Team,

See below. For those of us attending the OpenStack Summit in Paris,
please be sure to plan your schedule so you can attend this session.

Thanks,

Adrian

Begin forwarded message:

 From: Chris Hoge ch...@openstack.org
 Subject: Solum Design Session at OpenStack Summit
 Date: October 22, 2014 at 11:09:55 AM PDT
 To: Adrian Otto adrian.o...@rackspace.com
 
 Hi,
 
 Here is the latest schedule information for the Solum Design Session at
the OpenStack Summit.
 
 Thanks,
 Chris
 
 http://kilodesignsummit.sched.org/event/4e2033ced61b8dadf7a2db1aee6d8123


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Murano]

2014-07-22 Thread Lee Calcote (lecalcot) 
Gents,

For what it’s worth - We’ve long accounting for “extension points” within our 
VM and physical server provisioning flows, where developers may drop in code to 
augment OOTB behavior with customer/solution-specific needs.  While there are 
many extension points laced throughout different points in the provisioning 
flow, we pervasively injected “pre” and “post” provisioning extension points to 
allow for easy customization (like the one being attempted by Steve).

The notions of prepareDeploy and finishDeploy resonant well.

Regards,
Lee
  [cid:79A77799-DB4B-4D01-957B-D6A7D5D69476]
Lee Calcote
Sr. Software Engineering Manager
Cloud and Virtualization Group

Phone: 512-378-8835
Mail/Jabber/Video: 
lecal...@cisco.comapplewebdata://BF2BDB88-16CF-4E49-8251-92F7CF8AD490/lecal...@cisco.com

United States
www.cisco.com

From: Stan Lagun sla...@mirantis.commailto:sla...@mirantis.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, July 22, 2014 at 4:37 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Murano]

Hi Steve,

1. There are no objections whatsoever if you know how to do it without breaking 
the entire concept
2. I thing that deployment workflow need to be broken to more fine-grained 
steps. Maybe instead of single deploy methdos have prepareDeploy (which 
doesn't push the changes to Heat), deploy and finishDeploy. Maybe 
more/other methods need to be defined. This will make the whole process more 
customizible
3. If you want to have single-instance applications based on a fixed prebuild 
image then maybe what you need is to have your apps inhertir both Application 
and Instance classes and then override Instance's deploy method and add HOT 
snippet before VM instantiation. This may also require ability for child class 
to bind fixed values to parent class properties (narrowing class public 
contract, hiding those properties from user). This is not yet supported in 
MuranoPL but can be done in UI form as a temporary workaround
4. Didn't get why you mentioned object model. Object model is mostly user 
input. Do you suggest passing HOT snippets as part of user input? If so that 
would be something I oppose to
5. I guess image tagging would be better solution to image-based deployment
6. Personally I believe that problem can be eficently solved by Murano today or 
in the nearest future without resorting to pure HOT packages. This is not 
against Murano design and perfectly alligned with it


Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

mailto:sla...@mirantis.com


On Tue, Jul 22, 2014 at 8:05 PM, McLellan, Steven 
steve.mclel...@hp.commailto:steve.mclel...@hp.com wrote:
Hi,

This is a little rambling, so I’ll put this summary here and some discussion 
below. I would like to be able to add heat template fragments (primarily 
softwareconfig) to a template before an instance is created by Heat. This could 
be possible by updating but not pushing the heat template before 
instance.deploy, except that instance.deploy does a stack.push to configure 
networking before it adds information about the nova instance. This seems like 
the wrong place for the networking parts of the stack to be configured (maybe 
in the Environment before it tries to deploy applications). Thoughts?

--

The long version:

I’ve been looking at using disk-image-builder (a project that came out of 
triple-o) to build images for consumption through Murano. Disk images are built 
from a base OS plus a set of ‘elements’ which can include packages to install 
when building the image, templatized config file etc, and allows for 
substitutions based on heat metadata at deploy time. This uses a lot of the 
existing heat software config agents taking configuration from StructuredConfig 
and StructuredDeployment heat elements.

I’m typically finding for our use cases that instances will tend to be single 
purpose (that is, the image will be created specifically to run a piece of 
software that requires some configuration). Currently Murano provisions the 
instance, and then adds software configuration as a separate stack-update step. 
This is quite inefficient since os-refresh-config ends up having to re-run, and 
so I’m wondering if there’s strong opposition to allowing the object model to 
support injection of software configuration heat elements before the instance 
is deployed.

Alternatively maybe this is something that is best supported by pure HOT 
packages, but I think there’s value having murano’s composition ability even if 
just to be able to combine heat fragments (perhaps in the drag  drop manner 
that was briefly discussed in Atlanta).

Thanks,

Steve


___
OpenStack-dev mailing list
OpenStack-dev