Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

[Denis Makogon]

Small suggestion on listing datastore_type:
Since all compabilities based upon config, we could send response to user
based upon available guestagent managers, but this means, that all
datastore managers parameter should migrate to taskmanager.
Manager description(fq classpath) would delivered to instance through
guest_info.


2013/10/28 Vipul Sabhaya 

>
>
>
> On Sun, Oct 27, 2013 at 4:29 PM, Ilya Sviridov wrote:
>
>> Totally agree, however current concept supposes working with type and
>> version as different entities, even if it is  the attributes on one thing -
>> the configuration.
>>
>> The reason for storing it as separate models can be cases when we are
>> going to use them separately.
>>
>> Sounds really reasonable to keep it as one model, but another question
>> comes to mind.
>> How 'list datastore_type' will look like. That is important because API
>> should be inambiguous.
>>
>> Following openstack tenets, each entity exposed via API has an id and can
>> referenced by it.
>> If we are storing datastore as one entity, we are not able to query
>> versions or types only with their ids.
>>
>> But it is agreed as API
>>
>> /{tenant_id}/datastore_types
>> /{tenant_id}/datastore_types/{datastore_type}/versions
>> /{tenant_id}/datastore_types/versions/{id}
>>
>>
>>
>>
>>
> I am wondering why we even need the last route.
> /{tenant_id}/datastore_types/versions/{id}
>
> If we assume that a datastore_type is the parent resource of versions, we
> could change that route to: 
> /{tenant_id}/datastore_types/{datastore_type}/versions/{id}.
>  Although I don’t know if this route is even necessary - since listing all
> available versions of a certain type is all users really need.
>
> This will allow us to group the type and version, making version no longer
> independent as Nikhil suggests.
>
> So, with current concept it seems better to keep version and type as
>> separate entities in database.
>>
>>
>>  With best regards,
>> Ilya Sviridov
>>
>> 
>>
>>
>> On Fri, Oct 25, 2013 at 10:25 PM, Nikhil Manchanda 
>> wrote:
>>
>>>
>>> It seems strange to me to treat both the datastore_type and version as
>>> two separate entities, when they aren't really independent of each
>>> other. (You can't really deploy a mysql type with a cassandra version,
>>> and vice-versa, so why have separate datastore-list and version-list
>>> calls?)
>>>
>>> I think it's a better idea to store in the db (and list) actual
>>> representations of the datastore type/versions that an image we can
>>> deploy supports. Any disambiguation could then happen based on what
>>> entries actually exist here.
>>>
>>> Let me illustrate what I'm trying to get at with a few examples:
>>>
>>> Database has:
>>> id | type  | version | active
>>> --
>>> a  | mysql | 5.6.14  |   1
>>> b  | mysql | 5.1.0   |   0
>>> c  | postgres  | 9.3.1   |   1
>>> d  | redis | 2.6.16  |   1
>>> e  | redis | 2.6.15  |   1
>>> f  | cassandra | 2.0.1   |   1
>>> g  | cassandra | 2.0.0   |   0
>>>
>>> Config specifies:
>>> default_datastore_id = a
>>>
>>> 1. trove-cli instance create ...
>>> Just works - Since nothing is specified, this uses the
>>> default_datastore_id from the config (mysql 5.6.14 ) . No need for
>>> disambiguation.
>>>
>>> 2. trove-cli instance create --datastore_id e
>>> The datastore_id specified always identifies a unique datastore type /
>>> version so no other information is needed for disambiguation. (In this
>>> case redis 2.6.15, identified by )
>>>
>>> 3. trove-cli instance create --datastore_type postgres
>>> The datastore_type in this case uniquely identifies postgres 9.3.1 ,
>>> so no disambiguation is necessary.
>>>
>>> 4. trove-cli instance create --datastore_type cassandra
>>> In this case, there is only one _active_ datastore with the given
>>> datastore_type, so no further disambiguation is needed and cassandra
>>> 2.0.1  is uniquely identified.
>>>
>>> 5. trove-cli instance create --datastore_type redis
>>> In this case, there are _TWO_ active versions of the specified
>>> datastore_type (2.6.16, and 2.6.17) so the call should return that
>>> further disambiguation _is_ needed.
>>>
>>> 6. trove-cli instance create --datastore_type redis --datastore_version
>>> 2.6.16
>>> We have both datastore_type and datastore_version, and that uniquely
>>> identifies redis 2.6.16 . No further disambiguation is needed.
>>>
>>> 7. trove-cli instance create --datastore_type cassandra --version 2.0.0,
>>> or trove-cli instance create --datastore_id g
>>> Here, we are attempting to deploy a datastore which is _NOT_ active and
>>> this call should fail with an appropriate error message.
>>>
>>> Cheers,
>>> -Nikhil
>>>
>>>
>>> Andrey Shestakov writes:
>>>
>>> > 2. it can be confusing coz not clear to what type version belongs
>>> > (possible add "type" field in version).
>>> > also if you have default type, then specified version recognizes as
>>> > version of default type (no lookup 

[openstack-dev] [Mistral] Community meeting agenda - 10/28/2013

[Renat Akhmerov]

Hi,

Another Mistral IRC community meeting will be held today (10/28/2013) at 16.00 
UTC on #openstack-meeting. Here’s the agenda:

Review last week's action items
Discuss some advanced use cases
Discuss what is left on documentation (use cases, DSL, API)
Start discussing development plans
Open discussion


Go to https://wiki.openstack.org/wiki/Meetings/MistralAgenda to find more 
information about Mistral meetings (e.g. previous meetings’ logs).


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

[openstack-dev] [Heat] Comments on Steve Baker's Proposal on HOT Software Config

[Lakshminaraya Renganarayana]

Sorry, Re-posting this with [Heat] in the subject line, because many of us
have filters based on [Heat] in the subject line.

Hello,

A few us at IBM studied Steve Baker's proposal on HOT Software
Configuration. Overall the proposed constructs and syntax are great -- we
really like the clean syntax and concise specification of components. We
would like to propose a few minor extensions that help with better
expression of dependencies among components and resources, and in-turn
enable cross-vm coordination. We have captured our thoughts on this on the
following Wiki page

https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response


We would like to discuss these further ... please post your comments and
suggestions.

Thank you,
LN
_
Lakshminarayanan Renganarayana
Research Staff Member
IBM T.J. Watson Research Center___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Comments on Steve Baker's Proposal on HOT Software Config

[Lakshminaraya Renganarayana]

Hello,

A few us at IBM studied Steve Baker's proposal on HOT Software
Configuration. Overall the proposed constructs and syntax are great -- we
really like the clean syntax and concise specification of components. We
would like to propose a few minor extensions that help with better
expression of dependencies among components and resources, and in-turn
enable cross-vm coordination. We have captured our thoughts on this on the
following Wiki page

https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response


We would like to discuss these further ... please post your comments and
suggestions.

Thank you,
LN
_
Lakshminarayanan Renganarayana
Research Staff Member
IBM T.J. Watson Research Center
http://researcher.ibm.com/person/us-lrengan___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] upgrade_levels and cells

[Sam Morrison]

Hey,

I’ve been playing with Grizzly -> Havana upgrade paths with cells.
Having Havana at the api cell with Grizzly compute cells won’t work (don’t 
think it’s supposed too?)

Having Grizzly at api level with Havana compute cell almost works, it seems the 
only major issue is the block_device_mappings.

When havana child gets a parent grizzly build request the block_device_mapping 
is an empty list, when it come from Havana it has something like:

   block_device_mapping = [{'boot_index': 0,
 'connection_info': None,
 'delete_on_termination': True,
 'destination_type': 'local',
 'device_name': None,
 'device_type': 'disk',
 'disk_bus': None,
 'guest_format': None,
 'image_id': ‘XXX-XXX-XXX-XXX',
 'instance_uuid': XXX-XXX-XXX-XXX,
 'no_device': None,
 'snapshot_id': None,
 'source_type': 'image',
 'volume_id': None,
 'volume_size': None}]


I don’t know much about the new BDM stuff but it looks like not too much code 
needed to get this working?
Was wondering if anyone else is looking into this kind of stuff or is willing 
to help?

Cheers,
Sam


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

Re: [openstack-dev] consolidating .mailmap?

[Monty Taylor]

On 10/26/2013 04:38 AM, Robert Collins wrote:
> So nova has a massive .mailmap that maps multiple addresses for one
> person together. I'm wondering if a) it's still needed, and b) if it
> is, should we push it into all the repositories - e.g. have a single
> global copy and an automated job to push updates around.

We do still need it. We also have this info duplicated elsewhere (like
stackalytics and gitdm) Perhaps we don't even store it elsewhere in that
form, but instead generate it and then ship it around?

OR - (this is from IRC conversation) We remove it from the repo
altogether since it's mainly for sdist purposes - and instead have infra
read in the mailmap info globally, then copy it into the repo before
sdist generation. The downside to that is that the AUTHORS file would be
weird for people for locally produced tarballs. BUT - I kinda doubt that
people who are re-producing tarballs from source themselves care about
the AUTHORS file.

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

[openstack-dev] [Nova] Preserving ephemeral block device on rebuild?

[Robert Collins]

For context, in TripleO we have precious state to preserve when we
push updates out to a cluster: nova instance volumes (obviously),
swift data stores, mysql db's etc. We have a long term plan to have a
volume model and interface that with Cinder, but thats an Ironic
planed feature, and somewhat down the track : in the short term we'd
like to use the ephemeral volume for such storage: it seems like 'nova
rebuild' could easily be extended to preserve the ephemeral block
device.

>From a nova bm perspective, all that needs to happen is for us to
/not/ format the volume - simples - and we can do that in the current
rebuild code path where destroy + spawn is called, as long as we end
up on the same host.

However, we'd like to support this for libvirt too, because that lets
us test workflows in virt rather than on purely baremetal (or emulated
baremetal). For that, it looks to me like we need to push rebuild down
a layer to the virt driver : so rather than destroy(); spawn(); have a
rebuild() method that takes the same data spawn would, and will be
able to preserve data as needed.

Seeking thoughts on this - both the use of ephemeral in this way, and
sketched out code change - are sought!

Thanks,
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] RFC: Filtering boring commit subjects from ChangeLog

[Monty Taylor]

Hey all!

We're adding a little bit of code to pbr to make the auto-generated
ChangeLog files a bit more useful. Currently, they are just the git
changelog, which is kinda useless. So we wrote this:

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

which produces output like this:

http://paste.openstack.org/show/4  # on a tag
and
http://paste.openstack.org/show/50001  # not on a tag

It underscores the need for commit subjects to communicate something,
which is a good thing.

With that there, it makes changes like:
* Updated from global requirements
and
* Update my mailmap

Kinda lame in the changelog. So we were thinking - what if we recognized
one or more subject tags to skip things going into the ChangeLog file.
My first thought was:

NIT:  # use this for tiny commits that are not really worth changelogging

and

AUTO: # use for commits generated by our machines, such as the global
requirements sync or the Translations sync.

What do people think? Should we bother? Are those good? Would something
else be better? It's sort of an opt-in feature, so adding it SHOULDN'T
bork too many people.

Thoughts?
Monty

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

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

[Vipul Sabhaya]

On Sun, Oct 27, 2013 at 4:29 PM, Ilya Sviridov wrote:

> Totally agree, however current concept supposes working with type and
> version as different entities, even if it is  the attributes on one thing -
> the configuration.
>
> The reason for storing it as separate models can be cases when we are
> going to use them separately.
>
> Sounds really reasonable to keep it as one model, but another question
> comes to mind.
> How 'list datastore_type' will look like. That is important because API
> should be inambiguous.
>
> Following openstack tenets, each entity exposed via API has an id and can
> referenced by it.
> If we are storing datastore as one entity, we are not able to query
> versions or types only with their ids.
>
> But it is agreed as API
>
> /{tenant_id}/datastore_types
> /{tenant_id}/datastore_types/{datastore_type}/versions
> /{tenant_id}/datastore_types/versions/{id}
>
>
>
>
>
I am wondering why we even need the last route.
/{tenant_id}/datastore_types/versions/{id}

If we assume that a datastore_type is the parent resource of versions, we
could change that route to:
/{tenant_id}/datastore_types/{datastore_type}/versions/{id}.
 Although I don’t know if this route is even necessary - since listing all
available versions of a certain type is all users really need.

This will allow us to group the type and version, making version no longer
independent as Nikhil suggests.

So, with current concept it seems better to keep version and type as
> separate entities in database.
>
>
> With best regards,
> Ilya Sviridov
>
> 
>
>
> On Fri, Oct 25, 2013 at 10:25 PM, Nikhil Manchanda wrote:
>
>>
>> It seems strange to me to treat both the datastore_type and version as
>> two separate entities, when they aren't really independent of each
>> other. (You can't really deploy a mysql type with a cassandra version,
>> and vice-versa, so why have separate datastore-list and version-list
>> calls?)
>>
>> I think it's a better idea to store in the db (and list) actual
>> representations of the datastore type/versions that an image we can
>> deploy supports. Any disambiguation could then happen based on what
>> entries actually exist here.
>>
>> Let me illustrate what I'm trying to get at with a few examples:
>>
>> Database has:
>> id | type  | version | active
>> --
>> a  | mysql | 5.6.14  |   1
>> b  | mysql | 5.1.0   |   0
>> c  | postgres  | 9.3.1   |   1
>> d  | redis | 2.6.16  |   1
>> e  | redis | 2.6.15  |   1
>> f  | cassandra | 2.0.1   |   1
>> g  | cassandra | 2.0.0   |   0
>>
>> Config specifies:
>> default_datastore_id = a
>>
>> 1. trove-cli instance create ...
>> Just works - Since nothing is specified, this uses the
>> default_datastore_id from the config (mysql 5.6.14 ) . No need for
>> disambiguation.
>>
>> 2. trove-cli instance create --datastore_id e
>> The datastore_id specified always identifies a unique datastore type /
>> version so no other information is needed for disambiguation. (In this
>> case redis 2.6.15, identified by )
>>
>> 3. trove-cli instance create --datastore_type postgres
>> The datastore_type in this case uniquely identifies postgres 9.3.1 ,
>> so no disambiguation is necessary.
>>
>> 4. trove-cli instance create --datastore_type cassandra
>> In this case, there is only one _active_ datastore with the given
>> datastore_type, so no further disambiguation is needed and cassandra
>> 2.0.1  is uniquely identified.
>>
>> 5. trove-cli instance create --datastore_type redis
>> In this case, there are _TWO_ active versions of the specified
>> datastore_type (2.6.16, and 2.6.17) so the call should return that
>> further disambiguation _is_ needed.
>>
>> 6. trove-cli instance create --datastore_type redis --datastore_version
>> 2.6.16
>> We have both datastore_type and datastore_version, and that uniquely
>> identifies redis 2.6.16 . No further disambiguation is needed.
>>
>> 7. trove-cli instance create --datastore_type cassandra --version 2.0.0,
>> or trove-cli instance create --datastore_id g
>> Here, we are attempting to deploy a datastore which is _NOT_ active and
>> this call should fail with an appropriate error message.
>>
>> Cheers,
>> -Nikhil
>>
>>
>> Andrey Shestakov writes:
>>
>> > 2. it can be confusing coz not clear to what type version belongs
>> > (possible add "type" field in version).
>> > also if you have default type, then specified version recognizes as
>> > version of default type (no lookup in version.datastore_type_id)
>> > but i think we can do lookup in version.datastore_type_id before pick
>> > default.
>> >
>> > 4. if default version is need, then it should be specified in db, coz
>> > switching via versions can be frequent and restart service to reload
>> > config all times is not good.
>> >
>> > On 10/21/2013 05:12 PM, Tim Simpson wrote:
>> >> Thanks for the feedback Andrey.
>> >>
>> >> >> 2. Got this case in irc, and decided to pass type and version
>> >> together to avoid conf

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

[Ilya Sviridov]

Totally agree, however current concept supposes working with type and
version as different entities, even if it is  the attributes on one thing -
the configuration.

The reason for storing it as separate models can be cases when we are going
to use them separately.

Sounds really reasonable to keep it as one model, but another question
comes to mind.
How 'list datastore_type' will look like. That is important because API
should be inambiguous.

Following openstack tenets, each entity exposed via API has an id and can
referenced by it.
If we are storing datastore as one entity, we are not able to query
versions or types only with their ids.

But it is agreed as API

/{tenant_id}/datastore_types
/{tenant_id}/datastore_types/{datastore_type}/versions
/{tenant_id}/datastore_types/versions/{id}




So, with current concept it seems better to keep version and type as
separate entities in database.


With best regards,
Ilya Sviridov




On Fri, Oct 25, 2013 at 10:25 PM, Nikhil Manchanda wrote:

>
> It seems strange to me to treat both the datastore_type and version as
> two separate entities, when they aren't really independent of each
> other. (You can't really deploy a mysql type with a cassandra version,
> and vice-versa, so why have separate datastore-list and version-list
> calls?)
>
> I think it's a better idea to store in the db (and list) actual
> representations of the datastore type/versions that an image we can
> deploy supports. Any disambiguation could then happen based on what
> entries actually exist here.
>
> Let me illustrate what I'm trying to get at with a few examples:
>
> Database has:
> id | type  | version | active
> --
> a  | mysql | 5.6.14  |   1
> b  | mysql | 5.1.0   |   0
> c  | postgres  | 9.3.1   |   1
> d  | redis | 2.6.16  |   1
> e  | redis | 2.6.15  |   1
> f  | cassandra | 2.0.1   |   1
> g  | cassandra | 2.0.0   |   0
>
> Config specifies:
> default_datastore_id = a
>
> 1. trove-cli instance create ...
> Just works - Since nothing is specified, this uses the
> default_datastore_id from the config (mysql 5.6.14 ) . No need for
> disambiguation.
>
> 2. trove-cli instance create --datastore_id e
> The datastore_id specified always identifies a unique datastore type /
> version so no other information is needed for disambiguation. (In this
> case redis 2.6.15, identified by )
>
> 3. trove-cli instance create --datastore_type postgres
> The datastore_type in this case uniquely identifies postgres 9.3.1 ,
> so no disambiguation is necessary.
>
> 4. trove-cli instance create --datastore_type cassandra
> In this case, there is only one _active_ datastore with the given
> datastore_type, so no further disambiguation is needed and cassandra
> 2.0.1  is uniquely identified.
>
> 5. trove-cli instance create --datastore_type redis
> In this case, there are _TWO_ active versions of the specified
> datastore_type (2.6.16, and 2.6.17) so the call should return that
> further disambiguation _is_ needed.
>
> 6. trove-cli instance create --datastore_type redis --datastore_version
> 2.6.16
> We have both datastore_type and datastore_version, and that uniquely
> identifies redis 2.6.16 . No further disambiguation is needed.
>
> 7. trove-cli instance create --datastore_type cassandra --version 2.0.0,
> or trove-cli instance create --datastore_id g
> Here, we are attempting to deploy a datastore which is _NOT_ active and
> this call should fail with an appropriate error message.
>
> Cheers,
> -Nikhil
>
>
> Andrey Shestakov writes:
>
> > 2. it can be confusing coz not clear to what type version belongs
> > (possible add "type" field in version).
> > also if you have default type, then specified version recognizes as
> > version of default type (no lookup in version.datastore_type_id)
> > but i think we can do lookup in version.datastore_type_id before pick
> > default.
> >
> > 4. if default version is need, then it should be specified in db, coz
> > switching via versions can be frequent and restart service to reload
> > config all times is not good.
> >
> > On 10/21/2013 05:12 PM, Tim Simpson wrote:
> >> Thanks for the feedback Andrey.
> >>
> >> >> 2. Got this case in irc, and decided to pass type and version
> >> together to avoid confusing.
> >> I don't understand how allowing the user to only pass the version
> >> would confuse anyone. Could you elaborate?
> >>
> >> >> 3. Names of types and maybe versions can be good, but in irc
> conversation rejected this case, i cant
> >> remember exactly reason.
> >> Hmm. Does anyone remember the reason for this?
> >>
> >> >> 4. Actually, "active" field in version marks it as default in type.
> >> >>Specify default version in config can be usefull if you have more then
> >> one active versions in default type.
> >> If 'active' is allowed to be set for multiple rows of the
> >> 'datastore_versions' table then it isn't a good substitute for the
> >> functionality I'm seeking, which is t

Re: [openstack-dev] Cantrip for syncing all the OpenStack repos locally

[Kieran Spear]

On 28 October 2013 05:46, Monty Taylor  wrote:
> Hey all!
>
> We still don't have grokmirror running, which I'd like to do to help
> local syncing of the bazillion git repos. (I frequently like to do that
> before getting on a plane) However - turns out there is a simple
> shell-script snippet you can run to get the job done well.
>
> It assumes you have an ssh host setup called "review" which points to
> review.openstack.org:29418. This will clone or update every repo in gerrit:
>
> for repo in `ssh review gerrit ls-projects` ; do
> mkdir -p $(dirname $repo)
> if [ ! -d $repo ] ; then
> echo "Cloning $repo"
> git clone git://git.openstack.org/$repo $repo
> (cd $repo; git review -s)
> else
> echo "Updating $repo"
> (cd $repo; git remote update)
> fi
> done

mr looks useful for this type of thing. I haven't got into the habit
of using it yet though.

http://myrepos.branchable.com/

"If you run mr update inside a repository, it'll only act on that
repository. In general, any mr command runs recursively over any
repository located somewhere in or under the current directory."

Cheers,
Kieran



>
> ___
> 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] Cantrip for syncing all the OpenStack repos locally

[Monty Taylor]

Hey all!

We still don't have grokmirror running, which I'd like to do to help
local syncing of the bazillion git repos. (I frequently like to do that
before getting on a plane) However - turns out there is a simple
shell-script snippet you can run to get the job done well.

It assumes you have an ssh host setup called "review" which points to
review.openstack.org:29418. This will clone or update every repo in gerrit:

for repo in `ssh review gerrit ls-projects` ; do
mkdir -p $(dirname $repo)
if [ ! -d $repo ] ; then
echo "Cloning $repo"
git clone git://git.openstack.org/$repo $repo
(cd $repo; git review -s)
else
echo "Updating $repo"
(cd $repo; git remote update)
fi
done

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

Re: [openstack-dev] [stackalytics] Official Programs tag?

[Robert Collins]

On 28 October 2013 04:32, Sean Dague  wrote:
> I've been looking at the stackalytics code and one of the areas that I think
> stackalytics has a structural issue is around the project_group tag.
>
> The existing project_group tags of "core", "incubation", "documentation",
> "infrastructure", and "other" are all fine and good, however none of these
> actually represent a number I'd like to see, which is Official Programs
> contributions over all.
>
> Which would be core + documentation + infrastructure + QA / Devstack trees
> (+ maybe Tripleo? I don't remember if that's Official or Incubated program
> at this point).

TripleO is official

NB: Incubation happens to projects, not programs.

-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] [Heat] Network topologies

[Edgar Magana]

Heat Developers,

I am one of the core developers for Neutron who is lately working on the
concept of "Network Topologies". I want to discuss with you if the
following blueprint will make sense to have in heat or neutron code:
https://blueprints.launchpad.net/neutron/+spec/network-topologies-api

Basically, I want to let tenants “save”, “duplicate” and “share” network
topologies by means of an API and a standardized JSON format that describes
network topologies. This google document provides detailed description:
https://docs.google.com/document/d/1nPkLcUma_nkmuHYxCuUZ8HuryH752gQnkmrZdXeE2LM/edit#

There is a concern in Neutron of not duplicating efforts done by Heat team
and also to find the right place for this API.

The intended work does NOT include any application driven orchestration
system, does NOT include any already existing or vender-specific standard
format for describing topologies, actually we want to standardized one
based on Neutron but it is still on discussion.

If Heat developers could provide their point of view about this proposal,
wether it should be moved to Heat or it is fine to keep it in Neutron.

Thanks,

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

[openstack-dev] [stackalytics] Official Programs tag?

[Sean Dague]

I've been looking at the stackalytics code and one of the areas that I 
think stackalytics has a structural issue is around the project_group tag.


The existing project_group tags of "core", "incubation", 
"documentation", "infrastructure", and "other" are all fine and good, 
however none of these actually represent a number I'd like to see, which 
is Official Programs contributions over all.


Which would be core + documentation + infrastructure + QA / Devstack 
trees (+ maybe Tripleo? I don't remember if that's Official or Incubated 
program at this point).


What would be the best way to add this in? Right now there is a lot of 
assumptions that project_group is a string, and I think it should be an 
array of strings instead, but the implications across the source base to 
me are pretty unclear from my cursory reads. So hints at implementing 
this would be good.


-Sean

--
Sean Dague
http://dague.net
project_group

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

Re: [openstack-dev] RFC - Icehouse logging harmonization

[Julien Danjou]

On Wed, Oct 23 2013, Sean Dague wrote:

> Goals - Short Term
> ===
> As much feedback as possible from both core projects and openstack deployers
> about the kinds of things that they believe we should be logging, and the
> kinds of levels they think those things should land at.
>
> Determining how crazy it is to try to harmonize this across services.
>
> Figure out who else wants to help. Where help means:
>  * helping figure out what's already concensus in services
>  * helping figure out things that are really aberrant from that concensus
>  * helping build concensus with various core teams on a common
>  * helping with contributions to projects that are interested in
> contributions to move them closer to the concensus
>
> Determining if everyone just hates the idea, and I should give up now. :)
> (That is a valid response to this RFC, feel free to put that out there).

Big +1 from here. We want to leverage the usage of log from all projects
in Ceilometer by coupling it with notifications in the future. So having
them being *very* good quality is going to be a must.

-- 
Julien Danjou
// Free Software hacker / independent consultant
// http://julien.danjou.info


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

Re: [openstack-dev] [Nova] Newbie help around bug #1240197

[Davanum Srinivas]

Shantanu,

Left some feedback on the bug report. Typically a lot of the dev folks
hang out on IRC, so that's another venue to get feedback
(#openstack-nova, #openstack-dev etc)

-- dims

On Sun, Oct 27, 2013 at 8:23 AM, Shantanu Tushar Jha  wrote:
> Hi everyone,
>
> I'm trying to get started with contributing to OpenStack in my free time.
> Going through the list of low-hanging-fruit bugs I found #1240197 which
> sounds pretty interesting to implement.
>
> I made a comment around the approach but it didn't really get any reply, can
> someone take a look and suggest?
>
> P.S. If I should be directly emailing the bug reporter instead of posting to
> the ML, let me know :)
>
> Thanks!
>
> --
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: http://davanum.wordpress.com

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

[openstack-dev] Icehouse Design Summit Etherpad wiki page

[Sean Dague]

As my searching did not yet return an Icehouse design summit pages in 
the wiki with etherpads, I built it here - 
https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads


For consistency it would be great if all the projects would use the same 
page when listing their design summit sessions, it makes it a ton easier 
for people that are jumping between tracks to only have one master entry 
point to be able to get to everything.


-Sean

--
Sean Dague
http://dague.net

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

[openstack-dev] [Nova] Newbie help around bug #1240197

[Shantanu Tushar Jha]

Hi everyone,

I'm trying to get started with contributing to OpenStack in my free time.
Going through the list of low-hanging-fruit bugs I found
#1240197which sounds
pretty interesting to implement.

I made a comment around the approach but it didn't really get any reply,
can someone take a look and suggest?

P.S. If I should be directly emailing the bug reporter instead of posting
to the ML, let me know :)

Thanks!

-- 
Shantanu Tushar(UTC +0530)
http://www.shantanutushar.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Stable backports

[Gary Kotton]

Hi,
In the case of stable back ports which have "Fixes bug: #XYZ" we will have to 
change this to the new format "Closes-bug: #XYZ". Any thoughts on this?
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] About ryu neutron plugin

[Yoshihiro Kaneko]

Hi Yong,

Could you explain the details of your problem?

Thanks,
Kaneko

2013/10/27 Yongsheng Gong :
> Hi,
> I am trying to set up a deployment via neutron ryu plugin, but it seems
> there is no way to set up it right with the latest neutron code and the
> latest ryu code . And the document about ryu with openstack is not updated
> for a long time. https://github.com/osrg/ryu/wiki/OpenStack
>
>
> Who is maintaining the neutron ryu plugin can help me with it?
>
> Thanks
> Yong Sheng Gong
>
>
>
> ___
> 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