Re: [openstack-dev] [heat] [scheduler] Bringing things together for Icehouse (now featuring software orchestration)

[Robert Collins]

On 1 October 2013 19:31, Clint Byrum  wrote:
> TripleO meets at 2000 UTC every Tuesday.

1900UTC.

:)

-Rob
-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] Gate issues - what you can do to help

[Alan Pevec]

>> 1) Please *do not* Approve or Reverify stable/* patches. The pyparsing
>> requirements conflict with neutron client from earlier in the week is still
>> not resolved on stable/*.
>
> Also there's an issue with quantumclient and Nova stable/grizzly:
> https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/34/console
> ...nova/network/security_group/quantum_driver.py", line 101, in get
>  id = quantumv20.find_resourceid_by_name_or_id(
> AttributeError: 'module' object has no attribute 
> 'find_resourceid_by_name_or_id'

That should be fixed by https://review.openstack.org/49006 + new
quantumclient release, thanks Matt!

Adam, Thierry - given that stable/grizzly is still blocked by this, I
suppose we should delay 2013.1.4 freeze (was planned this Thursday)
until stable/grizzly is back in shape?


Cheers,
Alan

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

Re: [openstack-dev] [Spam] Heat stack-create fails in TripleO devtest environment

[hideyasu hayashi]

Thank you for your answer Clint.

I try to debug .and,  I set up TripleO by real hadware to use.


2013/10/1 Clint Byrum 

> Excerpts from hideyasu hayashi's message of 2013-09-30 18:29:24 -0700:
> > Dear List,
> >
> >
> >
> >  Hi, I set up TripleO devtest environment on VMware(Ubuntu 12.04.3 LTS)
> > according to devtest described in
> > http://docs.openstack.org/developer/tripleo-incubator/devtest.html
> >
> >
> >
> >  There are 50 steps. I set up following the procedures, but it fails.
> >
> >  Does anyone know how to debug?
> >
> >  If anyone was successful, tell me your enviroment.(OS..)
> >
> >
> >
> >  (TripleO devtest URL)
> >
> >  http://docs.openstack.org/developer/tripleo-incubator/devtest.html
> >
> >
> >
> >   (Failed detail)
> >
> >
> >
> >  We are failed in step 27th, that create UnderCloud Stack with Heat.
> >
> >
> >
> >  --27. Deploy an undercloud: -
> >
> >   heat stack-create -f
> > $TRIPLEO_ROOT/tripleo-heat-templates/undercloud-vm.yaml \
> >
> > -P
> >
> "PowerUserName=$(whoami);AdminToken=${UNDERCLOUD_ADMIN_TOKEN};AdminPassword=${UNDERCLOUD_ADMIN_PASSWORD};GlancePassword=${UNDERCLOUD_GLANCE_PASSWORD};HeatPassword=${UNDERCLOUD_HEAT_PASSWORD};NeutronPassword=${UNDERCLOUD_NEUTRON_PASSWORD};NovaPassword=${UNDERCLOUD_NOVA_PASSWORD};BaremetalArch=${NODE_ARCH}"
> > \
> >
> > undercloud
> >
> >  
> >
> >
> >
> >  I had run the command "heat stack-create -f $TRIPLEO_ROOT/tripleo..",but
> >  stack_staus result an  failed.
> >
> >
> >
> >    heat creat result 
> >
> >   root@ubuntu:~/tripleo# heat stack-list
> >
> >
> >
> +--+-+---+--+
> >
> >   | id   | stack_name  | stack_status  |
> > creation_time|
> >
> >
> >
> +--+-+---+--+
> >
> >   | c28d0e20-9270-4716-9b0c-ce7b80c96dab | undercloud  | CREATE_FAILED |
> > 2013-09-25T09:24:37Z |
> >
> >
> >
> +--+-+---+--+
> >
>
> Hello Hideyasu, thanks for trying out TripleO!
>
> The usual cause of a failure at this point is failing SSH from seed VM
> to host.
>
> Commands to debug:
>
> ## show the list of events and the specific resource that failed.
> heat event-list undercloud
>
> ## show the error message that caused the failure
> heat event-show undercloud resource_name event_id
>
> Now, most likely, you have an error on the creation of the "notcompute"
> resource. If so, you will have a server in ERROR state here:
>
> ## list my servers
> nova list
>
> If so, try
>
> # Show details about the server
> nova show server_id
>
> This may or may not be helpful, as many problems boil down to "I couldn't
> find a host to deploy to".
>
> You can look on the seed VM for clues in
> /var/log/upstart/nova-compute.log.
>
> It takes 60 seconds to see the registered baremetal nodes in the nova
> scheduler, so just deleting the stack and trying again can work. This is
> likely since you are running a nested VM, so timeouts are common because
> everything takes a _lot_ longer on nested vms. I highly recommend getting
> real hardware to use if you can.
>
> ## delete stack
> heat stack-delete undercloud
>
> I hope all of this helps.
>
> ___
> 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] [heat] [scheduler] Bringing things together for Icehouse (now featuring software orchestration)

[Sylvain Bauza]

Hi Mike and Zane,

Le 27/09/2013 15:58, Mike Spreitzer a écrit :

Zane Bitter  wrote on 09/27/2013 08:24:49 AM:

> Your diagrams clearly show scheduling happening in a separate stage to
> (infrastructure) orchestration, which is to say that at the point where
> resources are scheduled, their actual creation is in the *future*.
>
> I am not a Climate expert, but it seems to me that they have a
> near-identical problem to solve: how do they integrate with Heat such
> that somebody who has reserved resources in the past can actually 
create

> them (a) as part of a Heat stack or (b) as standalone resources, at the
> user's option. IMO OpenStack should solve this problem only once.

If I understand correctly, what Climate adds to the party is planning 
allocations to happen at some specific time in the non-immediate 
future.  A holistic infrastructure scheduler is planning allocations 
to happen just as soon as we can get the plans through the relevant 
code path, which is why I describe it as "now".




Climate is wide-scoped aiming to exclusively reserve any kind of 
resources by a certain time. This generic sentence doesn't mean Climate 
can't schedule things 'now': you can ask for an immediate lease 
(starting 'now') and youwill get the resources as of now.


Climate team is actually split into two different teams, one focusing on 
hardware procurement and one focusing of virtual procurement. I can't 
speak on behalf of the 'Climate Virtual' team, but I would bet 
scheduling an Heat stack or aSavanna cluster will require some kind of 
holistic DSL, indeed.


From the 'Climate Physical' POV, that could even be necessary, 

butyetunclear at the moment.

-Sylvain



> If I understood your remarks correctly, we agree that there is no
> (known) reason that the scheduling has to occur in the middle of
> orchestration (which would have implied that it needed to be
> incorporated in some sense into Heat).

If you agree that by orchestration you meant specifically 
infrastructure orchestration then we are agreed.  If software 
orchestration is also in the picture then I also agree that holistic 
infrastructure scheduling does not *have to* go in between software 
orchestration and infrastructure orchestration --- but I think that's 
a pretty good place for it.



> Right, so what I'm saying is that if all those things are _stated_ in
> the input then there's no need to run the orchestration engine to find
> out what they'll be; they're already stated.

Yep.

Thanks,
Mike


___
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] [Keystone] Client Auth Plugins and changes in how clients communicate.

[Jamie Lennox]

All, 

So I wrote out an article the other day on the background to the keystoneclient 
changes that I've been trying to get through. 

Please take a look: 
http://www.jamielennox.net/blog/2013/09/27/apiclient-communications/ 

I'm hoping that it gives a better understanding of the concepts and the bigger 
picture of the changes I'm trying to get through for keystoneclient and if we 
can generate some discussion on this then hopefully we can get some momentum on 
the issue before summit. 

Have a look, I'll be at the meeting tomorrow and can answer anything that is 
still ambiguous or any disagreements. 
Now that rc1 is locked up, I'm hoping to get some eyes on this stuff.


Thanks,
Jamie 

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

Re: [openstack-dev] Gate issues - what you can do to help

[Alan Pevec]

Hi Gary,

2013/9/29 Gary Kotton :
> Not related to the stable branches, but related to trunk. At the moment I am
> working on https://review.openstack.org/#/c/47788/. This patch adds a
> timeout to the access to the OVS database.

There are ovs-vsctl calls on stable/grizzly too, shouldn't this be backported?

Cheers,
Alan

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

Re: [openstack-dev] [heat] [scheduler] Bringing things together for Icehouse (now featuring software orchestration)

[Thomas Spatzier]

Clint Byrum  wrote on 01.10.2013 08:31:44 - Excerpt:

> From: Clint Byrum 
> To: openstack-dev ,
> Date: 01.10.2013 08:33
> Subject: Re: [openstack-dev] [heat] [scheduler] Bringing things
> together for Icehouse (now featuring software orchestration)
>
> Excerpts from Georgy Okrokvertskhov's message of 2013-09-30 11:44:26
-0700:
> > Hi,
> >
> > I am working on the OpenStack project Murano which actually had to
solve
> > the same problem with software level orchestration. Right now Murano
has a
> > DSL language which allows you to define a workflow for a complex
service
> > deployment.
> > ...
> >
>
> Hi!
>
> We've written some very basic tools to do server configuration for the
> OpenStack on OpenStack (TripleO) Deployment program. Hopefully we can
> avert you having to do any duplicate work and join forces.
>
> Note that configuring software and servers is not one job. The tools we
> have right now:
>
> os-collect-config - agent to collect data from config sources and trigger
> commands on changes. [1]
>
> os-refresh-config - run scripts to manage state during config changes
> (run-parts but more structured) [2]
>
> os-apply-config - write config files [3]
>
> [1] http://pypi.python.org/pypi/os-collect-config
> [2] http://pypi.python.org/pypi/os-refresh-config
> [3] http://pypi.python.org/pypi/os-apply-config
>
> We do not have a tool to do run-time software installation, because we
> are working on an image based deployment method (thus building images
> with diskimage-builder).  IMO, there are so many good tools already
> written that get this job done, doing one just for the sake of it being
> OpenStack native is a low priority.
>
> However, a minimal thing is needed for Heat users so they can use it to
> install those better tools for ongoing run-time configuration. cfn-init
> is actually pretty good. Its only crime other than being born of Amazon
> is that it also does a few other jobs, namely file writing and service
> management.

Right, there has been some discussion going on to find the right level of
software orchestration to go into Heat. As Clint said, there are a couple
of things out there already, like what the tripleO project has been doing.
And there are proposals / discussions going on to see who users could
include some level of software orchestration into HOT, e.g.

https://wiki.openstack.org/wiki/Heat/Software-Configuration-Provider

and how such constructs in HOT would align with assets already out there.
So Georgy's item is another one in that direction and it would be good to
find some common denominator.

>
> Anyway, before you run off and write an agent, I hope you will take a
look
> at os-collect-config and considering using it. For the command to run, I
> recommend os-refresh-config as you can have it run a progression of
config
> tools. For what to run in the configuration step of os-refresh-config,
> cfn-init would work, however there is a blueprint for a native interface
> that might be a bit different here:
>
> https://blueprints.launchpad.net/heat/+spec/native-tools-bootstrap-config
>
> > When do you have a meeting for HOT software configuration discussion? I
> > think we can add value here for Heat as we have already required
components
> > for software orchestration with full integration with OpenStack and
> > Keystone in particular.
>
> Heat meets at 2000 UTC every Wednesday.
>
> TripleO meets at 2000 UTC every Tuesday.
>
> Hope to see you there!

In addition, it looks like there will be some design sessions on that topic
at the HK summit, so if you happen to be there that could be another good
chance to talk.

>
> ___
> 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] Waiting for someone to verify/look into a bug I have opened for Glance Client tool

[GROSZ, Maty (Maty)]

All, you can view the bug here:

https://bugs.launchpad.net/glance/+bug/1222369

Thanks,

Maty.

-Original Message-
From: Iccha Sethi [mailto:iccha.se...@rackspace.com] 
Sent: Monday, September 30, 2013 17:51
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Waiting for someone to verify/look into a bug I 
have opened for Glance Client tool

Maty,

Can you link the launchpad bug? I have used image-list for glance v2 and it 
seemed to work fine for me. Maybe you could provide more details? 
Also maybe we should continue this discussion on openstack mailing list than 
the dev list?

Thanks,
Iccha

-Original Message-
From: "GROSZ, Maty (Maty)" 
Sent: Monday, September 30, 2013 9:40am
To: "OpenStack Development Mailing List" 
Subject: [openstack-dev] Waiting for someone to verify/look into a bug I have 
opened for Glance Client tool

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

I have opened a bug for Glance Client tool some weeks ago (at September 8th) - 
and I still didn't receive any comment on it. Is it right? Am I wrong? 
Anything...
I will really appreciate if someone from the Glance client tool will have a 
look on the bug (see below).

Thanks,

Maty.

>From launchpad:

Hi,

When I am running Glance Client tool against glance service using the following 
command:

> glance --debug --os-image-api-version 2 image-list

I get the followng output:

curl -i -X GET -H 'X-Auth-Token: 
rO0ABXc4ACAyYzlkYTk4ZDQwZGVmNWU2MDE0MGZjZDI0OThiMzk3MQAGbWdyb3N6AAQzMDQ3AAABQP0JOAs'
 -H 'Content-Type: application/json' -H 'User-Agent: python-glanceclient' -k 
https://cb.alucloud.local/al-openstack/v2/schemas/image
(9, 'Bad file descriptor')



*BUT* when I am running just the exact curl command you see in the debug log

> curl -i -X GET -H 'X-Auth-Token: 
> rO0ABXc4ACAyYzlkYTk4ZDQwZGVmNWU2MDE0MGZjZDI0OThiMzk3MQAGbWdyb3N6AAQzMDQ3AAABQP0JOAs'
>  -H 'Content-Type: application/json' -H 'User-Agent: python-glanceclient' -k 
> https://cb.alucloud.local/al-openstack/v2/schemas/image

I get what am I expecting to get - the JSON schema:

HTTP/1.1 200 OK
Date: Sun, 08 Sep 2013 09:51:04 GMT
Content-Type: application/json
Content-Length: 4958
Connection: close

{"type":"object","properties":{"id":{"type":"string"},"name":{"type":"string"},"visibility":{"type":"string","enum":["public","private"]},"file":{"type":"string"},"status":{"type":"string"},"minDisk":{"type":"integer"},"minRam":{"type":"integer"},"progress":{"type":"integer"},"userId":{"type":"string"},"metadata":{"type":"object"},"self":{"type":"string"},"size":{"type":"number"},"schema":{"type":"string"},"checksum":{"type":"string"},"customerId":{"type":"string"},"updated_at":{"type":"string"},"created_at":{"type":"string"},"container_format":{"type":"string","enum":["ovf","bare","aki","ari","ami"]},"disk_format":{"type":"string","enum":["raw","vhd","vmdk","vdi","iso","qcow2","aki","ari","ami"]},"name":"image"}



___
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] Gate issues - what you can do to help

[Thierry Carrez]

Alan Pevec wrote:
>>> 1) Please *do not* Approve or Reverify stable/* patches. The pyparsing
>>> requirements conflict with neutron client from earlier in the week is still
>>> not resolved on stable/*.
>>
>> Also there's an issue with quantumclient and Nova stable/grizzly:
>> https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/34/console
>> ...nova/network/security_group/quantum_driver.py", line 101, in get
>>  id = quantumv20.find_resourceid_by_name_or_id(
>> AttributeError: 'module' object has no attribute 
>> 'find_resourceid_by_name_or_id'
> 
> That should be fixed by https://review.openstack.org/49006 + new
> quantumclient release, thanks Matt!
> 
> Adam, Thierry - given that stable/grizzly is still blocked by this, I
> suppose we should delay 2013.1.4 freeze (was planned this Thursday)
> until stable/grizzly is back in shape?

Given the gate slowness these days, RC1 being late and the advice not to
approve too much stable/* stuff, I think it makes sense to defer for at
least a week. Adam ?

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [TripleO] Kicking TripleO up a notch

[Robert Collins]

Warning, this is a little long, but it's the distillation of a
2.mumble hour call I had late last week with Devananda and Clint. It's
a proposal: please do comment and critique it.

The tl;dr read is:
 - we've been doing good work
 - but most of us are currently focused on the tech rather than the
customer stories
 - lets fix that
 - Start with customer story and work back to minimum work needed
   - and we can actually be *delivering* that story [we have hardware
for it, thanks to HP]
 - Focus on efficiency and reducing firefighting before new features
 - https://trello.com/tripleo as an experimental kanban for this [1]

Now for a less condensed, and hopefully more useful version :)

The night before the call I finished reading
http://www.amazon.com/The-Phoenix-Project-Business-ebook/dp/B00AZRBLHO/ref=sr_1_9?s=digital-text&ie=UTF8&qid=1380182909&sr=1-9&keywords=the+goal
which is a devops casting of 'The Goal', a seminal work in the LEAN
manufacturing space. (It's terrible writing in a lot of ways, but it
also does do a pretty good job IMO of highlighting the
systems-thinking aspects of CD... but it doesn't drill into the
detailed analysis of each aspect so some followup reading required to
get chapter and verse on e.g. 'single item flow is ideal').

It reminded me very strongly of things I used to hold as very
important, but I've been sidetracked into playing with the tech -
which I love - and not focusing on ... 'The goal'. I grabbed Clint,
and Deva, and tried to grab Joe - to get a cross section of focus
areas : Heat, Ironic/NovaBM/Nova - to sanity check what was in my head
:).

Our goal is to deliver a continuously deployed version of OpenStack.
Right now, we're working on plumbing to build a /good/ version of
that. Note the difference: 'deliver an X', 'building stuff to let us
deliver a good X'.

This is key: we've managed to end up focusing on bottom-up work,
rather than optimising our ability to deliver the thing, and
iteratively improving it. The former is necessary but not sufficient.
Tuskar has been working top down, and (as usual) this results in very
fast progress; the rest of TripleO has provided a really solid
foundation, but with many gaps and super rough spots...

So, I'd like to invert our priorities and start with the deliverable,
however slipshod, and then iterate to make it better and better along
the design paths we've already thought about. This could extend all
the way to Tuskar, or we could start with the closest thing within
reach, which is the existing 'no-state-for-tripleo' style CLI + API
based tooling.

In the call we had, we agreed that this approach makes a lot of sense,
and spent a bunch of time talking through the ramifications on TripleO
and Ironic, and sketched out one way to slice and dice things;
https://docs.google.com/drawings/d/1kgBlHvkW8Kj_ynCA5oCILg4sPqCUvmlytY5p1p9AjW0/edit?usp=sharing
is the diagram we came up with.

The basic approach is to actually deliver the thing we want to deliver
- a live working CD overcloud *ourselves* and iterate on that to make
upgrades of that preserve state, then start tackling CD of it's
infrastructure, then remove the seed.

Ramifications:
 - long term a much better project health and responsiveness to
changing user needs.
 - may cause disruption in the short term as we do whats needed to get
/something/ working.
 - will need community buy-in and support to make it work : two of the
key things about working Lean are keeping WIP - inventory - low and
ensuring that bottlenecks are not used for anything other than
bottleneck tasks. Both of these things impact what can be done at any
point in time within the project: we may need to say 'no' to proposed
work to permit driving more momentum as a whole... at least in the
short term.
 - highlights that we'll need much better communication about what
work is suitable to tackle now vs what work is a distraction at this
point
   - Which implies much more work from someone in the group on
surfacing work to do and where it's blocked. {I'll happily take this
bullet, for now, for TripleO}
 - May need more hardware :)
 - We'll need to change how we pick work to work on, how we decide
whether to accept new work or not, and how we prioritise things.

Basic principles:
 - unblock bottlenecks first, then unblock everyone else.
 - folk are still self directed - it's open source - but clear
visibility of work needed and it's relevance to the product *right
now* is crucial info for people to make good choices. (and similar
Mark McLoughlin was asking about what bugs to work on which is a
symptom of me/us failing to provide clear visibility)
 - clear communication about TripleO and plans / strategy and priority
(Datacentre ops? Continuous deployment story?)

Earlier this year, within HP, we setup a rack using TripleO of the
time, for a customer, and the experience was fantastic: we made much
more forward progress towards whats needed than we had in the month or
two leading up to it... but then we went back

Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver

[Daniel P. Berrange]

On Mon, Sep 30, 2013 at 02:25:30PM -0700, Ravi Chunduru wrote:
> Alessandro,
>  I agree with you. I created a Blueprint. Let us collaborate and achieve
> this on all types of hypervisors.
> 
> All,
> 
> Here is the link for the BP as discussed.
> https://blueprints.launchpad.net/nova/+spec/appliance-communication-channel

That needs to be expanded to describe more about the intended usage
of the setup, and consider any security issues. IMHO we really do
not want this exposed to end users - particularly not whuen you are
proposing the ability to set arbitrary file paths for the UNIX
sockets against images. That woudl be a security flaw as proposed
in that doc.


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-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-docs] [Docs] Documentation PTL Candidacy

[atul jha]

+1




On Mon, Sep 23, 2013 at 7:38 PM, Emilien Macchi  wrote:

>  +1
>
> Anne is doing without any doubt an amazing job on OpenStack manuals.
>
> Thank you Anne,
>
> Emilien Macchi
> 
> # OpenStack Engineer
> // eNovance Inc.  http://enovance.com
> // ✉ emil...@enovance.com ☎ +33 (0)1 49 70 99 80
> // 10 rue de la Victoire 75009 Paris
>
> On 09/22/2013 08:19 PM, Anne Gentle wrote:
>
> Hi all,
> I'm writing to declare my intention to run for OpenStack documentation
> program technical lead. [1]
>
>  I've been working on OpenStack docs since September 2010, and it has
> been an honor and a privilege to serve in this position informally prior to
> having documentation declared a program. I've been serving as the interim
> PTL as encouraged by my doc peers.
>
>  In Havana we've been hard at work (and continue to do so), refactoring
> the openstack-manuals repo to ensure installation, configuration, and
> administration info is as complete and accurate as we can, including the
> addition of automation tools for gathering configuration options into one
> location.
>
>  We've added an End User Guide, an Admin User Guide, and a Cloud
> Administration Guide to document OpenStack as a whole, including all the
> clients and the things you can do with your OpenStack clouds through
> command-line calls.
>
>  We also work on API documentation to bring you a compete reference
> listing of all OpenStack APIs including example requests and responses.
>
>  In the last year we've held two successful book sprints in the past year
> resulting in the OpenStack Operations Guide and the OpenStack Security
> Guide. We're actively recruiting writers for a book sprint to write an
> OpenStack Architecture Design Guide. The Operations Guide has been
> translated to Chinese and Japanese.
>
>  I believe the documentation PTL role is one of coordination, coaching,
> and providing platforms for documentation. This doesn't happen in isolation
> and requires constant attention and coordination. I do know our
> shortcomings and continue to work through the difficulties we face trying
> to document a fast-moving integrated set of projects. In the future I'd
> like to recruit more upstream OpenStack writers and have designated project
> doc leads.
>
>  I continue to be the top committer to the openstack-manuals repo [2] and
> I am an active reviewer of all docs repos. [3]
>
>  I'm proud of the work we've done so far and would be privileged to
> continue this most challenging work.
> Thanks,
> Anne
>
>  1. Wow, that sounds too formal, but that's what this email is.
> 2. https://github.com/openstack/openstack-manuals/graphs/contributors
> 3. https://review.openstack.org/#/q/reviewer:anne%2540openstack.org,n,z
>
>
>
> ___
> Openstack-docs mailing 
> listOpenstack-docs@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 


Atul Jha
http://atuljha.com
(irc.freenode.net:koolhead17)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Reminder: Project & release status meeting - 21:00 UTC

[Thierry Carrez]

Today in the project/release status meeting, we expect a busy meeting as
we examine the last blockers before RC1. That includes looking into the
gate flaky tests that have been pleguing our velocity lately. In order
to issue the RC1s in the near future, we may have to restrict gating to
RC1-critical issues only, so that will be discussed as well.

Feel free to add extra topics to the agenda:
[1] http://wiki.openstack.org/Meetings/ProjectMeeting

All Technical Leads for integrated programs should be present (if you
can't make it, please name a substitute on [1]). Other program leads and
everyone else is very welcome to attend.

The meeting will be held at 21:00 UTC on the #openstack-meeting channel
on Freenode IRC. You can look up how this time translates locally at:
[2] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20131001T21

See you there,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [TripleO] Kicking TripleO up a notch

[Robert Collins]

On 1 October 2013 21:37, Robert Collins  wrote:

>  - https://trello.com/tripleo as an experimental kanban for this [1]

This was private; sorry - fixed!

Also, I forgot to include a link to
https://wiki.openstack.org/wiki/TripleO/TripleOCloud which is draft
documentation about this proposed cloud.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [Openstack-docs] [Docs] Documentation PTL Candidacy

[Vivek Varghese Cherian]

Hi,

Anne Gentle has been working consistently with me and my team from the time
we released the OpenStack Beginner's
Guide Diablo and Essex releases. Her work with Openstack manual project is
well known through out the community.

I am supporting Anne Gentle's candidature for OpenStack documentation
program technical lead.

Regards,
-- 
Vivek Varghese Cherian (विवेक वर्गीस चेरियान)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Gate issues - what you can do to help

[Gary Kotton]

Yes, it should. I'll mark the bug as a stable backport
Thanks

On 10/1/13 10:51 AM, "Alan Pevec"  wrote:

>Hi Gary,
>
>2013/9/29 Gary Kotton :
>> Not related to the stable branches, but related to trunk. At the moment
>>I am
>> working on https://review.openstack.org/#/c/47788/. This patch adds a
>> timeout to the access to the OVS database.
>
>There are ovs-vsctl calls on stable/grizzly too, shouldn't this be
>backported?
>
>Cheers,
>Alan


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

[openstack-dev] trove is already a source package in Debian and a Python module in PyPi

[Thomas Goirand]

Hi,

I have just found out that there's already a source package called
"trove" in Debian:

http://packages.debian.org/source/sid/trove

Lucky, I don't think it will clash with OpenStack trove since it
produces libtrove-java* .deb files, though that's quite annoying. The
source package for OpenStack Trove will have to be called something like
openstack-trove, which isn't nice.

Also, in PyPi, there is:
https://pypi.python.org/pypi/TroveClient

which would clash with python-troveclient. This pypi module was uploaded
more than a year ago. Since I have already uploaded python-troveclient
(currently waiting in the FTP master's NEW queue), OpenStack troveclient
will be in Sid, but if some day, someone wants to upload TroveClient
from http://dev.yourtrove.com, then we have a problem.

So, I am really questioning the choice of "Trove" as a name for the
DBaaS in OpenStack. I think it is a pretty bad move. :(

Is it too late to fix this?

Cheers,

Thomas Goirand (zigo)

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

Re: [openstack-dev] [nova] [scheduler] blueprint for host/hypervisor location information

[Mike Spreitzer]

Maybe the answer is hiding in plain sight: host aggregates.  This is a 
concept we already have, and it allows identification of arbitrary 
groupings for arbitrary purposes.___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [scheduler] [heat] Policy specifics (for holistic infrastructure scheduling)

[Mike Spreitzer]

Clint Byrum  wrote on 10/01/2013 02:38:53 AM:

> From: Clint Byrum 
> To: openstack-dev , 
> Date: 10/01/2013 02:40 AM
> Subject: Re: [openstack-dev] [scheduler] [heat] Policy specifics 
> (for holistic infrastructure scheduling)
> 
> Mike, this has been really fun, but it is starting to feel like a
> rabbit hole.
> 
> The case for having one feels legitimate. However, at this point, I 
think
> someone will need to actually build it, or the idea is just a pipe 
dream.

Yes, Clint, I and colleagues are interested in building it.  I think Debo 
and Yathi are too.  And we are finding intersections with other projects. 
I am still new here and learning lots, so outputs have not come as fast as 
I had initially hoped.  But I appreciate being able to have discussions 
and draw on the wisdom of the group.

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

Re: [openstack-dev] [Nova][Keystone][glance] Keystone V3 Domains and Nova

[Dolph Mathews]

On Tue, Oct 1, 2013 at 1:17 AM, Henry Nash wrote:

> I think an obvious first step of domain support outside keystone is for
> images.  Today, I believe, an image can be global or project based.  There
> is definitely a use case for a third state of being domain based - and
> hence available to all projects in that domain, but not to those in other
> domains.
>

> From a Nova perspective, where domains might be relevant is in how a cloud
> provider divides up their infrastructure, for example, I think there are
> use cases for when a cloud provider might want to specify on a domain-basis:
> - availability zones and/or host aggregates
> - quotas
>

/me facepalm

I can't believe I forgot about these. I take back the "yet to hear"!


> - IP ranges (ok, maybe a quantum discussion)
>
> Henry
> On 1 Oct 2013, at 06:45, Dolph Mathews  wrote:
>
>
> On Mon, Sep 30, 2013 at 11:42 PM, Christopher Yeoh wrote:
>
>> Hi,
>>
>> I've been looking into how Nova might support Keystone V3 domains and I'm
>> having a bit of trouble getting my head around exactly how we'd use domain
>> scoped tokens.
>>
>> With the V3 Nova API we no longer specify the tenant id in the url as it
>> is implicit in the token used to authorize with. This is true for Keystone
>> V3  tenant scoped tokens, but not for domain scoped tokens.  If we're going
>> to use domain scoped tokens with the Nova API is the idea that a client
>> would pass the tenant id in a header as well as the domain scoped token and
>> Nova would check that the tenant passed belongs to the domain that is
>> implicit with the token?
>>
>
> Without a specific use case to support domain-based operations, I'd be
> opposed to handling this scenario "implicitly." I have yet to hear a use
> case for domain awareness in nova, so I'd expect nova to return a 401 for
> any domain-based token.
>
>
>>
>> Also, should we be updating the Nova policy code to be able to handle
>> domains?
>>
>
> Keystone supports domain-based authorization on two levels:
> domain-specific role assignments and domain-specific role assignments that
> are inherited to all projects/tenants owned by that domain.
>
> With inheritance, a domain administrator can request authorization on any
> project in the domain (from keystone, per usual) and nova's policy doesn't
> have to handle anything special (it'll just be a regular project/tenant
> scoped token).
>
>
>>
>>
>
>> Regards,
>>
>> Chris
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> -Dolph
> ___
> 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
>
>


-- 

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

[openstack-dev] Scheduler sub-group meeting on 10/1

[Gary Kotton]

Hi,
Don is on vacation. Lets try and have the meeting today.
Topics that come to mind:

 1.  Consolidating ideas regarding scheduling API's that we can propose for 
summit – it would be great if we could come with a crystalized proposal for the 
community
 2.  On the mail list there has been a lot of discussion about heat and 
scheduling. Is this something we need to deal with? Should we be working on a 
combined session for summit?

So hopefully we are scheduled for the end of the hour :)

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

Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi

[Michael Basnight]

On Oct 1, 2013, at 6:45 AM, Thomas Goirand wrote:

> Hi,
> 
> I have just found out that there's already a source package called
> "trove" in Debian:
> 
> http://packages.debian.org/source/sid/trove
> 
> Lucky, I don't think it will clash with OpenStack trove since it
> produces libtrove-java* .deb files, though that's quite annoying. The
> source package for OpenStack Trove will have to be called something like
> openstack-trove, which isn't nice.
> 
> Also, in PyPi, there is:
> https://pypi.python.org/pypi/TroveClient
> 
> which would clash with python-troveclient. This pypi module was uploaded
> more than a year ago. Since I have already uploaded python-troveclient
> (currently waiting in the FTP master's NEW queue), OpenStack troveclient
> will be in Sid, but if some day, someone wants to upload TroveClient
> from http://dev.yourtrove.com, then we have a problem.
> 
> So, I am really questioning the choice of "Trove" as a name for the
> DBaaS in OpenStack. I think it is a pretty bad move. :(
> 
> Is it too late to fix this?

Well this sucks. Im not sure im a fan of renaming it because of the previous 
existence of a package. Renaming is not fun. Ill let the more experienced 
openstack peoples help decide on this...



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Nova Migrate/Resize Libvirt Methods

[Lingxian Kong]

Good idea, I'm very interested in that!


2013/10/1 Vishvananda Ishaya 

>
> On Sep 30, 2013, at 1:12 AM, Daniel P. Berrange 
> wrote:
>
> > On Fri, Sep 27, 2013 at 02:11:36PM -0400, Solly Ross wrote:
> >> Hello Fellow OpenStackers,
> >>
> >> I was working on a bug (
> https://bugzilla.redhat.com/show_bug.cgi?id=975014)
> >> involving the Nova resize functionality in the libvirt driver.  So, it
> >> turns out that the bug is caused by nova code trying to ssh directly
> >> into another compute node.  Since it was not authorized to do so, the
> >> command failed.
> >>
> >> So, my question is this: should nova really be SSHing directly into a
> >> peer machine to create a directory?  Doesn't that kind of defeat the
> >> purpose of the centralized RPC mechanism?  However, if this is the
> >> intended functionality, should Packstack be smarter about setting up
> >> permissions (this was a packstack install) when there are two or more
> >> compute nodes listed?
> >
> > Yes, I think that it is really pretty bogus design to use ssh in this way
> > in Nova & this should be fixed to not use ssh.
> >
> > Daniel
>
> Agreed. I think the simplest implementation would be to upload a temporary
> snapshot to glance that can be deleted after the resize/migrate is
> confirmed.
>
> Vish
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
**
*Lingxian Kong*
Huawei Technologies Co.,LTD.
IT Product Line CloudOS PDU
China, Xi'an
Mobile: +86-18602962792
Email: konglingx...@huawei.com; anlin.k...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi

[Nicholas Chase]

On 10/1/2013 10:53 AM, Michael Basnight wrote:


Well this sucks. Im not sure im a fan of renaming it because of the previous 
existence of a package. Renaming is not fun. Ill let the more experienced 
openstack peoples help decide on this...


Certainly it's not fun, but wouldn't it be easier to do it NOW, rather 
than later?


  Nick

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

Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi

[Michael Basnight]

On Oct 1, 2013, at 8:00 AM, Nicholas Chase wrote:

> 
> 
> On 10/1/2013 10:53 AM, Michael Basnight wrote:
> 
>> Well this sucks. Im not sure im a fan of renaming it because of the previous 
>> existence of a package. Renaming is not fun. Ill let the more experienced 
>> openstack peoples help decide on this...
> 
> Certainly it's not fun, but wouldn't it be easier to do it NOW, rather than 
> later?

Hah, well, it begs the question, why are we _not_ namespacing all openstack 
packages. If you look @ the rpms, they are all namespaced [1]. IMHO, i wouldnt 
mind seeing openstack-blah packages. And let me reiterate, im not sure changing 
our name _again_ is the way to go because of a conflicting debian package. This 
wont be a problem for the rpms, because they are namespaced (openstack-trove).

[1] https://admin.fedoraproject.org/pkgdb/acls/name/openstack-nova


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack][neutron] Handling issues unlikely to happen with the current code

[Cristian Tomoiaga]

Hello,

I am wondering if we should handle potential issues (unlikely to happen
with the current code) now or wait to see what happens with the code in the
future ?
What I am referring to can be seen for example
in neutron/db/db_base_plugin_v2.py in _recycle_ip if we try to recycle the
same IP twice.
Looking at where and how the _recycle_ip function is called, it's unlikely
that the same IP will be recycled twice, but if that happens, two
allocation pools will be created containing the same IP address leading to
all sorts of issues afterwards.
There is no check to see if the IP already exists as a single entry in the
allocation pools table.
An extra db query should be created to avoid this.
The IP handling code will change in the future but I am guessing the same
function will continue to exist.
Waiting for some feedback on this, thank you!

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

Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi

[Thomas Goirand]

On 10/01/2013 10:02 PM, Jonathan Dowland wrote:
> On Tue, Oct 01, 2013 at 09:45:17PM +0800, Thomas Goirand wrote:
>> Since I have already uploaded python-troveclient (currently waiting in
>> the FTP master's NEW queue), OpenStack troveclient will be in Sid, but
>> if some day, someone wants to upload TroveClient from
>> http://dev.yourtrove.com, then we have a problem.
> …
>> Is it too late to fix this?
> 
> Ask ftp masters to reject the package and re-upload with the source
> package renamed to have an openstack prefix/suffix/infix.

Thanks but no thanks. I need to have the python namespace (eg, the
egg-info and such) to match the package name, otherwise there will be no
correct automatic ${python:Depends} substitution.

FYI, the message was more addressed to the OpenStack community, rather
than -devel...

On 10/01/2013 10:53 PM, Michael Basnight wrote:
> Well this sucks.

Indeed!

> Im not sure im a fan of renaming it because of the
> previous existence of a package.

Well, I wonder how the Trove name was chosen. Clearly, it was done
without any good policy in place.

> Renaming is not fun.

It sure isn't. Quantum -> Neutron was hell for everyone. Though luckily,
Trove isn't that big (yet).

> Ill let the more experienced openstack peoples help decide on this...

Same over here. Though for this not to happen again, I think the
OpenStack projects needs to set some rules for project name choice.

Thomas


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

[openstack-dev] [TROVE] Thoughts on DNS refactoring, Designate integration.

[Tim Simpson]

Hi fellow Trove devs,

With the Designate project ramping up, its time to refactor the ancient DNS 
code that's in Trove to work with Designate.

The good news is since the beginning, it has been possible to add new drivers 
for DNS in order to use different services. Right now we only have a driver for 
the Rackspace DNS API, but it should be possible to write one for Designate as 
well.

However, there's a bigger topic here. In a gist sent to me recently by Dennis 
M. with his thoughts on how this work should proceed, he included the comment 
that Trove should *only* support Designate: 
https://gist.github.com/crazymac/6705456/raw/2a16c7a249e73b3e42d98f5319db167f8d09abe0/gistfile1.txt

I disagree. I have been waiting for a canonical DNS solution such as Designate 
to enter the Openstack umbrella for years now, and am looking forward to having 
Trove consume it. However, changing all the code so that nothing else works is 
premature.

Instead, let's start work to play well with Designate now, using the open 
interface that has always existed. In the future after Designate enters 
integration status we can then make the code closed and only support Designate.

Denis also had some other comments about the DNS code, such as not passing a 
single object as a parameter because it could be None. I think this is in 
reference to passing around a DNS entry which gets formed by the DNS instance 
entry factory. I see how someone might think this is brittle, but in actuality 
it has worked for several years so if anything changing it would introduce 
bugs. The interface was also written to use a full object in order to be 
flexible; a full object should make it easier to work with different types of 
DnsDriver implementations, as well as allowing more options to be set from the 
DnsInstanceEntryFactory. This later class creates a DnsEntry from an 
instance_id. It is possible that two deployments of Trove, even if they are 
using Designate, might opt for different DnsInstanceEntryFactory 
implementations in order to give the DNS entries associated to databases 
different patterns. If the DNS entry is created at this point its easier to 
further customize and tailor it. This will hold true even when Designate is 
ready to become the only DNS option we support (if such a thing is desirable).

Thanks,

Tim



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

Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi

[Monty Taylor]

On 10/01/2013 11:45 AM, Thomas Goirand wrote:
> On 10/01/2013 10:02 PM, Jonathan Dowland wrote:
>> On Tue, Oct 01, 2013 at 09:45:17PM +0800, Thomas Goirand wrote:
>>> Since I have already uploaded python-troveclient (currently waiting in
>>> the FTP master's NEW queue), OpenStack troveclient will be in Sid, but
>>> if some day, someone wants to upload TroveClient from
>>> http://dev.yourtrove.com, then we have a problem.
>> …
>>> Is it too late to fix this?

I don't think it's a problem. Two reasons:

a) libtrove-java having its source package named trove is a bug. the
upstream project is called trove4j, that's what their source package
should have been called. We can't be held accountable for that.

b) We got to python-troveclient first. We win. (sorry that's rude, but
we _did_ get into the queue first. That's the reason that pip is
"python-pip" in debian, because there is a pip tool in perl. TroveClient
released last january and dev.yourtrove.com is unresponsive.

I DO agree that we need to be careful with them, and I think that a fair
list of things to check when looking for a name are:

PyPI
Launchpad
debian
fedora

We might need some follow up from fedora and debian folks about HOW
people should search for names and what things should be considered in
conflict. Remember that most of our 1200 devs do not have any idea how
debian packaging works. Those of us who _do_ need to give very short and
succinct guidelines, such as:

The package name should not conflict with source or binary package names
in Debian. You can search for those by ...

However, again, in this case I think it's fine, and I do not think we
need to rename trove beceause there happens to be a package called trove4j.

>> Ask ftp masters to reject the package and re-upload with the source
>> package renamed to have an openstack prefix/suffix/infix.
> 
> Thanks but no thanks. I need to have the python namespace (eg, the
> egg-info and such) to match the package name, otherwise there will be no
> correct automatic ${python:Depends} substitution.
> 
> FYI, the message was more addressed to the OpenStack community, rather
> than -devel...
> 
> On 10/01/2013 10:53 PM, Michael Basnight wrote:
>> Well this sucks.
> 
> Indeed!
> 
>> Im not sure im a fan of renaming it because of the
>> previous existence of a package.
> 
> Well, I wonder how the Trove name was chosen. Clearly, it was done
> without any good policy in place.
> 
>> Renaming is not fun.
> 
> It sure isn't. Quantum -> Neutron was hell for everyone. Though luckily,
> Trove isn't that big (yet).
> 
>> Ill let the more experienced openstack peoples help decide on this...
> 
> Same over here. Though for this not to happen again, I think the
> OpenStack projects needs to set some rules for project name choice.
> 
> Thomas
> 
> 
> ___
> 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] [Trove] vagrant vbox and vmware developer environment support

[Craig Vyvial]

We have vagrant working with virtual box to start up a trove development
environment. This was tested with VirtualBox on an Ubuntu machine but
should work with any other environment as well. This is nice and should
benefit the community to setup trove easily in multiple environments.

This repo maybe renamed now that it has more scope than just using vmware
fusion. In the mean time it can be found here.

https://github.com/ed-/trove-vagrant-vmware


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

Re: [openstack-dev] Gate issues - what you can do to help

[Adam Gandelman]

On 10/01/2013 12:02 AM, Alan Pevec wrote:
>>> 1) Please *do not* Approve or Reverify stable/* patches. The pyparsing
>>> requirements conflict with neutron client from earlier in the week is still
>>> not resolved on stable/*.
>> Also there's an issue with quantumclient and Nova stable/grizzly:
>> https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/34/console
>> ...nova/network/security_group/quantum_driver.py", line 101, in get
>>  id = quantumv20.find_resourceid_by_name_or_id(
>> AttributeError: 'module' object has no attribute 
>> 'find_resourceid_by_name_or_id'
> That should be fixed by https://review.openstack.org/49006 + new
> quantumclient release, thanks Matt!
>
> Adam, Thierry - given that stable/grizzly is still blocked by this, I
> suppose we should delay 2013.1.4 freeze (was planned this Thursday)
> until stable/grizzly is back in shape?
>
>
> Cheers,
> Alan
>

This sounds okay to me.  To be clear:

2013.1.4 Freeze goes into affect Oct. 10th
2013.1.4 Release Oct. 17th

- Adam


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

Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi

[Thomas Goirand]

On 10/01/2013 11:23 PM, Michael Basnight wrote:
> 
> On Oct 1, 2013, at 8:00 AM, Nicholas Chase wrote:
> 
>>
>>
>> On 10/1/2013 10:53 AM, Michael Basnight wrote:
>>
>>> Well this sucks. Im not sure im a fan of renaming it because of the 
>>> previous existence of a package. Renaming is not fun. Ill let the more 
>>> experienced openstack peoples help decide on this...
>>
>> Certainly it's not fun, but wouldn't it be easier to do it NOW, rather than 
>> later?
> 
> Hah, well, it begs the question, why are we _not_ namespacing all
> openstack packages. If you look @ the rpms, they are all namespaced [1].
> IMHO, i wouldnt mind seeing openstack-blah packages. And let me reiterate
>, im not sure changing our name _again_ is the way to go because of a
> conflicting debian package. This wont be a problem for the rpms, because
> they are namespaced (openstack-trove).
> 
> [1] https://admin.fedoraproject.org/pkgdb/acls/name/openstack-nova

Because the problem is *not* only within the Debian package naming. They
are tight together. The problem is that dh_python2 uses (IMO nicely) the
Python namespace to generate dependencies automatically. If we start
pre-fixing package names, then all sorts of tricks will have to be
added, like debian/pydist_override files and so on, so that we get the
correct python-openstack-NAME package and not python-NAME.

So if you want to prefix things, that's a very good idea, but then the
Python namespace has to also include this prefix (for example, we would
have python-openstack-troveclient as package name, and
openstack-troveclient in the Python namespace).

Thomas Goirand (zigo)


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

[openstack-dev] Requirements syncing job is live

[Monty Taylor]

Hey all!

The job to automatically propose syncs from the openstack/requirements
repo went live today - as I'm sure you all noticed, since pretty much
everyone got a patch of at least some size.

The job works the same way as the translations job - it will propose a
patch any time the global repo changes - but if there is already an
outstanding change that has not been merged, it will simply amend that
change. So there should only ever be one change per branch per project
in the topic openstack/requirements submitted by the jenkins user.

If a change comes in and you say to yourself "ZOMG, that version would
break us" - then you should definitely go and propose an update to the
global list itself, which is in the global-requirements.txt file in the
openstack/requirements repo.

The design goal, as discussed at the last two summits, is that we should
converge on alignment by the release at the very least. With this and
the changes that exist now in the gate to block non-aligned
requirements, once we get aligned, we shouldn't probably be too far out
from each other moving forward.

Additionally, the list of projects to receive updates is managed in a
file, projects.txt, in the openstack/requirements repo. If you are
running a project and would like to receive syncing patches, feel free
to add yourself to the list.

Enjoy!
Monty

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

Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi

[Thomas Goirand]

Hi,

First of all, before I reply, I'd like to tell that hopefully, I believe
we're fine in this specific case (at least on the Debian side of
things). Though it really shouldn't have happen, and I believe it's my
role to warn everybody about the risks.

On 10/02/2013 12:02 AM, Monty Taylor wrote:
> 
> 
> On 10/01/2013 11:45 AM, Thomas Goirand wrote:
>> On 10/01/2013 10:02 PM, Jonathan Dowland wrote:
>>> On Tue, Oct 01, 2013 at 09:45:17PM +0800, Thomas Goirand wrote:
 Since I have already uploaded python-troveclient (currently waiting in
 the FTP master's NEW queue), OpenStack troveclient will be in Sid, but
 if some day, someone wants to upload TroveClient from
 http://dev.yourtrove.com, then we have a problem.
>>> …
 Is it too late to fix this?
> 
> I don't think it's a problem. Two reasons:
> 
> a) libtrove-java having its source package named trove is a bug. the
> upstream project is called trove4j, that's what their source package
> should have been called. We can't be held accountable for that.

The source package name isn't a problem, it can be anything. I think I
will use openstack-trove. By the way, it's only "trove4j" because there
was "trove3" before, if I understand well (I get that doing "apt-file
search trove" on my Sid box).

> b) We got to python-troveclient first. We win. (sorry that's rude, but
> we _did_ get into the queue first. That's the reason that pip is
> "python-pip" in debian, because there is a pip tool in perl. TroveClient
> released last january and dev.yourtrove.com is unresponsive.

Yes, that might be right for the Debian package. Though at PyPi, there's
TroveClient already. Or is it that PyPi is case sensitive, and then we
don't have a problem here?

> I DO agree that we need to be careful with them, and I think that a fair
> list of things to check when looking for a name are:
> 
> PyPI
> Launchpad
> debian
> fedora

Please also add Gentoo to the list (since there is also an ongoing
effort to package OpenStack there as well).

> We might need some follow up from fedora and debian folks about HOW
> people should search for names and what things should be considered in
> conflict.

For Debian:

1/ apt-cache search PACKAGE-NAME
2/
http://packages.debian.org/search?keywords=PACKAGE-NAME&searchon=names&suite=all§ion=all
3/ apt-file search PACKAGE-NAME
4/ http://www.debian.org/devel/wnpp/being_packaged
5/ http://www.debian.org/devel/wnpp/requested

This might not be an exhaustive list of checks.

And obviously, your favorite search engine might help (avoiding
trademark, as everyone know, is also very important). In this case, it
shows a few results that aren't engaging, and ... nothing about
OpenStack trove.

Also, while using apt-file search, make sure that no file in /usr/bin is
in conflict. Just to let everyone understand, allow me to remind
everyone the NodeJS which used /usr/bin/node, while an amateur radio
AX25 server "node" source package used /usr/sbin/node. Then we had this
decision from the technical committee:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614907#113

As a result, since NodeJS never migrated to Testing before the freeze
date (and that is a requirement), we released Wheezy without NodeJS.

This kind of disaster scenario should be avoided at all costs. Note that
within Debian, there's no "this package is more important than this one"
kind of things, so I don't believe that OpenStack would have any
priority in this kind of case, so it is very important to get things right.

> Remember that most of our 1200 devs do not have any idea how
> debian packaging works. Those of us who _do_ need to give very short and
> succinct guidelines, such as:
> 
> The package name should not conflict with source or binary package names
> in Debian. You can search for those by ...

Well, not only the binary package names (for the source package, it
maters a lot less, we can use anything). What's even more important is
that we should never have *installed files* collision. Declaring a
Breaks: or a Conflicts: doesn't cut it, unless we have 2 implementations
of the same things, with the same functionality (for example mawk vs
gawk, in which case we can use update-alternatives (see manpage)). For
example, if one day someone wants to package the TroveClient from
dev.yourtrove.com, we have such unsolvable problem of file collision (in
the Python dist-packages folder).

> However, again, in this case I think it's fine, and I do not think we
> need to rename trove beceause there happens to be a package called trove4j.

I just hope so as well.

Thomas Goirand (zigo)

P.S: I will use openstack-trove as source package.


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

Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi

[Michael Basnight]

Thx for getting this squared away zigo!!

On Oct 1, 2013, at 10:40 AM, Thomas Goirand wrote:

> Hi,
> 
> First of all, before I reply, I'd like to tell that hopefully, I believe
> we're fine in this specific case (at least on the Debian side of
> things). Though it really shouldn't have happen, and I believe it's my
> role to warn everybody about the risks.
> 
> On 10/02/2013 12:02 AM, Monty Taylor wrote:
>> 
>> 
>> On 10/01/2013 11:45 AM, Thomas Goirand wrote:
>>> On 10/01/2013 10:02 PM, Jonathan Dowland wrote:
 On Tue, Oct 01, 2013 at 09:45:17PM +0800, Thomas Goirand wrote:
> Since I have already uploaded python-troveclient (currently waiting in
> the FTP master's NEW queue), OpenStack troveclient will be in Sid, but
> if some day, someone wants to upload TroveClient from
> http://dev.yourtrove.com, then we have a problem.
 …
> Is it too late to fix this?
>> 
>> I don't think it's a problem. Two reasons:
>> 
>> a) libtrove-java having its source package named trove is a bug. the
>> upstream project is called trove4j, that's what their source package
>> should have been called. We can't be held accountable for that.
> 
> The source package name isn't a problem, it can be anything. I think I
> will use openstack-trove. By the way, it's only "trove4j" because there
> was "trove3" before, if I understand well (I get that doing "apt-file
> search trove" on my Sid box).
> 
>> b) We got to python-troveclient first. We win. (sorry that's rude, but
>> we _did_ get into the queue first. That's the reason that pip is
>> "python-pip" in debian, because there is a pip tool in perl. TroveClient
>> released last january and dev.yourtrove.com is unresponsive.
> 
> Yes, that might be right for the Debian package. Though at PyPi, there's
> TroveClient already. Or is it that PyPi is case sensitive, and then we
> don't have a problem here?
> 
>> I DO agree that we need to be careful with them, and I think that a fair
>> list of things to check when looking for a name are:
>> 
>> PyPI
>> Launchpad
>> debian
>> fedora
> 
> Please also add Gentoo to the list (since there is also an ongoing
> effort to package OpenStack there as well).
> 
>> We might need some follow up from fedora and debian folks about HOW
>> people should search for names and what things should be considered in
>> conflict.
> 
> For Debian:
> 
> 1/ apt-cache search PACKAGE-NAME
> 2/
> http://packages.debian.org/search?keywords=PACKAGE-NAME&searchon=names&suite=all§ion=all
> 3/ apt-file search PACKAGE-NAME
> 4/ http://www.debian.org/devel/wnpp/being_packaged
> 5/ http://www.debian.org/devel/wnpp/requested
> 
> This might not be an exhaustive list of checks.
> 
> And obviously, your favorite search engine might help (avoiding
> trademark, as everyone know, is also very important). In this case, it
> shows a few results that aren't engaging, and ... nothing about
> OpenStack trove.
> 
> Also, while using apt-file search, make sure that no file in /usr/bin is
> in conflict. Just to let everyone understand, allow me to remind
> everyone the NodeJS which used /usr/bin/node, while an amateur radio
> AX25 server "node" source package used /usr/sbin/node. Then we had this
> decision from the technical committee:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614907#113
> 
> As a result, since NodeJS never migrated to Testing before the freeze
> date (and that is a requirement), we released Wheezy without NodeJS.
> 
> This kind of disaster scenario should be avoided at all costs. Note that
> within Debian, there's no "this package is more important than this one"
> kind of things, so I don't believe that OpenStack would have any
> priority in this kind of case, so it is very important to get things right.
> 
>> Remember that most of our 1200 devs do not have any idea how
>> debian packaging works. Those of us who _do_ need to give very short and
>> succinct guidelines, such as:
>> 
>> The package name should not conflict with source or binary package names
>> in Debian. You can search for those by ...
> 
> Well, not only the binary package names (for the source package, it
> maters a lot less, we can use anything). What's even more important is
> that we should never have *installed files* collision. Declaring a
> Breaks: or a Conflicts: doesn't cut it, unless we have 2 implementations
> of the same things, with the same functionality (for example mawk vs
> gawk, in which case we can use update-alternatives (see manpage)). For
> example, if one day someone wants to package the TroveClient from
> dev.yourtrove.com, we have such unsolvable problem of file collision (in
> the Python dist-packages folder).
> 
>> However, again, in this case I think it's fine, and I do not think we
>> need to rename trove beceause there happens to be a package called trove4j.
> 
> I just hope so as well.
> 
> Thomas Goirand (zigo)
> 
> P.S: I will use openstack-trove as source package.
> 
> 
> ___
> OpenStack-de

[openstack-dev] [Tuskar UI] Wireframes for Node, Rack, and Resource Class Details pages

[Liz Blanchard]

Hi All,

Over the last few weeks, I've been working on compiling a list of metrics and 
representing these metrics via wireframes that are important to show to users 
on the Node, Rack(Logical Group), and Resource Class details pages in Tuskar. 
These have been designed keeping the metrics that Ceilometer surfaces in mind, 
but there are some additional metrics that would need to be surfaced to 
completely implement these pages.

Although these have been designed with Tuskar in mind, my hope is that these 
visualizations could be reused through out Horizon in certain detail and 
overview pages as we define which metrics are important to surface to users in 
the monitoring space.

When you have a chance, and if you have some time, please feel free to respond 
with any feedback you may have on these:
http://people.redhat.com/~lsurette/OpenStack/Tuskar%20Detail%20Pages_1.0.pdf

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

[openstack-dev] [Neutron][VPNaaS] VPNaaS team meeting

[Nachi Ueno]

Hi Neutron VPNaaS folks

In havana, IPsec site-to-site model and reference driver is merged.
Let's discuss next step! :P

I have created a page for this discussion.
so could you add your bp or thought or workitem on this etherpad page.

https://etherpad.openstack.org/NeutronVPNaaSIceHouse

I have also registered a session based on this discussion.
http://summit.openstack.org/cfp/details/163
I would like to discuss based on the etherpad page at the summit session.

Also, I would like to have a meeting on IRC.
I added a candidate date in the etherpad page, so please feel free to add
your option.

Best
Nachi

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

Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi

[Monty Taylor]

On 10/01/2013 01:40 PM, Thomas Goirand wrote:
> Hi,
> 
> First of all, before I reply, I'd like to tell that hopefully, I believe
> we're fine in this specific case (at least on the Debian side of
> things). Though it really shouldn't have happen, and I believe it's my
> role to warn everybody about the risks.

Thank you!

> On 10/02/2013 12:02 AM, Monty Taylor wrote:
>>
>>
>> On 10/01/2013 11:45 AM, Thomas Goirand wrote:
>>> On 10/01/2013 10:02 PM, Jonathan Dowland wrote:
 On Tue, Oct 01, 2013 at 09:45:17PM +0800, Thomas Goirand wrote:
> Since I have already uploaded python-troveclient (currently waiting in
> the FTP master's NEW queue), OpenStack troveclient will be in Sid, but
> if some day, someone wants to upload TroveClient from
> http://dev.yourtrove.com, then we have a problem.
 …
> Is it too late to fix this?
>>
>> I don't think it's a problem. Two reasons:
>>
>> a) libtrove-java having its source package named trove is a bug. the
>> upstream project is called trove4j, that's what their source package
>> should have been called. We can't be held accountable for that.
> 
> The source package name isn't a problem, it can be anything. I think I
> will use openstack-trove. By the way, it's only "trove4j" because there
> was "trove3" before, if I understand well (I get that doing "apt-file
> search trove" on my Sid box).

Whee. That's lovely.

>> b) We got to python-troveclient first. We win. (sorry that's rude, but
>> we _did_ get into the queue first. That's the reason that pip is
>> "python-pip" in debian, because there is a pip tool in perl. TroveClient
>> released last january and dev.yourtrove.com is unresponsive.
> 
> Yes, that might be right for the Debian package. Though at PyPi, there's
> TroveClient already. Or is it that PyPi is case sensitive, and then we
> don't have a problem here?

This:
 https://pypi.python.org/pypi/python-troveclient
Is us - so we append a python- anyway.

Don't ask me why - we just always have.

>> I DO agree that we need to be careful with them, and I think that a fair
>> list of things to check when looking for a name are:
>>
>> PyPI
>> Launchpad
>> debian
>> fedora
> 
> Please also add Gentoo to the list (since there is also an ongoing
> effort to package OpenStack there as well).

>> We might need some follow up from fedora and debian folks about HOW
>> people should search for names and what things should be considered in
>> conflict.
> 
> For Debian:
> 
> 1/ apt-cache search PACKAGE-NAME
> 2/
> http://packages.debian.org/search?keywords=PACKAGE-NAME&searchon=names&suite=all§ion=all
> 3/ apt-file search PACKAGE-NAME
> 4/ http://www.debian.org/devel/wnpp/being_packaged
> 5/ http://www.debian.org/devel/wnpp/requested
> 
> This might not be an exhaustive list of checks.
> 
> And obviously, your favorite search engine might help (avoiding
> trademark, as everyone know, is also very important). In this case, it
> shows a few results that aren't engaging, and ... nothing about
> OpenStack trove.
> 
> Also, while using apt-file search, make sure that no file in /usr/bin is
> in conflict. Just to let everyone understand, allow me to remind
> everyone the NodeJS which used /usr/bin/node, while an amateur radio
> AX25 server "node" source package used /usr/sbin/node. Then we had this
> decision from the technical committee:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614907#113
> 
> As a result, since NodeJS never migrated to Testing before the freeze
> date (and that is a requirement), we released Wheezy without NodeJS.
> 
> This kind of disaster scenario should be avoided at all costs. Note that
> within Debian, there's no "this package is more important than this one"
> kind of things, so I don't believe that OpenStack would have any
> priority in this kind of case, so it is very important to get things right.
> 
>> Remember that most of our 1200 devs do not have any idea how
>> debian packaging works. Those of us who _do_ need to give very short and
>> succinct guidelines, such as:
>>
>> The package name should not conflict with source or binary package names
>> in Debian. You can search for those by ...
> 
> Well, not only the binary package names (for the source package, it
> maters a lot less, we can use anything). What's even more important is
> that we should never have *installed files* collision. Declaring a
> Breaks: or a Conflicts: doesn't cut it, unless we have 2 implementations
> of the same things, with the same functionality (for example mawk vs
> gawk, in which case we can use update-alternatives (see manpage)). For
> example, if one day someone wants to package the TroveClient from
> dev.yourtrove.com, we have such unsolvable problem of file collision (in
> the Python dist-packages folder).
> 
>> However, again, in this case I think it's fine, and I do not think we
>> need to rename trove beceause there happens to be a package called trove4j.
> 
> I just hope so as well.
> 
> Thomas Goirand (zigo)
> 
> P.S: I will

Re: [openstack-dev] Meeting Tuesday October 1st at 19:00 UTC

[Elizabeth Krumbach Joseph]

On Mon, Sep 30, 2013 at 4:23 PM, Elizabeth Krumbach Joseph
 wrote:
> The OpenStack Infrastructure (Infra) team is hosting our weekly
> meeting tomorrow, Tuesday October 1st, at 19:00 UTC in
> #openstack-meeting

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-10-01-19.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-10-01-19.01.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-10-01-19.01.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2
http://www.princessleia.com

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

[openstack-dev] [TripleO] *tuskar* moving to openstack/

[Robert Collins]

Infra have a move slot this weekend and *tuskar* are now queued up to
move at that point.

Once we've moved them, they will have their test runs coerced to use
the official mirror and requirements sets; we may find that breaks
current tests that are using the looser rules from stackforge - if so,
it should be straight forward to fix them up post move.

You'll need to update URLs and git remotes once the move has happened.
Jim Blair will have announcements on exact timing closer to the move.

Cheers,
Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

[openstack-dev] [neutron] [ml2] devstack now defaults to the ML2 plugin

[Kyle Mestery (kmestery)]

Folks:

Just an update regarding the change to move devstack to default
to the ML2 Neutron plugin instead of the OVS plugin. The patch [1]
merged yesterday. Full tempest tests were passed with this, but
just a heads up for those using devstack without specifying a
Neutron plugin specifically.

Thanks,
Kyle

[1] https://review.openstack.org/#/c/47837/

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

Re: [openstack-dev] [neutron] [ml2] devstack now defaults to the ML2 plugin

[Nachi Ueno]

Congrat!

2013/10/1 Kyle Mestery (kmestery) :
> Folks:
>
> Just an update regarding the change to move devstack to default
> to the ML2 Neutron plugin instead of the OVS plugin. The patch [1]
> merged yesterday. Full tempest tests were passed with this, but
> just a heads up for those using devstack without specifying a
> Neutron plugin specifically.
>
> Thanks,
> Kyle
>
> [1] https://review.openstack.org/#/c/47837/
>
> ___
> 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] [TROVE] Thoughts on DNS refactoring, Designate integration.

[Ilya Sviridov]

On Tue, Oct 1, 2013 at 6:45 PM, Tim Simpson wrote:

>  Hi fellow Trove devs,
>
> With the Designate project ramping up, its time to refactor the ancient
> DNS code that's in Trove to work with Designate.
>
> The good news is since the beginning, it has been possible to add new
> drivers for DNS in order to use different services. Right now we only have
> a driver for the Rackspace DNS API, but it should be possible to write one
> for Designate as well.
>

How it corelates with Trove dirrection to use HEAT for all provisioning and
managing cloud resources?
There are BPs for Designate resource (
https://blueprints.launchpad.net/heat/+spec/designate-resource) and
Rackspace DNS (https://blueprints.launchpad.net/heat/+spec/rax-dns-resource)
as well and it looks logically to use the HEAT for that.

Currently Trove has logic for provisioning instances, dns driver, creation
of security group, but with switching to HEAT way, we have duplication of
the same functionality we have to support.


>
> However, there's a bigger topic here. In a gist sent to me recently by
> Dennis M. with his thoughts on how this work should proceed, he included
> the comment that Trove should *only* support Designate:
> https://gist.github.com/crazymac/6705456/raw/2a16c7a249e73b3e42d98f5319db167f8d09abe0/gistfile1.txt
>
> I disagree. I have been waiting for a canonical DNS solution such as
> Designate to enter the Openstack umbrella for years now, and am looking
> forward to having Trove consume it. However, changing all the code so that
> nothing else works is premature.
>

All non mainstream resources like cloud provider specific can be
implemented as HEAT plugins (https://wiki.openstack.org/wiki/Heat/Plugins)


>
> Instead, let's start work to play well with Designate now, using the open
> interface that has always existed. In the future after Designate enters
> integration status we can then make the code closed and only support
> Designate.
>

Do we really need playing with Designate and then replace it? I expect
designate resource will come together with designate or even earlier.

With best regards,
Ilya Sviridov


> Denis also had some other comments about the DNS code, such as not passing
> a single object as a parameter because it could be None. I think this is in
> reference to passing around a DNS entry which gets formed by the DNS
> instance entry factory. I see how someone might think this is brittle, but
> in actuality it has worked for several years so if anything changing it
> would introduce bugs. The interface was also written to use a full object
> in order to be flexible; a full object should make it easier to work with
> different types of DnsDriver implementations, as well as allowing more
> options to be set from the DnsInstanceEntryFactory. This later class
> creates a DnsEntry from an instance_id. It is possible that two deployments
> of Trove, even if they are using Designate, might opt for different
> DnsInstanceEntryFactory implementations in order to give the DNS entries
> associated to databases different patterns. If the DNS entry is created at
> this point its easier to further customize and tailor it. This will hold
> true even when Designate is ready to become the only DNS option we support
> (if such a thing is desirable).
>
> Thanks,
>
> Tim
>
>
>
>
> ___
> 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] [TROVE] Thoughts on DNS refactoring, Designate integration.

[Michael Basnight]

> On Oct 1, 2013, at 3:06 PM, Ilya Sviridov  wrote:
> 
> 
>> On Tue, Oct 1, 2013 at 6:45 PM, Tim Simpson  
>> wrote:
>> Hi fellow Trove devs,
>> 
>> With the Designate project ramping up, its time to refactor the ancient DNS 
>> code that's in Trove to work with Designate.
>> 
>> The good news is since the beginning, it has been possible to add new 
>> drivers for DNS in order to use different services. Right now we only have a 
>> driver for the Rackspace DNS API, but it should be possible to write one for 
>> Designate as well.
> 
> How it corelates with Trove dirrection to use HEAT for all provisioning and 
> managing cloud resources? 
> There are BPs for Designate resource 
> (https://blueprints.launchpad.net/heat/+spec/designate-resource) and 
> Rackspace DNS (https://blueprints.launchpad.net/heat/+spec/rax-dns-resource) 
> as well and it looks logically to use the HEAT for that.
> 
> Currently Trove has logic for provisioning instances, dns driver, creation of 
> security group, but with switching to HEAT way, we have duplication of the 
> same functionality we have to support. 

+1 to using heat for this. However, as people are working on heat support right 
now to make it more sound, if there is a group that wants/needs DNS refactoring 
now, I'd say lets add it in. If no one is in need of changing what's existing 
until we get better heat support, then we should just abandon the review and 
leave the existing DNS code as is. 

I would prefer, if there is no one in need, to abandon the exiting review and 
add it to heat support. 

>  
>> 
>> However, there's a bigger topic here. In a gist sent to me recently by 
>> Dennis M. with his thoughts on how this work should proceed, he included the 
>> comment that Trove should *only* support Designate: 
>> https://gist.github.com/crazymac/6705456/raw/2a16c7a249e73b3e42d98f5319db167f8d09abe0/gistfile1.txt
>> 
>> I disagree. I have been waiting for a canonical DNS solution such as 
>> Designate to enter the Openstack umbrella for years now, and am looking 
>> forward to having Trove consume it. However, changing all the code so that 
>> nothing else works is premature.
> 
> All non mainstream resources like cloud provider specific can be implemented 
> as HEAT plugins (https://wiki.openstack.org/wiki/Heat/Plugins)
>  
>> 
>> Instead, let's start work to play well with Designate now, using the open 
>> interface that has always existed. In the future after Designate enters 
>> integration status we can then make the code closed and only support 
>> Designate.
> 
> Do we really need playing with Designate and then replace it? I expect 
> designate resource will come together with designate or even earlier.
> 
> With best regards,
> Ilya Sviridov
> 
>> 
>> Denis also had some other comments about the DNS code, such as not passing a 
>> single object as a parameter because it could be None. I think this is in 
>> reference to passing around a DNS entry which gets formed by the DNS 
>> instance entry factory. I see how someone might think this is brittle, but 
>> in actuality it has worked for several years so if anything changing it 
>> would introduce bugs. The interface was also written to use a full object in 
>> order to be flexible; a full object should make it easier to work with 
>> different types of DnsDriver implementations, as well as allowing more 
>> options to be set from the DnsInstanceEntryFactory. This later class creates 
>> a DnsEntry from an instance_id. It is possible that two deployments of 
>> Trove, even if they are using Designate, might opt for different 
>> DnsInstanceEntryFactory implementations in order to give the DNS entries 
>> associated to databases different patterns. If the DNS entry is created at 
>> this point its easier to further customize and tailor it. This will hold 
>> true even when Designate is ready to become the only DNS option we support 
>> (if such a thing is desirable).
>> 
>> Thanks,
>> 
>> Tim
>> 
>> 
>> 
>> 
>> ___
>> 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] [TROVE] Thoughts on DNS refactoring, Designate integration.

[Tim Simpson]

Ilya you make a good point. We shouldn't spend time massively change the DNS 
code if we'll just have to do it again so that HEAT can do everything for us.

I echo Mike's comments though that if for some reason someone wants Designate 
support before we get HEAT integrated they should be able to add a new DNS 
driver. As I said before though I think that should be possible without major 
changes to the existing DNS code. 

Thanks,

Tim
___
From: Michael Basnight [mailto:mbasni...@gmail.com] 
Sent: Tuesday, October 01, 2013 5:37 PM
To: OpenStack Development Mailing List
Cc: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [TROVE] Thoughts on DNS refactoring, Designate 
integration.

On Oct 1, 2013, at 3:06 PM, Ilya Sviridov  wrote:

On Tue, Oct 1, 2013 at 6:45 PM, Tim Simpson  wrote:
Hi fellow Trove devs,

With the Designate project ramping up, its time to refactor the ancient DNS 
code that's in Trove to work with Designate.

The good news is since the beginning, it has been possible to add new drivers 
for DNS in order to use different services. Right now we only have a driver for 
the Rackspace DNS API, but it should be possible to write one for Designate as 
well.

How it corelates with Trove dirrection to use HEAT for all provisioning and 
managing cloud resources? 
There are BPs for Designate resource 
(https://blueprints.launchpad.net/heat/+spec/designate-resource) and Rackspace 
DNS (https://blueprints.launchpad.net/heat/+spec/rax-dns-resource) as well and 
it looks logically to use the HEAT for that.
Currently Trove has logic for provisioning instances, dns driver, creation of 
security group, but with switching to HEAT way, we have duplication of the same 
functionality we have to support. 

+1 to using heat for this. However, as people are working on heat support right 
now to make it more sound, if there is a group that wants/needs DNS refactoring 
now, I'd say lets add it in. If no one is in need of changing what's existing 
until we get better heat support, then we should just abandon the review and 
leave the existing DNS code as is. 

I would prefer, if there is no one in need, to abandon the exiting review and 
add it to heat support. 


 

However, there's a bigger topic here. In a gist sent to me recently by Dennis 
M. with his thoughts on how this work should proceed, he included the comment 
that Trove should *only* support Designate: 
https://gist.github.com/crazymac/6705456/raw/2a16c7a249e73b3e42d98f5319db167f8d09abe0/gistfile1.txt

I disagree. I have been waiting for a canonical DNS solution such as Designate 
to enter the Openstack umbrella for years now, and am looking forward to having 
Trove consume it. However, changing all the code so that nothing else works is 
premature.

All non mainstream resources like cloud provider specific can be implemented as 
HEAT plugins (https://wiki.openstack.org/wiki/Heat/Plugins)
 

Instead, let's start work to play well with Designate now, using the open 
interface that has always existed. In the future after Designate enters 
integration status we can then make the code closed and only support Designate.

Do we really need playing with Designate and then replace it? I expect 
designate resource will come together with designate or even earlier.

With best regards,
Ilya Sviridov

Denis also had some other comments about the DNS code, such as not passing a 
single object as a parameter because it could be None. I think this is in 
reference to passing around a DNS entry which gets formed by the DNS instance 
entry factory. I see how someone might think this is brittle, but in actuality 
it has worked for several years so if anything changing it would introduce 
bugs. The interface was also written to use a full object in order to be 
flexible; a full object should make it easier to work with different types of 
DnsDriver implementations, as well as allowing more options to be set from the 
DnsInstanceEntryFactory. This later class creates a DnsEntry from an 
instance_id. It is possible that two deployments of Trove, even if they are 
using Designate, might opt for different DnsInstanceEntryFactory 
implementations in order to give the DNS entries associated to databases 
different patterns. If the DNS entry is created at this point its easier to 
further customize and tailor it. This will hold true even when Designate is 
ready to become the only DNS option we support (if such a thing is desirable).

Thanks,

Tim



___
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.opensta

[openstack-dev] Instances running on VMware ESXi unable to get ip by dhcp

[openstack learner]

Hi all,

I read a similar topic was discussed before but it seems like no specific
and clear solution is provided in that discussion, anyone has the same
issue before and already solved it?


According to the vmware vsphere networking instruction, I create a port
group with the same name as the 'vmware.integration_bridge' value in
nova.conf (which is 'br-int'). And all VM NICs are now successfully
attached to this port group when I boot VMs.  When booting the new VMs, I
am using the default private network *private-subnet* 10.0.0.0/24, so from
horizon I can see ips such as 10.0.0.3 and 10.0.0.4 are assigned to the
VMs. However, when I do a "ifconfig" on the VMs, I find actually the
instances do not get the ip(10.0.0.3/10.0.0.4) by dhcp. I check the screen
log and it looks like the q-dhcp is working.  Anyone knows what cause this
issue?  Is there any further configuration I should do to make the dhcp
succeed?  I also tried using the nova-network(using port group "br100")
before and having the same issue.


*q-dhcp log:*

2013-09-30 23:42:41.685 2626 DEBUG neutron.openstack.common.rpc.
amqp [-] UNIQUE_ID is 10770fac52e147beb373fca9dcd1de40. _add_unique_id
/opt/stack/neutron/neutron/openstack/common/rpc/amqp.py:339
2013-09-30 23:42:41.688 2626 DEBUG amqp [-] Closed channel #1 _do_close
/usr/local/lib/python2.7/dist-packages/amqp/channel.py:88
2013-09-30 23:42:41.688 2626 DEBUG amqp [-] using channel_id: 1 __init__
/usr/local/lib/python2.7/dist-packages/amqp/channel.py:70
2013-09-30 23:42:41.689 2626 DEBUG amqp [-] Channel open _open_ok
/usr/local/lib/python2.7/dist-packages/amqp/channel.py:420
2013-09-30 23:42:45.685 2626 DEBUG neutron.openstack.common.rpc.amqp [-]
Making asynchronous cast on q-plugin... cast
/opt/stack/neutron/neutron/openstack/common/rpc/amqp.py:559
2013-09-30 23:42:45.685 2626 DEBUG neutron.openstack.common.rpc.amqp [-]
UNIQUE_ID is 56eb7c5e7d78487aa2ee7121dbec0da4. _add_unique_id
/opt/stack/neutron/neutron/openstack/common/rpc/amqp.py:339
2013-09-30 23:42:45.688 2626 DEBUG amqp [-] Closed channel #1 _do_close
/usr/local/lib/python2.7/dist-packages/amqp/channel.py:88
2013-09-30 23:42:45.688 2626 DEBUG amqp [-] using channel_id: 1 __init__
/usr/local/lib/python2.7/dist-packages/amqp/channel.py:70
2013-09-30 23:42:45.689 2626 DEBUG amqp [-] Channel open _open_ok
/usr/local/lib/python2.7/dist-packages/amqp/channel.py:420
2013-09-30 23:42:49.688 2626 DEBUG neutron.openstack.common.rpc.amqp [-]
Making asynchronous cast on q-plugin... cast
/opt/stack/neutron/neutron/openstack/common/rpc/amqp.py:559
2013-09-30 23:42:49.689 2626 DEBUG neutron.openstack.common.rpc.amqp [-]
UNIQUE_ID is 1151f4ac029f442b80f1f4af3049e870. _add_unique_id
/opt/stack/neutron/neutron/openstack/common/rpc/amqp.py:339
2013-09-30 23:42:49.691 2626 DEBUG amqp [-] Closed channel #1 _do_close
/usr/local/lib/python2.7/dist-packages/amqp/channel.py:88
2013-09-30 23:42:49.691 2626 DEBUG amqp [-] using channel_id: 1 __init__
/usr/local/lib/python2.7/dist-packages/amqp/channel.py:70
2013-09-30 23:42:49.692 2626 DEBUG amqp [-] Channel open _open_ok
/usr/local/lib/python2.7/dist-packages/amqp/channel.py:420
2013-09-30 23:42:53.688 2626 DEBUG neutron.openstack.common.rpc.amqp [-]
Making asynchronous cast on q-plugin... cast
/opt/stack/neutron/neutron/openstack/common/rpc/amqp.py:559
2013-09-30 23:42:53.689 2626 DEBUG neutron.openstack.common.rpc.amqp [-]
UNIQUE_ID is 661853b84a2b4ddbaa45a4f007c169df. _add_unique_id
/opt/stack/neutron/neutron/openstack/common/rpc/amqp.py:339
2013-09-30 23:42:53.691 2626 DEBUG amqp [-] Closed channel #1 _do_close
/usr/local/lib/python2.7/dist-packages/amqp/channel.py:88
2013-09-30 23:42:53.691 2626 DEBUG amqp [-] using channel_id: 1 __init__
/usr/local/lib/python2.7/dist-packages/amqp/channel.py:70
2013-09-30 23:42:53.692 2626 DEBUG amqp [-] Channel open _open_ok
/usr/local/lib/python2.7/dist-packages/amqp/channel.py:420
2013-09-30 23:42:57.690 2626 DEBUG neutron.openstack.common.rpc.amqp [-]
Making asynchronous cast on q-plugin... cast
/opt/stack/neutron/neutron/openstack/common/rpc/amqp.py:559
2013-09-30 23:42:57.691 2626 DEBUG neutron.openstack.common.rpc.amqp [-]
UNIQUE_ID is 59e6071e54c0401d9111cc7c0e35e9d1. _add_unique_id
/opt/stack/neutron/neutron/openstack/common/rpc/amqp.py:339
2013-09-30 23:42:57.693 2626 DEBUG amqp [-] Closed channel #1 _do_close
/usr/local/lib/python2.7/dist-packages/amqp/channel.py:88
2013-09-30 23:42:57.693 2626 DEBUG amqp [-] using channel_id: 1 __init__
/usr/local/lib/python2.7/dist-packages/amqp/channel.py:70
2013-09-30 23:42:57.694 2626 DEBUG amqp [-] Channel open _open_ok
/usr/local/lib/python2.7/dist-packages/amqp/channel.py:420

Thanks a lot

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

[openstack-dev] [TripleO] Tuskar and releases

[Robert Collins]

We'd like to get tuskar projects doing releases sooner rather than
later. For python-tuskarclient, this is pretty much a no-brainer : we
just need to start doing it.

However, for tuskar-ui and tuskar it's more complex.

# tuskar

This is an API service; whats the story for non-integrated projects
and releases? Can we do them, or does the release team do them? Does
it make integration/incubation any harder?

# tuskar-ui

This is a Horizon plugin -
http://git.openstack.org/cgit/stackforge/tuskar-ui/tree/docs/install.rst#n57
- so it's not super clear to me how to make releases of it. Should it
really just be in the Horizon tree?

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [neutron] [ml2] devstack now defaults to the ML2 plugin

[Richard Woo]

Kyle, what is the proper way to configure ML2 plugin (I plan to use OVS
with VLAN) in localrc?

Thanks,
Richard


On Tue, Oct 1, 2013 at 5:12 PM, Kyle Mestery (kmestery)
wrote:

> Folks:
>
> Just an update regarding the change to move devstack to default
> to the ML2 Neutron plugin instead of the OVS plugin. The patch [1]
> merged yesterday. Full tempest tests were passed with this, but
> just a heads up for those using devstack without specifying a
> Neutron plugin specifically.
>
> Thanks,
> Kyle
>
> [1] https://review.openstack.org/#/c/47837/
>
> ___
> 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] Requirements syncing job is live

[ZhiQiang Fan]

great job! thanks

(how about auto sync from oslo too?
- projects.txt: projects want to be automatically synced from oslo
- heads.txt: HEAD for each module in oslo

whenever module maintainer think current module is strong enough to
publish, then he/she can edit the heads.txt of that module line, then
jenkins will propose a sync patch for projects listed in projects.txt

this behavior will be dangerous, since it may pass gate test when merge but
cause internal bug which is not well test coverd)


On Wed, Oct 2, 2013 at 1:27 AM, Monty Taylor  wrote:

> Hey all!
>
> The job to automatically propose syncs from the openstack/requirements
> repo went live today - as I'm sure you all noticed, since pretty much
> everyone got a patch of at least some size.
>
> The job works the same way as the translations job - it will propose a
> patch any time the global repo changes - but if there is already an
> outstanding change that has not been merged, it will simply amend that
> change. So there should only ever be one change per branch per project
> in the topic openstack/requirements submitted by the jenkins user.
>
> If a change comes in and you say to yourself "ZOMG, that version would
> break us" - then you should definitely go and propose an update to the
> global list itself, which is in the global-requirements.txt file in the
> openstack/requirements repo.
>
> The design goal, as discussed at the last two summits, is that we should
> converge on alignment by the release at the very least. With this and
> the changes that exist now in the gate to block non-aligned
> requirements, once we get aligned, we shouldn't probably be too far out
> from each other moving forward.
>
> Additionally, the list of projects to receive updates is managed in a
> file, projects.txt, in the openstack/requirements repo. If you are
> running a project and would like to receive syncing patches, feel free
> to add yourself to the list.
>
> Enjoy!
> Monty
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TROVE] Thoughts on DNS refactoring, Designate integration.

[Vipul Sabhaya]

> On Oct 1, 2013, at 3:37 PM, Michael Basnight  wrote:
> 
>> On Oct 1, 2013, at 3:06 PM, Ilya Sviridov  wrote:
>> 
>> 
>>> On Tue, Oct 1, 2013 at 6:45 PM, Tim Simpson  
>>> wrote:
>>> Hi fellow Trove devs,
>>> 
>>> With the Designate project ramping up, its time to refactor the ancient DNS 
>>> code that's in Trove to work with Designate.
>>> 
>>> The good news is since the beginning, it has been possible to add new 
>>> drivers for DNS in order to use different services. Right now we only have 
>>> a driver for the Rackspace DNS API, but it should be possible to write one 
>>> for Designate as well.
>> 
>> How it corelates with Trove dirrection to use HEAT for all provisioning and 
>> managing cloud resources? 
>> There are BPs for Designate resource 
>> (https://blueprints.launchpad.net/heat/+spec/designate-resource) and 
>> Rackspace DNS (https://blueprints.launchpad.net/heat/+spec/rax-dns-resource) 
>> as well and it looks logically to use the HEAT for that.
>> 
>> Currently Trove has logic for provisioning instances, dns driver, creation 
>> of security group, but with switching to HEAT way, we have duplication of 
>> the same functionality we have to support.
> 
> +1 to using heat for this. However, as people are working on heat support 
> right now to make it more sound, if there is a group that wants/needs DNS 
> refactoring now, I'd say lets add it in. If no one is in need of changing 
> what's existing until we get better heat support, then we should just abandon 
> the review and leave the existing DNS code as is. 
> 
> I would prefer, if there is no one in need, to abandon the exiting review and 
> add it to heat support. 
> 

I would hate to wait til we have full Heat integration before getting Designate 
support, considering Heat does not yet have Designate support.  My vote is to 
move forward with a DNS driver in trove that can be deprecated once everything 
works with Heat.

As far as supporting only Designate, I would be fine with a driver interface 
that could potentially wrap Designate as well as Rax DNS.  Given that both will 
be somewhat temporary, I don't see a reason why we have to rip out rsdns at 
this point.

>>  
>>> 
>>> However, there's a bigger topic here. In a gist sent to me recently by 
>>> Dennis M. with his thoughts on how this work should proceed, he included 
>>> the comment that Trove should *only* support Designate: 
>>> https://gist.github.com/crazymac/6705456/raw/2a16c7a249e73b3e42d98f5319db167f8d09abe0/gistfile1.txt
>>> 
>>> I disagree. I have been waiting for a canonical DNS solution such as 
>>> Designate to enter the Openstack umbrella for years now, and am looking 
>>> forward to having Trove consume it. However, changing all the code so that 
>>> nothing else works is premature.
>> 
>> All non mainstream resources like cloud provider specific can be implemented 
>> as HEAT plugins (https://wiki.openstack.org/wiki/Heat/Plugins)
>>  
>>> 
>>> Instead, let's start work to play well with Designate now, using the open 
>>> interface that has always existed. In the future after Designate enters 
>>> integration status we can then make the code closed and only support 
>>> Designate.
>> 
>> Do we really need playing with Designate and then replace it? I expect 
>> designate resource will come together with designate or even earlier.
>> 
>> With best regards,
>> Ilya Sviridov
>> 
>>> 
>>> Denis also had some other comments about the DNS code, such as not passing 
>>> a single object as a parameter because it could be None. I think this is in 
>>> reference to passing around a DNS entry which gets formed by the DNS 
>>> instance entry factory. I see how someone might think this is brittle, but 
>>> in actuality it has worked for several years so if anything changing it 
>>> would introduce bugs. The interface was also written to use a full object 
>>> in order to be flexible; a full object should make it easier to work with 
>>> different types of DnsDriver implementations, as well as allowing more 
>>> options to be set from the DnsInstanceEntryFactory. This later class 
>>> creates a DnsEntry from an instance_id. It is possible that two deployments 
>>> of Trove, even if they are using Designate, might opt for different 
>>> DnsInstanceEntryFactory implementations in order to give the DNS entries 
>>> associated to databases different patterns. If the DNS entry is created at 
>>> this point its easier to further customize and tailor it. This will hold 
>>> true even when Designate is ready to become the only DNS option we support 
>>> (if such a thing is desirable).
>>> 
>>> Thanks,
>>> 
>>> Tim
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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/mail

Re: [openstack-dev] [neutron] [ml2] devstack now defaults to the ML2 plugin

[Henry Gessau]

Richard,

Please look at https://wiki.openstack.org/wiki/Neutron/ML2

If anything is unclear or doesn't work please follow up so we can tweak the
wiki.

-- Henry

On Tue, Oct 01, at 9:33 pm Richard Woo (richardwoo2...@gmail.com) wrote:
> Kyle, what is the proper way to configure ML2 plugin (I plan to use OVS
> with VLAN) in localrc?
>
> Thanks,
> Richard
>
>
> On Tue, Oct 1, 2013 at 5:12 PM, Kyle Mestery (kmestery)
> mailto:kmest...@cisco.com>> wrote:
>
> Folks:
>
> Just an update regarding the change to move devstack to default
> to the ML2 Neutron plugin instead of the OVS plugin. The patch [1]
> merged yesterday. Full tempest tests were passed with this, but
> just a heads up for those using devstack without specifying a
> Neutron plugin specifically.
>
> Thanks,
> Kyle
>
> [1] https://review.openstack.org/#/c/47837/
>
> ___
> 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] [trove] Configuration API BP

[Vipul Sabhaya]

> On Sep 26, 2013, at 8:49 AM, Michael Basnight  wrote:
> 
>> On Sep 25, 2013, at 7:16 PM, Craig Vyvial wrote:
>> 
>> So we have a blueprint for this and there are a couple things to point out 
>> that have changed since the inception of this BP.
>> 
>> https://blueprints.launchpad.net/trove/+spec/configuration-management
>> 
>> This is an overview of the API calls for 
>> 
>> POST /configurations - create config
>> GET  /configurations - list all configs
>> PUT  /configurations/{id} - update all the parameters
>> 
>> GET  /configurations/{id} - get details on a single config
>> GET  /configurations/{id}/{key} - get single parameter value that was set 
>> for the configuration
>> 
>> PUT  /configurations/{id}/{key} - update/insert a single parameter
>> DELETE  /configurations/{id}/{key} - delete a single parameter
>> 
>> GET  /configurations/{id}/instances - list of instances the config is 
>> assigned to
>> GET  /configurations/parameters - list of all configuration parameters
>> 
>> GET  /configurations/parameters/{key} - get details on a configuration 
>> parameter
>> 
>> There has been talk about using PATCH http action instead of PUT action for 
>> thie update of individual parameter(s).
>> 
>> PUT  /configurations/{id}/{key} - update/insert a single parameter
>> and/or
>> PATCH  /configurations/{id} - update/insert parameter(s)
>> 
>> 
>> I am not sold on the idea of using PATCH unless its widely used in other 
>> projects across Openstack. What does everyone think about this?
>> 
>> If there are any concerns around this please let me know.
> 
> Im a fan of PATCH. Id rather have a different verb on the same resource than 
> creating a new sub-resource just to do the job of what PATCH defines. Im not 
> sure the [1] gives us any value, and i think its only around because of [2]. 
> I can see PATCH removing the need for [1], simplifying the API. And of course 
> removing the need for [2] since it _is_ the updating of a single kv pair. And 
> i know keystone and glance use PATCH for "updates" in their API as well. 
> 
> [1]  GET /configurations/{id}/{key} 
> [2] PUT  /configurations/{id}/{key} 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

So from this API, I see that a configuration is a standalone resource that 
could be applied to N number of instances.  It's not clear to me what the API 
is for 'applying' a configuration to an existing instance.  Also if we change a 
single item in a given configuration, does that change propagate to all 
instances that configuration belongs to? 

What about making 'configuration' a sub-resource of /instances?  

Unless we think configurations will be common amongst instances for a given 
tenant, it may not make sense to make them high level resources. 
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [infra][neutron] Need a quantumclient patch pushed through the gate

[Matt Riedemann]

This patch is a fix for a bug that's blocking all stable branch patches 
from getting through Jenkins:

https://review.openstack.org/#/c/49006/

Jenkins is failing on it because it runs devstack from master which uses 
python-neutronclient but this is a fix for the quantumclient branch (which 
stable branch patches are tested against).

>From what I've seen on other patches like this (and what Monty was saying 
in IRC), the only way to get it in is to force merge it, so I'm requesting 
that someone from the infra team check that out please.



Thanks,

MATT RIEDEMANN
Advisory Software Engineer
Cloud Solutions and OpenStack Development

Phone: 1-507-253-7622 | Mobile: 1-507-990-1889
E-mail: mrie...@us.ibm.com


3605 Hwy 52 N
Rochester, MN 55901-1407
United States
<>___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TROVE] Thoughts on DNS refactoring, Designate integration.

[Michael Basnight]

On Oct 1, 2013, at 7:06 PM, Vipul Sabhaya wrote:

> On Oct 1, 2013, at 3:37 PM, Michael Basnight  wrote:
> 
>> On Oct 1, 2013, at 3:06 PM, Ilya Sviridov  wrote:
>> 
>>> 
>>> On Tue, Oct 1, 2013 at 6:45 PM, Tim Simpson  
>>> wrote:
>>> Hi fellow Trove devs,
>>> 
>>> With the Designate project ramping up, its time to refactor the ancient DNS 
>>> code that's in Trove to work with Designate.
>>> 
>>> The good news is since the beginning, it has been possible to add new 
>>> drivers for DNS in order to use different services. Right now we only have 
>>> a driver for the Rackspace DNS API, but it should be possible to write one 
>>> for Designate as well.
>>> 
>>> How it corelates with Trove dirrection to use HEAT for all provisioning and 
>>> managing cloud resources? 
>>> There are BPs for Designate resource 
>>> (https://blueprints.launchpad.net/heat/+spec/designate-resource) and 
>>> Rackspace DNS 
>>> (https://blueprints.launchpad.net/heat/+spec/rax-dns-resource) as well and 
>>> it looks logically to use the HEAT for that.
>>> 
>>> Currently Trove has logic for provisioning instances, dns driver, creation 
>>> of security group, but with switching to HEAT way, we have duplication of 
>>> the same functionality we have to support. 
>> 
>> +1 to using heat for this. However, as people are working on heat support 
>> right now to make it more sound, if there is a group that wants/needs DNS 
>> refactoring now, I'd say lets add it in. If no one is in need of changing 
>> what's existing until we get better heat support, then we should just 
>> abandon the review and leave the existing DNS code as is. 
>> 
>> I would prefer, if there is no one in need, to abandon the exiting review 
>> and add it to heat support. 
>> 
> 
> I would hate to wait til we have full Heat integration before getting 
> Designate support, considering Heat does not yet have Designate support.  My 
> vote is to move forward with a DNS driver in trove that can be deprecated 
> once everything works with Heat.
> 
> As far as supporting only Designate, I would be fine with a driver interface 
> that could potentially wrap Designate as well as Rax DNS.  Given that both 
> will be somewhat temporary, I don't see a reason why we have to rip out rsdns 
> at this point.

Sounds like we have a winner.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove] Configuration API BP

[Michael Basnight]

On Oct 1, 2013, at 7:19 PM, Vipul Sabhaya wrote:
> 
> So from this API, I see that a configuration is a standalone resource that 
> could be applied to N number of instances.  It's not clear to me what the API 
> is for 'applying' a configuration to an existing instance.  

https://wiki.openstack.org/wiki/Trove/Configurations#Update_an_Instance_.28PUT.29

> Also if we change a single item in a given configuration, does that change 
> propagate to all instances that configuration belongs to? 

Thats a good question. Maybe PATCH'ing a configuration is not a good thing. We 
either have 1) drift between an attached config on an instance vs the template, 
or 2) a confusing situation where we are potentially updating configurations on 
running instances. Another possibility is that a PATCH would in effect, clone 
the existing template, if its in use, giving it a new UUID with the updated 
parameters. But im not sure i like that approach either… Its really not a PATCH 
at that point anyway id think.

Blueprint designers, im looking to you for clarity.

> What about making 'configuration' a sub-resource of /instances?  
> 
> Unless we think configurations will be common amongst instances for a given 
> tenant, it may not make sense to make them high level resources. 

As in /instances/configurations, or /instances/{id}/configurations ? I do see 
commonality between a configuration and a bunch of instances, such that a 
configuration is not unique to a single instance. I can see a reseller having a 
tweaked out "works with _insert your favorite CMS here_" template applied to 
all the instances they provision.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Tuskar and releases

[Monty Taylor]

On 10/01/2013 08:08 PM, Robert Collins wrote:
> We'd like to get tuskar projects doing releases sooner rather than
> later. For python-tuskarclient, this is pretty much a no-brainer : we
> just need to start doing it.

Yup. Just do it.

> However, for tuskar-ui and tuskar it's more complex.
> 
> # tuskar
> 
> This is an API service; whats the story for non-integrated projects
> and releases? Can we do them, or does the release team do them? Does
> it make integration/incubation any harder?

Thus far, non-integrated project can pretty much release however they
want to. Things that would like to get integrated tend to start
following release process and timelines on their own, but nothing
requires it until such a time as the release team takes it over.

> # tuskar-ui
> 
> This is a Horizon plugin -
> http://git.openstack.org/cgit/stackforge/tuskar-ui/tree/docs/install.rst#n57
> - so it's not super clear to me how to make releases of it. Should it
> really just be in the Horizon tree?

Oy. No clue. In theory though - can you do independently releasable
django app things? /me clearly has no idea what he's talking about
here... Maybe see how
http://git.openstack.org/cgit/stackforge/savanna-dashboard/tree/
does it?

 My gut tells me that this either wants to be whatever/however that
works in django, or just wants to live in Horizon. Since it's in service
of the TripleO program, and we

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

Re: [openstack-dev] [TripleO] Tuskar and releases

[Robert Collins]

On 2 October 2013 18:20, Monty Taylor  wrote:

>> # tuskar-ui
>>
>> This is a Horizon plugin -
>> http://git.openstack.org/cgit/stackforge/tuskar-ui/tree/docs/install.rst#n57
>> - so it's not super clear to me how to make releases of it. Should it
>> really just be in the Horizon tree?
>
> Oy. No clue. In theory though - can you do independently releasable
> django app things? /me clearly has no idea what he's talking about
> here... Maybe see how
> http://git.openstack.org/cgit/stackforge/savanna-dashboard/tree/
> does it?
>
>  My gut tells me that this either wants to be whatever/however that
> works in django, or just wants to live in Horizon. Since it's in service
> of the TripleO program, and we

We ...?

Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [TripleO] Tuskar and releases

[Sergey Lukjanov]

In Savanna we're supplying "plugin" for OpenStack Dashboard - 
https://github.com/stackforge/savanna-dashboard

It doesn't contains any copy-paste and dependencies for Django/Horizon and 
currently compatible with Grizzly and Havana OpenStack Dashboard, it only 
contains our code and could be installed to any other existing dashboard. Here 
you can find info about how to install Savanna dashboard plugin - 
https://savanna.readthedocs.org/en/latest/horizon/installation.guide.html

Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.

On Oct 2, 2013, at 4:08, Robert Collins  wrote:

> We'd like to get tuskar projects doing releases sooner rather than
> later. For python-tuskarclient, this is pretty much a no-brainer : we
> just need to start doing it.
> 
> However, for tuskar-ui and tuskar it's more complex.
> 
> # tuskar
> 
> This is an API service; whats the story for non-integrated projects
> and releases? Can we do them, or does the release team do them? Does
> it make integration/incubation any harder?
> 
> # tuskar-ui
> 
> This is a Horizon plugin -
> http://git.openstack.org/cgit/stackforge/tuskar-ui/tree/docs/install.rst#n57
> - so it's not super clear to me how to make releases of it. Should it
> really just be in the Horizon tree?
> 
> -Rob
> 
> -- 
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
> 
> ___
> 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] [trove] Configuration API BP

[McReynolds, Auston]

I have a few questions left unanswered by the blueprint/wiki:

#1 - Should the true default configuration-group for a service-type be
customizable by the cloud provider?

#2 - Should a user be able to enumerate the entire actualized/realized
set of values for a configuration-group, or just the overrides?

#3 - Should a user be able to apply a different configuration-group on
a master, than say, a slave?

#4 - If a user creates a new configuration-group with values equal to
that of the default configuration-group, what is the expected
behavior?

#5 - For GET /configuration/parameters, where is the list of supported
parameters and their metadata sourced from?

#6 - Should a user be able to reset a configuration-group to the
current default configuration-group?

#7 - Is a new configuration-group a clone of the then current default
configuration-group with various changes, or will inheritence be
utilized?

#8 - How should the state of pending configuration-group changes be
reflected in GET /instances/:id ? How will this state be
persisted?

#9 - Reminder: Once multiple service-types and versions are supported,
the configuration-group will need a service-type field.

#10 - Should dynamic values (via functions and operators) in
  configuration-groups be supported?
  Example: innodb_buffer_pool_size = 150 * flavor['ram']/512

My Thoughts:

#1 - Yes
#2 - Actualized
#3 - Yes
#4 - Depends on whether the approach for configuration-groups is to
clone or to inherit.
#5 - ?
#6 - Yes
#7 - ?
#8 - ?
#9 - N/A
#10 - In the first iteration of this feature I don't think it's an
  absolute necessity, but it's definitely a nice-to-have. The
  design/implementation should not preclude this from being easily
  added in the future.

Where "?" == "I'd like to think about it a bit more, but I have a gut
feeling"

Thoughts?



On 10/1/13 7:55 PM, "Michael Basnight"  wrote:

>On Oct 1, 2013, at 7:19 PM, Vipul Sabhaya wrote:
>> 
>> So from this API, I see that a configuration is a standalone resource
>>that could be applied to N number of instances.  It's not clear to me
>>what the API is for 'applying' a configuration to an existing instance.
>
>https://wiki.openstack.org/wiki/Trove/Configurations#Update_an_Instance_.2
>8PUT.29
>
>> Also if we change a single item in a given configuration, does that
>>change propagate to all instances that configuration belongs to?
>
>Thats a good question. Maybe PATCH'ing a configuration is not a good
>thing. We either have 1) drift between an attached config on an instance
>vs the template, or 2) a confusing situation where we are potentially
>updating configurations on running instances. Another possibility is that
>a PATCH would in effect, clone the existing template, if its in use,
>giving it a new UUID with the updated parameters. But im not sure i like
>that approach eitherŠ Its really not a PATCH at that point anyway id
>think.
>
>Blueprint designers, im looking to you for clarity.
>
>> What about making 'configuration' a sub-resource of /instances?
>> 
>> Unless we think configurations will be common amongst instances for a
>>given tenant, it may not make sense to make them high level resources.
>
>As in /instances/configurations, or /instances/{id}/configurations ? I do
>see commonality between a configuration and a bunch of instances, such
>that a configuration is not unique to a single instance. I can see a
>reseller having a tweaked out "works with _insert your favorite CMS
>here_" template applied to all the instances they provision.
>


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