Re: [Openstack-operators] [openstack-dev] [cinder] No middle-man - when does/will Nova directly connect iSCSI volumes?

[Daniel P. Berrange]

On Wed, Jun 15, 2016 at 04:59:39PM -0700, Preston L. Bannister wrote:
> QEMU has the ability to directly connect to iSCSI volumes. Running the
> iSCSI connections through the nova-compute host *seems* somewhat
> inefficient.
> 
> There is a spec/blueprint and implementation that landed in Kilo:
> 
> https://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/qemu-built-in-iscsi-initiator.html
> https://blueprints.launchpad.net/nova/+spec/qemu-built-in-iscsi-initiator
> 
> From looking at the OpenStack Nova sources ... I am not entirely clear on
> when this behavior is invoked (just for Ceph?), and how it might change in
> future.
> 
> Looking for a general sense where this is headed. (If anyone knows...)
> 
> If there is some problem with QEMU and directly attached iSCSI volumes,
> that would explain why this is not the default. Or is this simple inertia?
> 
> 
> I have a concrete concern. I work for a company (EMC) that offers backup
> products, and we now have backup for instances in OpenStack. To make this
> efficient, we need to collect changed-block information from instances.
> 
> 1)  We could put an intercept in the Linux kernel of the nova-compute host
> to track writes at the block layer. This has the merit of working for
> containers, and potentially bare-metal instance deployments. But is not
> guaranteed for instances, if the iSCSI volumes are directly attached to
> QEMU.
> 
> 2)  We could use the QEMU support for incremental backup (first bit landed
> in QEMU 2.4). This has the merit of working with any storage, by only for
> virtual machines under QEMU.
> 
> As our customers are (so far) only asking about virtual machine backup. I
> long ago settled on (2) as most promising.
> 
> What I cannot clearly determine is where (1) will fail. Will all iSCSI
> volumes connected to QEMU instances eventually become directly connected?

Our long term goal is that 100% of all network storage will be connected
to directly by QEMU. We already have the ability to partially do this with
iSCSI, but it is lacking support for multipath. As & when that gap is
addressed though, we'll stop using the host OS for any iSCSI stuff.

So if you're requiring access to host iSCSI volumes, it'll work in the
short-medium term, but in the medium-long term we're not going to use
that so plan accordingly.

> Xiao's unanswered query (below) presents another question. Is this a
> site-choice? Could I require my customers to configure their OpenStack
> clouds to always route iSCSI connections through the nova-compute host? (I
> am not a fan of this approach, but I have to ask.)

In the short term that'll work, but long term we're not intending to
support that once QEMU gains multi-path. There's no timeframe on when
that will happen though.



Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [Openstack-operators] How do you handle purge of database tables ?

[Nick Jones]

Another vote of confidence for the script that Tim has mentioned with regards 
to clearing down Nova’s DB.  I blogged a bit about the process and the results 
here:

http://dischord.org/2015/12/30/archiving-data-in-nova-s-database/ 


— 

-Nick

> On 23 Jun 2016, at 06:53, Tim Bell  wrote:
> 
> There are also some tools in the OSOps repository (Nova for example has 
> https://github.com/openstack/osops-tools-generic/tree/master/nova) 
> 
>  
> Tim
>  
> From: Abel Lopez 
> Date: Thursday 23 June 2016 at 00:03
> To: Gilles Mocellin 
> Cc: openstack-operators 
> Subject: Re: [Openstack-operators] How do you handle purge of database tables 
> ?
>  
>> Some projects (e.g. cinder) have tools.. 
>> `cinder-manage db-purge` or maybe it's "db purge" or something along those 
>> lines...
>> It was around Kilo when that got added.
>>  
>> Otherwise, in the past, I've done
>> mysql backup, then a massive table by table purge of "deleted=1" rows.
>>  
>> On Wed, Jun 22, 2016 at 2:39 PM, Gilles Mocellin 
>> mailto:gilles.mocel...@nuagelibre.org>> 
>> wrote:
>>> Le 22/06/2016 à 23:26, Gilles Mocellin a écrit :
 Hello,
 
 While digging in nova's database, I found that many objects ar not really 
 deleted, but instead just marked deleted.
 In fact, it's a general behavior in other projects (cinder, glance...).
 
 I understand that. It can be handy.
 
 But, is there a way to handle regular purging of theses elements inside 
 OpenStack configuration ?
 
 Or do we, operators, have to create batchs to purge all that ?
 
>>> 
>>> I've found some blueprints indicating that there nothing for now, inside 
>>> OpenStack :
>>> 
>>> https://blueprints.launchpad.net/nova/+spec/purge-deleted-instances-cmd 
>>> 
>>> https://blueprints.launchpad.net/cinder/+spec/database-purge 
>>> 
>>> https://blueprints.launchpad.net/glance/+spec/database-purge 
>>> 

-- 
DataCentred Limited registered in England and Wales no. 05611763
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How do you handle purge of database tables ?

[xav]

On Thu, 2016-06-23 at 09:55 +0100, Nick Jones wrote:
> Another vote of confidence for the script that Tim has mentioned with
> regards to clearing down Nova’s DB.  I blogged a bit about the process
> and the results here:
> 
> 
> http://dischord.org/2015/12/30/archiving-data-in-nova-s-database/
> 
> — 

> 

In Nova, there's 'nova-manage db archive_deleted_rows' - is that the one
referred to in the blog post above that broke?


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

Re: [Openstack-operators] [Openstack-Operators] Keystone cache strategies

[Jose Castro Leon]

We only have the cache configured at the keystone level, not sure that will 
help, it will still require to retrieve the revoke tree from the cache to 
validate the tree…

Modifying the values on the cache_time does not reduce the number of requests 
on the cache, it increases the load on the database behind…

I am looking into other backends possibilities to reduce “hot key” issues, just 
wondering what are you using, and for the replies everyone is using memcache…

Cheers,
Jose

Jose Castro Leon
CERN IT-CM-RPS   tel:+41.22.76.74272
mob: +41.75.41.19222
fax:+41.22.76.67955
Office: 31-1-026  CH-1211  Geneve 23
email: jose.castro.l...@cern.ch

From: tadow...@gmail.com [mailto:tadow...@gmail.com] On Behalf Of Matt Fischer
Sent: Wednesday, June 22, 2016 5:07 AM
To: Sam Morrison 
Cc: Jose Castro Leon ; 
openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] [Openstack-Operators] Keystone cache 
strategies

On Tue, Jun 21, 2016 at 7:04 PM, Sam Morrison 
mailto:sorri...@gmail.com>> wrote:

On 22 Jun 2016, at 10:58 AM, Matt Fischer 
mailto:m...@mattfischer.com>> wrote:


Have you setup token caching at the service level? Meaning a Memcache cluster 
that glance, Nova etc would talk to directly? That will really cut down the 
traffic.
Yeah we have that although the default cache time is 10 seconds for revocation 
lists. I might just set that to some large number to limit this traffic a bit.

Sam

We have ours set to 60 seconds. I've fiddled around with it some, but I've 
found that revocation events are damaging to perf no matter how much magic you 
try to apply.
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Keystone's DB_SYNC from Kilo to Liberty

[Alvise Dorigo]

Hi,
I've a Kilo installation which I want to migrate to Liberty.
I've installed the Liberty Keystone's RPMs and configured the minimun to 
upgrade the DB schema ("connection" parameter in the [database] section 
of keystone.conf).

Then, I've tried to run

su -s /bin/sh -c "keystone-manage db_sync" keystone

but it's failed with the following error:

2016-06-23 13:20:50.191 22423 CRITICAL keystone [-] KeyError: 



which is quite useless.

Any suggestion ?

many thanks,

Alvise

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

Re: [Openstack-operators] Keystone's DB_SYNC from Kilo to Liberty

[Matt Fischer]

IIRC there are some debug/verbose flags you can pass in. Get anything from
them?
On Jun 23, 2016 5:37 AM, "Alvise Dorigo"  wrote:

> Hi,
> I've a Kilo installation which I want to migrate to Liberty.
> I've installed the Liberty Keystone's RPMs and configured the minimun to
> upgrade the DB schema ("connection" parameter in the [database] section of
> keystone.conf).
> Then, I've tried to run
>
> su -s /bin/sh -c "keystone-manage db_sync" keystone
>
> but it's failed with the following error:
>
> 2016-06-23 13:20:50.191 22423 CRITICAL keystone [-] KeyError:
> 
>
> which is quite useless.
>
> Any suggestion ?
>
> many thanks,
>
> Alvise
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How do you handle purge of database tables ?

[Nick Jones]

> On Thu, 2016-06-23 at 09:55 +0100, Nick Jones wrote:
>> Another vote of confidence for the script that Tim has mentioned with
>> regards to clearing down Nova’s DB.  I blogged a bit about the process
>> and the results here:
>> 
>> 
>> http://dischord.org/2015/12/30/archiving-data-in-nova-s-database/
>> 
>> — 
> 
>> 
> 
> In Nova, there's 'nova-manage db archive_deleted_rows' - is that the one
> referred to in the blog post above that broke?

That’s the one.

— 

-Nick
-- 
DataCentred Limited registered in England and Wales no. 05611763

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

[Openstack-operators] Ops Tag Team meeting time

[Devon Boatwright]

Hello,

I just want to verify the time for the Ops Tag Team meeting time. It says
every other Thursday at 1400UTC. Which I'm showing would be today at 10am
EDT. However, there is no meeting going on? Are these meetings still
happening? I see the logs for the last meeting were in March.

Thanks!
-- 
Devon Boatwright
devon.boatwri...@gmail.com
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Ops Tag Team meeting time

[Shamail]

Hi Devon,

> On Jun 23, 2016, at 10:22 AM, Devon Boatwright  
> wrote:
> 
> Hello,
> 
> I just want to verify the time for the Ops Tag Team meeting time. It says 
> every other Thursday at 1400UTC. Which I'm showing would be today at 10am 
> EDT. However, there is no meeting going on? Are these meetings still 
> happening? I see the logs for the last meeting were in March. 
Thanks for bringing up this topic. These meetings should still happen but I 
have not been able to reach out to people with reminders over the last few 
months.  I will start sending routine reminders again to ensure they pick up 
again.

We also need to fix the schedule on eavesdrop.  The ops-tags team usually meets 
only once a month (which is supposed to be every 3rd Thursday of the month) but 
this option can not be defined in eavesdrop, hence our schedule shows every 
other week.  

We can try to hold the meeting every couple of weeks so there is a set cadence 
going forward, although some agendas might be fairly light.

Thanks,
Shamail 
> 
> Thanks!
> -- 
> Devon Boatwright
> devon.boatwri...@gmail.com
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How do you handle purge of database tables ?

[Belmiro Moreira]

Hi,
we wrote this blog post a year ago but it still can be useful depending on
the
OpenStack version that you are running.

http://openstack-in-production.blogspot.ch/2015/05/purging-nova-databases-in-cell.html

Belmiro

On Thu, Jun 23, 2016 at 3:32 PM, Nick Jones 
wrote:

> > On Thu, 2016-06-23 at 09:55 +0100, Nick Jones wrote:
> >> Another vote of confidence for the script that Tim has mentioned with
> >> regards to clearing down Nova’s DB.  I blogged a bit about the process
> >> and the results here:
> >>
> >>
> >> http://dischord.org/2015/12/30/archiving-data-in-nova-s-database/
> >>
> >> —
> >
> >>
> >
> > In Nova, there's 'nova-manage db archive_deleted_rows' - is that the one
> > referred to in the blog post above that broke?
>
> That’s the one.
>
> —
>
> -Nick
> --
> DataCentred Limited registered in England and Wales no. 05611763
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How do you handle purge of database tables ?

[Edgar Magana]

I would encourage you to use that repo and if there is something worth to be 
added updated, please do! All suggestions are welcome.

Edgar

From: Tim Bell 
Date: Wednesday, June 22, 2016 at 10:53 PM
To: Abel Lopez , Gilles Mocellin 

Cc: "OpenStack-operators@lists.openstack.org" 

Subject: Re: [Openstack-operators] How do you handle purge of database tables ?

There are also some tools in the OSOps repository (Nova for example has 
https://github.com/openstack/osops-tools-generic/tree/master/nova)

Tim

From: Abel Lopez 
Date: Thursday 23 June 2016 at 00:03
To: Gilles Mocellin 
Cc: openstack-operators 
Subject: Re: [Openstack-operators] How do you handle purge of database tables ?

Some projects (e.g. cinder) have tools..
`cinder-manage db-purge` or maybe it's "db purge" or something along those 
lines...
It was around Kilo when that got added.

Otherwise, in the past, I've done
mysql backup, then a massive table by table purge of "deleted=1" rows.

On Wed, Jun 22, 2016 at 2:39 PM, Gilles Mocellin 
mailto:gilles.mocel...@nuagelibre.org>> wrote:
Le 22/06/2016 à 23:26, Gilles Mocellin a écrit :
Hello,

While digging in nova's database, I found that many objects ar not really 
deleted, but instead just marked deleted.
In fact, it's a general behavior in other projects (cinder, glance...).

I understand that. It can be handy.

But, is there a way to handle regular purging of theses elements inside 
OpenStack configuration ?

Or do we, operators, have to create batchs to purge all that ?

I've found some blueprints indicating that there nothing for now, inside 
OpenStack :

https://blueprints.launchpad.net/nova/+spec/purge-deleted-instances-cmd
https://blueprints.launchpad.net/cinder/+spec/database-purge
https://blueprints.launchpad.net/glance/+spec/database-purge



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

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

[Openstack-operators] Astara?

[Jonathan Mills]

I'm seeking user stories, experiences, feedback, etc relating to the use of
Astara for managing the overlay network in a vxlan scenario.  Was it
difficult to set up?  Was it worth your time/effort?  Are you still happy
with it, or do you prefer a different solution?  Your feedback is greatly
appreciated...
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Packaging Virtualenvs

[Silence Dogood]

I know from conversations that a few folks package their python apps as
distributable virtualenvs.   spotify created dh-virtualenv for this.  you
can do it pretty simply by hand.

I built a toolchain for building rpms as distributable virtualenvs and that
works really well.

What I'd like to do is make it so that every app that's built as a
virtualenv gets setup to automatically execute at call time in their
virtualenv.

I see two options:

1)  Dynamically generate a wrapper script during build and put it in the
RPM.  Call the wrapper.

2)  Created a dependency global module ( as an rpm ) set it as a
dependency.  And basically it'd be an autoexecuting import that
instantiates the virtualenv.  it would probably know all it needs to
because I am building all my packages to an internal standard.  Then when
building the APP rpm all I need to do is inject an import into the import
chain if it's being built as a virtualenv.  Then I have what are
effectively statically compiled python apps.

I like 2.  But 1 isn't very bad.  Both are a little hokey.

Was curious if folks might have a preference, or a better idea.

Thanks.

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

[Openstack-operators] Next Ops Midcycle NYC August 25-26

[Saverio Proto]

Hello there :)

is anyone from the openstack foundation or from bloomberg that can
help out with this ?

I share this for anyone that needs visa.

for Austin we had something like this:
https://www.openstack.org/summit/austin-2016/austin-and-travel/
https://openstackfoundation.formstack.com/forms/visa_form_austin_summit

anyone that needs to apply for Visa will need a 'US point of contact
information'.

Basically, if the organizer of the Ops Midcycle is officially the
openstack foundation or bloomberg, I need to enter in my visa
application the following info:

Organization name
Address in the US
Phone number
Email

It must be a phone number and a email where in case there is a check,
somebody can tell "yes of course, this guy exist and is coming to the
conference" :)

How we sort this out ?

thank you

Saverio

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

Re: [Openstack-operators] Next Ops Midcycle NYC August 25-26

[Mark Voelker]

Hi Folks,

A quick update on this: today’s the last day of earlybird pricing for OpenStack 
East, so if you’d like to attend both events I’d encourage you to register now 
(it’s only $99 for the next ~7 hours):

https://www.eventbrite.com/e/openstack-east-tickets-22413148330?ref=ebtnebregn

If you can’t register today, some good news: I spoke with the conference 
organizers and it looks like we’ll be able to get some sort of discount code 
for folks who are attending the Ops Midcycle and also want to attend OpenStack 
East!  We’re still working out logistics, so bear with me—I’ll send along some 
more info when I have it.

At Your Service,

Mark T. Voelker



> On Jun 22, 2016, at 2:16 PM, Mark Voelker  wrote:
> 
> It would definitely be cool to have more ops folks attend both events.  I’d 
> be happy to check in with the rest of the organizers and see if there’s a 
> possibility of working something out.
> 
> At Your Service,
> 
> Mark T. Voelker
> 
> 
> 
>> On Jun 22, 2016, at 12:27 PM, David Medberry  wrote:
>> 
>> Would be sweet if that offer could be extended at least a week as we go 
>> through the corp travel process. OTOH, $99 is almost cheap enough to buy and 
>> not care I'll be doing that I guess.
>> 
>> On Wed, Jun 22, 2016 at 9:44 AM, Matt Jarvis  
>> wrote:
>> Hi Mark
>> 
>> Given we've not got the Eventbrite for the Ops Meetup live yet, is there any 
>> chance you could extend the early bird pricing or give operators who may be 
>> travelling for the Ops Meetup a discount code ? I suspect there may be quite 
>> a lot of interest for those travelling some distance. 
>> 
>> Matt
>> 
>> On 22 June 2016 at 14:58, Mark Voelker  wrote:
>> Hi Ops,
>> 
>> FYI for those that may not be aware, that’s also the week of OpenStack East. 
>>  OpenStack East runs August 23-24 also in New York City (about ~15-20 
>> minutes away from Civic Hall by MTA at the Playstation Theater).  If you’re 
>> coming to town for the Ops Midcycle, you may want to make a week of it.  
>> Earlybird pricing for OpenStack East is still available but prices increase 
>> tomorrow:
>> 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openstackeast.com_&d=CwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=Pouk4RdhAp3O0-4z088jjeJcdTHWxG2QEHGPaCapbAg&s=pst_dGQnf8jOAggeotgW1NJGzEAbCpWryQ7tNon78IM&e=
>>  
>> 
>> At Your Service,
>> 
>> Mark T. Voelker
>> (wearer of many hats, one of which is OpenStack East steering committee 
>> member)
>> 
>> 
>> 
>>> On Jun 21, 2016, at 11:36 AM, Jonathan D. Proulx  wrote:
>>> 
>>> Hi All,
>>> 
>>> The Ops Meetups Team has selected[1] New York City as the location of the
>>> next mid-cycle meetup on August 25 and 26 2016 at Civic Hall[2]
>>> 
>>> Many thanks to Bloomberg for sponsoring the location.  And thanks to
>>> BestBuy as well for their offer of the Seattle location.  The choice
>>> was very close and hopefully their offer will stand for our next North
>>> American meet-up.
>>> 
>>> There's quite a bit of work to do to make this all happen in the
>>> next couple of months so it's still a great time to join the Ops
>>> Meetups Team[3] and help out.
>>> 
>>> -Jon
>>> 
>>> --
>>> 
>>> [1] 
>>> http://eavesdrop.openstack.org/meetings/ops_meetups_team/2016/ops_meetups_team.2016-06-21-14.02.html
>>> [2] 
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__civichall.org_about-2Dcivic-2Dhall_&d=CwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=oAH-SSZ6EFikpmcyUpbf3984kyPBIuLJKkQadC6CKUw&s=36Kl-0b4WBC06xaYXo0V5AM2lHzvjhL48bBV48cz2is&e=
>>> [3] https://wiki.openstack.org/wiki/Ops_Meetups_Team
>>> 
>>> 
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
>> 
>> DataCentred Limited registered in England and Wales no. 05611763
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
>> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

Re: [Openstack-operators] Next Ops Midcycle NYC August 25-26

[Anita Kuno]

On 06/23/2016 04:42 PM, Mark Voelker wrote:
> Hi Folks,
> 
> A quick update on this: today’s the last day of earlybird pricing for 
> OpenStack East, so if you’d like to attend both events I’d encourage you to 
> register now (it’s only $99 for the next ~7 hours):
> 
> https://www.eventbrite.com/e/openstack-east-tickets-22413148330?ref=ebtnebregn
> 
> If you can’t register today, some good news: I spoke with the conference 
> organizers and it looks like we’ll be able to get some sort of discount code 
> for folks who are attending the Ops Midcycle and also want to attend 
> OpenStack East!  We’re still working out logistics, so bear with me—I’ll send 
> along some more info when I have it.
> 
> At Your Service,
> 
> Mark T. Voelker
> 
> 
> 
>> On Jun 22, 2016, at 2:16 PM, Mark Voelker  wrote:
>>
>> It would definitely be cool to have more ops folks attend both events.  I’d 
>> be happy to check in with the rest of the organizers and see if there’s a 
>> possibility of working something out.
>>
>> At Your Service,
>>
>> Mark T. Voelker
>>
>>
>>
>>> On Jun 22, 2016, at 12:27 PM, David Medberry  wrote:
>>>
>>> Would be sweet if that offer could be extended at least a week as we go 
>>> through the corp travel process. OTOH, $99 is almost cheap enough to buy 
>>> and not care I'll be doing that I guess.
>>>
>>> On Wed, Jun 22, 2016 at 9:44 AM, Matt Jarvis 
>>>  wrote:
>>> Hi Mark
>>>
>>> Given we've not got the Eventbrite for the Ops Meetup live yet, is there 
>>> any chance you could extend the early bird pricing or give operators who 
>>> may be travelling for the Ops Meetup a discount code ? I suspect there may 
>>> be quite a lot of interest for those travelling some distance. 
>>>
>>> Matt
>>>
>>> On 22 June 2016 at 14:58, Mark Voelker  wrote:
>>> Hi Ops,
>>>
>>> FYI for those that may not be aware, that’s also the week of OpenStack 
>>> East.  OpenStack East runs August 23-24 also in New York City (about ~15-20 
>>> minutes away from Civic Hall by MTA at the Playstation Theater).  If you’re 
>>> coming to town for the Ops Midcycle, you may want to make a week of it.  
>>> Earlybird pricing for OpenStack East is still available but prices increase 
>>> tomorrow:
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openstackeast.com_&d=CwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=Pouk4RdhAp3O0-4z088jjeJcdTHWxG2QEHGPaCapbAg&s=pst_dGQnf8jOAggeotgW1NJGzEAbCpWryQ7tNon78IM&e=
>>>  
>>>
>>> At Your Service,
>>>
>>> Mark T. Voelker
>>> (wearer of many hats, one of which is OpenStack East steering committee 
>>> member)
>>>
>>>
>>>
 On Jun 21, 2016, at 11:36 AM, Jonathan D. Proulx  
 wrote:

 Hi All,

 The Ops Meetups Team has selected[1] New York City as the location of the
 next mid-cycle meetup on August 25 and 26 2016 at Civic Hall[2]

 Many thanks to Bloomberg for sponsoring the location.  And thanks to
 BestBuy as well for their offer of the Seattle location.  The choice
 was very close and hopefully their offer will stand for our next North
 American meet-up.

 There's quite a bit of work to do to make this all happen in the
 next couple of months so it's still a great time to join the Ops
 Meetups Team[3] and help out.

 -Jon

 --

 [1] 
 http://eavesdrop.openstack.org/meetings/ops_meetups_team/2016/ops_meetups_team.2016-06-21-14.02.html
 [2] 
 https://urldefense.proofpoint.com/v2/url?u=http-3A__civichall.org_about-2Dcivic-2Dhall_&d=CwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=oAH-SSZ6EFikpmcyUpbf3984kyPBIuLJKkQadC6CKUw&s=36Kl-0b4WBC06xaYXo0V5AM2lHzvjhL48bBV48cz2is&e=
 [3] https://wiki.openstack.org/wiki/Ops_Meetups_Team


 ___
 OpenStack-operators mailing list
 OpenStack-operators@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>> DataCentred Limited registered in England and Wales no. 05611763
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 

Has registration for the Ops event

Re: [Openstack-operators] Next Ops Midcycle NYC August 25-26

[Allison Price]

Hi Anita,

No, registration has not been opened yet. Once it has, we will update the 
mailing list. 

Cheers,
Allison


Allison Price
OpenStack Marketing
alli...@openstack.org


> On Jun 23, 2016, at 3:52 PM, Anita Kuno  wrote:
> 
> On 06/23/2016 04:42 PM, Mark Voelker wrote:
>> Hi Folks,
>> 
>> A quick update on this: today’s the last day of earlybird pricing for 
>> OpenStack East, so if you’d like to attend both events I’d encourage you to 
>> register now (it’s only $99 for the next ~7 hours):
>> 
>> https://www.eventbrite.com/e/openstack-east-tickets-22413148330?ref=ebtnebregn
>> 
>> If you can’t register today, some good news: I spoke with the conference 
>> organizers and it looks like we’ll be able to get some sort of discount code 
>> for folks who are attending the Ops Midcycle and also want to attend 
>> OpenStack East!  We’re still working out logistics, so bear with me—I’ll 
>> send along some more info when I have it.
>> 
>> At Your Service,
>> 
>> Mark T. Voelker
>> 
>> 
>> 
>>> On Jun 22, 2016, at 2:16 PM, Mark Voelker  wrote:
>>> 
>>> It would definitely be cool to have more ops folks attend both events.  I’d 
>>> be happy to check in with the rest of the organizers and see if there’s a 
>>> possibility of working something out.
>>> 
>>> At Your Service,
>>> 
>>> Mark T. Voelker
>>> 
>>> 
>>> 
 On Jun 22, 2016, at 12:27 PM, David Medberry  
 wrote:
 
 Would be sweet if that offer could be extended at least a week as we go 
 through the corp travel process. OTOH, $99 is almost cheap enough to buy 
 and not care I'll be doing that I guess.
 
 On Wed, Jun 22, 2016 at 9:44 AM, Matt Jarvis 
  wrote:
 Hi Mark
 
 Given we've not got the Eventbrite for the Ops Meetup live yet, is there 
 any chance you could extend the early bird pricing or give operators who 
 may be travelling for the Ops Meetup a discount code ? I suspect there may 
 be quite a lot of interest for those travelling some distance. 
 
 Matt
 
 On 22 June 2016 at 14:58, Mark Voelker  wrote:
 Hi Ops,
 
 FYI for those that may not be aware, that’s also the week of OpenStack 
 East.  OpenStack East runs August 23-24 also in New York City (about 
 ~15-20 minutes away from Civic Hall by MTA at the Playstation Theater).  
 If you’re coming to town for the Ops Midcycle, you may want to make a week 
 of it.  Earlybird pricing for OpenStack East is still available but prices 
 increase tomorrow:
 
 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openstackeast.com_&d=CwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=Pouk4RdhAp3O0-4z088jjeJcdTHWxG2QEHGPaCapbAg&s=pst_dGQnf8jOAggeotgW1NJGzEAbCpWryQ7tNon78IM&e=
  
 
 At Your Service,
 
 Mark T. Voelker
 (wearer of many hats, one of which is OpenStack East steering committee 
 member)
 
 
 
> On Jun 21, 2016, at 11:36 AM, Jonathan D. Proulx  
> wrote:
> 
> Hi All,
> 
> The Ops Meetups Team has selected[1] New York City as the location of the
> next mid-cycle meetup on August 25 and 26 2016 at Civic Hall[2]
> 
> Many thanks to Bloomberg for sponsoring the location.  And thanks to
> BestBuy as well for their offer of the Seattle location.  The choice
> was very close and hopefully their offer will stand for our next North
> American meet-up.
> 
> There's quite a bit of work to do to make this all happen in the
> next couple of months so it's still a great time to join the Ops
> Meetups Team[3] and help out.
> 
> -Jon
> 
> --
> 
> [1] 
> http://eavesdrop.openstack.org/meetings/ops_meetups_team/2016/ops_meetups_team.2016-06-21-14.02.html
> [2] 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__civichall.org_about-2Dcivic-2Dhall_&d=CwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=oAH-SSZ6EFikpmcyUpbf3984kyPBIuLJKkQadC6CKUw&s=36Kl-0b4WBC06xaYXo0V5AM2lHzvjhL48bBV48cz2is&e=
> [3] https://wiki.openstack.org/wiki/Ops_Meetups_Team
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 
 ___
 OpenStack-operators mailing list
 OpenStack-operators@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 
 
 DataCentred Limited registered in England and Wales no. 05611763
 ___
 OpenStack-operators mailing list
 OpenStack-operators@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 
 
>>> 
>>> ___
>>> Op

Re: [Openstack-operators] Packaging Virtualenvs

[Doug Hellmann]

Excerpts from Silence Dogood's message of 2016-06-23 15:45:34 -0400:
> I know from conversations that a few folks package their python apps as
> distributable virtualenvs.   spotify created dh-virtualenv for this.  you
> can do it pretty simply by hand.
> 
> I built a toolchain for building rpms as distributable virtualenvs and that
> works really well.
> 
> What I'd like to do is make it so that every app that's built as a
> virtualenv gets setup to automatically execute at call time in their
> virtualenv.
> 
> I see two options:
> 
> 1)  Dynamically generate a wrapper script during build and put it in the
> RPM.  Call the wrapper.
> 
> 2)  Created a dependency global module ( as an rpm ) set it as a
> dependency.  And basically it'd be an autoexecuting import that
> instantiates the virtualenv.  it would probably know all it needs to
> because I am building all my packages to an internal standard.  Then when
> building the APP rpm all I need to do is inject an import into the import
> chain if it's being built as a virtualenv.  Then I have what are
> effectively statically compiled python apps.
> 
> I like 2.  But 1 isn't very bad.  Both are a little hokey.
> 
> Was curious if folks might have a preference, or a better idea.
> 
> Thanks.
> 
> Matt

I'm not sure what you mean by a "wrapper script".  If you run the
Python console script from within the virtualenv you've packaged,
you shouldn't need to do anything to "activate" that environment
separately because it should have the correct shebang line.

Are you seeing different behavior?

Doug

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

Re: [Openstack-operators] Packaging Virtualenvs

[Kris G. Lindgren]

When we did this within CentOS6 with the python 2.7 software collection.  When 
nova called into nova-rootwrap, rootwrap was called without any of the software 
collection or venv stuff activated. So we had to move rootwrap to rootwrap-real 
and create a shell script that did the needful (activate the software 
collection and activate the venv, then call rootwrap-real).

Other than that we just modified the normal upstart scripts to activate the 
venv before executing the service like normal.  Under systemd one would do the 
same.  We never packaged the openstack clients into venv's, but if we did one 
could just add the correct stuff to your keystonerc file.
___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy







On 6/23/16, 3:12 PM, "Doug Hellmann"  wrote:

>Excerpts from Silence Dogood's message of 2016-06-23 15:45:34 -0400:
>> I know from conversations that a few folks package their python apps as
>> distributable virtualenvs.   spotify created dh-virtualenv for this.  you
>> can do it pretty simply by hand.
>> 
>> I built a toolchain for building rpms as distributable virtualenvs and that
>> works really well.
>> 
>> What I'd like to do is make it so that every app that's built as a
>> virtualenv gets setup to automatically execute at call time in their
>> virtualenv.
>> 
>> I see two options:
>> 
>> 1)  Dynamically generate a wrapper script during build and put it in the
>> RPM.  Call the wrapper.
>> 
>> 2)  Created a dependency global module ( as an rpm ) set it as a
>> dependency.  And basically it'd be an autoexecuting import that
>> instantiates the virtualenv.  it would probably know all it needs to
>> because I am building all my packages to an internal standard.  Then when
>> building the APP rpm all I need to do is inject an import into the import
>> chain if it's being built as a virtualenv.  Then I have what are
>> effectively statically compiled python apps.
>> 
>> I like 2.  But 1 isn't very bad.  Both are a little hokey.
>> 
>> Was curious if folks might have a preference, or a better idea.
>> 
>> Thanks.
>> 
>> Matt
>
>I'm not sure what you mean by a "wrapper script".  If you run the
>Python console script from within the virtualenv you've packaged,
>you shouldn't need to do anything to "activate" that environment
>separately because it should have the correct shebang line.
>
>Are you seeing different behavior?
>
>Doug
>
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Packaging Virtualenvs

[Matt Joyce]

I want the script to dynamically instantiate the venv is call activate this at 
execution time and deactivate when done.



On June 23, 2016 5:12:07 PM EDT, Doug Hellmann  wrote:
>Excerpts from Silence Dogood's message of 2016-06-23 15:45:34 -0400:
>> I know from conversations that a few folks package their python apps
>as
>> distributable virtualenvs.   spotify created dh-virtualenv for this. 
>you
>> can do it pretty simply by hand.
>> 
>> I built a toolchain for building rpms as distributable virtualenvs
>and that
>> works really well.
>> 
>> What I'd like to do is make it so that every app that's built as a
>> virtualenv gets setup to automatically execute at call time in their
>> virtualenv.
>> 
>> I see two options:
>> 
>> 1)  Dynamically generate a wrapper script during build and put it in
>the
>> RPM.  Call the wrapper.
>> 
>> 2)  Created a dependency global module ( as an rpm ) set it as a
>> dependency.  And basically it'd be an autoexecuting import that
>> instantiates the virtualenv.  it would probably know all it needs to
>> because I am building all my packages to an internal standard.  Then
>when
>> building the APP rpm all I need to do is inject an import into the
>import
>> chain if it's being built as a virtualenv.  Then I have what are
>> effectively statically compiled python apps.
>> 
>> I like 2.  But 1 isn't very bad.  Both are a little hokey.
>> 
>> Was curious if folks might have a preference, or a better idea.
>> 
>> Thanks.
>> 
>> Matt
>
>I'm not sure what you mean by a "wrapper script".  If you run the
>Python console script from within the virtualenv you've packaged,
>you shouldn't need to do anything to "activate" that environment
>separately because it should have the correct shebang line.
>
>Are you seeing different behavior?
>
>Doug
>
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Packaging Virtualenvs

[Xav Paice]

Can I suggest that using the tool https://github.com/openstack/giftwrap
might make live a bunch easier?

I went down a similar path with building Debs in a venv using
dh_virtualenv, with some good success when I sorted the shebang. I later
found that the debs produced by Giftwrap are not only very easy to build
and test, but also take a bunch less effort to maintain and create new
packages for new things.  To run the resulting code, I just symlink the
${venv}/bin/$binary to /usr/local/bin and run the thing using very
similar init scripts to the ones supplied by the distro packages.  Works
like a charm, because the shebang in the binary points at the venv, not
the system python.

I do, however, package the init scripts, sample configs, etc in a
separate .deb, which is really very quick and easy and allows me to
control the bits I want to, and let Giftwrap take care of the OpenStack
code repos.


On Thu, 2016-06-23 at 23:40 +, Matt Joyce wrote:
> I want the script to dynamically instantiate the venv is call activate
> this at execution time and deactivate when done.
> 
> 
> 
> On June 23, 2016 5:12:07 PM EDT, Doug Hellmann 
> wrote:
> Excerpts from Silence Dogood's message of 2016-06-23 15:45:34 -0400:
>  I know from conversations that a few folks package their 
> python apps as
>  distributable virtualenvs.   spotify created dh-virtualenv 
> for this.  you
>  can do it pretty simply by hand.
>  
>  I built a toolchain for building rpms as distributable 
> virtualenvs and that
>  works really well.
>  
>  What I'd like to do is make it so that every app that's 
> built as a
>  virtualenv gets setup to automatically execute at call time 
> in their
>  virtualenv.
>  
>  I see two options:
>  
>  1)  Dynamically generate a wrapper script during build and 
> put it in the
>  RPM.  Call the wrapper.
>  
>  2)  Created a dependency global module ( as an rpm ) set it 
> as a
>  dependency.  And basically it'd be an autoexecuting import 
> that
> 
> instantiates the virtualenv.  it would probably know all it 
> needs to
>  because I am building all my packages to an internal 
> standard.  Then when
>  building the APP rpm all I need to do is inject an import 
> into the import
>  chain if it's being built as a virtualenv.  Then I have what 
> are
>  effectively statically compiled python apps.
>  
>  I like 2.  But 1 isn't very bad.  Both are a little hokey.
>  
>  Was curious if folks might have a preference, or a better 
> idea.
>  
>  Thanks.
>  
>  Matt
> 
> I'm not sure what you mean by a "wrapper script".  If you run the
> Python console script from within the virtualenv you've packaged,
> you shouldn't need to do anything to "activate" that environment
> separately because it should have the correct shebang line.
> 
> Are you seeing different behavior?
> 
> Doug
> 
> 
> __
> 
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



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

Re: [Openstack-operators] Packaging Virtualenvs

[Silence Dogood]

I'll check out giftwrap.  never heard of it.  But interesting.

On Thu, Jun 23, 2016 at 7:50 PM, Xav Paice  wrote:

> Can I suggest that using the tool https://github.com/openstack/giftwrap
> might make live a bunch easier?
>
> I went down a similar path with building Debs in a venv using
> dh_virtualenv, with some good success when I sorted the shebang. I later
> found that the debs produced by Giftwrap are not only very easy to build
> and test, but also take a bunch less effort to maintain and create new
> packages for new things.  To run the resulting code, I just symlink the
> ${venv}/bin/$binary to /usr/local/bin and run the thing using very
> similar init scripts to the ones supplied by the distro packages.  Works
> like a charm, because the shebang in the binary points at the venv, not
> the system python.
>
> I do, however, package the init scripts, sample configs, etc in a
> separate .deb, which is really very quick and easy and allows me to
> control the bits I want to, and let Giftwrap take care of the OpenStack
> code repos.
>
>
> On Thu, 2016-06-23 at 23:40 +, Matt Joyce wrote:
> > I want the script to dynamically instantiate the venv is call activate
> > this at execution time and deactivate when done.
> >
> >
> >
> > On June 23, 2016 5:12:07 PM EDT, Doug Hellmann 
> > wrote:
> > Excerpts from Silence Dogood's message of 2016-06-23 15:45:34
> -0400:
> >  I know from conversations that a few folks package
> their python apps as
> >  distributable virtualenvs.   spotify created
> dh-virtualenv for this.  you
> >  can do it pretty simply by hand.
> >
> >  I built a toolchain for building rpms as distributable
> virtualenvs and that
> >  works really well.
> >
> >  What I'd like to do is make it so that every app that's
> built as a
> >  virtualenv gets setup to automatically execute at call
> time in their
> >  virtualenv.
> >
> >  I see two options:
> >
> >  1)  Dynamically generate a wrapper script during build
> and put it in the
> >  RPM.  Call the wrapper.
> >
> >  2)  Created a dependency global module ( as an rpm )
> set it as a
> >  dependency.  And basically it'd be an autoexecuting
> import that
> >
> > instantiates the virtualenv.  it would probably know all
> it needs to
> >  because I am building all my packages to an internal
> standard.  Then when
> >  building the APP rpm all I need to do is inject an
> import into the import
> >  chain if it's being built as a virtualenv.  Then I have
> what are
> >  effectively statically compiled python apps.
> >
> >  I like 2.  But 1 isn't very bad.  Both are a little
> hokey.
> >
> >  Was curious if folks might have a preference, or a
> better idea.
> >
> >  Thanks.
> >
> >  Matt
> >
> > I'm not sure what you mean by a "wrapper script".  If you run the
> > Python console script from within the virtualenv you've packaged,
> > you shouldn't need to do anything to "activate" that environment
> > separately because it should have the correct shebang line.
> >
> > Are you seeing different behavior?
> >
> > Doug
> >
> >
> > __
> >
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Packaging Virtualenvs

[John Dewey]

Not only is it interesting, it’s awesome :)

John


On June 23, 2016 at 5:53:59 PM, Silence Dogood (m...@nycresistor.com) wrote:

I'll check out giftwrap.  never heard of it.  But interesting.

On Thu, Jun 23, 2016 at 7:50 PM, Xav Paice  wrote:

> Can I suggest that using the tool https://github.com/openstack/giftwrap
> might make live a bunch easier?
>
> I went down a similar path with building Debs in a venv using
> dh_virtualenv, with some good success when I sorted the shebang. I later
> found that the debs produced by Giftwrap are not only very easy to build
> and test, but also take a bunch less effort to maintain and create new
> packages for new things.  To run the resulting code, I just symlink the
> ${venv}/bin/$binary to /usr/local/bin and run the thing using very
> similar init scripts to the ones supplied by the distro packages.  Works
> like a charm, because the shebang in the binary points at the venv, not
> the system python.
>
> I do, however, package the init scripts, sample configs, etc in a
> separate .deb, which is really very quick and easy and allows me to
> control the bits I want to, and let Giftwrap take care of the OpenStack
> code repos.
>
>
> On Thu, 2016-06-23 at 23:40 +, Matt Joyce wrote:
> > I want the script to dynamically instantiate the venv is call activate
> > this at execution time and deactivate when done.
> >
> >
> >
> > On June 23, 2016 5:12:07 PM EDT, Doug Hellmann 
> > wrote:
> > Excerpts from Silence Dogood's message of 2016-06-23 15:45:34
> -0400:
> >  I know from conversations that a few folks package
> their python apps as
> >  distributable virtualenvs.   spotify created
> dh-virtualenv for this.  you
> >  can do it pretty simply by hand.
> >
> >  I built a toolchain for building rpms as distributable
> virtualenvs and that
> >  works really well.
> >
> >  What I'd like to do is make it so that every app that's
> built as a
> >  virtualenv gets setup to automatically execute at call
> time in their
> >  virtualenv.
> >
> >  I see two options:
> >
> >  1)  Dynamically generate a wrapper script during build
> and put it in the
> >  RPM.  Call the wrapper.
> >
> >  2)  Created a dependency global module ( as an rpm )
> set it as a
> >  dependency.  And basically it'd be an autoexecuting
> import that
> >
> > instantiates the virtualenv.  it would probably know all
> it needs to
> >  because I am building all my packages to an internal
> standard.  Then when
> >  building the APP rpm all I need to do is inject an
> import into the import
> >  chain if it's being built as a virtualenv.  Then I have
> what are
> >  effectively statically compiled python apps.
> >
> >  I like 2.  But 1 isn't very bad.  Both are a little
> hokey.
> >
> >  Was curious if folks might have a preference, or a
> better idea.
> >
> >  Thanks.
> >
> >  Matt
> >
> > I'm not sure what you mean by a "wrapper script".  If you run the
> > Python console script from within the virtualenv you've packaged,
> > you shouldn't need to do anything to "activate" that environment
> > separately because it should have the correct shebang line.
> >
> > Are you seeing different behavior?
> >
> > Doug
> >
> >
> > __
> >
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

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