Re: [openstack-dev] [heat][tacker][heat-translator] deliverables of heat-translator library

[HADDLETON, Robert W (Bob)]

The Tacker team is dependent on tosca-parser and heat-translator but 
they are not the only consumers.


I agree the structure is odd, and Sahdev has more of the history than I do.

In the past the requests from the Tacker team have come to Sahdev/me and 
we have created
releases as needed.  For some reason this time a request went to the 
Heat ML, in addition to

a separate request to me directly.

I'm open to changes in the structure but I don't think Tacker is the 
right place to put the

deliverables.

Bob

On 6/20/2018 11:31 AM, Rico Lin wrote:
To continue the discussion in 
http://lists.openstack.org/pipermail/openstack-dev/2018-June/131681.html


Add Tacker and heat-translator to make sure all aware this discussion

On Thu, Jun 21, 2018 at 12:28 AM Doug Hellmann > wrote:


Excerpts from Zane Bitter's message of 2018-06-20 12:07:49 -0400:
> On 20/06/18 11:40, Rico Lin wrote:
> > I send a release patch now
https://review.openstack.org/#/c/576895/
> > Also, add Bob Haddleton to this ML who is considering as PTL for
> > heat-translator team
>
> Is it time to consider moving the heat-translator and
tosca-parser repos
> from being deliverables of Heat to deliverables of Tacker? The
current
> weird structure dates from the days of the experiment with
OpenStack
> 'Programs' (vs. Projects).
>
> Heat cores don't really have time to be engaging with
heat-translator,
> and Tacker is clearly the major user and the thing that keeps
getting
> blocked on needing patches merged and releases made.

It sounds like it. I had no idea there was any reason to look to
anyone
other than the Heat PTL or liaison for approval of that release. A WIP
on the patch would have been OK, too, but if the Tacker team is really
the one responsible we should update the repo governance.

Doug

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
May The Force of OpenStack Be With You,

*/Rico Lin
/*irc: ricolin






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

Re: [openstack-dev] [heat] Need new release of heat-translator library

[HADDLETON, Robert W (Bob)]

This request had come to me from someone else in the Tacker team and I 
was working on including a couple of other patchsets in the release, but 
this is fine.


Please tag these requests as [heat-translator] in the subject so they 
get flagged to me and I'm happy to work them.


Bob

On 6/20/2018 10:40 AM, Rico Lin wrote:

I send a release patch now https://review.openstack.org/#/c/576895/
Also, add Bob Haddleton to this ML who is considering as PTL for 
heat-translator team


Ben Nemec mailto:openst...@nemebean.com>> 於 
2018年6月20日 週三 下午10:26寫道：




On 06/20/2018 02:58 AM, Patil, Tushar wrote:
> Hi,
>
> Few weeks back, we had proposed a patch [1] to add support for
translation of placement policies and that patch got merged.
>
> This feature will be consumed by tacker specs [2] which we are
planning to implement in Rocky release and it's implementation is
uploaded in patch [3]. Presently, the tests are failing on patch
[3] becoz it requires newer version of heat-translator library.
>
> Could you please release a new version of heat-translator
library so that we can complete specs[2] in Rocky timeframe.

Note that you can propose a release to the releases repo[1] and
then you
just need the PTL or release liaison to sign off on it.

1: http://git.openstack.org/cgit/openstack/releases/tree/README.rst

-Ben

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
May The Force of OpenStack Be With You,
*/Rico Lin
/*irc: ricolin





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

Re: [openstack-dev] [heat][tacker][murano][RelMgmt] heat-translator deliverable type?

[HADDLETON, Robert W (Bob)]

On 2/9/2018 10:18 AM, Matthew Thode wrote:

On 18-02-09 10:10:10, Sean McGinnis wrote:

Hello Heat team,

The release team just recently noticed the heat-translator deliverable is
marked as a type of "other" and is following the release-model of
"cycle-with-intermediary".

It appears this is actually a library though. It's hard to tell, but it is
either a client lib or non-client lib. In either case, we need to mark it as
such and treat its release according to that type.

In order to stabilize requirements changes, we have two separate deadlines,
first for non-client libs, then a week later for client libs. Since
heat-translator appears to be a dependency used by other projects, it will need
to be subject to those release deadlines.

Can the team clarify what type of library this is, and change the type going
forward to accurately reflect that?

Please let the release team know if there are any questions.


I think tacker and murano may be using it in a non-intended way (those
are the only projects I could find that's using it).

https://github.com/openstack/tacker/search?utf8=%E2%9C%93=translator=
https://github.com/openstack/murano/search?utf8=%E2%9C%93=translator=
Tacker worked with us on their usage so it's a known scenario.  I wasn't 
aware that Murano was using h-t, but if the implementation is similar to 
Tacker's it should be fine.


spzala knows more of the history than I do, but heat-translator, like 
tosca-parser, was originally a stand-alone client that has evolved into 
a library that can be used by other projects.  Both projects are now 
used as libraries by Tacker, and possibly others, in addition to having 
users of the command-line clients.


When we moved into the release model it was suggested that we use type 
"other", but I'm happy to change to whatever the appropriate release 
type is.  Both projects are fairly low volume at the moment, so we don't 
need a lot of releases.


Thanks

Bob Haddleton

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

Re: [openstack-dev] [oslo][mistral] Mistral expressions package

[HADDLETON, Robert W (Bob)]

On 10/9/2017 2:35 PM, Doug Hellmann wrote:

Excerpts from Bob Haddleton's message of 2017-10-09 11:35:16 -0500:

Hello Oslo team:

The Mistral project has an expressions package [0] that is used to
evaluate inline expressions using a context.  It has a pluggable
architecture that presently supports Jinja and YAQL expression
evaluation.  It also allows custom functions[1] to provide Python
implementations of functionality that is then made available to the
expression evaluation engines.

This functionality was originally developed to support dynamic
processing within Mistral workflows, but is also very useful in other
applications that use templates which require runtime evaluation of
expressions.

I'd like to explore extracting this functionality from mistral to make
it more widely available with minimal dependencies.

The expressions dependencies are pretty limited:

Jinja2
oslo.utils
oslo.log
stevedore
yaql

and since 60% are already oslo-maintained packages, it seemed like a
logical place to start.

I'd appreciate feedback on the topic.  There is no real OpenStack
dependency in the functionality, so maybe a standalone package on pypi
makes sense.

Thanks for your help,

Bob Haddleton


[0] https://github.com/openstack/mistral/tree/master/mistral/expressions
[1]
https://github.com/openstack/mistral/blob/master/mistral/utils/expression_utils.py#L63


Oslo is a good place for things like this that have no other obvious
home, but if the Mistral team is already managing the code is there any
reason they couldn't also manage the library after you pull it out of
the service? It's much easier for any project team to manage a library
now, and we have several other examples of that pattern already.

Doug

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

Hi Doug:

That's probably fine, we're just not sure what the process should be and 
where the library would land?  Do you have an example that we could use 
as a pattern?


Thanks

Bob

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

[openstack-dev] [tosca-parser][heat-translator] Next two IRC meetings canceled

[HADDLETON, Robert W (Bob)]

The IRC meetings for this week (today) and next week are canceled due to 
travel and the Boston Summit.


We will resume on May 18.

Thanks

Bob

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

[openstack-dev] [tosca-parser][heat-translator] IRC Meeting Time change - Thursdays 1400UTC

[HADDLETON, Robert W (Bob)]

This is just to confirm that the tosca-parser/heat-translator weekly IRC 
meeting is now Thursdays at 1400UTC in #openstack-heat-translator


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

[openstack-dev] [tosca-parser][heat-translator] Meeting Time change

[HADDLETON, Robert W (Bob)]

The combined tosca-parser/heat-translator weekly IRC meeting has been on 
Thursdays at 1600UTC in #openstack-heat-translator.


Due to scheduling conflicts I need to change the meeting time, and I'd 
like to propose Thursdays at 1400UTC.


Please reply with any questions/concerns/counter-proposals.

Thanks

Bob Haddleton

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

Re: [openstack-dev] [mistral] Using mistral to start a not-to-die task

[HADDLETON, Robert W (Bob)]

Hi Gongysh:

You are looking for mistral cron-triggers.

See 
https://docs.openstack.org/developer/mistral/terminology/cron_triggers.html


Bob

On 3/22/2017 7:16 PM, gongys2017 wrote:

Hi mistral stackers,

Tacker is using the mistral as its part of system. Now we have a 
requirement:


tacker server registers an openstack as its NFVI, and needs to pinghttp-ping) the openstack's management IP,
for example the keystone URL until tacker updates or delete the 
openstack NFVI.


Can the mistral be asked to start a workflow which  contains just such 
a kind of task:

for ever running until extenal tells him to stop.


Thanks


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


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

Re: [openstack-dev] [tacker] Core team changes / proposing Dharmendra Kushwaha

[HADDLETON, Robert W (Bob)]

+1

Thanks Stephen!  And welcome aboard Dharmendra!

Bob

On 1/24/2017 6:58 PM, Sridhar Ramaswamy wrote:

Tackers,

I'd like to propose following changes to the Tacker core team.

Stephen Wong

After being associated with Tacker project from its genesis, Stephen
Wong (irc: s3wong) has decided to step down from the core-team. I
would like to thank Stephen for his contribution to Tacker,
particularly for his help navigating the initial days splitting off
Neutron and in re-launching this project in Vancouver summit for
TOSCA-based NFV Orchestration. His recent effort in writing the SFC
driver to support VNF Forwarding Graph is much appreciated. Thanks
Stephen!

Dharmendra Kushwaha

It gives me great pleasure to propose Dharmendra (irc:  dkushwaha) to
join the Tacker core team. Dharmendra's contributions to tacker
started in Jan 2016. He is an active contributor across the board [1]
in bug fixes, code cleanups and, most recently, as a lead author of
the Network Services Descriptor blueprint.

Also, Dharmendra recently stepped up to take care of bug triage for
Tacker. There is an uptick in deployment issues reported through LP
[2] and in irc - which itself is a good healthy thing. Now we need to
respond by fixing the issues reported promptly. Dharmendra’s help will
be immensely valuable here.

Existing cores - please vote +1 / -1.

thanks,
Sridhar

[1] 
http://stackalytics.com/?module=tacker-group_id=dharmendra-kushwaha=marks
[2] https://answers.launchpad.net/tacker

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


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

Re: [openstack-dev] [Tacker] Unable to assign IP address to connection points.

[HADDLETON, Robert W (Bob)]

Hi Prasad:
The first two things to check are:

1 - Check the VM instance in Horizon to confirm that there are three IP 
addresses assigned to it.  If there is only one IP address assigned to 
the VM, check the subnet configuration for the vnf_private and private 
networks and make sure they have DHCP enabled.


2 - Verify that the image you are using is configured to enable DHCP on 
eth1 and eth2 or their equivalent network interfaces.


If there ARE three IP addresses assigned to the VM from step 1 then it 
is likely that the image is not configured to support DHCP on eth1 and eth2.
You would need to either modify the image to enabled DHCP on eth1 and 
eth2 and then save the modified image, or find a new image that has DHCP 
enabled on those ports.


Hope this helps

Bob


On 11/16/2016 4:11 AM, prasad kokkula wrote:

Hi All,

[Tacker]   I have tried to launch the vnf Instance using Tacker. vnf 
is launched succesfully and able to do SSH.


I have faced the issue, the connection points (CP2, CP3) are not 
getting ip addreess except managament CP (CP1). Could you please let 
me know is this Tacker issue or any configuration mismatch.


I have installed openstack newton release on Centos 7. Please let me 
know if you need any other configuration.




=
Below are the net-list ip's

[root@localhost (keystone_admin)]# neutron net-list
+--+-+---+
| id   | name| subnets 
  |

+--+-+---+
| 55077c0e-8291-4730-99b4-f280967cb69e | public  | 
39256aad-d075-4c38-bf2c-14613df2252e 172.24.4.224/28 
  |
| 73bbaf70-9bdd-4359-a3a2-09dbd5734341 | private | 
09b9018c-ca3b-46ee-9a4e-507e5124139f 10.0.0.0/24 
  |
| d0560ee9-9ab0-4df8-a0d2-14064950a17c | vnf_mgmt  | 
01d2b67c-ee28-4875-92e0-a8e51fdf8401 192.168.200.0/24 
 |
| f98f38b8-8b6c-4adb-b0e9-a265ce969acf | vnf_private | 
61d39f59-2ff7-4292-afd9-536f007fd30c 192.168.201.0/24 
 |

+--+-+---+
[root@localhost (keystone_admin)]#

Tosca file used for vnf creation.


[root@localhost (keystone_admin)]# cat sample-vnfd.yaml

tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0

description: Demo vCPE example

metadata:
  template_name: sample-tosca-vnfd

topology_template:
  node_templates:
VDU1:
  type: tosca.nodes.nfv.VDU.Tacker
  capabilities:
nfv_compute:
  properties:
num_cpus: 1
mem_size: 512 MB
disk_size: 1 GB
  properties:
image: cirros1
availability_zone: nova
mgmt_driver: noop
user_data_format: RAW
config: |
  param0: key1
  param1: key2

CP1:
  type: tosca.nodes.nfv.CP.Tacker
  properties:
management: true
  requirements:
- virtualLink:
node: VL1
- virtualBinding:
node: VDU1

CP2:
  type: tosca.nodes.nfv.CP.Tacker
  properties:
anti_spoofing_protection: false
  requirements:
- virtualLink:
node: VL2
- virtualBinding:
node: VDU1

CP3:
  type: tosca.nodes.nfv.CP.Tacker
  properties:
anti_spoofing_protection: false
  requirements:
- virtualLink:
node: VL3
- virtualBinding:
node: VDU1

VL1:
  type: tosca.nodes.nfv.VL
  properties:
network_name: vnf_mgmt
vendor: Tacker

VL2:
  type: tosca.nodes.nfv.VL
  properties:
network_name: vnf_private
vendor: Tacker

VL3:
  type: tosca.nodes.nfv.VL
  properties:
network_name: private
vendor: Tacker

===


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


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

Re: [openstack-dev] [tacker] Proposing Yong Sheng Gong for Tacker core team

[HADDLETON, Robert W (Bob)]

+1

On 8/23/2016 10:55 AM, Sridhar Ramaswamy wrote:

Tackers,

I'd like to propose Yong Sheng Gong to join the Tacker core team. Yong 
is a seasoned OpenStacker and has been contributing to Tacker project 
since Nov 2015 (early Mitaka). He has been the major force in helping 
Tacker to shed its /Neutronisms/. He has low tolerance on unevenness 
in the code base and he fixes them as he goes. Yong also participated 
in the Enhanced Placement Awareness (EPA) blueprint in the Mitaka 
cycle. For Newton he took up himself cleaning up the DB schema and in 
numerous reviews to keep the project going. He has been a dependable 
member of the Tacker community [1].


Please chime in with your +1 / -1 votes.

thanks,
Sridhar

[1] http://stackalytics.com/report/contribution/tacker/90


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


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

Re: [openstack-dev] [tacker] Proposing Kanagaraj Manickam to Tacker core team

[HADDLETON, Robert W (Bob)]

+1.  Kanagaraj will be a great addition to the team.

Bob

On 6/16/2016 1:45 PM, Karthik Natarajan wrote:


+1. Thanks Kanagaraj for making such a great impact during the Newton 
cycle.


*From:*Sripriya Seetharam [mailto:ssee...@brocade.com]
*Sent:* Thursday, June 16, 2016 10:35 AM
*To:* OpenStack Development Mailing List (not for usage questions) 

*Subject:* Re: [openstack-dev] [tacker] Proposing Kanagaraj Manickam 
to Tacker core team


+1

-Sripriya

*From:*Sridhar Ramaswamy [mailto:sric...@gmail.com]
*Sent:* Wednesday, June 15, 2016 6:32 PM
*To:* OpenStack Development Mailing List (not for usage questions) 
>
*Subject:* [openstack-dev] [tacker] Proposing Kanagaraj Manickam to 
Tacker core team


Tackers,

It gives me great pleasure to propose Kanagaraj Manickam to join the 
Tacker core team. In a short time, Kanagaraj has grown into a key 
member of the Tacker team. His enthusiasm and dedication to get Tacker 
code base on par with other leading OpenStack projects is very much 
appreciated. He is already working on two important specs in Newton 
cycle and many more fixes and RFEs [1]. Kanagaraj is also a core 
member in the Heat project and this lends well as we heavily use Heat 
for many Tacker features.


Please provide your +1/-1 votes.

- Sridhar

[1] 
http://stackalytics.com/?module=tacker-group_id=kanagaraj-manickam=marks 





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


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

Re: [openstack-dev] [tacker] Proposing Lin Cheng for tacker-horizon core team

[HADDLETON, Robert W (Bob)]

+1


On 5/26/2016 12:45 PM, Sridhar Ramaswamy wrote:

Tackers,

I'd like to propose Lin Cheng to join as a tacker-horizon core team 
member. Lin has been our go-to person for all guidance related to UI 
enhancements for Tacker. He has been actively reviewing patchsets in 
this area [1] and also contributed to setup the unit test framework 
for tacker-horizon repo.


Please provide your +1/-1 votes.

- Sridhar

[1] 
http://stackalytics.com/?project_type=all=marks=all=tacker-group_id=lin-hua-cheng



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


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

Re: [openstack-dev] [glance] [glare] [heat] [tosca] [tacker] [murano] [magnum] [app-catalog] Austin summit summary: Generic cataloging and Glare v1 API

[HADDLETON, Robert W (Bob)]

Hi Nikhil:
The Tacker project may also be interested in using Glare during 
this cycle.  Is there any API or other documentation/examples that we 
could use to start?


Thanks

Bob

On 5/3/2016 2:40 PM, EXT Nikhil Komawar wrote:

Comment inline.

On 5/3/16 3:21 PM, Flavio Percoco wrote:

On 02/05/16 19:09 -0400, Nikhil Komawar wrote:


Added a few more tags to the subject line.



On 5/2/16 7:05 PM, Nikhil Komawar wrote:


Hello everyone,



Just wanted to send a brief summary of the discussions at the summit.

This list is not holistic however, it covers the relevant aspects that

various stakeholders need to be aware of.



   * Glare is useful for different use cases in OpenStack including

 currently being asked for in Heat, Murano and TOSCA

   * Heat needs something for usage in Newton

   * Murano needs the stable API to adapt the changes as they currently

 use experimental version

   * Glance team will continue to make progress on this effort and plan

 to have POC after Newton R-16 [1]

   * The initial plan is to focus on base artifact (no data asset

 associated) and then support at least one artifact type

   * The first artifact can be Murano application catalogs or Heat

 templates depending on either team's priorities when Glare is ready

 for consumption

   * In Newton, we will focus on the adoption of this service in at least

 the above mentioned two projects and getting the API in good shape

   * Images compatibility is deferred for now

   * Glare will be a side-priority for Newton meaning most of the cores

 are currently not expected to prioritize reviews on it except for

 those who want to focus on cross project initiatives and those

 involved in its adoption



Does this mean there will be some sort of "Fast Track" again? I'm
asking because

No, we won't have the FastTrack model. But at the same time, we want to
iterate over the code once that is consumed by the first service so that
the behavioral changes found during that phase can be corrected before
m-3. The end goal is to have a good API that can be consumed by other
services (and something compliant with OpenStack standards).


I believe this model polarizes the community a bit as far as picking
reviews go.

We voted to remove it in Mitaka and I was hoping we would workout a
way to bring

the community together in the Glare reviews.

My goal is to have champions for each module that is being worked on in
Newton (import, micro-versions, glare, documentation, etc) . This does
have a little bit of effect in creating tribal knowledge but we do have
that even today. The iterative plan though (yet to be formalized) is
that we need some sort of knowledge sharing model. I have been trying to
do that using the dedicated Glare meetings but we may need other models
of KT (knowledge transfer) here.




Please, don't get me wrong. As far as priorities go, I agree with what
you've

Thanks for bringing this up. Refines the thought process for sure.


said in the last point but review wise, I'm worried this would
implicitly bring

back some kind of fast track model.



Let's not go with the FastTrack model :-)


Cheers,

Flavio





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






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

[openstack-dev] [heat-translator][tacker] Etherpad for TOSCA NFV to Heat translation

[HADDLETON, Robert W (Bob)]

I created an Etherpad [1] to discuss the mapping of TOSCA NFV objects 
[2] to Heat resources by heat-translator, in support of this [3] blueprint.


The related tosca-parser work [4][5] is finishing up, so the next step 
is to map these objects into Heat resources.


This will likely be a work-in-progress for a while, but please 
comment/edit/etc if you have any input.


Thanks

Bob

[1] https://etherpad.openstack.org/p/tosca-nfv-heat-translation
[2] 
http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/csd02/tosca-nfv-v1.0-csd02.html

[3] https://blueprints.launchpad.net/heat-translator/+spec/tosca-nfv-support
[4] https://blueprints.launchpad.net/tosca-parser/+spec/tosca-nfv-support
[5] https://review.openstack.org/#/c/253689/5

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

Re: [openstack-dev] [tacker] Proposing Sripriya Seetharam to Tacker core

[HADDLETON, Robert W (Bob)]

+1

Well deserved!

Bob

On Nov 9, 2015, at 8:23 PM, Sridhar Ramaswamy 
> wrote:

I'd like to propose Sripriya Seetharam to join the Tacker core team. Sripriya
ramped up quickly in early Liberty cycle and had become an expert in the Tacker
code base. Her major contributions include landing MANO API blueprint,
introducing unit test framework along with the initial unit-tests and tirelessly
squashing hard to resolve bugs (including chasing the recent nova-neutron goose
hunt). Her reviews are solid fine tooth comb and constructive [1].

I'm glad to welcome Sripriya to the core team. Current cores members, please 
vote
with your +1 / -1.

[1] 
http://stackalytics.com/?release=libertyuser_id=sseethaproject_type=openstack-others
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Tacker

[HADDLETON, Robert W (Bob)]

Hi Ivan:
You need to add an entry in /etc/tacker/tacker.conf under servicevm:

[servicevm]
# Specify drivers for mgmt
mgmt_driver = noop
mgmt_driver = openwrt
mgmt_driver = nfvpilot

You will also need to update setup.cfg with an entry point for the 
driver.  This is assuming your object class is called DeviceMgmtNFVPilot:


tacker.servicevm.mgmt.drivers =
noop = tacker.vm.mgmt_drivers.noop:DeviceMgmtNoop
openwrt = tacker.vm.mgmt_drivers.openwrt.openwrt:DeviceMgmtOpenWRT
nfvpilot = tackervm.mgmt_drivers.nfvpilot.nfvpilot:DeviceMgmtNFVPilot

If you are installing into a running devstack, you will need to update 
the tacker.egg-info/entry_points.txt file with the same information:


tacker.servicevm.mgmt.drivers =
noop = tacker.vm.mgmt_drivers.noop:DeviceMgmtNoop
openwrt = tacker.vm.mgmt_drivers.openwrt.openwrt:DeviceMgmtOpenWRT
nfvpilot = tackervm.mgmt_drivers.nfvpilot.nfvpilot:DeviceMgmtNFVPilot

Then restart the tacker server.

Hope this helps

Bob


On 10/27/2015 1:42 AM, Ivan Lozgachev wrote:

Hello everyone!

Could you please help me implement custom management driver?

At the moment I created 
directory /opt/stack/tacker/tacker/vm/mgmt_drivers/nfvpilot/ and put 
there __init__.py and nfvpilot.py driver implementation as it' done 
for example for OpenWRT driver. But while creating my VNF I always get 
error


2015-10-20 10:33:28.409 TRACE tacker.api.v1.resource File 
"/opt/stack/tacker/tacker/vm/plugin.py", line 66, in mgmt_create_pre
2015-10-20 10:33:28.409 TRACE tacker.api.v1.resource device_dict, 
plugin=self, context=context, device=device_dict)
2015-10-20 10:33:28.409 TRACE tacker.api.v1.resource File 
"/opt/stack/tacker/tacker/vm/plugin.py", line 62, in _invoke
2015-10-20 10:33:28.409 TRACE tacker.api.v1.resource 
self._mgmt_driver_name(device_dict), method, **kwargs)
2015-10-20 10:33:28.409 TRACE tacker.api.v1.resource File 
"/opt/stack/tacker/tacker/common/driver_manager.py", line 74, in invoke
2015-10-20 10:33:28.409 TRACE tacker.api.v1.resource driver = 
self._drivers[type_]

2015-10-20 10:33:28.409 TRACE tacker.api.v1.resource KeyError: u'nfvpilot'

How do I register my own driver to make it visible?


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


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

Re: [openstack-dev] [mistral] Define better terms for WAITING and DELAYED states

[HADDLETON, Robert W (Bob)]

Hi Renat:

[TL;DR] - maybe use multiple words in the state name to avoid confusion

I agree that there is a lot of overlap - WAITING and DELAYED and 
POSTPONED are all very similar.  The context is important when trying to 
decipher what the words means.


I would normally interpret WAITING as having a known condition:

* I'm WAITING for the baseball game to begin

DELAYED implies WAITING but adds the context that something was supposed 
to have started already, or has already started, is now blocked by 
something out of your control, and you may or may not know when it will 
start again:


* The (start of the) ballgame has been DELAYED (by rain) (until 2:00). 
(So I'm still WAITING for it to begin)


POSTPONED implies DELAYED, but adds that something was "scheduled" to 
start at a certain time and has been re-scheduled for a later time.  It 
may or may not have started already, and the later time may or may not 
be known:


* The ballgame has been POSTPONED (because of rain) (until tomorrow) (so 
the game has been DELAYED and I'm still WAITING for it to start)


So using any of the three words on their own without context or 
additional information will likely be confusing, or at least subject to 
different interpretations.


I would be reluctant to rename DELAYED to POSTPONED, because it raises 
more questions (until when?) than DELAYED without providing more answers.


I think what it comes down to is the need to provide more information in 
the state name than is possible with one English word:


WAITING_FOR_PRECONDITIONS
DELAYED_BY_RETRY

These provide more specific context to the state but the state 
transition table gets to be unmanageable when there is a state for 
everything.


If more Waiting/delayed states are added it in the future it might make 
sense to create them as sub-states of RUNNING, to keep the transitions 
manageable.


Hope this helps

Bob


On 9/18/2015 8:55 AM, Renat Akhmerov wrote:

Hello,

We have a bug [1] that addresses the small semantical issue in names of
the states for workflow and task executions: WAITING and DELAYED.
I’m really interested in your opinion about this. Especially native
english speakers’ opinion because, IMO, they would be able to challenge
better what we’re discussing.

*Problem description*
*
*
We now have a set of states:

  * IDLE  - Nothing is going on, object was just created
  * RUNNING - Workflow/task is running
  * PAUSED - Workflow/task has been paused
  * SUCCESS - Workflow/task has completed successfully
  * ERROR - Workflow/task has completed with an error
  * WAITING - Task execution object has been created but it is not ready
to start because some preconditions were not met. For now it mostly
refers to a case when we have a ‘join’ task depending on a number of
other tasks, e.g. ‘task1’ depends on ‘task2’ and ‘task3’. But say
‘task2’ has completed and ‘task3’ has not and hence ‘task1’ has to
wait. I may assume that in the future it may be related not only to
joins.
  * DELAYED - Task has been delayed for a certain number of seconds. I
may happen, for example, in case of using ‘retry’ policy.


So the semantical difference between WAITING and DELAYED is the
following: Unlike WAITING, DELAYED says that we know exactly that the
task will run, it’s just a matter of time. In case of WAITING, it may
never run just because some of the preconditions may never be met.

And the concern is that we probably don’t use good names for WAITING and
DELAYED because, from English language perspective, they look similar to
a number of folks (including myself) and it’s therefore confusing if we
look at two tasks with states WAITING and DELAYED.

The latest idea that we had is just to rename DELAYED to POSTPONED
because the latter sort of expresses the fact of being postponed for a
certain period of time slightly better :) But I’m really not sure.

Would appreciate your input on this.

Thanks

[1] https://bugs.launchpad.net/mistral/+bug/1470369

Renat Akhmerov
@ Mirantis Inc.





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



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