Re: [openstack-dev] [solum] Consistency of development environment

[Paul Czarkowski]

>
>While I installed dnsmasq 2.63 manually, they used Ubuntu 14.04 to get
>around the problem. Is it maybe time to upgrade the base for the dev env
>to 14.04, or would that cause many other problems? Have you tried that
>out? If you have a pointer to an appropriate 14.04 image I can configure
>in Vagrant, I'd like to play with that a bit. Maybe that would also
>solve the problem with openvswitch.


We have actually recently upgraded our Vagrant environment to 14.04 so if
you pull from master from  https://github.com/rackerlabs/vagrant-solum-dev
you should get a working 14.04 instance.

We couldn¹t upgrade to 14.04 as quickly as we hoped as there is a bug that
we had to resolve with ubuntu system packages -
https://bugs.launchpad.net/solum/+bug/1365679


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

Re: [openstack-dev] [DevStack] neutron config not working

[Paul Czarkowski]

I¹m seeing similar. Instances launch,  they show as having Ips in
`neutron list`  but I cannot access them via IP.

Other thing I¹ve notices is that doing a `neutron agent-list` gives me an
empty list,  I would assume it should at least show the dhcp agent ?

On 7/1/14, 12:00 PM, "Kyle Mestery"  wrote:

>Hi Rob:
>
>Can you try adding the following config to your local.conf? I'd like
>to see if this gets you going or not. It will force it to use gre
>tunnels for tenant networks. By default it will not.
>
>ENABLE_TENANT_TUNNELS=True
>
>On Tue, Jul 1, 2014 at 10:53 AM, Rob Crittenden 
>wrote:
>> Rob Crittenden wrote:
>>> Mark Kirkwood wrote:
 On 25/06/14 10:59, Rob Crittenden wrote:
> Before I get punted onto the operators list, I post this here because
> this is the default config and I'd expect the defaults to just work.
>
> Running devstack inside a VM with a single NIC configured and this in
> localrc:
>
> disable_service n-net
> enable_service q-svc
> enable_service q-agt
> enable_service q-dhcp
> enable_service q-l3
> enable_service q-meta
> enable_service neutron
> Q_USE_DEBUG_COMMAND=True
>
> Results in a successful install but no DHCP address assigned to
>hosts I
> launch and other oddities like no CIDR in nova net-list output.
>
> Is this still the default way to set things up for single node? It is
> according to https://wiki.openstack.org/wiki/NeutronDevstack
>
>

 That does look ok: I have an essentially equivalent local.conf:

 ...
 ENABLED_SERVICES+=,-n-net
 ENABLED_SERVICES+=,q-svc,q-agt,q-dhcp,q-l3,q-meta,q-metering,tempest

 I don't have 'neutron' specifically enabled... not sure if/why that
 might make any difference tho. However instance launching and ip
address
 assignment seem to work ok.

 However I *have* seen the issue of instances not getting ip addresses
in
 single host setups, and it is often due to use of virt io with bridges
 (with is the default I think). Try:

 nova.conf:
 ...
 libvirt_use_virtio_for_bridges=False
>>>
>>> Thanks for the suggestion. At least in master this was replaced by a
>>>new
>>> section, libvirt, but even setting it to False didn't do the trick for
>>> me. I see the same behavior.
>>
>> OK, I've tested the havana and icehouse branches in F-20 and they don't
>> seem to have a working neutron either. I see the same thing. I can
>> launch a VM but it isn't getting a DHCP address.
>>
>> Maybe I'll try in some Ubuntu release to see if this is Fedora-specific.
>>
>> rob
>>
>>
>> ___
>> 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


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

[openstack-dev] [neutron] devstack w/ neutron in vagrant - floating IPs

[Paul Czarkowski]

Has anyone had any success with running devstack and neutron in a vagrant 
machine where the floating Ips are accessible from outside of the vagrant box ( 
I.e. From the host ).

I’ve spent a few hours trying to get it working without any real success.

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

Re: [openstack-dev] [infra][nova][docker]

[Paul Czarkowski]

Based on this feedback I have removed the docker portions of the review to
devstack
But have kept in the changes that make it easier for a nova drivers to add
their own
Files to the nova rootwrap.d directory.

On 4/11/14 10:47 AM, "Russell Bryant"  wrote:

>On 04/11/2014 11:28 AM, Paul Czarkowski wrote:
>> I would rather see the devstack support be integrated in devstack's repo
>> itself.   There's a review
>> Outstanding for devstack[1] that adds this support in and also adds in
>> some pieces to make
>> it easier to utilize external nova drivers.
>> 
>> 
>> If that fails out then I'm all for merging in your review to the
>> nova-docker driver.  We're
>> Currently using nova-docker for Solum and having the devstack support
>> would help us out a lot.
>> 
>> There is some ugliness in the nova-docker review[2] that we could avoid
>>by
>> merging the integration
>> directly into devstack.
>>  
>> [1] https://review.openstack.org/#/c/84839/
>> [2] 
>>https://review.openstack.org/#/c/81097/3/contrib/devstack/stackrc.diff
>
>Agree that directly in devstack is easier, but I just don't see that
>happening.  They've been pretty clear on only including support for
>things in official projects.
>
>See Sean's review of "I feel like this should be done entirely as an
>extras.d file which is actually in the docker driver tree. If there are
>call points which are needed in extras.d, we should add those."
>
>So, I think we should proceed with the support in the nova-docker repo
>for now.  That will unblock CI progress against nova-docker, which is
>the #1 blocker for eventually re-proposing the driver to nova itself.
>
>-- 
>Russell Bryant
>
>___
>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] [infra][nova][docker]

[Paul Czarkowski]

I would rather see the devstack support be integrated in devstack's repo
itself.   There's a review
Outstanding for devstack[1] that adds this support in and also adds in
some pieces to make
it easier to utilize external nova drivers.


If that fails out then I'm all for merging in your review to the
nova-docker driver.  We're
Currently using nova-docker for Solum and having the devstack support
would help us out a lot.

There is some ugliness in the nova-docker review[2] that we could avoid by
merging the integration
directly into devstack.
 
[1] https://review.openstack.org/#/c/84839/
[2] https://review.openstack.org/#/c/81097/3/contrib/devstack/stackrc.diff


On 4/11/14 9:53 AM, "Russell Bryant"  wrote:

>On 04/11/2014 10:11 AM, Derek Higgins wrote:
>> Hi All,
>> 
>> I've been taking a look at devstack support for nova-docker[1] which
>> was recently taken out of nova. I stumbled across a similar effort
>> currently underway[2], so have based my work off that.
>> 
>> What I hope to do is setup a check doing CI on devstack-f20 nodes[3],
>> this will setup a devstack based nova with the nova-docker driver and
>> can then run what ever tests make sense (currently only a minimal test,
>> Eric I believe you were looking at tempest support maybe it could be
>> hooked in here?).
>> 
>> I've taken this as far as I can locally to make sure it all works on a
>> manually setup devstack-f20 node and it works, of course there may be
>> slight differences in what nodepool sets up but we can't know that until
>> we try :-)
>> 
>> So I'd like to give this a go, I've left the various patches in WIP for
>> the moment so people can take a look etc...
>> https://review.openstack.org/86905
>> https://review.openstack.org/86910
>> 
>> Any thoughts?
>> 
>> thanks,
>> Derek.
>> 
>> [1] http://git.openstack.org/cgit/stackforge/nova-docker
>> [2] https://review.openstack.org/#/c/81097/
>> [3] https://review.openstack.org/#/c/86842/
>
>Hugely appreciated!
>
>It'd be nice to have one other person ACK the devstack integration and
>then I think we should merge it.
>
>I know last cycle we were looking at 3rd party CI, but that was because
>of timing and infra review availability.  I think a re-focus on doing it
>in openstack's infra is the right approach.
>
>-- 
>Russell Bryant
>
>___
>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] [Openstack][Nova][Docker] Devstack with docker driver

[Paul Czarkowski]

There is a bug in the default docker registry.   Set this is your localrc
and it should work

DOCKER_REGISTRY_IMAGE=samalba/docker-registry

On 3/12/14 1:35 AM, "urgensherpa"  wrote:

>hello there,i setup using devstack ..below is my docker version output
>--
>
>redhat@test:~/devstack$ docker version
>Client version: 0.7.6
>Go version (client): go1.2
>Git commit (client): bc3b2ec
>Server version: 0.7.6
>Git commit (server): bc3b2ec
>Go version (server): go1.2
>Last stable version: 0.9.0, please update docker
>--
>-
>I followed a guide from
>*http://damithakumarage.wordpress.com/2014/01/31/how-to-setup-openstack-ha
>vana-with-docker-driver/*
>
>--
>-
>I tagged an image using
>
>$ docker tag urgensherpa/lamp6 192.168.140.193:5042/lamp6
>Below is my 'docker push' commad output.
>
>redhat@test:~/devstack$ docker push 192.168.140.193:5042/lamp6
>
>The push refers to a repository [192.168.140.193:5042/lamp6] (len: 1)
>Sending image list
>Pushing repository 192.168.140.193:5042/lamp6 (1 tags)
>2014/03/11 13:22:03 HTTP code 500 while uploading metadata: invalid
>character Œ<' looking for beginning of value
>--
>
>Please let me know what i need to do thanks
>
>
>
>--
>View this message in context:
>http://openstack.10931.n7.nabble.com/Openstack-Nova-Docker-Devstack-with-d
>ocker-driver-tp28361p34942.html
>Sent from the Developer mailing list archive at Nabble.com.
>
>___
>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] [Solum] Regarding language pack database schema

[Paul Czarkowski]

I'm also a +1 for #2.However as discussed on IRC,  we should clearly
spell out that the JSON blob should never be treated in a SQL-like manner.
  The moment somebody says 'I want to make that item in the json
searchable' is the time to discuss adding it as part of the SQL schema.

On 2/13/14 4:39 PM, "Clayton Coleman"  wrote:

>I like option #2, simply because we should force ourselves to justify
>every attribute that is extracted as a queryable parameter, rather than
>making them queryable at the start.
>
>- Original Message -
>> Hi Arati,
>> 
>> 
>> I would vote for Option #2 as a short term solution. Probably later we
>>can
>> consider using NoSQL DB or MariaDB which has Column_JSON type to store
>> complex types.
>> 
>> Thanks
>> Georgy
>> 
>> 
>> On Thu, Feb 13, 2014 at 8:12 AM, Arati Mahimane <
>> arati.mahim...@rackspace.com > wrote:
>> 
>> 
>> 
>> Hi All,
>> 
>> I have been working on defining the Language pack database schema. Here
>>is a
>> link to my review which is still a WIP -
>> https://review.openstack.org/#/c/71132/3 .
>> There are a couple of different opinions on how we should be designing
>>the
>> schema.
>> 
>> Language pack has several complex attributes which are listed here -
>> https://etherpad.openstack.org/p/Solum-Language-pack-json-format
>> We need to support search queries on language packs based on various
>> criteria. One example could be 'find a language pack where type='java'
>>and
>> version>1.4'
>> 
>> Following are the two options that are currently being discussed for
>>the DB
>> schema:
>> 
>> Option 1: Having a separate table for each complex attribute, in order
>>to
>> achieve normalization. The current schema follows this approach.
>> However, this design has certain drawbacks. It will result in a lot of
>> complex DB queries and each new attribute will require a code change.
>> Option 2: We could have a predefined subset of attributes on which we
>>would
>> support search queries.
>> In this case, we would define columns (separate tables in case of
>>complex
>> attributes) only for this subset of attributes and all other attributes
>>will
>> be a part of a json blob.
>> With this option, we will have to go through a schema change in case we
>> decide to support search queries on other attributes at a later stage.
>> 
>> I would like to know everyone's thoughts on these two approaches so
>>that we
>> can take a final decision and go ahead with one approach.
>> Suggestions regarding any other approaches are welcome too!
>> 
>> Thanks,
>> Arati
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> 
>> --
>> Georgy Okrokvertskhov
>> Architect,
>> OpenStack Platform Products,
>> Mirantis
>> http://www.mirantis.com
>> Tel. +1 650 963 9828
>> Mob. +1 650 996 3284
>> 
>> ___
>> 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


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

Re: [openstack-dev] [Solum] Question about Zuul's role in Solum

[Paul Czarkowski]

On 2/12/14 5:16 PM, "Roshan Agrawal"  wrote:

>
>> -Original Message-
>> From: devdatta kulkarni [mailto:devdatta.kulka...@rackspace.com]
>> Sent: Wednesday, February 12, 2014 3:26 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Solum] Question about Zuul's role in Solum
>> 
>> Hi,
>> 
>> I have been looking at Zuul for last few days and had a question about
>>its
>> intended role within Solum.
>> 
>> From what I understand, Zuul is a code gating system.
>> 
>> I have been wondering if code gating is something we are considering as
>>a
>> feature to be provided in Solum? If yes, then Zuul is a perfect fit.
>> But if not, then we should discuss what benefits do we gain by using
>>Zuul as
>> an integral part of Solum.
>> 
>> It feels to me that right now we are treating Zuul as a conduit for
>>triggering
>> job(s) that would do the following:
>> - clone/download source
>> - run tests
>> - create a deployment unit (DU) if tests pass
>> - upload DU to glance
>> - trigger the DU deployment workflow
>> 
>> In the language-pack working group we have talked about being able to
>>do CI
>> on the submitted code and building the DUs only after tests pass.
>> Now, there is a distinction between doing CI on merged code vs.
>> doing it before code is permanently merged to master/stable branches.
>> The latter is what a 'code gating' system does, and Zuul is a perfect
>>fit for this.
>> For the former though, using a code gating system is not be needed.
>> We can achieve the former with an API endpoint, a queue, and a mechanism
>> to trigger job(s) that perform above mentioned steps.
>> 
>> I guess it comes down to Solum's vision. If the vision includes
>>supporting,
>> among other things, code gating to ensure that Solum-managed code is
>> never broken, then Zuul is a perfect fit.
>> Of course, in that situation we would want to ensure that the gating
>> functionality is pluggable so that operators can have a choice of
>>whether to
>> use Zuul or something else.
>> But if the vision is to be that part of an overall application lifecycle
>> management flow which deals with creation and scaling of
>> DUs/plans/assemblies but not necessarily be a code gate, then we should
>>re-
>> evaluate Zuul's role as an integral part of Solum.
>
>The question is: is Zuul the right tool for the code deployment workflow
>you outlined above? The code deployment workflow is the higher order
>need. 
>
>The code gating functionality is also useful and potentially something we
>would want to implement in Solum at some point, but the decision criteria
>on what tool we use to implement the code deployment workflow depends on
>how good is Zuul in helping us with the deployment workflow.
>
>> Thoughts?
>> 
>> Thanks,
>> Devdatta
>> 
>> 
>> 
>> ___
>> 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


The current proposed workflow for Solum (m1) is shorthanded to be something
like this

1. User writes code
2. User pushes to master branch in github
3. a github hook fires against the solum API.
4. Solum coordinates the testing/building and deployment of the app

None of this seems overly suitable for zuul to me ( not without a
significant
amount of work that will be needed to customize zuul to work for us ), and
can be easily ( for certain values of easy ) achieved with solum
forking a thread to do the build ( m1 implementation ? ) or solum
sending messages to a set of worker nodes watching a queue ( marconi? Post
m1, pluggable so operator could use their existing jenkins, etc ).

If an enterprise or provider wanted to implement code gating it would slip
in before option 1,  and would be relatively simple for an operator to
plug in their existing code gating/review tooling (github
PRs,CodeCollaborator,Crucible+Bamboo) or set up Gerrit/Zuul system:

1. User writes code
2. User runs `git review`
3. Gerrit calls zuul to run automated tests
4. Core reviewers +2 the code
5. Gerrit merges code to master branch in github
6. a github hook fires against the solum API
7. Solum coordinates the testing/building and deployment of the app


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

Re: [openstack-dev] [Solum] Lang-pack working group meeting cancelled today due to freenode DOS, will be rescheduled

[Paul Czarkowski]

Works for me.

On 2/4/14 11:07 AM, "devdatta kulkarni" 
wrote:

>Sounds good to me.
>
>- Devdatta
>
>-Original Message-
>From: "Clayton Coleman" 
>Sent: Monday, February 3, 2014 12:10pm
>To: "OpenStack Development Mailing List (not for usage questions)"
>
>Subject: Re: [openstack-dev] [Solum] Lang-pack working group meeting
>cancelled today due to freenode DOS, will be rescheduled
>
>Good point.  We can try immediately after the git inter workflow if folks
>prefer.  12pm US CST, 1pm EST.
>
>- Original Message -
>> Which time zone?
>> 
>> On Wednesdays between 11.00am - noon (US Central time) there is git
>> integration working group meeting.
>> 
>> 
>> -Original Message-
>> From: "Clayton Coleman" 
>> Sent: Monday, February 3, 2014 10:35am
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: [openstack-dev] [Solum] Lang-pack working group meeting
>>cancelled
>> today due to freenode DOS, will be rescheduled
>> 
>> Maybe wednesday at noon?
>> 
>> ___
>> 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
>> 
>
>___
>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


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

Re: [openstack-dev] [solum] Issues in running tests

[Paul Czarkowski]

If you're running on a machine with devstack these dependencies *should* 
already be met.

If you like to work on VMs on your local box I have build a Vagrant dev 
environment that should take care of your dependencies here - 
https://github.com/rackerlabs/vagrant-solum-dev

I think it's documented pretty well,  but if you want to use it and have any 
issues, reach out to me and I'll help.


From: Rajdeep Dua mailto:dua_rajd...@yahoo.com>>
Reply-To: Rajdeep Dua mailto:dua_rajd...@yahoo.com>>, 
"OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Sunday, February 2, 2014 10:46 AM
To: Julien Vey mailto:vey.jul...@gmail.com>>, "OpenStack 
Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [solum] Issues in running tests

Thanks that worked


On Sunday, February 2, 2014 7:17 PM, Julien Vey 
mailto:vey.jul...@gmail.com>> wrote:
Hi Rajdeep,

We just updated the 
documentation 
recently with some necessary packages to install :  libxml2-dev and libxslt-dev.
You just need to install those 2 packages.
If you are on Ubuntu, see 
http://stackoverflow.com/questions/6504810/how-to-install-lxml-on-ubuntu/6504860#6504860

Julien


2014-02-02 Rajdeep Dua mailto:dua_rajd...@yahoo.com>>:
Hi,
I am facing some errors running tests in a fresh installation of solum

$tox -e py27



gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -fPIC 
-I/home/hadoop/work/openstack/solum-2/solum/.tox/py27/build/lxml/src/lxml/includes
 -I/usr/include/python2.7 -c src/lxml/lxml.etree.c -o 
build/temp.linux-x86_64-2.7/src/lxml/lxml.etree.o -w

In file included from src/lxml/lxml.etree.c:340:0:

/home/hadoop/work/openstack/solum-2/solum/.tox/py27/build/lxml/src/lxml/includes/etree_defs.h:9:31:
 fatal error: libxml/xmlversion.h: No such file or directory

compilation terminated.

error: command 'gcc' failed with exit status 1



Thanks
Rajdeep

___
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

[openstack-dev] [solum][general] some pip package installs from requirements.txt fail when using pip 1.5

[Paul Czarkowski]

I have a box with a newer version of pip ( 1.5 ) and it refuses to install 
netaddr >= 0.7.6 as it's an external/insecure pip package.This may cause 
issues for devs that are running newer versions of pip than standard system 
packages.   There maybe other packages in the larger global-requirements ( 
https://github.com/openstack/requirements/blob/master/global-requirements.txt ) 
that will suffer the same fate.

The error message looks something like this

Downloading/unpacking netaddr>=0.7.6 (from -r requirements.txt (line 3))
  Could not find a version that satisfies the requirement netaddr>=0.7.6 (from 
-r requirements.txt (line 3)) (from versions: 0.3.1, 0.3.1, 0.4, 0.4, 0.5.1, 
0.5.1, 0.5.2, 0.5.2, 0.5, 0.5, 0.6.1, 0.6.1, 0.6.2, 0.6.2, 0.6.3, 0.6.3, 0.6.4, 
0.6.4, 0.6, 0.6, 0.7.1, 0.7.1, 0.7.2, 0.7.2, 0.7.3, 0.7.3, 0.7, 0.7)
  Some insecure and unverifiable files were ignored (use --allow-unverified 
netaddr to allow).
Cleaning up...
No distributions matching the version for netaddr>=0.7.6 (from -r 
requirements.txt (line 3))
Storing debug log for failure in /home/paul6951/.pip/pip.log

Dropping the netaddr version to 0.7.3 fixes the error I see as does running 
'pip install --allow-all-external --allow-unverified netaddr  -r 
requirements.txt'


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

Re: [openstack-dev] [Solum] MySQL Storage Engine

[Paul Czarkowski]

On 12/4/13 3:06 PM, "Adrian Otto"  wrote:

>
>On Dec 4, 2013, at 12:32 PM, Monty Taylor  wrote:
>
>> On 12/04/2013 03:25 PM, Clint Byrum wrote:
>>> Excerpts from Paul Montgomery's message of 2013-12-04 12:04:06 -0800:
 TLDR: Should Solum log a warning if operators do not use the InnoDB
 storage engine with MySQL in Solum's control plane?
 
 
 Details:
 
 I was looking at: https://review.openstack.org/#/c/57024/
 Models.py to be specific.
 
 The default storage engine is InnoDB for MySQL which is good.  I took
a
 quick look at the storage engines and only InnoDB seems reasonable
for the
 Solum control plane (it is ACID complaint).  I assume that we'll all
be
 coding towards an ACID compliant database for performance (not having
to
 revalidate database writes and consistency and such) and ease of
 development.
 
 If all of that is true, should we log a warning to the operator that
they
 are using an untested and potentially problematic storage engine
(which in
 a worst case scenario can corrupt their data)?  Should we even enable
an
 operator to change the storage engine through configuration?  I think
 enabling that configuration is fine as long as we make sure that the
 operator knows that they are on their own with this unsupported
 configuration but I welcome thoughts from the group on this topic.
 
>>> 
>>> Just assume MyISAM _does not exist_. It is 2013 for crying out loud.
>>> 
>>> If somebody accidentally uses MyISAM, point at them and laugh, but then
>>> do help them pick up the pieces when it breaks.
>>> 
>>> In all seriousness, if you can force the engine to InnoDB, do that.
>>> Otherwise, just ignore this. We are all consenting adults here and if
>>> people cant' RTFM on MySQL, they shouldn't be storing data in it.
>> 
>> +1000
>
>So are you suggesting we have a bit of database code in Solum that would
>quickly check the Engine of each table upon startup. Something like:
>
>SHOT TABLE STATUS LIKE '%solum%';
>
>Šand iterate the Engine column looking for anything not InnoDB, and
>logging a warning error if other values are found?
>
>Or, are you suggesting that we just trust people not to be fools, and
>leave this subject alone completely?
>
>Thanks,
>
>Adrian
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


I think if we're abstracting the database via a library like SQLAlchemy
then we should assume the person at the other end knows how to configure a
database.  Otherwise do we have to do the same for every database
supported by that library.

If an Operator can manage to install and run and production openstack,
plus solum,  we should be fairly confident they're able to set up a good
mysql.


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